AP_Relay: Refactor to support RELAYx_FUNCTION

[WickedShell]

This refactors the AP_Relay library as proposed on the dev call yesterday.

Things that stand out from the refactoring:

• You can now have per pin defaults. This is something I've been desperate for, because a number of our devices need opposite polarity. I've actually handled this in the past with inverters, but it's still frustrating.
• Each relay is hidden as an enable parameter, so you don't see/notice the cost of the extra default/function parameters unless you are using a given relay
• There was a small edge case before where changing a pair of relays one after the other (such as what we have to do in ICE), would result in logging just the first change, this now will catch both of these, but still rate limits logging.
• In order to walk through the parameters, you need to have an update call, but this is part of what made the logging handling above better.
• If a relay has a key feature assigned to it (say in this case ignition), a GCS user can't accidentally send the wrong relay command and turn off their ignition. This is actually a very significant win for my use cases. I have some relay outputs that scripts currently control, and the user has been known to try and toggle them with the relay interface in MP, which has resulted in very erroneous (and semi dangerous output). If we add some scripting functions to the list this entire failure mode disappears.

Downsides:

• If you are using all 6 relays then you will be viewing more parameters then before. As we start to refactor away various libraries to use this interface we should see that reduced.
• Initial setup is a bit more complicated because changing the function is an enable parameter, necessitating a param download.

Things missing as currently presented:

• Parameter conversion
• Need to correct that the params currently show up as RELAY_X_FUNCTION and the like. That's straightforward.

I haven't done the work to do parameter conversion yet, I wanted to present a prototype that is working with a CubeOrangePlus on the bench, with a oscilloscope hooked up to the outputs. Pin states were toggled using both the relay and engine commands in MAVProxy.

[Hwurzburg]

what is the state during boot period for a pin that will become a relay output?

[WickedShell]

It's defined by the hwdef (both bootloader and normal firmware) + any hardware level pullups. This is the same as it always has been, and there is no provision to let you control the pins from the bootloader.

[tridge]

I think we should try to remove the update() call, and do the logging at the time the set or toggle, to avoid excessive logging we will need a hal.gpio read first so we only log when the value actually changes
also removing _pin_states will avoid race conditions

[WickedShell]

I think we should try to remove the update() call, and do the logging at the time the set or toggle, to avoid excessive logging we will need a hal.gpio read first so we only log when the value actually changes
also removing _pin_states will avoid race conditions

Done. Generally it's more readable (although with comments it didn't end up shorter). The only thing I'm aware of is that when you start logging you might not get any indication of where a relay was before you started. And sending out the MAVLink message requires scanning all the pins.

[tridge]

@WickedShell we can't really do anything on the dev call with it failing the relay CI tests. Did you want someone else to work on it?

[rmackay9]

looking forward to this restructure.

[peterbarker]

Looks fine, really.

Has the Rover change been tested in SITL?

[peterbarker]

This pattern precludes us having two relay cameras, it seems. You might be in the second camera backend here.

[IamPete1]

Your right, but this is the current behavior. We certainly could add a second camera relay function in the future.

[IamPete1]

Has the Rover change been tested in SITL?

Yes, tested param conversion and arming check in SITL. I have not tested the actual relay outputs, but CI covers lots of the other functions.