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

[Story] - IMU - Get correct orientation for every robots #1246

Closed
HPezz opened this issue Jan 10, 2023 · 0 comments · Fixed by #1314
Closed

[Story] - IMU - Get correct orientation for every robots #1246

HPezz opened this issue Jan 10, 2023 · 0 comments · Fixed by #1314
Assignees
Labels
01 - type: story Clear roadmap to implement a new feature, refactor code, etc.
Milestone

Comments

@HPezz
Copy link
Contributor

HPezz commented Jan 10, 2023

Description

In order to reach the perfect 1080° rotation, we need to compute correct orientation in each robot.
Currently, there are still singularities between robots which induce a more or less good calculation of the robot orientation. Several improvement tracks have been investigated without real improvements. They are detailed below:

STATIC calibration of the accelerometer and the gyroscope

  • Realization: With an immobile electronic board laid flat, we read the static raw values of the accelerometer and the gyroscope. These values, considered as offsets, are then deducted at the reception of the raw values of the IMU.
  • Consequences :
    ✅ Consequent decrease of the yaw drift: 2° in 5 minutes
    🤕 No visible improvement of the orientation image by Mahony.
  • Going further: A DYNAMIC calibration, realized on a rotation controlled base could calibrate the gyro values dynamically

Dynamic Mahony Sampling delay

  • Realization: Use of two variables whose difference gives the Mahony sampling delay _dt . These 2 variables are updated (now()) respectively before the computation of _dt and at the end of the computation of the orientation :
    rtos::Kernel::Clock::time_point _last_time_point {};
    rtos::Kernel::Clock::time_point _current_time_point {};
  • Observations:
    _dt very constant on most robots ( = _delay + 2 ms of the imukit)
    Can sometimes (1/20) increase from 2 to 10 ms in context of use with video and leds
  • Consequences :
    🤕 Low or even improved feedback facing the user.
    ❌ Number of turns between 1 and 3 (while fixed at 2)
  • Going further :
    find a more revealing parameter for the singularities between each robot
    make sure that the tools provided by Mahony are relevant
@HPezz HPezz added the 01 - type: story Clear roadmap to implement a new feature, refactor code, etc. label Jan 10, 2023
@HPezz HPezz added this to the v1.4.0 milestone Jan 10, 2023
@HPezz HPezz linked a pull request Feb 17, 2023 that will close this issue
2 tasks
@HPezz HPezz linked a pull request Mar 6, 2023 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
01 - type: story Clear roadmap to implement a new feature, refactor code, etc.
Projects
None yet
3 participants