Gazebo | Ignition | Community
Ask Your Question

Timing / Synchronisation between Gazebo and ROS

asked 2013-06-10 10:14:29 -0500

Christoph gravatar image

Hi everyone,

I got a question regarding the timing in Gazebo and ROS.

I have a robot which uses Gazebo plugins and some ROS packages. In my plugins I use ros::Time::now() for everything I send outside of Gazebo (normally ros messages) and the ROS packages also (seem to) use ROS time. Only for Gazebo components, like my pid's, I use gazebo simulation time. ROS packages I use are for example move_base and gmapping.

My experiences with Gazebo are, that I have to restart the environment from time to time, when I delete my running robot and want to respawn it. Otherwise Gazebo would crash and I have to restart it anyways.

Now this is what happens and I am aiming at with my question: Sometimes during the simulation process, normally after restarting Gazebo, one of the ROS nodes won't work anymore because of bad/old messages coming from Gazebo. This I don't fully understand because they should use ROS time instead of Gazebo simulation time and it works fine at the first time I spawn my robot. Using the rqt gui I can see the /clock topic getting information from Gazebo, going to one of the ros nodes. I have to use rosparam to set simtime to false. After that it normally works again.

What are your experiences and advice with timing between Gazebo and ROS and how to handle it?

Can I disable simulation time in Gazebo sdf files?

It would be nice to have an equal timing between all those components. An equal simulation time may be nice to have in further developments.

Thanks in advance


edit retag flag offensive close merge delete

3 Answers

Sort by ยป oldest newest most voted

answered 2013-06-11 10:33:41 -0500

nkoenig gravatar image

ros time is the same as simulation time when the use_sim_time parameter is enabled. If you restart Gazebo while other nodes are kept alive, time will be reset to zero. This will produce old clock messages.

If you restart Gazebo, you should also restart everything else.

edit flag offensive delete link more


Thank you for the clarification! So there are more or less two ways to handle the timing? First approach (disabled sim time): to start Gazebo, set use\_sim\_time to false and then starting the other nodes. Second approach (enabled sim time): start Gazebo and then starting any other node. When I tried the second approach I only see the /clock going to my /teleop\_twist\_keyboard and not to all nodes, as I would expect. Or does a direct connection from Gazebo to a node autom. send the sim time?

Christoph gravatar imageChristoph ( 2013-06-11 11:02:03 -0500 )edit

Ok. I got the /clock topic (simulation time) to work for all of my nodes. I added the param "use\_sim\_time" to all my launch files so the nodes will listen to the /clock topic. Then I started Gazebo which automatically set use\_sim\_time to true and with it the /clock topic starts to send sim time.

Christoph gravatar imageChristoph ( 2013-06-12 05:49:00 -0500 )edit

@Christoph, it's a bit strange that you had to set up `use_sim_time` in every launch file. This parameter is looked up in the global namespace, thus, it should be sufficient to load it once before the first node starts.

Boris gravatar imageBoris ( 2013-06-12 21:43:56 -0500 )edit

@Boris: You are right. I just ran a test with gazebo and no use_sim_time entries in my launch files. There was probably an entry setting use_sim_time to false in one of the launch files before. So everything is fine if you only start gazebo, which sets use_\sim_time to true and then start every other node.

Christoph gravatar imageChristoph ( 2013-06-14 09:26:30 -0500 )edit

answered 2013-06-11 01:23:05 -0500

Boris gravatar image

updated 2013-06-11 01:24:44 -0500

Not sure this is the case, but here is the description how ROS dealing with /use_sim_time parameter:

If the /use_sim_time parameter is set, the ROS Time API will return time=0 until it has received a value from the /clock topic. Then, the time will only be updated on receipt of a message from the /clock topic, and will stay constant between updates.

For calculations of time durations when using simulation time, clients should always wait until the first non-zero time value has been received before starting, because the first simulation time value from /clock topic may be a high value.

So the problem can be with the nodes that do not take it into account.

P.S. In my experience such problem usually appears when nodes are using tf or when you try to visualize data in RViz.

edit flag offensive delete link more


Thanks for your reply Boris. Yes, I use rviz and tf messages. Today I tried to replicate that unwanted behaviour. It seems there aren't going /clock messages to the ros nodes as I remembered. But what happens is, after restarting only gazebo and respawning my robot again, that my map node complains about old tf messages and rviz can't get the transformation between my odom data and the base link data. At this point gazebo set use\_sim\_time to true. After disabling sim\_time it won't work either

Christoph gravatar imageChristoph ( 2013-06-11 09:42:30 -0500 )edit

answered 2017-12-18 02:50:40 -0500

markus gravatar image

According to this example here: I just set the use_sim_time parameter to true and also added the following code right after creating my node handle before the initialization of the ros publisher and ros subscriber and the update loop

// this wait is needed to ensure this ros node has gotten // simulation published /clock message, containing
// simulation time. ros::Time last_ros_time_; bool wait = true;
while (wait) { last_ros_time_ = ros::Time::now(); if (last_ros_time_.toSec() > 0) wait = false; }

edit flag offensive delete link more

Question Tools


Asked: 2013-06-10 10:14:29 -0500

Seen: 20,975 times

Last updated: Dec 18 '17