Add SetActivateRobotic service

[adamlm]

PR Details

Description

This PR introduces a new service interface for activating and deactivating a hardware interface controller module. The interface closely follows that of the SetEnableRobotic service.

Related Issue

Closes #134

Motivation and Context

Some hardware interface controller modules (such as the VESC used on the C1T) do not have an interface for activating or deactivating control. Adding this service would provide such an interface.

How Has This Been Tested?

cav_srvs package with proposed enhancement has been built successfully.

Types of changes

• [ ] Defect fix (non-breaking change that fixes an issue)
• [x] New feature (non-breaking change that adds functionality)
• [ ] Breaking change (fix or feature that cause existing functionality to change)

Checklist:

• [ ] I have added any new packages to the sonar-scanner.properties file
• [ ] My change requires a change to the documentation.
• [ ] I have updated the documentation accordingly.
• [x] I have read the CONTRIBUTING document. CARMA Contributing Guide
• [ ] I have added tests to cover my changes.
• [ ] All new and existing tests passed.

[msmcconnell]

Interesting idea, but I want to clarify the current implementation and then discuss if this is needed. Currently, the usage of SetEnableRobotic is that the user requests hardware to engage, then the hardware driver reports if the engagement was successful via the robot_active field in RobotEnabled.msg. So the flow is,

1. Send commands (to avoid driver timeouts)
2. Set enabled
3. Driver is enabled
4. When the commands are received (or any other required data), the driver becomes Active when automation is actively in control of the vehicle.

A manual activation seems like it defeats the purpose of that feedback, but I could be misunderstanding the objective of this change.

[adamlm]

Thanks for the clarification. I think I was misunderstanding the flow.

To be precise, let's define three terms: enabled, engaged, active.

• Enabled means the controller is operational and ready to be engaged. A user can request the controller be enabled through the SetEnableRobotic service, and robot_enabled = true once that process has successfully completed.
• Engaged is a state in which the controller is listening for incoming commands from CARMA and outputting those command into the drive-by-wire system. A controller can transition into this state after being enabled and can transition out of this state through various means (e.g., if a safety driver manually takes control of the vehicle).
• Active is an indicator of the controller being engaged. robot_active = true when the controller is engaged and robot_active = false otherwise.

Do these definitions match the current implementation? It seems to be that same as what you're saying, but this was how I interpreted it. If this is correct, then I don't think we need a SetActivateRobotic.srv.

[msmcconnell]

@adamlm That is correct.

[adamlm]

After discussion, conclusion is this feature is unnecessary.