So, I am in a weird position here, and I have been trying troubleshoot this.
I got my 3pi in the mail yesterday, and loaded the example maze solving code on there, to try
it out on a few mazes I had built. I had a 2" grid one, and a 3".
The 2" does not work… it’s too small for the robot, and he will just jump over dead ends to the next
line.
The 3" the robot successfully completes the maze, and finds the finish line, except, he only solves
it part of the time.
I did 10 trials of the 3" maze from start to finish, and 4 times, it found the shortest path, the
remaining 6 times, it would get it’s sequence of turns mixed up, and end up turning off the line and
getting lost.
Has anyone else experianced this? My maze surface is an old plastic hockey table… it’s the closet
thing I could find to a non-porous whiteboard material.
Can you post a picture of your maze? What did you use to make the black lines? Are you making sure to properly calibrate the 3pi before you have it run the maze? Sometimes uneven ambient lighting can interfere with the reflectance sensors. For example, if you have a patch of direct sunlight on a segment of the course and the robot was calibrated on a different segment of the course, it might get confused when it enters the patch of sunlight (sunlight has a relatively large IR component).
I was using 3/4" black electrical tape. I think I isolated the problem.
I modified some code, to offer a kind of troubleshoot mode, and I think the problem was that one of my black lines was not perfectly straight, it kind of had a really slight bend in it. I replaced the one line and now it’s working correctly much more of the time. I also sped it up to 140 speed, and it’s working fairly nicely now… I just have to make it turn faster. As well as make it go through intersections where it’s going straight without slowing down.
I added a little information to section 8.f (improving the maze-solving code) of the 3pi user’s guide on Thursday night, so you might want to take a look at that if you haven’t already. Note that the maze-solving code is heavily dependent on timing, so adding debugging statements that throw off the timing could cause the code to fail if they aren’t compensated for.
