Compass heading decrements when turning drone CW

[jerryt1]

Current Behavior

When the drone faces east, the heading displays 270 degrees on the INAV setup page while displaying 90 degrees when the drone faces west. Turning the drone CW causes the displayed degrees to decrement rather than increment. I’m using the Matek M8Q-5883 (the compass inside is the QMC5883). Attempting to resolve the problem by selecting CW 180 Flip (or any of the other options — tried them all) has no effect whatsoever — the degrees displayed and their direction doesn’t change after saving and rebooting.

Steps to Reproduce

QMC5883 with a Matek F722HD

Expected behavior

Correct Heading

Additional context

I believe the problem is with how INAV is dealing with the F/C. I’m using the Matek F722HD, which according to Matek is the F722PX with a DJI connector for using an Air Unit for video. I did select F722PX for the INAV firmware installation and INAV runs fine with every other feature. I suspect the Flight Controller because the compass works fine on my drones using the F722SE and supports PosHold and RTH, but not with the 722HD to which I’m changing over all drones to convert everything to DJI video.

Interestingly, if I select the HMC5883 compass on the configuration tab, the compass displays heading properly on the Setup tab when I turn the drone until I remove power and reconnect, then the compass doesn’t work at all because it’s the wrong target and I must reselect QMC5883. I tried this as a test to try to determine where the problem might lie — hope it helps.

https://pastebin.com/KWxa4gqQ

version

INAV/MATEKF722PX 2.5.2 Aug 4 2020 / 10:32:29 (faaedc7)

GCC-9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]

[issue-label-bot]

Issue-Label Bot is automatically applying the label BUG to this issue, with a confidence of 0.89. Please mark this comment with 👍 or 👎 to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[avsaase]

Maybe this is too obvious but do you have the compass mounted upside down?

[jerryt1]

Well, I'm a circuit designer and a developer, so you shouldn't have to ask. That said, I've designed and built a dozen drones and building a 10" last month I put the F/C in upside down and only realized it when it flipped over on what was supposed to be its maiden flight, so you ask a fair question. :-) But in this case, no, the GPS/Compass is mounted right-side up.

The reason I suspect the F/C is because I've used this GPS/Compass in 4 drones with no problem. They all used the Matek F722SE and have working PosHold and RTH. I've recently (last week) converted two of them to the Matek F722HD F/C using the same GPS/Compass in the same mount and I now have this reversed behavior. In the interest of full disclosure, I also converted from INAV v2.4.1 to v2.5.2 with these conversions. So the F/C have changed and so has the INAV version. But if it was INAV, I suspect you'd be hearing lots of others reporting this problem.

When I discovered the problem, I though I'd fix it easily on the Configuration tab with "Board and Sensor Alignment" by changing the Mag Alignment. But it has no effect. If I face the drone east, the the Setup tab heading reports 270 degrees. No matter what Mag Alignment setting I choose and save, Setup still reports 270 degrees. When I turn the drone CW where the degrees should increment, they decrement instead. Also, following Pawel's recommendation because of changed defaults in v2.5, I did rebuild the entire configuration in both drones rather than loading the prior Diff settings.

Could I have botched something else up? You betcha. But it's not an upside down module... well, not this time, anyway. And if so, I made the same mistake in both drones I converted - that's possible, I am a creature of habit, it's just not likely.

[DzikuVx]

majority of boards works with 270-FLIP. After changing the orientation you have to calibrate

[jerryt1]

Thanks, Pawel. Unfortunately, I've already tried that several times, but just did again on both drones after reading your suggestion - the behavior remains the same on both drones. I tried my normal calibration method of a full 360 turn on each axis and also the "DJI dance" method which does the same thing in a slightly different manner. I then save and reboot, and upon reboot, switch to the Setup tab, but there's no change. I've also tried unplugging the F/C from the computer to force a hard reboot with full power down for more than 10 seconds after calibration, but each time, east and west are still reversed and turning the drone CW still decrements the compass heading value. I suspect the F/C because I'm using an HGLRC Zeus F760 STACK on the 10 inch and that works properly, just as it did on the Matek 722SE F/Cs. The only other change is an upgrade from 2.4.1 to 2.5.2 of INAV.

I feel it has to be either something in INAV, or how it's handling heading info from the F722HD because changing Mag Alignment, saving/rebooting, re-calibrating and saving that is having no effect. Facing the drone east always gives a heading of 270 degrees and decrements the heading when turning CW no matter what Mag Alignment setting I select.

[A2BELE]

Hi, maybe we can help each other.
I’m on my first build with a F722se and when the drone climbs the baro height goes into the negative (bmp280) tried a few of the older firmware’s back to 2.4 and all do the same.
Can’t work out why 🤷‍♂️ I’m running crsf to a tx16s.
I also do Plc programming so can manage most things.
Btw I’m still waiting on compass to turn up so only running gps and baro.

