Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Since a google search with the 3 words, gazebo, pause and ros leads to here. I will just drop the few lines needed to pause/unpause gazebo in command/cpp and python ( it took me 3 hours to do it in cpp and despite it being a little out of the scope of the question, it may save this time to a few people). Note that at the end I propose a solution to solve this particular problem without the need to create a plugin.

To (un)pause in command line :

rosservice call gazebo/(un)pause_physics

Those who know how to use services should already know the following but for those who never used services before ( like me ) :

in cpp :

#include <std_srvs/Empty.h>

ros::ServiceClient pauseGazebo = nh.serviceClient<std_srvs::Empty>("/gazebo/(un)pause_physics");
std_srvs::Empty emptySrv;
pauseGazebo.call(emptySrv);

in Python ( available here )

from std_srvs.srv import Empty
(un)pause = rospy.ServiceProxy('/gazebo/(un)pause_physics', Empty)

That's for pausing and upausing gazebo.

For this particular problem :

The gazebo ros communication include as services - get_model_state,
- apply_body_wrench, apply_joint_effort, /gazebo/set_model_state and there is also the parameter /use_sim_time

With that it should be possible to do what was asked without writing a plugin. I must say that even if it's possible, I'm not sure if it's advised to process like this instead of creating a plugin for complex interactions with gazebo.

Since a google search with the 3 words, gazebo, pause and ros leads to here. I will just drop the few lines needed to pause/unpause gazebo in command/cpp and python ( it took me 3 hours to do it in cpp and despite it being a little out of the scope of the question, it may save this time to a few people). Note that at the end I propose a solution to solve this particular problem without the need to create a plugin.

To (un)pause in command line :

rosservice call gazebo/(un)pause_physics

Those who know how to use services should already know the following but for those who never used services before ( like me ) :

in cpp :

#include <std_srvs/Empty.h>

ros::ServiceClient pauseGazebo = nh.serviceClient<std_srvs::Empty>("/gazebo/(un)pause_physics");
std_srvs::Empty emptySrv;
pauseGazebo.call(emptySrv);

in Python ( available here )

from std_srvs.srv import Empty
(un)pause = rospy.ServiceProxy('/gazebo/(un)pause_physics', Empty)

That's for pausing and upausing gazebo.

For this particular problem :

The gazebo ros communication include as services - get_model_state,
- apply_body_wrench, apply_joint_effort, /gazebo/set_model_state and there is also the parameter /use_sim_time

With that it should be possible to do what was asked without writing a plugin. I must say that even if it's possible, I'm not sure if it's advised to process like this instead of creating a plugin for complex interactions with gazebo.

Edit : Indeed @gvdhoorn, It allows to stop the simulation during the processing time of any message ( which is what i thought the OP wanted before your comment) but to do the opposite ( which is having a simulation running but no processing ) is indeed not as straight forward with those services.

I belive it's possible to do what's requested but that it may be very unpractical to do : A "time_managment" node which would subscribe at the command and publish a boolean ROS_FREEZE read by all the other nodes should do the job no ?

  • In the node where the command is published, when the command is published, send at the same time a gazebo "unpause". In the "time_managment" node, receiving the command should trigger the publication of a ROS_FREEZE = TRUE.
  • All the other nodes running should subscribe on this topic and either enter a loop waiting for another message on this particular topic or individually changing the way all the other callbacks work when ROS_FREEZE = true -after 1s,the time_namagment node should send a ROS_FREEZE=false allowing one processing step and the same time a call to the rosservice to "pause" gazebo.
  • then on the next issued command, the cycle can restart.

This should work no ?