navigation: add MSP precision landing target consumer for MC/VTOL

[mart1npetroff]

Implement an INAV-side precision-landing target consumer that accepts external target offsets over MSP and applies correction only in MC/VTOL POSHOLD/LAND contexts, without direct motor/attitude control and without mode switching.

• add MSP2_INAV_SET_PRECISION_LANDING_TARGET (0x2231 / 8753)
• add precision landing state machine module (cache/validate/use/fallback)
• integrate with NAV + multicopter position controller + LAND flow
• add nav status exposure for precision states (OSD/DJI mappings)
• add CLI settings for source/validation/correction/retry behavior
• keep descent profile on standard LAND logic (remove custom PL descent tuning)
• add retry timeout auto mode: nav_precision_landing_retry_timeout_ms=0 => 2 * lost_hold_time_ms
• document MSP payload/reply and navigation behavior in docs

Safety behavior:

• no activation in fixed-wing profile
• no correction use in failsafe
• stale/low-confidence/bad-frame targets are rejected
• target loss recovery: HOLD -> CLIMB_AND_RETRY -> NORMAL_LAND fallback

[Jetrell]

Most of the navigation functionality written of in this PR is already written about in the Wiki. And if it was only about the understanding of the features and tuning, INAV MC/VTOL would work extremely well under all conditions.
However the greatest short fall INAV has in fulfilling what you want to accomplish with WP and RTH VTOL automation is actually missed.

What you want to accomplish is an awesome goal. But it won't be as simple as hoped. Without specific improvements being made to the MC navigation flight targeting control.

I'll give you a run down.
INAV has a long time Collaborator that has added a lot of work over the last couple of years to increasing the navigation sensor precision of the project. In that time others have come along side him and also added improvements. This has been relative to both fixedwing and multicopter platforms.
The focus has been on better position estimation on the XYZ, under challenging conditions that sensors encounter during flight.
e.g.

• Variations in GNSS EPH/EPV throughout the flight
• Barometric sensor temperature and pressure fluctuations
• Accelerometer vibrations from poor setup
• Compass magnetic deviation
• Pitot trust and fall-back
• General AHRS handling

From this work, INAV can now hit an XY target within 1m most of the time. While hitting Z target can be considerably more inaccurate. Due to various conditions effecting a MC's altitude control targeting while in forward flight.
The result is that INAV navigation can now Tag the XY position target with high certainty.

But the area of navigation flight control that has practically never been touched or scrutinized. Is the XY and Z multicopter approach velocity control to the target position. Whether a WP or the RTH home coordinates.

The key word here is VELOCITY or SPEED of the approach to the WP or home/safehome.

It is an easy thing to Tag the target. But is a completely different thing to approach the target at a higher velocity, then make and hold that target position on the first attempt. Without having to either backup to the XY target or climb/descend to the Z target.
Backing up to the target can be difficult for a MC with a tail wind.
But it can lead to the utter destruction of a VTOL. Because they have so much more Wing, Fuselage, and Stabilizer area for the wind to push against. Making it near impossible for the MC motors to maintain stabilization control over the VTOL airframe under unpredictable wind conditions, when the navigation engine is also trying to drive the VTOL back to the target it overshot.
Besides that. The point at which slowdown occurs at present is based on nav_wp_radius. With this setting being impossible to tune properly under all wind direction conditions. With it being even more difficult for what you require for a VTOL. Because the aircraft not only has to work out at what point to initiate slowdown or stop for a WP pause. But it also has to first transition from a FW to a MC in that same distance. Which will lead to massive overshoot of the WP or RTH home target. Especially with a tailwind.

I also touched on this very issue just recently. If you want to read both my comments in this issue report. And the first comment as well.

Currently the means INAV uses to alter and tune MC approach velocity, before a stop or turn, are these three under the topic- Settings that can influence position accuracy:

Originally when INAV MC WP flight navigation was added. nav_mc_bank_angle and nav_auto_speed where set very low. This made position accuracy much greater. But now days the defaults for both of these settings, which control navigation speed, have been increased. And rightly so. You can't set-out on a WP mission flying at the old default maximum flight speed of 30km/h, and bank angle of 15degs. Then expect the copter will make head way if it encounters even a mild headwind.

I have thought about a way this issue could be address over the years.
Ideally MC wind estimation would help greatly. But it adds so much more setup complexity to the project for users, than FW wind estimation does, that it just wouldn't be worth it.

Present rolling velocity target control is driven by a ControlDerivative related settings nav_mc_vel_xy_dterm_attenuation.
But it uses a more stepped approach to control navigation bank angle.

---

What is effectively required is an assessment of the distance to the XY target position, as well as approach velocity, not a fixed slowdown point. So it can dynamically adjust the point at which slow down occurs, based on those factors, and the bank angle the copter or VTOL is presently cruising with.
Then apply a reduction to the navigation pitch/roll bank angle. So the copter/VTOL can begin to transition and COAST into the WP. (better to undershoot with a tailwind, than to overshoot)
You don't want it to brake until it is moving at a much lower speed: just before the target is reached.. Braking adds even more heading trajectory drift and instability for VTOL's in MC flight.
This is also the reason nav_mc_wp_slowdown doesn't work very well in frontal cross winds, when slowing down. Because it is hard to hold the heading on the target when the nose of the MC is banked backward to brake.. It just gets blown of course and has to realign once braking has finished. And all this with the Yaw axis also causing control instability while trying to fight a possible incorrect wind offset, with respect to the direction the planes vertical stabilizer fin is facing that wind offset.

I know this is a big read. But It needs to be addressed if you want better success with your goal.
VTOL's crash easier if the wind speed is higher and its direction is unpredictable.

[Jetrell]

Have you tested this feature in Poshold Landing descent ?
As mentioned in my last advisory post. The navigation position control on the XY is presently rather good (9.1) when the craft is moving at slower speeds, once the target is met. If your GNSS precision is good and the mag is setup and calibrated properly.
Meaning, under these conditions, I very rarely experience much XY drift from the target with my VTOL's, when even landing in stronger winds.
If drift is experienced. It is generally cause by accelerometer vibrations affecting the position estimation.

My point is. You are using a large number of setting variables here. Which are a limited resource.
And I feel they likely won't be required.

EDIT:
Most landing target inaccuracy on the XY occurs because the user arms when the GNSS position accuracy is low, not long after power-up. Then as the flight progresses and the accuracy becomes better. The MC will return and actually land at the correct position coordinates. Not the coordinates it saved as home at the beginning of the flight, which may have had an error of a meter or two,
If you want absolute landing precision from the exact position you launched from everytime. The only way to ensure this, is to wait 13mins after power up for the almanac and ephemeris data to fully update in the GPS module. Then arm and take off.

[mart1npetroff]

I will be testing this and VTOL auto transition next week probably.
Waiting 13 minutes for GPS data after power up is something I did not try but sounds reasonable and definitely I will try and confirm.
Currently I’m getting landing with around 50 cm up to 2 m offsets.
I also see your concerns about variables and memory and will have that on my mind.
Will share videos from all my tests including target landing without code changes just waiting long enough after power up.

UPDATE: just saw MSP2_INAV_GPS_UBLOX_COMMAND will try to use this one to update almanac and ephemeris data after power up instead of waiting and consuming power for electronics.