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:
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.
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.
posted by RobZed at 6:50 pm
0 Comments:
Post a Comment
<< Home