Floating base estimation for Inverse Kinematics

[RVSagar]

Hi @stephane-caron,

Firstly, thanks for maintaining this nice repo and especially for answering everyone's questions, it's helped me clarify many concepts and learn a lot!

In Figure 2 of your manuscript, I saw that the floating base is updated from real robot measurements in the DCM observer (as you also explained here) but I was wondering whether any of this information (floating base position/orientation or joint states) is fed into the Inverse Kinematics block?

The IK QP is solved in mc_rtc (if I'm not mistaken), so I guess I'm asking, does the IK run in "closed-loop", taking into account the robot's current state from sensor readings?

Thanks so much for your time!

[stephane-caron]

In this controller we maintain two robot states:

• Real: the real robot state is used for e.g. CoM measurements and updated when we call updateRealFromKinematics, but it is not the one the inverse kinematics runs on.
• Control: the control robot state is the one updated by mc_rtc after the end of the call to Controller:run, i.e. that is the state the inverse kinematics runs on.

Since we don't update the configuration of the control state from measurements, the inverse kinematics runs "open loop", in the sense that for instance its floating base transform is updated by forward integration rather than read from measurements. This doesn't mean however that the IK is independent from sensor readings, since we do whole-body admittance control (force readings change IK targets).

For example, in the Standing the plank experiment with HRP-4 we can see the robot leaning forward/backward in response to terrain orientation changes: if we look at the control robot state while this happens, what changes are the feet orientations (foot damping control) and leg retractions (foot force difference control) in response to force readings, not the floating base orientation. This is somehow counter-intuitive when we look at the robot's behavior, but that's how this controller works 😄 I don't have a side-by-side video to illustrate this, but you can play with it by e.g. running the Docker image and pushing the robot around in Choreonoid. The state that you will see in RViz is the control robot state, look at how it changes upon various pushes.

Plagiating Pascal: please forgive this long answer; I didn’t have time to write a short one 😉

[RVSagar]

Thanks for clarifying! I'm sure many people (including myself) appreciate your verbose/insightful explanations :)

I imagine there might be certain scenarios (large pushes, fast inclination changes etc.) that might make the "control state" diverge from the "real robot state"? Nonetheless, this controller seems to work well.

As an aside, I have an NVIDIA graphics card in my computer and was having some troubles running the Docker (related to the rviz GUI crashing). I use Docker/NVIDIA with other ROS-based images (Gazebo/rviz) so I'll take a look at debugging, maybe it's just a driver issue. Do you use an NVIDIA card with this image? Sorry I don't have the error/crash messages I was receiving, I'll update if I get back to my computer later.

Thanks again!

[stephane-caron]

Hmm, my graphics card when I prepared the Docker image in 2019 was not from NVIDIA.

I'm not an expert in this, but from a quick search it seems you would need to install the NVIDIA driver inside the running container as an extra step to be able to run GUIs. This can be done by updating the docker run command to run just bash instead of lipm_walking --floor, install the driver and configure what should be configured, then call lipm_walking --floor from the command line.

Feel free to open a separate discussion for this if you find a set of working steps. This could be useful to fellow NVIDIA travellers 😃