Sunday, April 19, 2009

MINOS 09 - Saturday Late Afternoon

Garry Bulmer - Kids doing electronics, Embedded Control, Robotics. Existing schools kits, hand outs, breadboards, class PCs. Arduino development board. Various projects around these - including line follower robot.

Ken Hewitt - Overview of the Parallax Propeller Chip

Alan Dibley - More diagonal paths.

Saturday, April 18, 2009

MINOS 09 - Saturday Early Afternoon

Martin Barratt - IR-based wall sensing circuits, technical considerations and choice in detail

Martyn Pittuck - Adaptive Control - Mouse overview, and technical overview of details. Sensor FFT. Applying adaptive control to skidding, predictive to next turn. Generating trajectories using Bezier curves. Estimating friction. Controller operation and cornering offset and exit angles.

David Hannaford & Pete Harrison - Flood Algorithms & Route Planning - Discussion of the basic principles of flood algorithms and possible visited cell optimization. Methods of finding diagonal paths. Asynchronous flooding by Alan Dibley.

MINOS 09 - Saturday Morning

Good information this morning.

1. Dave O. in-wall start/end detectors. Also update on accelerometer and gyroscope work.

2. Duncan - "weightless communications" - Transmission of data using same IR LEDs used for wall sensing.

3. Derek - maze solver work. 256 bits. 1 bit/square maze solver... do whole lot again on every single square. bit flood.

Then 2 bits per square... four directions. Same thing.. go out with arrow points towards previous arrow.

Also discussed problems with finding optimal route for all mazes.

Saturday, April 11, 2009

Some Wall Detector Problems

The wall detector I've been working on has some pretty serious, but probably fixable, problems.

1. There is not enough overlap between the walls and the detectors. There are three solutions, I think, here:
  • a. Probably the detectors need to be wider (simple to do)
  • b. The bearing looks like it is sometimes off - so perhaps I need to average using a second bearing line (a little work but possible).
  • c. Also the detectors need position tweaking to avoid problems with the camera distortion, etc. This is not difficult but time consuming. This was expected, to be honest, because of the camera distortion and the slight camera rotation (around Z axis).

2. The walls appear to be offset by 180mm (one cell) in 'Z' (front/back direction) from the detectors. Have no clue what this is.

3. When the robot is at an angle other than straight ahead, we need a different set of detectors or extra detectors, on that side. This is a fair amount of work but possible and probably necessary. I can't use a single (large) set of detectors because of 1c above (and it would also be slower... not that I'm worrying about speed at this point). There might be a way of automatically adjusting detectors based on this camera distortion/rotation - but I haven't thought about this yet.

4. The line intersection with detection rectangle code probably needs enhancing to make diagonals more likely to get hit. It looks to me as though this will cause problems without this - although I'm going to do a hack to make sure it's quick, if less accurate.

I haven't actually debugged the wall detector code - this was from the graphical Mac app getting data about the wall detector positions from the robot and overlaying it with data from the rotated plan view.

The enhancements to the graphical app and the robot side collection of data were a fair amount of work this morning. Whilst I was doing this, ironically, the command line integer number input routine turned out to have a bug in it - it ignored the minus sign - trivial to fix but more time. I also had to add a method to transmit a bunch of data without using binary ... basically a simple base 64 type encoding to keep the characters in the printable ASCII range.

I also put in some code to use blue compare with red as opposed to green compare with red to overcome problems with bright sunlight coming from the side - I think this is what I was seeing a couple of weekends ago with the faint picture. I also need to check pixel positions of blue vs. red, because of the missing blue at the start of the line and put this in as a settable non-volatile option. It's a good job we hadn't gone to a RG only bus (hardware change that uses 16 bit mode with only 8 bits physically wired).

Was hoping to get the wall detectors as well as the robot position stuff (that Alan was working on) done today, but that looks unlikely.

The good news, I guess, is that the basic principle of wall detectors and rotated plan view looks like it will work. Which is good, since the alternative is a re-write!

Other random stuff

Still need to add the black card to shield the shaft encoders.

Measured bearings of greater than 45 degrees needs work on - these will usually mean we have a bearing based on a horizontal line not a vertical line, since horizontal lines will always be less than 45 degrees. This will cause us problems as soon as there aren't any local vertical lines.

