Decimus performance graphs

Time to do some tuning of the motion control parameters in Decimus. First I wanted to get some idea of how it is behaving with the initial settings. I have added a simple flight recorder function. A 4 kB buffer can hold up to 2000 integers. These are placed in the buffer on every timer tick. Thus I can record one second of two integers. this isn’t much but it is all I have available on the processor. Any future mouse will have to have a bigger data buffer.

For now, I am recording the profiler’s set speed and the average of the two wheel encoders. Set Speed is stored as a fixed-point 8.8 number so I get nice smooth results from this. However, since the encoders can only record whole counts, the numbers are discrete and even after averaging are correct only to the nearest half a count.

The first test was to place the mouse on its little stand with the wheels in the air. The profiler was told to run forward 2 cells (260mm) using a forward acceleration of 3m/s/s and a maximum speed of 0.5m/s/s. kP is set to 1 and kD is set to 2. These are the results:

You can see that the wheels track the set speed quite well. There is a bit of a lag which is to be expected as there will need to be an error for the controller to demand movement from the wheels. The other thing is the deceleration profile. Ideally, this would be a straight line but once again, the mouse lags and that error generates the drive to the motors. However, as the mouse gets to the end of its run, the controller has to generate increased accelerations to try and get the mouse to stop in the right place. This should be fixable somehow but I am unsure exactly how. Some feedforward would help in many ways and might assist here. Possibly the profiler needs to round off the deceleration value a bit better. I am not sure that is so good as I have noticed that the profiler can apply sufficient braking to bring the wheels to a halt before the mouse has reached its final position. This is not good as it gets stuck there. I may have to add another terminating condition to do with the finishing speed.

Next, the mouse is placed on the maze floor and the same run is repeated:

Now the inertia of the mouse is apparent. In the first test, the mouse only has to accelerate the wheels which are small and light. the mouse is much bigger and has correspondingly greater inertia. You can see a much bigger lag during the initial phase of acceleration. the controller soon catches up however and after about 100ms (1mm on the ground) acceleration is back on target. When the target speed is reached, there is some overshoot that lasts about 300ms. Once again, the deceleration phase shows the greatest amount of lag and error as the profiler tries to bring the mouse to a halt in the exact spot.

Integrating these results shows the profile as a series of set positions and the actual mouse position by comparison:

Because of the scaling on the graph, these look like quite a good match. However when you look at the differences, it is clear that the final position as determined by the velocities and the actual counts from the encoders differ by about 150 counts. This is about 5mm on the ground and would represent a serious error over this distance.

the distance measured by the encoders is as close as we can get to the actual distance travelled by the mouse. Slippage will always generate some errors. The actual count recorded at the end of the move was 8600 counts. the distance calculated from initial calibration shows this should have been 8552. Thus the actual error appears to be about 48 counts or about 2mm. So long as this is not a cumulative figure, a 2mm error is quite acceptable at present. For all I know it may never get any better than that for anyone.