LSM9DS1 vs. MPU-9250 vs. BMX055

[maziarzamani]

Hi.

I was wondering if you had made any comparison on these 3 chips, especially in terms of the magnetometer, which has been a big problem for me on the Invensense in terms of error.

[kriswiner]

I am in the process of doing just that between the MAX2110X (no magnetometer), MPU9250, LSM9DS0, and BMX055. I will eventually get around to testing the LSM9DS1 and AK9912, et al. but I am starting detailed comparison testing with the four integrated motion sensors listed above.

I don't know what kind of error you are getting but my experience with the AK8963A embedded in the MPU9250 is that with proper bias calibration the data are pretty good. I have also had no problem with the LSM9DSX magnetometers nor the BMX055 but the latter is an odd duck in that the data are magnetic sense data plus a Hall resistance and the magnetic field has to be constructed out of these in software. Still, the resulting data seem OK. All qualitative. I will do quantitative comparisons in the next few weeks of accel, gyro, and mag as well as testing the different data inputs on the resulting open source sensor fusion quaternions, etc.

Right now I can tell you the MPU6500 (accel/gyro in the MPU9250) accelerometer has much lower jitter than the BMX055 accelerometer. I can't say much about the magnetometer relative performance yet but I would ask if your problem with the MPU9250 mag is that you have neglected the bias calibration; this will produce very bad results in any fusion solution.

[maziarzamani]

Sounds very exciting. I am not saying that the data is utter garbage, as i do calibrate the compass. But i tend to experience that it is not acting so stable and easily generate messy data in different environments. It could just be a downside of the MEMS technology with magnetometers.

I am trying to find a few reasons to replace the MPU-9250 with a LMS9DS1. I will be using a few hundred of them and looking at the price tag as a initial comparison we are talking 637$ (MPU-9250) vs. 471$ at 100 pieces. It is a quite significant price difference if they are quite equal in terms of performance.

[kriswiner]

Well, this is a different issue. You can buy (I have) MPU9250s on www.aliexpress.com for ~$5 with free shipping and no sales tax (in US); I would highly recommend "New Hope" as I have bought several things from them many times and the service and quality are very good. The MPU9250 has the advantage in smaller footprint, much simpler design (2 die instead of the four or so in the LSM9DS1) and wider full scale ranges (+/- 16 g). I like ST products generally but in this case, there is no advantage to using the LSM9DS1 over the MPU9250 in my view. The LSM9DS0 might be a competitor for the MPU9250 and I would consider it if I were you. It is larger, a little more difficult to solder mount, but produces very good data. I'll have more quantitative results on this point in a few weeks but the prices are about the same.

[maziarzamani]

I bought the initial demo boards from aliexpress, but unfortunately i will need to buy them on tray for the next batches i will be making. I have already soldered quite a few of the MPU-9250 and they are literally a pain in the ass to paste in hand (even with a stencil) and solder in a oven without having to do a lot of post-soldering due to solderball formation under the IC, especially due to the thermal pad in the middle of the IC which causes an unwanted spacing. Besides that the chip is ok, but rumors spread that LSM9DS0 is a good replacement. In which aspects would you say that the LSM9DS0 is superior?

[kriswiner]

First of all, the breakout boards offered from www.aliexpress are complete crap, I would never use them especially if they are purple. It is the MPU9250 QFN chips that are the bargain and well worth buying from "New Hope" seller.

I hope you are not soldering the thermal pad. It must remain unconnected electronically. I don't use a metallized pad underneath the QFN package in my designs and neither does Invensense. This is asking for trouble.

I said the LSM9DS0 might be comparable in performance; I haven't finished my quantitative testing yet. But it is bigger, a bit harder to use, and used to be more expensive but I think the price dropped recently so that now they are about the same price. I will just tell you that in our commercial projects we are using the MPU9250 and might switch to the MAX21105 but haven't decided. We are not considering the LSM9DSX currently.

Sounds like your stencil or the application of solder process if faulty if you are having trouble here. I have soldered hundreds of these with little trouble except the occasional solder bridge between pins.

Maybe your landp pad design is the problem?

[maziarzamani]

I will check out the seller on AliExpress!

I see what you mean with the thermal pad, i have just notified my HW guy, which has clearly made an huge mistake, thanks for the tip!

