Regression after upgrading to ArduCopter 4.7 (vibrations and LAND/RTL behavior)

ArduCopter Copter 4.7
1

Title: Regression after upgrading from ArduCopter 4.6 to 4.7

Hello everyone,

I upgraded my quadcopter from ArduCopter 4.6 to 4.7 to test the new version and compare its behavior. Unfortunately, after the upgrade I experienced several problems that I did not have with ArduCopter 4.6.

The first issue I noticed was a significant increase in vibrations. I could clearly see more shaking through my FPV goggles, and the flight felt less stable compared to 4.6. Looking at the logs, the VIBE values are much higher, especially during descent, where the vibrations increase considerably.

Another thing I noticed is that the vertical controller parameters changed from PSC_ACCZ_P and PSC_ACCZ_I in ArduCopter 4.6 to PSC_D_ACC_P and PSC_D_ACC_I in ArduCopter 4.7. From what I understand, the vertical controller implementation and parameter behavior have changed. I am not sure if this is related, but could these changes be responsible for the increased oscillations and vibration levels? With the same hardware and setup, these issues were not present in ArduCopter 4.6.

I also experienced unexpected behavior during landing. The vehicle was already in LAND mode and had reached the ground, but instead of stopping, it suddenly increased throttle and tried to take off again with significant force, as if it had not detected that it was already on the ground. This behavior never happened with ArduCopter 4.6 using the same aircraft configuration.

In another landing attempt, while the vehicle was already in LAND mode and only a few meters above the ground, a Battery Failsafe warning appeared. Immediately after this warning, the flight mode changed from LAND to RTL. I tried to switch back to LAND, but the vehicle ignored my command and continued with RTL.

The hardware has not changed: same frame, motors, propellers, ESCs, battery, flight controller, and payload. The main change was upgrading from ArduCopter 4.6 to 4.7 and migrating some parameters.

Has anyone experienced similar behavior after upgrading from ArduCopter 4.6 to 4.7? Could these changes be related to the new vertical controller or failsafe behavior in 4.7?

2

Please provide logs with both 4.6 and 4.7 flights.

Both from my experience and from what I observe on the forum, the 4.6 to 4.7 transition should not result in anything you describe. Automated conversion normally performs migration correctly. However, if you migrated some parameters manually, you could probably have copied old parameters onto new ones without understanding that their scaling has changed.

3

Of course, I also noticed a change in CTUN.ThO between both versions. It is important to note that in the 4.6 flight RPM filtering was not enabled, while in the 4.7 flight RPM filtering was already active. logs - Google Drive

4

Hi @jhon_mesa,

Txs for the report and logs.

As you noticed the the vibration levels are very different especially in the horizontal axis which has a lower threshold than the vertical. The 4.7 horizontal vibes for the Y axis are above 40m/s/s which is outside the acceptable range (for X, Y they really should be down below 20). Surely the hardware has changed in some way between these flights? Perhaps a screw has come loose on one motor?

4.6 vibration levels

image
image1204×568 72.3 KB

4.7 vibration levels

image
image1204×568 101 KB

The log doesn’t include the LAND and RTL mode issue so we can’t investigate that with these logs I’m afraid.

It might be good to go back to 4.6 for a moment and confirm the vibration issues persist. This is quite straight forward using MP’s “All Options” button which is shown at the top of the 4.7.0 release announcement.

5

I would say that we are comparing trash with trash here.

The vehicle has never been appropriately tuned, in particular, all the PIDs are at defaults, and D-term contributions are a bit too high. In both flights.

This results in motor outputs be like this with 4.6:

newplot
newplot1915×1378 431 KB

and similarly with 4.7:

newplot
newplot1915×1378 498 KB

With constant clipping at MOT_SPIN_MIN, none of the logs can be called a good flight.

I would also say that in these conditions the harmonic notch may have contributed towards the worse - especially given that with INS_HNTCH_FREQ = 80 and INS_HNTCH_BW = 40 and four motors there is probably a severe additional phase lag in the system.

And, of course, the maximum accelerations (ATC_ACC_{R,P,Y}_MAX) are now also at defaults. Previously they were different. This might or might not have contributed towards the overall experience, but it does not really matter.

You should start re-tuning your machine from scratch. Use Ardupilot Methodic Configurator for that, because right now your experience appears deeply insufficient.

6

Providing help is always great but I think “trash with trash” is a bit harsh.

The 4.6 log’s rate tuning is not too bad

image
image1204×568 54.9 KB

But the 4.7 log RATE logs look terrible so something has definitely happened.

image
image1258×653 102 KB

7

I noted that pitch and roll deviations in the new flight are significantly one-sided. This may mean nothing because of all the clipping, but it may also be a sign that weight distribution has changed (and this led to worse responses with the existing problems).

8

