servo control

You might try wiring external pull-down resistors between the pins that drive the servos and ground. Say 10k ohms, might help with the transistion period and cheap to try.

Lefty

Good idea...
Tried it, unfortunately, had no effect.

Hmmm..
I just reread the servo reference page, and it states:

Note servos draw considerable power, so if you need to drive
more than one or two, you'll probably need to power them from
a separate supply (i.e. not the +5V pin on your Arduino). Be sure
to connect the grounds of the Arduino and external power supply
together.

I am driving three servos, but I do use an external supply, plugged
into the jack on the arduino board. I do have my servos connected
to +5v on the arduino, and I did not do any wiring to strap the
external power supply ground to arduino ground. I took for granted
that these were the same point. Now I'm guessing that this is
wrong...???

Also, by the way, I notice that plugging/unplugging other USB devices
into my PC cause the servos to occasionally go haywire. I have this
arduino board on a separate powered hub, and I apply the additional
external powersupply to the arduino, so I'm kinda surprised at that.

I do have my servos connected to +5v on the arduino

Don't do that.

Make your own little circuit for the power to the servo's. So you only use the arduino for signal, and your own circuit for powering the servo.

Hmmm..
If I'm using a 9v external wall-wart powersupply, anyone know
if that's too much voltage to directly power the servos? All I read
is that the servos run between 4.5 and 6V, so I guess I need an
additional regulator (or voltage divider at least) to get 6V?

9V is too high, so yeah, you need something to get it down.

4 alkaline batteries. Bigger battery with a voltage regulator. Bunch of possibilities. Just make sure to:

Tie the ground to the Arduino ground and to all the servo grounds.
Tie the hot to all the servo hots.
The data pins go to each servo signal.

This will work for any power source in the proper voltage range.

I used a Bigger Lithium Polymer battery and a voltage regulator to get proper voltage for my servos. But it is pretty much the same as using 4 AA batteries.

Here is a thread with more info about how I did it.
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1265626147/6#6

In the first picture, you can see the orange and green wires. They carry the signal from the 18 pins to the servo plugs. Power comes from the 2 wires running off the shield.

First, before I continue, I just wanna say thanks for the responses.
Great forum!
Ok, now back to the problem...
I found a 6V supply, and rewired the power for the three servos to
that line, plus I have grounds tied together. I also have 10k pull-down
resistors on each of my servo signal lines (to help with the transition
from powerup to servo.attach()).
That being said, it appears that I can now plug in/out other USB
devices on my PC and this no longer affects my servos.
Unfortunately, that's the only good news.
I still have a glitch each time I connect to the PC com port. My
guess is that this is caused by the transition on DTR, so I could
disable that; however, it seems like a good thing to have the board
reset when I first connect to it.
Plus, the other problem is that at startup you don't know what the
position of the servo is, so when you do the initial attach how do
you keep the servo from potentially slamming to the startup position?

So, I have two problems (sorry about the verbosity):

  1. Glitch at startup (servo just jumps a few degrees. this happens
    even with an empty setup() loop())

  2. How do you gently sync up the initial position you set your servo to
    with the actual position the servo is at? For example, if my servo
    just happens to be at 180-degrees and I start up and want to
    initialize things to 90 degrees it will just "SLAM" over from 180 to
    90 because I can't tell where the servo is at startup.

Again, thanks for all the input.
BTW, I'm using pins 9, 10 & 11 for servo control. Are there preferred pins for this?

So, I have two problems (sorry about the verbosity):

  1. Glitch at startup (servo just jumps a few degrees. this happens
    even with an empty setup() loop())

I think you just have to live with that. Even when used in radio control systems, the servos twitch a little on initial power up.

  1. How do you gently sync up the initial position you set your servo to
    with the actual position the servo is at? For example, if my servo
    just happens to be at 180-degrees and I start up and want to
    initialize things to 90 degrees it will just "SLAM" over from 180 to
    90 because I can't tell where the servo is at startup.

As there is no independent position feedback from the servos to the Arduino, there is no way to know what position the servos are at when first powered up, therefore no way to smoothly transition to a desired starting position. If it's an important safety or application requirement then about the only thing you could consider is adding some kind of analog position feedback pot to the servo's output wheel or linkage, then you could read it's position and decide which direction and how fast to command to the desired start-up position.

Lefty

I agree regarding the initial position issue (needing some kind of
position encoder on the servo); however, I still wonder if there is
more I could do to reduce/eliminate the startup glitch...
The glitch is apparently caused by the change in state on the signal
line. I'm reasonably certain of this because the 6v supply I'm now
using for servo power is always on.
So, assuming DTR does a reset on the CPU, the IO lines that end up
being servo control signals are initially inputs, and the pull-downs
on those pins would keep those lines low from the servo's point of view
(right?).
Since I still see this glitch even if I don't call servo.attach() in my
arduino app, doesn't that imply that the bootloader must be doing
something with these lines momentarily?
I guess my long-winded question here is this:
Is it possible that a bootloader modification would cure this?

The servo motors will even move back when you just give them power without a signal. They should then just move to their middle position.

Maybe a fix could be to make the arduino control when they get power? So it can set the signal, and then pull a relay to give them power. But still not sure if that would work.

