EmbeddedRelated.com
Forums

motion control / servos / robotics

Started by Steve at fivetrees August 16, 2004
Perhaps the wrong ng, but I know I'm amongst well-informed friends here, so
please forgive me if so.

I need to become an overnight expert in driving (smallish, DC) motors, with
particular emphasis on smoothness and control of the
acceleration/deceleration profile, for a mechatronics/robotics application.
I have a background in PID control, and analogue/power electronics, so I'm
not a total novice - but the sample rates I now need are orders of magnitude
higher than I have experience of. I also need very high resolution, probably
using absolute encoders (e.g. Stegmann/Hiperface et al).

I've tried, and failed, to find one or more killer reference books ("Dummies
Guide to Motion Control" or something ;)). I've googled and found *some*
material, but so far without the detail I need. Could any kind soul point me
at a source of detailed data on the subject?

One particular question - why do certain motor controllers need both an
encoder (for position) and a tacho (for speed) input to the control system?
Or is this only common when the final axis of rotation is > 360 degrees?

TIA,

Steve
http://www.fivetrees.com
http://www.sfdesign.co.uk


You will also get good answers to this question by posting it to
comp.robotics.misc



"Guy Macon" <http://www.guymacon.com> wrote in message
news:10i1mfoohe7m214@news.supernews.com...
> > You will also get good answers to this question by posting it to > comp.robotics.misc
Noted - thanks. Steve http://www.fivetrees.com
Steve at fivetrees wrote:

> <snip> > > One particular question - why do certain motor controllers need both an > encoder (for position) and a tacho (for speed) input to the control system? > Or is this only common when the final axis of rotation is > 360 degrees? >
Most (or all) the controller I know of use only an encoder as feedback. If you are planning to work at low speeds, you might have some problems with speed measurement from an encoder due to the very low sample rate then (remember, an encoder read position, not speed). If you're dealing with robotics, sometimes you can go on without speed measurement at all, since the positiong is what's in your objective. As you mentioned using an high resolution encoder, you should have no problem to take the speed from position measurement also. Ricardo
> TIA, > > Steve > http://www.fivetrees.com > http://www.sfdesign.co.uk > >
"Ricardo" <spamgoeshere1978@yahoo.com> wrote in message
news:2oc774F92nquU1@uni-berlin.de...
> If you're dealing > with robotics, sometimes you can go on without speed measurement at all, > since the positiong is what's in your objective. As you mentioned using > an high resolution encoder, you should have no problem to take the speed > from position measurement also.
Logical - thanks. Steve http://www.fivetrees.com
Hi Steve,

> One particular question - why do certain motor controllers need both an > encoder (for position) and a tacho (for speed) input to the control system?
I don't know the *generic* answer to this, but the *specific* situation where I have needed both is where there is a big gear ratio involved (500:1 in my case). The position encoder in my system went on the output of the geartrain, and the tach was on the motor shaft directly. The tach had to go on the motor shaft because of the annoyance/error in accurate measurement of very slow time intervals. The position encoder was best placed on the final output for a couple of reasons: 1. this drastically reduces interrupt loading on the micro. 2. so it accurately indicates actual position of the final shaft in the geartrain, taking into account "slack" in the gears.
Lewin A.R.W. Edwards wrote in message
<608b6569.0408161115.25b71a19@posting.google.com>...
>Hi Steve, > >> One particular question - why do certain motor controllers need both an >> encoder (for position) and a tacho (for speed) input to the control
system?
> >I don't know the *generic* answer to this, but the *specific* >situation where I have needed both is where there is a big gear ratio >involved (500:1 in my case). The position encoder in my system went on >the output of the geartrain, and the tach was on the motor shaft >directly. > >The tach had to go on the motor shaft because of the annoyance/error >in accurate measurement of very slow time intervals. > >The position encoder was best placed on the final output for a couple >of reasons: > >1. this drastically reduces interrupt loading on the micro. >2. so it accurately indicates actual position of the final shaft in >the geartrain, taking into account "slack" in the gears.
slack or backlash in the geartrain , together with flexing , have the undesirable effect of making the PID motor control loop unstable , *if* the encoder is situated after the geartrain . Placing the encoder on the motor shaft is the cheapo solution, but then it doesn't read (and the loop doesn't compensate for ) the geartrain inaccuracies . In order to stabilize the loop with the encoder after the geartrain, a second loop is closed based on motor velocity . This can be a tacho if the motor turns fast enough , another encoder , or other less orthodox methods like detecting brush spikes or back EMF . There are some variations that are possible, some drivers provide a current mirror output , and together with the PWM value , the actual EMF can be calculated rather than measured . best regards, matt tudor
On Mon, 16 Aug 2004 14:13:41 +0100, "Steve at fivetrees"
<steve@NOSPAMTAfivetrees.com> wrote in comp.arch.embedded:

