UniversalRobots
Make several members of hw_interface atomic, for thread safety
Addresses #447.
I look at this as cheap insurance because there's no downside to making these variables atomic AFAIK.
@fmauch you probably know more about it than I do. The way I look at it is:
position_controller_running_ and velocity_controller_running_ are used in write() and doSwitch(). They are probably safe if ros_control does its job of stopping the read/write loop before switching. So I could probably revert those if you want me to.
robot_program_running_ is used in write(), isRobotProgramRunning(), handleRobotProgramState(), and stopControl(). That's quite a few places that I don't all trust to be threadsafe (but maybe they are...)
Same thing with controller_reset_necessary_. It's used in read(), handleRobotProgramState(), and shouldResetControllers(). Several places that might not all be threadsafe.
position_controller_running_andvelocity_controller_running_are used in write() and doSwitch(). They are probably safe if ros_control does its job of stopping the read/write loop before switching. So I could probably revert those if you want me to.
No, I'm absolutely fine with keeping them. @stefanscherzinger do you think this would make sense to merge into master or staging? Intuitively I would merge it into master, but it will probably create conflicts with staging. Additionally, we introduced other members in the staging branch that should get the same treatment. I would go for merging this into master and adapting staging accordingly.
Looking at the conflicts it looks as if we have to extend this PR with the new interfaces. @AndyZe would you like to do it or should I update this PR?