Arrival of the new omniwheels
July 1, 2011 | Posted by Guillaume under Building, Ground robots, Programming, Refining the project, Testing |
It’s been one week now we are testing the new Rotacaster omniwheels LEGO compatible^{1} with our omnidirectional robot. Here is a picture with those wheels integrated with the new design.
We ran quite numerous tests with the new omniwheels: we’ll show you in this article the differences with the old ones, fully study the performances of Rotacaster omniwheels and what can be your expectations when you get those ones.
Our LEGO design vs. Rotacaster LEGO compatible design
Without correction | With PI correction |
---|
This test is supposed to give the worst results for one reason: every time the robot is given a new direction command, it’s making a light rotation provided that the two angles are close to each other (<20°). We had the worst results with 90° turns, and this is the reason why on those videos, the robots (old omniwheel vs Rotacaster design) are making a square (about 7 meters perimeter) at the same time so as to observe their behavior. In order to sum up the differences of both robots, making a table seemed to be more convenient.
Custom LEGO omniwheel design | Rotacaster omniwheel design | |||
---|---|---|---|---|
No correction | PI correction | No correction | PI correction | |
Straight lines | Poor | Acceptable | Really nice | Close to perfection |
Measured errors | Strong distance and angular errors | Improved behavior but still not acceptable | Distance OK, angle can be improved | Distance still OK and angle really close to expectations |
Reliability | Nice in order to test an omnidirectional device, but lacks of accuracy, adherence. You cannot get functional and light omniwheel at the same time and this is a huge constraint. | A surprise. Totally unexpected. Even without correction the model is better than ours. With such a project we have, we need accuracy and coupled with a correction, that’s the best deal. |
Rotacaster omniwheel accuracy tests
Results
After observing the tremendous difference that we obtained with our new omniwheels, we wanted to look at the accuracy closer. In order to do that, we coded a function able to make the robot draw a polygon (with a parameterisable number of sides and length for the perimeter) and we run several test with different number of side and compared the results with and without correction. Here is the algorithm:
public void drawPentagone(int iter, int len) { if ( iter < 2 ) return; int angle = 360/iter; for (int i = 0; i < iter; i++) { moveAngLen(angle/2+i*angle, len/iter); } }
After that, we ran the tests (several times for each configuration, taking the average as a result) and measured the distance errors (distance from the finishing to the starting point, supposed to be the same) and angular errors (the robot isn’t supposed to turn on itself, this error is simply the angular difference between the starting and finishing point).
Interpretation / Conclusion
First, as mentioned before, the robot is really accurate as long as the commands doesn’t change much the directions given to the robot: this is why we have really interesting results for n=2. We can see that we have a peak for n=4 as we explained before but it is interesting to look at the behavior of the curbs starting at n=9.
Without any correction, the results are totally unreliable within the time: the system is reliable for few movements but the more turns there are, the bigger the errors get (the last test we did was with a 360-sided polygon, it was almost supposed to be a circle but we weren’t close enough to call that a circle).
Nonetheless, with a simple PI correction (that might be better tuned along the project, even upgraded to a PID) the errors tend to be constant and more than acceptable: with the 360 sided polygon, we had 20 centimeters of “distance error” (over 7 meters and 359 turns) and less than 10° of “angular error”.
We are obviously aware that we can not reach a perfect regulation simply because the robot is only regulating itself with its self parameters (tacho count of the motors) and nothing else. Indeed it would be better if we had another sensors (as the compass that we tried before) that could be 100% reliable but our previous tests showed us that it wasn’t possible (with the LEGO technologies, at least). So for the time being, the results we came out with are more than enough for our project and we know that we can make it even more accurate if we spend some more time on the PID.
We hope this article demonstrated you the use of the PID and that self made design are indeed enriching and give fuel for thought for the community but don’t ever play cheap and know how to allocate wisely your resources for the faith of your project. In that case, if you need to build omnidirectional devices, Rotacaster is a sure investment.
References