Octarotor loiter mode oscillations and crash during takeoff

Hello everyone,
I am currently working with a large octarotor frame with a all up weight of over 50 kgs. I am relatively new to octarotors and large frames, so I had a lot of difficulty in the tuning process.

Here are the details of the setup:
frame: Octarotor
motors: T-motor P80III 120kv (12S)
ESC: T-motor Alpha 80A FOC (FOC controls not used)
Props: 30" folding props
battery: 66000mah (12s)
pixhawk: Cube orange
weight without payload: 37 kg

For the tuning, I had not changed the advanced parameters in the beginning, but instead continued tuning with the default parameters.
On the first day of tuning, there were slow oscillations and the control was a nigtmare. After a bit of tuning, handling got better. Tried to switch to different modes and it performed adequately.
On the second day of tuning I continued the process, and it further improved. Pitch and roll was pretty good, yaw required more tuning.
Then I realized it would be better to change the advanced parameters and tune from there. So I made the necessary changes according the Advanced Tuning page.

But as soon as I went for the next flight, took off in loiter mode, there were extreme oscillations and crashed, almost 65 degrees of roll at one point. I had set the roll limit to 30 degrees but looks like that didn’t matter.

I have checked the logs but haven’t been able to identify what went wrong. There were compass variance errors during takeoff and landing, only breaching the threshold for brief instances. But other than that there were no vibration issues or anything noteworthy.

Also, one thing I would like to point out is the Octa was powered on for over an hour and a half in the hot sun from when I started. Arming and disarming only for each PID change, I’m not sure but could that have affected it in anyway?

Here is the log file: LOG

The parameters I changed before the last takeoff:
ATC_RAT_PIT_FLTD: 20 > 7.5
ATC_RAT_PIT_FLTT: 20 > 7.5
ATC_RAT_RLL_FLTD: 20 > 7.5
ATC_RAT_RLL_FLTT: 20 > 7.5
ATC_RAT_YAW_FLTT: 20 > 7.5

I really need help in figuring out why it behaved the way it did. Any help would be greatly appreciated.
Thank you very much

Log is access controlled. Rewove that limitation for help.

Hello Dave,
I have removed the restriction. Here’s the new Log file.
Thank You

Hi Dexter,
I think some of the Advanced Parameter guidelines are a bit off for very large props and some of your filter parameters should go back to default at this stage I think. You could try these:


These might have to go back down but try defaults again:


INS_LOG_BAT_MASK,1 (this is for Notch Filter setting analysis if the flight goes OK)

If it’s generally stable on takeoff switch to AltHold and make a hover flight for ~1min, land and post that log.

Hi Dave,
Thanks for the input. I’ll make the changes and do a test flight again.
I’ll have to travel a bit to test something so big, but I’ll do it within the week.

Also any suggestions for the behaviour in loiter mode? And would keeping it powered for a longer duration affect it in any way?

I would guess the filter parameters are too low but we’ll see. I wouldn’t worry about Loiter performance until it’s flying stable in Stabilize and AltHold. No problem keeping it powered.

If the aircraft has been booted up for a long time prior to flight then you may well have had the IMU go through quite a range of temperatures as it heats up (depending on what your settings are). This is not conducise to controlled flight. I would always, as a precaution, conduct a ‘preflight re-boot’ action or just do a hard re-boot after a long period as this will reset the IMU etc. This might not actually be the cause of the crash but is worth noting and considering regardless I would say.

Yes that was my doubt too. When I checked the logs the temperature had increased about 5 degrees and the pressure difference caused the take off altitude to be 16 meters. I was wondering if that might have adversely affected the flight.
I will take the precaution and reboot every flight.
I will be doing the tests tomorrow and will upload the logs.
Thank you

On some Flight Controllers it can produce a static problem from accelerometer offset due to temperature. You can search “the leans” to get more info. But this is not a dynamic effect which is what you are seeing.

