uNav AHRS

Status
Not open for further replies.
First, thanks for writing the library class, great job. I found my Nan issue (it was essentially an unformatted EEPROM entry). I basically used a Teensy 3.2 to run your class library and sent the results over a USB connection to a Windows WPF program. The program had a 3D object whose movements emualate the movements of the MPU. The Windows program displays the bias and scaling obtained by using your library so the user can see the units. I have also tried to build a graphical way for the user to calibrate the MPU using your class library as well.

So everything seems to work functionally, but I am seeing some calibrations issues as the object starts off well but then starts to drift in time. The calibrateMag function is self explaining, but I do have some questions on the calibrateAccel function.

You explain: This function works one axis at a time and needs to be run for all 6 sensor orientations. After it has collected enough sensor data, it will estimate the bias and scale factor for all three accelerometer channels and apply these corrections to the measured data.

So I’ll assume we do the X+,X-, Y+, Y-, Z+ and then Z- orientations, which is how I set it up. I guess the question arises from my very limited AHRS experience is: do we physically orient the MPU’s embossed XYZ vector arrows for each reading to magnetic North? For instance, I am using the Imverness MPU9250. I know the vectors of the unit are marked as such on the board and the +Z vector in this pic is coming at you.

Inverness.png

Now I know this seems trivial and silly, but I just cannot seem to wrap my head on the physical orientation of the unit for accelerometer calibration.

So given the magnetic north as shown in the pic below, would aligning the MPU in this manner constitute X+ for calibration?

X+.png

X-?

X-.png

Y+?
Y+.png

Y-?
Y-.png

Z+?
Z+.png

Z-?
Z-.png

Sorry for such a silly question, but the physical alignment of the unit for calibration is the last thing I need to get my project going.
 
For the accelerometer calibration, you'll need to align each axis (+/-X, Y, Z) with gravity, not magnetic north.
 
Ok , so assuming a physically level table where the MPU resides on, and the MPU vector markings as below:

axis.png

If +X and -X are the extremes to measure, then should the the X vector be perpendicular to the table up, and then perpendicular to the table down?
 