[jerryt1]

I hope no one feels this thread/issue is being hijacked, but I’m happy to Segway and help if I can:

I’m not sure where or how you’re reading the output of the barometer (Blackbox log?), but, the atmospheric pressure goes down as you climb. Are you sure you're actually seeing height and not a pressure reading? Without seeing the F722SE code that is processing the BMP280’s output, I don't know how the barometer's output is being processed. But practically, we really need just the delta change in barometric pressure rather than its actual pressure reading for our application. Therefore, it should be around zero when maintaining altitude, increase positively when descending, and be an increasing negative number when climbing because the pressure goes down as the craft climbs. And from what you’re reporting, that is what you’re seeing.

The primary purpose of the barometer is just to provide a finer tolerance of altitude change. The GPS reading is too coarse to maintain PosHold, for example. Perhaps it could maintain the craft within 6 to 10 meters, but that would be about it. The barometer allows my drones to almost stay still in position on a calm wind day.

[avsaase]

Hi, maybe we can help each other.
I’m on my first build with a F722se and when the drone climbs the baro height goes into the negative (bmp280) tried a few of the older firmware’s back to 2.4 and all do the same.
Can’t work out why 🤷‍♂️ I’m running crsf to a tx16s.
I also do Plc programming so can manage most things.
Btw I’m still waiting on compass to turn up so only running gps and baro.

This is a completely separate and unrelated issue? That said, if this happens in-flight and you are talking about altitude readings not air pressure, then I suspect the higher throttle needed to gain altitude blows air onto the barometer -> higher air pressure -> lower reported altitude.

[jerryt1]

@A2BELE, you can test AVS2's diagnoses by placing a small piece of foam over the barometer to stop prop air flow from affecting the barometer reading. I have a piece of foam over the barometer on each craft - it works.

[jerryt1]

I'm not sure where this issue has been left. Is it in the queue for investigation once higher priority tasks are completed? Or is the status something else? I'm trying to learn the status so I can decide whether I should wait, or move ahead to replace several flight controllers with another model that will support PosHold and RTH. Obviously, I'd rather be able to use the F722HD/F722PX I already have in these drones for which I reported the problem; but I will begin a move to progressively swap them out if I must Thanks much.

[digitalentity]

I was unable to reproduce the issue.

I believe it's either your compass placement (alighment is wrong) or the magnetic interference (something magnetic nearby, either in the airframe or the land/buildings). Note that active buzzers and screws are usually magnetic. As for the environment - avoid anything metal or containing magnetic materials (cars, concrete buildings, pipes, powerlines).

[jerryt1]

@digitalentity, thanks for the feedback of not being able to reproduce the problem. I’ve been wanting to move the GPS/compass rearward in order to place a GoPro on the front; I will do this now to see if that resolves the issue.

Also, I do want to include more info so you know everything:

1. When I test, I do so in my office first with only the F/C connected to power, and that’s through the USB cable that connects the F/C to the computer running the INAV configurator – no battery is connected. I start this way to methodically configure, calibrate, etc., to assure the GPS and compass are displaying coordinates and heading values correctly – currently, two drones, both using the F722HD are backwards as far as compass direction and no settings or flip settings make any difference in the headings they report. And as Pawel suggested, I am calibrating after each setting change. In this scenario, I assure that the receiver and GPS/Compass are connected to live +5VDC on the F/C so they are powered.

2. If that works properly, I’ll then connect a battery to the ESC to see if any additional fields from powering the remaining loads changes anything. I’ll also spin up the motors some (sans props).

3. Finally, I test the system outside with everything powered up and the drone hovering hovering about 3 meters off the ground in PosHold. On the two drones on which I converted from the Matek F722SE to the Matek F722HD, they worked well on the SE version, including multiple uses of RTH. Since converting to the F722HD F/C, the compass degrees decrement when turning the drone CW. No Align Mag setting changes make a difference – whether they include “Flip” or not, the compass still works backwards and registers the same direction when pointing north. On another drone using the Zeus DJI F722 F/C, it works properly in all the aforementioned scenarios just as the others did on the Matek F722SE did..

The foregoing is why I have been suspecting the F722PX/HD versions of the F/C. I hope this helps and I will report back on whether the compass move has had any positive result. Thanks!

[jerryt1]

I've moved the compass to the rear of the drone and the behavior is the same. As a second test, I also took the compass off the drone completely as far as it's wires allow (about 6cm) and held it off to the side while I rotated it - the heading still decrements when I turn it CW and increments when I turn it CCW. Only the F/C is powered and it powers the GPS/compass and CSFR Nano receiver (the compass is not near the CSFR antenna - it's about 15cm away). If this problem is not an incompatibility between INAV and the F/C, I have no idea what else it could be, especially because the compass worked properly with the Matek F722SE.

@digitalentity, when you tried to reproduce this problem, was that with a F722HD or an F722PX? I ask because if you tested with the F722PX F/C and it worked well, that doesn't mean it works properly with the HD version - it's possible the HD is not identical to the PX except for the DJI video connector even though Matek has us using the PX firmware. Thx.

[brainbubblersbest]

Matek M8Q-5883 has a CW270FLIP Setting.
Or a Free Alignment setting of
align_mag_pitch = 1800
align_mag_roll = 0
align_mag_yaw = 2700
What happens in your Sensor Tabs with mag reading?
Please Give us a CLI Output of "get mag"

Magnetometer should have the same readings but in negative to the Accelerometer.
If ACC Z = 1 then your Z on Magnet should have a specific Value in -Z
The Alignment need to Match, and the Sensor Tab Mag readings belongs to up and down, not to North and South.
I Know this is Confusing, but its the behavior.

(Height of Mag Value depends only on Magnetic strength and with Mag Calibration you Calibrate the Middle of that with an Offset, ACC otherwise depends on Earth Acceleration which should always be 1 if you not Move)

-Because of this, Mag Calibration never can Correct a Missaligned Magnetometer.
-If your Mag reading is Missaligned, you need to do it over free Alignment.
-For that, you Glue your Mag to a carton/Paper, Set your FC Configuration to defaults by CLI defaults and safe.
-Turn your Mag and note your Physical Mag readings in correlation to UPWISE (direction to Sky) and DOWNWISE (Direction to Eart) to the Carton/Paper
-X and Y with arrows and Z in a Circle, note also wich direction is +, and wich direction is - ,Do it on both sides.

-You need to understand, that to define the Position of an specific Axis in 3 Dimensions, you need always 2 other Axis.
-This means: if you Turn Pitch by 1800, Pitch is still at the old Position, but YAW (Z AXIS) ROLL (Y AXIS) are turned now vice versa. (They are negated! You Can Watch this on your Paper/Carton helper Tool)

-Begin always with wrong -Z Direction, because this is always wrong by direction when its soldered upsidedown under a GPS Puck.
-And its normed for Aircrafts, also in every Code available, to do the alignment with a turn first on the Pitch (Y) Axis.
-THIS CHANGES THE ALIGNMENT OF Z (YAW) AND X (ROLL) by 180degree +/- on both is now changed, like explained before

type in CLI
align_mag_pitch = 1800
save

Your Z readings should be now Correct

**BUT, your Y and X readings maybe are wrong by one or multiple 90 degree turn at the Z (YAW)
(90 or 270 if the Y correlates with X of your Accelerometer and vice versa.
But by 180 if Y and X are not Swapped, but not in a negated Value related to your Accelerometer)

Try to turn the Z (YAW) Axis to CHANGE THE ALIGNMENT OF Y (ROLL) AND X (PITCH)**

align_mag_yaw = 900
save

-if X and Y are still wrong try 1800 then 2700 instead of 900. you can also use -900 to turn in the other direction

-To be ULTRACORRECT you can measure the Missalignment in degree. There are GPS Pucks where the mag is mounted in a angle of 45 degree around the Z (YAW) Axis too. Just to let you know.

AFTER ALL THAT ABOVE
If your Compass is mounted with a Tilt by 45 degree, Just Look at your Sensor Tab. Figure out wich AXIS beside Z is wrong by 45 degree too. Z (Yaw) is always wrong at such a mounting type)
If it's the Y (Roll) , make the Change by add or take 450 to/from your X (Pitch) .
And If it's the X (Pitch) Do this at your Y (Roll) instead .

After that, i think this can be added to the MAG WIKI, what do you say @DzikuVx ?
This is what i talked about, to you in the INAV FB Group.

#5640

[brainbubblersbest]

I figured out why you have Problems here, after i look in your pastebin content:

set align_mag_roll = 0
set align_mag_pitch = 0
set align_mag_yaw = 2500

This is what you set, change:
align_mag_yaw = 0
after that change, you can use the cw270 setting in the configurator again.

[jerryt1]

@brainbubblersbest, thank you for your time digging into this and also for taking the time to provide a comprehensive explanation! I will admit that I’m not quite understanding “the Sensor Tab Mag readings belongs to up and down, not to North and South.” To assess whether or not the compass is correctly reporting the heading direction to the F/C, I have been referring to the heading reported on the Setup tab. I’m hoping I can trust that because we do need some way to determine whether or not the compass is working properly and reporting accurate heading information.