Since I still see this glitch even if I don't call servo.attach() in my
arduino app, doesn't that imply that the bootloader must be doing
something with these lines momentarily?
I guess my long-winded question here is this:
Is it possible that a bootloader modification would cure this?

I don't think so. The processor internal hardware logic just defaults to all I/O pins go to input mode (floating) on power up or reset cycle. The bootloader I don't think does anything to pins other then serial in and out and pin 13.

Look at from the servos perspective. When it powers up, but has no valid command PPM pulse arriving what should it do? That is a undefined state and servos can only do what they see coming from the signal wire. Most I have worked with, in that condition, just twitch a little but stay in the position they are already at. That is if mechanically unloaded. If there is a heavy mechanical load and no PPM pulse arriving it's possible for the load to move the servos initial position, but that depends on the load, gearing, etc.

Again if initial position at power up is important then you will have to add some kind of feedback measurement, otherwise you just have to live with commanding to a initial known starting position.

Lefty

The servo motors will even move back when you just give them power without a signal. They should then just move to their middle position.

I don't believe that is a true statement. A servo will not default to it's middle position unless it is receiving 1.5msec PPM pulses on it's signal line. There is no default position for servos that have no PPM pulses being sent to them.

Lefty

I don't believe that is a true statement. A servo will not default to it's middle position unless it is receiving 1.5msec PPM pulses on it's signal line. There is no default position for servos that have no PPM pulses being sent to them.

hmm, I got four that does it.

Lefty,
Ok, thinking about it, I agree that its very unlikely that the bootloader
is doing anything to these pins that could cause this. However, I think
if there was a signal issue that would cause the servo to glitch at
startup, the pull-down resistor would cure that.
So, now I think I finally realize what is going on (lemme know if you
think this makes sense)...

The problem isn't actually at startup, its at shutdown.
Think about it...
I claim that the pull-down resistors cure the "initially floating" state, so
the signal into the servo at that point is low & clean. Then when
my application does its servo.attach(), valid PWM is applied to the
signal and things come up clean (so far so good). The problem
(this is my latest theory anyway) is when DTR hits the CPU to reset
it...
Now, the servo is running just fine, getting a valid PWM control
stream, then suddenly the stream is just terminated at some random
point. This means that the very last PWM pulse width is also random;
and this causes the glitch because it randomly repositions the servo.
Seems to me, if you don't have any control over when that DTR pulse
is coming in, then you really can't do anything about this.

Thoughts?

Now, the servo is running just fine, getting a valid PWM control
stream, then suddenly the stream is just terminated at some random
point. This means that the very last PWM pulse width is also random;
and this causes the glitch because it randomly repositions the servo.
Seems to me, if you don't have any control over when that DTR pulse
is coming in, then you really can't do anything about this.

Thoughts?

I think you have it pretty close. Not sure how much a servo can move from the transistion of valid steady PPM pulses to suddenly no pulses. The servo's internal electronics normally intergates the input pulses so a single pulse of say 0% won't cause the servo to move from say 50% to zero, rather just a slight twitch most likely.

This may not be related, but there is a way to prevent auto-reset on DTR caused resets, by removing the connection of the DTR capacitor wired to the reset switch. Some boards have a means with a switch or jumper clip to enable or disable auto-rest on DTR function. That won't deal with power off/on cycles of the board or servo however.

Lefty

hmm, I got four that does it.

Well I just tested a typical R/C (cheap Asian model) servo on my desk. With no signal, but just applying power on and off. If I manually move the servo to one extreme and then apply power it moves about 35% when powered up. If I keep removing and applying power it continues to initial move about 35% each time until it reaches the other extreme end of travel. After that it just twitches with each application of power off/on around that end of travel. The servo never moves or twitches on removal of power, just on the application of power.

A servo without an input pulse stream is a undefined function/status and I'm sure different servos will move/twitch different amounts. It would take a more advance digital servo with internal non-volatile memory functions to have say a programmable start-up position in the event of no or loss of control pulses. I do believe there are such more advanced 'digital servos' available, but they are more expensive and would have to be programmed/setup to behave as one wants.

Lefty

Okay, mine are ~85$ Hyperion digital servo's, can't set startup position in their controller, but without a signal, they move to center.

Just tested a cheap servo (same i am using for my catdoor lock) it doesn't move without a signal.

But also got a problem with the digital servo's... They refuse to move with the arduino, but no problem with my parallax 16ch controller.

Ok, I think I'm good to go.
Just to recap this thread...
My initial problem was a servo "glitch" at startup, and an occasional
loss of servo control when other devices were plugged into
my PC's USB.
I've changed over to use an external 6V power supply to
directly power the servos; and it appears that this has fixed
my occasional loss of control when other devices plug into USB.

The glitch is something that really can't be eliminated; however,
my control application on the PC was toggling DTR at time of
connection, so I no longer do that, and this indirectly eliminates
the glitch (doesn't fix it, just avoids it).

Finally, the problem with not knowing where the servo is at startup
is an open issue, and is common to all servos that don't have some
kind of position feedback. I can live with that.

Thanks to all for the input...
'Twas a good day.