Insane Roll/Pitch Behavior in GUIDED Mode Only

Hello, I have a problem I’m trying to work through.

When flying in GUIDED mode, the drone aggressively rotates out of control along the pitch and roll axes. I am testing a very simple dronekit script to takeoff and land. The drone flies fine in LOITER mode right before attempting the script. This happens consistently when attempting this GUIDED mode dronekit script, and it is all so confusing because it consistently flies fine in any non-GUIDED/AUTO mode.

This is a simple script I have ran successfully many times in the past, and even on this drone.


Raspberry Pi 4
OS Image: Buster
ArduCopter Version: 4.0.3
Pi Cam with shielded/insulated ribbon cable
External M8N GPS and Compass connected via UART port
TF Mini Rangefinder connected via USB->UART

92.bin (926.5 KB) 93.bin (625.5 KB) 94.bin (1.1 MB)

92.bin is a manual and successful LOITER flight right before the crashes
93.bin is a GUIDED mode crash powered by a dronekit script
94.bin is a another GUIDED mode crash powered by a dronekit script

In 93.bin and 94.bin, the actual pitch/roll is way higher than the desired pitch/roll in the ATT log type. There don’t appear to be any errors flagged by the FC until the drone crashes.

I am wondering if this is an ESC synchronization issue, and the takeoff command in the GUIDED script occurs too quickly and the motors respond different. In the past, occasionally the ARMING MOTORS command in the dronekit script would only successfully arm 3 of the motors, and the drone would immediately flip when the TAKEOFF command provided thrust, which also makes me suspicious of maybe an ESC sync issue?

Once I fix the drone after the crash(es), I am going to attempt a dronekit script once it is already in the air to test this hypothesis.

[HELP ME :)]
Does anyone see anything suspicious in the log files, or have any ideas on what may be causing the crazy pitch/roll behavior in GUIDED mode?

Thanks so much! :smile:

Hi @caleb,

I’ll look into your log files and will let you know about any results and conclusions.

1 Like


I downgraded to AC-3.5.5 and everything works perfectly, GUIDED mode works fine. There seems to be something about AC-4.0.3 that specifically affects GUIDED mode. Of note, my compass heading is 180 degrees off in AC-4.0.3 when using the external compass, but works fine in AC-3.5.5. Might be related or might be a separate issue.

Hi @caleb,

Glad that you’ve resolved your issue!

Is it possible that after downgrading you’ve done something specific that was not done on the new 4.0.3 version? Maybe, additional calibration?

Hi there Mikhail,

I would say with almost certainty that this is not the case. Additionally, external compass discovery in 4.0.3 had the compass heading off by 180 degrees, while in 3.5.5 it was correct.

I would like to update this issue with my latest findings, which appears to make AC-4.0.* unusable for dronekit.

My baseline test is to takeoff the drone into the air at 1m using the python dronekit package using a quadcopter. Tests can be performed by taking off all props and calling the dronekit script which initiates the takeoff, so the behavior can be reproduced without having to crash the drone.

Analyzing the RCOUT message shows the issue clearly:

C3 and C4 (motor 3 and 4) have PWM raised upon an attempted takeoff. C1 and C2 (motors 1 and 2) lag the output of C3 and C4 considerably, and therefore the takeoff is extremely unstable and the drone yaws CCW with unequal thrusts on each motor.
image 273.bin (300 KB)

This same behavior replicated on the following AC-4* versions:

The unequal thrust output problem goes away when using AC-3.5.5
3.bin (493.4 KB)

Variables that were changed but still reproduced the problem:
Navio2 Board
Variables that were consistent across tests and could therefore be rules out:
Dronekit version
Navio2 distro (buster)

Additionally, the unequal PWM values for the motors persisted with props off, which removes any CoG or bad prop variables from a potential diagnosis.

I am left concluding that something about the AC-4. firmware is the issue*. Since I changed just about all the hardware possible and kept reproducing the problem, it appears this problem will persist for all Navio2 users using AC-4 who wish to program with Dronekit (and likely AUTO missions).

Hope this problem can get some attention, as I am afraid this could put the longterm viability of the Navio2 on precarious grounds for dronekit users.

Hi Caleb,

Thanks for the detailed description of the tests! We’ll look into the issue.

May I ask you to share if you tried controlling your drone via, for example, Mission Planner? Just to confirm that the issue occurs while working with the dronekit only.

1 Like

any solution yet ?
can i at least downgrade from 3.6 to 3.5 ?

Hi @iyad.salameh.44,

We’ve released the new image for Navio2. It should fix issues with the Dronekit connection. It’d be great if you could update it and check if the solution works for you.

The full list of the fixes and improvements can be found in this community forum thread.

This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.