MAX21105 seems interesting. Which magnetometer will you pair it with?

[kriswiner]

I plan to test both the AK8963A which I already know fairly well and the newer AK9912. BTW, I like the LIS3MDL mag from ST (I currently pair the MAX21100 with it in my breakout boards for sale at Tindie) so I will be testing this in some detail also. Lot's to do, and so little time!

[maziarzamani]

I am looking forward to see your results! :+1:

[jheissjr]

Kris, how is testing? Are you looking at the AK8963A, AK9912, LIS3MDL?

[kriswiner]

Currently I am testing the AK8963C, LIS3MDL and HMC5883L. I am going to add the HMC5983 since it is the newer Honeywell offering. I also have some samples of the AK9912 I want to test, just haven't gotten there yet.

So far I am impressed with the Honeywell mag but it only has 12-bits compared to the 16-bits of the others so its apparent stability might just be due to the lower resolution. The LSM9DS1 has the LIS3MDL embedded in it and I am testing this 9 DoF solution also. Still have a lot of work to do before I can come to any conclusions but I am working on it.

One thing I already know is that I don't like the Bosch magnetometer.

Kris

-----Original Message----- From: jheissjr [mailto:notifications@github.com] Sent: October 4, 2015 4:21 PM To: kriswiner/MPU-6050 Cc: Kris Winer Subject: Re: [MPU-6050] LSM9DS1 vs. MPU-9250 vs. BMX055 (#6)

Kris, how is testing? Are you looking at the AK8963A, AK9912, LIS3MDL?

Reply to this email directly or view it on GitHub https://github.com/kriswiner/MPU-6050/issues/6#issuecomment-145400698 . https://github.com/notifications/beacon/AGY1qm_jNtUJYMx4W3VrhmEdW8ErwQg7ks5 o4au_gaJpZM4EbfGw.gif

[jheissjr]

What have you seen with the Bosh magnetometer?

[kriswiner]

You can read about the detailed results on the MPU9250 Wiki at my github site, but bottom line, it is not very easy to calibrate it.

-----Original Message----- From: jheissjr [mailto:notifications@github.com] Sent: October 4, 2015 8:32 PM To: kriswiner/MPU-6050 Cc: Kris Winer Subject: Re: [MPU-6050] LSM9DS1 vs. MPU-9250 vs. BMX055 (#6)

What have you seen with the Bosh magnetometer?

Reply to this email directly or view it on GitHub https://github.com/kriswiner/MPU-6050/issues/6#issuecomment-145420488 . https://github.com/notifications/beacon/AGY1qvsJB3IaWD7stvTPoXOiJXzTOSRFks5 o4eaigaJpZM4EbfGw.gif

[maziarzamani]

Did you ever have the chance to try out the AK9912?

[kriswiner]

Still on my list of things to do, but I did get some samples.

[jheissjr]

I've been reading that Helmholtz coils are used for calibrating magnetometers. Do you have access to a Helmholtz coil for your testing by chance? I wish I did lol. I was also thinking it would be good to wrap the magnetometer in magnetic shielding (like MuMetal) to provide a quiet environment for taking noise measurements

[kriswiner]

I don't have Helmholtz coils or Mu-metal but I don't think they are necessary for the kind of testing relevant for characterizing the quality of sensor fusion solutions, which is my interest. I have been using Honeywell's HMC5883 mag lately and I find it is pretty stable compared to the AK and ST mags. This is partly due to the fact that Honeywell's mags (the newest HMC5983 too) use a 12-bit ADC instead of a 16-bit one, but their construction is unique and I am beginning to think superior to standard MEMS Hall sensors. I need to do more testing, but I am hopeful the HMC5983 will provide the kind of sensor fusion solution capable of +/- 2 degree heading accuracy.

-----Original Message----- From: jheissjr [mailto:notifications@github.com] Sent: October 10, 2015 7:38 PM To: kriswiner/MPU-6050 Cc: Kris Winer Subject: Re: [MPU-6050] LSM9DS1 vs. MPU-9250 vs. BMX055 (#6)

I've been reading that Helmholtz coils are used for calibrating magnetometers. Do you have access to a Helmholtz coil for your testing by chance? I wish I did lol. I was also thinking it would be good to wrap the magnetometer in magnetic shielding (like MuMetal) for taking noise measurements to provide a quite environment.

Reply to this email directly or view it on GitHub https://github.com/kriswiner/MPU-6050/issues/6#issuecomment-147147435 . https://github.com/notifications/beacon/AGY1qpA9RPy3cU6M7oUtSqCrWVyCjrftks5 o6cMegaJpZM4EbfGw.gif

[sarwadenj]

@kriswiner,@maziarzamani have you obtained quantitative results for the MPU9250 and LSM9DS1? If so please link me to them. Regarding the MPU9250, why do you think it is not very easy to calibrate? Which one of these will you recommend for use in Miniature Aerial Vehicles? Thank you.

[kriswiner]

The MPU9250 is straightforward to calibrate, and it is what I use for my small flying robots.

On Mon, Jan 23, 2017 at 5:29 AM, Narasing Sarwade notifications@github.com wrote:

@kriswiner https://github.com/kriswiner,@maziarzamani https://github.com/maziarzamani have you obtained quantitative results for the MPU9250 and LSM9DS1? If so please link me to them. Regarding the MPU9250, why do you think it is not very easy to calibrate? Which one of these will you recommend for use in Miniature Aerial Vehicles? Thank you.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU-6050/issues/6#issuecomment-274487879, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qnco4v3S3sfeT-ReshG86AMNRE9Aks5rVKtAgaJpZM4EbfGw .

[cavetronic]

Hi Kris, How about Your test? Is it worth (in the meaning of data quality - jiggling, acccuracy and sensivity) to replace LSM9DS0 with MPU9250? Or there is any other alternative which gives the good readings? Bests! Adam

[kriswiner]

https://github.com/kriswiner/MPU-6050/wiki/9-DoF-Motion-Sensor-Bakeoff

MPU9250 is the right choice.

On Wed, Mar 8, 2017 at 1:02 AM, cavetronic notifications@github.com wrote:

Hi Kris, How about Your test? Is it worth (in the meaning of data quality - jiggling, acccuracy and sensivity) to replace LSM9DS0 with MPU9250? Or there is any other alternative which gives the good readings? Bests! Adam

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU-6050/issues/6#issuecomment-284985480, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qvZZcC-2A_36f-y-pysnt0r-204dks5rjm6JgaJpZM4EbfGw .

[cavetronic]

Thank You so much!

[mik00]

Hi Kris,

Your Bakeoff is a great bit of work Kris. Practical, to the point, and just the right amount of detail. Exactly what I wanted to know. Thanks.

Well, perhaps there is one other thing I'd like to know...

I'm currently using the MPU9250 for my eldercare activity sensor. I need to do some rather specialised signal processing for my app, which at present has to be done on my host - an M4. I notice that it is claimed that one can write custom signal processing code to embed in the BMX which is an M0 I think.

Do you have any comment or experience on the feasibility/ease/benefits of that please?

Anyone else out there have an opinion.?

[kriswiner]

You are thinking of the BMF055, which has an M0 and can be programmed somehow. The BNO055 also has an M0 but is closed to the user. I have never successfully used the BMF055. But my opinion is the Bosch suite of sensors on the BNO055/BMF055 is subpar, and I would stick with the MPU9250 if I were you. We use the EM7180 as a motion co-processor with the MPU9250 and since we can write drivers for it we have added some specialized application code (like pressure/accelerometer fusion for better altitude estimation for flying robots for example). But the RAM is severely limited and is really not appropriate for extensive applications code.

On Thu, May 18, 2017 at 8:09 PM, mik00 notifications@github.com wrote:

Hi Kris,

Your Bakeoff is a great bit of work Kris. Practical, to the point, and just the right amount of detail. Exactly what I wanted to know. Thanks.

Well, perhaps there is one other thing I'd like to know...

I'm currently using the MPU9250 for my eldercare activity sensor. I need to do some rather specialised signal processing for my app, which at present has to be done on my host - an M4. I notice that it is claimed that one can write custom signal processing code to embed in the BMX which is an M0 I think.

Do you have any comment or experience on the feasibility/ease/benefits of that please?

Anyone else out there have an opinion.?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU6050/issues/6#issuecomment-302597322, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qgR2YsD-2dtTagG3YvJTMSEUGDCHks5r7Qf2gaJpZM4EbfGw .

[mik00]

Thanks so much for the swift response. My head is spinning with all the different Bosch variants.
Are you connected with Pesky at all? I'd like to ask more questions about the EM7180, but I don't want to clog up this thread.

[kriswiner]

Yes, email me at tleracorp@gmail.com for more discussion.

On Thu, May 18, 2017 at 11:54 PM, mik00 notifications@github.com wrote:

Thanks so much for the swift response. My head is spinning with all the different Bosch variants. Are you connected with Pesky at all? I'd like to ask more questions about the EM7180, but I don't want to clog up this thread.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU6050/issues/6#issuecomment-302624496, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qnazjVwTyErqWkop6xMe1M3tIl2mks5r7Ty_gaJpZM4EbfGw .

[saedelman]

@kriswiner - Great information. Can you comment on the quality of the data from the MPU9250 when forward motion of the device is in excess of 10mph? I am currently experimenting with the BNO055 in an aviation application and it is utterly useless with even the slightest forward speed. This is not just drift, all of the values start producing non-sensical and erratic values. Do you have any data to suggest that the MPU9250 would fare better?

[kriswiner]

Yes, we use the EM7180+MPU9250 in small (35 g ) quad copters and the performance is excellent with heading accuracy better than 2 degrees.

The MPU9250 sensors are significanlty beter than those on the BNO055 while the sensor fusion solution is equivalent, but good fusion cannot make up for bad sensor data.

In your case, have you elimanated calibration errors? This is the most common source of poor results. Even the BNO055 should be able to provide stabe absolute orientation estimation with proper calibration albeit with ~7 degree heading accuracy. Part of the problem is with the BNO055 dynamic mag calibration. AKA magnetic anomaly detection/correction. The EM7180 has this too but it seems to work much better on the EM7180 with much less jumping around and more predictable behavior.

On Sun, Jul 16, 2017 at 1:10 PM, saedelman notifications@github.com wrote:

@kriswiner https://github.com/kriswiner - Great information. Can you comment on the quality of the data from the MPU9250 when forward motion of the device is in excess of 10mph? I am currently experimenting with the BNO055 in an aviation application and it is utterly useless with even the slightest forward speed. This is not just drift, all of the values start producing non-sensical and erratic values. Do you have any data to suggest that the MPU9250 would fare better?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU6050/issues/6#issuecomment-315633888, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qvo1OXbx-4WNG_u10z5s1zv-hMUrks5sOm41gaJpZM4EbfGw .

[saedelman]

@kriswiner - Thanks for your comments. The impression I have is that their fusion model is optimized for slow movements only (e.g. applications for VR headsets, etc.). Perhaps, an interesting experiment would be to conduct the tests you previously did for the bakeoff using your 4 different types of MEMS sensors while in a moving vehicle (fixed speed and with acceleration). There is very little data available on how these sensors behave with acceleration/deceleration present.

[kriswiner]

We do real time telemetry on our qaudcopters, which we cannot share, but i can tell you the EM7180+MPU9250 has no problem maintaining accurate absolute orientation at the (relatively small) moving velocities.

On Sun, Jul 16, 2017 at 3:20 PM, saedelman notifications@github.com wrote:

@kriswiner https://github.com/kriswiner - Thanks for your comments. The impression I have is that their fusion model is optimized for slow movements only (e.g. applications for VR headsets, etc.). Perhaps, an interesting experiment would be to conduct the tests you previously did for the bakeoff using your 4 different types of MEMS sensors while in a moving vehicle (fixed speed and with acceleration). There is very little data available on how these sensors behave with acceleration/deceleration present.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU6050/issues/6#issuecomment-315641807, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qnpw-sqdtFYmoPo4RyLx_FfCqghLks5sOoyegaJpZM4EbfGw .

[didasy]

@kriswiner Where do you buy EM7180? I couldn't find it anywhere.

[kriswiner]

If you just need a few I can sell them to you, e-mail me at tleracorp@gmail.com.

On Mon, Jul 31, 2017 at 11:17 PM, Andida Syahendar <notifications@github.com

wrote:

@kriswiner https://github.com/kriswiner Where do you buy EM7180? I couldn't find it anywhere.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU6050/issues/6#issuecomment-319278751, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qjRIdbhFIwDc--OXvlbYa1NbtQ2Bks5sTsMEgaJpZM4EbfGw .

[saedelman]

@kriswiner - I am looking more closely at the MPU9250 as a replacement for the BNO055 in our project. It appears that the MPU9250 provides a fusion solution through its onboard DMP processor. Why do you still use the EM7180 (which is short of impossible to source in NA) with the MPU9250? Isn't the EM7180 redundant in this case? What am I missing?

[kriswiner]

The MPU9250 DMP can only handle 6 DoF fusion (no magnetometer), for the full 9 DoF solution you have to do the fusion processing on the host.

The EM7180 can be ordered from Omnipro for $1.50 each plus shipping. See timlydia@omnipro.net.

If you want to do fusion on the host, I would recommend either the MPU9250 or LSM6DSM+LIS2MDL, the former is capable of 4 degree rms heading accuracy and the latter 3 degree rms heading accuracy using a simple open-source (Madgwick) fusion filter.

The EM7180 + MPU9250 routinely achieves 2 degree rms heading accuray. We are currently testing the EM7180 +LSM6DSM+LIS2MDL solution, which promises to do even better.

On Thu, Oct 12, 2017 at 11:24 AM, saedelman notifications@github.com wrote:

@kriswiner https://github.com/kriswiner - I am looking more closely at the MPU9250 as a replacement for the BNO055 in our project. It appears that the MPU9250 provides a fusion solution through its onboard DMP processor. Why do you still use the EM7180 (which is short of impossible to source in NA) with the MPU9250? Isn't the EM7180 redundant in this case? What am I missing?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU6050/issues/6#issuecomment-336224269, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qqMrRV7hJme5bk8Dww3PzQ8NOGv4ks5srllpgaJpZM4EbfGw .

[IngRaffaeleMineo]

Hi Mr. Winer, I follow you since 1 year ago. Have you new information about EM7180 +LSM6DSM+LIS2MDL? Perhaps I have a question: can the madgwich filter be the best solution if it is implemented at very high rate 20khz (STM32F4 employed at firmware level), or in your study the best limit remains 3° accuracy? Thanks in advance

[kriswiner]

We are working on combining the EM7180 with the ST sensors. For now we are expecting the first ST sensor boards (without EM7180) from initial production in December. So best results are still with the USFS (EM7180+MPU9250), but with the ST sensors using the Madgwick filter you could get 3 degree heading accuracy if well calibrated.

On Tue, Nov 28, 2017 at 10:53 AM, RaffaeleMineo notifications@github.com wrote:

Hi Mr. Winer, I follow you since 1 year ago. Have you new information about EM7180 +LSM6DSM+LIS2MDL? Perhaps I have a question: can the madgwich filter be the best solution if it is implemented at very high rate 20khz (STM32F4 employed at firmware level), or in your study the best limit remains 3° accuracy? Thanks in advance

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU6050/issues/6#issuecomment-347626008, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qvYb62e1_5zdZq9vNoEAW8onSDNkks5s7FacgaJpZM4EbfGw .

[jheissjr]

Which ST sensor/IC will be on the ST sensor board? I'm a little confused about the EM7180, is it an ASIC, micro with custom software?

[kriswiner]

This is what is coming in December:

https://www.tindie.com/products/onehorse/all-st-motion-sensor-breakout-board/?pt=ac_prod_search

I have a couple that I assembled myself but there about 80 coming from the fab.

The EM7180 is a motion co-processor, meaning that is is an ARC processor running at 10 MHz with FPU running firmware specifically designed for efficient sensor management and data fusion.

On Tue, Nov 28, 2017 at 12:20 PM, jheissjr notifications@github.com wrote:

Which ST sensor/IC will be on the ST sensor board? I'm a little confused about the EM7180, is it an ASIC, micro with custom software?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU6050/issues/6#issuecomment-347651207, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qjoklwowCsyeTjlnTRcmOzcNc0O3ks5s7GsOgaJpZM4EbfGw .

[saedelman]

Interesting. Wouldn't having the magnetometer physically offset from the XY axis of the accel/gyro chip introduce an error in the fusion solution? I suppose you could have the accel/gyro on one side of the board and the mag on the other to minimize this, but that does not appear to be the case with the board you referenced on Tindie. I suppose you could compensate for this in the Madgwick solution, but how exactly?

[kriswiner]

Not sure what you mean by offset. The specifics of the arrangement of the sensors is accounted for in the Madwick algorithm simply by feeding the filter function with the data in the correct order. I usually use a NED convention, but ENU or any other consistent protocol will work. This is the case also for the BMX055 and MPU9250. Only the LSM9DS0 seems to have all of the sensors ordered more or less the same. But it's been a while since I looked. In short, different orientation of the axes is a non-issue.

Offset of the physical centers of the devices could be an issue but for the magnetic field, it is not strongly dependent on location as much as orientation so this arrangment is fine. And for the gyro and less so for the accel, avoiding large radius of motion is important for maximum accuracy, this is why I put the accel/gyro at the centroid.

The fact that I have been able to achieve 3 degree rms heading accuracy after calibrationusing this board and the Madgwick filter belies any concern.

On Tue, Nov 28, 2017 at 6:50 PM, saedelman notifications@github.com wrote:

Interesting. Wouldn't having the magnetometer physically offset from the XY axis of the accel/gyro chip introduce an error in the fusion solution? I suppose you could have the accel/gyro on one side of the board and the mag on the other to minimize this, but that does not appear to be the case with the board you referenced on Tindie. I suppose you could compensate for this in the Madgwick solution, but how exactly?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU6050/issues/6#issuecomment-347736364, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qtOHrtjOttBrJ5nUL7laXveaJxLAks5s7MaSgaJpZM4EbfGw .

[carbonadam]

After trying out the bno055 and not getting anything reliable I am going to order one of your sensor fusion boards as I really like that the fusion seems to output something I can use:) At the moment I am working on a swarm robot project that I was planning on using a sensor like this one in each robot(100 in total) but it needs to be fairly robust with the calibration as I dont want to wave a 100 robots in the air everyday in figure 8s...I will go insane. But just for arguments sake how well do you think running the fusion software on a esp32 would work using the MPU9250 in comparison to the sensor fusion module you make?

[IngRaffaeleMineo]

Hi Mr. Winer. How about ST board with EM7180? When do you sell this?

[kriswiner]

The ESP32 is quite capable of achieving the <=4 degree heading accuracy typical of using the Madgwick or Mahony filter with well-calibrated sensors. In order to make use easier you could calibrate each sensor once and store the calibration values on the MCU EEPROM. The sensor calibration will drift with temperature and the ESP32 will heat up with use; it is not a low-power device. But this is a viable solution if your heading accuracy requirements are not too stringent. The temperature drift is an inherent sensor sensitivity and not much you can do about it but to keep the sensor temperature from wide swings in temperature. My recommendation is to try it with one or two devices in order to figure out if it is going to work for your application. The USFS offers a lot of advantages including magnetic anomaly detection/correction and automatic mag and gyro calibration but it is not magic. It takes some work to make good use of it and there are applications where its features are more of a hinderance than help. I think for what you want either an MPU9250 with fusion on the host or a USFS would work well. You'll just have to test one or both to find out for sure.

Let me know how I can help.

On Mon, Jan 15, 2018 at 2:08 AM, carbonadam notifications@github.com wrote:

After trying out the bno055 and not getting anything reliable I am going to order one of your sensor fusion boards as I really like that the fusion seems to output something I can use:) At the moment I am working on a swarm robot project that I was planning on using a sensor like this one in each robot(100 in total) but it needs to be fairly robust with the calibration as I dont want to wave a 100 robots in the air everyday in figure 8s...I will go insane. But just for arguments sake how well do you think running the fusion software on a esp32 would work using the MPU9250 in comparison to the sensor fusion module you make?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU6050/issues/6#issuecomment-357637557, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qow3RjcwgeFQxmsQDH_HizLfNl1tks5tKyO7gaJpZM4EbfGw .

[kriswiner]

We have a design for an all-ST sensor board using the EM7180 and we are testing it against the MPU9250-based version now. So far, both designs seems to be doing about as well as can be expected with heading accuracies of between 1 and 2 degrees. We will be documenting these testing results soon and will likely have a production run of the EM7180+ST-sensor board made in the Spring.

In our view, neither solution is significantly better than the other, but the MPU9250 has been in production for quite a few years and we would like to have at least one other highly-accurate solution available in case the MPU9250 goes out of production, which it will have to someday...

On Mon, Jan 15, 2018 at 4:43 AM, RaffaeleMineo notifications@github.com wrote:

Hi Mr. Winer. How about ST board with EM7180? When do you sell this?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU6050/issues/6#issuecomment-357672653, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qn80V-2x8_hcPbtzVAdNlXTq2O2zks5tK0fdgaJpZM4EbfGw .

[Benik3]

Hello. Didn't you check BNO080? It looks pretty powerful and accurate. It's able to calculate full 9DOF on the chip... (what I get MPU9250 is capable only to do 6DoF - without magnetometer).

[kriswiner]

Yes, but the BNO090, like the BNO055, uses the same crappy Bosck motion sensors. If you want the best on-chip sensor fusion, stick with the MPU9250 plus EM7180 https://www.tindie.com/products/onehorse/ultimate-sensor-fusion-solution/.

On Sat, Apr 14, 2018 at 9:03 AM, Benik3 notifications@github.com wrote:

Hello. Didn't you check BNO080? It looks pretty powerful and accurate. It's able to calculate full 9DOF on the chip... (what I get MPU9250 is capable only to do 6DoF - without magnetometer).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU6050/issues/6#issuecomment-381339486, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qnaTDfoHwA91Zsi2iXf5p4Tf9a3Qks5toh3XgaJpZM4EbfGw .

[kriswiner]

meant BNO080

On Sat, Apr 14, 2018 at 9:10 AM, Tlera Corporation tleracorp@gmail.com wrote:

Yes, but the BNO090, like the BNO055, uses the same crappy Bosck motion sensors. If you want the best on-chip sensor fusion, stick with the MPU9250 plus EM7180 https://www.tindie.com/products/onehorse/ultimate-sensor-fusion-solution/ .

On Sat, Apr 14, 2018 at 9:03 AM, Benik3 notifications@github.com wrote:

Hello. Didn't you check BNO080? It looks pretty powerful and accurate. It's able to calculate full 9DOF on the chip... (what I get MPU9250 is capable only to do 6DoF - without magnetometer).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU6050/issues/6#issuecomment-381339486, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qnaTDfoHwA91Zsi2iXf5p4Tf9a3Qks5toh3XgaJpZM4EbfGw .

[Benik3]

OK, thank you :)

