Integrate DCM Estimator

[mmurooka]

This PR allows BWC to compensate for the DCM bias estimated by the LipmDcmEstimator

In the video below, the JVRC1 controller model (URDF) is not modified, but only the simulation model (VRML) is mass offset in the lateral direction. Only when the DCM estimator is enabled and the bias is removed, the robot is stable in stepping.

https://github.com/isri-aist/BaselineWalkingController/assets/6636600/032ddff6-8f94-4293-8983-5f32cccc7d40

[mehdi-benallegue]

That is great! I hope it helps,

I have two remarks:

• Less important In the simulation video, we can see that the bias in y-axis saturates, I think you have added too much mass or not enough bias limit for the estimator to properly estimate the bias and it would be even more stable. I am wondering if we should not run an unconstrained estimator in parallel just to see how much it is bigger than the limit (I don't recommend to use an unconstrained one and clamp the output, because it would be slow at coming back to zero if the bias was caused by a disturbance).

• Very important It seems you did not integrate the correction of CoM position implemented here in the lipm stabilizer https://github.com/jrl-umi3218/mc_rtc/blob/418f74fac4e8e14331db105727ce666a18cba603/src/mc_tasks/lipm_stabilizer/StabilizerTask.cpp#L873-L883

In the case the bias on the DCM comes from a bias in the CoM (which is most often the case) you will have a static error in the tracking of the ZMP and CoM positions. Is there a reason you did not report this part?

[mmurooka]

Thank you for your comment @mehdi-benallegue

As for saturation due to the bias estimation limit, that is indeed what is happening in the video above, but I had a more thorough verification on my side and confirmed that it appears even more stable in the absence of saturation.

Regarding the reflection of the estimated bias in the CoM measurements, it was not necessarily required since my control does not explicitly use the CoM measurements in the control in the subsequent blocks. However, there was a possibility to use CoM measurements in some cases, so I made a small correction in the commit above.