-
Upcoming Events
Tag Archives: motor
Bi level stepper driver
At the 2007 Minos micromouse conference, Martin Barratt gave a talk about his stepper motor driving scheme. For best performance, steppers really need to be driven by a high voltage. However, the current will need to be limited to prevent the motor overheating. Normally this is done with dropper resistors which waste all the energy or with chopper drives that can be relatively complex. Martin has an alternative approach that provides the high voltage needed to produce fast step rates and the low current needed to reduce dissipation and keep the battery size under control.
The essence of the method is quite simple. Stepper motors look like inductors to the driver circuit. The torque available depends upon the current flow through the coils but the rate at which the current can increase is proportional to the applied voltage. If you drive a stepper at low voltage and low frequency, it is perfectly happy. You will get adequate torque as the rise-time of the current will be a small part of the total step time. As you increase the step rate, there is less and less time for the current to rise and the torque suffers greatly. Simply using a higher voltage will result in the coils being over-driven severely. This will require a large battery and will make the motor overheat significantly.
Martin’s solution is to have a two level power supply and a switch. At low speeds, or when the stepper is holding, the coils are supplied from a lower voltage. When a step is made, the switch connects a high voltage to the motors for a short period – long enough to get the current up to a respectable value quickly enough to ensure the motor responds quickly.
You can see the entire presentation with a detailed description of the rationale and the implementation here:
the proof of the pudding is in the eating and Martin’s mouse uses steppers motors and this drive technique to achieve excellent performance with only a modest set of batteries.
Encoder/Motor trouble
This micromouse thing is a bit tricky. I have not been happy with the accuracy of the results I have been getting with Decimus. Occasionally, a move is significantly shorter, or longer than intended. Looking at the code does not help – either the code is fine or I just follow the same thought process leading to the same errors every time I look. There is, however, something odd about the encoders.
If I set a distance (number of encoder counts) for the mouse to run and then measure how far it has moved on the ground, I get a value for the number of encoder counts per cell. This works out at about 4250 making about 23.6 counts per mm. This is fairly consistent and repeatable. There is some change in physical distance travelled when the acceleration is changed. I can explain this away in terms of wheel slippage and compensate accordingly although it is more than a bit of a fudge to do so.
Then I tried getting a value for the number of encoder counts per mm by pushing the mouse along by hand and recording the number of counts from the encoders. I had many goes at this and finally arranged to measure the same distance several times. To try and reduce experimental error, physical stops were used to ensure the mouse always started and stopped in the same place. Backlash in the gearing was eliminated for each trial. To eliminate variations caused by a curved path, the mouse was pushed along a straight edge. Care was taken not to push down too hard so that the tyre were not compressed. The average of ten trials was used for the result.
With all these precautions, I end up with upsetting values. First, there is the result of 23.1 counts per millimeter rather than the 23.6 from having the mouse do the driving. I have no idea why that would be. Second is the awful variability in the results. Each trial is over 706mm. The encoder counts vary over a range of 110 counts out of around 16,000. That is nearly 5mm. It is not nearly good enough.
I guess I shall have to try and see if there are spurious counts caused by the back-EMF of the motors. The results do not seem to be caused by the speed of the motors. I may try putting the counters into x4 decode mode to see if that makes any difference. Also, the index pin is left floating as there is a setting to ignore it. Perhaps better to tie that high or low as well.
While testing, it became apparent one of the motors is faulty. With the mouse set to hold its position, I can turn the left wheel by hand as far as I like. The motor output saturates and when I let go the wheel rapidly returns to its set position. Exactly as it should do. However, if I do that with the right wheel, the current drawn gets nowhere near as high when the motor drive saturates. Further, the encoder on that motor stops generating pulses. If I swap the motor connections around, the problem stays with the same wheel so it is not caused by either the drive circuit or the counter.
All in all, not a happy Easter bunny here. I just ordered a replacement motor. Painfully expensive those things are.
Decimus doing circuits
After a bit of a break, I have done some more work on Decimus, my DC micromouse. With all the peripherals tested and working, I have been concentrating on the motion controller or profiler. This has turned out to be harder than I expected. The basic idea is simple enough but the implementation turns out to be a bit tricky. Probably in part because I wanted it to be useable with Primus, the beginner’s stepper-driven micromouse.
Until I add the code into Primus, I am not going to know how successful I have been but I have a fair degree of confidence. the profiler only communicates with the hardware in two ways. One is to read the encoders to find out how far the mouse has moved since the last timer tick. Primus has no encoders but instead keeps a pair of counters exactly equivalent to the values maintained by the encoder hardware in Decimus.
The other communication is with the motor driver. It is the task of the profiler to generate speed profiles appropriate to a particular movement. Each movement generate two kinds of speed information – forward speed and rotational speed. These speeds are given to the motor controller where they get resolved into appropriate speeds for each wheel. The motor driver in Primus can only set the pulse rate for the steppers so the speeds are used directly. Since the steppers are open-loop it is sufficient to assume that pulses get turned into wheel movement unless we push the controller too far.
For Decimus, the wheel speeds are used to update the setpoint for each wheel. An error term is calculated which is the previous error plus a new component due to the speed term less the distance the wheel has actually moved. This error, for each wheel is used in two PD controllers to determine the power to each motor.
For initial testing, arbitrary values have been used for the P and D constants. These allow the mouse to work but some work now remains to determine the optimum values for these constants.
Although Decimus can steer off the walls and implements forward error correction by looking at wall trailing edges, the sensors have not yet been calibrated or properly aligned so the whole process is still a bit flaky. Still, results so far are quite promising:
Add to Google