We also need to be able to measure robot position (in Z) without horizontal walls - there are three options: dead reckoning, horizontal wall gaps (what IR mice use) and stop and rotate 90 to check (and then rotate back 90). No code for either of the last two yet - although it might be fine to ignore for the wall follower case.

Running by MINOS?

What does all this mean for MINOS next weekend? I'm not sure, there is still a lot to do - but I'm pretty sure I'm not going to get the maze solver in. Assuming I can get the wall detection routines working, finish the robot position detect then write a movement control routines (I have the movement code and just need to link in some control code that uses the vision) then a non-contact wall follower might be possible.

Tuesday, April 07, 2009

Image corners and camera angle

Sorted out the segment processor going around corners ("corner cutting of the line detector"). Took me most of the time figuring out how process_segments worked (which is my own code)! Added some (more) comments on each block just in case I need to change it again. Once this was done, I basically added a very simple positive or negative gradient rule check into the segment processor that maintains the previous direction when matching segments.

Also squished a bug where I couldn't alter the camera angle - and in fact this was part of the reason why I was seeing distorted plan view images - although it eventually needed adjusting from 20.5 degrees to 24 degrees look down to make the plan view image look right.

Also ended up adding a command to list the internal trig variables and world Z table used by the reverse perspective. This showed these variables weren't changing when the camera angle changed. The serial command line really has been essential in the development of the mouse.

Two things that are bugging me is the slight (physical) rotation of the camera (around Z ... where Z is the direction the robot faces) and not knowing how fast these routines are running. However, neither problem is critical to getting the mouse running so I've leaving them. (The rotation could be fixed in software or hardware ... obviously physically adjusting the mount would be the least processing power ... but perhaps let's not touch the hardware at this late stage!)

Things next are: position location from the image lines, maze wall detection and some black card to make sure the shaft encoders work in bright light.

The maze wall detection is interesting - Basically I'm thinking about using circular or rectangular 'detection' areas to find the walls indicated by the lines. I've been contemplating which is the fastest option. I'm not an expert in a fast integer approach, but my previous work in 3d (game) collision detection with spheres and viewport clipping seems to be applicable here.

Saturday, April 04, 2009

More Mouse

Sorted out the plan image rotation problem. Simple problem: z instead of x in the rotation formula. Should have been:

new_x = x * cos(A) - z * sin(A)
new_z = z * cos(A) + x * sin(A)

Still investigating the faint picture.

Next up: Sort out the corner cutting of the line detector - the problem mentioned that when pointing at 45 degrees the image processor sometimes makes corners into a single line, effectively straightening out the corner.

Alan is testing getting the world x and z position from the rotated plan image, by using the wall distance modulo 180mm.

Friday, April 03, 2009

Variable results

Last night, looked at the robot problem I was having with different lighting conditions between the robot operation and the picture download. Could I reproduce it? Of course not. But the lighting conditions were not the same - it was dark outside last night, but light when I noted the problem - so it could be an issue with that.

So we (Alan and I) looked at why vertical lines seem to be rotated ok, but horizontal lines appear to be being rotated the opposite direction. No clues yet.

Thursday, April 02, 2009

Importer Status 2nd April 2009

I've posted this to the LWC forum, but I think I'll post it here as well - to document one of my other projects - the LWC wlk data importer.

Currently the importer script changes a .wlk file, another script handles an entire collection of files and the basic GUI is together.

Not too much to do now (hopefully).

Things left to do for LWC v1 importer:
  • Check/correct time in seconds in/out (This is related to the OS storing dates in DST format in LWC)
  • Check conversion in and out by eye ... for every single element in, at least, one data file.
  • Check output directory ... do we want this separate or automatically put in the LWC data folder (currently separate)
  • change exit() on deep error into something more 'sociable' (e.g. exceptions) (internal thing - but ensures the GUI gets the proper message)
  • One of the sample data files gives "ERROR: Unknown collector type", fix
  • Create application bundle for easy use (single 'file' for importer)
  • Link the GUI to the import script
  • Add detail and error log to GUI
  • Get more data files to check against (since we had an import error above)
  • Get Stu to review it before Beta testing
  • Beta Test!
Newer›  ‹Older