Searching \ for '[PIC] Servo control questions' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ios.htm?key=servo
Search entire site for: 'Servo control questions'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Servo control questions'
2008\07\15@113652 by threewheeler7

picon face

Hello i am working on a project that will control up to 6 analog R/C servos,
2-3 at the same time, i have a couple questions on how i would implement
this on a PIC. first, as you may know rc servos are used with PWM, to
control them, i need to know what is a good way to go about controlling more
than 1 PWM output and still running the rest of the code. i was thinking,
keeping the off time the same for all the motors, and have a timer overflow
interrupt, update each motors position(on time), not sure completely if this
is feasible. also speed control is an issue, i would like to have
positioning time slowed down a bit. i have read that increasing the off time
of the PWM will slow the servo's operation. i was thinking of slowly
bringing up or down  PWM in software. thats all i can think of right now, if
anyone has any suggestions, keep me posted.
--
View this message in context: www.nabble.com/Servo-control-questions-tp18468263p18468263.html
Sent from the PIC - [PIC] mailing list archive at Nabble.com.

2008\07\15@120625 by Bob Blick

face
flavicon
face
The positive pulse width sets the position. Although the repetition rate
affects the speed/strength, they are real sloppy if you try to use that
as a feature.

Typically you drive multiple servos in sequence, round-robin. After
going though all 6 servos you'd start back at the beginning.

If you use a CCP peripheral in Compare mode you can generate nice
accurate pulses. Then use some external logic to steer it to each servo
in turn, like 74HC238.

Cheerful regards,

Bob



On Tue, 15 Jul 2008 08:36:28 -0700 (PDT), "threewheeler7"
<spam_OUTthreewheeler7TakeThisOuTspamhotmail.com> said:
{Quote hidden}

--
http://www.fastmail.fm - Does exactly what it says on the tin

2008\07\15@122719 by Tamas Rudnai

face picon face
You can use Pulse Position Modulation inside your firmware (search for PPM
on google). With that you can have 1 pin to feed a shift register which
basically converts the PPM to PWM, so each output of that shift register is
a servo channel. You can also write a shift register software module so for
example an entire port is the shift register and you shifting the high
output bit-by-bit (using a shadow register of course).

Tamas


On Tue, Jul 15, 2008 at 4:36 PM, threewheeler7 <.....threewheeler7KILLspamspam@spam@hotmail.com>
wrote:

{Quote hidden}

> -

2008\07\15@130000 by Ariel Rocholl

flavicon
face
Or optionally you can go to a multi-PWM output PIC, such as 18F4331, you can
have your 6 channels being assisted by PWM hardware peripherial and keep
your core doing other tasks.

2008/7/15 Tamas Rudnai <tamas.rudnaispamKILLspamgmail.com>:

{Quote hidden}

2008\07\15@141841 by Bob Ammerman

picon face
The control signal to an RC servo is a verrrrryyyyy slllooooooowwww PWM. In
particular, the period is typically 20ms, and the pulse width is usually
1-2ms for full scale motion of the servo.

This means that you only have to produce the output for one servo at a time
within the 20 millisecond interval.

Thus, you use the first 2 milliseconds to generate the pulse for one servo,
the next 2 ms for the next one...
etc...

I would probably just use an interrupt driven state machine (driven by a
timer interrupt) to produce the pulses, with a separate pin for each servo.
In order to the the CCP hardware support of the PIC, you'd have to add a
demultiplexor so that each pulse was routed to a different servo. That
sounds like a pain in the next to me!

-- Bob Ammreman
RAm Systems

2008\07\15@160421 by olin piclist

face picon face
threewheeler7 wrote:
> Hello i am working on a project that will control up to 6 analog R/C
> servos, 2-3 at the same time, i have a couple questions on how i
> would implement
> this on a PIC. first, as you may know rc servos are used with PWM, to
> control them, i need to know what is a good way to go about
> controlling more
> than 1 PWM output and still running the rest of the code.

If you only need two, then using two CCP modules is probably easiest.
Otherwise I would look into multiplexing the output of a single CCP module
used in one-shot mode and getting to each servo successively.  They'll be
fine as long as you get to each one every 20mS or so, which should allow you
to drive up to 10 from one CCP output with a little external multiplexing
hardware.

> i was thinking,
> keeping the off time the same for all the motors, and have a timer
> overflow
> interrupt, update each motors position(on time),

Doesn't sound like a good idea.  What if two servos need about the same
pulse time, then at least one of them will be off or jitter.

