Hello all, I have tuned the Rate PID values of Roll and Pitch of my quadcopter (“CUBE Orange+” FC) and it flew well in all modes. After few days suddenly it started twitching (undesired Roll and Pitch movements) in Alt_hold and Loiter modes. The Loiter mode has control over horizontal movement, but the Alt_hold mode doesn’t. Even then, recently my drone oscillated in Roll axis without any Pilot input when in Alt_hold mode. The Des.Roll plot showed Left and Right Roll values when the RCIN1 is flat at 1500. It also took a small backward Pitch input and gave momentum to the drone by the time it touched ground. This caused the drone to flip back upside down and crash.
Need some guidance on what might have caused such undesired roll and pitch movements by FC.
Glad to share whatever information that might help you to diagnose.
I have attached the “.bin” log file for your reference.
VS50 Alt_hold crash log file
There seems to be a very slow change in the drone. I can’t put my finger on what’s going on. How are the propellers mounted? Any chance one could come loose?
I think you have too much filtering. Try this:
Also set:
ATC_THR_MIX_MAN,0.5
ARMING_CHECK,1
Might help to run MAGFIT on both compasses but there’s not enough data in this log for a good calculation.
Hello @Allister, thanks for the response.
Regarding the points that you mentioned:
-
The flight is a simple Alt_hold hover test. In the flights before this, the drone flew well in Stabilize mode. In Alt_hold mode, the drone hovered well for upto 2.5 minutes, and then suddenly these oscillations started.
-
The propellers are mounted with a detachable quick release mount and it has redundant locking. All propellers are tightly intact.
-
Our motors occasionally spin slower when weight is less, if i increase the HNTCH_FREQ to 40 Hz, it will prevent the notch from filtering the propeller noise under that. Hence, i considered 30Hz.
-
We are using only external compass (Here 3+). The CUBE internal compass is not being used. Please specify how to collect the data required for calculation.
Some additional information:
- The drone has a depth sensor, and it is used for altitude upto 3.5 metres, then switches to Baro.
- Can the battery have any factor in causing such issues? because, there are no such anomalies in any flight mode when a Trontek battery is used, whereas these oscillations occurred when used a Dreamfly battery (25 cycles old battery).
This is very rarely a parameter or software issue if the drone has been flying in a steady state in a mode such as AltHold with no significant inputs. In the short time I looked I didn’t see any smoking gun, but I’d still try to rule out everything mechanical.
Not correct. You are using ESC telemetry, and that will move the filter as required. Also by setting INS_HNTCH_FM_RAT to something below 1 it will go below the specific notch frequency. Most times 0.7 or 0.8 are the right place. You can see in the graph I posted that the black lines indicate where the center point of the filter is targeting and the grey bands show the range the filter is working in. The goal is to have peaks below -50db, and with the settings I suggested that is possible.
To get a good data set for MagFit you need to fly the drone in some figure 8 patterns, ideally at different speeds and altitudes. The figure 8 patterns don’t need to be anything fancy, but they just make sure the drone is traveling in all 360 in both left and right turns.
Battery can cause issues. When I looked at the voltage I didn’t see that as a problem here but it can be.
Hello @Allister, after implementing the changes, i did a flight test.
But still, upon switching from Stabilize mode to Alt_hold mode, the drone took Desired Right Roll. Only when i gave a Left roll input, it stayed at one place. As soon as I leave the stick to centre, the drone is again going towards Right.
I am attaching the logs for your reference.
When enabled “All” in Prearm checks, i got a “Logging failure” error. But, if i disable it and arm, the logs are being saved. Can this pre arm error has any role in the instability?
Stabilize takeoff to Alt_hold
Alt_hold takeoff
I did the same test with two different batteries, and the behaviour is same. What else can i test independently to rule out?
This is likely caused by needing to repeat the “accel level” cal again. If this is new, you might have a physical change on the vehicle that needs inspection.
Choose “Level Cal” in this picture after finding some level groung
I agree with @Joshua_Kordani. Have you added weight moved anything significant on the drone? The MOT_THST_HOVER value looks like it might be low, so I wonder what has been done to the drone since it flew well.
Can you share a log file from the drone flying without trouble?
@Allister, here are the flight logs when the drone hovered and flew well.
https://drive.google.com/file/d/1auxO2J3NIAxNcsVM7dtwzZyKAYKM_E8j/view?usp=drivesdk - Loiter flight.
https://drive.google.com/file/d/10fNIVzUvrzmmvRZmScnbHkKbaXDngJR_/view?usp=drivesdk - Alt_hold flight.
This Alt_hold flight is the last time the drone hovered well.
@Joshua_Kordani, I calibrated the Level and Accelerometer again, yet there is no difference in the flight behaviour in At_hold mode.
Nothing has changed structurally between these flights including the payload. I just used two different batteries (both of same weight). Today the drone didn’t flew well with neither of them.
I also did a bench test by removing props, I armed the drone in Stabilize mode and switched to Alt_hold mode.. then also the Des.Roll graph jumped to right Roll for upto 7 to 8 degrees. When I tilted the drone manually to right side, then the Des.Roll came back to zero in some tests and stayed same in few cases.
Bench tests with the props removed don’t provide any useful information other than the motors spin. That doesn’t tell you anything. Might be fun, we’ve all done it. It’s useless for trouble shooting a tuning issue because you are cutting out the control loop (or closing it off depending on how you look at it)
Set:
LOG_BACKEND_TYPE,1 ARMGING_CHECKS,1 MOT_THST_HOVER,0.23
Try a hover in Alt hold again.