0
$\begingroup$

Gazebo Answers logo

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

Christoph


Originally posted by Christoph on Gazebo Answers with karma: 141 on 2013-06-10

Post score: 2

$\endgroup$

1 Answer 1

0
$\begingroup$

Gazebo Answers logo

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.


Originally posted by nkoenig with karma: 7676 on 2013-06-11

This answer was ACCEPTED on the original site

Post score: 2


Original comments

Comment by Christoph on 2013-06-11:
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?

Comment by Christoph on 2013-06-12:
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.

Comment by Boris on 2013-06-12:
@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.

Comment by Christoph on 2013-06-14:
@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.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.