Oscillation Crash and high wind problems when retuning VTOL Trimotor plane with front tilt

ArduPlane Plane 4.6
1

I am trying to remaiden a VTOL plane tricopter’-style with two front tilt motors which was flown succesfully a couple of years ago.

Yesterday I was able to get it up flying again with 4.3 Ardupilot and pids which seem to be the original ones.

I managed to do three short flights in QSTABILIZE, QHOVER and QLOITER mode and the plane seemed to behave well, with battery starting at 16.2 Volts, and after the last flight being 15.2 V. When trying to take off last time, the copter started oscillating in roll axis on the ground. Tried to get it up quickly, and it crashed with the same oscillations in the air from 1 meter, with additional pitch oscillation.

Today I tried again, but I was not able to get it off the ground, it oscillates (rolls) back and forth on its belly. I increased PIDs from 0.25 to 0.36 and also increased M_SPIN_MIN from 0.08 to 0.15 and M_ARM from 0.05 to 0.12. The latter improved marginally the oscillations, but certainly did not solve it.

The plane does not have a landing gear, just a belly, which allows it to rock from side to side by maybe 20 degrees.

Also, I noticed that QAUTOTUNE option 22 disappeared, but I did not reach that point.

I was flying without SD card.

I am totally lost, because this VTOL was flying well some 2 years ago.

I assume that the reason why the final test flight became totally unstable was due to lower battery voltage, and when this happens, i.e. when you have lower battery voltage, you usually want to increase the PIDs, but in this case increasing PIDs did not do any good at all.

I may try and reduce the PIDs to check if this helps, but I really do not want to poke in the dark, because the plane is not that light and can be damaged quickly.

VTOL tri 23 03 2026.param (38.0 KB)

2

You should mount an SD card and send the logs.

Since you’re going to have to fly it again anyways, I would suggest figuring out the quiktune lua script. it’s (imo) not as risky as autotune and much more effective. The copter needs to be in a bare minimum flyable state for it to work.

in preparation for this, you should reduce the P gains instead of raising them if you’re observing fast oscillations. if the thing shakes but can still fly mostly in place, strap a GPS to it and give quiktune a try.

last comment, you keep saying QLOITER, QAUTOTUNE, etc as if it’s a quad plane. are you really running copter or is it plane with Q_ENABLE = 1?

3

@Michail_Belov Is it running 4.3 or 4.6?

If it’s running 4.3 is in the wrong category.

“Problems” is a very vague word. Oscillations are the problems you are having right? Why not use that in the title?

The symptoms you describe could be caused by an incorrect MOT_THST_EXPO value.

4

It is 4.6.3. Sorry for that. Oscillations on ground.

What I am most worried about that first flights went virtually perfect, and then it got out of had completely. I was either very lucky the first time or something changed.

5

It is arduplane with Q_ENABLE.

The oscillations were low frequency, about 1 Hz or even slower, progressive. It has GPS. It is a plane with 3 motors, two front motors are with servo tilt

6

Thanks for improving the title. Is was very confusing before. I fixed the category.

1 Like
7

Did another bunch of test flights. I think I may have found the culprit - too low M_SPIN_ARM and M_SPIN_MIN. I increased them considerably, to 0.14 and 0.18. I also reduced the PIs to 0.16 from 0.25, but I feel it was the increase of no power RPMs which solved the issue. The motors were running on very low RPM and it took too long to spool them up, which resulted in the roll oscillation on the ground. Once in the air and stable the RPM are much higher so no lag was there.

At least I ran the battery down to 11.2 V without stability issues.

I will now run the QuickTune lua script.

8

If you could move the topic to Arduplane 4.6….

9

I got another test flight, did a quick tune which went well.

BUT:

One of the reasons I abandonned this VTOL project before was due to the fact that it was absolutely useless for takeoffs in high wind.

When wind was around 20 km/h, the total current went up by about 100 %, because the plane wing was tilting downwards generating enormous drag to stay at the same altitude and position.

At that time I did not use lua scripts.

This time I made a very simple script which allows to tilt the front motors using a pot:

function update ()

