Open PRAN384 opened 1 month ago
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?
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
Hi @robbiefish and @vinnnyr. Thank you for the solutions. I have tried all the three but no luck. Here are my findings:
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.
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.
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!
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?
Hi @robbiefish , yes I agree. I can now confirm that this is the case. This is perfect. Thank you and @vinnnyr for the help!
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:
Please help as my application is very sensitive to high jitter.