-
Upcoming Events
-
Feb6Mon
-
Apr14Sat
-
Tag Archives: acceleration
Decimus speed feed forward
As set up for the last post, my micromouse Decimus is performing reasonably well on the ground. So far. The data plots show some features that are a little bit curious. However, my concerns over the apparent error in the endpoint were a little misleading. The recorded error is derived from the integral of the set speed and the total count from the wheel encoders. Thus, it does not represent an actual error on the ground…
This may not make much sense but the distances according to the set speed are representative of what the profiler thinks should be happening. That is to say, the profiler takes the desired speed and acceleration and uses them to derive a set speed for the mouse. This is used to tell the motor controller where the wheels should be. It is a relative term. Actual distance on the ground is measured from the encoders. And, so far, the mouse position on the ground is correct to less than the error shown on the graph. Effectively, the error plots just say how hard the controller wants to drive the motors. As with any control system, without an error there will be no restorative force.
One of the features that is interesting is the oscillation after turn-around when we switch from accelerating to decelerating in a couple of milliseconds. This is a big change. Possibly the biggest and may well represent the hardest work the controller has to do. Another feature is that the position error seems to reduce as the mouse gets faster. Now this may be due to the controller being under damped or it may be due to an incorrect value for the speed related feed forward term.
When a motor is turning, it generates a voltage that opposes any more current flowing in to it. This is the reason that a motor runs at a given speed for any particular applied voltage. Consequently, when the motor is running quickly, we need to take into account that back emf by applying an even higher voltage to the motor if we want to change its speed. Decimus does this. A value for the PWM is calculated according to the error terms and then an additional value is added that is proportional to the motor speed. In the last trial, I was using the actual motor speed as measured by the encoder counts. This is a bit crude and there is an implicit error of +/- half a count even at best. A simple change is to use the set speed which is maintained to a higher precision.
It is clear that this has reduced the oscillation somewhat. It has had the effect of filtering the applied feed forward term. After seeking some expert advice, it was suggested that the value of the speed feed forward term might be a bit high. As it stands, the term is calculated from the published motor specification. I need to determine a value experimentally that is better suited to the actual motors I have. Out of interest though, I ran the same trials with significantly larger and smaller values of the back emf constant.
First, the constant was lowered from 3840 to 2840. As this is a signed 8.8 fixed point number, this is a reduction from 15 to 11. A very big change but I wanted to see how much effect the term had.
Wow! Now the response is just rubbish. Well, not quite but it is pretty poor. The finishing position of the mouse on the ground overshoots by 15mm or so even though we get the same apparent error from the data. The reason for this is probably the huge deceleration at about 600ms. At that point, the tyres will almost certainly slip and the mouse will slide on effectively out of control. This is a valuable lesson. I had seen a tendency for the mouse to overshoot when the acceleration was turned up and now I understand why. It was not the high acceleration as such but at that time, I had no feed forward control term. This will drive the controller to extremes in an attempt to eliminate the errors. The resultant skid is invisible to the observer. You can barely see what it is doing anyway. Even filming them doesn’t help much. For these trials, the entire sequence would be over in about 20 frames with a PAL camera (25 frames for the NTSC world). The high speed performance is the thing to notice. As the mouse gets fast, the controller is unable to generate a high enough voltage to keep accelerating the mouse.
So, the obvious question now is – what happens if we use too much feed forward. For the next trial, the constant was increased from 3840 to 4840:
Once again, the initial and final phases of movement are pretty well unchanged but there are differences at high speed. Most obviously, the decelerating phase is much more noisy than before although the position error is not degraded too severely. I think. I really don’t understand where this noisy response comes from. Bear in mind, the controller gains have never been properly set so until that is done everything is a bit of a guess. The frustrating thing is that the acceleration portion behaves pretty well exactly how I would predict. The other feature is that the speed of the mouse (on average) more closely follows the set speed at the point of change over.
More testing …
After a good number of trials, I have found a value for the back emf feed forward constant that seems to improve matters considerably. It is still a bit too big but that is safer than having it too small. Tests in tiny maze sections don’t tell you what will happen at speed. In particular, the speed compensation may work just fine at the relatively low speeds found in the maze but you don’t want it to all go pear shaped when you hit a long straight. Since I only have a 5×5 maze, I was forced to clean a bit of the kitchen floor and test it in there. The surface is different to a maze but it is hard and smooth. I think that if I can get 4m/s/s in the kitchen, a reasonable maze should be fine. Decimus has a designed-in top speed of 2.8m/s. This is an arbitrary figure that is based on all the losses I think are in the system and assumes a battery voltage of at least 6.5V as a worst-case. If I chose 7.2V for the battery voltage, I should be able to do 3m/s. At this stage, better safe than sorry. It takes 0.7 seconds to reach 2.8m/s by which time the mouse has travelled 5.4 squares so I set the run for a total of 12 squares. I only have room for 1000 data samples so the plots are truncated.
Even a change in speed compensation of 0.1 changes the behaviour from stable to unstable so I am not going to tune this any further for the time being until I can get in a real maze. The problem now is that so many of these constants inter-relate and I don’t have a good enough mathematical model to let me predict exactly how. Even if I did, there would still be a need for much empirical testing.
A final point occurs. During the initial phase, the mouse is trying to catch up with the controller and is eventually forced to accelerate harder than the design value in order to do so. This is a potential source of trouble should the mouse lose grip at that point. The same will happen at the changeover points. Either proper tuning of the controller will help reduce this or it may become necessary to introduce a smoother change in acceleration at those points.
Decimus data – 2
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:
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.
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.
Posted in Micromouse
Tagged acceleration, braking, deceleration, graph, motor control
Leave a comment
Tyres and traction
It is true, I am losing my grip. A while ago I posted a link to a Japanese site demonstrating the grip available from a particular micromouse. A common way of doing this is to lock the wheels and place the mouse on a tilting surface. As the slope of the surface is increased, the downforce available to the tyres is progressively reduced until the mouse slips. Part of the downforce is lost due to the angle alone and is proportional to the tangent of the slope.
Thus, at 45 degrees, the coefficient of friction needed to prevent slip is 1. There is another factor at play though. As the lope increases, more of the weight of the mouse is transferred to the skid on the downward side of the mouse. This reflects what happens when the mouse is under braking or acceleration. Reaction torque transfers some force to the skid. A long mouse with a low centre of mass fares better here.
With Decimus I have been having trouble when the acceleration gets much above 3m/s/s. This is disappointing as I was aiming for at least 4m/s/s. The tyres are the most obvious reason for problems at high accelerations so I built a little test rig to see how much grip was available:
I am using Mini-z tyres. They are a bit hard to find in the UK and come in a bewildering variety of materials and patterns. these are 8mm wide slick intended for the front wheels of mini-z 1/18th scale electric racers. I have a few of these and they all appear pretty similar so the rig is intended to find the best set I have. A pair of mini-z wheels are bolted to a small meccano frame so that they cannot turn. batteries add some weight and a harness allows me to attach a spring balance. The whole assembly weights 100g and has the weight almost exactly over the wheels.
The spring balance lets me measure the force needed to start the wheels slipping. Before the test, a section of maze is cleaned and the tyres are cleaned of any dust and dirt. Several trials are needed to even out any variations.
It turns out that my very best tyres begin to slip at about 43g. My worst tyres, which do not feel much different to the good ones start to slip at about 16g! If I take into account weight transfer when the mouse is running and the possibility of dust on the maze floor, it seem I am best limiting my acceleration to 3m/s/s until I can get some better tyres.
I just ordered some replacements. These are a set of GPM slicks said to be 8 shore hardness and a set of Shimizu slicks at 15 shore hardness. I chose the GPM because they were the softest I could find and the Shimizu because several folk in micro racing forums rated them as particularly good.
Derek Hall, owner of MouseX, is fond of balloon rubber over the outside of his tyres. I tried that over the top of my ‘good’ set and found no significant difference.
Formula1 Rat Race – How fast is that?
The schools competition includes a head-to-head drag race called Formula 1. If you want to know how fast you have to be, read this.The Formula 1 Rat Race track is straight and 7.2m long. At the start end is an area 375mm long where the rat starts from. At the end is a 1.2m long area for the mouse to come to a rest. It must not overshoot this area of penalties will be incurred that will almost certainly eliminate the rat from the competition.For best performance, a rat will probably want to accelerate from the start line as hard as it can and then brake as hard as it can to bring it to a rest just short of the end of the braking area. This means a run of total length about 6.8m with the rat crossing the line as fast as it can while still allowing space to come to a halt.We can plot the mouse speed against time:
At time T1 the mouse will be half way along its path having travelled 3.4m. The time taken to get there (T1) can be calculated from the standard equations of motion as:
T1 = sqrt(2*3.4/a)
where a is the acceleration of the rat. By inspection, it can be seen that T3 is twice T1.T2 is the time that the rat crosses the finishing line. Since we know the distance between the finishing line and the end of the braking area (1.2m), we can use the same equations to determine the time interval T3-T2 which is:
T3-T2 = sqrt(2*1.2/a)
Which is easily rearranged to give:
T2 = T3 – sqrt(2.4/a)
Substituting 2*T1 for T3 in this equation gives us:
T2 = 2*sqrt(6.8/a) – sqrt(2.4/a)
Simplifying:
T2 = 3.67/sqrt(a)
Now we can make a table to see how long the race will take for different values of acceleration, a:
| Acceleration (m/s/s) |
time (s) |
| 1 | 3.66 |
| 2 | 2.59 |
| 3 | 2.11 |
| 4 | 1.83 |
| 5 | 1.63 |
| 6 | 1.49 |
| 7 | 1.38 |
I believe the current record holder from the 2007 competition managed to run in 2.58 seconds indicating the equivalent of continuous acceleration/deceleration of about 2m/s/s.A good micromouse can easily manage accelerations of better than 3m/s/s. Things start to get tricky at more than 5m/s/s.Thus, I think we should be expecting times for this competition to fall below 2 seconds and, for the ambitious, a target time of 1.5 seconds would be appropriate.So, give it a go.But hurry. Continue reading
Add to Google