motion control / servos / robotics

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