One of the big problems I’m facing with the Zumo bot for dead reckoning is its tracks. They are hard to align well and by their nature, because they have such a large contact area with the ground, there is a lot of inherent “slippage” that results in non-deterministic errors the Navigator cannot account for.
Where this shows up the most is in turning. While the bot can turn to a new heading fairly accurately there is quite a bit of lateral movement, i.e. movement off its center, that is not accounted for by the Navigator.
This diagram shows the problem:
A is the center position of the bot before turning, B is the center position after the turn and C is the new center position calculated by the Navigator.
Ideally A and B should be the same point, i.e. no lateral movement, but even if we had no slippage this is not practical to achieve as it requires the motors to move perfectly in syntonization with each other. The next best thing is to at least have the navigator correctly calculate the new position. To do this we need to minimize non-systematic errors. One way is to not use tracks but rather thin, well aligned wheels where there is much less scope for slippage.
And I happen to have a bot that has wheels and wheel encoders.
The original Wallie Bot:
Wallie Bot should perform better than Zumo. Even though it has 17mm wide tires there is still majorly less surface area with the ground and wheel alignment is much easier to deal with.
So I modified the NavBot code so it can handle multiple robots. [I’ll write more about that shortly.]
The initial runs were very encouraging. From the very first straight line run, without any adjustments, the bot was only 3 or 4 centimeters off center after 2 meters. After a little tweaking it was within 1 and 2 cm each time.
Turning had much less lateral drift which would be expected as most of the slippage error should be gone now. However, the heading precision seemed poor compared to the Zumo Bot. I’ve not debugged this in any detail but I’m pretty sure the problem is with the encoder resolution. The encoders have only 48 ticks per revolution while the Zumo has 1200.
For Wallie we can calculate the minimum heading resolution of the navigator.
Here is the actual code the Navigator uses to calculate heading changes:
nvDistance dr = ((nvDistance)m_rticks)*m_dist_per_tick; nvDistance dl = ((nvDistance)m_lticks)*m_dist_per_tick; // calc and update change in heading nvRadians dh = (dl - dr)/m_base_dist;
So for one “tick” of revolution – the smallest heading change we can detect – one wheel will travel forward by one tick and the other backwards by one tick. The distance per tick is the wheel circumference divided by 48, as there are 48 ticks per revolution, which for a 42.6mm diameter wheel is 2.788 mm. The wheel base is 93.4mm therefore the smallest head change we can detect is:
dh = (dl – dr)/m_base_dist
dh = (2.788 – -2.788)/93.4
dh = 5.576/93.4
dh = 0.0597 radians
dh = 3.42 degrees
This means Wallie is only accurate to +-1.21°.
Still, Wallie did reasonably well in the square test. I’ve put together a sequence of sped up video clips to give an idea of how it performed:
Not great but not terrible either. You can see that a few of the runs have much more error than others. I should also spend some time verifying that the Navigator and Pilot logic are working correctly. The coarseness of Wallie’s encoder resolution is a great stress test for those systems.
The results have also prompted me to attempt to build a better version of Wallie using the higher resolution shaft encoders and thinner wheels. The parts are ordered so hopefully the new bot will be up and running in a week or two. Will be interesting to see what degree of accuracy can be achieve with these simple changes.