Add Flight mode column to the CSV file

[danarrib]

Add a text column "simplifiedMode" to the CSV file.

It's a 4-character active flight mode indicator, almost identical to the INAV Flight Mode OSD element.

Possible values are:

• !FS!
• MANU
• RTH
• A+PH
• 3CRS
• CRS
• PH
• AH
• WP
• ANGL
• HOR

It'll be useful to display the active flight mode on a overlay tool that I'm planning to publish soon (a command-line dashware-like tool)

Also, this change:

• Removes the --dashware command line option.
• Makes the fields Distance (m), homeDirection, mAhPerKm, cumulativeTripDistance and azimuth available on the CSV file when the --merge-gps command line option is used.
• Makes the fields rssi (%) and Throttle (%) always available, since this fields are not related to GPS data.

[stronnag]

Please fix the following compilation warning:

%% blackbox_decode.c
.//src/blackbox_decode.c:104:23: warning: left shift count >= width of type [-Wshift-count-overflow]
  104 |  NAV_CRUISE_MODE = (1 << 36),
      |                       ^~
.//src/blackbox_decode.c:104:20: warning: enumerator value for ‘NAV_CRUISE_MODE’ is not an integer constant expression [-Wpedantic]
  104 |  NAV_CRUISE_MODE = (1 << 36),
      |                    ^

The ISO C standard defines that an enum is of width int. We prefer to be both warning free and standard compliant.

Where do the values after MANUAL_MODE come from (they are off by one compared to firmware src/main/fc/rc_modes.h

So we have the situation with a log including a waypoint flight, we have:

• flightModeFlags (flags) : ARM|NAVWP (correct)
• navState 17 == nav_state_waypoint_in_progress (correct)
• the new flightMode column states ACRO (which is incorrect)

It would also be preferable if the new column as not called flightMode as it's a gross simplification of what the firmware thinks is the flightMode, perhaps simplifiedMode or displayedMode or OsdMode would be better and less confusing.

[stronnag]

As discussed on TG previously, the actual blackbox variable that is stored in the BBL is only 32 bits wide, so defining non-standard enums beyond (1<<31) is pointless (as well as non-standard).

From a BBL with 3D criuse:

navState                                 mode flags
nav_state_cruise_3d_in_progress (33)	 ARM|NAVALTHOLD

[danarrib]

Thanks the feedback Jonathan. I just fixed the problems.
Now the flight mode flags are correctly defined.
I removed the unnecessary ones (the ones that doesn't affect the displayed text).
I also did some minor fixes... The columns rssi (%) and Throttle (%) now are added to resulting file regardless of --merge-gps option, since this values are not GPS dependent.

[stronnag]

Daniel, much better. May I suggest a couple more small improvements:

• Use the BBL failsafePhase field to detect failsafe (via defnition in inav/src/main/flight/failsafe.h and how it's handled here in src/parser.c. This will then work for F/S cases other than RTH
• Use #define or enum for navStates. This makes it easier to follow /maintain the code vice magic numbers.
• Consider then if you want to use the CRS_2D values from inav/src/main/navigation/navigation_private.h / navigationPersistentId_e, I don't think your current test for 2D is valid.

[stronnag]

We also still have a problem with home range and bearing (well, bearing at least).
Here's what should happen (home is c. W (278°) of the launch point).

The log says it's NE (52°) --- not even 180°off.

Later on in the log, the bearing is negative. This should not happen.

[stronnag]

So part of the problem is nomenclature. What's called homeDirection is relative bearing and azimuth is the reciprocal bearing (and incorrect).

[stronnag]

Daniel, I've been playing around with another approach to the geodetics that for my examples gives somewhat (IMO) resutls, such that especially for flights involving lots of turns, it gets more accurate total distances and energy usage.

Let me know when you've got as far as you're content with your current PR, and I'll rebase an experimental branch for you to try on what you've done so far plus my experiment.

[danarrib]

Daniel, much better. May I suggest a couple more small improvements:

• Use the BBL failsafePhase field to detect failsafe (via defnition in inav/src/main/flight/failsafe.h and how it's handled here in src/parser.c. This will then work for F/S cases other than RTH
• Use #define or enum for navStates. This makes it easier to follow /maintain the code vice magic numbers.
• Consider then if you want to use the CRS_2D values from inav/src/main/navigation/navigation_private.h / navigationPersistentId_e, I don't think your current test for 2D is valid.

Hello Jonathan, thanks again for your valuable feedback. I fixed this points today. It's already on the branch. You can merge if you like.

Regarding the problems with the homeDirection and azimuth, I can reproduce using the two log files you provided, but with my log file everything works as expected... Today was a busy day and I could not give this problem the needed attention.

Let me know if you'll take a look on this or if you like I try to fix.

[stronnag]

Daniel, tomorrow I'll merge your PR "as is" and rebase my experiential geodetics on top of it. Then you can test that branch on your files and maybe we reach a consensus.

[stronnag]

To be continued ...

[stronnag]

Daniel, please try #24, in particular whether its idea of relative home direction (clockwise from the vehicle) is what you expect.
For some of my aerobatic, range < 300m flights, #24 provides an accurate measure of distance, where #23 could be 50% out (i.e. cumulative distance ~ 50% of the actual distance).