- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Meitav,
Awesome! Looking forward to the fix then
Thanks,
Yipu
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page