added logic to encode NAN as INT16_MAX to transfer to IO from FMU

[dlwalter]

Describe problem solved by the proposed feature
Currently, mixers must pass through NANs on the throttle channel to correctly send disarm values on those motors. If using Simple Mixers on PX4IO to map actuator_control channels to outputs, there is no logic to send a disarm value, as NANs get written to 0.0f through the float->int->float casting process to transfer data to the IO.

Simple Mixers on the FMU correctly pass through NAN on the actuator_control channels to the outputs, resulting in disarm values. I believe that both mixer behaviors (FMU vs IO) should appear transparent to the user and handle NANs identically.

Describe your preferred solution
Have NANs reach the Simple Mixer on the PX4IO using the px4io driver by encoding them as INT16_MAX. Since control channels are constrained between -1.0f and +1.0f, when FLOAT_TO_REG encodes as int16, they only require a range of -10000 to 10000. We can encode a NAN as something out of this range without affecting normal operation.

Describe possible alternatives
Another alternative would be to modify Simple Mixer or create a Simple Motor Mixer that can detect a disarmed vehicle state and write NANs to that output to achieve a disarm. The disadvantage of this is it could further complicate.

A more intrusive alternative would be to change how we achieve disarm values and move away from the expected passthrough of the actuator_controls throttle channel NANs. A solution could be output channel parameters that identify channels as motors and relies on the vehicle arm/disarmed status as opposed to passthrough of NANs. PWM_ISMOTOR_MAIN1,...etc.

Additional context
I have a couple posts on the forums especially revolving around thrust vectoring, 6 dof control, and tilting motors where developers are facing this issue. It would make development simpler for these projects since they won't have to work outside of an individual module and change px4io firmware to implement their code.

[dlwalter]

Just noticed that this will cast INF to NAN on the IO side. I don't see any logic setting control values to INF, but this may have been better implemented as an "isnan()" instead of "!isfinite()" to catch NANs.

[LorenzMeier]

Fair - could you please send a follow-up PR?

[dlwalter]

#12745

Done.