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

How exactly does ROS "Exact Time" policy work, for a time synchronizer?

asked 2019-05-17 16:09:09 -0500

1fabrism gravatar image

Quick question, I'm trying to understand more in depth how this aspect of ROS works. As per the title, does exact time policy really mean that the timestamp of the messages being compared have to be literally the same down to the nanosecond? And is there a guarantee that the data transmitted was indeed captured at the specified instant, or does the timestamp only say when the message was published on the ROS topic?

For example, let's say I've got a turtlebot. I want to do sensor fusion between the wheel encoders and the gyroscope. In order to have the best result, I'd better make sure that the data coming into my Kalman filter was recorded by the different sensors at the same time, correct? But how can the computer running the turtlebot software be able to give the exact same timestamp to different sensor data? Won't it be running one line of code at a time?

Thanks.

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
3

answered 2019-05-18 03:05:24 -0500

gvdhoorn gravatar image

As per the title, does exact time policy really mean that the timestamp of the messages being compared have to be literally the same down to the nanosecond?

Yes. See wiki/message_filters: ExactTime Policy:

The message_filters::sync_policies::ExactTime policy requires messages to have exactly the same timestamp in order to match. Your callback is only called if a message has been received on all specified channels with the same exact timestamp.

This is mostly used with message streams that are published by the same node, but on different topics. Camera drivers are a good example: the sensor_msgs/Image and CameraInfo messages are published on different topics, but with the same timestamp. Or sensor_msgs/Image and sensor_msgs/PointCloud2 published by a 3D camera driver.

And is there a guarantee that the data transmitted was indeed captured at the specified instant, or does the timestamp only say when the message was published on the ROS topic?

The timestamp is set by the driver / algorithm / node / process, not by ROS (which is an ambiguous thing to say in any case).

So if the driver sets the timestamp equal to when the data was captured, it will represent the time at which the data was captured. If it sets it to something else, it'll be something else.

But how can the computer running the turtlebot software be able to give the exact same timestamp to different sensor data? Won't it be running one line of code at a time?

Technically (and pedantically): no, as it will execute a single instruction at a time, and a line may translate into many instructions. As to your question: this will be difficult to answer, as in multi-processor or multi-core systems, it's certainly possible for multiple nodes to be active at the same time.

The chances of having two independent nodes, active in parallel, to publish with the exact same timestamp are very low however. And that is why there is an ApproximateTimeSynchronizer, which allows you to configure a maximum delta-t between messages for them to still be considered published "at the same time" (or in that specific case: near enough).

edit flag offensive delete link more

Comments

One could wonder: if a single node publishes multiple messages on different topics with the same timestamp, why not just publish a single message that is the union of all those messages?

There are (at least) two reasons for this:

  1. you cannot subscribe to a field in a message, only a topic. If a single, large msg would be published, it would be impossible to express interest in a part of it (ie: subscribers would have to subscribe and deserialise each and every message, as a whole, to retrieve only part of it)
  2. standard tools (ie: rostopic, RViz, etc) would not know how to process the union-msg: this would immediately mean the loss of visualisation tools, easy debugging and other uses where ROS standard tools help. Plugins or forks would have to be created to deal with the union-msg, which becomes unmaintainable rather quickly

Publishing seperate msgs from the standard ...(more)

gvdhoorn gravatar image gvdhoorn  ( 2019-05-21 02:47:39 -0500 )edit

Question Tools

1 follower

Stats

Asked: 2019-05-17 16:09:09 -0500

Seen: 1,253 times

Last updated: May 18 '19