local tilt_angle=20
local pot=rc:get_pwm(14) – selector for parameter value, a pot
pot=pot-1000
tilt_angle=19+pot/50 – maximum additional 20 degrees
param:set (‘Q_TILT_YAW_ANGLE’,tilt_angle)

return update, 100

end

return update()

The problem was that indeed it kept the plane horizontal without generating extra drag due to inclined wing, but still the current went up by about 30 % for a horizontal speed of about 15 km/h and 20 degree extrs motor tilt.

But it is still way too low a speed I need (I want to have landing options with wind speed up to 40 km/h).

So I am not sure whether I can increase tilt angle further without risking unstable hover?

www.ecoterrenos.cl/Vtol Tri.bin

10

Got a crash during the last hover flight…

This is the .bin file:www.ecoterrenos.cl/vtolcrash.bin

Basically, I tried a few abrupt roll and pitch inputs in hover mode when staationary, and while roll seemed to go smoothly, strong pitch input resulted in progressive oscilations.

Before, I did a quick tune which gave me a much higher PI for pitch (0.35) compared to 0.17 for roll.

After that, I changed the rear motor from 1000 kV to 1050kV. I did not try to retune, thinking that the change was insignificant (and still think it is). The reason for that change was to increase the power on prop for the rear motor and also because of overheating, the new motor has a much higher power rating (V3115 1050 from T-motor).

