Searching \ for '[PIC] PIC servocontroller jittery' 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: 'PIC servocontroller jittery'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] PIC servocontroller jittery'
2005\02\01@154350 by Padu

face picon face
First, thanks everybody for the long discussion (almost a relition war :-) ) of the "Interrupt USART + TMR0" thread, there was significant insights in that discussion that helped me with my program.

A quick refresh of what I want to do: in a few words, to control a R/C servo using a PIC mcu. The PC sends commands to the PIC using RS232. I will control 2 servos using the same PIC (could be more, but for now only 2). For example, if I want to set the servo connected to PORTC:<0> to -60 degrees (0 is center position), I would send 4 bytes to the PIC: $65 $8E $03 $35, in simpler terms that is A910#. First byte is what I call logical port: A=PORTC:<0> and B=PORTC:<1>, following 2 bytes are interpreted as a word, therefore 0x038E or 910, and last byte is just a simple way of checking the integrity of message. 910 will then generate a PWM of 0.91ms pulse on a 20ms dutycycle.

If the current angle is let's say -20 and I send a message "go to +60", the servo responds immediately and its motion is very smooth (I guess it goes at its regular operating speed - 0.19sec/60deg), but if I grab my pointer on the user interface and drag it, the motion of the servo is very bumpy and jittery. It will end up where I release my GUI pointer, but the trajectory will be rough. The same roughness can be perceived if you are measuring the signal on the oscope.

In my first controller, I implemented the PWM creation with a series of delays on the main program looping, then I've implemented using TMR0 with two timeslots, as suggested somewhere here in the list. With both of them I get the same bumpy results.

I have a few guesses of what could be going wrong, but before spending weeks trying to prove my hypotheses, perhaps someone knows or have a hint of what may be going wrong (well, it's not wrong, it's rough)

1-The servo itself could be rough. I don't believe though, because when I use the same brand of servo in my RC car, the servo-receiver "replicates the motion of my finger" when I press the trigger of the RC transmitter, very smoothly.
2-The servo needs more current to "start" moving. I'm supplying the Vcc to the servo from my development board, and honestly I don't know how much current it has. The board itself is drawing power from USB, therefore I guess not more than 500mA. What prompted me for this hypothesis is that whatching the oscope, the high signal drops a a little when it is moving roughly.
3-I'm using TMR0 to raise a flag every 10ms. On the main looping, when a flag is raised, it decide which port will be served in the current timeslot and then delay the appropriate number of cycles to generate the necessary width. Because there is also an interrupt for each character received from the USART, I'm afraid that characters are being received in the middle of the wait periods, creating a pulse width with incorrect timing.

Which one is the most probable to be happening?

2005\02\01@161117 by Jan-Erik Soderholm

face picon face
Padu wrote :

> A quick refresh of what I want to do: in a few words, to
> control a R/C servo using a PIC mcu. The PC sends commands to
> the PIC using RS232. I will control 2 servos using the same
> PIC (could be more, but for now only 2). For example, if I
> want to set the servo connected to PORTC:<0> to -60 degrees
> (0 is center position), I would send 4 bytes to the PIC: $65
> $8E $03 $35, in simpler terms that is A910#. First byte is
> what I call logical port: A=PORTC:<0> and B=PORTC:<1>,
> following 2 bytes are interpreted as a word, therefore 0x038E
> or 910, and last byte is just a simple way of checking the
> integrity of message. 910 will then generate a PWM of 0.91ms
> pulse on a 20ms dutycycle.

What resolution (in degrees or ms or whatever) do you need ?
+/- 1 deg ?
+/- 0.1 deg ?
How many descreet steps ? 100 ?
I would probably not try to send a measurment it "real" units,
but something more efficent.

> If the current angle is let's say -20 and I send a message
> "go to +60", the servo responds immediately and its motion is
> very smooth (I guess it goes at its regular operating speed -
> 0.19sec/60deg), but if I grab my pointer on the user
> interface and drag it, the motion of the servo is very bumpy
> and jittery. It will end up where I release my GUI pointer,
> but the trajectory will be rough. The same roughness can be
> perceived if you are measuring the signal on the oscope.

What "signal" ? The PWM signal probably, right ?
Note that sending characters out from a serial port on a
(Windows ?) PC isn't realy a "real time" process. My guess
is that you actualy have a "bumpy" stream of characters
comming out of the PC. Can you add a "logging" feature to
your PC program that logs exactly whats sent out ? Best would
be a serial line logger with timestamps on each byte.


> In my first controller, I implemented the PWM creation with a
> series of delays on the main program looping, then I've
> implemented using TMR0 with two timeslots, as suggested
> somewhere here in the list. With both of them I get the same
> bumpy results.

Since I guess that it's the sending routin in the PC that's
"bumpy", I guess that the actual code in the PIC doesn't matter.

> 1-The servo itself could be rough. I don't believe though,
> because when I use the same brand of servo in my RC car, the
> servo-receiver "replicates the motion of my finger" when I
> press the trigger of the RC transmitter, very smoothly.

Not likely, no.

> 2-The servo needs more current to "start" moving. I'm
> supplying the Vcc to the servo from my development board, and
> honestly I don't know how much current it has. The board
> itself is drawing power from USB, therefore I guess not more
> than 500mA. What prompted me for this hypothesis is that
> whatching the oscope, the high signal drops a a little when
> it is moving roughly.

Then it would move slowly rather then bumpy/roughly, I'd say.

> 3-I'm using TMR0 to raise a flag every 10ms. On the main
> looping, when a flag is raised, it decide which port will be
> served in the current timeslot and then delay the appropriate
> number of cycles to generate the necessary width. Because
> there is also an interrupt for each character received from
> the USART, I'm afraid that characters are being received in
> the middle of the wait periods, creating a pulse width with
> incorrect timing.

I would use timers to time *all* times related to the RC servo
PWM signal. Even the 1.0 - 2.0 ms pulse. Then other interrups
wouldn't matter a bit (or at least less...).

I'm not sure what speed your PIC is using, but getting an INT
fromt eh USART, saving the byte and RETFIE'ing whould not take
many us's, so that should not mess up your hardcoded timing
code that much anyway.

No, I'd take a closer look at whats actualy is sent out from
the PC.

Jan-Erik.



2005\02\01@165216 by Padu

picon face
Jan-Erik wrote:
<snipped>
> No, I'd take a closer look at whats actualy is sent out from
> the PC.


Humnn, I guess I could investigate this possibility by simply doing a PIC
(by the way 4Mhz) program that goes from -60 to +60 at a given angular speed
and remove the USART component from the equation for now. If you are
correct, that should be smooth. I'll do that test and post the results
later.

Cheers,

Padu

2005\02\01@170928 by Jan-Erik Soderholm

face picon face
Padu wrote :

> Jan-Erik wrote:
> <snipped>
> > No, I'd take a closer look at whats actualy is sent out from
> > the PC.
>
>
> Humnn, I guess I could investigate this possibility by simply
> doing a PIC (by the way 4Mhz) program that goes from
> -60 to +60 at a given angular speed and remove the USART
> component from the equation for now. If you are correct,
> that should be smooth. I'll do that test and post the results
> later.

Or put that test application in a *second* PIC and keep the
USART code so that gets tested as well...

Jan-Erik.



2005\02\01@172751 by Walter Banks
picon face
One factor that should not be overlooked is the frame rate to the servo. Earlier you stated that it was 10 ms. You might want to check that is correct for the servo you are using. It was the source of a RC servo control problem that I tracked down in a
project.

w.


Padu wrote:

{Quote hidden}

> -

2005\02\01@174220 by Padu

picon face
Jan,

You were right on target! I did a very simple application that at every 20ms
cycle, it increases the PWM by one degree (I know, the units are kind of
messy, but I guess you'll understand). When it reaches 60 degs, it starts
decreasing until -60 and then repeats forever. I also have a constant to
control angular speed, and I've tested with slow and fast speeds (up to the
servo limit speed) and they all work flawlessly.

I feel that I wasn't too polite not answeing your questions, so here they
are:

> What resolution (in degrees or ms or whatever) do you need ?
> +/- 1 deg ?
> +/- 0.1 deg ?

1 degree is fine

> How many descreet steps ? 100 ?

from -90 to 90, therefore 180 discrete steps, although I think -60 to 60 is
what I will end up using.

> I would probably not try to send a measurment it "real" units,
> but something more efficent.

Right now I'm sending a word with the pulse width in microseconds, what
would you suggest?

{Quote hidden}

right