And while we are on the subject there is a PR in to compensate the IMU for these effects by collecting data while fixed in position over a range of temperatures. Not sure when this will be available to the common man :grinning:

Hello guys,
I did the flight today. The handling was much better with the new PID and params. Thanks for that dave.
There were some issues though. I checked a few flights with some payloads. The handling was really good in stabilize and althold. However in poshold, there was a quite of bit of wobbling when the craft stopped after every stick input. But that is only in position hold, althold was gold.

Here is the LOG of the first flight.

Here is the LOG with different modes.

There was also a little bit of tilting during takeoff. Had to abort one takeoff because the frame was about to tip over.

Also, that’s great news about the PR, solving the real problems!

It looks OK but definitely needs Auto Tune. But 1st set the Dynamic Notch Filters settings as follows:
INS_HNTCH_ENABLE,1 (then refresh parameters)

Make another Hover flight in AltHold for ~1min and then post that log. Or if you want to assume these filters parameters are going to work go right to Autotune. I would take the extra step as these parameters are just my best guess from your log data.

Hi Dave,
I will make the changes and let you know.
Do you have any suggestions or corrections for the wobbling effect in poshold? Will auto tuning solve the issue?

The issues will be fixed by following the instructions posted.

Hello guys,
I had the test flight and things were going pretty well.
Then as Dave suggested I went ahead with the autotune. I did roll axis tune, it went on for about 15 mins, but even then the tune wasn’t completed and the new PIDs weren’t saved.
I realized the saving issue was my fault as I had forgotten to use the CH7 switch for high and low.

There was an issue with the switch setup, but after setting it up, I started facing a different problem. The motors don’t spin up linearly when armed. In some cases none of the motors start and in others one or two don’t work. I check the servo output after arming and the PWMs are not linear at all. I tried many things including recalibrating the radio and ESCs. Also this problem is there only when I try arming in stabilize mode, it servo output and the motor spinning becomes linear when armed in AltHold.
This is the servo output when armed in stabilize with no stick input. And while testing on the field the motor spin test wasn’t working either, until I set the throttle percent to 15 or higher.

One more point to be noted is that with the same transmitter and a different receiver I have the same motor linearity problem on another quad. A system that worked fine a day before.
Also the throttle failsafe is triggered even when the transmitter is just with 5m of the drone. That is rather new and that went away when I changed the throttle failsafe value from 975 to 965.

I believe the problem started when I began playing around with the switches.
I know this whole problem is irrelevant to the topic at hand, but I could really use some input here. I’ll be really grateful for any help you could provide.

As for the original issue.
Here’s the LOG for the first flight with the new filter parameters.
And this is the LOG from the autotune.
Also the third LOG of the motor linearity issue.

In my experience, the parameter MOT_BAT_VOLT_MAX and MOT_BAT_VOLT_MIN. If these parameter are not set right, motors will not rotates that the same rpm. Moreover, any MOT_x parameters must be set appropriately. Let’s try and keep me posted if this helps, thanks.

You have MOT_SPIN_ARM set to .7 I would guess a mistake in trying to enter .07? You are probably lucky something worse didn’t happen.

The Motor thrust linearization parameters are set correctly, don’t change those.

The flight after setting the Notch filter looks OK but make a longer flight in AltHold and get off the ground. ~1min is good. Then post that log.

I have changed the MOT_SPIN_ARM back to the default of 0.1, but the problem persists.
The behavior is fickle, the motors start spinning in some cases and in others it doesn’t, and in some 7 out of the 8 starts spinning. I’ve tried arming with MOT_SPIN_ARM set to 0.15 and 0.2 and seen similar things happen.

If you are testing this on the bench and the craft is not leaving the ground this could be meaningless. Does it take off and fly in Stabilize mode?

Because of the linearity issue, I aborted the take off and have been testing this on the bench without props.

That will tell you nothing other than the motors turn and in what direction. Use Motor Test in Mission Planner if you want to see if they are spinning up properly.