Hi, two my quads suffer from ALTHOLD mode failure. When I keep the throttle constant, quad sometimes descents quickly. So I have to switch to STABILIZE mode to prevent the crash.
Arducopter 4.5.7.
SpeedyBee F405 V3 for 5” quad and Matek H743 for 7” quad.
F405.log, timing 08:20:03, 08:32:30 etc
F743.log, timing 00:06:45, 00:21:45 etc
For H743, the vibration levels are insane, so for this I would say everything can happen. My suggestion is to fix either the frame or the tuning (or both).
For F405, I see that the barometric altitude seems to be affected in a significant way by the propellers: the more the PWM, the greater the altitude. Also - not sure which one is the cause and which one is the consequence - descents are correlated with very high PWM variations, which looks like propwash oscillations to me. Together this may confuse the autopilot - as the propwash starts, it feels that as less pressure on the barometer and starts to think that the copter goes up, so it decreases the throttle, which reduces the attitude authority and adds more propwash, etc etc.
MOT_SPIN_MIN seems lower than the default, and the motors don’t hit the floor on the descent before propwash starts, so it’s not the case. The machine seems to have undergone some tuning, but it still looks noisy to me (from ATT.Pitch vs ATT.DesPitch, same for roll). The overall vibration level, as per VIBE, seems way better here, but possibly some resonances are not ruled out. There are no ESC entries, so you are not using ESC/bdshot telemetry, why?
So for the F405 machine I suggest checking the airflow (maybe get some barometer isolation, e.g. open foam or something) which would hopefully reduce the altitude measurement sensitivity to propeller outputs, and consider using ESC telemetry and paying attention to spectral characteristics of the frame noise to reduce the overall control noise, improve tuning and reduce the likelihood of getting bashed by propwash.
(That’s not a very good analysis, in particular I have no idea what caused the EKF altitude measurements to go from ~64 to ~32 meters at 790.xx seconds, but things above are worth paying attention to anyway)
A kind of bad advice is to increase ATC_THR_MIX_MIN a bit, maybe to 0.2, which has some chances to improve attitude handling when descending quickly, at the cost of descent speed. But these things are only advised to modify on well-tuned machines, which is not 100% applicable to this machine yet. Another quick fix is to decrease the landing speed, ideally to something which does not yet induce the propwash oscillations, but again, it’s always better to fix hardware and tuning first.
Thanks for your analysis.
Why? Barometric altitude decreases. So autopilot can’t think that the copter goes up.
AP doesn’t support bdshot for SpeedyBee F405 V3.
I’m talking about local changes as opposed to general trends. For instance here:
It’s clear that the general trend is falling down, but the copter in the reality is definitely not jumping +1m and -2m in consecutive 1/10ths of a second. For this part, it kind of seems that PWM peaks map to local minima in altitude, but based on what happens at 787.4-787.6, it’s rather phase lag, because a longer minimum in PWM causes a longer minimum in altitude with a delay.
What’s more, switch to stabilize causes the altitude measurement to go 12 meters up in 0.2 seconds, which would be somewhat unrealistic, also given that the subsequent measurements go down even if you hold the throttle at the same level:
So this is definitely something like sudden flow changes that confuse the barometer. If you check the logs, you will see false peaks like this at all occasions you switch to Stabilize with high throttle - again, I interpret these as “false” because the measurement goes down a bit later with the same throttle still applied.
I have SpeedyBee F405 V3 STACK. You have V4. AP supports bdshot for this fc.
