QuadPlane завершает переход VTOL→Plane не по таймеру «на глаз», а по выбранному режиму, типу аппарата и оценке airspeed. Если GCS показывает Transition airspeed wait, вертикальные моторы обычно продолжают поддерживать аппарат, пока скорость не достигнет AIRSPEED_MIN или её оценки. Попытка сократить переход случайным Q_OPTIONS способна превратить зависание в сваливание.
Сначала определи, какой переход не работает
Запиши exact Plane firmware, frame class, тип QuadPlane (обычный lift+cruise, tiltrotor, tailsitter), исходный и целевой режим, GCS messages и DataFlash log. Прямой переход VTOL→fixed wing и обратный переход Plane→VTOL имеют разную логику. Tailsitter использует отдельные углы и rates, поэтому инструкция обычного tiltrotor к нему не применяется.
Переход обычно инициируется сменой flight mode. При выборе Manual или Acro VTOL-моторы могут прекратить поддержку сразу; без достаточной скорости это создаёт риск stall. В других fixed-wing режимах контроллер ждёт минимальную airspeed и постепенно убирает вклад вертикальных моторов. Поэтому первое диагностическое доказательство — mode sequence и сообщение, а не только положение наклонного механизма.
Проверь аппарат до перехода
- Сними пропеллеры и составь таблицу
SERVOx_FUNCTION: lift motors, forward motor, tilt servos и управляющие поверхности должны отвечать реальной проводке. - Проверь motor order/direction и поверхности отдельно в VTOL- и fixed-wing-контуре.
- Убедись, что Q-frame class соответствует геометрии и все tilt endpoints достигаются без механического упора.
- Проверь CG в обеих конфигурациях, питание servo rail и отсутствие просадки силовой батареи при одновременной работе lift и forward motors.
- В SITL или со снятыми пропеллерами подтверди mode mapping и GCS messages. Наземный тест не доказывает аэродинамику, но ловит перепутанные функции.
Не запускай автоматический transition на привязанной модели: контроллер ожидает реальное ускорение и может вывести моторы на высокую мощность. Безопасный ground test ограничивается outputs, направлениями, режимами и логикой сообщений.
Transition airspeed wait не заканчивается
В DataFlash сравни airspeed, groundspeed, pitch, throttle и сообщение перехода. Официальная документация указывает canonical airspeed в CTUN.As: она берётся с датчика либо из synthetic estimate. Если значение не достигает AIRSPEED_MIN, найди причину: forward motor не создаёт тягу, throttle stick/режим не требует её, airspeed sensor нездоров или synthetic estimate и ветер не дают ожидаемой скорости.
Проверь, не тянет ли пилот elevator так, что tiltrotor задерживает ускорение, и как настроен bit 0 Q_OPTIONS. Его смысл — изменение поведения level/climb во время transition, а не «ускорить любой переход». Настройки Q_TRANSITION_MS определяют плавное уменьшение вклада VTOL после достижения скорости; они не заменяют сам критерий airspeed.
Q_TRANS_FAIL задаёт максимальное время forward transition, а связанное действие выбирает реакцию на timeout. Нулевое значение отключает timeout. Не включай Q_OPTIONS bit 19, заставляющий завершить переход при timeout, как универсальный workaround: сначала докажи по логу, что самолёт уже безопасно летит на крыле.
Переход завершается, но аппарат теряет высоту или кренится
Это уже не «не достиг скорости». Сравни attitude demands, VTOL motor output, forward throttle, airspeed и battery voltage до/после момента завершения. Высокий одновременный ток способен просадить LiPo и лишить вертикальные моторы запаса. Официальные docs рекомендуют подтверждать это по логу и при необходимости пересматривать батарею/лимиты мощности, а не увеличивать всё подряд.
Issue-кейсы показывают, что одинаковый внешний симптом возникал из разных причин: историческая ошибка transition на старой firmware, изменение AUTO-логики после VTOL_TAKEOFF и текущий открытый defect знака roll assist у конкретного vectored-yaw tiltrotor в crosswind. Если аппарат совпадает с условиями открытого issue, не проверяй гипотезу полноценным полётом: сверяй release status, воспроизводи в SITL и прикладывай parameter file/log разработчикам.
Обратный переход Plane→VTOL
При выборе Q-режима forward thrust обычно прекращается, поверхности продолжают стабилизировать самолёт, а VTOL-контур тормозит и удерживает высоту согласно режиму. Резкий набор высоты или pitch-up может быть частью торможения. Проверь Q_BACKTRANS_MS, airspeed и выбранный Q-mode; не сравнивай QLOITER, QHOVER и QACRO как одинаковые команды.
До первого обратного перехода проверь, что Q-моторы имеют достаточный hover margin, EKF healthy, GPS доступен для position-hold режимов, а возврат в QSTABILIZE/QHOVER заранее назначен и отработан. Логика QRTL и mission VTOL commands проверяется отдельным сценарием.
Критерий готовности
В SITL и наземных тестах функции/режимы верны; в контролируемом полётном тесте airspeed достигает порога, GCS фиксирует завершение без timeout, просадка питания допустима, attitude остаётся управляемым, а обратный переход заканчивается устойчивым Q-режимом. Параметры и лог сохраняются как baseline. Начальную Plane-настройку смотри в руководстве ArduPlane, анализ — в главе DataFlash/TLOG, тесты миссий — в руководстве SITL.