Callback queues and locking in Gazebo plugins/controllers [closed]
Most gazebo plugins in package gazebo_plugins instantiate a plugin-specific callback queue and start a separate thread that runs the callbacks. While writing own plugins, the following questions arose:
Why this is needed at all. What is the problem of using the default callback queue?
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?
