[CLOSED] D435i IMU - Gyroscope - non symmetrical behaviour
Introduction
Dear all,
We have a D435i camera on our 2D mobile robot in order to improve the orientation estimation of the system. Data are streamed with a C-USB cable (3.1) within the ROS2 (humble) framework (therefore, we are using librealsense-ros).
As starting point, we are trying to achieve the best possible outcome with only gyroscope before to fuse with wheel encoders.
Problem description
We noticed that we get different results (orientation estimation) depending on which verse the robots turns: specifically, we get a worse performance when robot is turning clockwise with respect to counterclockwise movements. This result seems does not depend on
- the applied method (like simple integration or Kalman);
- if the IMU is calibrated or not.
We are probably missing something. Do you have any suggestions? Please, feel free to ask if you need more details on our set-up.
Side notes
- This scenario has been observed on 2 / 3 cameras we tried so far.
- Cameras have the latest firmware.
-
Hi Fulvio Diluzio RealSense cameras equipped with an IMU can use a Python-based tool to calibrate the IMU by proceeding through a six stage process where the camera is placed in different rotational orientations, such as straight ahead and 90 degrees on its side.
IMU calibration tool
https://github.com/IntelRealSense/librealsense/tree/master/tools/rs-imu-calibration
Documentation
https://dev.intelrealsense.com/docs/imu-calibration-tool-for-intel-realsense-depth-camera
-
Is the orientation rendered accurately when turning clockwise if you run the RealSense SDK official IMU example program rs-motion
https://github.com/IntelRealSense/librealsense/tree/master/examples/motion
-
A RealSense team member explains the lack of extractable yaw angles here:
https://github.com/IntelRealSense/librealsense/issues/4391#issuecomment-510369366
It is known that the IMU can lose tracking if the camera turns too sharply. As far as I am aware there have not been previous reports of problems related to turning in one particular direction though.
-
Dear MartyG,
That is in line with my previous post. Here the problem is not the ability or not to correct yaw, but having consistent measurements.
By the way, robot maximum angular velocity is 0.7 rad/s (~40 deg/s) which is far lower than the available range, and that velocity is reached with a low angular acceleration for the purpose of avoiding sharp movements.
-
At the link below a RealSense team member advises that you may be able to do without wheel encoders if the ground that the robot is traveling on is stable and there is not high vibration.
https://github.com/IntelRealSense/librealsense/issues/5555#issuecomment-572175625
Though the comment refers to the RealSense T265 Tracking Camera model, T265 used the same IMU as the D435i.
-
In the #4391 GitHub case that I linked to earlier, the RealSense team member handling that case said to that case's RealSense user, "It seem that the gyro is not working properly. With gyro streaming normally there should be no issue of tracking left / right. Actually gyro has no notion of "left / right" it just tracks attitude in 3D inertial frame".
https://github.com/IntelRealSense/librealsense/issues/4391#issuecomment-527190133
So there should not be a difference between turning clockwise and turning anti-clockwise if the gyro does not know the difference between left and right.
Of the set of three cameras, is the one that turns clockwise correctly newer than the other two cameras? After early 2022, RealSense cameras changed their IMU component from the 'BMI055' to the similar 'BMI085' component that had a default minimum accel speed of 100 instead of the 63 that the BMI055-equipped units had.
-
Dear MartyG,
We put the camera on a platform to make it not perceive vibration but no improvement has been observed. Furthermore, probably due to the default sensitivity, the slower the robot rotates the worse becomes the sensed angular velocity of the IMU (probably due to signal-strenght/noise ratio). Therefore, we currently decided to suspend (not definitely at least) any development on this camera with integrated IMU.
I kindly thank you for your support and all the time spent for this argument.
I am going to mark this post as closed.
Please sign in to leave a comment.
Comments
13 comments