Home | Tutorials | Wiki | Issues
Ask Your Question

Callback queues and locking in Gazebo plugins/controllers

asked 2013-01-21 17:52:05 -0500

Johannes Meyer gravatar image

I asked this question regarding implementation details of ROS plugins about a year ago on ROS answers, but nobody answered until today. Perhaps someone here can give some enlightenment. Could this question be somehow related to the problem of reduced update rates since ROS fuerte?

Most gazebo plugins in package gazebo_plugins instantiate a plugin-specific callback queue and start a separate thread that runs the callbacks.

  1. Why this is needed at all? What is the problem of using the default callback queue? (Anyway, for publishing only plugins, the callback queue is only in charge of calling the connect/disconnect callbacks asynchronously, leading to issues due to concurrency.)

  2. If the plugin wants to use its own queue to be able to control at which time the callbacks are processed, there is no sense in using a separate thread and deal with locking. In this case, it would be much simpler to call callAvailable() at the beginning of the UpdateChild() hook. I am using that method in the hector_quadrotor_simple_controller plugin in the hector_quadrotor_gazebo_plugins package and it seems to work flawlessly.

  3. If using a separate thread, mutexes are needed to protect shared data. E.g. the ros_gazebo_force plugin locks wrench data during the UpdateChild() hook, but not in the UpdateObjectForce() callback. Is this a bug or is there some other mechanism that prevents the wrench struct from being overridden during UpdateChild() is active?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2013-09-19 10:13:35 -0500

nkoenig gravatar image

See this question

edit flag offensive delete link more
Login/Signup to Answer

Question Tools

1 follower


Asked: 2013-01-21 17:52:05 -0500

Seen: 825 times

Last updated: Sep 19 '13