Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[attitudeObserver] Add gyro-bias management #17

Open
wants to merge 11 commits into
base: main
Choose a base branch
from

Conversation

mehdi-benallegue
Copy link
Member

@mehdi-benallegue mehdi-benallegue commented Aug 12, 2022

This PR allows to calibrate the gyro bias for attitude esitmation while the controller is running. There are two methods to estimating the bias:
-while the robot is static, the user can compute the average measurement (that should be zero). This is accessible in the GUI of the state observer.
-using the gyro bias estimator embedded in the same Kalman filter used to estimate the attitude. This estimator can also be initialized with the average estimation coming from the first method. This estimator can be activated in the GUI of the state observer too.

This requires this PR
jrl-umi3218/mc_rtc#282

@mehdi-benallegue mehdi-benallegue marked this pull request as ready for review September 2, 2022 06:49
Copy link
Collaborator

@arntanguy arntanguy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the delay.

I just gave this a try, most comments are inline in the code.

Main points:

  • We should check the state-observation minimum version in cmake
  • When I click on EKF bias estimation I get 10e13 bias values and the robot falls immediately
  • Compensate Mode also makes the robot fall
  • I fixed a bug with the gui_helpers in the main branch (0fd1bb4) which fixes the GUI here (rebase needed)

Note to easily test the stabilization failures, you can simply edit <mc_rtc_install_prefix>/lib/mc_controller/etc/LIPMStabilizer.yaml and add the Attitude observer:

ObserverPipelines:
...
- type: Attitude
- type: KinematicInertial

And you can try in choreonoid with any robot and the LIPMStabilizer controller (I only tried HRP2KAI).

Once all issues are resolved here I'll see about integrating the Attitude observer directly in mc_rtc and using it as the default observer.

void switchWithGyroBias(bool);

void setGyroBiasToMeanValue(); /// set the value of the bias to the mean identified value
void startGyroBiasIdentification(); /// start the identification of the bias from the curren gyro readings
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
void startGyroBiasIdentification(); /// start the identification of the bias from the curren gyro readings
void startGyroBiasIdentification(); /// start the identification of the bias from the current gyro readings

@@ -168,7 +168,7 @@ const auto & X_Camera_Object = datastore().call<const sva::PTransformd &>(name_+
## Dependencies

- [gram_savitzky_golay](https://github.com/arntanguy/gram_savitzky_golay)
- [state-observation](https://github.com/jrl-umi3218/state-observation) > 1.3.3
- [state-observation](https://github.com/jrl-umi3218/state-observation) > 1.4.1
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should make this a version requirement in cmake find_package.
While trying this PR locally, I didn't update the state-observation package. Viciously, this builds, but the estimation is nonsense (with the stabilizer just standing, the robot estimate leans backwards and the robot falls forward). I assume this is because of an index mismatch.

Enforcing the minimal version of state-observation would prevent such subtle errors.

Comment on lines 32 to 39
double gyroCovariance = 1e-10;
double orientationAccCov = 0.003;
double linearAccCov = 1e-13;
double biasDriftCov = 1e-10;
double biasInitCov = 1e-7;
double stateCov = 3e-14;
double oriCov = 1e-12;
double stateInitCov = 1e-8;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not directly related to this PR, but I found a bug in gui_helpers (dangling reference making the GUI for these parameters meaningless), fixed by 0fd1bb4. You'll need to rebase to fix the GUI.

Comment on lines +285 to +287
Checkbox(
"EKF bias\nestimation", [this]() { return withGyroBias_; },
[this]() { switchWithGyroBias(!withGyroBias_); }),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There seems to be an issue with the EKF bias estimation. If I switch it on while using the LIPMStabilizer controller (with hrp2), the robot immediately falls down and the gyro bias becomes on the order of 10e13.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably unrelated by Compensate mode also makes the robot fall.

Checkbox(
"EKF bias\nestimation", [this]() { return withGyroBias_; },
[this]() { switchWithGyroBias(!withGyroBias_); }),
Button("Calibrate\nfrom data\n(static robot)",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understood correctly, one needs to manually stop the calibration process? Isn't there a way to automatically detect when calibration is complete?

@mehdi-benallegue
Copy link
Member Author

mehdi-benallegue commented Sep 9, 2022

Thank you very much for your reply and sorry for the delay

Unfortunately, for technical reasons I cannot immediately check the code, but I can reply to some remarks and questions

Note to easily test the stabilization failures, you can simply (...) and the LIPMStabilizer controller (I only tried HRP2KAI).

Thank you, this is actually how I test it too. I used HRP4CR and it worked very well. This is why I am surprised by that:

When I click on EKF bias estimation I get 10e13 bias values and the robot falls immediately

I will test it again ASAP

Compensate Mode also makes the robot fall

Is there anybody currently using the Compensate mode? this feature was implemented to keep the compatibility with regard to the old KF. If nobody use it I think it should be deprecated and eventually removed.

I fixed a bug with the gui_helpers in the main branch ([0fd1bb4](https://github.com/jrl-umi3218/mc_state_observation/commit/0fd1bb4ed37463d762232feef8c0d990130cf2fb)) which fixes the GUI here (rebase needed)

I will check that

Once all issues are resolved here I'll see about integrating the Attitude observer directly in mc_rtc and using it as the default observer.

Sounds nice. I think it deserves to be cleaned up a bit though. I planned to ask Arnaud Demont to work on it to finish it by the end of this year.

@arntanguy
Copy link
Collaborator

I gave this another try today, and it fails as previously reported:

  • As soon as EKF bias estimation is selected in the GUI, the gyro bias diverges and the robot starts spinning around increasingly faster
  • The static gyro bias estimation seems to be working fine, however it would need to be activated from the start, otherwise the initial drift accumulated before its estimation remains forever.

For example on HRP2012c, you can see that it initially drifts (gyro bias not estimated yet), and as soon as I trigger the static estimation of the gyro bias the drifiting rate is reduced (although not completely removed).
bias

Regarding the EFK issue, it is reproducible in choreonoid and can be tested very simply with a posture controller and the observer activated. To do so, put the following in ~/.config/mc_rtc/controllers/Posture.yaml:

ObserverPipelines:
  name: "TestAttitudeBug"
  gui: true
  observers:
    - type: Encoder
    - type: Attitude
    - type: BodySensor

Then run a posture controller

MainRobot: HRP2DRC
Enabled: Posture

Note that this also fails with the JVRC robot.

I've also rebased this branch on master here: https://github.com/arntanguy/mc_state_observation/tree/topic/GyroBias

@mehdi-benallegue Could we look into solving this issue? I'm available to test any solution on the real HRP2012 robot.

@mehdi-benallegue
Copy link
Member Author

mehdi-benallegue commented Jan 26, 2023

Thank you very much @arntanguy to look into that. This is now my main priority.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants