Quantcast
Channel: ROS Answers: Open Source Q&A Forum - RSS feed
Viewing all articles
Browse latest Browse all 475

ROS bag synchronization problem with laser scan messages

$
0
0
I have a raw csv data sequence of laser scans and odometry data. Here are a few data samples: Laser scans: 25 1205853395.41 181 0.5429999828338623 0.5389999747276306 ... 26 1205853395.51 181 0.5450000166893005 0.5429999828338623 ... 27 1205853395.62 181 0.5450000166893005 0.5350000262260437 ... 28 1205853395.73 181 0.5400000214576721 0.5400000214576721 ... 29 1205853395.83 181 0.5479999780654907 0.5360000133514404 ... Odometry: 901 1205853437.119040 0 -3.102520660503609 3.963312253867039 1.153641139388319 ... 902 1205853437.163038 0 -3.102512280308661 3.963330776419583 1.138202487770184 ... 903 1205853437.211029 0 -3.102511007946354 3.963333473265386 1.121727579355471 ... 904 1205853437.263017 0 -3.102505770651651 3.963344116867601 1.105313585686352 ... In these data samples, the first column refers to the id for the data samples. the second column refers to the time stamp, in seconds. I am trying to write a ROS-bag file that contains these data samples, and play the bag file, and use AMCL to do localization. The way I currently generate the ROS-bag file is by iterating through all data samples, and write a message (either LaserScan, or Odometry) for each data sample to the appropriate topics, with the timestamp directly obtained from these data samples. The problem I observed is that, while playing the ROS-bag file, with AMCL running, the localization was pretty bad - the laser scan readings shown in RVIZ completely misaligned with the obstacles in the map, after 5 seconds or so. After some investigation, I found that the source of the problem could be due to the time stamps written to the bag file. It appears that the time stamps that these messages are published are different from the time stamps when they were written to the bag file. Furthermore, the difference between laser messages' **"published time stamp"** and **"true time stamp"** is way larger than that for the odom messages, by around 5-7 seconds. For example, for laser scan message with id=27, the publish time is 1205853412.16, but the *true time* for this message, as shown above, is 1205853395.62. On the other hand, for odometry message with id=902, the publish time is 1205853437.163038015, and the true time is 1205853437.163038, as shown above. I believe that it's because of such difference in the delay caused the synchronization problem. Although this phenomenon seems reasonable, because the LaserScan message is larger than Odometry due to the "ranges" array, it is something very undesirable. I haven't come up with a way to deal with this effectively. Has anyone encountered this issue before, or know something about how to resolve this? I really appreciate your help! EDIT: 5-7 seconds should be over 10 seconds.

Viewing all articles
Browse latest Browse all 475

Trending Articles