A wheelchair configuration micromouse has the wheels in the middle and skids at either end. Those skids cannot both be on the ground at the same time or, when the mouse encounters a step in the maze surface, the drive wheels will be lifted off the ground and the mouse may come to a halt. But, if there is too much clearance, the mouse will be able to rock back and forth quite a lot. It turns out that can have quite a big influence on behaviour…
During development, I collect quite a lot of log files – data from the mouse while it performs simple moves. These allow the tuning and setup of the controllers and can indicate other problems. For some time, I had noticed some features of these plots and it slowly dawned on me what they were. Look at this typical example:
Two trials are show here. One with a weight added to the front of the mouse and one with a weight added to the rear. These ensure that the mouse rests preferentially on the front or rear skid respectively. Speed is measured as the sum of the left and right encoder counts and is shown on the left axis. The right axis shows the controller PWM output for one of the wheels.
The first thing to notice is that the first few milliseconds, in both cases, show some oscillation in the mouse speed. Up until today, I thought that must be slippage or elasticity in the tyres but now I think it is likely to be backlash in the gears. Whatever it is, the balance of the mouse does not have an effect. It should be easy enough to have the motors take up backlash to see if that makes a difference.
Next notice how, with the mouse resting on the front skid, there is a sudden large perturbation after about 50ms of acceleration. This now looks to me like the mouse rocking back onto its rear skid and bouncing. The controller makes a good effort at compensating for the apparent change in speed.The amount of rock available is about 2 degrees. Since each revolution of the wheel is 4096 counts on the encoders, the full excursion of one rock from front to rear will be about 4096/180 = 23 counts. Examination of the record shows that the speed apparently changes from 12 counts/ms to 33 counts/mm and then back down to 10 counts/ms. This is exactly the range of values that you would see if the mouse rocked back onto its rear skid and then bounced back onto the front skid. All in all, not good. A similar effect can just be seen when the mouse begins to decelerate, with the mouse bouncing about once more. The effect lasts longer.
With the weight distributed nearer the back of the mouse (blue records), the acceleration is very tidy after that initial jump in the first couple of milliseconds. However, the decelerating phase is much worse than before. The mouse takes a long time to settle with the controller making heroic efforts to sort things out. From a low speed, the deceleration phase is quite brief and the controller, confused by the large changes in speed tends to make the mouse over-run the set distance. While the recorded distance is correct, the actual distance travelled on the ground is too great. It is not clear that the mouse actually skids but it seems likely. Strangely, with higher top speeds, the overshoot is smaller. This is probably because the mouse has time to settle into a nose-down posture during the longer acceleration.
To test some of these observations, I lowered the mouse by 0.8mm. This was done by the simple expedient of placing a washer under each motor mounting point. Thus, the mouse PCB is closer to the ground by the thickness of one washer – 0.8mm. The clearances are correspondingly smaller. Possibly too small since the maximum step that the mouse can now negotiate is 0.8mm. Most contest rules state that there may be a step of up to 1mm and on one occasion, this has proven a problem with a previous mouse. Still, what effect has reducing the rock had?
I would say that the results are pretty dramatic. The exact same moves were performed with the same weights front and rear. It is clear that there is no appreciable rock during the acceleration phase in either case. During deceleration, the rock is greatly reduced in both cases although it is still greater when the mouse is balanced to the rear. Even so, since the magnitude is much less, the effect is over much more quickly. It is also notable that the mouse now manages the same actual distance travelled in both cases and the total distance travelled is much more accurate.
The mouse should now be more accurate overall as well as being capable of higher accelerations. There is no obvious sign of slippage at 7500mm/s/s. If you look closely, you will see that I probably need to tweak the feedforward constants but otherwise, I am reasonably happy with the improvement. Now I only have to worry about steps