Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix support for AK8975 MAG #3413

Merged
merged 3 commits into from Jun 24, 2018

Conversation

Projects
None yet
3 participants
@fiam
Copy link
Member

commented Jun 21, 2018

Supersedes #3324
Fixes #3288

@fiam fiam added this to the 2.0 milestone Jun 21, 2018

@fiam fiam referenced this pull request Jun 21, 2018

Closed

Ak8975 fix #3324

@fiam

This comment has been minimized.

Copy link
Member Author

commented Jun 22, 2018

Can someone with this mag give this PR a try?

@rb1205

This comment has been minimized.

Copy link
Contributor

commented Jun 23, 2018

Tried it on my SP3EVO. Still the same problems reported by gbine in #3288:

  • When you pitch/roll the board while keeping constant jaw angle, the reported heading changes. This doesn't happen in 1.8.
  • DEFAULT mag orientation isn't correct, while on 1.8 it is

Additionally with this PR, I can't seem to set align_mag. Everything I set is just reverted to DEFAULT on reboot after save.~~

@rb1205

This comment has been minimized.

Copy link
Contributor

commented Jun 23, 2018

Disregard the first point of what I wrote above, I did a new calibration instead of reusing 1.8 values and it's working fine! Great job 👍

Also disregard the issue with align_mag not being saved: it's correctly saved when set through CLI but not when set through GUI configurator. Most probably not an issue with your PR.

@rb1205

This comment has been minimized.

Copy link
Contributor

commented Jun 23, 2018

Hm, I might have talked too soon: every align_mag i tried other than CW270FLIP (which is the default on SP3EVO) makes the jaw attitude act erratically.

With the default orientation, heading is 180° off (reports 180° when headed N, W when headed E and so on). Therefore, I set CW90FLIP. That way the heading when the board is level are is correct, but it starts rotating around when rotated on the jaw or pitch angle.

@tootomthumb

This comment has been minimized.

Copy link

commented Jun 23, 2018

@rb1205 how do I try this fix? I have the AK8975 but TBH it has never worked perfectly. In version 1.8 I could get the XYZ on Accelerometer to move/change in sync with Magnetometer but only when the Mag reading was 180 degrees out. Changing the flips etc to give me a correct reading broke the XYZ correlations and then it starts to drift wildly when you roll or pitch.

So I was hoping version 1.9 would allow me to fix that with the new XYZ magnetometer offset controls. Of course, I cannot try it out until I get the AK8975 working and so I'm back to the start... How can I try this AK8975 fix?

I should probably add that I'm using the Matek F405 target.

@tootomthumb

This comment has been minimized.

Copy link

commented Jun 24, 2018

Using the instructions from this link https://github.com/iNavFlight/inav/blob/65dd94dd9ee19e13b0c2ef1d9316b68a11c078bf/docs/development/Building%20in%20Windows.md I think I have compiled a .hex file, using the edited "common_hardware.c" file which I then uploaded to my Matek but it seems to be the same issue, the AK8975 isnt recognised.

Is there any way to confirm my compiled file is using the new "common_hardware.c" file? For instance, I compared the old .hex file with the new one and they are both exactly 687,386 bytes in size. I expected them to be slightly different or is that an incorrect assumption?

Or are there other files I need to change?

Enable MAG_AK8963 and MAG_AK8975 for targets that had drivers
Only added the defines for targets which already included
compass_ak8963.c and compass_ak8975.c
@fiam

This comment has been minimized.

Copy link
Member Author

commented Jun 24, 2018

@tootomthumb Please, try again with the new commit I've added on top.

@fiam

This comment has been minimized.

Copy link
Member Author

commented Jun 24, 2018

@rb1205 Your issue seems unrelated to this commit. There's probably in incorrect axis inversion in the driver. In the meantime, you can set the compass alignment to 0º and use align_mag_roll, align_mag_pitch and align_mag_yaw settings to rotate it arbitrarily.

@tootomthumb

This comment has been minimized.

Copy link

commented Jun 24, 2018

@fiam can I confirm that I need to use a command like "git clone -b agh_fix_ak8975 --single-branch https://github.com/iNavFlight/inav.git" to draw down the appropriate files so when I then use "make TARGET=MATEKF405" I create a .hex of the correct branch?

@fiam

This comment has been minimized.

Copy link
Member Author

commented Jun 24, 2018

@tootomthumb I think that should work, but better test with the file attached to this comment.

inav_2.0.0_MATEKF405_TEST_3413.hex.zip

@tootomthumb

This comment has been minimized.

Copy link

commented Jun 24, 2018

@fiam That has certainly got me much further!

Flashing your hex file (which out of interest was a different size to the one I created using the branch clone) has got the AK8975 visible again. It's still 180 degrees about face but that's roughly where I was with version 1.8.

One thing to note is that there seems to be a lot more mag Jitter, the compass seems to move +/- 3-4 degrees constantly and rapidly but doesn't drift. Is there some sort of Noise filter which was included or not set in this version?

In regards to the 180 degree orientation problem. Gyro and Mag have the same cardinal points (XYZ react the same way to movement) so I think my AlignMag/AlignGyro/AlignAccel settings are correct. I can see that I have magzero_x/y/z which are now set at 56, -118 and -390 respectively.

Given those values I assume I cannot just add 180 to 56 (ie set mazero_x=236) to get the orientation to move 180 degrees around. In fact when I do that it only adds around 20 degrees to my orientation. Far short of the requirement.... Sorry if this is far out of spec for this trail, but do you have any idea of what I should do?

Thanks @fiam for getting me this far!

@fiam

This comment has been minimized.

Copy link
Member Author

commented Jun 24, 2018

@tootomthumb Thank you so much for the testing. So now that the FC sees the AK8975, we can merge this PR. I'll now start debugging the issues with the default alignment.

@fiam

This comment has been minimized.

Copy link
Member Author

commented Jun 24, 2018

@tootomthumb @rb1205 We'll continue on #3434, merging this one.

@fiam fiam merged commit 3aa16e1 into development Jun 24, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@fiam fiam deleted the agh_fix_ak8975 branch Jun 24, 2018

@tootomthumb

This comment has been minimized.

Copy link

commented Jun 24, 2018

@fiam I realise you probably knew this wouldn't work, but just in case you didn't, I wanted to add that I tried to use the align_mag_yaw command by setting it =180 hoping it would push my orientation from 180 to 360/0. Instead it went to approximately 80 and has messed up all the alignment with Accelerometer to Mag so the X/Y/Z no longer react in sync. Similarly setting it to -180 also doesnt work.

@fiam

This comment has been minimized.

Copy link
Member Author

commented Jun 25, 2018

@tootomthumb There were 2 problems:

  • The AK8975 wasn't properly detected by INAV
  • AK8963, AK8975 and MPU9250 have incorrect default orientations

This PR was only fixing the first of those 2 problems. I've opened #3434 to track the second one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.