Tilt when getting up

My drone, which was able to take off properly in position hold mode before, has now started behaving like this when taking off, what do you think?
Crsh - Google Drive (3 departure attempts on the same day)

OK, upload a .bin log of the tip-over event, and .bin log of a good flight.
Also use Loiter instead of PosHold, but that is unrelated to this issue.

I wont be surprised if Fence and other safety features are not implemented.
Fence is critical with anything larger than a racing/fpv quad due to size/weight and expense - you dont want these things disappearing over the horizon, nor crashing into objects or people.

Can you explain why I should prefer loiter over position hold?
I will take into account your warnings about security measures.
I have uploaded logs of successful and unsuccessful flights to the drive.

PosHold is old and superseded by Loiter.
Here are the available parameters for PosHold:

Here are the parameters available for Loiter:

A much more comprehensive set to tune how you like. PosHold should be deprecated to save a bit of valuable flash!

I looked in the latest tip-over log

The 1st GNSS unit (GPS0 in logs) has a terrible update rate, it’s clearly overwhelmed by the number of satellites and constellations. See on the map the position of the two GPS units is vastly different.


See if you can do a firmware update for the first GPS, (GPS0) and also set:
to check if the situation improves.

If the second GNSS unit is more reliable then I would swap their position (connectors) and parameters and set:
GPS_AUTO_SWITCH,4 → Use primary if 3D fix or better, will revert to ‘UseBest’ behaviour if 3D fix is lost on primary

and check the associated parameters, this will save a lot of tears.


Plus there is a few other things that may need refinement. What battery, motors, props and ESCs do you have exactly?

Your battery voltage drops very fast too, and there’s no current monitoring which will come in handy.

Also set these now, ready for more tuning work when you supply the requested info
INS_HNTCH_ENABLE,1 ← set this then refresh params to see the rest

If that poor GNSS unit, the ublox, does not come good then disconnect it and throw it away - it’s just consuming power for no value

My motors are t-motor p80 120 KV. This is the battery I use Tattu Plus1.0 22000mAh 44.4V 25C 12S1P Lipo Smart Battery Pack with AS150U Plug.
2. gps emlid reach rtk m+ . I was surprised that the gps can really affect the battery so much. I can’t remove my external gps because the gps on the navio is not very good. Did you notice what is causing the problem now, which was not a problem in my previous flights? Because I had a good flight 4 times before.

thanks i will check it out

I suspect the tip overs were possibly because one or more motors were not starting up reliably. These T-Motor ESCs and very large props are sensitive to having just the right MOT settings.
With these big copters it’s also very important that the GPS position is stabilised before launch so the copter doesnt try to move laterally and snag the landing gear. You also dont want it disappearing over the horizon if does a RTL.

What prop size do you have?

Set these in addition to all the ones I listed previously

I recommend changing these to
but you MUST check in MissionPlanner motor test that MOT_SPIN_ARM produces reliable motor start up and smooth running. Ensure MOT_SPIN_MIN is set to the ARM value + 0.03 or there abouts.

When you next do a test flight use AltHold, or preferably Stabilise mode, to launch and try to hover for a while in AltHold mode.
Hover thrust will take some time to relearn after those changes, so you will need to manipulate the throttle somewhat until hover is stable. Then just move around gently in AltHold, no acrobatics required :slight_smile:
Try out Loiter if you can too.


I just meant the very poor GPS is just another device sucking some (tiny) amount of power. They dont use much at all.
Since that onboard GPS is poor and cant be removed, and the external one is good, set these:
and that should ensure the good GNSS unit is used unless something goes drastically wrong.

Dont skip the Fence or other Batt settings I mentioned, during testing is when you need these the most.

I am using a 30 inch propeller

I will definitely take what you said into consideration.

Did you decide on these after seeing my battery?

And did you enter these values in the notch filter because of my vibration values?

I want to be good at this job. Are there any resources you can share about the details or is just the ardupilot site enough?

Yes for the voltages, and for the MOT values I believe you are using T-Motor Alpha ESCs since you didnt mention otherwise.

No not vibrations, but FFT graphs since you already had some INS_LOG settings in place.
There may be some adjustment after more test flights, but those values will do for now

Mostly everything you need is here in the forum and in the docs. A lot of Youtube stuff is outdated.
The general idea is to get everything working quite well, including the filtering and move on to Autotune.
Component selection is very important - some builds are never going to work because of mismatched components and mismatched expectations.
There are often quite a few test flights, particularly with the bigger props.
And the flip-side is : a good build with plenty of time on the bench going over parameters before fight might only need 1 or 2 test flights before being fully tuned and ready for work or play.

The tuning guide, along with the Initial Parameters section in MissionPlanner
Harmonic Notch Filter
Some wiring info

yes esc is inside the engine so i know that way too

thanks, i will apply these and go on my test flight

Is there a possibility that the compass calibration may be corrupted after the first installation and can I see from the logs that it is not corrupted?

Unlikely, there would be compass errors and warnings in the log.

See if you can make all the changes and do a test flight with plenty of yaw, circles, figure 8 patterns…
Then we can check and adjust the compass settings with Magfit from the .bin log.

I always get this warning in automatic analysis, doesn’t it indicate a problem?

The automatic analysis is outdated, dont rely on it.
Stick to the plan then do a test flight with lots of yaw.