New Cube Black (4.0.3) and Dual Here2 severe ATT.Yaw misalignment in flight

Just built up a brand new DJI S1000 airframe with new Cube hardware from IR-Lock. All flight control components were purchased within the last two weeks. Aircraft is setup with the two Here2 units running in UAVCAN to CAN1 and CAN2 on the Cube. This is a routine build so motors, props, etc are correct.

Everything on the ground checks out but as soon as it takes off the heading goes all wrong (accompanied by lots of EKF and IMU alerts, video 1 example, video 2 example). Upon landing the heading goes back close to where it should have been.

Here are the maiden flight logs and screenshots of the HW IDs and Here2 Firmwares.

Things of note during calibration etc:

  • Compass 1 and 2 are set as external and used (with compass_scale set to 1.17 per this). Compass 3 was set as internal during calibration but wouldn’t calibrate and was not used. After several successful calibration, the two external compasses would automatically change orientation from None to Yaw 180 (assumed to be the compass_auto_rot).
    Why is internal compass failing even relaxed cal? Why are external compasses pointed toward the front of the aircraft being corrected by 180?
  • Due to PWM motor output the cube carrier board is rotated 180 degrees and AHRS_orientation is corrected by 4=yaw180.

This is the good graph to check, it is very telltale :slight_smile:

Looks like the Mag2 value is closely following the CTUN TH0 value.
Could this be attributed to a hardware issue with that Here2 Unit?

Or that somehow the mag’s are mixed up and MAG2 is also an internal one.
These are the ID’s from a Cube Plane with only one Here2 GPS
and these are your ID’s

You have to set up compass priority correctly

You also need Copter 4.0.4Beta for it to work

Thank you.
So based on your compass priority it looks my dual UAVCAN setup SHOULD have 97539 for Compass_dev_ID1 and 2 and then 131874 or something as compass_dev_id3?
Is the 4.0.4 release pretty stable at this point?
Trying to decide if removing the MAG2 from the loop should be the first step or updating to 4.0.4

The issue is that you cannot set compass_dev_id directly. 4.0.4 is RC2 and safe to use.
Using only one compass is also a working solution.

It looks like you are correct that it was prioritizing internal compasses (131874 and 263178) over the Here2 Units 97539 and 97283.
4.0.4 initial settings

I have updated to 4.0.4 and switched around the order so CAN Here2 units are priority 1 and 2. Does it matter which device is priority 3/4? I cannot uncheck the External box on 131874 (LSM303D).

Nope, AC uses only the first three compasses. But since compass3 is an internal one you have to disable it…

What about rearranging them like this so that priority 3 is a not-external one?
4.0.4 rearranged settings Would you recommend not using internal compass if I have two Here2 units mounted cleanly above the copter?

EDIT: After a reboot it make the 263178 (AK8963) checked for external. So just turning off the Use Compass 3 will resolve that issue and it will only use two external compases?

Might have the issue resolved by updating to 4.0.4 and visualizing the compass orientation. I had priority 1 and 2 as internal compasses and priority 3 as one of the UAVCAN Here2 units. In the picture Eosbandi showed of the sensors/compass/compass vs throttle the Mag 3 was the only good value.

I have disabled Mag 3 and Mag 1 and 2 look good when throttling up to 50% on a indoor test bench.

I will flight test this setup and follow up tomorrow.


Flight tests were uneventful showing the issue to be fully resolved.

Updating to 4.0.4rc2 with the compass priority option was key to prioritizing the UAVCAN compasses over the internal units.

1 Like