Implement auto vtol smooth transition state

[mart1npetroff]

PR #11553 Summary: Smooth VTOL Auto-Transition Controller

This PR adds a smooth VTOL transition controller for aircraft that switch between a fixed-wing mixer profile and a multicopter mixer profile.

Please use latest docs version and specially docs/VTOL.md for main guideline for setup and testing.

The description bellow could be outdated and could contain obsolete settings from old PR commits.

The goal is to keep the existing VTOL mixer-profile workflow usable, while making transitions less abrupt, more airspeed-aware, and safer during both manual and mission-triggered operation.

At a high level, this PR adds:

• optional edge-triggered auto VTOL transitions;
• mission-authorized VTOL transitions using waypoint USER action bits;
• airspeed-first MC->FW transition completion when trusted pitot data is available;
• timer fallback when pitot is unavailable or unhealthy;
• configurable airspeed-timeout abort handling;
• optional dynamic transition scaling for pusher/lift/MC authority/FW authority;
• optional low-speed FW->MC protection;
• mission MC->FW retry logic after airspeed-timeout aborts;
• configurable transition fail actions;
• target fixed-wing stabilized servo preview before profile hot-switch;
• debug support for transition state inspection;
• USE_AUTO_TRANSITION gating so smaller flash targets can keep the pre-existing transition behavior.

This PR does not implement target fixed-wing throttle preview or tilt-motor propulsion blending. Pusher throttle during transition still uses the existing transition pusher throttle convention from the MC mixer profile but with dynamic scaling.

---

Legacy behavior vs current PR behavior

In this summary, “legacy” means the behavior that existed before this PR.

Before this PR:

• MIXER PROFILE 2 directly selected mixer profile 2 while active.

• The default mixer profile was profile 1.

• Existing VTOL examples commonly used:

  • Profile 1 = fixed-wing / FW
  • Profile 2 = multicopter / MC

• MIXER TRANSITION was used as a transition-mixing input, typically overlapping with MIXER PROFILE 2 in the middle switch position.

• A common switch layout was:

  • FW
  • MC + transition
  • MC

With this PR, when the new auto-transition controller is enabled, MIXER TRANSITION becomes an edge-triggered transition request. The transition controller decides the direction from the current active profile and performs the profile hot-switch when the transition completes.

When the auto-transition controller is disabled, manual transition should keep the pre-existing behavior.

---

Example switch topology

This PR should support the long-standing VTOL profile order and overlap-style switch topology used by existing VTOL examples:

Profile 1 = FW
Profile 2 = MC

Example 3-position switch:

Position 1: FW stable mode
  MIXER PROFILE 2 = OFF
  MIXER TRANSITION = OFF

Position 2: transition request / transition mix
  MIXER PROFILE 2 = ON
  MIXER TRANSITION = ON

Position 3: MC stable mode
  MIXER PROFILE 2 = ON
  MIXER TRANSITION = OFF

The important part is the middle position:

Position 2 overlaps:
  MIXER PROFILE 2
  +
  MIXER TRANSITION

With the new auto-transition controller enabled, MIXER TRANSITION is treated as a transition request edge. The controller determines the transition direction from the current active profile:

If currently MC:
  MIXER TRANSITION rising edge requests MC->FW.

If currently FW:
  MIXER TRANSITION rising edge requests FW->MC.

During an active auto transition session, the transition controller temporarily owns the profile-switch decision. This prevents the direct MIXER PROFILE 2 path from immediately overriding the requested smooth transition while the transition is still active.

---

Example: FW->MC using the overlap topology

Start in Position 1:
  Profile 1 / FW
  MIXER PROFILE 2 = OFF
  MIXER TRANSITION = OFF

Move to Position 2:
  MIXER PROFILE 2 = ON
  MIXER TRANSITION = ON

The transition controller sees MIXER TRANSITION rising edge while currently in FW.
It starts a smooth FW->MC transition.
When the transition completes, it hot-switches to MC / Profile 2.

Move to Position 3:
  MIXER PROFILE 2 = ON
  MIXER TRANSITION = OFF

The aircraft remains in MC stable mode.

---

Example: MC->FW using the overlap topology

Start in Position 3:
  Profile 2 / MC
  MIXER PROFILE 2 = ON
  MIXER TRANSITION = OFF

Move to Position 2:
  MIXER PROFILE 2 = ON
  MIXER TRANSITION = ON

The transition controller sees MIXER TRANSITION rising edge while currently in MC.
It starts a smooth MC->FW transition.
When the transition completes, it hot-switches to FW / Profile 1.

Move to Position 1:
  MIXER PROFILE 2 = OFF
  MIXER TRANSITION = OFF

The aircraft remains in FW stable mode.

This overlap topology is important because it matches the established VTOL workflow and user expectations.

---

Automated transition controller

The optional automated controller is enabled with:

mixer_vtol_manualswitch_autotransition_controller = ON

When enabled, auto MIXER TRANSITION becomes edge-triggered:

MIXER TRANSITION OFF -> ON:
  starts one transition request

MIXER TRANSITION ON -> OFF before hot-switch:
  aborts the auto transition request

A new transition request requires:
  OFF -> ON again

