imu to camera delay
-
I'm currently working on a setup involving the VOXL 2 platform, and I'm observing some unexpectedly large delays between sensor measurements when using the MPA-to-ROS interface.
Specifically, I'm seeing:
350 ms delay between the onboard VOXL 2 IMU readings and the TOF M0178 data.
170 ms delay between the IMU and the IR camera M0166 data.Is there any known filtering, buffering, or image preprocessing occurring on the TOF M0178 or IR camera M0166 streams that might account for the latency?
What else can cause such latency on my setup?
Thanks in advance, -
I'm currently working on a setup involving the VOXL 2 platform, and I'm observing some unexpectedly large delays between sensor measurements when using the MPA-to-ROS interface.
Specifically, I'm seeing:
350 ms delay between the onboard VOXL 2 IMU readings and the TOF M0178 data.
170 ms delay between the IMU and the IR camera M0166 data.Is there any known filtering, buffering, or image preprocessing occurring on the TOF M0178 or IR camera M0166 streams that might account for the latency?
What else can cause such latency on my setup?
Thanks in advance,@yardy , can you please clarify how you are measuring the latency?
voxl-camera-serversends out TOF data without delay (after performing required processing to generate the depth data) andvoxl-imu-serversends out IMU data in batches, depending on the settings invoxl-imu-server.conf. However, there should not be delay of such magnitude at the MPA pipe level.It is possible that the data gets backed up in mpa-to-ros application, we can figure it out if you let me know how you are measuring the latency.
Alex
-
@yardy , can you please clarify how you are measuring the latency?
voxl-camera-serversends out TOF data without delay (after performing required processing to generate the depth data) andvoxl-imu-serversends out IMU data in batches, depending on the settings invoxl-imu-server.conf. However, there should not be delay of such magnitude at the MPA pipe level.It is possible that the data gets backed up in mpa-to-ros application, we can figure it out if you let me know how you are measuring the latency.
Alex
@Alex-Kushleyev
Thanks for replying.temporal alignment between the IMU signal and the camera motion, extracted using a calibration target. The IMU and the camera were rigidly attached and moved together as a single unit during the test.
B.R
-
@Alex-Kushleyev
Thanks for replying.temporal alignment between the IMU signal and the camera motion, extracted using a calibration target. The IMU and the camera were rigidly attached and moved together as a single unit during the test.
B.R
@yardy , i understand. Which timestamps are you looking at after temporal alignment? Are those timestamps of ros packets being received or timestamps within the packets themselves?
-
@yardy , i understand. Which timestamps are you looking at after temporal alignment? Are those timestamps of ros packets being received or timestamps within the packets themselves?
Hi @Alex-Kushleyev,
The results I shared earlier are based on the difference between the internal header timestamps of both sensors.
Also, we measured a delay of approximately 50 ms between the internal header timestamp and the ROS message timestamp for the camera, and about 30 ms for the IMU.
-
Hi @Alex-Kushleyev,
The results I shared earlier are based on the difference between the internal header timestamps of both sensors.
Also, we measured a delay of approximately 50 ms between the internal header timestamp and the ROS message timestamp for the camera, and about 30 ms for the IMU.
@yardy ,
looking at mpa to ros code..
The timestamps for the message headers are assigned here :
So the timestamps should be correctly converted to ROS time and not susceptible to any delays in the mpa to ros conversion.
Are you logging the ros messages using
rosbag recordand analyzing them offline? Make sure that you are not using thebagtimestamp for that.Alex
-
@yardy ,
looking at mpa to ros code..
The timestamps for the message headers are assigned here :
So the timestamps should be correctly converted to ROS time and not susceptible to any delays in the mpa to ros conversion.
Are you logging the ros messages using
rosbag recordand analyzing them offline? Make sure that you are not using thebagtimestamp for that.Alex
This post is deleted! -
@yardy ,
looking at mpa to ros code..
The timestamps for the message headers are assigned here :
So the timestamps should be correctly converted to ROS time and not susceptible to any delays in the mpa to ros conversion.
Are you logging the ros messages using
rosbag recordand analyzing them offline? Make sure that you are not using thebagtimestamp for that.Alex
@Alex-Kushleyev We found out that we didnt take into account the phase difference when comparing angular rate to angle. Thanks and sorry for the confusion.
-
@Alex-Kushleyev We found out that we didnt take into account the phase difference when comparing angular rate to angle. Thanks and sorry for the confusion.
@yardy , ah, that makes sense!! thank you for clarying.
Alex
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login