> Perhaps the wrong ng, but I know I'm amongst well-informed friends here, so > please forgive me if so. > > I need to become an overnight expert in driving (smallish, DC) motors, with > particular emphasis on smoothness and control of the > acceleration/deceleration profile, for a mechatronics/robotics application. > I have a background in PID control, and analogue/power electronics, so I'm > not a total novice - but the sample rates I now need are orders of magnitude > higher than I have experience of. I also need very high resolution, probably > using absolute encoders (e.g. Stegmann/Hiperface et al). > > I've tried, and failed, to find one or more killer reference books ("Dummies > Guide to Motion Control" or something ;)). I've googled and found *some* > material, but so far without the detail I need. Could any kind soul point me > at a source of detailed data on the subject? > > One particular question - why do certain motor controllers need both an > encoder (for position) and a tacho (for speed) input to the control system? > Or is this only common when the final axis of rotation is > 360 degrees? > > TIA, > > Steve > http://www.fivetrees.com > http://www.sfdesign.co.uk
Others have already pointed out the uses of two feedback elements, one on the motor shaft and the other on the payload. It is relatively easy to implement a basic PID loop to perform velocity control on a motor, especially if you add feed forward terms for velocity, acceleration, and friction/stiction. But the best you can do with a loop like this is achieve very stable velocity of the motor, with some characteristic following error. You can add an outer position loop, and if you do it properly you can use the payload encoder. This can not only greatly reduce the following error, it can automatically reduce/eliminate the effects of any backlash in the drive train between the motor and the payload. The input to the position loop is the following error, that is the difference between the point defined by the profile geometry and the actual position of the payload at each iteration of the loop. If it is possible to run the velocity loop much faster than the position loop (5x - 20x), you can use the output of the position loop to feed the velocity loop. If for some reason you are not able to run the position loop more frequently than the velocity loop, I have had better results with using the position loop to generate an adjustment value, which is then added to the profile velocity to feed the velocity loop. Do a Google search for PIV motion control, the acronym is shorthand for a PID velocity loop inside a PI position loop. I don't know of any really decent books on the subject. Some times I think I'd like to write one some day, but I doubt that will ever really happen. Besides, if I did, there's no guarantee that it would be all that good. -- Jack Klein Home: http://JK-Technology.Com FAQs for comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html comp.lang.c++ http://www.parashift.com/c++-faq-lite/ alt.comp.lang.learn.c-c++ http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
There are some well documented examples on Microchip web site.
I have done a DC servo controller taking one of the examples as a starting
point.
Namely this one:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en011782

We have used the servo in tacho-tester with success.
I have got complete controller PCB's ready for power of 20A at 24V.
I am ready to cooperate on the design if you need any help.

The solution is on our web site, however so far we did't translate it to
english.
http://www.elitel.pl/produkty8.php - you can have a loo anyway.



Piotr Stawicki


> I need to become an overnight expert in driving (smallish, DC) motors, with > particular emphasis on smoothness and control of the > acceleration/deceleration profile, for a mechatronics/robotics application.
Besides the microchip datasheets, you could have a look at a Silicon Labs application note. Look for motor control on their website. To get some hands-on experience, the (expensive) national LM628 or excellent and lower cost JR-Kerr (www.jrkerr.com) devices are great. Jrkerr has some great boards, chips, software and examples to drive small motors. It will be hard work to implement a simple motion controller that has as much functionality as his devices.
> I've tried, and failed, to find one or more killer reference books ("Dummies > Guide to Motion Control" or something ;)).
The only good introduction i know of is 'Designing With Motion Handbook' by Chuck Raskin. (Available at amazon). He gives a good introduction on servo loops, tuning , feedback etc. Also some code and examples for the 8052. Stijn