This micromouse thing is a bit tricky. I have not been happy with the accuracy of the results I have been getting with Decimus. Occasionally, a move is significantly shorter, or longer than intended. Looking at the code does not help – either the code is fine or I just follow the same thought process leading to the same errors every time I look. There is, however, something odd about the encoders.
If I set a distance (number of encoder counts) for the mouse to run and then measure how far it has moved on the ground, I get a value for the number of encoder counts per cell. This works out at about 4250 making about 23.6 counts per mm. This is fairly consistent and repeatable. There is some change in physical distance travelled when the acceleration is changed. I can explain this away in terms of wheel slippage and compensate accordingly although it is more than a bit of a fudge to do so.
Then I tried getting a value for the number of encoder counts per mm by pushing the mouse along by hand and recording the number of counts from the encoders. I had many goes at this and finally arranged to measure the same distance several times. To try and reduce experimental error, physical stops were used to ensure the mouse always started and stopped in the same place. Backlash in the gearing was eliminated for each trial. To eliminate variations caused by a curved path, the mouse was pushed along a straight edge. Care was taken not to push down too hard so that the tyre were not compressed. The average of ten trials was used for the result.
With all these precautions, I end up with upsetting values. First, there is the result of 23.1 counts per millimeter rather than the 23.6 from having the mouse do the driving. I have no idea why that would be. Second is the awful variability in the results. Each trial is over 706mm. The encoder counts vary over a range of 110 counts out of around 16,000. That is nearly 5mm. It is not nearly good enough.
I guess I shall have to try and see if there are spurious counts caused by the back-EMF of the motors. The results do not seem to be caused by the speed of the motors. I may try putting the counters into x4 decode mode to see if that makes any difference. Also, the index pin is left floating as there is a setting to ignore it. Perhaps better to tie that high or low as well.
While testing, it became apparent one of the motors is faulty. With the mouse set to hold its position, I can turn the left wheel by hand as far as I like. The motor output saturates and when I let go the wheel rapidly returns to its set position. Exactly as it should do. However, if I do that with the right wheel, the current drawn gets nowhere near as high when the motor drive saturates. Further, the encoder on that motor stops generating pulses. If I swap the motor connections around, the problem stays with the same wheel so it is not caused by either the drive circuit or the counter.
All in all, not a happy Easter bunny here. I just ordered a replacement motor. Painfully expensive those things are.