Is the DC motor not precise?
lardom
Posts: 1,659
I'm learning to control a gearhead DC motor with a quadrature encoder. I'm also learning the L293. Unlike my experience with a stepper or a servo I'm finding it difficult to make it stop at the position I want it to. I haven't exhausted all my ideas on how to do it but I would like to know if I should expect a certain amount of slop in a gearhead DC motor? Is PID (which I haven't tried yet) a necessary part of controlling these motors? :nerd:
Comments
PID is nice, but not necessary.
Where are you placing your encoder and what kind of encoder are you using? Is it connected to the motor shaft or is is connected to the final output shaft? What is the resolution of the encoder? If possible I like to place the encoder on the motor shaft for the best control. There are lots of variables so if you can give us some more details we should be able to help.
Robert
Robert,
I'm curious: why does placing the encoder on the motor shaft (and not the output shaft) provide better control? I would think that, so long as some sort of software allowance is made for backlash, that you would want to know where the output shaft is located more than the motor shaft.
lardom,
As for slop in the gearhead: unless the gears have some sort of fancy anti-backlash system, you will probably always see some amount of slop. See, for example:
http://en.wikipedia.org/wiki/Backlash_(engineering)
Whether or not such mechanical backlash is a problem for you is, of course, dependent on your application. It should be something you can easily measure and allow for in your software. However, I'm just guessing your problem is probably a control issue, not so much a mechanical one.
-Phil
Phil, I believe you, but I also wonder if gears are always mounted perfectly, and if they are always cut perfectly, plus if there's a lot of load, you might get torsional deformations, so do you always benefit from the greater resolution?
-Phil
Based on my mechanical experience, lots of geartrain backlash only adds uncertainty to what the wheel position really is. Knowing the motor position to one part in a million can't really improve that situation. Even if you reverse the motor position briefly to take up the slack, the whole geartrain oscillates and the final wheel position is still uncertain. I'm a mechanical engineer, and I'm sold on the requirement for a sound, minimum backlash geartrain. In that case, a wheel encoder works perfectly fine, assuming that the disk resolution is sufficient to meet the accuracy needs.
A while back, Jay Kickliter had a thread about building a balancing robot using motors with lots of backlash. I kinda had my doubts then, and at last report he threw in the towel on those . Based on recent experiments with my poor man's balancer, I've gotta say that backlash in that application is the kiss of death. That's all about accurate position control, and given how often the motor reverses direction just to hold position, a geartrain with significant backlash would wear rapidly and make a bad situation worse.
Your thoughts, Professor?
My first NC mill was one I built from a Sherline unit and stepper motors. It had no encoders and lots of backlash, which varied over time with wear on the leadscrew thrust washers. Before each milling job, I obtained backlash readings from each axis, which got plugged into the firmware. At each direction reversal, the backlash got taken up before the stroke that caused the reversal was executed. Yes, it was a PITA, but it worked.
-Phil
I always speak in terms of a moderate-speed robotic system with demands for dynamic course correction and keeping diff-drive wheels synchronized, in which case backlash ain't your best friend!
Price is definitely an important consideration. In the case you are describing you also have to consider the backlash and how much it varies with speed and load. A 400 slot encoder on the front might be better than a 16 slot encoder on the motor if there is 1 degree of backlash.
-Phil
Robert
RobotWorkShop, The motor has a built-in hall effect encoder. I'm using "Quadrature Decoder" by Luke Haywas which is excellent and "SN754410.spin" by Javier R. Movellan which I've tweaked.
Now that I know that these motors are very precise I will continue working at it. I will build an H-bridge because I think I'm getting stuck at the L293D. The motor coasts when I want it to brake at a certain value. My most recent test was to abruptly reverse direction which gets closer but still goes past the limit I specified.
You can get very precise control. Remember a lot of mid range dot matrix printers used to use DC motors with optical encoder feedback. They would produce 100+ characters per second in each direction, where each character was 7+ pixels wide with all of the collumns of characters visually lining up. Some printer vendors today still use DC motors with optical feedback on their carrage rails for image printing. So the control can be achieved.
From looking at the L293 data sheet it has a fast motor stop. I've not used it, but it would be worth a try. Part of the problem may be that you are driving the motor flat out and then trying to stop it. You may want to look at ways of throttling it back (maybe pulsing it (but very quick long duration pulsing) aka PWM). This may give you more control. You may want to do some kind of predictive motor control, ie. drive it slower when you get closer to the target.
One of the things to note with DC motors is an alignment position and crash stop. Normally you'd have an alignment point, on start, it would position itself to this point, some techniques use a switch or optical feedback (ie. photo interupter ( a TX & RX sensor pair) and something to break the beam between the two, other techniques just bang a couple of times against a physical stop and expect it to be at the zero mark. The method you use will depend on the outcome you are trying to achieve, and whether you need to position relative to the alignment point. A crash stop can be useful in case some how you loose your positioning, rather than smashing at the other end of the carriage rail, you again have a sensor that you read (ie. photo interupter/ hall effect sensor / switch) that detects that it's beyond normal operational limits so you can recall it to the callibration point (alignment position).
I absolutely appreciate the help of this forum.
Or switch the NC & NO leads for power-off (failsafe) dynamic braking.
Even with a continuously variable speed control, I usually use pick two motor speeds (fast and slow) that suit my evil purposes. For encoder control of a motor, I run it at fast speed as I count encoder pulses. Switch to the slower speed as my stop approaches, then brake at the right time.
You can leave the speed controller on the low speed while the motor is braked, since the motor is disconnected from it. That way you resume turning the motor on slow speed just by turning the braking relay off.