Issue recovery commands

[joshmackwilliams]

Allow the safety manager to call node safety command services to assign the appropriate recovery strategies.

[wheitman]

Just to clarify the flow of this:

1. A node issues a Safety Event as a service request to the Safety Manager, which acts as the service server.
2. The manager then refers to the lookup table (#174) to determine the appropriate recovery strategy.
3. The manager then assigns this strategy to the calling node.

If this is the case, what is the response? The assigned safety strategy? Services are designed to be just about synchronous, as opposed to "actions", so should the response to the safety event service call simply be the assigned strategy, rather than having two separate services. This way, the assigned strategy is itself an acknowledgement of receipt.

As a simple example, you could have a single file called "SafetyEvent.srv" that looks something like:

# SafetyEvent.srv
# Request
uint8 event_id
string description
uint8 status
string request_details
---
# Response
uint8 strategy
string response_details

If you believe that the gap between a safety event being raised and an appropriate strategy being assigned is too long for this to work, I would suggest using an Action instead. These incorporate a built-in feedback topic for things like acknowledgement, response strategy updates, and so on. Might be worth a shot!

Finally, is this dependent on #174?

[joshmackwilliams]

First, the recovery strategy can't really be sent in the response. If we implement it that way, the safety manager can only assign recovery strategies to nodes that raise safety events. Since issues might affect multiple nodes, and a broken node might not be aware enough to raise a safety event, the recovery strategy is a separate service call from the safety manager to the node. Thus, the response is empty, and functions purely as an acknowledgement. See the design document for details on all of this - https://github.com/Nova-UTD/navigator/wiki/Safety-Manager-Design.

I don't want to use an action for the same reason - the safety manager can't initiate with a node that hasn't realized something is wrong yet. Two services seems to fit our use case best in terms of versatility.

A good example is pulling off the road. "Generate a steering path off the road" is a recovery strategy of the path planner. It might be triggered by something completely unrelated - ie, our throttle control has gone out. In this case, the path planner wouldn't know anything was wrong and thus would not raise a safety event, but still needs to be assigned a strategy. We don't have this capability if we assign recovery strategies in a response or use actions - the safety manager simply can't initiate with a node that is unaware of a problem.

To address that last question, this is by design not dependent on #174. #174 is "figure out what to do" - ie, what of the available actions need to be taken in a given scenario. This issue is "figure out how to do it" - ie, once we know that a particular node needs a recovery strategy, how do we actually assign it?

Actually, it is possible that #174 would be dependent on this issue - ie, we should have explored our recovery strategy capabilities before writing the logic on which to assign. However I don't think this needs to be the case (if we implement good mocks of everything as needed).