Troubleshooting hexarotor oscillation movement until crash

Hi community,

I am currently experiencing oscillation problems when I fly my hexarotor.

During the flights, the weather conditions are quite good (very little wind, clear sky). And, before taking off, I check that everything is good, ending with a small engine test. No error message appears on Mission Planner, and there is no noise or suspicious behavior.

Many flights go smoothly, but sometimes the drone starts to oscillate for reasons I can’t explain yet. I am asking you the community to help me to solve this mystery.

I provide you a log file of a flight that almost didn’t happen, due to a wobble at takeoff, and that ended with a crash :
https://drive.google.com/file/d/1tsS6wD6zL1rmYsFWnkt2QZ-jgK1kHOax/view?usp=sharing

Concerning this flight (so the log file provided):
- The drone took off without any problem (ALT_HOLD mode) ;
- A few seconds later, the drone started to pitch forward, without any action from me;
- The drone became uncontrollable, and according to the logs, the autopilot tried to compensate this destabilization;
- I changed the flight mode (LOITER) to try to recover the drone, but without success. I disarmed the engines to limit the damage;
- The drone made a left roll to restabilize itself;
- It finally flipped onto its back as it followed, and crashed to the ground.

I have a few hypotheses:
- A poorly tuned PID problem: when looking at the PIDAerr parameter, there is a significant error between the autopilot command and the drone’s action. But, the other flights in identical conditions, before this log, went without any problem.
- An EKF / IMU / compass problem: I don’t know how to diagnose it, and nothing is visible before takeoff;
- A problem in the engine control: I observe a saturation in the RCOUT commands (from 1 to 6)

I invite you to visualize the log with UAV log viewer to observe and understand my problem :slight_smile:

What do you think about it ?

I join you the schematic of my hexarotor, with the RCOUT numbers

Thanks

1st, if you have a Hexa X you have the wrong FRAME_TYPE selected. 0 is Hexa +

Some of your PID’s don’t make sense. The I term is rarely other than equal to P or perhaps a bit less. Also, some other parameters are at default indicating you haven’t followed the Initial Tuning Guide, which should have been done before your 1st flight.
https://ardupilot.org/copter/docs/tuning-process-instructions.html

You haven’t set the Dynamic Notch filter either.

2 Likes

I had a quick look at the log but @dkemxr’s got it all covered I think. The only thing I’d say though is that I don’t think it’s necessary to immediately setup the dynamic notch filter. That probably helps eventually (I hear good things) but could be skipped for the first flight.

Thanks @ dkemxr for your answer, I’ll test it all and come back to you if I encounter any more problems with it :slight_smile:

1 Like

@dkemxr nevertheless, I have a question: is it possible that the configuration of the drone changes, without action from a user? because it seemed to me to have configured my drone in HEXA X and not in HEXA +. I made some flights before the appearance of these problems, and it was not too bad

Thanks :slight_smile:

What Flight Controller? The circumstances I have read about with parameter resets would change more than just one parameter but I suppose it’s possible. I tend to think not though.

@corentin33,

We sometimes see reports of unexplained parameter changes but I’m quite confident that it is not coming from the autopilot flight code. It is possible that the ground station has done this and if you’re using the MP it would probably have happened while the Setup >> Mandatory >> Frame Type screen was open

We’ve never caught a case where the GCS did this (as far as I know) but if it is happening then it is possible to capture evidence of this by setting LOG_DISARMED = 1 and then any parameter changes will be recorded in the onboard logs’s PARM mesage. So if you can reproduce it then we can catch it in the act.

1 Like