ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

timing problem with laser scan (synchronizing with odometry)

asked 2013-10-22 01:00:52 -0600

Hendrik Wiese gravatar image

Hi guys,

I've got a timing problem with my laser scans. I receive laser scan data through a tcp socket (it's simulated laser data from another system in the network). While the robot is standing still everything is fine. But as soon as it moves/turns, the laser scan gets biased depending on how fast the robot is moving/turning. It looks like the scans are stamped wrong in relation to odometry/tf.

At the moment I stamp all my sensor data with the time stamp of the moment they arrive in the node. I suppose there is some kind of offset due to the time some of my data needs to get through ROS.

So, how can I synchronize my nodes to get rid of the speed depending bias?

Thank you!

Cheers, Hendrik

edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted

answered 2013-10-22 11:52:33 -0600

tfoote gravatar image

From our experience the recommend way to syncronize machines is using the chrony ntp client. There's a few notes here:

If you are running on a system that does cannot be syncronized or you are going to be using system time @skiesel's answer would be the way to go.

edit flag offensive delete link more


I see and I agree - synchronizing both systems would be a great help. Is it possible to synchronize a Linux and a Windows system like this? My simulator runs on a Windows machine.

Hendrik Wiese gravatar image Hendrik Wiese  ( 2013-10-22 18:03:18 -0600 )edit

Yeah, it's just using NTP, there should be plenty of windows clients. And it's probably builtin too.

tfoote gravatar image tfoote  ( 2013-10-22 19:45:55 -0600 )edit

Alright, I'll give it a try. Thanks a lot!

Hendrik Wiese gravatar image Hendrik Wiese  ( 2013-10-22 20:36:18 -0600 )edit

answered 2013-10-22 01:37:46 -0600

Just throwing something out there for you. I'm sure someone else will come along with something more "official" but...

You could try having your remote system query ROS for the current ROS time. This way the latency between the "exact" time the data was collected and its stamped time is only about the latency of the communication between the two systems.

Alternatively, you could try syncing both machines to an ntp server, stamp the incoming data from the remote system with a system timestamp, then when the ROS system receives the message it can "rewind" the ROS time by however far off the system time stamp attached to the message is from the current system time (on the local ROS machine).

edit flag offensive delete link more

Question Tools

1 follower


Asked: 2013-10-22 01:00:52 -0600

Seen: 1,249 times

Last updated: Oct 22 '13