# 3pi Line Maze Solver

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).

- Ben

Very cool!

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.

Greetings
Excuse my English, I am Chilean.

Hello vandarren, welcome to the Pololu forum!

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

``````void turn_left_90()
{
set_motors(0,255);
delay_ms(234);
set_motors(0,0);
}
``````

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.