> also speed control is an issue, i would like to have
> positioning time slowed down a bit.

That's easy.  Low pass filter the incoming position requests, or never
change them by more than a fixed value each pulse until the pulse width
finally matches the requested value.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\07\15@181345 by Jan-Erik Soderholm

face picon face
threewheeler7 wrote:
> Hello i am working on a project that will control up to 6 analog R/C servos,
> 2-3 at the same time, i have a couple questions on how i would implement
> this on a PIC. first, as you may know rc servos are used with PWM, to
> control them, i need to know what is a good way to go about controlling more
> than 1 PWM output and still running the rest of the code. i was thinking,
> keeping the off time the same for all the motors, and have a timer overflow
> interrupt, update each motors position(on time), not sure completely if this
> is feasible. also speed control is an issue, i would like to have
> positioning time slowed down a bit. i have read that increasing the off time
> of the PWM will slow the servo's operation. i was thinking of slowly
> bringing up or down  PWM in software. thats all i can think of right now, if
> anyone has any suggestions, keep me posted.

First you can more or less forget about the hardware PWM
module in the PIC's, it is not designed för RC-servo
control at all.

Bob Ammerman has the only reasonable solution.
Time your pulses with whatever timer you have
un-used. Send the "pulse" to each servo in turn.
After the last servo wait a while to make up the
total cycle time of 20 ms.

All timing and "waiting" is of course made by
properly pre-setting some timer and waiting for
the interrupt...

Jan-Erik.

2008\07\15@184252 by olin piclist

face picon face
Jan-Erik Soderholm wrote:
> First you can more or less forget about the hardware PWM
> module in the PIC's, it is not designed för RC-servo
> control at all.

It's not ideal, but it is still better than nothing for this purpose.  You
can use the CCP module in compare mode as a digital one-shot.  The software
does have to set the output high manually right before releasing timer 1,
but after that the hardware takes over to time the pulse.  Since setting the
output pin and enabling timer 1 can be done in successive instructions in
the interrupt routine, the pulse time can be totally predictable and have a
resolution of the instruction clock.

In the OP's case, there would be a regular interrupt in which the software
would switch the mux to the next servo, load timer 1 with the pulse time,
raise the output pin, then enable timer 1.  Hardware automatically ends the
pulse.  This is certainly no worse than the software doing all the timing.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\07\15@184443 by Bob Blick

face
flavicon
face

On Wed, 16 Jul 2008 00:13:24 +0200, "Jan-Erik Soderholm"
<EraseMEjan-erik.soderholmspam_OUTspamTakeThisOuTtelia.com> said:
>
> First you can more or less forget about the hardware PWM
> module in the PIC's, it is not designed för RC-servo
> control at all.

I am on the "less" side of that argument :)

Hardware PWM is only the "P" in the CCP peripheral. I have used the
Compare quite successfully to drive servos with more ease and accuracy
than timer-based interrupts, which will tend to be jittery if you have
more than one source of interrupts.

