Bad joint_states when in Nominal mode

Create issue
Issue #127 invalid
Thomas Koletschka created an issue

Copied from answers.gazebosim, posted by pbeeson:

We have found a bug where if we keep the Atlas robot pinned, that joint_states reported are correct. however, when switched to Nominal mode (the default when launching Atlas in an empty world after 10 seconds or so), that joint_states starts sending incorrect values BUT it seems like the internal joint controller sees the correct values, so any kind of closed loop control cannot be performed correctly.

To Reproduce:

Make a node that can sends a position to the neck joint through /atlas/joint_commands.

Launch atlas and watch /atlas/joint_states/positions[3] (the neck) start at 0, then after the robot becomes unpinned, it goes to -0.05 (or similar). Send the joint_command to ask the neck to return to 0. It doesn't (BECAUSE WE THINK IT BELIEVE INTERNALLY THAT IT IS ALREADY AT ZERO).

Now, send the service message to repin Atlas, and watch the joint value go back to 0.

While pinned, you can send the neck joint a new position goal, let's say 0.3. It will go there using the PID in the Gazebo plugin. Unpin the robot, and watch the value go to 0.25. So, because the joint_states for (AT LEAST) the neck joint are off by -0.05 radians, any closed loop control gets confused because it's always chasing this offset.

Comments (4)

  1. Patrick Beeson

    Thanks for opening this Thomas. Between the DRC forums, Gazebo Answers, and this, it's hard to keep track of all the places I should be looking for answers to problems.

    I think I figured out the root cause of this. It looks like the neck (at least -- that's what I've been using to easily find and reproduce errors) requires a constant Force of around 1.1 to remain "stable" in Nominal mode. So when Atlas becomes unpinned, it starts with the neck at 0 and the setpoint at 0. Because this results in no force, the neck quickly starts moving negatively (weird since I would think the head would be front heavy) until it stablizes around -0.05 radian with a constant force around 1.1 trying to push it back to 0.

    If then, one sends a joint_command to the neck to go to -0.05 (let's say we are running a continuous controller that tries to keep the neck still), then the position error immediately goes to 0 from 0.05, the derivative goes really largely low, which causes the head to move even further into negative territory. Where again, it settles with a force around 1.1-1.2 which another -0.05 offset (head now at -.1 with set point at -0.05).

    In theory, this steady-state offset can be overcome by the integral controller. However, having to tune the full PID in Nominal mode is nearly impossible, as the robot falls anytime a bad paramter is given. If we do have to tune all PID parameters because of steady state offset, then at least the "pinned mode" have similar steady state offset issues so that we can tune controllers that way.

    Additionally, because of this difference in Nominal versus pinned offset, then there is always a "catchup" period once the robot unpins where the users' controllers have to integrate error over time in order to push the joints back to the original 0 set points.

    Tomorrow I will investigate to see if joints other than neck have noticable differences between pinned and nominal/unpinned joint states.

  2. Patrick Beeson

    At this point, I'd definitely classify this difference in between "pinned" and "nominal" as a bug. At the risk of repeating myself from above, the issue is that in Nominal mode there is a subset of joints that have a steady-state offset (neck_ay is the easiest and most obvious to examine for debugging purposes) and need a non-zero integral gain (jacking up the P only reduces the offset by multiples, but doesn't remove it completely). But, it's impossible to tune a joint because in Nominal mode, without properly tuned joints, the robot falls over after even simple motions (like just lowering or raising the neck joint). In pinned mode, you can isolate and move individual joints with ease in order to tune the PD parts of a controller, but without the steady state offset, you can't tune the I gain, and of course without I gain, it's impossible to prperly stay balanced while tuning in Nominal mode. So we have a bit of a cyclical problem that (in my opinion) can most easily be handled by having a "pinned" mode that acts the same way as nominal mode for all joints, but just with the "hovering" so that is it easy to tun individual joints without having to restart Gazebo because the robot falls over and contacts the ground.

  3. John Hsu

    This is not a problem with joint_state, but an issue on gravity settings for the atlas robot during development.

  4. Log in to comment