Hi Guys,
Took a break from UAVcan and went back to working on trying to find a way to get a Kalman Filter working on my MPU9250. I found another implementation (http://lyfkyle.blogspot.com/search/label/Custom Flight Controller) that implements in matlab and on a STM32, so I ported it over to the Teensy 3.5 with the MPU-9250 I have. Got some results - a lot noisier but seems to work a little different than other implementations so far. If you are interested in trying it out here it is:

Forgot the attachment:
View attachment YAKF-KW.zip

Read the blog has some good info on it. Have to try and get the papers he references.

As for using the NXP SensorFusion - put that approach on the side for now. Pitch/Roll very stable but yaw still a problem as before.

Regards
Mike
 
I made one more change to the Filter setup. I added back in the Brian's calibration for sensor and made the necessary modifications to the filter. While still noisy seems to work a lot better than with the previous versions. So here is the second version with the MPU-9250 Calibration being used. Note, the reason why I added the 9250 into the sketch is that I changed the transform matrix in the .h file so the axis transform is in the sketch itself. Also, I add in a function to just get the raw sensor counts.
 

Attachments

  • YetAnotherKalman.zip
    16.8 KB · Views: 154
A debt of gratitude is in order for the reference material. Indeed the library is working fine, the issue is simply with specific breakout board I have, no INT accessible. I picked this one since it had a weight sensor on the breakout board. Should try the 15 state EKF out when you make it go. Assembling a test stage (moded rc-auto) to try out a RTK arrangement. Ending up with three diverse comm ways - I know I am insane. I tried the associations in a static design and it appears to work. I am utilizing the NeoGPS lib to translate the NMEA strings I am utilizing. Chipping away at some waypoint code - the code utilizes a waypoint flyby approach. Sadly winter has sent here so outside time will be constrained.
Much obliged From GBWhatsapp themes
 
Hi Mike, Sorry I've been offline for the last couple months. Been consumed with delivering RTK units for a small fleet of drones. Your YAKF sounds interesting, I'll take a look!

You and Brian were talking about heading issues with the MPU9250 magnetometers. I'm experimenting getting heading with dual RTK receivers/antennas, and it seems to be working very well, seems very accurate. Of course you need really good visibility to get robust RTK lock, but neat anyway. I haven't integrated it in yet with any filters, but that might be a next step. Running the RTK code on the LattePanda, but could pull results into a Teensy easily.

I was experimenting around with the INS/AHRS library yesterday that you put together some months ago. Had an application where someone needed to measure tilt very precisely, but the MPU9250 can't get the accuracy they needed. I seem to be seeing on the order of about 0.1 degree accuracy, and they wanted several orders of magnitude better, so is no-go.

I need to catch up on all the stuff you guys have been doing the last couple months...
 
Hi Don

Welcome back. uNAVAhrs has been pretty quiet. Think everyone's been working other projects. I've been playing around with it on and off trying different things to get it working with the 9250 but never could get the heading stable. In Brian's MPU9250 post we were talking about the BMI160 and the BMM150 mag as a replacement for the 9250 when it goes out of production. I go some good results with that combination using Brian's code. Most of what I did is on my repository if your interested: https://github.com/mjs513/Modified-BMI160---BMM150-Arduino-Libraries.

Was also working on a port of UAVCan to the Teensy which I managed to get working. But that version is getting ready to change to v1.0 - they are pretty much redesigning it. They are planning on using CAN-FD as well as an option for just CAN. tonton81 has a really neat library for CAN called CANquitto, that he posted on the forum. You now can control another Teensy over CAN. Should be great for the T4. Use the T4 for the master and then control t3.x's. Also got CAN-FD working with the T3.x's using SPI and a MCP1517FD breakout board that is posted as well. More to follow on that one.

Brian's been busy with some new Teensy's boards as you can see.

Regards
Mike
 
Yeah, the MK66FX1M0 breakout and some stackable add-on boards for the Teensy 3.2 footprint. Plus a flight code update.

I'll be coming back around to this after the flight code update. Initially we're using the 15 state EKF in flight tests, and it's working fine, but I would like to have other options for if people are configuring aircraft without GPS or flying in GPS denied environments.
 
Hi Brian
Have gone back to your updated uNAVAHRS code (no GPS) to play around with that version. I did incorporate a temperature compensation curve for the accelerometer and that seemed to help the yaw drift a bit. As for gyro correction working on something else. I did find this on the nxp web site for their sensor fusion algorithm and it probably pertains to all Kalman filters:
Our Kalman filters are based on equations of motion and work best when the board is moving. If your board is stationary on a table top, then the gravity vector is expressed entirely in the Z-axis and there is no information in X&Y to help compute Z-axis offset. Yaw drift is eventually always going to occur in that case. Pick the board up, rotate it in free space a few seconds and put it back down, you'll see the yaw drift rate cut dramtically. Eventually it will creep back up.
Here's the link if you are interested https://community.nxp.com/thread/389634.
 
Back again even though this thread seems kind of dormant.

Any way been playing around with the different Kalman filters and MPU-9250 drivers. Using the uNAVAHRS (GitHub) I hooked up a couple of different sensor breakout boards with the latest being the Embedded Masters board. Using your mpu-9250 library (I added in a couple addition functions for my use and testing like a fast gyro calibration) they all seem to exhibit the same thing with the gyro in the z direction. Namely if I rotate the board (fast or slow it doesn't matter) gz never seems to return to near the bias value and drifting starts right up:
Capture.jpg.

Now as a test I used Kris Winer's MPU-9250 code and if I rotate the board the gyros come back to their bias values at least to the point where I don't get any indication with my zero motion detection function (ZM in the image). But I still get a lot of drifting in yaw.

Mike
 
I just reran the above scenario with my modified lib and to my surprise didn't see the issue described above even though in a day of running tests I saw that occur multiple times using the MPU-9250 library. Wil do more trial tomorrow.
 
Just a quick updated if you are interested. As you might have guessed my frustration with Kalman filters and the MPU-9250 is beginning to get the better of me. I decided to do a quick test by using a hmc5883L that I still had laying around and yaw drift seem to be dramatically reduced or steady - just a quick and dirty test. Not sure what to make of this so going to do more testing on and off.

In terms of magnetometers I came across this thread a from a couple of years ago for a replacement for the HMC5983 that you all might be interested in: https://groups.google.com/forum/#!topic/drones-discuss/XhTl5hmko04.

Regards
Mike
 
Hi Mike,

Thanks, yeah I saw that several weeks ago when we were talking about MPU-9250 alternatives.

I think the yaw drift may be due to a few things:
1. High magnetometer noise on the MPU-9250
2. Low dynamics (when checking for yaw drift), which AHRS are not well suited for
3. Temperature effect on gyro

I'll be writing up some tutorials for the Teensy Motion Backpack in a week or two, so I'll probably be revisiting the AHRS and INS algorithms then. To clear up some of the drift, it may be changing the covariance of the magnetometer and having temperature compensation for the gyro.

I also just noticed that Digikey has some of the Bosch Sensors in stock (finally!), so I may purchase some of those to start evaluating.
 
Hi Brian

Thanks for the added info. I tried a couple of things that I did not mention with the 9250. The first was to implement a Temp Correction Curve (TC) on the accelerometer but that didn't have much affect. I did try to re-zero the gyro's periodically when no motion was detected - that helped a bit but too many other factors were involved to get it work right. But that did seem to help.

A couple of things I did not try was using a Butterworth filter on the magnetometer which I use in one of other programs using magnetometers. And the other thing was a gyro TC routine. I do have the equations. But just a note that the TC is probably dependent on the configuration selected for the gyro. So I was trying other things first. :) Tested the hmc5883L just for sanity sake.

o clear up some of the drift, it may be changing the covariance of the magnetometer and having temperature compensation for the gyro.
Yeah, that sounds good.

Mike
 
Hi Brian

Went back to my FreeIMU library to see what I did for the MPU-9250 and saw that I added a butterworth filter on the magnetometer. If you want to laugh this is the note that I had for the adding the filter for the MPU-9250:
//Set up Butterworth Filter for 9150/9250 mag - more noisy than HMC5883L
//was butter50hz2_0, new values base on Mario Cannistrà suggestion
//he also used same filter on the gryo's which I am not using rigth now
butter100hz2_0 mfilter_mx;
butter100hz2_0 mfilter_my;
butter100hz2_0 mfilter_mz;
This was from a few years back.

Anyway when I added the filter to my modified library yaw drift was significantly reduced no more wild excursion. The first run it was rock solid about +/- 0.5 degrees. The second run saw about 5deg of drift over an hour. Here is a screen shot at the beginning of the test and at the end:
Initial.jpg
9250BWF60mins.jpg
the variation in yaw and pitch you see is from me leaning on the desk where I have the mpu9250. Think I will play around with the gyro next

Mike

EDIT: I added the same type of filter on the gyro, just out of curiosity and which helped a little bit. The one thing I did different was that after drifting started I moved the senor around a little bit and put it back in approximately the same position and the drifting stopped again for a while. This effect might be related back to the nxp comment I quoted in an earlier post.
 
Last edited:
Hello,
I'm building a small portable instruments which periodically samples and saves heading (compass) and tilt values, for situations where GPS signal is not available.
It's an instrument for walking pedestrians: no UAV/vehicles etc.

Having reading somewhere that Bosch BNO055 is a good sensor, I purchased a couple of Adafruit breakouts to test it out with a Teensy 3.2.
Adafruit has a library for it; it puts the sensor in NDoF mode (fusion) and has calibration API calls to verify calibraton status (BNO055 has 4 calibration indicators: system, gyro, accelerometer, magnetometer).

Problem: using their unmodified example, even after calibration (distant from magnetic fields, metals etc.) compass readings (heading) are all over the place, not reliable at all.
Like: put the sensor on a flat surface, read say 210.0. Turn the sensor around, reposition it exactly as before, read 159.2. Repeat, read 240.0 :(

At first I thought I had a faulty breakout board, but I purchased two of them, and both exhibit the same behaviour.

Same goes for a non-Adafruit (CMPS12 by Robotech UK) breakout based upon the same BNO055 sensor, with (very simple) library written by me from scratch.

Could this uNav AHRS library improve things? Does it support BNO055 (or is it reasonably easy for me to add support)?

I just need heading and tilt for a walking human, nothing really fancy; yet I'm in the dark. :(

Thank you very much.

Fernando
 
Last edited:
Hello,
I'm building a small portable instruments which periodically samples and saves heading (compass) and tilt values, for situations where GPS signal is not available.
It's an instrument for walking pedestrians: no UAV/vehicles etc.

Having reading somewhere that Bosch BNO055 is a good sensor, I purchased a couple of Adafruit breakouts to test it out with a Teensy 3.2.
Adafruit has a library for it; it puts the sensor in NDoF mode (fusion) and has calibration API calls to verify calibraton status (BNO055 has 4 calibration indicators: system, gyro, accelerometer, magnetometer).

Problem: using their unmodified example, even after calibration (distant from magnetic fields, metals etc.) compass readings (heading) are all over the place, not reliable at all.
Like: put the sensor on a flat surface, read say 210.0. Turn the sensor around, reposition it exactly as before, read 159.2. Repeat, read 240.0 :(

At first I thought I had a faulty breakout board, but I purchased two of them, and both exhibit the same behaviour.

Same goes for a non-Adafruit (CMPS12 by Robotech UK) breakout based upon the same BNO055 sensor, with (very simple) library written by me from scratch.

Could this uNav AHRS library improve things? Does it support BNO055 (or is it reasonably easy for me to add support)?

I just need heading and tilt for a walking human, nothing really fancy; yet I'm in the dark. :(

Thank you very much.

Fernando

Honestly, for heading and tilt in walking conditions the AHRS might not be appropriate - I'm not sure you would see enough dynamic motion in that context. I would consider implementing a tilt-compass, which is what cell-phones use for this sort of thing. You can find some example code here:
https://forum.pjrc.com/threads/53695-Teensy-Backpacks?p=193234&viewfull=1#post193234

Should be easy to modify for your IMU's. Ditto for the AHRS, it's written to work with any IMU and magnetometer source, just be careful with the axis convention.
 
Status
Not open for further replies.
Back
Top