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

High IMU Jitter with ROS2 #357

Open
PRAN384 opened this issue Oct 10, 2024 · 6 comments
Open

High IMU Jitter with ROS2 #357

PRAN384 opened this issue Oct 10, 2024 · 6 comments
Labels
bug Something isn't working Stale This issue has been inactive for 2 weeks

Comments

@PRAN384
Copy link

PRAN384 commented Oct 10, 2024

Describe the bug
I am experiencing high jitter while using the GV7 AHRS IMU. Although I have tried various data rates, the jitter remains an issue. However, I did observe that the jitter appears to be less pronounced at 1000Hz compared to lower rates. I have experimented with settings like device timestamps and ROS2 timestamps, but the problem persists.

To Reproduce
Steps to reproduce the behaviour:

Launch the IMU node with command ros2 launch with the provided config.yaml file
Set data rate to 200Hz (also tested with 1000Hz).
Observe the output for jitter.

Expected behavior
The IMU data should be stable and without significant jitter across different data rates and configuration settings.

OS: Ubuntu 22
Architecture: ARM64, x86
ROS Version: Humble
Version: 4.3.0
Sensor(s): Microstrain GV7 AHRS IMU
Modifications
No source code modifications were made.

Launch Parameters
Please find the custom_imu.yml.txt file attached here:
custom_imu.yaml.txt

Attaching data rate plots for different settings:

200hz
1000hz

Please help as my application is very sensitive to high jitter.

@PRAN384 PRAN384 added the bug Something isn't working label Oct 10, 2024
@github-actions github-actions bot added the New This issue is new, and should not be marked as stale label Oct 10, 2024
@vinnnyr
Copy link

vinnnyr commented Nov 7, 2024

At rates that high, I would also try to tune at the DDS layer. What RMW implementation, what QoS is your publisher (driver) and subscriber?

@robbiefish
Copy link

Hi @PRAN384, the comment left by @vinnnyr is a good one as DDS tuning can certainly help with timestamp jitter, which I believe is what you are showing. However, the problem you are seeing is also caused by the way that USB data gets read by our devices.

One option would be to connect the device over serial, which should result in more consistent DTs assuming you can run at a high enough baudrate.

If you want to continue using USB, we have added the timestamp_source parameter in the most recent release which should help with this problem. I think that either option 1 or 2 would help with your problem

@robbiefish robbiefish removed the New This issue is new, and should not be marked as stale label Nov 7, 2024
@PRAN384
Copy link
Author

PRAN384 commented Nov 19, 2024

Hi @robbiefish and @vinnnyr. Thank you for the solutions. I have tried all the three but no luck. Here are my findings:

  1. DDS Tuning: I am using FastRTPS as the middleware and tried a custom DDS profile for low latency publishing. However it had no effect on the jitter.

  2. timestamp_source: I have tried all the possible arguments for this param. Argument 1 (device timestamps) seems to be performing the best. I just get some outliers which are responsible for the bad jitter. The outliers decrease as the frequency is increase to 1000.

  3. Serial Port Connection: I am trying to get the serial reading working using UART pins on a Jetson Orin. The ROS2 node is unable to open the the port with any baud rate settings and exits. I wrote a python script to open the serial port and read data directly. It does output data but it doesn't match the MIP structure. Here is an example of the data that I am reading data.txt

I tried the same script with the USB connection and everything seems fine. I have also tested the UART port on the PC in isolation(loop-back test: Writing data to TX and reading the RX of the device) and it passed.

Please recommend a possible solution.

Thank you in advance!

@robbiefish
Copy link

I have taken a look at dts in the message timestamps when using timestamp_source: 1 (device timestamp) at 100 hertz, and I see an average dt of around 0.01 seconds +/- 0.3 microseconds. I would expect you to see something similar when running your tests as the timestamps are coming directly from the device.

How are you measuring the dts? Are you looking at the timestamp in the header, or the time at which you receive the ROS messages?

@PRAN384
Copy link
Author

PRAN384 commented Nov 24, 2024

Hi @robbiefish , yes I agree. I can now confirm that this is the case. This is perfect. Thank you and @vinnnyr for the help!

Copy link

This issue is stale because it has been open for 2 weeks with no activity. If the issue is still not resolved, please leave a comment describing what is still not working

@github-actions github-actions bot added the Stale This issue has been inactive for 2 weeks label Dec 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working Stale This issue has been inactive for 2 weeks
Projects
None yet
Development

No branches or pull requests

3 participants