The setting should be enabled in both mixer profiles used for VTOL switching.

The controller has a session latch so that the transition does not unexpectedly change behavior immediately after the profile hot-switch. This matters because mixer settings are profile-specific, but an active transition session must remain consistent across the source and destination profiles.

---

Direct profile switching vs transition-controller switching

The current PR keeps two separate paths:

MIXER PROFILE 2:
  direct manual profile selection path

MIXER TRANSITION:
  smooth transition-controller request path when auto-transition is enabled

During an active auto transition session, the transition controller owns profile switching.

Outside an active transition session, direct MIXER PROFILE 2 selection remains available.

This distinction is important for the overlap topology. In the middle switch position, both MIXER PROFILE 2 and MIXER TRANSITION can be active. The controller must prevent the direct profile-switch path from immediately defeating the requested smooth transition.

---

Mission-authorized VTOL transitions

This PR adds mission-authorized VTOL transitions through a configured waypoint USER action bit:

nav_vtol_mission_transition_user_action = USER1 / USER2 / USER3 / USER4

The selected USER bit acts as an absolute target selector on each navigable waypoint:

selected USER bit = 0:
  target is MC / MULTIROTOR

selected USER bit = 1:
  target is FW / AIRPLANE

This is not a toggle. It is a per-waypoint target-state declaration.

Example:

Waypoint A:
  USER1 clear
  target = MC

Waypoint B:
  USER1 set
  target = FW

Waypoint C:
  USER1 set
  target = FW
  already in FW, so action is idempotent

Waypoint D:
  USER1 clear
  target = MC

During mission transition, mission progression pauses while the transition is in progress and resumes only after transition completion.

---

Airspeed-first completion

For MC->FW transitions, this PR can use trusted pitot airspeed as the primary completion condition.

Example:

vtol_transition_to_fw_min_airspeed_cm_s = 1400

Behavior:

MC->FW transition starts.
Forward propulsion / transition mixing starts.
If trusted pitot is available, completion waits until the target airspeed is reached.
Only then does the controller hot-switch to the FW profile.

If pitot is unavailable or unhealthy, or the configured threshold is disabled, transition completion falls back to the configured timer path.

The key point is that airspeed is used for transition completion only when trusted pitot data is available.

---

Timer fallback and airspeed timeout

The PR distinguishes between:

mixer_switch_trans_timer

and:

mixer_vtol_transition_airspeed_timeout_ms

They serve different purposes.

mixer_switch_trans_timer is the fallback completion timer. It is used when airspeed-controlled completion is not active.

mixer_vtol_transition_airspeed_timeout_ms is an abort timeout for the airspeed-controlled path. It only applies while the controller is waiting for trusted pitot airspeed to satisfy the transition threshold.

Example:

Trusted pitot available:
  completion waits for airspeed threshold

Airspeed threshold not reached before timeout:
  transition aborts or follows configured failure handling

Pitot unavailable/unhealthy:
  controller uses timer fallback instead

For airspeed-first setups, reviewers should check that the fallback timer is non-zero and reasonable, so pitot-loss fallback does not complete immediately.

---

Dynamic transition scaling

The PR adds optional dynamic scaling:

mixer_vtol_transition_dynamic_mixer = ON

When enabled, transition progress can scale:

forward propulsion / pusher contribution
lift motor contribution
MC stabilization authority
FW stabilization authority
target-FW stabilized servo preview outputs

The current setting names use “min” semantics, for example:

vtol_transition_lift_min_percent
vtol_transition_mc_authority_min_percent
vtol_transition_fw_authority_min_percent

These values should be understood as minimum/floor authority values.

Example:

MC->FW:
  FW authority starts at its configured minimum and ramps toward 100%.

FW->MC:
  FW authority starts at 100% and fades down toward its configured minimum.

The optional scale ramp timer controls the ramping of transition scaling independently from airspeed completion. For example, forward propulsion can ramp in quickly while the final MC->FW hot-switch still waits for airspeed.

---

Target fixed-wing stabilized servo preview

The PR adds new servo input sources:

INPUT_AUTOTRANSITION_TARGET_STABILIZED_ROLL
INPUT_AUTOTRANSITION_TARGET_STABILIZED_PITCH
INPUT_AUTOTRANSITION_TARGET_STABILIZED_YAW

These are intended for fixed-wing control surfaces that should become active during MC->FW transition before the actual profile hot-switch.

Example:

MC profile:
  elevator servo rule uses INPUT_AUTOTRANSITION_TARGET_STABILIZED_PITCH

During MC->FW:
  the elevator starts receiving a target-FW pitch stabilization preview
  the output is scaled by FW authority
  the eventual hot-switch to FW should have less servo discontinuity

For FW->MC, matching FW stabilized authority fades down instead of being removed abruptly.

This preview is intended to approximate the target FW control behavior closely enough for a smoother transition.

---

Tilt servos and transition geometry

Tilt servos, nacelles, and other mechanical transition geometry should continue to use:

INPUT_MIXER_TRANSITION

This is the transition-progress input.

Example:

MC->FW:
  INPUT_MIXER_TRANSITION moves from MC position toward FW position
  tilt servos move motors/nacelles forward

FW->MC:
  INPUT_MIXER_TRANSITION moves back toward MC position
  tilt servos move motors/nacelles vertical

The new INPUT_AUTOTRANSITION_TARGET_STABILIZED_* inputs are not for tilt geometry. They are for stabilized fixed-wing control outputs such as elevator, aileron, or rudder-like surfaces.

---

Pusher throttle behavior

This PR keeps the existing transition pusher throttle model.

Dedicated transition pusher behavior still uses the existing MC mixer throttle convention but adds dynamic scaling , for example:

throttle value between -1 and -2

This PR does not add:

target-FW throttle preview
tilt-motor propulsion blending

Those features are intentionally out of scope for this PR because PR is big enough so far and they require mixer Configurator UI changes.

Future work could add explicit target-FW propulsion preview:

Dedicated pusher:
  target FW throttle output * transition propulsion scale

Tilt motor:
  MC lift/control contribution
  +
  target FW propulsion contribution

But that will be a separate PR later. Current testing with pusher VTOL is giving great results even with throttle value between -1 and -2 in mixer.

---

Low-speed FW->MC protection

The PR adds optional low-speed FW->MC protection:

vtol_fw_to_mc_auto_switch_airspeed_cm_s

When configured, if the aircraft is in FW mode, valid pitot is available, and airspeed drops below the configured threshold, the controller can request a smooth FW->MC transition automatically.

Example:

Aircraft is flying in FW profile.
Airspeed drops below configured threshold.
Controller starts FW->MC transition.
When complete, it switches to MC profile.
A latch prevents direct MIXER PROFILE 2 state from immediately forcing the aircraft back into FW.
Pilot must make a deliberate switch action to resume normal profile selection.

This latch is important for the overlap topology, because the RC switch may still physically indicate the previous stable profile position when the protection transition completes.

---

Mission MC->FW retry and fail actions

The PR adds configurable retry behavior for mission MC->FW transitions that abort due to airspeed timeout.

Example:

Mission requests MC->FW.
Transition starts.
Airspeed threshold is not reached before timeout.
Transition aborts.
If retry is enabled and pitot is valid, aircraft performs a heading scan.
The controller samples trusted pitot airspeed during the scan.
Best heading is selected.
One retry is attempted.
If retry fails, configured fail action is executed.

The retry scan includes safeguards:

valid pitot required
trusted airspeed sample required
per-heading-step timeout
overall retry scan timeout
no infinite yaw-scan hang

Fail actions are configurable separately for MC->FW and FW->MC failures. The current PR should ensure that “LOITER” style FW->MC failure behavior maps to a local position-hold style behavior, not an unexpected RTH path.

Those retries and fail actions are implemented mainly to provide stable "PLAN B, C..." in case when automated mission is executing and one of both (lift motors or pusher) fails for some reason (blown motor for example)

---

USE_AUTO_TRANSITION gating

The smooth transition functionality is conditionally compiled behind:

USE_AUTO_TRANSITION

The intended split is:

Targets with enough flash:
  smooth auto-transition features enabled

Small / 512 KB targets:
  pre-existing transition behavior retained
  smooth auto-transition settings hidden/unavailable

Reviewers should verify both build paths:

USE_AUTO_TRANSITION enabled target:
  new controller builds and works

USE_AUTO_TRANSITION disabled target:
  no references to auto-transition-only fields/functions/settings
  pre-existing transition behavior still builds and works

This is one of the most important review areas because the PR adds conditional fields, settings, enums, and code paths.

---

Practical examples

Example 1: Existing overlap-style VTOL switch

Profile 1 = FW
Profile 2 = MC

Switch position 1:
  FW stable
  MIXER PROFILE 2 OFF
  MIXER TRANSITION OFF

Switch position 2:
  transition request
  MIXER PROFILE 2 ON
  MIXER TRANSITION ON

Switch position 3:
  MC stable
  MIXER PROFILE 2 ON
  MIXER TRANSITION OFF

This is the example reviewers should keep in mind when checking auto transition behavior.

Example 2: MC->FW with airspeed-first completion

Start in MC stable position.
Move switch to transition position.
Controller starts MC->FW.
Pusher/transition propulsion ramps in.
Lift/MC/FW authority scales according to configuration.
If trusted pitot is healthy, completion waits for target airspeed.
Controller hot-switches to FW.
Pilot moves switch to FW stable position.

Example 3: FW->MC from the same switch topology

Start in FW stable position.
Move switch to transition position.
Controller starts FW->MC.
FW authority fades down.
MC/lift authority returns.
Controller hot-switches to MC.
Pilot moves switch to MC stable position.

Example 4: Tilt servo transition geometry

Tilt servo rule uses INPUT_MIXER_TRANSITION.

MC->FW:
  tilt servo moves gradually from vertical to forward position.

FW->MC:
  tilt servo moves gradually from forward to vertical position.

Example 5: Target-FW elevator preview

MC profile has an elevator servo rule:
  INPUT_AUTOTRANSITION_TARGET_STABILIZED_PITCH

During MC->FW:
  elevator begins receiving target-FW pitch stabilization preview.
  Output scales with FW authority.
  Hot-switch to FW should produce a smaller servo step.