> Note that sending characters out from a serial port on a
> (Windows ?) PC isn't realy a "real time" process. My guess
> is that you actualy have a "bumpy" stream of characters
> comming out of the PC. Can you add a "logging" feature to
> your PC program that logs exactly whats sent out ? Best would
> be a serial line logger with timestamps on each byte.

It already has a simple one, it logs a list of messages sent and all of them
are in increasing order (if I'm increasing the angle, of course). I also did
another test by sending a stream of messages created on linear time, instead
of dragging the pointer of my GUI application, it is still bumpy, but you're
right, the problem is somewhere there I guess.

> I'm not sure what speed your PIC is using, but getting an INT
> fromt eh USART, saving the byte and RETFIE'ing whould not take
> many us's, so that should not mess up your hardcoded timing
> code that much anyway.

I guess I could do another test using the "wiper" code I just did (-60 to
+60 forever) by including again the USART code in there but not using it to
change the servo angle, but I agree with you that the problem is not likely
to be there.

> No, I'd take a closer look at whats actualy is sent out from
> the PC.

Do you have any suggestion for which tool to use in this case?

Thanks!

Padu

2005\02\01@175108 by Padu

picon face
Walter wrote:
> One factor that should not be overlooked is the frame rate to the servo.
Earlier you stated that it was 10 ms. You might want to check that is
correct for the servo you are using. It was the source of a RC servo control
problem that I tracked down in a
> project.
>
> w.

10 ms is for one timeslot only. So portc:0 sends its pulse in timeslot 'A'.
portc:1 sends its pulse in the next timeslot. When it's the timeslot 'A'
again, 20ms have passed by, therefore the dutycycle is correct. As I stated
in another message, if the angles are dictated from a calculated number by
the PIC itself, the movement is very smooth (like a swiss clock), but if the
angles are sent from a PC using RS232, then it gets rough...

2005\02\01@180735 by Jan-Erik Soderholm

face picon face
Padu wrote :

> Jan,
>
> You were right on target!

Phu ! :-)

> I did a very simple application that at every 20ms cycle,
> it increases the PWM by one degree... and they all work
> flawlessly.
>
> 1 degree is fine
>
> from -90 to 90, therefore 180 discrete steps, although I
> think -60 to 60 is what I will end up using.

OK. So 120 steps then.
It would be easier to change the actual angle if you could
keep it to, let's say, 120 steps no matter what the real
angles are. See below.

>
> > I would probably not try to send a measurment it "real" units,
> > but something more efficent.
>
> Right now I'm sending a word with the pulse width in
> microseconds, what would you suggest?

Just sending a value between 1 and 120. Now this happens to
mean "degrees" in tha case or +/- 60, but should be seen as
a rellative measurement of the wanted position of the servo.

Then, your PIC app takes care of converting this into degrees
or ms or whatever. Such as a simple 120 position lookup table
with the delay amounts (or timer init values to get the wanted
pulse with). By just changing the values in this table, you could
get any actual movement. You could also use something like Excel
to calculates non-linear values to compensate for such things
as a rotary servo controling a linear "thing", some kind of
sin or cos function applied to the table.

> I also did another test by sending a stream of messages
> created on linear time, instead of dragging the pointer of
> my GUI application, it is still bumpy, but you're
> right, the problem is somewhere there I guess.

Well, it still *could* be the USART code interfering, we don't know
for sure until you have included that in your test.

> > No, I'd take a closer look at whats actualy is sent out from
> > the PC.
>
> Do you have any suggestion for which tool to use in this case?

There are simple PC based tools that logs an RS232 line,
but I think that you'd need better equipment to get realy good
timestamps on the bytes sent to see if it comes in "bursts" or
something.

Maybe just try to "see" the RS232 stream on an o-scope ?

Jan-Erik



2005\02\01@181208 by Jan-Erik Soderholm

face picon face
Padu wrote :

> 10 ms is for one timeslot only. So portc:0 sends its pulse in
> timeslot 'A'.  portc:1 sends its pulse in the next timeslot.
> When it's the timeslot 'A' again, 20ms have passed by,
> therefore the dutycycle is correct. As I stated in another
> message, if the angles are dictated from a calculated number
> by the PIC itself, the movement is very smooth (like a swiss
> clock), but if the angles are sent from a PC using RS232,
> then it gets rough...

