Realsense-ros: D435i: IMU timestamps are repeating

[mfehr]

Hi all,

A while ago I opened an issue about uniting the imu messages, including a hacky fix how I managed to fix it, at least for my datasets: #544. Today I wanted to try the sensor again, and since I noticed that the feature of uniting the imu messages has been added to the repo now, I switched back to the development branch.

However I couldn't get our VIO to run on the sensor anymore. When I had a closer look at the IMU data i noticed that the timestamps of the IMU are broken and it looks like they are repeating/cycling through the same range (?). Here is a plot of the IMU timestamps:

So I switched back to my branch that worked last time, but kept librealsense the same and the issue was there as well. So I guess it's a problem of librealsense?

Does anyone else see this issue?

Any help on how to fix it or which version of librealsense/realsense provides working IMU messages would be appreciated. Thanks!

Info:

• I used the rs_rgbd.launch file and only added <arg name="unite_imu_method" value="linear_interpolation"/>
• ROS melodic, Ubuntu 18.04
• branch: development

[KitKat7]

@mfehr I met the same problem in Ubuntu 18.04, with librealsense2 the version 2.19.2 and the development branch (https://github.com/intel-ros/realsense/commit/eea5b1592d6889817c500b22179c1fe1da60cde4).

It seems that the timestamps of the default IMU outputs without unite_imu_method are also repeated.

Did you have any updates about this problem?

[mfehr]

I managed to get it working again, by setting librealsense to one specific version and realsense to another + replacing the official unite imu logic with my own hacky version again. The new (linear interpolation) unite imu logic didn't work with maplab for me and when I checked at what frequently the united msgs are published it I noticed that the 450hz gyro signal and the 250 hz accel signal were combined into a 490hz signal. So it's probably trying to interpolate both the slow onto the fast and the fast onto to slow signal. My logic only does fast to slow interpolation.

I created a repo with these specific branches of the realsense repos as submodules and some documentation so that we have a version that works with maplab and it is easy to find and install. I made it public just now:

https://github.com/ethz-asl/realsense_D435i

[KitKat7]

Thanks @mfehr. I've tried your ROS wrraper with librealsense version 2.19.1. It works!

[doronhi]

@mfehr , what firmware are you using? what is the scale of x-axis in your graph?
Just making sure - The new realsense2_camera (what version) with librealsense 2.19.1 also didn't work for you? What was the problem in that case?

[mfehr]

@doronhi don't know the firmware version, I can check, but I don't have the sensor atm. The plot is timestamp [s] vs message number from a short rosbag I recorded. When I reported this issue, I did a fresh install of librealsense and realsense2_camera both on the development branch, didn't work (that's where the plot is from), then tried the realsense2_camera version I was using before (December 18 version, I think), also didn't work. Then after a quick look at the new imu unite logic (linear interpolation) I decided to check out the latest tagged release of both librealsense and realsense2_camera and re-integrate my alternate unite imu logic (version and changes are described in the meta repo I shared). That worked, but I can't say for sure if was just the right combination of releases or whether my changes had any effect on it. I mainly switched to the other unite imu logic, because I thought it was weird that the united imu message has a higher frequency than the individual signals and I didn't have time to debug/investigate :) Did you do a check on you side if the IMU timestamps with the most recent branches?

Maybe a bit off topic: With the version I linked above I can run maplab (VIO) quite ok, it is not super stable though and when I'm calibrating the sensor with kalibr, the IMU errors/biases are looking unhealthy. I used the official realsense imu calibration tool and also tried calibrating IMU intrinsics with kalibr, but didn't help. So I'm still not sure whether there is a flaw in my imu unite logic, my calibration skills, the ros wrapper, librealsense or it's just the limit of the BMI055. So if anyone has ideas or a good source for IMU sigmas for the BMI055, I'm all ears.

[doronhi]

Apparently there is a issue concerning the timestamps of the IMU in librealsense since v2.19.2.
Work is in progress.

[doronhi]

A bug was fixed in librealsense. It is merged but not yet released. It involved IMU timestamps in Linux.
If in hurry, you can check out the master branch of librealsense

[mfehr]

Thx @doronhi, I quickly checked but couldn't find a matching PR, would it make sense to link the PR here?

[mfehr]

@doronhi I tested it using rs_camera.launch with linear_interpolation enabled for the imu.

• librealsense master branch + realsense 2.2.3 -> bug still there
• librealsense development branch + realsense 2.2.3 -> timestamp bug is fixed
  Thanks, as far as I'm concerned this issue can be closed.

[doronhi]

You are right, my bad. This is the link to the PR: https://github.com/IntelRealSense/librealsense/pull/3726
Glad it worked out for you :)

[bednarhonza]

Thank you, I face the same problem, I tried to compile the development and it worked just fine. Do you know, when it will be released?

[doronhi]

Hopefully early next week.