So I have ordered a 3pi, and am waiting for it in the mail, in the meantime I thought I’d look at the example source for the maze solving… this code is (like mentioned) fairly simple and readable, and definitely well documented. I am curious, how well does it function? Does anyone have any videos of their 3pi solving a maze using the example code and not user created code?
Hello.
We don’t have any videos of the sample code in action, but I did find this video on youtube:
Though I can’t be sure the user hasn’t modified the code some, it certainly appears to show a 3pi running our sample maze-solving program. This video shows the approximate speed and performance you can expect from the stock program.
- Ben
Awesome. Thanks for the video.
It’s great that it actually seems to function as I imagined it would. Definitely room for tweaking, but still a solid platform to work on. Now I am just going to build my maze, and wait for my 3pi in the mail.
I was thinking, cost-wise of just using 4 sheets of white posterpaper, held together by masking tape, and then make the maze itself with standard electrical tape… Will the masking tape here be a problem because it’s off white, or how sensitive are the IR sensors?
none related question
When the 3pi starts up, it appears like it has a welcome message, where is that defined? and how hard is that to modify, say perhaps if I wanted to name my bot :).
There is a big difference between the off-white of masking tape and the black of electrical tape, so I don’t expect the 3pi will get confused. The sensors can be used to pick up subtle differences in reflectance, but our sample programs make decisions based on seeing very dark regions. For example, I stumbled on this youtube video recently that shows a 3pi running on a line course taped onto a tile floor:
For the most part, the 3pi isn’t fazed by the black grout between the tiles (at least not until the very end!). You could always put the masking tape on the underside of your posterboard, or you could use small strips in places where the 3pi won’t be crossing it.
One fun way to make a maze is to make separate ones on each piece of poster board; you can then easily change the overall maze by altering how the separate poster board pieces are connected. By using small pieces of masking tape to join the boards together, it becomes easier to rearrange them later.
It’s easy to change the message that the 3pi displays at startup. For example, if you look at the sample line-following code, you can see the following code:
...
// Introductory messages. The "PROGMEM" identifier causes the data to
// go into program space.
const char welcome_line1[] PROGMEM = " Pololu";
const char welcome_line2[] PROGMEM = "3\xf7 Robot";
const char demo_name_line1[] PROGMEM = "Line";
const char demo_name_line2[] PROGMEM = "follower";
// A couple of simple tunes, stored in program space.
const char welcome[] PROGMEM = ">g32>>c32";
...
// Initializes the 3pi, displays a welcome message, calibrates, and
// plays the initial music.
void initialize()
{
...
// Play welcome music and display a message
print_from_program_space(welcome_line1);
lcd_goto_xy(0,1);
print_from_program_space(welcome_line2);
play_from_program_space(welcome);
delay_ms(1000);
clear();
print_from_program_space(demo_name_line1);
lcd_goto_xy(0,1);
print_from_program_space(demo_name_line2);
delay_ms(1000);
...
}The easiest way for you to change the start-up message is to change the welcome/demo strings that are defined at the top of the program. Remember that these strings should be no more than eight characters long since the LCD is only an 8x2 display. It’s very easy to print whatever you want to the LCD using the Pololu AVR library, and there are several sample programs that show how to use the LCD control functions. Please see the LCD section of the library’s user’s guide (and the LCD section of the library’s command reference) for more information.
- Ben
Thanks again for the quick reply. I can’t wait till my 3pi arrives in the mail. I am super pumped.
I made a maze out of two posterboard sheets, but only realized afterwords that some of the lines
may be too close together…
but I’ll have to test it and see, I made the maze on a 2" grid surface.
Does the robot go completely off the maze in the dark? or how does that function. I saw the pictures of the bot in the dark, with the trailing LED’s which looked pretty cool, I just thought it would need a certain amount of light to function.
The sensors are IR reflectance sensors; each one consists of an IR-emitting LED paired with an IR-sensitive phototransistor. The two modules are mounted side-by-side in the same package, and the phototransistor measures how much light from the LED is being reflected back to it. Since the sensors produce their own light, the robot can work just fine in the dark. In fact, the less ambient IR light there is, the better the sensors will work. Generally, the 3pi’s initial calibration to the course will negate the detrimental effects of ambient IR on the sensors, but if the ambient IR is not uniform over the course it could still cause problems. For example, my maze solver experience problems when it drove over a section of maze that was lit directly from the sun shining through a window.
The sample maze-solving code has been tested on a maze made on a 3" grid. I’m not sure how well it will work on a 2" grid, but I’m curious to find out. Please let us know how it goes!
Also, remember to use freshly charged batteries (or new alkalines) when you program your 3pi!
- Ben
Yeah, I purchased some energizer 850 mAh batteries and a charger, now I just have to wait for it to arrive.
When you program the 3pi does it rewrite what’s already on there, or is it possible, if both programs are small enough, to have two seperate programs loaded into the memory at once?
Hello,
Except in some special applications (bootloaders), you always erase everything when programming the 3pi. If you want to have multiple functions (e.g. maze solving and line following) in the same robot, you can make both functions accessible with a custom menu system that uses the buttons and LCD. You wouldn’t want to have the programs be totally independent of each other anyway, because you can save a lot of precious memory by reusing common subroutines.
-Paul
That’s what I was assuming, a maze solving robot has to follow the line anyway, so much the same functions and methods would be duplicates.
Thanks for your help.
EDIT
There is all this talk about how the robot going dead while programming will permanently damage it… how long does the actual programming take?
Here is a PowerPoint presentation that clearly explains the line maze solving algorithm:
I have also just purchased the 3pi robot, is there an example of the source code for the line-maze-algorithm. Thanks.
Hello djman96,
Have you used any of the example projects in the Pololu AVR Library? You can find out how to download and install the Pololu AVR Library, then look in the libpololu-avr/examples/atmega168/3pi-mazesolver/ directory of the downloaded archive. There is an AVR Studio project and sample code there that turns your 3pi into a maze solver. A detailed discussion of the maze solving code is also available.
- Ryan
So, this has kinda been a deadpost, but since this is an issue I’ve been having lately with the example source I thought it fit.
I have been having issues with in my maze the robot (on the second run) stops just before the finish.
I made a video to show this, hack204.com/donotdisclose/minitaur.mpg
Ignore the music 
Any suggestions as to why this is occuring? It happens everytime, on multiple mazes, and I don’t get why.
I found if I increased the regular drive speeds, it reduces the amount of times it will stop prematurely.
Is your robot just running Pololu’s sample maze-solving code, or have you modified it some?
- Ben
When it stops early like that on the second run? That’s just the sample code.
When I modify it I can speed up the motors, and then it seems to correct the issue, I was just wondering
if there was a noticeable reason my sample code stopped early :). It’s no big deal really, just curiosity.
Hello,
I took a look at the video and the sample code, and I don’t know why your robot didn’t follow the final line. There’s an extra line of code specifically to do that last step in the example source - maybe you can do some debugging with the LCD or LEDs around that point to figure out what is going wrong.
-Paul
It’s got to be something to do with the final line, because I added a second “finish” line, and a ran the track in reverse (starting at what was previously the finish, and going to the previous start) and then it works perfectly everytime.