Incomplete Time Stamp Generated With Euclid IMU

[yzhao23]

Hi,

I was trying to set up a visual inertial SLAM on Intel Euclid. The fisheye camera seems to working perfectly; however, some wired issue happened to the IMU module. The time stamp I got from rostopic /camera/imu/data_raw being incomplete: the secs of all records are always 0, while the nano second readings seem to be proper:

I am using the default scenario "camera" and the default lr200 launch file. I wonder what could be the issue that leads to incomplete IMU info? Any comments or suggestions are appreciated

[Meitav_K_Intel]

Hi yipuzhao,

It's working correctly. When we implemented the rosnode that broadcasts the IMU, we did not separate the time field to seconds and nano seconds.

I will admit that it's not as intuitive, but the reason behind this is that our SLAM implementation accepts this format of data. You can make a simple rosnode to divide the nsecs field by 10^6 and recover the seconds field.

Hope that answers your question.

Happy new year!

Meitav

Intel Euclid Development Team

[yzhao23]

Hi Meitav,

Thank you for the help. Now I got both secs and nsecs field for the Imu message.

However, when I print out the camera_info from fisheye side by side with the converted Imu info, I notice difference in the timestamp of these two sensors.

The easiest fix of course is to deduct the constant difference between timestamps from two sensors. But I wonder if there's a better way to do the job?

Fisheye timestamp = 1514520124.489182832

Imu timestamp = 395.874174

[Meitav_K_Intel]

Hi yipuzhao,

Their timestamps should be on the same timeline. The IMU should have a timestamp field with the correct timestamp.

If you do need to sync timestamps, the best way to do it would be to collect a few matching samples and calculate the difference, then average it out for a single "clock sync" (also make sure that you are sampling two devices that are working at the same frequency, the IMU and fisheye, for example, do not operate at the same one). It is best practice to do a clock sync every one second or so, to accommodate for clock drift.

Let me know how it goes,

Meitav

Intel Euclid Development Team

[yzhao23]

Hi Meitav,

Yes it is possible to estimate the time difference between two modules on my own.

But I assume there should be some more sound fix, since the intel in-build SLAM is also taking both IMU and fisheye as input.

Yet one thing I noticed is that, the fisheye timestamp is epoch/unix timestamp, while the IMU timestamp starts from 0 when the Euclid is on.

After digging into the repo of general realsense, I noticed that there is a fix available:

https://github.com/intel-ros/realsense/pull/175 Start IMU in startCamera by mkhansen-intel · Pull Request # 175 · intel-ros/realsense · GitHub

Now the question is, can one build realsense lib from source on Euclid? Correct me if I were wrong, but I had the impression that most ros lib were locked in Euclid.

Thanks,

Yipu

[Meitav_K_Intel]

Hi yipuzhao,

I'm saying that the timestamps are already synced to the same timeline. I believe you are reading one of them from the wrong place. I don't think any fix is necessary for you to get it working.

As for building librealsense, it's complicated - the code there belongs to a newer model (the D435), so it will not be compatible with Euclid. There is a branch that works with the Euclid that you can clone and build yourself.

May I ask how you got the timestamps from each of the topics (IMU and Fisheye)?

Cheers,

Meitav

Intel Euclid Development Team

[yzhao23]

Hi Meitav,

Thank you again for the help. I took the fisheye info from topic camera/fisheye/camera_info, while imu info is from /camera/imu/data_raw.

Am I supposed to use other topics?

Thanks,

Yipu

[Meitav_K_Intel]

Hi Yipu,

Yes, you should be reading the timestamp from /camera/fisheye/image_raw.

It is an image msg type, which has the correct timestamp on it. That's the topic that is being used in the Intel SLAM.

Let me know if this solves your problem,

Meitav

Intel Euclid Development Team

[yzhao23]

Hi Meitav,

Thank you for the advice. Unfortunately I don't think it resolves my issue: the timestamp I got from fisheye/image_raw is still epoch/unix timestamp.

I attached two screenshots regarding the timestamp I got. The latest record of IMU reads 386395521, i.e. 386.395521 sec; while the latest record of fisheye reads 1514520114 sec 723640939 nesc.

So, there is roughly about a difference of 1514519728 sec, which I suspect is the epoch timestamp I started my Euclid (this is further confirmed by trying with rosbag recorded at different dates).

This problem is really annoying, since it stops me from testing any visual inertial odometry / SLAM on the device. Appreciate any comments from you!

rostopic echo /camera/imu/data_raw/header

rostopic echo /camera/fisheye/image_raw/header

[Meitav_K_Intel]

Hi Yipu,

You got me - while the topics should be synced, I can't seem to find the right topic to show the correct timestamps.

I'm going to try and consult with one of the other developers. I can guarantee you that there's a topic with synced timestamps.

In the meantime, what kind of SLAM are you trying to run? I have published guides for running some of the more popular implementations in our community website.

Meitav

Intel Euclid Development Team

[yzhao23]

Hi Meitav,

I appreciate the help a lot!

Since the build-in 6DoF tracking of Euclid is utilizing both visual and inertial data, I guess it's more or less an issue of topic broadcasting. But yes, definitely let me know if you got any information regarding it

I had no trouble following the VSLAM tutorials from the forum; it's just the inertial part that bothers me a lot, since ultimately I wish to test visual inertial pipeline on Euclid.

Again, thank you for the help!

Yipu

[yzhao23]

Hi Meitav,

Any luck on this issue?

Thanks,

Yipu

[Meitav_K_Intel]

Hi Yipu,

I found the "issue". The IMU is being timestamped by the motion module's controller. The fisheye doesn't use these timestamps and instead receives ros::time:now().

The controller can't timestamp any of the cameras except for the fisheye, so the best fix would probably be to timestamp the imu with ros::time::now().

I'm going to try and test if timestamping the IMU with ros::time::now() yields no errors for the other Euclid features and scenarios, and when I do I will be releasing a fix.

Cheers,

Meitav

Intel Euclid Development Team

[yzhao23]

Hi Meitav,

Awesome! Looking forward to the fix then

Thanks,

Yipu

[Meitav_K_Intel]

Hi Yipu,

After further research, we've determined that changing this behavior will be more complex than what I described, and will impact many of the Euclid's features.

This means that at this time, it's not going to be feasible for us to prioritize this. Your best option would be to write your own clock syncing node for your use.

Thank you for your understanding,

Meitav

Intel Euclid Development Team