Is this robot really accurate though? With so many dead reckoning movements I expect it wouldn't be able to do this over a wide range of battery conditions. Dust and other factors will also affect it.
Perhaps I missed it? Dual light sensors/another method would help, but not solve problems completely. I do see the ultrasonic sensor, but that won't keep the robot going straight along the same line the entire time.
Well, from the video... yes, this robot really is this accurate (at least for one take of the video). Notice that the robot in question used very slow (i.e., non-skidding) turns for positioning. With the motor encoders, battery voltage isn't a factor - remember the robot knows exactly how far each tire has moved, not just ""how long have i been running them" like on the RCX. The US sensor appears to be for looking down to detect the presence (not the approach angle) of the gap to be bridged.
In general I don't trust dead-reckoning for much, for all the reason you suggest. But clearly it can work reasonably well in certain circumstances, and certainly far better under the NXT than for the RCX (as a lot of FLL teams found out this year... hey FLL, how about movable or randomly-placed challenges to require sensors? hinthint...).
Did you notice that the robot used the "swing-turn" technique ( 2nd motor stopped). I usually encourage the "point-turn" technique ( 2nd motor rotates in opposite direction.
Has there been any studies as to which technique is more accurate(turn at exactly a 90 or 180 degree angle)? Do both techniques tend to skid at the same speeds?
Brian - the one thing you're leaving out is backlash. While the NXT may have 1 degree of accuracy in the encoders, backlash brings this down several factors.
David - using a spin (both motors opposite directions) cuts your accuracy in half because you are registering half as many degrees. Why do you recommend this type of turn?
"cuts your accuracy in half" Is that really true or maybe just for very short vehicle turns?
I like the spin turn because it doesn't cause the vehicle to drift off it's last position. However that may not always be an issue if your only concern is that the vehicle should be accurately turned to its new angle.
Well, first, I'm not leaving off backlash, but answering your original question - obviously it *is* accurate enough to execute this sort of solution to the problem, at least twice in a row., and I then pointed out that some of the factors you mentioned (battery state, for instance), are explicitly addressed by using encoders. Yep, backlash can be a problem... but it can also be compensated for by knowing how much there is and when (and when it does not) come into play. Not always, but it certainly can work often. Again, look at the number of teams that used dead reckoning (very successfully!) with the NXT in FLL this year. It's not a perfect method, and not the method I usually choose... but it clearly works in some cases, and as my mother used to say, "if it ain't broke, don't fix it" :-).
As to "which turn is better", again, I suspect it's kind of like programming - it depends on what the problem is and what your solution is. For instance, a pivot turn (my name for "running one wheel while the other is held stationary") does offer twice the angular resolution for a turn... because the radius of the turn is effectively doubled. You could get the same thing by making the axle length twice as large and executing a "spin turn" (one wheel one way, the other opposite). Spin turns have the advantage of keeping the motion of the robot nearly in a "pure rotation" mode, so you don't have to account for the physical displacement of the robot during the turn (as David said). Also, pivot turns can be subject to greater inaccuracy on certain surfaces, because you are depending on the "locked" tire to act as a good pivot... which is not true on carpet, where it may slip, or if you don't consider backlash.
Just my opinion, but the perfect solution usually only exist in a perfectly artificial problem - the real world often accomodates a lot of different approaches to the problem, each with advantages and disadvantages, and understanding those differences is probably a valuable skill.
Hello. Just wanted to respond to some of your comments on Madison.
Question on reliability: she picks the bridge up after a crossing with about a 90% success rate. The video was shot first-take. Of course, I then tried again for a backup vid and she promptly fell through the gap. Needless to say, I wasn't going to put that one on YouTube!
I found the 'pivot turn' was much more accurate than the spin, especially at slow speed. Getting those turns right was the most time-consuming part of the whole project.
Excellent. Thank you for the update and details. Do you have any plans for what to do next with this? Perhaps more sensors so it can more actively align with the gaps?
Yes, how about 2 ultrasonic sensors farther out (one on each side), so you should have minimal accuracy loss when both dropping the bridge and picking it up!
Currently concentrating efforts on the nxtlog quad-walker challenge. Trying to do a simple walker with an interesting step-by-step nxtlog - the sort of thing my son could use to build the robot.
Will build a Madison 2 at some point in future. Priorities for me on that would be gearing it properly to be able to lift a longer bridge, and sorting out the pick-up accuracy so it's not just about dead-reckoned turns.
Like the twin US sensor idea, would make for a better laydown and pickup, but won't they interfere with each other?
when is a swing turn more useful than a point turn? And the oppositre when is a point turn more useful than a swing turn?
Anonymous said…
In general I find that the nxt move blocks are quite accurate, and my FLL team used them to perform spin turns and longer arcs that were completely reproducible.
Okay, yes that was sort of a lie. The above is true if and only if you have magic batteries that are always at the same power level. As the batteries drop the arcs get wildly tighter.
So, what's next? The firmware clearly can't handle controlled medium arc turns. I'm looking for alternate approaches. I suspect that the answer will lie in platform designs that totally isolate drive and steering.
Comments
I think what's so striking about that robot is its simplicity. I'm tempted to have my students watch the video and try to recreate it.
David
Perhaps I missed it? Dual light sensors/another method would help, but not solve problems completely. I do see the ultrasonic sensor, but that won't keep the robot going straight along the same line the entire time.
Josh
In general I don't trust dead-reckoning for much, for all the reason you suggest. But clearly it can work reasonably well in certain circumstances, and certainly far better under the NXT than for the RCX (as a lot of FLL teams found out this year... hey FLL, how about movable or randomly-placed challenges to require sensors? hinthint...).
--
Brian Davis
I usually encourage the "point-turn" technique ( 2nd motor rotates in opposite direction.
Has there been any studies as to which technique is more accurate(turn at exactly a 90 or 180 degree angle)?
Do both techniques tend to skid at the same speeds?
David - using a spin (both motors opposite directions) cuts your accuracy in half because you are registering half as many degrees. Why do you recommend this type of turn?
Josh
Is that really true or maybe just for very short vehicle turns?
I like the spin turn because it doesn't cause the vehicle to drift off it's last position. However that may not always be an issue if your only concern is that the vehicle should be accurately turned to its new angle.
As to "which turn is better", again, I suspect it's kind of like programming - it depends on what the problem is and what your solution is. For instance, a pivot turn (my name for "running one wheel while the other is held stationary") does offer twice the angular resolution for a turn... because the radius of the turn is effectively doubled. You could get the same thing by making the axle length twice as large and executing a "spin turn" (one wheel one way, the other opposite). Spin turns have the advantage of keeping the motion of the robot nearly in a "pure rotation" mode, so you don't have to account for the physical displacement of the robot during the turn (as David said). Also, pivot turns can be subject to greater inaccuracy on certain surfaces, because you are depending on the "locked" tire to act as a good pivot... which is not true on carpet, where it may slip, or if you don't consider backlash.
Just my opinion, but the perfect solution usually only exist in a perfectly artificial problem - the real world often accomodates a lot of different approaches to the problem, each with advantages and disadvantages, and understanding those differences is probably a valuable skill.
--
Brian David
Question on reliability: she picks the bridge up after a crossing with about a 90% success rate. The video was shot first-take. Of course, I then tried again for a backup vid and she promptly fell through the gap. Needless to say, I wasn't going to put that one on YouTube!
I found the 'pivot turn' was much more accurate than the spin, especially at slow speed. Getting those turns right was the most time-consuming part of the whole project.
--
Brian Davis
Josh
Will build a Madison 2 at some point in future. Priorities for me on that would be gearing it properly to be able to lift a longer bridge, and sorting out the pick-up accuracy so it's not just about dead-reckoned turns.
Like the twin US sensor idea, would make for a better laydown and pickup, but won't they interfere with each other?
http://mindstorms.lego.com/nxtlog/ProjectDisplay.aspx?id=dc60c8ac-06f5-4b02-aa4c-aae3698eaede
--
Brian Davis
Okay, yes that was sort of a lie. The above is true if and only if you have magic batteries that are always at the same power level. As the batteries drop the arcs get wildly tighter.
So, what's next? The firmware clearly can't handle controlled medium arc turns. I'm looking for alternate approaches. I suspect that the answer will lie in platform designs that totally isolate drive and steering.
Any other approaches?
Rich