Out of scope:
Do not expect target-FW throttle preview or tilt-motor propulsion blending in this PR.

[Jetrell]

Thanks for your VTOL contribution to INAV. They will be welcome improvements

I have a couple of questions.

I noticed you have an edge trigger for the transition switch, along with the legacy 3Pos manual method.
I'm wondering if this might be less intuitive for users who are familiar with the legacy 3Pos toggle switch ? Which could cause confusion for those used to the legacy method, but still want to use the airspeed/timer method.

I also noticed your addition of Dynamic Scaling. Of which I like the idea.
However it would seem the timer for the scaling is controlled by mixer_switch_trans_timer. Which would seem to indicate the scaling is ramped over that whole time period.
I thought this could be an issue.. In the example of the 'pusher contribution' on a 4 + 1. If the plane requires 80% throttle to gain a good MC to FW transition speed. And the mixer_switch_trans_timer was set to a reasonable value of 5s. It would mean that 80% throttle would not be reached until right before transition ended, if mixer_switch_trans_airspeed_cm_s wasn't met in that time period.
I would have thought it might be more intuitive for users to have another timer that could be set to a shorter period. To specifically overcome harsh motor startup torque reaction on larger tilt-rotors / 4+1's. Or the short transition instability that occurs between mixer changes, as the plane settles into that flight state.
While leaving mixer_switch_trans_timer as just a transition time backup for mixer_switch_trans_airspeed_cm_s ?

[mart1npetroff]

Great feedback, thank you.

On the 3-position manual method question:

I agree this can be confusing if not documented clearly, so I should clarify it better in the PR/docs. The intent is not to replace legacy behaviour. The edge-triggered manual controller is optional (manual_vtol_transition_controller), and legacy 3-position/manual behaviour remains available when that setting is OFF.

my intention is still to support practical 3-position switch workflow when manual_vtol_transition_controller = ON, not to remove it.
A typical setup can still be:

Position 1: MC
Position 2: Auto Transition
Position 3: FW
When manual_vtol_transition_controller = ON, position 2 is used as a trigger to start the AUTO transition sequence.
In real use, I can fly in MC, move the switch to Transition, let the controller complete the automatic transition, then move the switch to FW after completion. For FW->MC, I do the same in reverse order.

So the goal is to keep familiar switch ergonomics, while making transition execution more deterministic and safer.

On the dynamic scaling timer point: I agree this is a good observation.
Scaling follows airspeed progress when pitot is healthy/available, and falls back to timer-based progress when pitot is unavailable. In fallback cases, using only mixer_switch_trans_timer can make ramp-up too slow for some setups.

I propose an optional separate setting:

vtol_transition_scale_ramp_time_ms

with behavior:

0 (default): keep current behavior (backward compatible)

0: use this timer only for scaling ramp (pusher/lift/authority), while transition completion logic remains unchanged (airspeed-first; mixer_switch_trans_timer still acts as fallback completion timer when pitot is unavailable/unhealthy)
Example:

mixer_switch_trans_timer = 5000 ms
vtol_transition_scale_ramp_time_ms = 1200 ms
This gives:

scaling reaches target levels in about 1.2s (smoother motor startup / less torque step),
completion still waits for airspeed threshold when pitot is healthy,
if pitot is not available, completion fallback still uses the 5s transition timer.
If this direction makes sense to you, I can implement it in a follow-up patch after agreement.

When pitot is healthy/available, transition progress is airspeed-driven (not timer-driven).

• MC -> FW:

  • progress = constrain(airspeed / to_fw_threshold, 0..1)
  • completion condition = airspeed >= to_fw_threshold

• FW -> MC:

  • capture startAirspeed when transition starts
  • progress = constrain((startAirspeed - airspeed) / (startAirspeed - to_mc_threshold), 0..1)
  • completion condition = airspeed <= to_mc_threshold

Dynamic mixer scaling (vtol_transition_dynamic_mixer = ON) uses this progress:

• MC -> FW:

  • pusher scale ramps 0 -> 1
  • lift scale ramps 1 -> vtol_transition_lift_end_percent
  • MC authority ramps 1 -> vtol_transition_mc_authority_end_percent
  • FW authority ramps vtol_transition_fw_authority_start_percent -> 1

• FW -> MC:

  • pusher scale ramps 1 -> 0
  • lift scale ramps vtol_transition_lift_end_percent -> 1
  • MC authority ramps vtol_transition_mc_authority_end_percent -> 1
  • FW authority ramps 1 -> vtol_transition_fw_authority_start_percent

For transition/pusher motors (-2.0 < throttle < -1.0), output is interpolated from idle to target:

motor = idle + (target - idle) * pusherScale

where:

• target = -mixerThrottle * 1000
• idle = throttleRangeMin

[Jetrell]

If this direction makes sense to you, I can implement it in a follow-up patch after agreement.

Position 1: MC
Position 2: Auto Transition
Position 3: FW

vtol_transition_scale_ramp_time_ms = 1200 ms

Yes I agree with both changes you have proposed.

Do you happen to have the RealFlight simulator software to test this with the SITL before an actual flight? I unfortunately don't have it.

[mart1npetroff]

Changes pushed and PR updated.

