Servers by jDrones

QAUTOTUNE - VTOL autotune for quadplanes

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.

Hello!

Sorry to revive the topic but we’re trying to do an autotune of our Qplane and are not getting desired results.

We set flight mode 6 to Qautotune and went for a test. We take off in Qhover and then toggle into Qautotune when we’re in the air. From what I’ve read on here we should see it twitch rapidly about its roll axis but we don’t get any reaction at all. Furthermore we can’t see the correct parameters in the parameter list. We’re running arduplane 4.0.5.

Thank you!

We managed to get it started by updating to fw 4.1.0! :slight_smile: Unfortunately our rig flips when we exceed 15 degrees so when autotuning the roll axis we flip immediately. Will update here and here if we figure it out.

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

are these settings for quad planes still valid?

As per the Tuning Instructions Guide these Acceleration rate parameters must be set according to the propellor size (which is proportional to UAV size & weight).

However, @Leonardthall recommended these for Pretty much ALL Quadplanes which does make sense as high rate of acceleration in Roll & Pitch is neither desirable nor safe for a Quadplane. I would start-off with these parameters for a Quadplane and work from there.

1 Like

Today something very similar happened to me. I believe I followed all advices from this thread regarding parameters. I took off, the VTOL was oscillating a bit. However, it kept position nicely, so I decided to switch to QAUTOTUNE. Since I set it to the lowest aggressiveness I thought it should be fine. It seems like it started autotune, but a few seconds into it the VTOL flipped to its left and crashed top-down.
In the logs I can see that RATE.Rdes all of a sudden goes to -170deg, which should be the reason for the crash. However I didn’t even touch the joysticks during the flight

Its a Cube Black, two GPS, one flow sensor and a rangefinder.

Can anybody see from my logs why this happened or if I set any parameter wrong?
Here are the logs, params and a video of the flight.
https://1drv.ms/f/s!AuKkq6JXpbFTzrUaVbcwDCcSh3o1eQ

@snakeeater I am very sorry to hear about your crash but I think I was pretty clear in the instructions lined above that you should not start autotune until you have “ensured that the current tune is good enough to recover from the repeated tests run by Autotune”. Given:

The tune was clearly not ready for autotune.

I go on to describe how to tune manually.

I am sorry to be blunt here but you clearly did not follow the instructions.

This is an excellent thread. Thanks to all who have contributed.

Sadly, I have had two crashes recently, so I am moving forward with this build more cautiously.

I’ve read this thread numerous times and went through the tuning process instructions. I’ve done four flights. No crashes!

The first two flights were done with

Q_A_ACCEL_R_MAX 50000
Q_A_ACCEL_P_MAX 50000
Q_A_ACCEL_Y_MAX 18000 per the Tuning Processes Instructions.

The log showed overshoots on all axis.

I then set the parameters suggested by Leonard.

Q_A_ACCEL_R_MAX 15000
Q_A_ACCEL_P_MAX 15000
Q_A_ACCEL_Y_MAX 5000

This alleviated the overshoots.

I am satisfied with what I am seeing on the pitch and roll axis, but I have oscillations on the yaw axis. It’s not visible when flying but obvious on the log.

Can anyone suggest what might be causing the oscillation? And most importantly can I proceed with an autotune?

Log to the third and fourth flights is attached.

The first flight was flown with ATC_RATE_FF_ENAB to 0. The second flight ATC_RATE_FF_ENAB was set back to 1.

Thanks,

Dave

Ok, thanks for the clear assessment. Thats what I was considering too. I thought my D gains were already quite low, but obviously i will lower them further and be more cautious regarding vibrations before starting the Autotune.

So you recon the PIDs were the main problem? That spike in the graph above is not some sensor failure/reset because of wrong parameters or anything, but it was actually the first normal cycle of autotune? I would like to understand it from the data.

Btw on the Quadplane parameter page https://ardupilot.org/plane/docs/quadplane-parameters.html it says:
" The most critical tuning parameters are Q_A_RAT_RLL_P and Q_A_RAT_PIT_P. These default to 0.25 but you may find significantly higher values are needed for a QuadPlane."

I think this gave me a completely wrong feeling about those parameters. My initial try was 0.3 based on that and the plane flipped right at the start, thats why I was rather positive how it went this time. Of cause I am just one point of experience, but my VTOL should be a rather average setup. Maybe it should be considered weather the documentation should be updated?

Hi Dave,

If you have any oscillation then you can’t proceed with Autotune.

The good news is I don’t see any oscillation in yaw. Can you show where you think you see it?

You do have some high frequency noise at about 80 Hz that you would benefit from removing with a notch or harmonic notch depending on where it comes from. A batch fft log would be the way to go here see what it shows.

Your filter settings look ok otherwise though.

In any case I would add the notch filtering after the FFT log flight before proceeding to Autotune. I suspect you would get away with it though. I just would do the setup properly first.

Yes that is correct.

Your log looks like it is oscillating in both Alt Hold and pitch. So I would read through the instructions above and make the appropriate changes I describe there. If you follow the instructions step by step you should do well.

Hi Leonard,

Thanks for the quick reply, Attached, please find an image of dyaw and yaw. I circled the part that I am bit concerned about.

I’ve never used FFT logs before. I do see the 80 hz noise in the IMU plot. Is the what I should filter out?

Df log attached link below.

Thank you. I really appreciate your time and experience.

Dave

Ok, I set up a harmonic notch filter linked to the throttle.

Did a few test flights. Everything looked good, so I proceeded with an autotune. First thing I noticed was a sharp yaw to the left, which surprised me because autotune is supposed to start with roll and I had Q_AUTOTUNE_AXES set to 1.

I gave it a few more minutes and didn’t like what I was seeing so I abandoned the autotune.

A few concerns:

The autotune seems too aggressive for a 2m QPLANE. Q_AUTOTUNE_AGGR is set to 0.1. Should I lower this to .05. AUTOTUNE_LEVEL is set to 6, which is default and consistent with the recommendation. Should I reduce the level?

The other concern is current draw during the autotune. It spikes to 160 amps. The four ESCs are rated at 60 amps and the Mauch Power module is rated at 200 amps. But the battery, connector, esc and engines are getting warmer than desired. I am concerned it may get too hot during an autotune. I plan to do one axis at a time, land, let it cool and do the next axis. And I am thinking reducing the aggressive may reduce the current spikes?

Long term I am not too concerned about the heat because we only plan to be vtol for a few minutes for takeoff and landing.

Any suggestions about how to proceed are greatly appreciated.

Thank you,

Link to the log for the attempt at tuning. It consists of two test flights and the autotune flight.

That is not oscillation. Oscillation is very regular and will look sinusoidal or at very least like a saw blade of some sort.

I am not sure what you want to show in that log but I didn’t see the batch fft logging there. Did I miss something?

This does not impact the tests just the choice of parameters. Three currently isn’t any way to reduce the maximum twitch request.

A quick look at your log doesn’t show any signs that I would be worried about. I can’t evaluate your power system but assuming it can take it I would proceed with autotune.

Servers by jDrones