Current based position control mode in a quadruped robot


I am currently working on a quadruped robot using 12 XM430-W210-T servos.

The robot is currently using the servos in:
-Position control mode
-Time based profile

This works really well and produces good and stable movement

The next step is to use the servos in:
-Current based position control mode.
-Time based profile
and use the goal current to make the legs some sort of compliant.

When the servos work in current based position control mode they work very shaky and bouncy.

Some info on how the system works:

Every 5 milliseconds a new goal position is calculated for all servos.
The profile acceleration is set to 0
The profile velocity is set to 5ms

-Position control mode
Position P gain = 700
Position I gain = 0
Position D gain = 500;

-Current based position control mode
Position P gain = 800
Position I gain = 0
Position D gain = 4000; (default value when you change the servos to current based position control)

The goal current is set to 2000mA (around max current for this servo) for now.

I assumed that this is basically telling the servo to work in position control mode with access to the full torque to reach its goal position if needed.

Does anybody have any idea why the robot walks fine in default position control but starts to bounce/shake when I switch to current based position control with a fixed goal current?

I also tested the robot with the same PID parameters as in position control but I cannot seem to tune the PID gaits to reach a stable result.

I hope someone can help me further since the current based position control really looks like the next step to make the robot react to the ground/objects it steps on.


In current based position mode the actuators will do their best to maintain the specified goal position after arriving there. It sounds like the motion of the quadruped is resulting in the compliant legs moving out of the goal position, then the servos are quickly “Springing” back to the specified goal, resulting in sudden motion that again pushes them out of the new goal position starting the cycle again and resulting in bouncy movement.

Without seeing footage of what the motion looks like and logs of the actuator’s outputs, that’s the best guess I can give about what’s going on.

Resolving it might be as easy as tuning down the P gain and adjusting the goal torque, but an optimal solution would likely require some on-the-fly adjustment of the goal position and goal torque to compensate for uneven terrain and reduce springback.

In my experience with the XL-430s, the 5 ms between Goal Positions may be too short. Can you live with 10 ms?


Ty for the fast responses.


I played around with one servo in the dynamixel wizard today and thats indeed what seems to happen. Every time the goal position reaches its goal the spring effect occured.
Since I change the goal position every 5ms I got this spring effect every 5ms.

It suprises me that this happens in the current based postion control and not in default position control.

I could improve the behaviour alot by the combination of:
-Estimate and update the goal current every timestep.
-Tuning down the P-Gain.

The robot still acts alot more bouncy when its legs land on the ground compared to the default position control but I can work on that.

Changing the timestep did not do alot for me, I tried 10ms and 20ms but could not really see a difference.


I just reread your system settings, and I saw that you set Profile Acceleration to 0. This indicates Infinite Acceleration Time (i.e., a Pulse).

Can you try 1 (= 1 ms) for Profile Acceleration to see if that helps?


I experimented with different profile accelerations but did not see huge differences.

What is in fact the best approach with a dynamixel servo to follow a trajectory as accurate as possible.

Lets say you want that the servo follows a sinusoidal trajectory every 200ms.

Profile velocity = 5ms
Profile acceleration = 1ms
Goal position update every 5ms

Assume that the servo is capable of reaching the goal position in time during this timestep and has to start from 0 speed.

Once I update the goal position, the servo accelerates for 1 ms, stays 3ms at the desired velocity and then deaccelerates for 1 ms, this leads to a fully stopped motor.
Next timestep the process is repeated until all 40 points are parsed.

Should I infact not change the
Profile velocity = 6ms
Profile acceleration = 1ms
Goal position every 5ms

Once I update the goal position, the servo accelerates for 1 ms, stays 4ms at the desired velocity, the servo has not reached its goal position yet so the motor is still at the desired velocity for this timestep.
The second goal position update starts and the servo accelerates/deaccelerates to the new velocity and automatically corrects the fact that the last goal position was not reached by moving a bit faster, this way the motor never stops during the full trajectory and will only have a small delay in reaching the final point in the trajectory.

Is this a correct assumption?



Your assumption about the behavior of time based profiles is mostly correct, save for your assumption that the servo “automatically corrects the fact that the last goal position was not reached by moving a bit faster.”

Once you send an updated goal position, the servo simply discards it’s previous profile and generates a new one based on it’s current state and the new goal position. Whether or not the previous goal was reached before the position update doesn’t affect the new trajectory.

Sending continuous updates to the goal position will still result in smooth motion though, as the new profile generated will take into account the current moving velocity.