Compare is great because you set it to flip the pin after a certain
number of clocks. There is a little trick for getting the starting edge
not to glitch(it's in the datasheet but I can supply the code if
anyone's interested) but it works perfectly and you get no jitter.

There are plenty of ways of using one CCP pin to feed multiple servos,
the simplest uses diode logic and plenty of PIC pins. An external logic
chip like the 74HC238 or CD4017 can also be used to steer the CCP pin.

Cheerful regards,

Bob

--
http://www.fastmail.fm - Email service worth paying for. Try it for free

2008\07\15@203726 by Gaston Gagnon

face
flavicon
face
threewheeler7 wrote:
> Hello i am working on a project that will control up to 6 analog R/C servos,
> 2-3 at the same time, i have a couple questions on how i would implement
> this on a PIC. first, as you may know rc servos are used with PWM, to
> control them, i need to know what is a good way to go about controlling more
> than 1 PWM output and still running the rest of the code. i was thinking,
> keeping the off time the same for all the motors, and have a timer overflow
> interrupt, update each motors position(on time), not sure completely if this
> is feasible. also speed control is an issue, i would like to have
> positioning time slowed down a bit. i have read that increasing the off time
> of the PWM will slow the servo's operation. i was thinking of slowly
> bringing up or down  PWM in software. thats all i can think of right now, if
> anyone has any suggestions, keep me posted.
>  
Here is an example of controlling 12 servo and a 38400 bit/sec serial
line at the same time. Even if you do not want to use a pic solely to
control your motors and a different pic to control the rest of your
application the program is worth taking the time to study as the author
make use of a FSM (Finite State Machine) implemented in assembler.

It is based on a PIC16F84 but it can be slightly modified to run on a
different pic.

http://home.planet.nl/~havinga1/servo/servo.htm

Gaston



2008\07\15@213245 by Apptech

face
flavicon
face

----- Original Message -----
From: "Jan-Erik Soderholm" <jan-erik.soderholmspamspam_OUTtelia.com>
To: "Microcontroller discussion list - Public."
<@spam@piclistKILLspamspammit.edu>
Sent: Wednesday, July 16, 2008 10:13 AM
Subject: Re: [PIC] Servo control questions


threewheeler7 wrote:
> Hello i am working on a project that will control up to 6
> analog R/C servos,
> 2-3 at the same time, i have a couple questions on how i
> would implement
> this on a PIC. first, as you may know rc servos are used
> with PWM, to
> control them, i need to know what is a good way to go
> about controlling more
> than 1 PWM output and still running the rest of the code.

The various software PWM solutions have merit.

It is extremely easy to implement multiple PWM channels in
software using a single timer interrupt *IF* the resolution
that you get is acceptable.
eg if you want a 2% resolution and your maximum pulse width
is 2mS (as has been suggested) then an interrupt every
2mS/50 = 40 uS would allow 50 steps within a 2 mS period. If
the control pulse was eg 1 mS to 2 mS for 0%-100% and you
wanted say 100 steps across this 1 mS range then you'd need
an interrupt every 2ms/100/2 = 10 uS. Depending on the clock
speed that level of overhead may or may not be acceptable.

I implement multiple timers by using decrement_if_not_zero
(mnemonic varies with processor) on variables within and IRQ
routine and testing for zero in the background.  This allows
as many timers as desired with relatively small overheads.
The background code tests for variable zero and acts when it
is and reloads the timer to its next desired count. As the
timer is always zero when the background code acts on it
there is no chance of accidental interaction with the IRQ
code.

In your case, as the servos have a short on_pulse_time with
a long cycle time you can use the above method with a single
counter and still interleave
all the servos as otherwhere suggested.


       Russell McMahon

2008\07\15@232353 by Harold Hallikainen

face
flavicon
face
I've wondered what the hardware in these servos really is. It SEEMS that
maybe they run the PWM through a low pass filter to get an analog voltage
that they then compare with a pot on the shaft and drive the motor with
the difference. It SEEMS that the use of PWM is just a way to get analog
voltages. I've never taken one of these servos apart, but one of my
students brought one to class to play with. I found that just driving it
with an analog voltage between the supply rails did NOT make set the motor
position as I had expected. Maybe there's a schmitt trigger before the
LPF?

So, does anyone know what's actually in the servo motors?

Harold

--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2008\07\16@051244 by Gaston Gagnon

face
flavicon
face
Harold Hallikainen wrote:
> I've wondered what the hardware in these servos really is. It SEEMS that
> maybe they run the PWM through a low pass filter to get an analog voltage
> that they then compare with a pot on the shaft and drive the motor with
> the difference. It SEEMS that the use of PWM is just a way to get analog
> voltages. I've never taken one of these servos apart, but one of my
> students brought one to class to play with. I found that just driving it
> with an analog voltage between the supply rails did NOT make set the motor
> position as I had expected. Maybe there's a schmitt trigger before the
> LPF?
>
> So, does anyone know what's actually in the servo motors?
>
> Harold
>
>  
The servo controller in the Hobbico C-61 is the NJM2611
semicon.njr.co.jp/njr/hp/fileDownloadMedia.do?_mediaId=417
Gaston


2008\07\16@075551 by Dave Tweed

face
flavicon
face
Gaston Gagnon wrote:
> Harold Hallikainen wrote:
> > I've wondered what the hardware in these servos really is. It SEEMS that
> > maybe they run the PWM through a low pass filter to get an analog voltage
> > that they then compare with a pot on the shaft and drive the motor with
> > the difference. It SEEMS that the use of PWM is just a way to get analog
> > voltages. I've never taken one of these servos apart, but one of my
> > students brought one to class to play with. I found that just driving it
> > with an analog voltage between the supply rails did NOT make set the motor
> > position as I had expected. Maybe there's a schmitt trigger before the
> > LPF?
> >
> > So, does anyone know what's actually in the servo motors?
>
> The servo controller in the Hobbico C-61 is the NJM2611
> http://semicon.njr.co.jp/njr/hp/fileDownloadMedia.do?_mediaId=417

It isn't terribly clear in that datasheet, but the basic concept is
this: The feedback pot on the servo controls a monostable multivibrator
(one-shot), and the width of the pulse that it generates is compared with
the width of the input pulse. Whichever pulse ends first determines the
direction that the motor needs to be driven, and the difference in pulse
widths controls the strength of the drive.

In this relatively primitive controller, the rate of the input pulses
directly controls the rate of drive pulses to the motor, and it's driven
entirely by the "P" (proportional) term in the error. In more sophisticated
servo controllers (that incorporate a microcontroller), they measure the
input pulse width directly, and then drive the motor with a higher pulse
rate that is independent of the input pulse rate. They can also incorporate
a full "PID" control algorithm for improved performance.

-- Dave Tweed

2008\07\16@083609 by olin piclist

face picon face
Harold Hallikainen wrote:
> I've wondered what the hardware in these servos really is. It SEEMS
> that maybe they run the PWM through a low pass filter to get an
> analog voltage that they then compare with a pot on the shaft and
> drive the motor with the difference.

No.  Remember, this was all designed when computers filled whole rooms and
nobody was going to put one in a simple RC transmitter or receiver.
Everything is analog based and something you could handle with simple
circuits and cheap components.  So now think how you'd design the system
given these constraints.

The transmitter provides a pulse occasionally, and the data is encoded in
the width of this pulse.  Since it's RF, you can't rely on any one pulse
making it thru, so relying on average duty cycle doesn't make sense.  That's
why your DC level didn't work.

In the servo, a low input level keeps a integrator reset.  When the pulse
goes high, the integrator starts integrating, creating a linearly rising
voltage.  At the pulse trailing edge, this voltage is saved in a sample and
hold.  The sample and hold output is the analog drive voltage the servo
adjusts the motor to.

The "integrator" can be as simple as a resistor and capacitor with a
transistor for resetting.  So it's not perfectly linear.  Oh well.  The
sample and hold also doesn't need to be all that accurate or fancy.  This is
why servos act strange when you don't give them a pulse for a while.  The
sample and hold output starts to drift.  These were designed to be refreshed
every 20mS, with the ability to ride out one or two consecutive missing
pulses.

With the current state of microcontrollers, it's possible that some servos
use them instead of the analog electronics the interface scheme was
originally designed for.  I'm guessing a large number probably don't though.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\07\16@090218 by Harold Hallikainen

face
flavicon
face

{Quote hidden}

Thanks for the explanation! I think the end result is similar to the
purely analog approach I described EXCEPT that with the approach you
describe, the motor is driven with a PWM signal (the pulse width is the
difference between the locally generated pulse width and the input pulse)
instead of a varying DC voltage.

Harold

--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2008\07\16@091710 by Apptech

face
flavicon
face
PIC content dropping ... .
Still relevant as to how decoding may be done simply and
what information is available in the signal. Looking EEish.


{Quote hidden}

Or, as someone suggested, and as the Japan Radio IC suggests
(although I haven't checked its functionality):

The pulse rising edge triggers a monostable whose period is
set by the servo position pot. If the monostable pulse is
longer the servo drives anticlockwise. If the monostable
pulse is shorter the pot drives clockwise. This could either
be done proportionately as Olin suggests, with a long
difference pulse giving a faster servo speed OR very simply,
the direction only could be sampled and the motor could
drive at constant speed in the appropriate direction. Note
that the JR IC had a deadband control which (presumably)
allow the servo to not hunt continually when the pot setting
is close to the one being sent.

In the technology of the day, a (TTL) 74121 monostable and
perhaps a 7474 or 7476 as a latch would allow a 2 IC
solution, with a bit of head scratching to deal with dead
time.

Aaaagh !!!

       http://focus.ti.com/lit/ds/symlink/sn74121.pdf

Brings back memories :-).



       Russell.


2008\07\16@093729 by Bob Ammerman

picon face
>>> The servo controller in the Hobbico C-61 is the NJM2611
>>> semicon.njr.co.jp/njr/hp/fileDownloadMedia.do?_mediaId=417
>>
>> It isn't terribly clear in that datasheet, but the basic concept is
>> this: The feedback pot on the servo controls a monostable multivibrator
>> (one-shot), and the width of the pulse that it generates is compared with
>> the width of the input pulse. Whichever pulse ends first determines the
>> direction that the motor needs to be driven, and the difference in pulse
>> widths controls the strength of the drive.
>>
>> In this relatively primitive controller, the rate of the input pulses
>> directly controls the rate of drive pulses to the motor, and it's driven
>> entirely by the "P" (proportional) term in the error.

So....

Faster pulse repetition rate = faster slew response of servo.

But....

You have to be careful you don't try to retrigger the one-shot too soon. It
may have a limited duty cycle depending on its design.

And of course, this chip is just one way of doing it.

Thus....

Assuming there are 'standards' for RC Servos. How fast a pulse rep rate is
'legit' for all compliant servos? Is it 20ms, or faster?

-- Bob Ammerman
RAm Systems

2008\07\16@095412 by Ariel Rocholl

flavicon
face
2008/7/16 Olin Lathrop <KILLspamolin_piclistKILLspamspamembedinc.com>:

>
>
> With the current state of microcontrollers, it's possible that some servos
> use them instead of the analog electronics the interface scheme was
> originally designed for.  I'm guessing a large number probably don't
> though.
>
>
>
>

That is exactly the difference between traditional "analog" servos, and more
modern "digital" servos. <Digital> is the way most manufacturers indicate
the servo is now being driven by a uC rather than traditional analog
circuitry. One known tech note on this
http://www.futaba-rc.com/servos/digitalservos.pdf

--
Ariel Rocholl
Madrid, Spain

2008\07\16@095802 by Ariel Rocholl

flavicon
face
2008/7/16 Bob Ammerman RemoveMErammermanTakeThisOuTspamverizon.net:

>
> Assuming there are 'standards' for RC Servos. How fast a pulse rep rate is
> 'legit' for all compliant servos? Is it 20ms, or faster?
>
>

Most RC servos will work with periods as low as 15ms, in fact many
transmitters are closer to 15 than to 20ms to get faster response on
traditional servos. That said, some specific servos don't like anything
different than 19-20ms. So an "universal" control has to assume either 20ms
or provide a bit of configurability.

--
Ariel Rocholl
Madrid, Spain

2008\07\16@100018 by Tamas Rudnai

face picon face
> Assuming there are 'standards' for RC Servos. How fast a pulse rep rate is
> 'legit' for all compliant servos? Is it 20ms, or faster?

20ms is only a 'hint', some of them do it in 22ms, some others in 10ms. I
believe there is a 6ms timing that needed after the falling edge of the
pulse for resetting the circuit. Also note that the 1-2ms is also a 'hint',
many radio system goes down to 500us and goes up till 2.5ms to be able to
set the end-point-adjustments in a wider range. Now if you have 2.5ms + 6ms
resetting theoretically you can have a frame rate of 8.5ms - but to be safe
I would not go below 10ms. BTW I think some Futaba controllers use 10ms for
analogue servos and works well with most well known (aka legitimate) servos
like Futaba, Hitec, Swana or Graupner.

BTW if servo would move slower with smaller errors between the current
position and pulse, we would not hear the annoying brumm from the servo from
time to time (brumm as it has a similar voice as a radio operated by an
unfiltered 50Hz psu). Also these servos designed to keep the position, not
just reaching it. So on an airplane for example the smallest difference
between the desired control surface position and the actual one could lead
to major differences in flying. Therefore the servo has to have a high
torque at all times.

Tamas


On Wed, Jul 16, 2008 at 2:35 PM, Bob Ammerman <spamBeGonerammermanspamBeGonespamverizon.net> wrote:

{Quote hidden}

> -

2008\07\16@161852 by William \Chops\ Westfield

face picon face

On Jul 15, 2008, at 8:23 PM, Harold Hallikainen wrote:

> So, does anyone know what's actually in the servo motors?

Interesting timing. Elsewhere, someone recently posted:

  www.seattlerobotics.org/encoder/200009/S3003C.html
which points to:
   http://www.seattlerobotics.org/encoder/200009/Servos.html

Looks like the feedback pot is used to generate a pulse that the  
incoming pulse is compared against digitally rather than first  
converting the pulse to an analog voltage as you theorize.  I don't  
know offhand why one way would be better than the other (less  
dependence on supply voltage, perhaps?)  Actual reasons may be lost  
in the depth of time; 544 is a pretty damned low part number; I'm not  
sure what the state of digital electronics was at the time, and  
perhaps hobby servos leverage "standard" technology from industrial  
controls of which I'm unaware...

BillW

More... (looser matching)
- Last day of these posts
- In 2008 , 2009 only
- Today
- New search...