No I do not have RealFlight on my site right now but while ago I tested some scenarios with X-Plane and Alia 250 eVTOL.
I will provide update and hopfully videos after test flights.

One more question: Currently I'm using one of User Actions in WP (configurable) for target selection in mission. Do you think this is good approach or is it better to use bit 5 (which is currently reserved) from WP's p3 instead?

[github-actions]

Test firmware build ready — commit 3699c17

Download firmware for PR #11553

238 targets built. Find your board's .hex file by name on that page (e.g. MATEKF405SE.hex). Files are individually downloadable — no GitHub login required.

Development build for testing only. Use Full Chip Erase when flashing.

[Jetrell]

I've had a bit of a look through your later commits and the docs you have added. And need to point out a few things.

In keeping with consistency. I noticed you have stated in your Docs, the use of Profile 1 for MC and Profile 2 for FW. While the legacy documentation show it to be the other way around. i.e. Profile 1 for FW and Profile 2 for MC.
I know it can work both ways. However it was originally noted that the VTOL is first a fixedwing aircraft (mixer profile 1). And secondary a multicopter (mixer profile 2).
You quoted in the docs -

Recommended switch topology (explicit):

Does explicit mean it excludes it from working in the legacy way that I mentioned above ?

I have also read through your Documents and Setting descriptions. And I have to say they are not easy to follow.
I don't say this out of criticism. But rather to inform you of how the wording of such a document is of the greatest importance. Because most users just get confused by technical terms. The documentation needs to be in simple layman's terms.
I want to see your work here add benefit to iNAV. Rather than confusing people even more than VTOL setup already does.
One of the biggest issues most people have with Ardupilot VTOL setup, is the complexity. This is why many come here.

I have made a start on rewording your documents for this pull request. And when I have them finished. If you don't mind ? I can post them here to see what you think.
In fact I have been thinking of rewording even some of the older legacy stuff too. Which also confuses some users in places.

I also have a few other function related questions, about your implementation. But I'll ask about that later.

[mart1npetroff]

Thanks, this is very helpful feedback.

You were right on both points.

I had left the newer wording inconsistent with the long-standing VTOL convention used in the older docs. I have now aligned the documentation so it consistently uses:

• Profile 1 = fixed-wing
• Profile 2 = multicopter

I also reworded the switch section. “Recommended switch topology (explicit)” was not meant to imply that other arrangements are unsupported. What I wanted to show was a clear 3-position example. The wording now reflects that more clearly, and it also notes that the firmware can still work with the profiles swapped if someone intentionally sets it up that way.

I also simplified some of the setup wording in the VTOL docs to make it easier to follow for non-technical users.

I agree that VTOL documentation needs to stay as simple and practical as possible, and I’d be happy to incorporate improvements there, including cleanup of older wording where it helps.

Feel free to send the function-related questions too when ready.

[Jetrell]

I also simplified some of the setup wording in the VTOL docs to make it easier to follow for non-technical users.
I agree that VTOL documentation needs to stay as simple and practical as possible, and I’d be happy to incorporate improvements there, including cleanup of older wording where it helps.

That sounds great.
The more you can use direct and simple wording that is applicable to the layman, the better.

Try to think of it from the perspective of someone who has no idea of what your improvements do. Don't assume they understand any of the setting operations, as you do.
Then use simple wording that the average hobbyist will be familiar with... Then expound directly on what that setting does. And don't diverge too much from the topic.

For example. In your setting explanations and docs. Perhaps use a descriptor like RPM speed ramp-up in place of SCALE.
And the name of the device (motor or servo) that is being controlled, in place of a word like AUTHORITY.

I hope that make sense.

[mart1npetroff]

PR is stable for final testing. Everyone are welcome to try.
Please take a good read at docs/VTOL.md and be careful.
All of you could ask me questions here or in discord.
I will make INAV Configurator updates as well later after we merge this PR. I'm planning dedicated VTOL tab for the configurator so once I have the plan clear will share it for further discussion and thoughts.

[Sibre3]

Does it have OSD system messages to inform us of when a state is in operation or complete?

I will make INAV Configurator updates as well later after we merge this PR. I'm planning dedicated VTOL tab for the configurator so once I have the plan clear will share it for further discussion and thoughts.

This will be extremely helpful.

[mart1npetroff]

Yes, system osd messages are available after latest commits.

[Jetrell]

@mart1npetroff I've been going over your code and docs. And I have to say, you are covering all the bases with this PR.
It's a huge amount of work you're putting in... It's taken me a fair bit of time to just assimilate most of the changes.. But they were certainly required, based on past issue reports.. Thanks for going to this much effort.

I'm presently setting up a plane for ground testing, and altering my Diff to suit these changes. I'm not sure when I will get out to flight test it, because its winter here. With the whether not being too good. Plus, I don't want to rush this. I want to understand what each settings is doing in its fullness.

[mart1npetroff]

Fully autonomous flight including: MC take off, MC->FW transition, FW flight, FW->MC transition, RTH and landing.
Video: https://youtu.be/zX_wN9fN4HY?si=mCShXQvK7AEf6k8p
Mission accomplished.

[Mick51]

Bravo, you’ve done a truly colossal amount of work. Does it also work with tailsitters ? If it does, I absolutely have to give it a try.

