Hello, I have a problem I’m trying to work through.
[PROBLEM]
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.
[HARDWARE/SETUP]
Navio2
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 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.
[WHAT I AM SUSPICIOUS OF]
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?
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.
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. 273.bin (300 KB)
This same behavior replicated on the following AC-4* versions:
4.0.1
4.0.2
4.0.3
4.1.0-dev
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
Motors
ESCs 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.
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.
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.