Note that 10ms (or even 1 ms) is a rather long time for a PIC.
Usualy timers are best to "time" those intervals, not software
delay loops. (I'm not sure if and, if so, how much timers was
used in your code...)

B.t.w, you mentioned 4 Mhz, but did you mention the PIC model ?

Jan-Erik.



2005\02\01@185907 by Padu

picon face
Jan wrote:
>
> Note that 10ms (or even 1 ms) is a rather long time for a PIC.
> Usualy timers are best to "time" those intervals, not software
> delay loops. (I'm not sure if and, if so, how much timers was
> used in your code...)

I'm timing the 10ms using TMR0 interrupts, the 1 to 2ms I'm using delay
loops. From the results of my "wiper" application it seems it is working
fine, but I also took note of the suggestion of using timer to control the
1ms pulses too.

> B.t.w, you mentioned 4 Mhz, but did you mention the PIC model ?

PIC16F877A that resides on my development board. I still haven chosen which
one will be used in my project (an autonomous RC car)


2005\02\01@230557 by Bob Ammerman

picon face
Assuming a max 270 degree rotation capability of a  servo.... (ie: 1msec = 0
degrees, 2msec = 270 degrees)

If you take 40 instruction times to handle incoming character, that would be
8usec on a 4MHz PIC.

A 'blip' of 8usec in your timing will result in an error (jitter) of: 2+
degrees

8usec * 270 degrees/msec = 2.16 degrees

Bob Ammerman
RAm Systems




{Original Message removed}

2005\02\02@101934 by John Ferrell

face picon face
I don't think you have the problem YET, but the RC Servos draw a great deal
of current when they are mechanically loaded. At stall it will be in excess
of  the USB specs.

Just a heads up warning....
John Ferrell
http://DixieNC.US

{Original Message removed}

2005\02\02@124127 by Padu

picon face
That's a good point, and that brings me another question: can I supply Vcc
and GND from a circuit other than the one where the PIC is? Or should both
the servo and the PIC have common GND and Vcc?

I'm using the USB supply only for development purposes, later it will draw
power from a battery. Moreover, I don't expect a great load, one servo will
control the throttle of an RC monster truck and the other will steer. Right
now the stock servos do the job with only 4 AA batteries.

John Ferrell wrote:
> I don't think you have the problem YET, but the RC Servos draw a great
deal
> of current when they are mechanically loaded. At stall it will be in
excess
> of  the USB specs.
>
> Just a heads up warning....
> John Ferrell
> http://DixieNC.US



2005\02\02@145630 by michael brown

picon face
Padu wrote:
> That's a good point, and that brings me another question: can I
> supply Vcc and GND from a circuit other than the one where the PIC
> is? Or should both the servo and the PIC have common GND and Vcc?

You can use a seperate Vcc for the servo, but the grounds must be
shared.

> I'm using the USB supply only for development purposes, later it will
> draw power from a battery. Moreover, I don't expect a great load, one
> servo will control the throttle of an RC monster truck and the other
> will steer. Right now the stock servos do the job with only 4 AA
> batteries.

A AA battery can deliver much more current than a USB port.

> John Ferrell wrote:
>> I don't think you have the problem YET, but the RC Servos draw a
>> great deal of current when they are mechanically loaded. At stall it
>> will be in excess of  the USB specs.
>>
>> Just a heads up warning....
>> John Ferrell
>> http://DixieNC.US

2005\02\02@162438 by John Ferrell

face picon face
I concur.
John Ferrell    
http://DixieNC.US

----- Original Message -----
From: "michael brown" <spam_OUTspam-meTakeThisOuTspamhouston.rr.com>
To: "Microcontroller discussion list - Public." <.....piclistKILLspamspam@spam@mit.edu>
Sent: Wednesday, February 02, 2005 2:47 PM
Subject: Re: [PIC] PIC servocontroller jittery


{Quote hidden}

> --

2005\02\02@172248 by Antonis Iliopoulos

flavicon
face
Dear Padu,

I am working with servos at the moment and I noticed that when you have common GND and VCC for the pic and the servos, there is a lot of noise coming out of the servos.
Therefore I would recommend seperate power supplies.  On the other hand most of the servos run either on 4.8 or 6 volts and of course at 6 volts they are faster.  

