driver crashes (sometimes) due to switching controllers in velocity mode

[floweisshardt]

a) this one works:
roslaunch cob_bringup robot.launch
init
rosservice call /arm_left/controller_manager/switch_controllers (stop_controllers = joint_trajectory_controller, start_controllers = joint_group_velocity_controller)

b) this one crashes (sometimes, but very often):
roslaunch cob_bringup robot.launch
init
rostopic pub /arm_left/joint_group_velocity_controller/command std_msgs/Float64MultiArray ...

The difference between a) and b) is that in a) we're only switching controllers and in b) we're switching controllers while publishing velocities. There are two subscribers (cob_control_mode_adapter and canopen driver) for the velocity topic. So the crash might be caused by a race condition when a callback in the driver is executed before the callback and switch in the cob_control_mode_adapter has finished successfully.
@thiagodefreitas: can you please investigate that on monday?
If that's true, the driver should ignore all velocity inputs as long as not all modules are switched successfully to velocity mode (initiated by the cob_control_mode_adapter).

@ipa-mdl: FYI

[mathias-luedtke]

problem was already fixed in ipa320/ros_controllers@97f887b,
but the ipa320 overlay was removed from the robot user and the fix was not merged upstream.

However, ForwardJointGroupCommandController is not thread-safe and needs to be adjusted,
otherwise commmands could be mixed up from different input messages.

The ipa320 is just an intermediate fix for preventing the crashes.

[fmessmer]

There is currently a similar discussion here with a pending PR here

But as just discussed with @ipa-mdl there is more to that and it is present in other controllers, too... the respective PRs will be updated or superseded...