QAUTOTUNE - VTOL autotune for quadplanes

Less things to go wrong and I am in more direct control. Landing in a position hold modes can cause tip overs, especially if your only half way through setup.

Don’t forget you can autotune in Qhover.

Plane behaviour is the same as copter as far as I know.

I really don’t see any disadvantage to letting people switch out of autotune. You can still do it without switching, just gives more options. The key thing to save gains is to disarm in autotune.

Sure, but on Plane we save regardless of mode. So if your vehicle goes
completely nuts during autotune and you switch to land - we’ll save your
bad gains on landing. Yay!

This is the issue I created for it: https://github.com/ArduPilot/ardupilot/issues/10411

Here are the relevant two lines in the test - qland then wait for
gains-saved string:

donloaded the firmware with ctrl-q in mission planner, updated mission planner to the latest, set flight mode to 22, shows up in mp as “qautotune”. the issue i have is that in full parameterlist “Q_AUTOTUNE_AXES” does not show up. any idea? im on 3.10-dev

you have the ‘advanced’ box ticked?

no facepalm
thanks

i tryed it, did not change the outcome.
you mean the “adavnced” layout in config/tuning -> planner -> adavnced layout?


same with apmplanner2

hum, maybe try installing direct from the latest folder. http://firmware.ardupilot.org/Plane/latest/

download the appropriate .apj and install using the load custom firmware button on the mission planner firmware page.

worked. version number was shown as the same :wink:

Really good. did one axis at a time. afterwards much better hover performance.
if you are interested in logs, i have uploaded the pitch autotune log here. had to switch in qloiter for a second. thought a propeller was coming lose to the sound, but it was just a motorcycle passing by :smiley: the seconde one is just a short qhover -> fbwa -> q hover to check if everything works.

Excelent job guys … Just used autotune for a quadplane. Worked extremely well.

One question;
It hoovers at half throttle in QLOITER mode. When I switch to QSTABILIZE it needs about 70% throttle to stay at the same elevation. What Parameter do we use nto adjust this?
I have been playing with Q_M_THRST_HOVER and Q_M_HOVER_LEARN but doesnt seem to change ?

this PR will fix that

do you mean 50% throttle position on the RC transmitter (~1500 pwm ch3in)?

in qloiter the throttle isn’t absolute, 50% throttle means stay at the current altitude. Above 55% it climbs and below 45% it descends (I think this range is adjustable as well).
If you look at the average throttle to the motors it would be about 70% like you see in Qstab. You can see this in the Dataflash log as QTUN.ThrOUT

Hmm… I mean when I am flying in QLOITER and hovering, my radio is at about 50% throttle. But if I switch to QSTABILIZE the quadplane drops in elevation unless I quickly give it near 70% throttle. I would like to fix that. It is not clear to me what or how to adjust? Not a big deal… not even sure why I would use QSTABILIZE, but I am just testing and learning how it all works. Thank you for the input.

You could set the controller (assuming it’s capable) to scale and offset the throttle output when you switch modes so that 70% throttle occurs at a 50% stick position in qstab, but that sounds like it comes with it’s own potential trouble.

Jace McCown

@tridge, @iampete, @Leonardthall , We’ve done some Q_Autotune with a tricopter tiltrotor platform. You can find the logs here: https://discuss.ardupilot.org/t/vtol-quadplane-tricopter-autotune/40957

Will add to this post later today once we have done the yaw autotune and tilt autotune which should be interesting :). Hope the data is useful for you guys!

1 Like

Large QuadPlane Crash in QAUTOTUNE

Hello All!

Tried QAUTOTUNE (Mode 22) on a large QuadPlane weighing 8.5 Kgs and 8-ft Wing Span.
The aircraft is fitted with Pixhawk2.1 Cube and HERE GNSS running Arduplane Latest 3.10.0-dev, and set up as an X Frame in the firmware (Q_FRAME_TYPE 1)

Quad drive is KDE3520XF-400KV coupled with KDEUAS55HVC (55A+HV) ESCs running T-Motor 18x6.1 CF Props, powered by a 16000mAH 6S Lipo battery. As per eCalc this setup provides a Thrust-to-Weight ratio of 1.7 at full charge and a hover time of 10+ mins.

In our first flight, QuadPlane was stable in QLOITER mode and held its position comfortably on a very calm day with all default PID gains. However, PID gains tunning was required as a small Roll/Pitch input from RC would result in oscillations in Roll/Pitch axis. Flight log is attached as QPlane_T1.BIN

Following parameters were set for the QAUTOTUNE Flight:

  • AUTOTUNE_AXES = 1 (Roll Axis only)
  • AUTOTUNE_AGGR = 0.06 (Reduced Autotune Aggressiveness)
  • Q_ANGLE_MAX = 3000 (Limit Quad lean angle to 30 degrees)
  • Roll/Pitch P gains (Q_A_RAT_RLL_P, Q_A_RAT_PIT_P) Reduced from 0.25 to 0.2
  • Roll/Pitch D gains (Q_A_RAT_RLL_D, Q_A_RAT_PIT_D) Increased from 0.0036 to 0.005

