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.

Good walk-through
This gives a good idea of the process of troubleshooting a robot, running through different steps to narrow down what the difficulty is, good tip!

It’s all in the timing (TWSS)

This is a good tip. 15ms is typically the center of a “normal” servo or “off” for a continuous rotation one.

Two other scenarios spring to mind:

1) You are too chicken to open your C/R (because that’s what I’m calling Continuous Rotation servos now) servo.

2) You open your servo to find a pair of resistors where the pot should be!

In this case, you’ll need to manually “hunt” for the centre position. Start at 1500us, then try 1550. If that reverses the direction try a value between 1500 and 1550. If it makes no difference, try 1450. If that reverses the direction try a value between 1450 and 1500.

If neither of these values makes any difference, try 1600 and 1400 mics.

It would think it rare to be further out of calibration than this.

what duty cycle are you
what duty cycle are you using? (curiosity)

When PWM is not PWM

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.

huh?

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?

Depends on your Definition

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…

yes, I was talking semantics

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”!

strike 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

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.

pwm over single wire = serial

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?

Ones and Zeros down a wire

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.

ahh, an intermediate controller

between brain and brawn

get it now