Yep, I haven’t adjusted my PID values yet. Right now I’m focusing on eliminating the vibrations first, and once that’s done I’ll tune the PIDs.

I’ll go back to ArduPilot 4.6 and compare the behavior. What I find strange is that it’s exactly the same drone—nothing has changed mechanically, electrically, or in the hardware. The only major change was updating from 4.6 to 4.7.

Also, the RTL and LAND issues occurred on different flights, and I have the log from the most recent flight where the problem occurred. https://drive.google.com/file/d/1PqrBDa2Tk476rAeQz91GgfDuwQ--x6-9/view?usp=sharing This is the log from the flight where the problem occurred. I was using LAND to finish the flight, and after the drone had already touched the ground, it suddenly took off again like a rocket.

In the log, you can see a sharp spike in the altitude after it appears to be on the ground. I’m not sure if I accidentally triggered something or if there is another explanation for this behavior.

I also have a question: is it normal for a drone to take off again or make such a large correction if it remains in LAND mode on the ground for an extended period? Or should it simply stay on the ground until it automatically disarms?

9

There are significant differences in configuration between the logs, including harmonic notch and gyro filtering setup. The stat params indicate a significant number of flights between the two provided logs. I don’t think 4.6 to 4.7 is the only change. Unfortunately because the 4.7 param conversion has now been done, and then more changes made on top the only way to test it would be to wipe params. Go back to 4.6 and restore the config from a saved set of 4.6 params. Then perform the first test flight. Then update to 4.7 and perform the second test flight.

Vibrations, filtering and PIDs are all different sides of the same thing, you cant work on only one while leaving the others fixed.

The vehicle changed into stabilize mode due to a RC flight mode switch change. Unfortunately there is a lot of dropped data in the log so some items are missing. So we don’t actually see the change in RC input log message. But the mode message give the reason for the mode change.

10

Txs for the log.

As @iampete says, it looks like the reason the “took off again like a rocket” was because it was changed to stabilize mode from the transmitter with the RC3 channel raised (input throttle is only 20% but it’s a powerful copter).

The below screen shot shows the “Rsn” code which is defined here in ModeReason.h.

image
image1204×868 54.3 KB

Too bad the SD card can’t keep up with the logging. Our Hardware Report WebTool has a nice graph of what messages are taking up the most SD card bandwidth

image
image785×854 59.6 KB

Maybe removing the “Fast IMU” and/or Fast Attitude from LOG_BITMASK would help a bit or perhaps just replace the SD card

image
image686×220 12.2 KB

11

In a tangentially related note, how does a firmware downgrade handle param “reversion” since 4.7 changes param names and probably their scaled values on the upgrade?

12

Hi @Joshua_Kordani,

It depends a bit on how the parameter was changed:

  1. if the parameter was simple renamed, the name will revert to the older 4.6 name. Any changes made while using 4.7 will persist after rolling back to 4.6
  2. if the parameter was re-scaled (which actually involves creating a new parameter with a new name) then the old parameter and its value will re-appear just as they were when last using 4.6

.. if the above is too much detail then the short answer is, “for most parameters, the old name will re-appear and will have the same value as it had the last time you used 4.6”.

13

Hello everyone, I reduced my vibes, and I’m sure my RPM filtering was the cause of the increase. On the other hand, I’m using ArduPilot 4.7 from scratch, my rates look better, however it continues with some noise, in the next days I’ll change it. Another thing I noticed, in the other logs the CTUN.ThO was around 0.08, but in this version it decreased to 0.06, not a huge change, but curious. On another note, regarding the copter, in the previous flight the battery failsafe forced RTL mode, and while it was in RTL I tried to switch back to Land mode but it wouldn’t let me, it stayed stuck in RTL. So in this new flight I changed the failsafe action to Smart RTL or Land mode, and it didn’t happen again. The vibes could probably decrease if I change INS_GYRO_FILTER from 75 to 60 Hz, but I’m not sure. I attached my log if you want to analyze it, and I want to ask you, is RPM filtering completely necessary to activate or not, and when should you activate it?. https://drive.google.com/file/d/16bkcQHe6sVDVWqL-Ifzzeh7mz57NWzf3/view?usp=sharing

14

Did the copter just die in the air and crash? It looks like logging just stopped. That could be an issue with a voltage regulator or battery connector.

Your vibrations are not high, there’s a bit of X/Y axis but nothing serious.
You dont need to change anything about the vibrations, and anyway it would be a hardware problem if there were significant vibrations.
There’s no harmonic notch filter data collected in this log, but I would assume from INS_GYRO_FILTER,75 that you have 5 inch props, and you have ESC RPM data so you could easily start with this for the harmonic notch filter:

INS_HNTCH_ENABLE,1
INS_HNTCH_MODE,3
INS_HNTCH_REF,1
INS_HNTCH_FREQ,80
INS_HNTCH_BW,20
INS_HNTCH_FM_RAT,1
INS_HNTCH_HMNCS,1
INS_HNTCH_OPTS,2

and see how it looks in logs with INS_RAW_LOG_OPT,9 set.
We need to see the next log to know more.

The battery voltage in that flight didnt go down to your low voltage level, so there was no failsafe action.
If you’re having trouble with the copter descending or losing control before failsafe triggers then ensure the voltage cutoff settings in the ESCs are disabled.

I can see where you selected Land mode and the copter landed the first time, the second time the copter was descending then you changed to Stabilise mode and flight continued. So that doesnt seem to be an issue yet.

The motor outputs are oscillating a lot because the copter has a lot of defaults and there’s no tuning done.
Start with these for 5"

ATC_ACC_P_MAX,162
ATC_ACC_R_MAX,162
ATC_ACC_Y_MAX,56
ATC_ANG_PIT_P,12.0
ATC_ANG_RLL_P,12.0
ATC_ANG_YAW_P,6.0
ATC_RAT_PIT_D,0.001
ATC_RAT_PIT_I,0.06
ATC_RAT_PIT_P,0.06
ATC_RAT_RLL_D,0.001
ATC_RAT_RLL_I,0.06
ATC_RAT_RLL_P,0.06
ATC_THR_MIX_MAN,0.5

Send the next log

15

No, I did not crash. My memory is limited because I am using the internal memory of the H743. Recently I flew in Stabilize mode, and the rates looked much better. I also changed the INS_GYRO_FILTER to 60 Hz. I will try your suggested parameters later, but first I want to make a backup of my current configuration in case something goes wrong. I’ve uploaded my latest flight log. If you have a chance, could you let me know if I need to change my PID values? I’d really appreciate any advice or suggestions. https://drive.google.com/file/d/1LsKybQm9GLOHcnoqDm8Pi-S0QkhPYHWM/view?usp=sharing

16

ATC_ACC_P_MAX,162
ATC_ACC_R_MAX,162
ATC_ACC_Y_MAX,56
ATC_ANG_PIT_P,12.0
ATC_ANG_RLL_P,12.0
ATC_ANG_YAW_P,6.0
ATC_RAT_PIT_D,0.001
ATC_RAT_PIT_I,0.06
ATC_RAT_PIT_P,0.06
ATC_RAT_RLL_D,0.001
ATC_RAT_RLL_I,0.06
ATC_RAT_RLL_P,0.06
ATC_THR_MIX_MAN,0.5

I flew with these PIDs and the copter feels smoother, but I don’t like the delay in roll, pitch, and yaw control. After a while, I noticed that the copter does not recover stabilization with the same speed. When I move the stick back to the center, I feel like there is a delay because the drone only starts stabilizing after a moment. Because of this, I was not able to make very aggressive movements or quick corrections. https://drive.google.com/file/d/1D7HjMeEk-9CMoKI4sAtwF0Ou7BV1n1rg/view?usp=sharing

17

I would advise to keep all those settings I provided and work from there, probably Autotune then adjust for the required response and feel. Attitude control looked OK, so that’s something.
Motor outputs are now nice and under control instead of oscillating, that will help a lot.
Just changing the gyro filter value wont help you much without doing everything else that multirotor tuning requires to go along with that small change. Higher is generally better provided it filters enough of the noise. A flight with suitable log settings (below) will tell us what we need to know.

There’s no notch filter data in that log.
Use these for logging if possible, there will be less memory (or smaller file size) used than the raw log option:

INS_LOG_BAT_MASK,1
INS_LOG_BAT_OPT,4
LOG_BITMASK,180222

Actually, do gather the notch filter data using these log settings before going to Autotune or any other tuning, it makes a big difference to the results by doing all these things in a specific order.

18

Re responsiveness, I’m not sure how large the vehicle is but you might try increasing the ATC_ACC_P_MAX and ATC_ACC_R_MAX from 162 to more like 300 and see if that helps while still remaining under control.

19

Hi everyone, I tried all of your suggested settings and increased ATC_ACC_P_MAX and ATC_ACC_R_MAX to 250. Overall, the drone feels much better and more responsive. However, sometimes I still feel that it briefly becomes difficult to control, almost as if it loses precision for a moment. It doesn’t happen all the time, but I noticed it a few times during today’s flight. I have uploaded today’s flight log, and if anyone has time to review it, I would really appreciate your feedback and any suggestions. Tomorrow I also plan to enable RPM filtering and record another flight log so I can compare the results and see if it improves the remaining issues. Thank you very much for all your help and support! https://drive.google.com/file/d/1senjyVEdOpV0vTz2r2u9zpK_CNp6ycqM/view?usp=sharing

20

Great.
Also try to fly the copter for longer in order to gather the filter data - I realise 1 minute would have just been a quick test.