1205853412.16 - 1205853395.62 is about 16.5 seconds - that's quite a while. A medium-sized laser scan message absolutely should not cause a 16-second delay.
rosbag should be more than capable of playing these bag files back at a reasonable speed, without introducing a 5-15 second delay for a laser scan message. (rosbag can play back much higher bandwidth bag files in real time without issues).
There are often two timestamps for each message that is written to the bag file; the bag timestamp (which rosbag uses when replaying) and the timestamp in the Header, if the message contains a Header. The Header timestamp represents the actual time that the message was captured, AMCL will use the Header timestamp to help it correct for any delay in receiving the LaserScan message. You must write the Header timestamp correctly, and having the bag timestamp match the header timestamp is ideal if you're generating the bag file from another dataset.
I'm curious where the "publish time" that you report is coming from. Which tool or which message field are you getting the publish time from?
Originally posted by ahendrix with karma: 47576 on 2016-12-18
This answer was ACCEPTED on the original site
Post score: 0
Original comments
Comment by zkytony on 2016-12-18:
Thanks for the insight. The published time is from the result of echoing /scan, and /mobile_base/odom, topics that the messages are written to. I did actually write the true time stamp to the header of each message. I also used that time as the third param for the bag.write() function.
Comment by zkytony on 2016-12-18:
@ahendrix, if you have time, check out this video: https://www.youtube.com/watch?v=LHc1nuO1eRQ&feature=youtu.be for the problem I observed.
Comment by zkytony on 2016-12-18:
I agree with you that the size of the message shouldn't be the problem. I tested with a rosbag file recorded from data in simulation, and the laser ranges array has length of 921, much larger than what the length in the data sequences here. There is no synchronization problem for that.
Comment by zkytony on 2016-12-18:
Here is my code for writing the laser scan message:
# write laser scan message
bag.write("/scan", lsmsg,
rospy.Time.from_sec(scan['time_stamp']))
Here, scan is a dict made by parsing the raw csv data. lsmsg is a LaserScan message, with header.stampassigned to ...
Comment by zkytony on 2016-12-18:
rospy.Time.from_sec(scan['time_stamp']) as well
Comment by ahendrix on 2016-12-19:
It looks like you're writing timestamps to the bag file correctly. The localization in your video definitely looks poor. rostopic echo doesn't print timestamps by default, so I'm still don't understand what you're running to observe this timestamp issue.
Comment by ahendrix on 2016-12-19:
I hope you're not trying to use this to do localization in real time, while the robot is driving.
Comment by zkytony on 2016-12-19:
Thanks @ahendrix. LaserScan message has a header field, and rostopic echo can display that, isn't it? Because each individual reading is almost unique (lots of decimal digits), I basically used a reading to search for the row for that reading in the csv file. (I read those reading from shell screen)
Comment by zkytony on 2016-12-19:
Localization for the real robot works pretty well for us, and it's not relevant to the problem here. Here I'm just trying to restore the pose of the robot when the robot collected these data (as you can see from the time stamp, it's several years ago).
Comment by zkytony on 2016-12-19:
I was wondering if this problem has anything to do with "wheelbase width", because it seems that, besides the strange delay problem, the localization is off when the robot is rotating, but not when it moves in a straight line. But, I don't know how to configure the wheelbase width in my case.
Comment by ahendrix on 2016-12-19:
That seems like a pretty inexact way to measure the timestamp, and it doesn't make much sense to see rosbag playback producing a timestamp that's different from the input data (the header timestamp should come directly from the recorded message)
Comment by ahendrix on 2016-12-19:
From the video it definitely looks like your odometry is not accurate when rotating. You can try to increasing the rotational noise parameter in AMCL. If you have a differential drive robot then adjusting the wheelbase may help your rotational accuracy.
Comment by zkytony on 2016-12-19:
@ahendrix, It seems that I made a mistake when reading the timestamp. There is actually NO delay problem. Sorry for the incorrect information. I believe that adjusting wheelbase can help, but I don't know where to set it. Also, it seems that AMCL doesn't need the wheelbase info, right?
Comment by ahendrix on 2016-12-19:
AMCL needs a rotational estimate from you odometry. AMCL doesn't care how you compute that value, but for differential drive robots the underlying math usually uses the wheelbase and the wheel diameter to convert wheel rotations into rotation of the body.
Comment by ahendrix on 2016-12-19:
The ROS navigation tuning guide has a short section about tuning odometry that compares your odometry to your laser scan data.
Comment by zkytony on 2016-12-20:
Thanks for the link. But that guide didn't specify how he "mucked" with the parameters. I tried to tune the alpha values in odometry model, but it didn't work very well with the odometry data I have; although there is indeed some change in localization behavior, it's still not acceptable.
Comment by zkytony on 2016-12-20:
@ahendrix One more follow up. I found a paper on setting the measurement error, and it seems to be what I want http://www.ijsrp.org/research-paper-1213/ijsrp-p2491.p. I'll try and see how good this method can be. When you are tuning amcl odometry model yourself, what math/theory do you rely on?
Comment by ahendrix on 2016-12-20:
I don't tune AMCL often; when I do I try to make a rough estimate of my robot's parameters, start with that, and then collect a few data runs that try to capture the space of possible inputs. I then tune AMCL against that logged data.