Skip to content

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

Draft
mart1npetroff wants to merge 3 commits into
iNavFlight:maintenance-10.xfrom
mart1npetroff:msp2-inav-set-precision-landing-and-posh-target
Draft

navigation: add MSP precision landing target consumer for MC/VTOL#11554
mart1npetroff wants to merge 3 commits into
iNavFlight:maintenance-10.xfrom
mart1npetroff:msp2-inav-set-precision-landing-and-posh-target

Conversation

@mart1npetroff
Copy link
Copy Markdown

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

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
Copy link
Copy Markdown

Jetrell commented May 14, 2026

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.

…rify MSP/docs

- Add USE_PRECISION_LANDING compile-time guard in target common defaults
  (enabled for larger-flash targets via common policy)
- Wrap precision landing API/state/config fields with USE_PRECISION_LANDING
  in navigation headers and runtime integration paths
- Guard precision landing MSP handler (MSP2_INAV_SET_PRECISION_LANDING_TARGET)
  and related OSD/nav-state mappings
- Make nav_precision_landing* CLI settings conditional on USE_PRECISION_LANDING
- Update Navigation/MSP docs:
  - build-time availability note
  - precision landing scope/limitations (final correction layer)
  - conservative "Why not SET_WP?" explanation
  - clarify timestamp semantics (informational; freshness by FC receive time)

This keeps behavior unchanged when precision landing is not compiled in and
improves compatibility for flash-constrained targets.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants