Let's Make Robots!

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.

 Hope this helps someone.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
what duty cycle are you using? (curiosity)

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.

Do you mean that for PWM to be true PWM, it is the ratio (pulse width) : (pulse period) that mathers?

And also that servo control depends on pulse width alone? No ration no true PWM? Is that it?

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...

I consider myself a bit of a semanticist.

I also appreciate the "within reason" footnote.

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".

update: Strike "springed solenoid"!

update: Strike "springed solenoid"! Its a "proper" motor driven actuator. (yet another dangerous word: proper)

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.

Now, how's that for a recap?

Serial comms is not always an option. Only some digital servos support it and it's usually only for programming the endstops and the rate of change.

WRT speed: thy always go as fast as they can, but anyhalf decent controller will allow you to control the rate.

In my book anyway. I meant serial as in "nothing going parallel". Not necessarily any official protocol like i2c. I figured PWM as a serial  communication.

I did read  the thread on digital servos. Will stay away from those for a while (I'm pre-beginner in servology).

WRT speed indeed: how would I influence rotation speed, assuming a half decent controller? That's the IC in the servo right? Not the microcontroller that is talking to it?

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.

between brain and brawn

get it now