[Mick51]

I would like to integrate the PR into the iNav 9.1 version for an AtomRC F405 Navi. Do you think that's possible ?

[sensei-hacker]

integrate the PR into the iNav 9.1

I think back-porting this back to 9.1 would be quite a bit of work. Any reason not to try this branch? Or maintenance-10.x when this is ready to merge?

[Mick51]

Fully autonomous flight including: MC take off, MC->FW transition, FW flight, FW->MC transition, RTH and landing. Video: https://youtu.be/zX_wN9fN4HY?si=mCShXQvK7AEf6k8p Mission accomplished.

Does this work for a tailsitter ?

[Mick51]

integrate the PR into the iNav 9.1

I think back-porting this back to 9.1 would be quite a bit of work. Any reason not to try this branch? Or maintenance-10.x when this is ready to merge?

I installed the firmware he suggested, but before trying it, I'd like to know if it will work with a tailsitter.

[mart1npetroff]

integrate the PR into the iNav 9.1

I think back-porting this back to 9.1 would be quite a bit of work. Any reason not to try this branch? Or maintenance-10.x when this is ready to merge?

I installed the firmware he suggested, but before trying it, I'd like to know if it will work with a tailsitter.

With the current implementation, it is not safe to test the new auto-transition controller on a tailsitter in flight. The functionality has been developed and tested on tilt-motor and pusher VTOL configurations.
The MC-to-FW transition may work, but FW-to-MC is currently risky and has not been designed or validated for the tailsitter-specific orientation change.
Before we take any action, please read the VTOL.md documentation carefully several times and perform thorough bench tests without propellers. This would be valuable feedback and can help us extend this PR to properly support tailsitter configurations.
If you are willing to help test the functionality and can provide Blackbox logs, configuration dumps, and video after each test, I can prepare an initial manual-test build for a tailsitter. We can then develop the full implementation step by step.
Please note that I do not own a tailsitter platform, so I cannot validate this myself. You would effectively be the initial test pilot for this work, so all testing must start conservatively on the bench and progress to very cautious flight tests only when the previous stage is confirmed safe.

[Mick51]

Entering CLI Mode, type 'exit' to return, or 'help' #

Building AutoComplete Cache...Done!

get mixer_vtol_manualswitch_autotransition_controller

mixer_vtol_manualswitch_autotransition_controller = ON
Allowed values: OFF, ON

get vtol

mixer_vtol_transition_dynamic_mixer = OFF
Allowed values: OFF, ON

mixer_vtol_manualswitch_autotransition_controller = ON
Allowed values: OFF, ON

mixer_vtol_transition_airspeed_timeout_ms = 0
Allowed range: 0 - 60000

mixer_vtol_transition_scale_ramp_time_ms = 0
Allowed range: 0 - 60000

nav_vtol_mission_transition_user_action = OFF
Allowed values: OFF, USER1, USER2, USER3, USER4

nav_vtol_mission_transition_min_altitude_cm = 0
Allowed range: 0 - 50000

nav_vtol_transition_retry_on_airspeed_timeout = OFF
Allowed values: OFF, ON

nav_vtol_transition_fail_action_mc_to_fw = IDLE
Allowed values: IDLE, POSH, RTH, EMERGENCY_LANDING

nav_vtol_transition_fail_action_fw_to_mc = LOITER
Allowed values: IDLE, LOITER, RTH, EMERGENCY_LANDING, FORCE_SWITCH

vtol_transition_to_fw_min_airspeed_cm_s = 0
Allowed range: 0 - 20000

vtol_transition_to_mc_max_airspeed_cm_s = 0
Allowed range: 0 - 20000

vtol_fw_to_mc_auto_switch_airspeed_cm_s = 0
Allowed range: 0 - 20000

vtol_transition_lift_min_percent = 100
Allowed range: 0 - 100

vtol_transition_mc_authority_min_percent = 100
Allowed range: 0 - 100

vtol_transition_fw_authority_min_percent = 100
Allowed range: 0 - 100

vtol_mc_protection_mode = OFF
Allowed values: OFF, NAV, NAV_AND_STABILIZED

vtol_mc_thr_reserve_percent = 15
Allowed range: 0 - 40

Show less

Diagnosed firmware gap and weighed reflash versus Workaround Paths
Diagnosed firmware gap and weighed reflash versus workaround paths
Your get vtol command definitively settles the matter: you have absolutely all the VTOL settings from the PR (dynamic_mixer, timeouts, fail_actions, vtol_transition_*, vtol_mc_protection_mode…) except for one — vtol_autotransition_always doesn't appear in the list.

So it's confirmed: your build contains everything that was added up to ~end of June (the MC protection from June 15th, the renaming to _min_percent…), but not the commit from July 3rd which specifically introduced the 2-position mode. The "Jul 8" label on your firmware is misleading on this point. Nothing needs correcting in the file: the name is correct, it's just missing from your binary.

Your GET also confirms my choices: all three airspeed thresholds are at 0 → timer completion, which is exactly the correct benchmark behavior without me having to invent any speeds.

Two paths, the choice is yours:

