Pitch oscillations when braking in Loiter mode

ArduCopter Copter 4.5
1

Hello,

We have a heavy lift copter that is exhibiting severe oscillations in the pitch axis when braking in loiter mode. Here’s what we know so far:

  • The issue only happens in the pitch axis (where there’s more inertia), roll axis is flawless.
  • Visibly, we see the vehicle pitch back to brake but it keeps going past the angle limit, and then it quickly snaps back to level and enters a oscillation. Sometimes the oscillation dies out on its own, but with a full payload it goes unstable until we take over.
  • We have detuned PSC quite heavily at this point, but the issue persists.
  • In the logs we see that the roll rate controller requests a very large roll rate change which the Copter takes some time to hit. But by then there seems to be some I-term buildup and we enter an oscillation.
  • Turning down ATC_ACCEL_P_MAX seems to help, but even with a value as low as 3800 the issue persists.

I’ve attached two logs that show this behavior. In flight 1 the oscillation recovers on its own. In flight 2 (with more payload) the oscillation did not stop and we took over to save the vehicle.

Flight 1: Flight 1.bin - Google Drive

Flight 2: Flight 2.BIN - Google Drive

We are pretty sure this is a attitude control problem but we’re not sure where the issue really is. I’d appreciate any ideas anyone has on how we can overcome this!

Thank you.

2

There are two changes that might help.

The first is the position controller appears to be driving the occilation to a significant extent, in particular vel P.
PSC_VELXY_P 0.5

The overshoot also appears to be driven by pitch I so I would also try halfing that.
ATC_RAT_PIT_I 0.055

Your aircraft is very slow and both of these changes are often required for large slow aircraft.

2 Likes
3

Probably ATC_ANG_PIT_P is too high. Try lowering it to around 6 to 8 and test

4

I agree with this however the accelerations are so low I don’t think this is what is causing the behaviour we see here.

1 Like
5

You might be right. I only suggested this because I have seen many times autotune produce unnecessarily high values for ATC_ANG and ATC_ACCEL sometimes leading to oscillation when braking

6

You are completly correct with your feedback.

1 Like
7

We did 20 flights today trying a whole lot of stuff. Here’s a summary of each flight and the log:

Flight 80: No payload. Updated ATC_RAT_PIT_I to 0.055 and PSC_POSXY_P to 0.5. This led to a wobbly position hold in Loiter. We saw oscillations in PSCN.PN and PSCN.VN:

image
image1817×1043 14.2 KB

Flight 81: No payload. Kept ATC_RAT_PIT_I at 0.055 and set PSC_POSXY_P back to 1.0. This mostly fixed the wobbly Loiter but we noticed that the copter would make noticeable position corrections to position after coming to a full stop. I think I see this in PSCN.PN as well as some oscillation around the target:

image
image1817×1043 15 KB

Flight 82: No payload. Did some higher speed tests in Loiter and found that the pitch went unstable really easily. PIDP.Tar oscillations happened and the motors almost bottomed out:

image
image1817×1043 37.6 KB

Flight 83: No payload. Dropped ATC_RAT_PIT_D and ATC_RAT_RLL_D by a factor of 10 to rule out a D-term oscillation. This made things even worse and it was completely unstable in PIDP and PIDR. Landed almost immediately.

image
image1817×1043 20.5 KB

Flight 84: No payload. Reset ATC_RAT_PIT_D and ATC_RAT_RLL_D back to their previous values just to make sure it was stable again, and it was.

Flight 85: No payload. Dropped ATC_ANG_PIT_P to 6 and ATC_RAT_PIT_D by half. This looked decent but we were still seeing overshoot when braking from high speed (> 8 m/s):

image
image1817×1043 22.5 KB

Flight 86: No payload. Dropped ATC_ANG_PIT_P to 4.5. This was looking promising but unfortunately we hit another oscillation when braking from 12.5 m/s. It probably would have recovered but we switched into AltHold just in case:

image
image1817×1043 23.1 KB

Flight 87: No payload. Dropped ATC_RAT_PIT_D to 0 just to really confirm that this term is necessary for stability. This definitely made things worse again, and we were getting really aggressive oscillations when braking from 8m/s:

image
image1817×1043 20.3 KB

Flight 88: No payload. Increased ATC_RAT_PIT_D to 0.002 (half of what it was before) and decreased ATC_RAT_PIT_P by 30%. We thought maybe some D with a lower P would prevent the oscillations. This was better but unfortunately we still had large overshoot when braking from 10m/s:

image
image1817×1043 21.9 KB

Flight 89: Same parameters as before, but we added 20L of payload (which is 40% of the total payload capacity). We wanted to see if the additional mass would add some stability. Unfortunately it did not, the overshoot persisted:

image
image1817×1043 26.6 KB

In the afternoon we did 10 more flights where we did some more risky experiments (will post logs tomorrow):

  • Tried adding in some ATC_RAT_PIT_D_FF based on @andyp1per’s suggestion. This didn’t seem to make a difference but we likely didn’t add enough (due to fear of losing the vehicle).
  • Tried setting ATC_INPUT_TC to 0.2 as a band aid fix to see if slowing everything down would help. It did not.
  • Tried dropping ATC_ACCEL_P_MAX to 1900 to really slow things down, but this counterintuitively made this even more wobbly.

So overall we haven’t really made any significant progress towards root causing this issue. Here are my takeaways from today:

  • D-term is (for some reason) very important for this vehicle’s stability, which seems very suspicious to me.
  • I get the feeling that lowering the PIDs and rates doesn’t seem to be addressing our root issue. It seems to have an impact for sure, but the issue seems to always be there the faster we go.
  • In all of the overshoot cases we seem to have the same chain of events: PIDP.Tar requests an roll rate to achieve the braking angle, which the vehicle hits. Then PIDP.Tar drops to try to hold that angle but due to inertia the copter keeps pitching. I-term builds up, and at some threshold it suddenly corrects and overshoots. One thing I’ve noticed that the PIDP.Tar has a pretty steep “triangle” shape where it requests a roll rate until the desired angle is achieved and only then starts backing off:

image
image1817×1043 65.1 KB

@Leonardthall would it be possible to have the rate controller start backing off the target pitch rate before the target angle is hit? Basically as we get closer to the target angle we want to reduce the pitch rate instead of waiting until the target angle is hit to reduce the rate. So when the target angle is hit the pitch rate is already close to 0. I’m hoping that this would allow the rate controller to keep up with the inertia of this vehicle without needing to build up I-term.

We’ll be flying all day every day until this is fixed, so any suggestions are welcome!

Thank you.

8

You dont need the FFT or a 2nd notch filter:

FFT_ENABLE,0
INS_HNTC2_ENABLE,0

The ESC RPM is wrong, it doesnt match the noise frequency.
See if you have some way of correctly specifying the number of motor poles so the harmonic notch filter works correctly. Until then, these are the notch filter settings you were looking for:

INS_HNTCH_FREQ,20
INS_HNTCH_BW,5
INS_HNTCH_FM_RAT,1
INS_HNTCH_REF,1
INS_HNTCH_HMNCS,2
INS_HNTCH_OPTS,2

If you get the ESC RPM reporting correctly, just change INS_HNTCH_HMNCS to 1.

My feeling is ATC_ACCEL_x_MAX values should probably always be above about 10000. As you found, going too low is LESS stable instead of more stable. I think your P and R accel values could be around 13000. This increase shouldnt be detrimental.
I think these could go back to a bit more conventional:

ATC_RAT_PIT_D,0.0045
ATC_RAT_PIT_I,0.111

I would be tempted to try these Loiter values:

LOIT_ACC_MAX,600
LOIT_BRK_ACCEL,200
LOIT_BRK_DELAY,0.3
LOIT_BRK_JERK,300

maybe halve those except for the delay value. Increase the delay if you find Loiter is unnecessarily braking.

I was looking at log 86 at there is a weight bias towards the front of the copter, unsure if that was because of the payload, or lack of payload. Best to keep the copter well balanced for tuning.

Standardise these:

INS_ACCEL_FILTER,10
INS_LOG_BAT_MASK,1

I’d definitely be putting back the other logging to standard later when all issues are solve - just a reminder so log size doesnt get out of control.

I noticed these:
PILOT_TKOFF_ALT probably should be at least 100 to get up out of ground effect, I use 200.
These might need checking: RTL_ALT and RTL_CONE_SLOPE

9

I gave you two things to try and from what you have shown me here the lower I term has solved the problem:

After that you randomly tried a bunch of things without any clear methadology from what I can see.

10

This is extremely accurate, we were frankly totally lost and just shooting in the dark that day.

However, on Saturday we made a few breakthroughs. We first updated some of our filtering as suggested by @xfacta and Matt:

  • Removed the primary harmonic notch at 16hz and just did 1 notch at the 2nd harmonic (to reduce phase lag).
  • Increased ATC_RAT_PIT/RLL_FLTT to 20 to further reduce phase lag.
  • Decreased INS_ACCEL_FILTER to 10 to match the official documentation recommendation.

We then went back to stock PID gains and tuned manually using @Leonardthall’s guide, first with ATC_RATE_FF_ENAB = 1, then switching to 0 after gaining confidence. Surprisingly this gave us much higher gains than we had previously.

We then did a bunch of high speed braking maneuvers with the new gains and generally the Copter was behaving extremely well, but we would occasionally see some rapid oscillations while braking from time to time (see flight 124). We then kept the high gains but reduced ATC_ANG_PIT_P, and this final change got rid of the oscillations.

I think what happened here is that we simply didn’t give enough credit to the vehicle, the motors responded really well to higher gains. To our surprise, after adding 20L of payload the copter started performing even better. This is a graph from that flight showing really solid angle control (by far the best we had seen) (flight 127):

image
image1817×1043 17.2 KB

We further analyzed the vibrations and ended up adding a notch at the 100hz and 200hz noise peaks that were still prevalent in the gyros, which also seems to have helped a bit.

Today we also brought back up the PSC gains and we now have a config that both holds position well and is able to brake from 13 m/s reliably.

The tune is still a bit noisy and with extremely over-payload cases it struggles but I think we can close this thread now. We’ll continue tuning until the cows come home.

Thanks again for all the help everyone!

11

Be aware it’s usually unnecessary to add notches at higher frequencies - if you check the graph you may see pre-filter peaks but there is probably no post-filter peaks. That noise rarely gets past the low pass filter. More options and notches than absolutely necessary just adds more CPU overhead for no gain.

12

Congradulations, I am glad you managed to get things working well.

13

I checked log 127.
You could pick the 4th harmonic (near 100HZ) but any other extra selections are not necessary.

In Attitude control there’s some small oscillations pre- and post-landing, which may just be due to very big props or long landing gear.
You could upgrade firmware to 4.6 Beta 3 and set these:

ATC_LAND_P_MULT,0.8
ATC_LAND_R_MULT,0.8
ATC_LAND_Y_MULT,0.8

Try that and provide feedback please.
The 4.6 Beta3 firmware is quite safe to use, myself and others have given it quite a workout and I couldnt find any strange behaviours.

1 Like
14

Got it, that makes sense. We’ll test out 4.6 as well as the 4th harmonic only at 100hz. Thank you!

15

Just so I’m clear, leave the other notch filter settings in place, it’s working OK, just add in the 4th harmonic.