Servos go out of sync!

Hello everyone. I am part of a bio-inspired robot project. We are building a robot that has 4 HSR-2645CRH continuous servos for movement. I have ordered a PCA9685 servo controller to control the servos but couldn't figure out the code so I decided to connect the servos directly to the Arduino Uno R3.

The problem that I'm having is that servos go out of sync after a while. 1st servo called in the code moves earlier and faster than other servos, 2nd servo earlier and faster than 3rd and 4th etc.
I used the oscilloscope to check the signal and saw that the signal from arduino doesn't come at the same time for all servos. Is there anyway to sync them or move them at the same time? Does using the PCA9685 board help to solve this problem?

I can't see any code or a circuit diagram so I don't know what it is that you're doing that might cause your problems.

But if you're expecting that simply sending the same signal value to 4 different servos is going to result in them rotating at PRECISELY the same speed you're going to be disappointed even with HSR-2645CRH servos.

BTW have you had them on a programmer to fine tune their speeds, that should give you the best chance. But if you really need them to stay in sync long term then you'll need to use encoders with them.

Steve

Yea, a sequentially running program trying to do 4 somethings at the same time is an issue. Have you tried the concept of sending one signal to a device that will split the signal servo into 4 parts? Better yet, there are servo "Y" connectors where you'd only have to split the signal into two parts.

ElectronDonda:
The problem that I'm having is that servos go out of sync after a while. 1st servo called in the code moves earlier and faster than other servos, 2nd servo earlier and faster than 3rd and 4th etc.
I used the oscilloscope to check the signal and saw that the signal from arduino doesn't come at the same time for all servos. Is there anyway to sync them or move them at the same time? Does using the PCA9685 board help to solve this problem?

You say it happens "after a while"; does that mean all is ok at the outset? Please elaborate.

If (and we can't say since you didn't show any code) the servo.attach()'s or servo.write()'s that control all the servos are on consecutive lines in the code, they surely can't start moving more than a very very very tiny part of a second apart. (No further than say 2 consecutive digitalWrite()'s might be to fire up 2 DC motors.) Let's see the 'scope trace.

The different speeds can only be due to physical differences in the motors, or the signals are of different lengths. Yet the "after a while" makes it seem as if the motors start out at the same speed but then that changes?

Maybe you should post the code, schematic, 'scope traces and a more detailed description of what's going on....

(I will meantime dust off my scope (only 2 channels) and see how far apart (if it's even discernible) two servo signals start when their calls are on consecutive lines of code, and how different in length (if it's even discernible) the pulses are for write()'s of the same length.)

I used the oscilloscope to check the signal and saw that the signal from arduino doesn't come at the same time for all servos.

If you user servo.write() for all 4 servos sequentially, I would expect the servo signals to go out nearly simultaneously. How much lag are you seeing? I cannot see how this would be detectable by the human eye.

How do you have the servos powered? Get a pen and paper, draw up a wiring diagram that includes your power source and how that power is distributed to the 4 servos, take a picture of the drawing and post the picture here.

vinceherman:
If you user servo.write() for all 4 servos sequentially, I would expect the servo signals to go out nearly simultaneously.

Me too... read on....

elvon_blunden:
(I will meantime dust off my scope (only 2 channels) and see how far apart (if it's even discernible) two servo signals start when their calls are on consecutive lines of code, and how different in length (if it's even discernible) the pulses are for write()'s of the same length.)

Ok I finally dug my scope out, and very interesting findings. Alas, I can't grab the scope screenshots. When I bought my scope I had Windows Vista, and EasyScope worked. Now I have Win 10, and can't get an Easy Scope driver. So as a side note, if anyone has a Win 10 EasyScope driver for my AA-Tech ADS-2102B scope, please send me a link...

I only have a 2-channel scope, but wrote a sketch for 4 servos and scoped the first one always, and moved the probe from the second to third to fourth to pretend I had 4-channels. All I did was have 4 successive servo.attach() commands, each preceded by a servo.writeMicroseconds()

Turns out that servo2's first pulse only goes out after servo1's pulse has finished and gone low. When scoping 1 and 4 (servo number being the order of the commands in the sketch) there's a gap on the scope where servo2's and servo3's pulses would have been. (Grrrr. wish I had a 4-channelscope.)

I used various servo.writeMicroseconds(). Whatever the value, subsequent servo pulses only go out on the tail of the previous one,once the previous one has gone low.

Not saying the way the servo pulses work is the casue of the problem here in this thread, but it certainly was not what I expected. The 4 outputs remain in the same relationship once they start of course, just that they're apart by the pulse width to start. Since the cycle time of 20ms stays the same, the pulses remain out of synch by that same amount; it doesn't get worse.

Send me a Win10 driver for EasyScope and I'll grab shots.

(In contrast, scoping blink with delay style output with digitalWrite() on two pins, the pins go high together to start and if of the same length, return to low together.)

But on the bright side that's exactly how a traditional RC receiver, which decodes the PPM signal using a shift register, will work too. And it's not likely that a human eye will detect a difference of maximum of 2ms.

Plus it doesn't go any way to explaining why the 2nd,3rd etc servos each run noticeably slower than the preceding one with same pulse length.

OTOH since the OP has now posted twice about this problem but has never replied to any questions/suggestions it's probably not worth worrying about it.

Steve

slipstick:
But on the bright side that's exactly how a traditional RC receiver, which decodes the PPM signal using a shift register, will work too. Good to know the servo library's written properly, then.And it's not likely that a human eye will detect a difference of maximum of 2ms. For sure!

Plus it doesn't go any way to explaining why the 2nd,3rd etc servos each run noticeably slower than the preceding one with same pulse length. Agreed. (I didn't actually put servos on the pins, just the scope probes)

OTOH since the OP has now posted twice about this problem but has never replied to any questions/suggestions it's probably not worth worrying about it. Wasn't "worrying" about it but it was interesting for me to look into, and if nothing else it reminded me how to use my 'scope.

Steve