directly led to that intersection. The units of the segment times were chosen to provide numbers that
can allow the robot to meaningfully differentiate between longer and shorter segments but that never
exceed 255 for any segment in the maze. This second restriction means that the values can be stored
in an array of unsigned chars (i.e. each segment’s time takes up just one byte of memory), which
helps keep memory usage down. The ATmega168 has just 1024 bytes of RAM, so it’s important that
applications like this store data in an efficient way that leaves enough room for the stack, which is also
stored in RAM. A good rule of thumb is to leave 300 – 400 bytes of RAM available for the stack and
data used by the Pololu AVR library (or more if you have some deeply nested functions or functions
with a lot of local variables). Note that the ATmega328 has 2048 bytes of RAM, which gives you a bit
more room for your data.
Once the 3pi has learned the maze, the maze-driving algorigthm is essentially:
1. If the robot is going straight at the next intersection, drive the current segment at high speed;
don’t even worry about slowing down until we know we have an intersection coming up that
will require a turn.
2. Otherwise, drive the current segment at high speed until time
T
has elapsed, at which point
slow back down to normal speed until the next intersection is reached.
The value
T
is computed from a function that uses the previously measured segment “length”. For
short segments,
T
is negative and the 3pi just drives the entire segment at normal speed. For longer
segments,
T
is positive and causes the 3pi to drive most of the segment at high speed before slowing
down just in time to handle the intersection safely. We came up with a function for
T
on paper and then
ran a series of tests to get the various constants right.
Typically, one might use encoders to measure the lengths of the segments. We were able to just use
timing on the 3pi, however, because of the 3pi’s power system, which uses a regulated voltage for the
motors and produces highly repeatable results. With a more traditional power system, motor speed
would decrease as the batteries discharge, and a timing approach like this would potentially produce
unreliable results. For example, if you were to use a robot with a more traditional power system, the
function you come up with for
T
when the batteries are freshly charged might work poorly when they
are nearly drained.
Tip:
Once you start significantly increasing your maze-solving speed, performance becomes
dependent on the traction of the tires. Unfortunately, traction decreases over time as the tires pick up
dust and dirt from the course. Our fast maze solver needs to have its tires cleaned every few runs or
else it starts fishtailing on the turns, which slows it down and can even cause it to mess up. You can
see the effects of this on the second (solution) run of the video (the tires hadn’t been cleaned recently).
You can easily clean the tires by wiping them with a little rubbing alcohol on a paper towel.
Pololu 3pi Robot User’s Guide
© 2001–2019 Pololu Corporation
8. Example Project #2: Maze Solving
Page 53 of 85
Содержание 0J5840
Страница 24: ...Pololu 3pi Robot User s Guide 2001 2019 Pololu Corporation 5 How Your 3pi Works Page 24 of 85...
Страница 67: ...Source code Pololu 3pi Robot User s Guide 2001 2019 Pololu Corporation 10 Expansion Information Page 67 of 85...
Страница 77: ...Source code Pololu 3pi Robot User s Guide 2001 2019 Pololu Corporation 10 Expansion Information Page 77 of 85...