Cause of Divergence Between ATT.Yaw and AHR2.Yaw

[trituner (Jim Smith)]

Hi all,

I recently experienced an issue where my drone started uncommanded lateral movement within several seconds of takeoff in Loiter. On log analysis, I found a significant divergence between the ATT and AHR2 yaw values that appeared to be resolved by an EKF lane change when I switched from Loiter to Stabilized.

This drone has been flown in Loiter previously without issue. I am using a Cube Orange with ArduCopter 4.2.3. I have a HERE3 GPS/Compass mounted on an external mast ~5" above power wiring. The internal compass is currently disabled due to noise from the Cube’s heater, which is on a significant amount of time for outdoor winter testing in Colorado.

Can someone point me in the right direction for digging deeper into the root cause of this issue?

Thank you!

Log: https://drive.google.com/file/d/1gqcINRpjWOUyMZuHtsGypLkvmDF7mKyo/view?usp=sharing

[xfacta (Shawn)]

The GPS speed instantly going to 14m/sec is not good, and signs of poor GPS position or interference.

And the GPS update rate is way less than ideal

There’s a lot of things going on with position controller, RC inputs and vibrations. I suspect it’s all because of being in Loiter mode and having a wandering GPS position causing the copter to move laterally. It looks like the RC inputs and vibrations are effects of the sudden movement, then you switch to Stabilise to save the copter.
If you look on the map of that log there is total lack of any GPS track, at least no where near the IMU track.

Related to this problem I would set these:

• BRD_BOOT_DELAY,3000 to allow the CAN GPS to boot before the flight controller
• FENCE_ENABLE,1 wont allow you to arm until Home can be set
• GPS_GNSS_MODE,7 to limit the number of constellations

and check if there’s a firmware update for the CAN GPS unit

Priority should be to update to latest stable firmware too, 4.3.3 at this point in time. There is important fixes for Cube Orange, and plenty more of course.
In relation to other parameters I see that you SHOULD set:
BATT_FS_CRT_ACT,1
BATT_FS_LOW_ACT,2
and these will help
INS_HNTCH_MODE,1
INS_HNTCH_REF,0.16
INS_HNTCH_FREQ,30
INS_HNTCH_BW,15
INS_HNTCH_FM_RAT,0.7
INS_LOG_BAT_MASK,1
INS_LOG_BAT_OPT,4
LOG_BITMASK,180222 ← no need to log raw IMU

Do you have T-Motor Flame or Alpha ESCs?
This is the PWM range for them
MOT_PWM_MIN,1100
MOT_PWM_MAX,1940
There might also be some experimentation or testing related to setting the MOT_THST_EXPO correctly, and also recheck the MOT_SPIN_ARM and MOT_SPIN_MIN.
If you change any of those, Hover Thrust needs to relearn, so give it some time in AltHold.

If you can get a good valid flight post a link to the .bin log file.
See if you can do some yaw and circle pattens
We (or you) can run that log through MagFit to improve compass settings.

Opinion: anything bigger than a small FPV quad, should use every safety option and setting available to ensure there’s no fly-away or unexpected lateral movements. And you dont want these things disappearing away to Sea of Japan when RTL triggers.
You should see what a large CF prop can do to a solid lump of galvanized steel!

[trituner (Jim Smith)]

Hi xfacta,

Thank you for your reply. Prior to our next flight I am planning to update FW to 4.3.3, check the HERE3 GPS module for firmware updates, and update the parameters you specified, including: BRD_BOOT_DELAY, FENCE_ENABLE, GPS_GNSS_MODE, the battery parameters, and the harmonic notch filter parameters. I’ll also verify the ESC variety, set the PWM values accordingly, and review the MOT_THST_EXPO and MOT_SPIN parameters.

Weather permitting, I’m targeting a follow up flight this Friday and will post the .bin once I have collected additional data.

@xfacta

If you look on the map of that log there is total lack of any GPS track, at least no where near the IMU track.

What parameters are you looking at to determine the GPS and IMU tracks? The GPS Lat, Lng, and Spd all appear to track the drone’s actual behavior when it began drifting during the test flight.

I looked into the PSCE/N data today, specifically the TVE and VE values. Prior to the Yaw Reset and EKF3 Lane Switch 1 events that occurred around when I switched to Stabilized, the VE value appears to inversely track TVE. At that point in time, the drone was flying west at an increasing rate as captured in VE. This appears to be related to the ATT.Yaw value in my original screenshot, which also suggests our calculated heading was roughly 180deg off from the drone’s actual heading. Do you know what could lead the controller to develop such a significant offset between calculated and actual heading?

Thank you again for your time looking into this!