FW launch status reporting improvement

[breadoven]

Provides a more useful means of tracking the status of the fixed wing launch sequence with 2 additional end states added making it clearer if the launch resulted in flight or was aborted. The Idle state has been removed since it is now redundant, replaced by the 2 new additional states.

[dragnea]

Why is all those states needed, since only 2 will be used (launch detected and finish/abort? https://github.com/iNavFlight/inav/pull/7068/files#diff-11d5bd31d29e1a5d6ca52ed58ff0694afdf0559801dafb5fb63170245eb0f90f
Also all of these new states are reflected in here:

inav/src/main/navigation/navigation_fw_launch.c

Line 115 in 30f0ce2

fixedWingLaunchState_t currentState;

I see more complexity by adding these, also the code is just doing the same. Perhaps you may want to add the launchStatus in the fixedWingLaunchData_t to be more consistent

inav/src/main/navigation/navigation_fw_launch.c

Line 117 in 30f0ce2

} fixedWingLaunchData_t;

and set it in the state machine

inav/src/main/navigation/navigation_fw_launch.c

Line 123 in 30f0ce2

static const fixedWingLaunchStateDescriptor_t launchStateMachine[FW_LAUNCH_STATE_COUNT] = {

I'm just saying

[breadoven]

The problem with the states used at the moment is they're transient. Launch Detected state lasts a loop/few loops and then is no longer the current state. You know you've moved beyond it perhaps by looking at the current state number but when you get to the end of the launch you end up at the idle state which resets the state number sequence back to 0 meaning there's no way to know how far the launch sequence went before finishing. Was it aborted immediately after detection or did it actually reach the end with a flying plane ?

I wanted to use the change in this PR as a means of detecting if the plane was actually likely to be successfully flying at the end of the launch or if the launch was aborted before then meaning you couldn't be sure the plane was flying. isFixedWingLaunchFinishedOrAborted doesn't tell me this.

Maybe there's a better way of doing this but as it is it's difficult to understand what happened at launch finish using the current state reporting.

[dragnea]

I see. But the navigation doesn't know what to do with such of states at this moment (Was it aborted immediately after detection or did it actually reach the end with a flying plane), it's just the same behaviour as isFixedWingLaunchFinishedOrAborted(), no distinction, so there will be no result or benefit for the users. On the other hand you add transient state in navigation.c if I'm not wrong. I don't know...
Maybe if you want to see some additional messages on the OSD, like "Aborted by stick movement", or "Max altitude reached" or "Timeout reached", and so on, I suggest to replace the IDLE state with these specific states, of course by adding the corresponding events and messages in the launch state machine. And if it will be needed later in navigation, we only have to take them from here

[breadoven]

Well it did occur to me that the idle state is the problem here, resetting the state sequence to 0. Should be possible to end launch and hold the current state so doesn't really need an idle state ? Once launch is finished it's not going to be used again during the flight so setting it to an idle state doesn't really achieve anything other than flag the launch is finished or aborted ... which could be achieved by another method that maintains the last current state.

As to the suggestion to add the additional states ... seems that is a more complicated solution than adding a status flag (and yes I know people don't like flags but maybe sometimes they offer the more effective solution).

[dragnea]

Should be possible to end launch and hold the current state so doesn't really need an idle state ?

Yes. By adding a state (let's name it 'FW_LAUNCH_STATE_FLYING') which is called on success event for `FW_LAUNCH_STATE_FINISH'. This can remain until the navigation will activate again the autolaunch . IDLE should remain as an initial state, we can rename it to match a state of 'waiting for activation'. I know it looks more complicated, but in the end, you have to deal with one step at a time, each step doing its thing.
The states should look something like this (I added the abort state too):
...

[FW_LAUNCH_STATE_FINISH] = {
        .onEntry                                    = fwLaunchState_FW_LAUNCH_STATE_FINISH,
        .onEvent = {
            [FW_LAUNCH_EVENT_SUCCESS]               = FW_LAUNCH_STATE_FLYING,
            [FW_LAUNCH_EVENT_ABORT]                 = FW_LAUNCH_STATE_ABORTED
        },
        .messageType                                = FW_LAUNCH_MESSAGE_TYPE_FINISHING
    },

[FW_LAUNCH_STATE_ABORTED] = {
        .onEntry                                    = fwLaunchState_FW_LAUNCH_STATE_ABORTED,
        .onEvent = {
            
        },
        .messageType                                = FW_LAUNCH_MESSAGE_TYPE_ABORTED
    },

[FW_LAUNCH_STATE_FLYING] = {
        .onEntry                                    = fwLaunchState_FW_LAUNCH_STATE_FLYING,
        .onEvent = {
            
        },
        .messageType                                = FW_LAUNCH_MESSAGE_TYPE_FLYING
    }

... of course requires the implementation for handlers of each new state.
This logic look more solid for me. But it's just a suggestion, I added the state machine for autolaunch to be more clear and scalable, as the previous version was hard to evolve and hard to add messages and smooth end at that moment.
it's up to you

[breadoven]

I think adding the additional states should work because it preserves the state sequence to the end. It also maintains the cleaner structure which, I agree, is a much better than the old version.

Not sure the Idle state would be used in this case though, given that Launch initialises to the FW_LAUNCH_STATE_WAIT_THROTTLE state. Still, leaving it does no harm.

[breadoven]

Decided to remove the Idle state in the end since it seems totally redundant with the 2 new end states added.

Also changed the Abort logic during the fwLaunchState_FW_LAUNCH_STATE_FINISH state given it makes sense to consider the launch successful at this point whether the finish times out or is cancelled prematurely by moving the sticks. Either way the plane should be "flying".

[dragnea]

great. looking good👍

[breadoven]

This is working as required so could be included in 4.0.0. Doesn't change anything from a user point of view but does improve the logic of the launch sequence making the launch status more obvious and easier to use where required.