-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
D435i IMU recording at inconsistent rate #11987
Comments
Hi @ryanalex98 Setting unite_imu_method to 'copy' instead of 'linear_interpolation' may provide more stable IMU data. This can be done by including the command unite_imu_method:=copy in your roslaunch instruction. As well as setting global time to false, you could also try setting enable_sync to true with the roslaunch command enable_sync:=true if you have not done so already. When true, it gathers the closest frames of different sensors to be sent with the same timetag. I note that you are using camera firmware driver version 5.15.0.2 in your camera. This is the recommended firmware for librealsense 2.54.1 and using it with older SDK versions such as 2.50.0 may cause errors. The recommended firmware version for use with 2.50.0 is 5.13.0.50. |
Thanks for the quick reply @MartyG-RealSense. I updated the launch file with the unite_imu_method set to copy and launched with the following args:
Still getting curious output behavior: I think I have the versions aligned, I'm using sdk v2.54.1.0 and firmware v5.15.0.2, which I believe are the most recent release pair? To give some context, I am using this for a VIO application, which necessitates a high level of consistency from the IMU readings. Thanks for your help. |
Thanks very much for the update. Yes, SDK 2.54.1 and firmware 5.15.0.2 are the correct pairing. If you are using ROS1 Noetic though then the ideal configuration would be SDK 2.51.1, ROS wrapper 2.3.2 and firmware 5.13.0.50. This is because development of the ROS1 wrapper has ceased and so it has not been updated for compatibility with librealsense versions newer than 2.51.1. IntelRealSense/realsense-ros#898 is an interesting discussion about IMU data stability and the importance of it for VIO, which led to the original creation of the 'copy' mode of unite_imu_method to provide additional IMU data stability. Raw RealSense IMU data is inherently 'noisy'. One RealSense ROS user decided to use a high-quality external IMU instead of the camera's built-in one for their IMU topic's data. |
Hi @ryanalex98 Do you require further assistance with this case, please? Thanks! |
Case closed due to no further comments received. |
Issue Description
Hi there, I am currently using a D435i camera and attempting to record some IMU data. However, when I record data, I am noticing a very inconsistent rate at which the readings are recorded. I have reviewed several issues in this forum to try and alleviate the problem across different product models but nothing seems to work for my case, hence why I am opening my own issue. I will do my best to go through what I've tried thus far.
First attempt: Gyro 400Hz, Accel 250Hz
USB 3.2 cable, port.
Launch file:
imu_recording.txt
Command line output
Rosbag investigation:
As you can see, the timestamps are consistently inconsistent, with drops occurring around every second.
Second attempt with camera enabled
When I enable the infra1 and infra2 cameras at 30Hz (640x480), I get the following output:
On the surface this output looks correct, but it should be operating at 400Hz, or every 0.0025 seconds. Instead, its alternating between producing a single message and then a couplet of two messages roughly every 0.0037 seconds. So on average, it produces three messages every 0.0075 seconds which lines up with 400Hz - the distribution of the messages is the problem.
Issues I referenced while attempting debug:
I tried decreasing the rates to 200Hz (Gyro) and 63Hz (Accel), but this didn't help. I also toggled global_time_enabled:=false (and true), neither of which solved the issue.
Please let me know if there is any more information I can provide in resolving this case. Thank you very much!
The text was updated successfully, but these errors were encountered: