image/IMU relative and absolute timestamp issues

[protobits]

When recording to a rosbag a stream of camera and IMU messages I see two issues. First: with respect to current time (ros::Time::now()) messages appear future dated by some small ammount. Second: IMU messages arrive in batches surrounding the image message, and have timestamps which are before the image. In other words, the IMU messages appear to be delayed considerably.
While the first issue may not be as problematic, the second one means that if indeed IMU messages are delayed (and it is not a timestamping problem), the IMU cannot be reliably used to predict the camera motion from last frame to the current frame.

Given that mynteye obtains readings timestamped with a hardware clocked, it would be expected that sensor readings are emitted with appropriate relative order as well as absolute timestamp.

As an example, here's a short (zipped) rosbag (no restamping applied) where you can inspect the relative and absolute timestamps: 2019-03-22-10-53-51.zip

Possibly related issues: #24 #39 #25

[joinAero]

The image timestamp of camera (S1030) is using the end of exposure time now. And IMU datas are collected during the exposure.

Our developers are testing the image timestamp using the center of exposure time. Will release new firmware after test pass.

Now, you could get image exposure time in ROS wrapper as below.

#include "mynteye/device/utils.h"
mynteye::utils::get_real_exposure_time(params.framerate, data.img->exposure_time);

And adjust the image timestamp data.img->timestamp with this exposure time.

[protobits]

Thank you! I will test compensating for exposure time. I assume that if I substract exposure time to image timestamp I should o obtain IMU measurements after this timestamp.

[protobits]

I tried this approach and it seems that all IMU measurements (which arrive just after an image arrives) correspond to previous image interval. In other words: all imu measurements received just after an image have timestamps from before the image. I'm not sure if this is due to the ROS layer or the driver layer but I guess I will have to deal with it myself and buffer images to ensure proper ordering.

[protobits]

I've upgraded to firmware 2.3.0. Does this firmware now uses center of exposure time or is it sill the beggining? Please let me know so I compensate correctly.