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.
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.