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.
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.)
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.
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?
Originally posted by Johannes Meyer on Gazebo Answers with karma: 196 on 2013-01-21
Post score: 4