Freedrive Controller

[VinDp]

The PR aims at introducing the possibility of enabling the freedrive mode through the ROS2 driver. It relies on the implementation of a specific controller to handle it, in order to correctly deactivate other controllers and avoid unsafe jumps of the robot once the freedrive mode is switched off.

[gavanderhoorn]

Would an action be nicer, semantically?

Start of action -> enable freedrive.

Cancel action -> stop freedrive.

The goal client handle would become something similar to a 'token' or 'mutex' (not exactly, as it wouldn't be as safe or strict, but conceptually).

Concurrent goal -> reject (something/someone else already has 'control' of the freedrive mode).

Event on robot or robot-controller causes freedrive to be disengaged -> abort action (notifies client something happened). A subscriber can't do that.

it would also make it (slightly) harder for something to take over control of the robot by just spamming Bool messages.

And it would make it semantically clearer it controls some specific functionality (ie: because a custom action goal needs to be submitted, instead of a generic Bool).

[fmauch]

Would an action be nicer, semantically?

I have to say, that makes sense! Thank you for the input :-)

[gavanderhoorn]

One aspect that would need some thought though: time-out (ie: when should freedrive be stopped due to the client no longer 'responding').

There might be some way to exploit liveliness QoS or something, but I'm not sure how that would work with actions.