Preparation of Decimus2B for the UK micromouse contest in four weeks or so proceeds apace. The mouse is faster than it has ever been, it is more accurate than it has ever been and it turns better than it ever has before. Does it work well? Of course not.
During the Minos contest, I had Decimus set up to do the outer circuit run but just could not get it to perform as fast as it should. The mouse has a design top speed of better than 3.5m/s and can do about 8m/s/s before there is a risk of lost traction. Nonetheless, the long straight could only be managed at lower values. There is no room normally at home to do long straight tests so this weekend, I got hold of a 2.5m long piece of board and set the mouse off doing long, fast straights to see what happened. Apart from the fact that it looks like I will have to recalibrate the encoder distance values a little (only about 1%), things did not look good at the high performance settings.
Just to be clear, for the mouse to even reach 3.5m/s from a standstill, down the full length of the maze, it would have to accelerate at more than 4.5m/s/s. I only had about 2m of safe distance to play with so I set the mouse to do 2m with an acceleration of 5m/s/s. That should bring it to a top speed of 3.16m/s at the half way point. During the run, I recorded the profiler set speed and the encoder count.
Well, that didn’t go to plan then. Clearly, there is a problem with the controller or profiler. Probably, this is a simple overflow issue in the controller since the profiler speed is correct but the motors try to slow down dramatically as the measured speed starts to hit 128 counts per ms. It should not be too difficult to track down. Of course, it would be better if it was not there at all.
See how the controller tries heroically to cope with the problem as the bug messes up all the inputs. Interestingly, on this surface, the mouse mostly manages to finish in the right place. Everything is carefully prepared to give optimum conditions though.
UPDATE:
That didn’t take long. The feedforward calculation had an overflow in it which caused the feedforward value to drop to a negative value as the speed reached 128 counts per millisecond. Not good. After a quick fixup, the mouse can now do 8m/s/s quite well.
There is still a bit of work to do on the change in feedforward values as the speed peaks but that is relatively minor. In case you are interested, the fault lies with the fact that the feedforward values are calculated from the profile speed rather than the actual speed of the motors. I think.
where are you using feedforward compesation (I’m assuming it’s to compesate the high friction)? On the outer pi/pd/pid loop of the motor controller or are you using a state-space controller? Can you share any more info on that?
Feedforward is used to make the controller’s life easier. Set up correctly, the mouse can make a fair success of a move even without the controller turned on. That leaves the controller just having to deal with errors.
The controller is a phase lead design. I don’t understand the state-space stuff unfortunately.
The profiler determines a new set point for the motors and the controller sets an output PWM based entirely on the difference between the new setpoint and the actual position.
That output PWM has a value added to it that is made of three components. one is proportional to motor speed, one proportional to motor acceleration and an additional value to overcome stiction/friction effects.
The sum of all these is given to the motor to control its speed. The effect is to keep position errors in the drive train significantly smaller than they would be otherwise.
After the UK contest I may write this up properly since it seems not to be widely used.