With new tyres and a tweak to the acceleration profilers it is time to grab some data from Decimus again. The tyre seem to give me reliable grip up to 4m/s/s. They will probably manage more but I seem to have other control issues then. In any case, a dusty maze will soon put paid to that. For this trial, the mouse was commanded to move forward 4 squares with no limit on its top speed…

The change to the profiler involves the deceleration phase. At every control cycle, the code checks to see if the deceleration required to bring the mouse to a halt is greater than the current value of acceleration. Previously, the result was simply divided by two as per the equation:

dec_eq

where v is the current speed, u is the terminal speed and s is the remaining distance. However, this always rounds down, or truncates the answer and gives a value that is a bit too small. The result of that can be seen in the previous trials where the mouse has to decelerate much harder in the last few mm of a move to compensate for the gentle braking that had gone before. It is a simple matter to round this fraction to the nearest whole number and get a better result. Now, you will see that deceleration is steady throughout the braking phase.

 performance200800403aperformance200800403b  

With the commanded acceleration higher, some other changes are apparent. The nature of the software means that there must be some delay before the mouse physical movement catches up with the demanded movement. Once underway, there is some overshoot. The second graph shows the error between the commanded position and the actual position as measured from the encoders. Note, this is not the speed difference. This shows a fairly predictable decaying oscillation and that the error reduces as the mouse gathers speed. There will always be some error or there would not be a drive signal to the motors. The system uses a PD controller only. After all, the mouse is not doing any one thing long enough for it to need steady state errors reduced. However, before that error can be made small, it is time to start braking and the mouse over-runs. The sudden reversal of acceleration is a greater change than the initial increase and brings with it correspondingly greater oscillations in the error term. I expect some of the high frequency errors to be due to tyre elasticity. Also, the PD controller has not really had its parameters tuned so there may be considerable scope for improvement there.

In spite of the greater degree of oscillation in the error term, it is clear that the overall error is very nicely approaching zero at the end of the move. Unfortunately, it seems that the driver stops commanding the motor at the end and the mouse runs on a bit. The total error is only about 3mm and this would be adequate so long as it is a constant or known quantity. Much better to get it under control though so I shall have to look at that.

This Post Has 2 Comments

  1. Daniel Alexander

    Could you provide me with a reference to the PWM braking code, please?

  2. Peter Harrison

    Hello

    This is a very old post now and I could not find any of the details any more.

    You can see a complete set of code for a micromouse, including the motor drive, PWM and braking details on my more recent project here:

    https://github.com/ukmars/ukmarsbot-mazerunner

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.