QAutoTune (Mode 22) was engaged from QLOITER mode. Aircraft did not start twitching immediately because the throttle stick was not exactly centered (at 1530 PWM). Reduced the throttle to around 1490 PWM and the aircraft started to twitch as expected. All was good in the first 9 twitches, as the aircraft would recover to level position from the twitch with about 5-degrees overshoot. It did not recover from the 10th twitch and came down crashing. Sustained major structural damage to the wing and fuselage.

Here is the link to both log files: https://www.dropbox.com/sh/eh3d5lf7kw5imrt/AADqb469NAs4RRDXmX5PK7sia?dl=0

I am now trying to look into the log file and figure out the cause of the crash and how it could have been avoided. So far i have discovered two anomalies:

  1. On 10th twitch, the throttle signal to Motor-1 (Front Right, CCW) & Motor-2 (Backward Left, CCW) i.e RCOU.C5 & RCOU.C6 went down to ZERO momentarily and then recovered to around 1700 PWM. Is this an ESC De-Sync scenario?

  2. 1.5 seconds after the above, the throttle signal to Motor-2 (Backward Left, CCW) RCOU.C6 goes to max (1900), while the throttle signal to Motor-1 (Front Right, CCW) RCOU.C5 goes to ZERO in perfect synchronization. The vehicle was still recovering from the overshoot of last twitch.

It seems like the Motor-2 is unable to provide the necessary lift and auto-pilot reduces the throttle on Motor-1 to ZERO in an attempt to keep the vehicle level. But it does not work as the vehicle keeps rolling to the left specifically dipping on the Motor-2 and starts loosing altitude and eventually hits the ground. Does this points to a Motor/ESC failure or an ESC de-sync?

Few More Questions

  1. Reducing the AutoTune Aggressiveness further down would have avoided this crash? Does the Autotune Aggressiveness limits the Max roll/pitch demanded by autopilot for twitching? Or it reduces the Rate (degrees per second) demanded by autopilot during the twitch?
  2. How about limiting the Q_ANGLE_MAX to 20-degrees to avoid excessive motor load during AutoTune? How would it impact the Autotune effectiveness and general flight later on?
  3. Assuming it is a Motor/ESC failure scenario, was this failure triggered because of the excessive motor load experienced in AutoTune mode? Should i consider increasing the T/W ratio in the design to give more headroom?

@Leonardthall and all: I might have missed something important so please look into the logs and provide your valued feedback.

Looking forward to great help as always!
Amir

First up, pretty much all quad planes should start out using these settings:
Q_A_ACCEL_R_MAX 15000
Q_A_ACCEL_P_MAX 15000
Q_A_ACCEL_Y_MAX 5000

The bad news is this is a classic ESC sync loss. You need to do your standard due diligence on your ESC setup. You should check to make sure that all your wiring and setup is done correctly in case it is a loose wire or something similar.

The things that reduce the chance of sync loss are keeping all power wires gently twisted from the battery to the ESC, avoid large loops.

Ideally you would reproduce the sync loss issue on the bench. Then you can make changes to minimise the chance of desync happening. To reduce the chance of sync loss you can increase the minimum throttle or increase the timing value.

Good luck and I am sorry to see your crash!

Thank you @Leonardthall for quick help!
I have already started the re-build and will incorporate all the feedback to make it a success this time around.

Noted for all future QuadPlane setups.

I have tested all ESCs and Motors individually and they are working fine. So this indeed is an ESC Sync Loss.

1 pair of 10-gauge power wire runs from PDB (mounted in fuselage) to centre of each boom (0.8m wire), where it splits into two ESC inputs. A loose twist was applied every 8 inches on the power wire to avoid the same. The ESC signal wire is routed alongside the power wire, using an anti-interference twisted servo extension cord (90 cm)
Is there a need to shield the power or signal wire using aluminium based shielding tape?

Minimum throttle was set to 23%. But i noticed that the motor spins very slowly at this point (using Motor Test and setting Throttle to 23%). Perhaps this is because of the Throttle Expo. Can you please point out how the parameters Q_THROTTLE_EXPO and Q_M_THST_EXPO affect the output level?

As for timing, the arduplane documentation says RCOU.C5-RCOU.C8 are set at 400Hz update rate for a QuadPlane setup. Digging into the ESC manual, i found that it supports OneShot and i have set Q_M_PWM_TYPE to the default Normal. Is it recommended to switch to OneShot if the ESC supports it?

Thank again!

@tridge and all: Any help with above questions please!

Many Thanks!
Amir

The main way to test this is to do step pwm inputs from near minimum to maximum. Basically you need to abuse the low end of the RPM range with fast steps to high RPM.

This seems quiet high. Make sure you have calibrated the ESC’s.

They don’t impact the minimum and maximum throttle settings. At minimum throttle you should have an assertive rotation but not so much that it is producing a significant amount of thrust.

I was talking about the ESC phase timing. This is not a setting in Ardupilot, it is an ESC setting. There are a few settings in BLHeli that might help. RC Test Bench is a good reference for BL Heli settings.

This is probably not going to be any great improvement in your system. So at this point I would not add another variable.

No, it sets the target overshoot for the tests. This overshoot needs to be between 5% and 10% for best performance. However, the tests can’t tell the difference between noise and the actual movement so we set it to the upper range by default. The noise in the system will mean it ends up lower.

Autotune works between 10 and 20 degrees on the angle steps and aborts if it goes over 20 degrees. So this would have no impact on autotune.