Some good news:
I made the changes you suggested and the compass direction now increases as I turn the drone through the headings from N to E to S to W, etc., as it should. Two of my drones had the problem I reported since I changed their F/C. Your suggested changes resolved the problem with one of them. The other at least now increments properly, but there are varying errors depending on the heading. However, this could be due to where I have mounted the compass and I’m considering re-3D printing a new mount to move it elsewhere, perhaps beyond the rear of the craft cantilevered slightly out the back. It is currently over the rear portion of the frame which is empty underneath. The battery cable does run out the bottom of the frame in that section to the battery mounted underneath. But the compass is 4.5cm above that cable, which I thought would be enough; perhaps it isn’t. When facing magnetic North with this second drone, INAV’s Setup tab displays the direction as 23 degrees rather than 0 degrees as it should.

I have several related questions:

1. Large ships have historically had large magnetic compasses on gimbals in a platform called a binnacle. The binnacle has metal correcting spheres or correcting magnets to compensate for errors caused by being close to the metal hull of the ship. Are there any similar correction settings in the GUI or via the CLI in INAV that allow us to compensate or correct for a compass that is near metal in a drone, such as being close to a DJI Air Unit or a metal standoff? (Obviously, I know there is no way to correct for large fluctuating currents in nearby battery or motor wiring - better separation is the only fix.)

2. What do the X, Y, and Z compass calibration data displayed on the Calibration tab mean? Can we/should we attempt to make any adjustments there to make corrections about what I asked in question 1?

3. For PosHold and RTH to work properly, how accurately does a compass reading have to be to not allow the drone to toiletbowl? Is within 20 degrees of accuracy enough? 10? 5?

Finally, because you provided additional suggestions that have resolved the primary problem, do you still want the “get mag” dump? I’m happy to provide it or any other information that is useful to you.

And thank you again for all your help!

[brainbubblersbest]

Magnetometer should have the same readings but in negative to the Accelerometer.
If ACC Z = 1 then your Z on Magnet should have a specific Value in -Z

Check Correct alignment in Sensor Tab,
Thats the only way to See why in setup tab it makes strange movement.
AccZ+1.0 = MagZ-40
AccZ-1.0 = MagZ+40
AccX+1.0 = MagX-40
AccX-1.0 = MagX+40
AccY+1.0 = MagY-40
AccY-1.0 = MagY+40

The Calibration leads to that 40~ Values, without Calibration These can be quite more different in Heights.
A few Percents difference are normal
(around 5%difference?)
And the Value is not to be 40 by any Build. Can also be 30 or 50. This is related to the used Magnetometer. The Earth Magnetic on your location etc.

And Yes, DC Cables are the biggest Problem here.
Print a mount that hold your Puck a few cm away in the back. You can also tilt it. Then you need to set this tilt with the roll Axis. Because your mag is mounted by an 270degree Angle around the Z Axis. (2700) Your x and y is changed to another.
No i dont need your get mag after i See you already posted your cli out. ;D

And NO, there is no setting you mentioned in 2 to solve the thing in question 1.
For 3 this is Hard to Tell. I think there is a setting in inav like how much this can be tolerante before the fc make correction. Im not shure just in the Moment. This is at a place in inav configurator Navigation values.

Cables with much dc current are much much more a Problem then any metal plates or Carbon.

[jerryt1]

Interestingly, I resolved the remaining problem with the "varying errors depending on the heading" in an unexpected way: I replaced the GPS/compass module with a new one, and now everything works properly. I did not suspect the original module because it worked fine up until I made the F/C change.

So, this means the issue @brainbubblersbest found with align_mag_yaw was the problem for both. While I cannot remember explicitly making the wrong setting, I can think of no other way it could have occurred. Setting align_mag_yaw=0 and then using CW270 has resolved the problem for both craft. Both were preceded by a change to a different Matek F/C and I suspect the align_mag_yaw setting worked well with the prior F/C. After changing the F/Cs, I loaded the correct firmware for the new F/C and then loaded the diff file to incorporate the settings I'd used before. Obviously, starting from scratch would have been a better approach.

From a user standpoint, a nice feature to consider is a way to be able to separately save and re-use a subset of the settings that likely won't be affected by most INAV improvements. For example, when upgrading to V2.50, we should not load prior "diff all" files because PIDs, Rates, and Filters should start with the new defaults and then the user should make adjustments from there to fine tune performance. But it'd be great to not have to reload every other setting that will rarely be affected by updates and upgrades. Such settings would likely include Modes, OSD configurations, Beeper enabled/disabled settings, Failsafe settings, Ports, etc. My thanks to everyone who offered assistance with this problem. Unless there is other feedback or requests for me to further test something, I will close this issue within the next week.