Here is a youtube video of my Pololu 3pi robot solving a line maze.
This was my first attempt at making a maze solver and I wrote the code from scratch the night before our last local robotics competition, so there’s plenty of room for improvment (for example, it would be cool if it could handle mazes with loops or irregular intersections). It would also be cool if it could have similar performance with higher robustness (changing conditions such as harsh shadows or dusty tires can really throw it off at the moment).
It uses PID control to follow the lines and it makes pre-programmed, timing-based turns once it has identified which way it wants to go at a given intersection. Because of this, it’s kind of at the limit of what it can do with current programming; if I push it much further it starts to miss intersections or think the ending circle is an intersection, at which point it turns left and drives around the outside of the circle. As it is now, it’s so finely tuned that it only functions with clean tires. In the video, on the fast run, you can see it start to fishtail on some of the turns just from the dust the tires picked up on the learning run (normally I use some rubbing alcohol to clean the tires before every run, but I figured that would be pretty boring to put in the video).
More information on the 3pi robot can be found in this thread:
I would like to know as the robot is 90 degrees in the turns so well. What I mean is serving as the algorithm to detect the line and turn, at junctions and on roads in 90 degrees.
The 3pi web page is now up, so you can see some more information about its features.
The 3pi is able to very precise turns because of a unique power system where a regulated 9.25 V is provided to the motors. This means that the wheels always spin at the same speed, no matter what the battery voltage is. You can program a turn with something like
where “234” is a number that you calibrate to get the turn as close to 90 as possible. After you calibrate the turn, you will be able to use this function over and over again in many different programs.
Thanks for your answer, another question, as the algorithm detects crossings in T to bend to one side or the same way at junctions in the shape of a cross, I suppose that uses sensors more outside but I would like you to know the actual operation.
The sensors on the outside are definitely important for detecting an intersection and determining its type. We designed 3pi to have five sensors so that the outer ones could be far away from the line that the robot is on - this means that if one of them detects black, there is a branch heading in the direction of that sensor. One tricky thing is the timing required to detect a T or L junction as quickly as possible, before the robot completely passes it and loses the line. Another tricky thing is driving straight while entering a junction with a branch to one side - the usual line following algorithm tends to cause a robot to veer to one side or another, often causing it to turn enough that it completely misses the intersection before detecting it! These issues need to all be addressed simultaneously, and doing it efficiently and quickly can result is some pretty messy code.
Does that answer your question at all? We should have a simple example maze-solving program available soon to give you a starting point, but making it work really well is always going to be a challenge.
What about doing longer-range odometry? I’m guessing this wouldn’t quite fit, but I’m wondering would the larger Pololu Wheel (42x19 mm) fit on the 3pi? And if so, would there be room for one of the wheel encoder reflectance sensors? Probably not with the motor mount, but if so it would be cool. If not I’m sure I could hack on a wheel encoder some other way.
The repeatability of the motors is good enough for long-range navigation to some extent: Ben used this to have his robot take the long straightaways as fast as possible in the video above. We’re confident that it’s going to be good enough to solve mazes with loops. But if you want more accuracy, we don’t have a good encoder solution for 3pi. The design was pretty tight already, and after using up all of the I/O on the mega168, we couldn’t spare four more lines for encoding. Our larger wheels and the extended bracket won’t really work with the 3pi chassis, though there’s nothing stopping you from building some sort of a spacer that would get it to the right height and push the motors away from the centerline a bit.
It might be possible to mount some kind of a detector on top of the motor bracket or maybe in the user prototyping space in front of the wheel. If I were attempting this, I’d glue a little rare-earth magnet inside the wheel and place a hall-effect sensor in the prototyping area, to let me at least count the number of full rotations of the wheel.
Do you have some specific plans for the 3pi that would require odometry?
No plans in particular, I just thought it would be neat to be able to go off-maze for a while, maybe with some auxiliary sensors. Or to build up a map of the reflectivity of an area by driving over it in a pattern first, rather than following features from the start.
