Done flipped after switching from stabalize to ALT_HOLD

Hi @rmackay9, @dkemxr , @MaxBuzz and everyone , I need help in analysis of attached logs .
Hardware used - pixhawk 6c mini, unirc 7, air40a esc, 5008 340kv motors and pm06 module. Now what happened was that , we were testing the drone in stablize mode and altitude it was flying perfectly and after two days we again tested the same drone without changing anything first it flew in stablise mode for some second then after we switched it to alt hold mode and within 15 seconds drone crashed by flipping.
these same issue we have faced earlier with two drones it flipped.

00000008.BIN (940 KB)

Has this been configured and tunned using the ArduPilot documentation?
Are you sure you did not miss a configuration step?

Use AMC to make sure that all the steps are done in the correct order and with a minimal number of test flights.
It minimizes trial-and-error and gets you flying safely faster.

yes i have tuned it as per ardu docs.

How did you make sure you did not miss a step?

Do you have a checklist?

  • If yes, post it here so that we can see it.
  • If not, describe the steps you did.

i have autotuned it and it was perfectly stable in loitre mode.

Autotune is just one step. And it requires many other steps to be done first.

If you have done Autotune without doing the other steps, it will do a sub-optimal tune.
Did you tuned the altitude controller? Did you tuned the dynamic notch filters?

ArduPilot is very forgiven, and works okish when you skip a lot of configuration steps. But that does not mean that your vehicle is working optimaly.

Hi @Dtown,

Looks like the arming checks have been disabled (ARMING_CHECK = 0). This is generally a very bad idea. I know they can be annoying but they will find issues and improve safety.

The logs just suddenly end with the vehicle in the air. This is normally a symptom of a sudden power failure. A sudden software failure is also possible but in those cases you should see a watch dog warning on the next boot and it will appear in the next log.

The POWR log message sometimes shows issues if there are issues with the power being provided to the autopilot but it doesn’t show anything this time.

In a general sense Copter-4.6.3 is very stable so I think it’s unlikely to be a software issue but it’s not impossible. It looks like the vehicle was very close to the ground, perhaps this is a new build?

BTW, the change in flight mode is just a coincidence I think. The flight mode change happens a few seconds before the crash so it doesn’t seem directly related.

Hope that helps, thanks for using AP!

1 Like

Sir, drone flipped and after that power failure occur , we have faced this incident earlier also it got crashed. we accept that we have turned off the arming check but we have flown the vehicle day earlier on stablize and alt hold mode for about 20 min and didn’t find any issues. same we did today but met with the crash. could you help us finding the issue as per our findings it is due to ekf error or internal compass issue.

can you guide us how to do perfect tuning? for commercial usage of drones as we have many orders .

Yes, I can. I provide the free open source software AMC and provide professional consultancy on optimal tuning.

1 Like

That’s not what the log indicates. At the time of power loss the attitude does not show it has flipped. The small amount of pitch it had (~13 degrees) was commanded.

Looks like a sudden power loss to me.

1 Like

it might not showing as it was at very low altitude when it crashes.

It shows a pitch command by the pilot which it executes and it loses power and logging stops. I don’t see what difference it makes what the altitude was. There was a GPS Glitch or Compass Error ~ 1s before logging stops. Probably because of the same power issue about to happen.

Before flying again you should configure the Vertical Acceleration Controller gains based on hover thrust properly. But, this will have nothing to do with the event it’s just a step in you missed.

And I suppose you ran Auto Tune w/o 1st configuring a notch filter.

BTW-Were you flying this craft or is the pilot telling you what happened?

2 Likes

pilot was flying and i was there at that moment , these things has already been happened before with our clients. even i have given the demo somewhere and same happened . also we usually calibrate the drone before flying and then it happened. Can you check where we are lagging as i know that their might be a issue with the drone tuning i just want to know where is the exact root cause as wiring and all are perfect

It doesn’t look like a tuning issue to me. Yes, you should set the PSC_ACCZ_P/I parameters correctly and configure the notch filter before running another Auto Tune but the lack of that won’t cause this type of event. And obviously turn on all arming checks. That’s troubling being disabled for a commercial craft.

What do mean by this? What calibration?

1 Like

compass calibration

Generally there is no reason to do that more than once with Magfit during the tuning process.

2 Likes

not while tuning as it shows deflection in heading before flight so we need to do the compass calibration to correct the heading of drone

I don’t know what you mean by that. The only time you have to redo a mag calibration is if the hardware or battery has changed. So you are doing a Magfit calibration before what? Every flight? Anyway, that’s a different topic. I don’t think there is any more I can add to this one.

1 Like

most of the the everyflight.
is “GPS/Compass glitch shortly after transitioning to AltHold. This sensor disagreement likely confused the EKF (Extended Kalman Filter), causing the flight controller to command an aggressive, un-commanded pitch forward in its attempt to correct what it mistakenly perceived as a position or heading error.” this could be the reason??