The controller stopper basically listens to a boolean topic and stops all controllers instead of a set of preconfigured controllers when receiving a false message. On a true message it restarts the previously stopped controllers. This has the following benefits:
When the interpreting program on the robot gets stopped, the JTC gets stopped and therefore the trajectory gets aborted this does
give the user feedback about the trajectory not being executed successfully
prevent the JTC from further interpolating and therefore leading to infeasible jumps / very fast motions once control is re-enabled
While the robot is not ready to receive control commands, trajectories sent to the driver will get rejected (basically adding the same benefits as with the last point)
Obviously, this is a rather simple method to achieve that goal which has the culprit that nothing stops users from starting controllers manually while robot control is not active...
The failing tests seem not to be related. @bmagyar Do you think it would be worth it writing a test for the controller stopper? I guess the answer would be "with test coverage every PR is nicer".
This basically implements #510.
The controller stopper basically listens to a boolean topic and stops all controllers instead of a set of preconfigured controllers when receiving a
false
message. On atrue
message it restarts the previously stopped controllers. This has the following benefits:Obviously, this is a rather simple method to achieve that goal which has the culprit that nothing stops users from starting controllers manually while robot control is not active...