I still have a lot of clipping for the rear motor, especially when I try to hover with front motors inclined forward and forward speed (in the second flight one can see that clearly, and the plane begins to descend quickly, with forward speed of about 30..35 km/h at 25 degree forward inclination of motors. The inclination is controlled through RCIN 14.

The probable reason why more power is required for the rear motor in that configuration is because the inclination forward of the two front motors moves the lever by about 2 cm forward or 10 % from CG, so that the rear motor has to pull harder.

The setup is this:

4S

Two front motors Sunnysky 2814 1000 kV with 12 x 6.5 Props

Rear motor Velox 3115 1050 kV with 13 x 6.5 Prop.

So…

I am thinking about increasing the battery to 5S. That will be absolutely required for higher altitude takeoffs and landings at 2000..3000 meters, but I want to tune the plane with 4S at sea level and then switch to 5S when going higher up.

I will reduce the PI of the pitch from 0.35 to something like 0.25 and the redo the quicktune, but I am not sure if this is the right thing to do.

I also am thinking about increasing the M_SPIN_MAX from 0.95 to 1.

(One issue I had was that I was not able to do the regular ESC calibration, (not sure why it did not want to do, with some message from Mission planner of a wrong version). What I did was that I changed the Motor 1,2,4 to Throttle, put throttle to maximum connected battery, and then put throttle to minimum. That actually calibrated well the ESCs, with the only problem being that the max throttle was 2000 uS, not 1900 uS, so maybe I have also to increase MAX_PWM to 2000 from 1900.)

Any suggestion as to what I may be missing in the setup and how to prevent crashes?

11

Hello Michail, You can find the detailed log report from www.bbaflighthub.com

For more AI based analysis you can use web page for free.

Best

BBAFlightHub — Flight Diagnostics Report

Vehicle: vtol | Motors: 3 | Protocol: PWM
Duration: 743s (12.4 min) | Max Altitude: 12.4m | Max Speed: 8.9 m/s
Battery: 16.2V → 15.6V (min 12.5V) | Used: 2254 mAh

Health Score: 0/100

13 issues detected: 6 CRITICAL, 5 HIGH, 2 MEDIUM

Score Breakdown

  • -25 [vibration] Critical vibration level detected
  • -25 [compass] Magnetic interference on Compass 0 (internal, config #0)
  • -15 [compass] COMPASS_MOT calibration not performed
  • -15 [ekf] EKF estimation variance exceeded safety threshold
  • -8 [ekf] EKF innovation values elevated
  • -15 [tuning] PID asymmetry: Pitch P is 2.0x higher than Roll P
  • -8 [configuration] Tilt servo asymmetry detected (68µs difference)
  • -25 [safety] Crash detected by autopilot
  • -15 [airspeed] Airspeed sensor configured but no data received
  • -25 [compass] Ghost compass detected: 2 compass(es) enabled with no device
  • -25 [ekf] AHRS attitude does not match accelerometer (possible orientation or EKF error)
  • -15 [power] Thrust-to-weight imbalance (hover throttle 44%)
  • -25 [safety] 3 safety failsafe(s) disabled

Compass Summary

  • Compass 0 (INTERNAL, ACTIVE): field variation 251.5%

Detailed Findings

1. :red_circle: [CRITICAL] Critical vibration level detected

Category: vibration

Vibration exceeds 60 m/s². This severely affects position and altitude hold. IMU clipping indicates sensor saturation.

Evidence:

  • maxVibeX: 66.1
  • maxVibeY: 71.0
  • maxVibeZ: 61.8
  • totalClips: 0

Recommended Actions:

  1. Check propeller balance — replace if damaged or worn
  2. Inspect motor mounts for looseness or cracks
  3. Add vibration damping (foam pads) under flight controller
  4. Check frame for structural damage or loose bolts

2. :red_circle: [CRITICAL] Magnetic interference on Compass 0 (internal, config #0)

Category: compass

Magnetic field varies 251.5% during flight (acceptable: <10%). Throttle-mag correlation: 3.6%. Interference pattern is consistent/directional (69% consistent). This is caused by current flowing through ESCs and power cables near the compass.

Evidence:

  • compassIndex: 0
  • isExternal: False
  • isActive: True
  • fieldVariationPct: 251.5
  • throttleCorrelationPct: 3.6
  • consistencyPct: 68.9
  • interferenceType: consistent/directional
  • avgFieldStrength: 229.9

Recommended Actions:

  1. Run COMPASS_MOT calibration: Mission Planner > Initial Setup > Compass > Motor Calibration
  2. Move compass away from power cables and ESCs
  3. Use twisted pair power cables to reduce magnetic field
  4. If external compass is available, use it as primary

3. :orange_circle: [HIGH] COMPASS_MOT calibration not performed

Category: compass

Motor compensation is disabled. The compass has no correction for magnetic interference from ESCs and power cables. This causes heading errors proportional to throttle.

Evidence:

  • COMPASS_MOT_X: 0.0
  • COMPASS_MOT_Y: 0.0
  • COMPASS_MOT_Z: 0.0
  • COMPASS_MOTCT: 0.0

Recommended Actions:

  1. Mission Planner > Initial Setup > Compass > Motor Calibration
  2. Slowly increase throttle to 75%, hold a few seconds, slowly decrease
  3. Click Done when complete. Write Params.
  4. Alternative: Enable per-motor compensation with COMPASS_PMOT_EN = 1

4. :orange_circle: [HIGH] EKF estimation variance exceeded safety threshold

Category: ekf

EKF variance exceeded FS_EKF_THRESH. This indicates the navigation solution is unreliable. Common causes: GPS issues, compass interference, or high vibration.

Evidence:

  • maxVelocityVariance: 1.4
  • maxPositionVariance: 0.6
  • maxHeightVariance: 0.63
  • fsThreshold: 0.800000011920929

Recommended Actions:

  1. Check GPS quality and satellite count
  2. Verify compass calibration
  3. Check vibration levels
  4. If false alarm, consider increasing FS_EKF_THRESH slightly (max 1.0)

5. :yellow_circle: [MEDIUM] EKF innovation values elevated

Category: ekf

High EKF innovation means sensor measurements disagree with the state estimate. This is often caused by vibration or GPS multipath.

Evidence:

  • maxVelocityInnovation: 1.04
  • maxPositionInnovation: 9.66

Recommended Actions:

  1. Review vibration levels
  2. Check GPS antenna placement for multipath

6. :orange_circle: [HIGH] PID asymmetry: Pitch P is 2.0x higher than Roll P

Category: tuning

Pitch P (0.3345) is significantly higher than Roll P (0.1667). This asymmetry can cause oscillation on the axis with higher gain. Unless the aircraft has very different inertia on each axis, these values should be similar.

Evidence:

  • Q_A_RAT_PIT_P: 0.3345
  • Q_A_RAT_RLL_P: 0.1667
  • ratio: 2.01

Recommended Actions:

  1. Reduce the higher P value to match the lower one as a starting point
  2. Run QuickTune/AutoTune again with the aircraft properly balanced
  3. If the asymmetry persists after tuning, check for physical differences (motor power, arm length, weight distribution)

7. :yellow_circle: [MEDIUM] Tilt servo asymmetry detected (68µs difference)

Category: configuration

Left and right tilt servos differ by 68µs on average. This causes asymmetric thrust vectoring, leading to roll or yaw bias during tilt transitions.

Evidence:

  • RCOU5: 1914
  • RCOU6: 1982

Recommended Actions:

  1. Calibrate tilt servos to match — adjust SERVO trim values
  2. Check tilt mechanism for mechanical binding or play
  3. Verify both tilt servos have the same travel range

8. :red_circle: [CRITICAL] Crash detected by autopilot

Category: safety

The ArduPilot crash checker was triggered. This means the autopilot detected that attitude could not be maintained.

Evidence:

  • event: ERR subsystem=10 code=22
  • timestamp: 740224872

Recommended Actions:

  1. Inspect airframe for structural damage before next flight
  2. Review PID tuning — oscillation before crash usually indicates gain too high
  3. Check motor/ESC health — a failed motor causes immediate attitude loss
  4. Review the moments before crash in the log for root cause

9. :orange_circle: [HIGH] Airspeed sensor configured but no data received

Category: airspeed

ARSPD_TYPE is set but no airspeed data was logged. The pitot tube may be disconnected or blocked.

Evidence:

  • ARSPD_TYPE: 1.0
  • samplesReceived: 0

Recommended Actions:

  1. Check pitot tube connection to airspeed sensor
  2. Inspect pitot tube for blockage (insects, dirt)
  3. Verify ARSPD_TYPE parameter matches your sensor hardware

10. :red_circle: [CRITICAL] Ghost compass detected: 2 compass(es) enabled with no device

Category: compass

Compass 1, 2 has USE=1 but DEV_ID=0 (no physical device). This feeds invalid data to EKF, causing incorrect attitude estimation and heading errors.

Recommended Actions:

  1. Disable ghost compass: set COMPASS_USE2=0
  2. Only enable compasses with valid DEV_ID (physical devices)
  3. Recalibrate remaining compasses after disabling ghosts

11. :red_circle: [CRITICAL] AHRS attitude does not match accelerometer (possible orientation or EKF error)

Category: ekf

At startup, accelerometer shows roll=-6.6° pitch=3.8° but AHRS reports roll=83.7° pitch=135.2°. Difference: roll 90°, pitch 131°. This usually means AHRS_ORIENTATION is wrong, compass is corrupting EKF, or the flight controller is not mounted as configured.

Evidence:

  • ahrsRoll: 83.7
  • ahrsPitch: 135.2
  • accRoll: -6.6
  • accPitch: 3.8
  • rollDiff: 90.2
  • pitchDiff: 131.4
  • AHRS_ORIENTATION: 4.0

Recommended Actions:

  1. Verify AHRS_ORIENTATION matches actual flight controller mounting direction
  2. Disable any compass with DEV_ID=0 (ghost compass)
  3. Recalibrate accelerometer with vehicle on level surface
  4. Check compass health — magnetic interference can corrupt attitude estimation

12. :orange_circle: [HIGH] Thrust-to-weight imbalance (hover throttle 44%)

Category: power

Hover throttle is 44% — above 40% means the motors are working hard just to hover. The vehicle has insufficient thrust margin for maneuvering, wind resistance, or emergency climbs. This is a thrust-to-weight ratio problem. Recommended hover throttle: 30-40%.

Evidence:

  • hoverThrottle: 43.7

Recommended Actions:

  1. Reduce vehicle weight — remove unnecessary payload or use lighter components
  2. Upgrade motors to higher thrust rating or use larger propellers
  3. Consider higher voltage battery (more cells = more power)
  4. Avoid flying in strong winds — insufficient headroom for corrections

13. :red_circle: [CRITICAL] 3 safety failsafe(s) disabled

Category: safety

Multiple safety systems are not configured. In an emergency (RC loss, low battery, flyaway), the vehicle has no automated protection.

Recommended Actions:

  1. Enable FENCE_ENABLE: No geofence active. Vehicle can fly away without limit. Set FENCE_ENABLE = 1 and configure FENCE_RADIUS and FENCE_ALT_MAX.
  2. Enable BATT_CRT_VOLT: No critical battery voltage set. The vehicle will not automatically land on critically low battery.
  3. Enable BATT_FS_LOW_ACT: No action configured for low battery. Set BATT_FS_LOW_ACT = 2 for RTL on low battery.

Root Cause Analysis

Based on the diagnostics findings, the following cause-effect chain is identified:

Ghost compass (DEV_ID=0, USE=1)
  → Feeds invalid data to EKF
  → AHRS attitude 90° off (acc says -6.6° but AHRS says 83.7°)
  → Autopilot makes incorrect corrections
  → Tilt servos hit max (yaw control saturated)
  → Roll/pitch oscillation ±370°
  → CRASH_CHECK triggered

Contributing factors:
  - Compass 251% magnetic interference (no COMPASS_MOT calibration)
  - PID Pitch P (0.335) is 2x Roll P (0.167) — QuickTune asymmetry
  - Hover throttle 44% — low thrust margin for corrections
  - Vibration >60 m/s² on all axes — degrades sensor quality
  - Airspeed sensor not connected — no stall protection
  - 3 failsafes disabled — no automated protection

Priority Actions (Do These Before Next Flight)

  1. COMPASS_USE2=0, COMPASS_USE3=0 — Disable ghost compasses immediately. These feed garbage data to EKF.
  2. Install external compass or run COMPASS_MOT calibration — 251% interference on internal compass is unacceptable.
  3. Verify AHRS_ORIENTATION — Current value is 4 (Yaw270). Confirm this matches physical FC mounting.
  4. Reduce Q_A_RAT_YAW_P from 0.736 to ~0.3 — Current value causes aggressive tilt servo oscillation.
  5. Reduce Q_A_RAT_PIT_P from 0.335 to ~0.17 (match Roll P) — Re-run QuickTune after fixing compass.
  6. Connect airspeed sensor or set ARSPD_TYPE=0 — Configured but no data received.
  7. Enable failsafes: FS_GCS_ENABLE=1, FENCE_ENABLE=1, battery failsafe configured.
  8. Consider propulsion upgrade — Hover at 44% leaves insufficient margin. Higher voltage battery (5S→6S) or larger props recommended.

Report generated by BBAFlightHub (www.bbaflighthub.com)
Upload your ArduPilot/PX4 logs for free AI-powered flight analysis.

12

Very interesting…

Some observations are quite valid, other are bogus. I would take the AI analysis with a grain of salt:

“Vibes are critical”. That is wrong. The peaks of 60 mentionned in the report correspond to touchdowns, when the fuse lands. All vibes in flight are below 3. Actually, based on that number, I may have too soft mount for the FC.

Asymetry of the tilt servoes: that is a natural result of the torque due to propellers. All props are of the standard type, which generates a tendency to rotate, and the servoes must incline the motors in suchc a way as to counteract. In fact, the rear fixed motor is mounted at a small angle to counteract that tendency, but it is not enough, and so the servoes also have to maintain the front motors at a small angle to stabilize yaw. I may use counterrotating props, I have 12 x 8 both normal and pushers, but for the first hover flights I decided to use lower pitch props 12 x 6.5 for which I do not have counterrotating ones.

Failsafes: I never set them, except RTL for Radio Link loss.

Absolutely correct observations which I detected by myself:

-increase battery voltage.

-reduce P for pitch.

What I found interesting:

-reduce Yaw P. In fact, I observed a too strong, jerky and oversteered movement of the tilt servoes. But I did not pay too much attention to taht. My doubt is why the quick tune did such a bad job for yaw and pitch.

incorrect orientation of the board. That is a very big mistake, and I am not sure how it could have happened… that is a blunder on my part.

Compass issues: that one I did not expect. The compass is located about 15 cm away from ESC power cables which carry between 12 and 20 A. Not sure if that is enough to cause the interference.

1 Like
13

That seems to be a blunder on part of the report. Indeed I have a value 4 set. But it corresponds to Yaw180 in Mission Planner. And the board is installed horizontally, with the arrow pointing backwards. So I do not get where they got the Yaw270 from?

14

Hi Michail,

Thanks for the detailed feedback — this is exactly what helps us improve.

To clarify: this report is not purely AI-generated. BBAFlightHub uses a
rule-based diagnostic engine that analyzes parameters, motor outputs,
compass data, PID values, and sensor correlations directly from your .bin
file. The AI layer adds interpretation on top of those findings.

You’re right on the corrections:

  • Vibration: Our engine was using peak values which included touchdown
    spikes. We’ve already fixed this — now using 95th percentile to exclude
    landing impacts. Your in-flight vibes at <3 m/s² are excellent.

  • Tilt servo asymmetry: You’re correct — with same-direction props,
    differential tilt for torque compensation is expected behavior. We’ve
    updated the threshold for vectored yaw configurations (Q_TILT_TYPE=2).

  • AHRS_ORIENTATION: Our mistake — value 4 is Yaw180, not Yaw270.
    We’ve corrected this in our parameter mapping. However, the underlying
    finding is still valid: at startup, the accelerometer shows the vehicle
    nearly level (roll ~6°, pitch ~4°) while AHRS reports roll=83°,
    pitch=135° — that’s a 77°+ mismatch that points to an EKF/compass
    initialization issue, which aligns with the ghost compass finding.

The findings you confirmed — compass interference, Yaw P too high,
Pitch P asymmetry, board orientation issue — those came directly from
the rule engine analyzing your actual flight data.

We’re actively improving based on feedback like yours. These corrections
are already deployed.

15

It seems that my compass orientation was wrong! But apparently the manually set orientation should have being ignored because of automatic orientation detection. I am not yet sure…

16

You must be careful with that. I was setting up once a copter where I did short high speed passes, and there it also peaked to about 40..50. But during deceleration and turns, it was below 20. The peak values were very short, maybe a few seconds, but the whole pass was maybe 60 seconds. With 95 % approach you may exclude something relevant.

17

Thanks for the feedback. Good point on the percentile approach
we’re working on filtering ground contact events specifically
instead of a blanket cut. Your feedback from real flights is
exactly what improves the tool.

18

I have rerun quick tune, but I got similar results as the last time.

For the pitch, I started with PI of 0.19 and D 0.008. I did moderate pitch and roll inputs which seemed to be stable.

After that I did a quicktune, which pumped PIDs up to 0.285 and 0.0065. During the previous tune, it was 0.34 and 0.013. So I am not sure how to go from here. I decided not to risk it with any abrupt inputs.

The roll remained very similar, quicktune left it almost untouched at 0.16 and 0.004.

This is the file: www.ecoterrenos.cl/vtol1.bin

There are two short flights, the first one being where I tested pitch and roll, with pitch PI 0.19 and D 0.008. I looked at the file using the PID review tool and I think that P should definitively not be increased, although quick tune had a different opinion.

I will reduce the PD obtained from quickctune proportionally, to PI 0.19 D 0.004 and try from there. Basically what will change is the relation between P and D, without increasing P

19

I have flown now with new pitch PIDs, 0.19 0.004 with full deflection of both pitch and roll without any obvious failures.

The yaw was also reduced by 50 % from the values obtained by quicktune. The yaw worked well in stationary hover. However, when I inclined front motors, from about 15 km/h forward speed the yaw became unstable with continuous oscillations, with nose going all over the place. My feel is that the yaw PIDs should be increased for this flight mode, but I am not sure. Too high yaw PIDs I had before resulted sometimes in oscillations on ground, and during lift-off the plane sometimes dipped the wing or nose to level off then.

One solution I see is to increase yaw PIDs based on POT position which controls the front motor inclination. In addition, when on ground, I would start with even lower yaw PIDs, i.e. the lua script should detect the take off, and then change the yaw PIDs from low to standard values, and when POT is activated, switch standard PIDs to high PIDs.

And I still get 90 degree inconsistency message with AHRS. Not sure where the problem may lie.