A. You want the true 2-position (position = desired mode). Reflash the latest pr-test-builds (Full Chip Erase). My 2-position file will work as is, without any changes. This is the only way to achieve this ergonomics.

B. You test now without reflashing → 3-position. And good news: your diff from July 8th already has the correct aux wiring (PROFILE 2 at 1300-2100, TRANSITION at 1300-1700, the correct overlap), and your controller is already ON. Almost nothing is missing for smooth transitions to work on this build, via the middle position. I'll regenerate a clean 3-position file from your ATOMRC diff in 30 seconds.

A "pure" 2-position switch isn't properly implemented on your current build (the only workaround would be to pulse MIXER TRANSITION on a 2-position switch, but that's a relative toggle, not a mode selection—fiddly in flight, I don't recommend it).

[Mick51]

A firmware update would be needed for the automatic transition to work on a 2-position switch; with the higher firmware versions, the 2-position mode cannot function.

[Mick51]

Intégrer le PR dans iNav 9.1

Je pense que le portage vers la version 9.1 représenterait un travail considérable. Y a-t-il une raison de ne pas essayer cette branche ? Ou la branche maintenance-10.x lorsque celle-ci sera prête à être fusionnée ?

J'ai installé le firmware qu'il m'a suggéré, mais avant de l'essayer, j'aimerais savoir s'il fonctionnera avec un système de maintien de l'arrière de la moto.

Dans sa version actuelle, il est dangereux de tester le nouveau contrôleur de transition automatique sur un aéronef à décollage et atterrissage vertical (ADAV) à hélices basculantes en vol. Cette fonctionnalité a été développée et testée sur des configurations ADAV à moteurs basculants et à hélices propulsives. La transition MC-FW pourrait fonctionner, mais la transition FW-MC est actuellement risquée et n'a pas été conçue ni validée pour le changement d'orientation spécifique aux ADAV. Avant toute action, veuillez lire attentivement la documentation VTOL.md à plusieurs reprises et effectuer des tests approfondis sur banc d'essai sans hélices. Vos retours seront précieux et nous permettront d'améliorer cette PR afin de prendre en charge correctement les configurations ADAV. Si vous souhaitez participer aux tests et fournir les journaux Blackbox, les dumps de configuration et une vidéo après chaque test, je peux préparer une première version de test manuelle pour un ADAV. Nous pourrons ensuite développer l'implémentation complète étape par étape. Veuillez noter que je ne possède pas d'ADAV et ne peux donc pas la valider moi-même. Vous seriez en quelque sorte le pilote d'essai initial pour ces travaux ; par conséquent, tous les essais doivent commencer de manière prudente sur banc d'essai et ne progresser vers des essais en vol très prudents que lorsque l'étape précédente est confirmée comme sûre.

Thanks for the detailed and honest reply — understood on all points, especially that FW->MC is the risky direction on a tailsitter and that the orientation change hasn't been designed or validated for it yet.

I'm happy to act as the initial test pilot for the tailsitter case, and I'll follow a strict bench-first, props-off methodology, only progressing to very cautious flight once each stage is confirmed safe. I'll re-read VTOL.md thoroughly before touching anything.

My platform:

