[RFC] Use WP P3 as a bitfield for additional user defined functions

[stronnag]

Currently, we use WP parameter3 bit 0 (value 0 / 1) to define relative or absolute altitude mode.
It is proposed that in future we consider this as a bit field, and initially define additional bits as WPUSER1 ... WPUSER4.

The FC would then be enhanced such that the logic conditions can make these flags available to the user, such that they could be used for actions such as:

• Deploy parachute
• Activate camera
• etc. (i.e. move servo).

Other than an enhancement to the logic conditions, it is not envisaged that any other work would be needed in the FC (other than explicitly checking for bit0 set / unset for altitude mode rather than p3 == 0 / p3 == 1 and some #define / enum to make it clear these bits are reserved).

Given the quite recent addition of rel / absolute altitude mode and to the author's knowledge this being supported only by the configurator and mwp / impload, it is unlikely that there is a substantive legacy issue. In any case, the benefits are significant in addressing a range of support requests (e.g. such as the bullet list above).

[b14ckyy]

As with potential upcoming changes in terms of flight reliability with the new AHRS and Waypoint path tracking, INAV could indeed become much more popular for Mapping and general Mission applications. Having the option to run certain triggers automatically along a WP mission would massively increase the potential for fixed wing as well as multirotor. as stronnag mentioned the camera activation would be great to only record video or picture series while on the actual mapping path but stopping while on the turn legs of the path makes also post processing of these work cases much easier.

it could also be used to disable the VTX during certain sections of the WP mission to reduce power consumption on small fixed wings or reduce electrical interference for RF related appliances. A friend of mine needs to do exactly that as he uses INAV Fixed wings to track down micro-transmitters that are attached to wild animals. He flies Mission Patterns over the target area and creates heat maps of the transmitter signals to locate them with a modified AR Pro that is full of shielding all around any electronics.

[stronnag]

We'd also need to add a distinct jump counter (as we piggy back on P3 at the moment, such an ugly hack (mea culpa)).
Note this is code internal, not exposed API.
Or maybe not, as Rel/Abs and JUMP are mutually exclusive ....

[b14ckyy]

let's hope that Speedybee does not decide to implement mission planning. They already needed 3 months to adapt for the MSP changes. Imagine we break compatibility again :O

[breadoven]

Sounds like a good idea. Should still be able to use P3 for the Jump counter given any user action probably wouldn't apply to the Jump waypoints only the preceding geospatial waypoint ? Unless of course you wanted to be able to have a different action for each Jump from the same "multi Jump" geospatial waypoint which would only be possible if the action was associated with each Jump waypoint itself. e.g.

1
2
3
4
5
6 jump to 1, action 1
7 jump to 2, action 2
8 jump to 3, action 3
9
10

But would anyone really want to do this ?

[b14ckyy]

I guess this would be a extreme edge case scenario. (Having WP triggers is already edge case). If someone really needs that they can add a second WP right in front of the first on the same path for the trigger and then jump.

[stronnag]

There are a number of options:

1. Limit "user actions" to geographic WPs
2. Use the (some of) the remaining bits in P3 for the jump counter.
3. Add a new array just for jump counters

As the current graphical mission planners don't really / easily expose non-geographic WP attributes to the end user, (1) is the easiest / most pragmatic approach.

[b14ckyy]

+1 for Option 1.
Least changes on the WP side and also planner sides. And it saves up P3 bits for later use. 3 would just raise the config size again I guess.

[breadoven]

Yes, 1 would be fine. No need to complicate things for something that would rarely get used and as @b14ckyy says you can just add geospatial WPs close to each other to achieve the same thing.

[stronnag]

Excellent, I'll do a PR for the navigation.[ch] side. I understand that @b14ckyy may have a victim volunteer for the PLC side.

[b14ckyy]

I think @MrD-RC will love to work on this :D

[MrD-RC]

Huh??? What's a waypoint...

[PatrickStimpson]

Action at WP could be what I am looking for...
I imagine a tab the same as failsafe - so when the wp is reached it can kick into the channel fallback settings for a predetermined length of time (like failsafe stage 1) then istead of going into failsafe stage 2 it would just carry on to the next WP.

You could do most actions with that I would have thought.