AP_Periph: Add ARM cmd receive monitoring.

[ghost]

Currently, if the CAN data is stopped receiving, AP_Periph will still remain in the last known ARM state. This creates an issue if we are driving Motors as if the last state was ARMED and Motor running it will stay at this state until new data is received. To solve this I have made a change so there is a 1Hz polling of ARM msg. If not received it will disarm AP_Periph.

Would like to hear the thoughts of others on the logic.

[tridge]

To solve this I have made a change so there is a 1Hz polling of ARM msg.

this doesn't look safe to me. If you had 1 lost uavcan::equipment::safety::ArmingStatus packet then there is a good chance the ESC would disarm (the packets are sent at 2Hz) I think we'd need to also check if we have received an ESC command. Those come in much faster (eg. 300Hz), so would make it a lot safer. I think it should stay armed until:

• a specific disarm command is received
• or no arming command and no ESC command for 1s

Adding a DISARM_DELAY parameter would also be a good idea

[ghost]

@tridge I have implemented the change you requested and have tested it. AP_Periph will Disarm if

1. A specific disarm command is received
2. no arming command and no ESC command receive for DISARM_DELAY period.

[peterbarker]

Ping @loki077 @robertlong13 thoughts on this one?

[robertlong13]

@peterbarker I'm on the fence about it. It feels like the right thing to do, but I can't imagine a realistic scenario where this makes a true safety difference.

Lokesh may feel differently

[loki077]

@peterbarker can close this PR. For now the esc raw command timeout implementation is good enough for safety.