• AtomRC Penguin, twin-motor tractor, converted to an experimental tailsitter. mixer_profile 1 = AIRPLANE/FW, mixer_profile 2 = MC with tailsitter_orientation_offset = ON, roll via differential thrust.
• FC: AtomRC F405 NAVI, 6S, CRSF/ELRS.
• No real airspeed sensor: pitot_hardware = VIRTUAL, so airspeed-first completion won't apply — I'll be on the mixer_switch_trans_timer fallback (all vtol_transition_*_airspeed thresholds at 0).
• My currently flashed build has the full auto-transition settings set EXCEPT vtol_autotransition_always (the build predates the Jul 3 commit — get vtol confirms it's the only one missing), so I'm on the 3-position MIXER TRANSITION workflow for now.

After every run I can provide: Blackbox logs (with debug_mode = VTOL_TRANSITION), a full diff all, and video showing the model, the Configurator horizon, and the OSD messages.

If you can prepare an initial manual-test build for a tailsitter, I'll start on the bench with orientation and mixing-sign checks, then armed transitions beginning with MC->FW, and leave FW->MC for last and most cautiously.

Could you let me know which commit/build to flash, and whether there's any specific debug channel or test sequence you'd like me to capture first? Happy to iterate step by step.

[mart1npetroff]

Please test this on the bench first, with propellers removed.

This is the first experimental tailsitter auto-transition implementation. (latest changes are pushed)
It is intentionally limited to manual/supervised transitions. Do not use it for missions, RTH, landing, failsafe, or automatic low-speed recovery yet. I do not have a tailsitter airframe, so flight testing must be very careful and supported by blackbox logs.

Example profile layout:

mixer_profile 1
set platform_type = AIRPLANE
set tailsitter_orientation_offset = OFF
set mixer_vtol_manualswitch_autotransition_controller = ON
set mixer_vtol_transition_dynamic_mixer = OFF
set mixer_switch_trans_timer = 50
set mixer_vtol_transition_airspeed_timeout_ms = 8000

mixer_profile 2
set platform_type = MULTIROTOR
set tailsitter_orientation_offset = ON
set mixer_vtol_manualswitch_autotransition_controller = ON
set mixer_vtol_transition_dynamic_mixer = OFF
set mixer_switch_trans_timer = 50
set mixer_vtol_transition_airspeed_timeout_ms = 8000

set vtol_transition_to_fw_min_airspeed_cm_s = 1200
set vtol_transition_to_mc_max_airspeed_cm_s = 900
save

Use safe values appropriate for the airframe. The values above mean:
MC -> FW: waits for 12 m/s airspeed, or uses the existing 5 second timer fallback if airspeed is unavailable.
FW -> MC: waits until valid airspeed is at or below 9 m/s. It deliberately has no timer fallback.
FW -> MC without usable airspeed: OSD should show VTOL NO SPEED; after 8 seconds it should abort and remain in FW.
Expected FW -> MC sequence with valid airspeed:
Select the manual transition request.
INAV waits for airspeed at or below the configured FW -> MC limit.
INAV switches to the MC profile.
OSD shows VTOL TAILSITTER CAPTURE.
The existing 45-degree tailsitter attitude target remains active until pitch is stable between 35 and 55 degrees for 300 ms.
INAV reports transition completion.
If the switch is returned to the FW endpoint during the capture phase, INAV must start the normal MC -> FW transition. It must not direct-switch between reference frames.

Before any flight:
Verify the MC profile uses tailsitter_orientation_offset = ON and the FW profile uses it OFF.
Verify Configurator model orientation and motor/servo directions.
Verify FW -> MC without airspeed refuses to hot-switch.
Record DEBUG_VTOL_TRANSITION during every initial test.
Share CLI diff, blackbox log, airframe description, and video for each result.

[Mick51]

Veuillez d'abord tester cela sur un banc d'essai, hélices retirées.

Il s'agit de la première implémentation expérimentale de transition automatique pour avion à décollage et atterrissage vertical. (Les dernières modifications sont intégrées.) Elle est volontairement limitée aux transitions manuelles/supervisées. Ne l'utilisez pas encore pour les missions, le retour au point de départ, l'atterrissage, la sécurité intégrée ou la récupération automatique à basse vitesse. Je ne dispose pas d'un appareil à décollage et atterrissage vertical, les essais en vol doivent donc être extrêmement prudents et documentés par des enregistrements de données (boîte noire).

Exemple de mise en page de profil :

mixer_profile 1
set platform_type = AIRPLANE
set tailsitter_orientation_offset = OFF
set mixer_vtol_manualswitch_autotransition_controller = ON
set mixer_vtol_transition_dynamic_mixer = OFF
set mixer_switch_trans_timer = 50
set mixer_vtol_transition_airspeed_timeout_ms = 8000

mixer_profile 2
set platform_type = MULTIROTOR
set tailsitter_orientation_offset = ON
set mixer_vtol_manualswitch_autotransition_controller = ON
set mixer_vtol_transition_dynamic_mixer = OFF
set mixer_switch_trans_timer = 50
set mixer_vtol_transition_airspeed_timeout_ms = 8000

set vtol_transition_to_fw_min_airspeed_cm_s = 1200
set vtol_transition_to_mc_max_airspeed_cm_s = 900
save

Utilisez des valeurs sûres adaptées à la cellule. Les valeurs ci-dessus signifient : MC → FW : attend une vitesse de 12 m/s ou utilise le délai de secours de 5 secondes si la vitesse est indisponible. FW → MC : attend que la vitesse soit inférieure ou égale à 9 m/s. Aucun délai de secours n’est prévu. FW → MC sans vitesse utilisable : l’OSD doit afficher « VTOL NO SPEED » ; après 8 secondes, la transition doit s’interrompre et l’aéronef reste en mode FW. Séquence FW → MC attendue avec une vitesse valide : sélectionnez la demande de transition manuelle. INAV attend une vitesse inférieure ou égale à la limite FW → MC configurée. INAV bascule sur le profil MC. L’OSD affiche « VTOL TAILSITTER CAPTURE ». L’assiette cible de 45 degrés reste active jusqu’à ce que le tangage soit stable entre 35 et 55 degrés pendant 300 ms. INAV signale la fin de la transition. Si le commutateur est ramené au point final FW pendant la phase de capture, INAV doit démarrer la transition MC → FW normale. Il ne doit pas y avoir de commutation directe entre les référentiels.

Avant tout vol : vérifiez que le profil MC active l’option tailsitter_orientation_offset et que le profil FW la désactive. Vérifiez l’orientation du modèle dans le configurateur et le sens de rotation des moteurs/servos. Vérifiez que la commutation à chaud FW → MC, sans vitesse, est impossible. Enregistrez DEBUG_VTOL_TRANSITION lors de chaque test initial. Partagez les différences CLI, le journal de bord, la description de la cellule et la vidéo pour chaque résultat.

Thanks a lot 🙏. Is there new firmware available for testing ? Or do I need to compile the new firmware myself ?

[error414]

I'm satisfied how it works, I attahed config, it's a good base for asjust transition to be more smoother.

https://www.youtube.com/watch?v=LoUvT63j46w

INAV_9.1.0_cli_T1_20260723_184733.txt