Decimus 4 is a four wheel micromouse in the same style as so many others that you see now. Until building it I thought I had a good idea what some of the problems might be. I was partly right…
Having watched many four wheel micromouse runs since Kato-san so impressed everyone in 2009, I was keen to give it a go myself. The two-wheel design is capable of great things but it soon reaches the limits of what might be possible. In particular, straight line acceleration is limited by the height of the centre of mass and the force exerted on the front and rear skids.
With a four wheel mouse, it should be possible to ensure that the centre of mass does not shift outside the contact patches even under heavy braking and acceleration. Of course, none of this is of any use if you do not have enough grip in the tyres but that is another story.
Four wheel micromouse forward profile
After setting up the controller, it was time to see how hard the four wheel micromouse design could accelerate.
This profile shows the mouse accelerating at 9m/s/s up to a top speed of 2m/s. Deceleration is limited to 7m/s/s. The total distance covered was 2m. Tracking is generally good. Although I can manage 11m/s/s, the response starts to get very noisy as the speed gets up to maximum. I expect it would be possible to tune the controller a bit more to eliminate this but I see no real need just now. While 2m/s may not seem a very high top speed, note that the PWM peaks at 900 while correcting at that speed. The maximum possible PWM is 1024 and this run was done with fairly fresh batteries. As the battery voltage drops, the PWM is automatically increased to get a constant voltage drive. There must always be some headroom in the PWM or the controller will saturate. With a top speed of 2.8m/s, the mouse went into a violent spin as it got to near the top speed. No need to go there again.
Deceleration needs to be limited to a lower value than acceleration because the mouse centre of mass is a it closer to the front wheels. I think that, with a deceleration of 9m/s/s, the mouse tips onto its nose.
The error trace is in hundredths of a millimeter and, according to the data log, the error never exceeds about 1.5mm. Even so, there is some lost motion – about 15mm over 2m – as the wheels slip. Keeping the accelerations down to less than 7m/s/s pretty much eliminates all slipping. You will see that the left and right PWM traces differ my a small amount. That is caused by the gyro correcting a problem I will mention a bit later.
Overall, I am fairly happy with the forward controller and profiler.
Four wheel micromouse turn profile
However, that is the easy bit. Two problems are giving trouble. One is the cause of the gyro correction in the data log shown above. I had thought that a four wheel micromouse was intrinsically more likely to go straight than a two wheel micromouse. Now I think that the design may actually be less stable. Experiments show that tiny changes in the orientation of the left and right drive trains will cause the mouse to wander off to one side or another. Simply bringing in the front end of the drive trains by as little as 0.2mm can change the straight line performance for a drift left to a drift right.
This may be cause by poor mechanical design on my mouse. Certainly, I can now think of ways to do it better. Even so, Everyone I have asked so far has also observed that, without the gyro correction, their mouse will not go straight.
The other problem is that I am having a lot of trouble making the turns accurate and repeatable. During any turn, all the wheels of the four wheel micromouse must skid. because of that, there are very large losses and these are slightly unpredictable. Clean tyres on a clean maze make for the highest losses. For a slow turn, the losses are a high proportion of the turning force needed.
It seems impossible to find a good set of values for the feedforward constants that will give me decent open-loop turns. Worse still, my calculations for the rotational controller seem not to produce a useable controller. For the forward controller, I could just do the calculations, plug in the controller constants and get the result you see above. For the rotation controller, things seem much more difficult. I may have to go back and do the PWM-angular velocity calibration again because that is critical to the process. Naturally, the results that you get form that calibration depend upon the available grip.
Once the turns are sorted out, D4 should be nearly ready to go but, so far, that is looking much harder than I had supposed.
yeah, I am having same issue, my max stable speed is only 2m/s and stable accerlation can only go up to 8m/s^2. Once it beyond the limit, system gets noisy. I don’t have too much time to do fine adjust and analysis, wish you good luck and hope you can make your D4 mouse make APEC this year 🙂
Looking forwad to seeing it run at the APEC micromouse contest this year.
Hi Peter,
What kind of calculations do you do for your forward controller? Are these constants for the
controller, or the feedforward component?
Thanks for a very interesting article!
Hi
At the end, where it mentions calculations for the controller, I mean the design of the phase lead controller described here:
https://micromouseonline.com/2011/05/16/designing-a-phase-lead-controller.
I meant to put a link in the post
Hey again Peter,
I wanted to ask, cause I’m having a rather bothersome headache with odometry on my micromouse. Without using the gyro, I’m having moderately good results with two PD controllers, although I have a rather large drift, though the mouse doesn’t go ape crazy.
If I combine the encoder and gyro output as in (gyro+encoder difference)/2 , and then use it for feedback, I’m getting even worse results! The mouse after doing a (still not straight) line, goes crazy and starts rotating, even though the rotation controller has a set point of 0…
I’m really stumped on this one, would you mind helping me via e-mail? I’ve lost 2 days now just to get a massive headache.
Cheers
did you right-left or left -right for encoder rotational error? pay attention on the sign for the gyro angular velocity reading. For instance, I use right-left for encoder and when I combine gyro output as part of rotational error, I use encoder_rotational_error-gyro_output instead of plus since gyro give positive output when rotating to one direction and negative for other direction(I forget which for which). So when I first added gyro output to the overall rotational error, the mouse behaved like yours and made the moving even worse, when I subtract the gyro output instead and the problem fixed.
Seems the gyro and encoder rotational error doesn’t really maintain 1:1 ratio. It’s not like add them up and divide by 2. I use ly3200ALH and I multiplied 1.5 on the gyro output and subtract to the encoder rotational error, you should have yours value measured differently. But the mouse should be able to go pretty straight on a medium constant speed with only encoder. It only gets unstable when on hard acceleration and deceleration as what I observed on my mouse. You should have enough encoder resolution on your mouse since the encoder is AS5040, assume it reads properly. I hope these can help.