Bug Report
SITL quadplane-copter_tailsitter cannot take off in any VTOL mode (Plane 4.7.0)
Bug description
The quadplane-copter_tailsitter SITL frame is unable to perform a VTOL takeoff on ArduPlane V4.7.0 (tag Plane-4.7.0, commit 1511f27). In every VTOL takeoff path tested, the motor mixer immediately saturates with a large sustained pitch-moment demand while the vehicle sits on its tail at the correct hover attitude, leaving no collective headroom to lift off. The vehicle remains on the ground indefinitely with motors at a fixed asymmetric pattern.
The CopterTailsitter autotest is registered in Tools/autotest/quadplane.py and is not in disabled_tests(), so this appears to be expected to work on this release.
How to reproduce (headless, no GCS required)
Build SITL at tag Plane-4.7.0: ./waf configure --board sitl && ./waf plane
Launch with the frame's own CI default parameters:
./build/sitl/bin/arduplane --model quadplane-copter_tailsitter -w --speedup 8
--defaults Tools/autotest/default_params/quadplane.parm,Tools/autotest/default_params/quadplane-copter_tailsitter.parm
--home -35.363262,149.165237,584,353
Connect MAVLink on tcp:5760, wait for EKF3 origin + "using GPS".
Any of the following (all reproduce the failure):
GUIDED user takeoff (the autotest path): set mode GUIDED, arm, send MAV_CMD_NAV_TAKEOFF with param7=60. The command is ACCEPTED (COMMAND_ACK result=0) but the vehicle never leaves the ground.
AUTO mission: mission of NAV_VTOL_TAKEOFF (alt 150) + waypoints; arm in QLOITER, switch to AUTO. "Mission: 1 VTOLTakeoff" is announced; no liftoff.
QSTABILIZE with RC: feed valid RC on SITL RC-in UDP 5501 (all 1500, ch3=1000), set QSTABILIZE, arm, raise ch3 to 1800. No liftoff.
Observed behavior
In all cases, SERVO_OUTPUT_RAW settles within ~1 s of throttle-up to approximately:
motor1 (out5) ~1670 motor2 (out6) ~1670 motor3 (out7) 1150 motor4 (out8) 1950
i.e. front/back motors pinned at opposite limits (a maximum pitch moment in the hover frame), elevator railed, mean motor output ~1610, relative altitude never exceeds ~0.3 m. SIM ground-truth pitch remains 90 deg (resting on tail) throughout; the vehicle is at the attitude the tailsitter controller should treat as hover-level, yet a maximal rotation demand is produced and sustained.
Additional observations:
Disabling assistance (Q_ASSIST_SPEED=0, Q_ASSIST_ANGLE=0, Q_ASSIST_ALT=0) does not change the behavior, so VTOL assist is not the cause.
When arming in GUIDED, "Angle assist r=... p=89" is emitted (plane-frame attitude used in the assist message for a tailsitter standing nose-up), followed by "VTOL Position1 d=0.0" / "Transition VTOL done" while on the ground.
Q_TAILSIT_ENABLE correctly auto-sets to 1 via the motor_mask != 0 heuristic in Tailsitter::setup().
Fixed-wing modes (MANUAL/FBWA) can lift the model off the ground briefly, so the physics model and outputs respond; only the VTOL attitude-control path is affected.
Failure also occurs identically when launched via sim_vehicle.py -f quadplane-copter_tailsitter (WSL2 Ubuntu 24.04) with MAVProxy + Mission Planner as GCS; dataflash logs available on request showing the same 1150/1950 motor signature.
Expected behavior
GUIDED user takeoff / AUTO VTOL_TAKEOFF / QSTABILIZE throttle-up should lift the vehicle vertically, as exercised by the CopterTailsitter autotest.
Version
ArduPlane V4.7.0 (1511f27), SITL (waf --board sitl), Ubuntu 24.04 (native container and WSL2)
Frame: --model quadplane-copter_tailsitter with stock quadplane.parm + quadplane-copter_tailsitter.parm defaults, wiped EEPROM (-w)
Notes
The other SITL tailsitter frame, plane-tailsitter, is already annotated in arduplane.py known_broken_frames as "unstable in hover; unflyable in cruise", which leaves no working tailsitter SITL frame on this release if this issue is confirmed. Happy to provide the full reproduction script, dataflash logs, and servo-output traces.
Bug Report
SITL quadplane-copter_tailsitter cannot take off in any VTOL mode (Plane 4.7.0)
Bug description
The quadplane-copter_tailsitter SITL frame is unable to perform a VTOL takeoff on ArduPlane V4.7.0 (tag Plane-4.7.0, commit 1511f27). In every VTOL takeoff path tested, the motor mixer immediately saturates with a large sustained pitch-moment demand while the vehicle sits on its tail at the correct hover attitude, leaving no collective headroom to lift off. The vehicle remains on the ground indefinitely with motors at a fixed asymmetric pattern.
The CopterTailsitter autotest is registered in Tools/autotest/quadplane.py and is not in disabled_tests(), so this appears to be expected to work on this release.
How to reproduce (headless, no GCS required)
Build SITL at tag Plane-4.7.0: ./waf configure --board sitl && ./waf plane
Launch with the frame's own CI default parameters:
./build/sitl/bin/arduplane --model quadplane-copter_tailsitter -w --speedup 8
--defaults Tools/autotest/default_params/quadplane.parm,Tools/autotest/default_params/quadplane-copter_tailsitter.parm
--home -35.363262,149.165237,584,353
Connect MAVLink on tcp:5760, wait for EKF3 origin + "using GPS".
Any of the following (all reproduce the failure):
GUIDED user takeoff (the autotest path): set mode GUIDED, arm, send MAV_CMD_NAV_TAKEOFF with param7=60. The command is ACCEPTED (COMMAND_ACK result=0) but the vehicle never leaves the ground.
AUTO mission: mission of NAV_VTOL_TAKEOFF (alt 150) + waypoints; arm in QLOITER, switch to AUTO. "Mission: 1 VTOLTakeoff" is announced; no liftoff.
QSTABILIZE with RC: feed valid RC on SITL RC-in UDP 5501 (all 1500, ch3=1000), set QSTABILIZE, arm, raise ch3 to 1800. No liftoff.
Observed behavior
In all cases, SERVO_OUTPUT_RAW settles within ~1 s of throttle-up to approximately:
motor1 (out5) ~1670 motor2 (out6) ~1670 motor3 (out7) 1150 motor4 (out8) 1950
i.e. front/back motors pinned at opposite limits (a maximum pitch moment in the hover frame), elevator railed, mean motor output ~1610, relative altitude never exceeds ~0.3 m. SIM ground-truth pitch remains 90 deg (resting on tail) throughout; the vehicle is at the attitude the tailsitter controller should treat as hover-level, yet a maximal rotation demand is produced and sustained.
Additional observations:
Disabling assistance (Q_ASSIST_SPEED=0, Q_ASSIST_ANGLE=0, Q_ASSIST_ALT=0) does not change the behavior, so VTOL assist is not the cause.
When arming in GUIDED, "Angle assist r=... p=89" is emitted (plane-frame attitude used in the assist message for a tailsitter standing nose-up), followed by "VTOL Position1 d=0.0" / "Transition VTOL done" while on the ground.
Q_TAILSIT_ENABLE correctly auto-sets to 1 via the motor_mask != 0 heuristic in Tailsitter::setup().
Fixed-wing modes (MANUAL/FBWA) can lift the model off the ground briefly, so the physics model and outputs respond; only the VTOL attitude-control path is affected.
Failure also occurs identically when launched via sim_vehicle.py -f quadplane-copter_tailsitter (WSL2 Ubuntu 24.04) with MAVProxy + Mission Planner as GCS; dataflash logs available on request showing the same 1150/1950 motor signature.
Expected behavior
GUIDED user takeoff / AUTO VTOL_TAKEOFF / QSTABILIZE throttle-up should lift the vehicle vertically, as exercised by the CopterTailsitter autotest.
Version
ArduPlane V4.7.0 (1511f27), SITL (waf --board sitl), Ubuntu 24.04 (native container and WSL2)
Frame: --model quadplane-copter_tailsitter with stock quadplane.parm + quadplane-copter_tailsitter.parm defaults, wiped EEPROM (-w)
Notes
The other SITL tailsitter frame, plane-tailsitter, is already annotated in arduplane.py known_broken_frames as "unstable in hover; unflyable in cruise", which leaves no working tailsitter SITL frame on this release if this issue is confirmed. Happy to provide the full reproduction script, dataflash logs, and servo-output traces.