Heavy Kopter sags with quick roll or pitch inputs on the remote control

Flight Testing & Log Analysis
1

Hello,
it is possible to make a copter fall down by quickly moving the roll/pitch lever on the remote control left and right. This behavior can be reliably reproduced again and again.

The behavior can be evoked in Acro, Stabelise and in Simple Position Hold mode.

Attached is a log file where the copter is brought to an extra crash at the end.
It should be said that we have already tested many different MC_ / MCP_ tunings. We also tested different filter settings. In the log file attached here we use the default Gyro Filter Settings.

The copter weighed 8.72 kg during the test flight. It has a propeller circle of 100cm and is operated with 17x5.8 propellers with 340kv motors at 6S.

Oh, the system used here is a wooden twin of our commercial systems and is used for destructive test flying.

We have noticed (log files) when the user moves the stick on the remote control (setpoint) faster than the system is able to follow, limited by the set rates. Then suddenly Estimatet Roll/Pitch becomes larger than Setpoint. When this happens, the system will immediately remove the thrust, even if the user increases the thrust on the throttle.

We don’t know if this is a bug or a security fix. However, the behavior makes it difficult to determine limit parameters when tuning.

Log File:
https://review.px4.io/plot_app?log=c1e9cf08-8ef6-4406-8aa7-e459df1a3156

2

I have not thoroughly reviewed the logfile yet, but what you describe sounds like a mixer saturation that would be taken care of by enabling airmode:

1 Like
3

@wolke Reading your observation I would have guessed that your vehicle requires much more than 50% hover thrust and when constantly commanding unfeasibly fast tilt changes the allocation (mixer) prioritizes differential thrust over collective thrust worst case leading to an average of 50% collective thrust when e.g. two motors are at the maximum limit and the opposite two on the minimum limit.

I took a look at the log and am pretty sure this is not the problem because:
a) the estimated hover thrust is 55% and the drop in altitude accelerates with ~3m/s^2 which is in my estimation much too fast for dropping to the worst case 50% collective thrust.
b) you stopped moving the sticks back and forth when the vehicle still continues to drop heavily

This brings me to my conclusion that there is a fundamental control problem where the rate controller can be excited go unstable and run into an unescapable limit cycle. The most common reason for this is the slow or otherwise unexpected reaction of motor controllers (ESCs).

That brings me to the question:
What motor controllers are you using?
That might give us some hint.

I also noticed you have regular text messages from uavcan in the log. Might this be in some way related?

[uavcan:25:load] idle 82.56%(4128354/5000015)

For your reference these are the plots I was looking at:

image
image1920×1142 155 KB

4

[Solved]

First of all, I would like to turn to @LorenzMeier and @MaEtUgR. You have invested time and attention in our problem, that is not a matter of course, thank you very much. :+1:

We were able to solve the problem by switched on Airmode and reducing MC_ROLLRATE_K, and correspondingly for Pitch the same, from two to one. MC_ROLLRATE_I has now been reduced from 0.6 to 0.3 and MC_ROLLRATE_P has been reduced from 0.3 to 0.19. Depending on the previous MC_ROLLRATE K value, of course.
The result can now be seen. The copter now flies stable.

MC_ROLLRATE I and PITCHRATE I are still a bit too small if you explicitly only want to fly in acro :). The copter tends to roll back into the center of gravity on its own. A Racekopter would be set much more I with Betaflight to Race:) But we build tools that should fly safely and not race in acro. That’s why we can probably live with the relatively low I values.
On this copter, however, the high I in combination with our slower controllers (T-Motor Flame 60) seems to lead to uncontrollable mixer behavior. It might be helpful to set a control time value as a parameter for tuning larger copters. When we plan a copter design, we test controllers and motors in combination on the performance test stand. Here we can also see the times/latencies
and determine controller ramps that result when starting a propeller/motor/controller combination. Such a latency value, which is entered as a parameter when starting from minimum speed to maximum speed, could maybe support the control circuit.

UAVCAN:
Our wooden test copter twin has a Canbus GPS and compass combination. (Here 3)

Logfiles with Airmode and new PID settings:
https://review.px4.io/plot_app?log=260b735b-65ed-4096-b961-33d43c1f6ee0

5

@wolke Thanks for reporting back. I’m happy to hear that you were able to improve the flight performance of your vehicle by tuning.

Just some hints that might help you to improve further:

MC_ROLLRATE_K, and correspondingly for Pitch the same, from two to one.

I usually keep it on 1 if I don’t have a tuning that’s already very good and I know that just the output range changed a bit. That’s personal preference since it just scales all the gains at once.

MC_ROLLRATE_I has now been reduced from 0.6 to 0.3

Default is 0.2 and doubling can help especially with the drift you mentioned but higher values usually have to be handled with care.

MC_ROLLRATE_P has been reduced from 0.3 to 0.19

Default is 0.15. This often works well with the usual normalized ranges and ok ESC responses. A slight increase is desirable if there are no negative side effects. Sometimes those side effects can be dampened with RATE_D gain, sometimes not. 0.3 seems like a very high value to me. The output range or reaction times or something about the vehicle would need to be special. It could well be that this was the biggest impact leading to the experienced instability.

with our slower controllers (T-Motor Flame 60) seems to lead to uncontrollable mixer behavior

Very often slower reacting ESCs lead to such problems. If not in hover flight then with step inputs or other more extreme flight conditions. You might want to give these ESCs a try: 120F3[X] — Advanced Power Drives They should provide low latency reactions and might fit your requirements. They also support digital setpoint signal over Dshot and configuration via FTDI.

But we build tools that should fly safely and not race in acro.

I heard this argument a lot of times and while it’s not wrong in my practical experience the better any multirotor flies in acro the more robust flight performance you’ll get out of it independent of the size and use case. That said I’m not talking about flips but mostly quick, predictable accurate, non-oscillating, non-drifting flight with 100 deg/s back and forth steps in setpoint.

What definitely needs to change on a large platform is IMU filtering, often a notch filter based on high rate log analysis helps significantly. And attitude control gains. When giving unfiltered diagonal attitude step inputs the vehicle should not overshoot notably and fly very predictable. Usually on larger multicopters that have good rate control tuning it’s required to lower the attitude gains MC_ROLL/PITCH_P up to half the default value. This generally has less impact on disturbance rejection than any detuning of the rate controller.

It might be helpful to set a control time value as a parameter for tuning larger copters.

We discussed at least explicit documentation for larger vehicles and possibly configuration profiles for usual adjustments necessary with vehicle size that can be used as a starting point.

switched on Airmode

Be careful with airmode. While I’d enable it on a well-tested vehicle to increase flight performance in low total thrust command situations e.g. when an efficient vehicle with large propellers is braking or simply with low thrust descend in Stabilized/Manual mode. I’d disable the feature for bring-up, prototyping and tuning flights where risk of problems is higher because if e.g. some actuator, propeller, sensor orientation is wrong or the tuning is off the drone could flip or oscillate up very quickly even with zero commanded thrust.

UAVCAN:
Our wooden test copter twin has a Canbus GPS and compass combination. (Here 3)

:bulb: :+1:

6

very nice,
good tips from experienced people are worth their weight in gold.

A question about the K value.
Is that right?
MC_xyzRATE_K * MC_xyzRATE_x = USED_MC_xyzRATE_x

As I understand it from the PX4 USER GUIDE, the K value is linear to the parameters applied to it.

7

good tips from experienced people are worth their weight in gold

@wolke Nice to hear. We try to make all of this information easily available in the documentation.

The user guide explains why the K is there and how it works: Multicopter PID Tuning Guide (Manual/Advanced) | PX4 User Guide (main)

To summarize it in a very easy example setting MC_ROLLRATE_K to a different value than 1 e.g. 1.1 is exactly the same as manually multiplying MC_ROLLRATE_P, MC_ROLLRATE_I, MC_ROLLRATE_D by 1.1.

So K = 1, P = 1.1, I = 2.2, D = 3.3 is equivalent to K = 1.1, P = 1, I = 2, D = 3