Add E-stop service to send estop CAN frames

[erbornemeier]

Add a service to allow sending of the Estop CAN message upon request per the CAN message spec:

https://docs.odriverobotics.com/v/latest/manual/can-protocol.html#estop

This has been fully integration tested and shown to consistently estop the motors within a full ROS2 stack with several odrive_can nodes

[samuelsadok]

The implementation looks clean, however the main question is: what is the fundamental use case that this addresses, compared to calling request_axis_state with IDLE?

I should say that the Estop message in the ODrive CANSimple protocol does not provide any stronger safety guarantees than just sending a requested_state of IDLE. It does set an ESTOP_REQUESTED flag, but since the application is the one sending the command either way, it already knows the reason itself why it requested IDLE.

In terms of CAN message priority, Estop might look like it has a higher priority than Set_Axis_State, however since all messages to/from node_id=0 have higher priority than all messages from node_id=1, this is not true in a multi-axis system. (If we would redo the protocol, we would swap the order of node_id vs cmd_id in the message ID)

In that sense we're actually considering the Estop message obsolete. We should clarify this in the docs. But if there's any aspect I'm missing please let me know.

[erbornemeier]

I should say that the Estop message in the ODrive CANSimple protocol does not provide any stronger safety guarantees than just sending a requested_state of IDLE. It does set an ESTOP_REQUESTED flag, but since the application is the one sending the command either way, it already knows the reason itself why it requested IDLE.

I see the argument here, but especially in the distributed style of ROS nodes where responsibility of commanding and monitoring of the ODrives may happen from different nodes (such as my case where I monitor several Odrives status from a higher level node), having the reason reported from the ODrive vs needing to couple those nodes together I think adds value and generally simplifies implementation. Said differently, how else would other ROS nodes in the system understand that the Odrives have stopped for an estop without some additional communication method?

The act of sending the Estop I think belongs within the odrive nodes themselves whereas how the user application handles status changes is more context and application dependent, and that node's only way of knowing the Odrives have stopped for an estop vs a some other reason to set idle is via the ESTOP_REQUESTED flag.