Hello,
Just curious, but when you guys were adjusting the overall speed of the 3pi by increasing max speed and tuning the PID and the motor settings, did the robot have a problem simplifying the path(maze-solver)? I’ve got the robot up to about 160/255 and all along the way i tuned the PID constants and adjusted the motor settings accordingly. When I put the robot on the maze I constructed it follows the learning segment without too much shaking, but about 2/5 times it doesn’t remember the quickest route. Is this some issue with the path length array or is it just unreliable because of the speed that it’s at? Thanks in advance.
btw, i ran the code at 60/255 previously and it follows my maze perfectly in both the learning and simplified versions of the maze solver code.
If you’re talking about the maze-solving example program we provide, we haven’t really tried to speed that one up. The fast maze-solving 3pi video we have shows a 3pi running a different program.
In general, making a maze-solver run faster is a complicated task. Besides just losing the line or failing to make your turns, there are also timing-dependent things going on (like trying to correctly identify intersection types with your line sensors) that get thrown off as your overall speed increases. I think the only way to really get to the bottom of your problems is with lots of feedback from your robot to find out where it is going wrong. Perhaps have it print statements to the LCD about what it thought the past few intersections were, or have it make different beeps based on what it’s seeing. The best solution is to have it wirelessly stream data to your computer so that you can monitor its state as it runs, but you can also have it store a map of the maze and dump it to your PC serially for analysis later.
By the way, there isn’t necessarily too much of an advantage to making the maze-solving run all that fast. It’s going to take a while no matter what since you have to explore the maze, so my suggestion is to keep that part slow and reliable and instead go for speed on subsequent solution runs, where you already know the best path and don’t even need to bother characterizing intersections beyond detecting that you’ve hit one.