Padu <padupicspamKILLspammerlotti.com> wrote:
That's a good point, and that brings me another question: can I supply Vcc
and GND from a circuit other than the one where the PIC is? Or should both
the servo and the PIC have common GND and Vcc?

I'm using the USB supply only for development purposes, later it will draw
power from a battery. Moreover, I don't expect a great load, one servo will
control the throttle of an RC monster truck and the other will steer. Right
now the stock servos do the job with only 4 AA batteries.

John Ferrell wrote:
> I don't think you have the problem YET, but the RC Servos draw a great
deal
> of current when they are mechanically loaded. At stall it will be in
excess
> of the USB specs.
>
> Just a heads up warning....
> John Ferrell
> http://DixieNC.US



2005\02\02@174521 by Antonis Iliopoulos

flavicon
face

Dear Padu,

The specs say that srvos need a PWM around 18ms.  People on the site encouraged me to go down to 10 ms.

I am actually using the S03 standard servos and by using a PWM generator, I kept the duty cycle stable in neutral possition - 1.5 ms and I was reducing the period.

And I went down to 4 ms without any problems.  

I know that the duty cycle has to be max 3/4 of the Period.  I would recommend you do the same so you confirm the specifications.  

Since you have a code working - would you mind if I send you my code that is sort of working in your private address in order to have a look?  Limit 40 k on this site... ?

{Original Message removed}

2005\02\02@174905 by John Ferrell

face picon face
A lot of high dollar big RC model airplanes use separate supplies and opto
couplers. How elaborate you get involves what risk is acceptable.
FWIW, On my Precision Aerobatics models I am comfortable with 4 Sanyo (1400
mah) NiCads. The total loss figure would be between $1500 &$3000 depending
on whether you are buying or selling.

John Ferrell
http://DixieNC.US

{Original Message removed}

2005\02\02@203507 by michael brown

picon face
John Ferrell wrote:
> A lot of high dollar big RC model airplanes use separate supplies and
> opto couplers. How elaborate you get involves what risk is acceptable.
> FWIW, On my Precision Aerobatics models I am comfortable with 4 Sanyo
> (1400 mah) NiCads. The total loss figure would be between $1500
> &$3000 depending on whether you are buying or selling.

It's been about 10 years since I was really into R/C planes.  Are NiCads
still the preferred battery type?  I would have thought NiMHs would be
the big thing now.

2005\02\02@204100 by michael brown

picon face
Antonis Iliopoulos wrote:
> Dear Padu,
>
> The specs say that srvos need a PWM around 18ms.  People on the site
> encouraged me to go down to 10 ms.
>
> I am actually using the S03 standard servos and by using a PWM
> generator, I kept the duty cycle stable in neutral possition - 1.5 ms
> and I was reducing the period.
>
> And I went down to 4 ms without any problems.

I'd be interested to know if there is an increase in current drawn by
the servo as the period is reduced.

> I know that the duty cycle has to be max 3/4 of the Period.  I would
> recommend you do the same so you confirm the specifications.
>
> Since you have a code working - would you mind if I send you my code
> that is sort of working in your private address in order to have a
> look?  Limit 40 k on this site... ?

2005\02\02@233946 by John Ferrell

face picon face
There will always be those trying new things and making wild claims. The
Sanyo NiCads always exceed specs and are a lot tougher that the manufacturer
advertises. NiMh has higher internal resistance, higher self discharge and
low tolerance to fast charging. Rechargeable Lithium's are nice but
expensive and potentially dangerous.

BTW, the frame rate on the servo does have an effect on the servo torque.

John Ferrell
http://DixieNC.US

{Original Message removed}

2005\02\03@133251 by Jan-Erik Soderholm

face picon face
> The Sanyo NiCads always exceed specs and are a lot
> tougher that the manufacturer advertises. NiMh has
> higher internal resistance, higher self discharge and
> low tolerance to fast charging. Rechargeable Lithium's
> are nice but expensive and potentially dangerous.

Won't NiMh replace NiCa soon anyway, becouse of the
toxic Cadmium ?

Jan-Erik.



2005\02\03@142057 by John Ferrell

face picon face
I have no idea what the greenies are going to do next.
I have not seen a NiMh electric screwdriver though...

I wonder just how much risk is involved with Cadmium since it used to be the
material of choice to keep steel from rusting.
John Ferrell
http://DixieNC.US

{Original Message removed}

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