Continuous rotation servo broken.

I thought i'd make this post to help any beginners that also run into this problem, i wasted a good hour and a half on this, so hopefully no one else has to.

So i have two continuous rotation servos, i set each one driving a single wheel. I was testing my driving methods forward, backwards, left, right. I tested forwards and it worked, i tested right and it worked, i then tested backwards and it turned right, then i tested left and it went backwards. After a bit of debugging i narrowed it down to one servo only turning in one direction. I set up some code and realised that no matter what pwm value i sent, it would only spin in one direction.

Anyway to cut a long story short i needed to "re-calibrate" the servo by sending a pwm value of 15millis and adjust the potentiometer so that it was centered.

I try to approximate a pulse period of 10ms and the pulse duration is variable between 500us and 2500us, so duty cycle is variable from 5% through 25%.

...but that's not at all relevant as the servo control output is not (in the strictest definition) a PWM signal at all. The relationship between the pulse period and pulse duration is completely unimportant. You can change the pulse period to anything from 5ms through 25ms or more and it will make no difference whatsoever to your servo position.

What's important is the pulse duration.

Now, I'm a smart-ass (you may have noticed). I would argue that if you are modulating the pulse width, then it's Pulse Width Modulation...

...but the DoD, the JTA, ANSI, ITU, NATO and STANAG all appear to disagree with me.

Normally, the important aspect of PWM waveform is the ratio between the pulse rate and the pulse length, yes. If you are using a PWM to DC voltage convertor, for example, (a cheap and very common implementation of a DAC) the device doesn't know (or care) what the frequency is, only that the waveform was "high" for n% of the total time.

Again, yes. The servo doesn't really care about the cycle time, within reason. The tolerances differ from servo to servo, but I've have very bad results with cycle times below 5ms and if your cycle time goes much about 20ms, your torque starts to drop off. The ratio between pulse width and cycle time is irrelevant here. But regardless of your cycle time, 1.5ms is (I'm tempted to use the dangerous word "always") the centre or off position.

I'm glad abarax (1289) opened up this topic. It seems like there's quite a bit of interest in servo internals. I have my own issues with them...

And now I am starting to understand the internals of servos a bit better. Also in part due to the discussing of springed gm10's somewhere else. I now regard a servo as a Springed Solenoid; Angular, BiDirectional and Controlled by its own IC. Communication with the IC is through a standardised serial protocol which should not be confused with (but is very comparable to) "true PWM".

The motor turns as commanded by the servo's IC. The serial communication offers the ability to command how far the shaft should turn. Speed is pretty much constant. There is no spring, unless I missed something. Return to the neutral (center) position is performed by the IC/motor action. The IC knows the angulaar state of the shaft because it receives feedback from the pot that acts as an encoder.

According to some of the replies on digital servos you should be safe enough so long as you don't buy some cheap-and-nasty ones like I did.

Speed: No, I wouldn't have you delve into the internal controller. With the possible exception of digital servos, there is no way to modify the rate of change of the servo internally (without opening up the servo). The only way to do this is by making successive position demands of your servo using the microcontroller.

If the servo is at position 0 and you demand that it get to postion 100, it will go there as fast as the motor will take it. If you demand position 1, 2, 3 ... 100 with a 100ms gap between, it will take 10 secons to get from 0 to 100.

A decent servo controller will allow you to specifiy the rate of change and then just go away and get on with it so your main MCU doesn't need to worry about it.