timing problem with laser scan (synchronizing with odometry)

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

1137 ●76 ●90 ●104

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

add a comment

0

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

tfoote

58457 ●128 ●550 ●526 http://www.ros.org/

From our experience the recommend way to syncronize machines is using the chrony ntp client. There's a few notes here: http://wiki.ros.org/ROS/NetworkSetup

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

Comments

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 ( 2013-10-22 18:03:18 -0500 )edit

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

tfoote ( 2013-10-22 19:45:55 -0500 )edit

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

Hendrik Wiese ( 2013-10-22 20:36:18 -0500 )edit

add a comment

0

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

skiesel

549 ●13 ●16 ●26 http://cs.unh.edu/~skiesel

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

add a comment

timing problem with laser scan (synchronizing with odometry)

2 Answers

Comments

Question Tools

Stats

Related questions

timing problem with laser scan (synchronizing with odometry) edit

2 Answers

Comments

Question Tools

Stats

Related questions

timing problem with laser scan (synchronizing with odometry)