Ok, I assume the simulator is Gazebo, that can be reset using the rosservice call /gazebo/reset_simulation
service. From this line of gazebo_ros_packages
I asume that with a reset you are only reseting the World not the Entities, however the code is calling a Reset function on the pointer world object that based on this, it is reseting time and model poses, configurations in simulation. As far as I understand is not aproblem of your command publisher but the state of the simulation when calling the reset service.
As I see, when calling the reset service this saves the simulation state, reset the world and apply the state saved earlier, leaving all simulation entities with the same state just before calling the reset. This is because the /joint_states
topic stops publishing joint states after the call of the reset and then resumes the publication when revecives a new command. This post made a good point about the reseting the simulation and I believe is the way to go.
Furthermore, this behaviour is considerided kind of an issue with Gazebo. As for the way of reseting the publisher I do not know a proper way of doing that but generally most people just implement a function that sets all values in the command message to 0 or the initial ones.
Hi @azerila, To avoid an xy-problem, can you provide more background info about what you want to achieve with that?
Hi @Weasfas, I have a robot simulator which uses publisher and subscriber to publish robot states and subscribe robot's commands. When I reset the simulator it seems to me that what was left in the queue of the the publisher's and subscribers remain to be applied which will cause not to restart the simulator from the very initial state of it.