The dreaded PWM servo jump! Many of us know it far too well

PWM servos are "read only", in the sense that they listen for a pwm signal length and move into a position relative to that length. The controller which sends the signal can never know the position of a servo unless it is sending the position. You see, at first startup it can only begin sending a position because it doesn't know what position the servo is in. There is no feedback mechanism.

There are two solutions. One is far more elegant, where the other kind of just works....

1) The "Just Work" Method (assume init position) This is more brute force than anything. But every time you initialize, assume the robot is already in a position. Meaning, have the robot's belly against the ground and the legs out. The trouble with this , of course, is that every "connection" requires you to move the robot into that position. Otherwise, you can have a sensor to verify if the robot's belly is down or not to adjust the assumed init position.

Also, in this method, you'll want to initialize each servo within a 1-2 second delay. So you loop through each servo and initialize each one into a position at a time. This prevents the huge current draw that occurs when the init rushes all servos into a position.

2) The "elegant" but a lot of work method (Obtain servo positions) Here's where it gets a little more work for you, but my preferred method. There are servo manufacturers (robotis, lewansoul, feetech) that have position feedback. This is helpful for robot skills like the Auto Position to know where the servos are on initialization, The However, you could still do the same in code and handle getting the positions yourself with code.

A new wire would need to be added to each servo. This involves opening the servo bottom and soldering a wire to the center pin of the position potentiometer. This will now be a 0-5v signal that can be read by ADC and calculated into a relative position. I made a tutorial video on it here...

The two skills i used...

• Reading positions with the 8 onboard EZ-Robot EZB v4 controller: https://synthiam.com/Support/Skills/Servo/PWM-Servo-Feedback-ADC?id=18047

• Reading additinal ADC positions from an arduino over I2C to the main controller: https://synthiam.com/Support/Skills/Servo/PWM-Servo-Feedback-i2c?id=18069

Also with this setup, i was able to make something fun like this....

Hi DJ,

for decades I am busyly flying RC planes. This means I have worked on many dozends of servos, working on the same principle as here with robots.

But - in the RC business - no single servo is jumping to an intitial zero position upon receiver "power on". The servos receive the pulse length, according to transmitter sticks positions  and will adjust their arms to these specific start values.

In case you positioned servos beforehand; nothing will happen; they will stay quiet.

In case you did not position a servo to its initial "power on position", it will jump to this initial position.

This servo behaviour is totallly OK, but it does not apply with to EZ-B.

Even I position the servos to their assumed initial position within the program, all servos will at first rapidly jump to their own zero position (pulse duration: 100 ms) and will only then return to the program initial position (by defined speed).

I assumed here the following puls duration for servo motion: 100 ms: servo zero position 150 ms: servo central position 200 ms: servo fullscale position

You see, there is a totally different behaviour for servos in RC environment and in EZ-B environment.

And exactly this difference is what I am puzzled about.

Questions are:

-   What is creating these 100 ms long servo pulses (servo zero position) within the program, before the correct initial value it transmitted to the servo ?

-   How can these 100 ms long pulses at software startup be suppressed ?

I guess, the absolute very first thing that has to happen in any program is generating an initial pulse width for all servos (user defined). By these means "uncontrolled" servo motions may not occur.

What do you think ?

I will dig a bit deeper in this - inside my "insect" program.

OK, a feedback loop is nice, but there must be another solution; since - in the RC world it works ! !

Cheers

Volker

hi

the HD servo's move when power on. the HDD servo's dont move when power on. did you calibrate your servo's first ?

There’s no code sending any pwm when power is applied to the ezrobot ezb v4. You can review the ezrobot ez-b v4 code in the github repo.

Firstly: I understand the EZ-B behaviour; is OK for a computer-baseed servo driver (acting different than a "simple" RC transmitter).

Secondly: Don't worry, we'll find a solution.

What about this (within 30+ yrs. in space industry one became creative :-)

-   Servos are not directly connected to the EZ-B DIO ports, but via a switch.

-   Other input side of the switch is connected to the output of a NE555 (astable multivibrator); acting as a "mother servo pulse generator"). Such connections need to be realised via diodes in order to avoid later pushback from EZ-B.

-   Servos are powered externally (e.g. robot Lipo); same voltage as EZ-B DIO's.

-   NE555 pulse duration is selected for mechanically safe servo positions (not harming themselves by hard stops).

Operation: -   EZ-B is switched off.

-   Flip switch (with servo input lines) to "NE555 operation".

-   Switch on NE555 --> All servos  will move to "harmless positions".

-   Switch on EZ-B.

-   Flip above switch to "EZ-B operation" so that servos will go to their programmed initial positions.

At a first glance, this approach might look a bit cumbersome, but it is easier than EZ-B re-configurating ? ! !

In principle, this potential solution should work; I will set up a circuit diagram and will check whether there are bugs within.

@DJ: Do you have an email address or similar, where we could discuss such a circuit in detail (in case you are interested) ?

Cheers

There is a much easier solution for overcoming servo jumps:

Servos will receive power after EZ-B initialising is completed and not before !

How ?

-    Only the signal wires of the servos are connected to the DIO ports.

-    Servos GND and Plus wires are directly connected to the battery (2S Lipo); have done this several times with HV servos and RC receivers (battery GND and Plus are identical with corresponding DIO pins).

-    servo power is activated via toggle switch.

This approach has the additional advantage that servo action can be "killed" in case of emergency without disconnecting the EZ-B from power.

Cheers

Volker

The EZ-Robot EZ-B v4 can be configured to have one of the digital pins active for the client connection status. Meaning, when ARC connects the pin goes HIGH. Connect that to a solid state or a transistor powering a physical relay. That way if you ever disconnect in case of emergency, the servos will go limp for safety.

That setting can be configured in the HTTP server of the EZ-Robot EZ-B v4.

No open questions left.