[saedelman]

We've been testing the BNO055 9DOF sensor as part of an aviation data logger and even with calibration, the fusion solution gets completely hammered after any acceleration or moderate g-maneuvers (1.1-2g). It appears to us that the BNO055 is primarily dimensioned for use in VR headsets where the acceleration is contained. See an example below. I can assure you, we were not actually flying sideways.

We're going to be spinning a new board with the TDK Invensense ICM-20948 (replacement for MPU9250) and the EM7180, now that we have identified CDIWEB as a North American supplier of this elusive part (MOQ 4000) and we'll see how it holds up under the same conditions.

[kriswiner]

You can get the EM7180 in any quantity from Omnipro, ask for Tim Lydia.

On Sat, Apr 14, 2018 at 3:39 PM, Stephan Edelman notifications@github.com wrote:

We've been testing the BNO055 9DOF sensor as part of an aviation data logger and even with calibration, the fusion solution gets completely hammered after any acceleration or moderate g-maneuvers (1.1-2g). It appears to us that the BNO055 is primarily dimensioned for use in VR headsets where the acceleration is contained. See an example below. I can assure you, we were not actually flying sideways.

We're going to be spinning a new board with the TDK Invensense ICM-20948 (replacement for MPU9250) and the EM7180, now that we have identified CDIWEB as a North American supplier of this elusive part (MOQ 4000) and we'll see how it holds up under the same conditions.

[image: image] https://user-images.githubusercontent.com/5248091/38773055-2c51c7ce-4012-11e8-819c-e155dbd0af7e.png

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU6050/issues/6#issuecomment-381365609, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qiKkNEPBu24ipRQxw3Q3UE6OxD-Uks5tonqxgaJpZM4EbfGw .

[saedelman]

@kriswiner - Thank you, I'll get them to provide a quote.