Comments (238)
kriswiner
commented on August 17, 2024
9
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.
from mpu6050.
kriswiner
commented on August 17, 2024
5
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 ***@***.***> 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
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qvZZcC-2A_36f-y-pysnt0r-204dks5rjm6JgaJpZM4EbfGw>
.
from mpu6050.
kriswiner
commented on August 17, 2024
3
The mismatched VDDIO has kept me from mustering enough interest in this
sensor to do any testing with it; it would be interesting to compare the
jitter and stability against the MPU9250.
I can say the LSM6DSM is at least as good as if not better than the MPU6500
and the LIS2MDL is better in a lot of ways (interrupt, lower thermal
variation, lower jitter) than the AK8963C. Also, the LPS22HB is
significanltly better than the MS5637, our previous "go-to" barometer, in a
lot of ways (interrupt, low jitter, FIFO, direct read of
pressure/temperature).
The MPU9250 was a significant improvement over the MPU9150 and this could
easily be seen in even simple tests. I wonder what an ICM20948 vs. MPU9250
matchup would show...?
…On Sat, Apr 14, 2018 at 4:19 PM, Benik3 ***@***.***> wrote:
Yes. I just wouldn't say that it's replacement of MPU9250. It's just for
another section of market (IoT etc.)...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qgXcbfXc5SIQRoHw9XG43s8gN4nqks5tooPugaJpZM4EbfGw>
.
from mpu6050.
kriswiner
commented on August 17, 2024
3
Well we like the LIS2MDL very much and the IIS2MDC seems to be a successor,
but I will have to look into it. This
<https://www.tindie.com/products/onehorse/all-st-motion-sensor-breakout-board/>
is our latest breakout for the all-ST sensor suite including the LIS2MDL,
and we are producing a version with the EM7180 motion co-processor right
now. We will have accuracy data for this sensor suite compared to the
MPU9250 on github in a few weeks. For now I can tell you it performs as
well or better that the MPU9250 and with our own sensor fusion algorithms
we can routinely obtain 1 degree heading accuracy. So the sensor are really
quite good.
…On Sat, May 19, 2018 at 3:37 AM, Batilan ***@***.***> wrote:
Hi Kris,
Great topic and great linked articles! Any change you will include the STM
IIS2MDC magnetometer
<http://www.st.com/content/st_com/en/products/mems-and-sensors/e-compasses/iis2mdc.html>
in your research? However I guess you have more than enough sensors to
compare already :-). Probably you already saw this nice overview of STM
magnetometers.
<http://www.st.com/en/mems-and-sensors/e-compasses.html?querycriteria=productId=SC1449>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qm72w6PTzU029CpQTdW1IBCyVZ-Lks5tz_XZgaJpZM4EbfGw>
.
from mpu6050.
kriswiner
commented on August 17, 2024
3
Hi David,
The design looks very well done. I didn't check the schematic and will
assume this is correct. I have some comments on the layout:
First, this kind of design is much more easily done with a four-layer pcb
and the design performance would be better as well. Then you could have a
1.8 V layer and a GND layer and avoid having the long traces for these that
are in your current design.
Are you using the grossly oversized Sparkfun passive footprints? I would
cut these down by half in width and length.
Best to avoid vias anywhere near the ICM package to minimize pcb stresses.
I would use the extra PTH for ICMaddress pin so you can have more than one
on a given I2C bus. This is standard practice.
I notice there is no copper ground pour on either layer; maybe no room with
all of those traces. But the bottom at least needs one. Both sides really,
then you can eliminate several vias, which is a good thing.
All power traces should be minimum 0.25 mm wide.
There should be no copper underneath the ICM package, and the ICM pad
should not be connected to the pcb. At least the latter was true for the
MPU9250 and I would be surprised if the advice is to solder the central pad
for the new design.
Don't you need pullups on the I2C bus?
I would use 13-mil (0.325 mm) vias since this is the smallest allowed with
two layers. Another benefit to a four layer design is the via size minimum
drops to 10 mil.
Yes, there are a lot of clearance issues even with the looser OSHPark
design rules (which I recommend you use.
My minimum recommendations:
Use ground copper pours on top and bottom and eliminate as many GND vias as
possible.
Cut the size of the passive footprints.
remove metal from underneath the ICM package.
You need at least 15 mils center-to-center (0.375 mm) separation between
each trace.
When you have the ground pours in and the design revised let me have
another look.
Kris
…On Fri, Jan 18, 2019 at 5:10 AM David ***@***.***> wrote:
I have designed my own breakout board for the ICM-20948. If you are
interested, check it out! I would love to get some comments as this is one
of my first designs.
https://github.com/dtornqvist/icm-20948-breakout
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qpIHPgcFVoXxElNtZNkB2obQ_Varks5vEce9gaJpZM4EbfGw>
.
from mpu6050.
kriswiner
commented on August 17, 2024
2
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
[email protected].
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 ***@***.***> 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
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qqMrRV7hJme5bk8Dww3PzQ8NOGv4ks5srllpgaJpZM4EbfGw>
.
from mpu6050.
kriswiner
commented on August 17, 2024
2
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 ***@***.***> 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
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qvYb62e1_5zdZq9vNoEAW8onSDNkks5s7FacgaJpZM4EbfGw>
.
from mpu6050.
kriswiner
commented on August 17, 2024
2
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 ***@***.***> 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
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qn80V-2x8_hcPbtzVAdNlXTq2O2zks5tK0fdgaJpZM4EbfGw>
.
from mpu6050.
kriswiner
commented on August 17, 2024
1
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?
from mpu6050.
maziarzamani
commented on August 17, 2024
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.
from mpu6050.
kriswiner
commented on August 17, 2024
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.
from mpu6050.
maziarzamani
commented on August 17, 2024
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?
from mpu6050.
maziarzamani
commented on August 17, 2024
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?
from mpu6050.
kriswiner
commented on August 17, 2024
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!
from mpu6050.
maziarzamani
commented on August 17, 2024
I am looking forward to see your results! 👍
from mpu6050.
jheissjr
commented on August 17, 2024
Kris, how is testing? Are you looking at the AK8963A, AK9912, LIS3MDL?
from mpu6050.
kriswiner
commented on August 17, 2024
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:[email protected]]
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
#6 (comment) .
<https://github.com/notifications/beacon/AGY1qm_jNtUJYMx4W3VrhmEdW8ErwQg7ks5
o4au_gaJpZM4EbfGw.gif>
from mpu6050.
jheissjr
commented on August 17, 2024
What have you seen with the Bosh magnetometer?
from mpu6050.
kriswiner
commented on August 17, 2024
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:[email protected]]
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
#6 (comment) .
<https://github.com/notifications/beacon/AGY1qvsJB3IaWD7stvTPoXOiJXzTOSRFks5
o4eaigaJpZM4EbfGw.gif>
from mpu6050.
maziarzamani
commented on August 17, 2024
Did you ever have the chance to try out the AK9912?
from mpu6050.
kriswiner
commented on August 17, 2024
Still on my list of things to do, but I did get some samples.
from mpu6050.
jheissjr
commented on August 17, 2024
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
from mpu6050.
kriswiner
commented on August 17, 2024
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:[email protected]]
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
#6 (comment) .
<https://github.com/notifications/beacon/AGY1qpA9RPy3cU6M7oUtSqCrWVyCjrftks5
o6cMegaJpZM4EbfGw.gif>
from mpu6050.
sarwadenj
commented on August 17, 2024
@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.
from mpu6050.
kriswiner
commented on August 17, 2024
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 ***@***.***> wrote:
@kriswiner ***@***.***
<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
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qnco4v3S3sfeT-ReshG86AMNRE9Aks5rVKtAgaJpZM4EbfGw>
.
from mpu6050.
cavetronic
commented on August 17, 2024
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
from mpu6050.
cavetronic
commented on August 17, 2024
Thank You so much!
from mpu6050.
mik00
commented on August 17, 2024
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.?
from mpu6050.
kriswiner
commented on August 17, 2024
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 ***@***.***> 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
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qgR2YsD-2dtTagG3YvJTMSEUGDCHks5r7Qf2gaJpZM4EbfGw>
.
from mpu6050.
mik00
commented on August 17, 2024
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.
from mpu6050.
kriswiner
commented on August 17, 2024
Yes, email me at [email protected] for more discussion.
…On Thu, May 18, 2017 at 11:54 PM, mik00 ***@***.***> 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
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qnazjVwTyErqWkop6xMe1M3tIl2mks5r7Ty_gaJpZM4EbfGw>
.
from mpu6050.
saedelman
commented on August 17, 2024
@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?
from mpu6050.
kriswiner
commented on August 17, 2024
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 ***@***.***> 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
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qvo1OXbx-4WNG_u10z5s1zv-hMUrks5sOm41gaJpZM4EbfGw>
.
from mpu6050.
saedelman
commented on August 17, 2024
@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.
from mpu6050.
kriswiner
commented on August 17, 2024
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 ***@***.***> 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
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qnpw-sqdtFYmoPo4RyLx_FfCqghLks5sOoyegaJpZM4EbfGw>
.
from mpu6050.
didasy
commented on August 17, 2024
@kriswiner Where do you buy EM7180? I couldn't find it anywhere.
from mpu6050.
kriswiner
commented on August 17, 2024
If you just need a few I can sell them to you, e-mail me at
[email protected].
…On Mon, Jul 31, 2017 at 11:17 PM, Andida Syahendar ***@***.*** > 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
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qjRIdbhFIwDc--OXvlbYa1NbtQ2Bks5sTsMEgaJpZM4EbfGw>
.
from mpu6050.
saedelman
commented on August 17, 2024
@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?
from mpu6050.
IngRaffaeleMineo
commented on August 17, 2024
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
from mpu6050.
jheissjr
commented on August 17, 2024
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?
from mpu6050.
kriswiner
commented on August 17, 2024
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 ***@***.***> 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
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qjoklwowCsyeTjlnTRcmOzcNc0O3ks5s7GsOgaJpZM4EbfGw>
.
from mpu6050.
saedelman
commented on August 17, 2024
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?
from mpu6050.
kriswiner
commented on August 17, 2024
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 ***@***.***> 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
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qtOHrtjOttBrJ5nUL7laXveaJxLAks5s7MaSgaJpZM4EbfGw>
.
from mpu6050.
carbonadam
commented on August 17, 2024
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?
from mpu6050.
IngRaffaeleMineo
commented on August 17, 2024
Hi Mr. Winer. How about ST board with EM7180? When do you sell this?
from mpu6050.
kriswiner
commented on August 17, 2024
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 ***@***.***> 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
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qow3RjcwgeFQxmsQDH_HizLfNl1tks5tKyO7gaJpZM4EbfGw>
.
from mpu6050.
Benik3
commented on August 17, 2024
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).
from mpu6050.
kriswiner
commented on August 17, 2024
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 ***@***.***> 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
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qnaTDfoHwA91Zsi2iXf5p4Tf9a3Qks5toh3XgaJpZM4EbfGw>
.
from mpu6050.
kriswiner
commented on August 17, 2024
meant BNO080
On Sat, Apr 14, 2018 at 9:10 AM, Tlera Corporation <[email protected]>
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 ***@***.***> 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
> <#6 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AGY1qnaTDfoHwA91Zsi2iXf5p4Tf9a3Qks5toh3XgaJpZM4EbfGw>
> .
>
from mpu6050.
Benik3
commented on August 17, 2024
OK, thank you :)
from mpu6050.
saedelman
commented on August 17, 2024
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.
from mpu6050.
kriswiner
commented on August 17, 2024
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 ***@***.***> 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
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qiKkNEPBu24ipRQxw3Q3UE6OxD-Uks5tonqxgaJpZM4EbfGw>
.
from mpu6050.
saedelman
commented on August 17, 2024
@kriswiner - Thank you, I'll get them to provide a quote.
from mpu6050.
kriswiner
commented on August 17, 2024
They usually charge me $1.50 each plus shipping, very reasonable. CDW is
likley to be significanlty higher than this..
…On Sat, Apr 14, 2018 at 4:04 PM, Stephan Edelman ***@***.***> wrote:
@kriswiner <https://github.com/kriswiner> - Thank you, I'll get them to
provide a quote.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1quNE21XvMStNWjlUR458t1a45BnIks5tooCCgaJpZM4EbfGw>
.
from mpu6050.
Benik3
commented on August 17, 2024
The ICM-20948 is almost the same as MPU9250 what I see.
Just lower power, magnetometer 16bit (vs 14bit) and SPI up to 7MHz (vs 1MHz).
from mpu6050.
kriswiner
commented on August 17, 2024
Big difference is the VDDIO maximum is 1.8 V, so if you want to use a 3V3
MCU like we do you will need logic level conversion etc, a PITA and not
worth the trouble IMHO. I would recommend the ST sensor suite as a
replacement for the MPU9250.
…On Sat, Apr 14, 2018 at 4:12 PM, Benik3 ***@***.***> wrote:
The ICM-20948 is almost the same as MPU9250 what I see.
Just lower power, magnetometer 16bit (vs 14bit) and SPI up to 7MHz (vs
1MHz).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qtyDs_KN0fe4DhD1M7SRZQsrvuXPks5tooJHgaJpZM4EbfGw>
.
from mpu6050.
kriswiner
commented on August 17, 2024
The MPU9250 mag (AK8963C) has either 14-bit or 16-bit resolution, user
selectable. As for the SPI speed, this is irrelevant for sensor fusion and
for most applications as far as I can see sine the max sensor sample rate
is ~8 kHz. There might be a slight advantage for power usage but overall I
would stick with I2C for simple math reasons; 2 pin IO vs. 4 pin IO. GPIOs
are too precious to waste on motion sensors.
On Sat, Apr 14, 2018 at 4:14 PM, Tlera Corporation <[email protected]>
wrote:
… Big difference is the VDDIO maximum is 1.8 V, so if you want to use a 3V3
MCU like we do you will need logic level conversion etc, a PITA and not
worth the trouble IMHO. I would recommend the ST sensor suite as a
replacement for the MPU9250.
On Sat, Apr 14, 2018 at 4:12 PM, Benik3 ***@***.***> wrote:
> The ICM-20948 is almost the same as MPU9250 what I see.
> Just lower power, magnetometer 16bit (vs 14bit) and SPI up to 7MHz (vs
> 1MHz).
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#6 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AGY1qtyDs_KN0fe4DhD1M7SRZQsrvuXPks5tooJHgaJpZM4EbfGw>
> .
>
from mpu6050.
Benik3
commented on August 17, 2024
Yes. I just wouldn't say that it's replacement of MPU9250. It's just for another section of market (IoT etc.)...
from mpu6050.
didasy
commented on August 17, 2024
You can get the EM7180 in any quantity from Omnipro, ask for Tim Lydia.
Do they sell board or just the chip?
from mpu6050.
kriswiner
commented on August 17, 2024
Omnipro sells the IC, you can get a board from CDIWeb or here
<https://www.tindie.com/products/onehorse/ultimate-sensor-fusion-solution/>.
…On Tue, Apr 17, 2018 at 3:49 AM, Andida Syahendar ***@***.***> wrote:
@kriswiner <https://github.com/kriswiner>
You can get the EM7180 in any quantity from Omnipro, ask for Tim Lydia.
Do they sell board or just the chip?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qoWhzFX3oBrfS-6Pbdm9B16R2zm7ks5tpci3gaJpZM4EbfGw>
.
from mpu6050.
laufetc
commented on August 17, 2024
And... if the volumes are very large (100k+), you can contact EM
Microlectronic directly to get extremely inexpensive pricing.
On Tue, Apr 17, 2018 at 10:02 AM, Kris Winer <[email protected]>
wrote:
… Omnipro sells the IC, you can get a board from CDIWeb or here
<https://www.tindie.com/products/onehorse/ultimate-sensor-fusion-solution/
>.
On Tue, Apr 17, 2018 at 3:49 AM, Andida Syahendar <
***@***.***>
wrote:
> @kriswiner <https://github.com/kriswiner>
>
> You can get the EM7180 in any quantity from Omnipro, ask for Tim Lydia.
>
> Do they sell board or just the chip?
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#6 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AGY1qoWhzFX3oBrfS-
6Pbdm9B16R2zm7ks5tpci3gaJpZM4EbfGw>
> .
>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAJxqYS895kBTGAlZz5RrJ56AiWJtPAVks5tphIogaJpZM4EbfGw>
.
from mpu6050.
burnhamd
commented on August 17, 2024
Hey Kris, based on your suggestions I am using the 9250 for my application. Any idea how the performance of the Motion library (MPL) invensense provides compares in accuracy to the EM7180?
I've been doing some testing with the MPL and found that the 6-axis is pretty good, but the heading is pretty variable with +- 4 degrees standard deviation. That is after using their built in calibration.
from mpu6050.
kriswiner
commented on August 17, 2024
No idea, I have never used Invensense's MPL. We typically get +/- 2 degree
rms heading error with the EM7180, and can get +/- 1 degree heading error
with our own propriatary fusion algorithms. This depends on excellent
calibration of the sensors. +/- 4 degrees is typical of what I would expect
from the MPU9250 using simple Madgwick or Mahony fusion.
…On Tue, May 8, 2018 at 11:16 AM, burnhamd ***@***.***> wrote:
Hey Kris, based on your suggestions I am using the 9250 for my
application. Any idea how the performance of the Motion library (MPL)
invensense provides compares in accuracy to the EM7180?
I've been doing some testing with the MPL and found that the 6-axis is
pretty good, but the heading is pretty variable with +- 4 degrees standard
deviation. That is after using their built in calibration.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qsiVgVlWO-7nVx_jfcRp-czWVND-ks5tweEMgaJpZM4EbfGw>
.
from mpu6050.
saedelman
commented on August 17, 2024
Kris,
Do you license your algorithms? How computationally expensive are your algorithms compared to Madgewick / Mahoney?
Regards,
Stephan.
----
Stephan Edelman
NewAce Corporation
866.779.1518 x221
416.460.9602
On May 8, 2018, at 2:18 PM, Kris Winer <[email protected]<mailto:[email protected]>> wrote:
No idea, I have never used Invensense's MPL. We typically get +/- 2 degree
rms heading error with the EM7180, and can get +/- 1 degree heading error
with our own propriatary fusion algorithms. This depends on excellent
calibration of the sensors. +/- 4 degrees is typical of what I would expect
from the MPU9250 using simple Madgwick or Mahony fusion.
On Tue, May 8, 2018 at 11:16 AM, burnhamd ***@***.******@***.***>> wrote:
Hey Kris, based on your suggestions I am using the 9250 for my
application. Any idea how the performance of the Motion library (MPL)
invensense provides compares in accuracy to the EM7180?
I've been doing some testing with the MPL and found that the 6-axis is
pretty good, but the heading is pretty variable with +- 4 degrees standard
deviation. That is after using their built in calibration.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qsiVgVlWO-7nVx_jfcRp-czWVND-ks5tweEMgaJpZM4EbfGw>
.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#6 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AFAUW_8Tmu_PzdWsr7pUZ6_t_VSnjJRDks5tweGBgaJpZM4EbfGw>.
from mpu6050.
kriswiner
commented on August 17, 2024
They are very efficient, never thought about licensing. We are still in the
middle of testing ST sensors vs MPU9250, EM7180 versus Madgwick/Mahoney vs.
our own, etc. Might be premature but if you need +/- 1 degree heading
accuracy, we can discuss licensing our methods for getting there.
On Tue, May 8, 2018 at 11:22 AM, Stephan Edelman <[email protected]>
wrote:
… Kris,
Do you license your algorithms? How computationally expensive are your
algorithms compared to Madgewick / Mahoney?
Regards,
Stephan.
----
Stephan Edelman
NewAce Corporation
866.779.1518 x221
416.460.9602
On May 8, 2018, at 2:18 PM, Kris Winer ***@***.***<mailto:
***@***.***>> wrote:
No idea, I have never used Invensense's MPL. We typically get +/- 2 degree
rms heading error with the EM7180, and can get +/- 1 degree heading error
with our own propriatary fusion algorithms. This depends on excellent
calibration of the sensors. +/- 4 degrees is typical of what I would expect
from the MPU9250 using simple Madgwick or Mahony fusion.
On Tue, May 8, 2018 at 11:16 AM, burnhamd ***@***.***<
***@***.***>> wrote:
> Hey Kris, based on your suggestions I am using the 9250 for my
> application. Any idea how the performance of the Motion library (MPL)
> invensense provides compares in accuracy to the EM7180?
> I've been doing some testing with the MPL and found that the 6-axis is
> pretty good, but the heading is pretty variable with +- 4 degrees
standard
> deviation. That is after using their built in calibration.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#6 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-
auth/AGY1qsiVgVlWO-7nVx_jfcRp-czWVND-ks5tweEMgaJpZM4EbfGw>
> .
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<https://github.com/
kriswiner/MPU6050#6#issuecomment-387494994>, or mute the thread<
https://github.com/notifications/unsubscribe-
auth/AFAUW_8Tmu_PzdWsr7pUZ6_t_VSnjJRDks5tweGBgaJpZM4EbfGw>.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qqYuB1sz6NbXsnIXLly3bzyqBTkxks5tweJYgaJpZM4EbfGw>
.
from mpu6050.
saedelman
commented on August 17, 2024
Hello Kris,
Can I contact you offline?
Regards,
Stephan.
----
Stephan Edelman
NewAce Corporation
866.779.1518 x221
416.460.9602
On May 8, 2018, at 2:24 PM, Kris Winer <[email protected]<mailto:[email protected]>> wrote:
They are very efficient, never thought about licensing. We are still in the
middle of testing ST sensors vs MPU9250, EM7180 versus Madgwick/Mahoney vs.
our own, etc. Might be premature but if you need +/- 1 degree heading
accuracy, we can discuss licensing our methods for getting there.
On Tue, May 8, 2018 at 11:22 AM, Stephan Edelman <[email protected]<mailto:[email protected]>>
wrote:
Kris,
Do you license your algorithms? How computationally expensive are your
algorithms compared to Madgewick / Mahoney?
Regards,
Stephan.
----
Stephan Edelman
NewAce Corporation
866.779.1518 x221
416.460.9602
On May 8, 2018, at 2:18 PM, Kris Winer ***@***.******@***.***><mailto:
***@***.******@***.***>>> wrote:
No idea, I have never used Invensense's MPL. We typically get +/- 2 degree
rms heading error with the EM7180, and can get +/- 1 degree heading error
with our own propriatary fusion algorithms. This depends on excellent
calibration of the sensors. +/- 4 degrees is typical of what I would expect
from the MPU9250 using simple Madgwick or Mahony fusion.
On Tue, May 8, 2018 at 11:16 AM, burnhamd ***@***.******@***.***><
***@***.***>> wrote:
> Hey Kris, based on your suggestions I am using the 9250 for my
> application. Any idea how the performance of the Motion library (MPL)
> invensense provides compares in accuracy to the EM7180?
> I've been doing some testing with the MPL and found that the 6-axis is
> pretty good, but the heading is pretty variable with +- 4 degrees
standard
> deviation. That is after using their built in calibration.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#6 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-
auth/AGY1qsiVgVlWO-7nVx_jfcRp-czWVND-ks5tweEMgaJpZM4EbfGw>
> .
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<https://github.com/
kriswiner/MPU6050#6#issuecomment-387494994>, or mute the thread<
https://github.com/notifications/unsubscribe-
auth/AFAUW_8Tmu_PzdWsr7pUZ6_t_VSnjJRDks5tweGBgaJpZM4EbfGw>.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qqYuB1sz6NbXsnIXLly3bzyqBTkxks5tweJYgaJpZM4EbfGw>
.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#6 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AFAUW558HQN6C6RyrAp6ZAC1JOu4NFDUks5tweLZgaJpZM4EbfGw>.
from mpu6050.
kriswiner
commented on August 17, 2024
925 8547820
On Tue, May 8, 2018 at 11:26 AM, Stephan Edelman <[email protected]>
wrote:
… Hello Kris,
Can I contact you offline?
Regards,
Stephan.
----
Stephan Edelman
NewAce Corporation
866.779.1518 x221
416.460.9602
On May 8, 2018, at 2:24 PM, Kris Winer ***@***.***<mailto:
***@***.***>> wrote:
They are very efficient, never thought about licensing. We are still in the
middle of testing ST sensors vs MPU9250, EM7180 versus Madgwick/Mahoney vs.
our own, etc. Might be premature but if you need +/- 1 degree heading
accuracy, we can discuss licensing our methods for getting there.
On Tue, May 8, 2018 at 11:22 AM, Stephan Edelman ***@***.***
***@***.***>>
wrote:
> Kris,
>
> Do you license your algorithms? How computationally expensive are your
> algorithms compared to Madgewick / Mahoney?
>
> Regards,
>
> Stephan.
> ----
> Stephan Edelman
> NewAce Corporation
> 866.779.1518 x221
> 416.460.9602
>
> On May 8, 2018, at 2:18 PM, Kris Winer ***@***.***<mailto:
***@***.***><mailto:
> ***@***.******@***.***>>> wrote:
>
> No idea, I have never used Invensense's MPL. We typically get +/- 2
degree
> rms heading error with the EM7180, and can get +/- 1 degree heading error
> with our own propriatary fusion algorithms. This depends on excellent
> calibration of the sensors. +/- 4 degrees is typical of what I would
expect
> from the MPU9250 using simple Madgwick or Mahony fusion.
>
> On Tue, May 8, 2018 at 11:16 AM, burnhamd ***@***.***<
***@***.***><
> ***@***.***>> wrote:
>
> > Hey Kris, based on your suggestions I am using the 9250 for my
> > application. Any idea how the performance of the Motion library (MPL)
> > invensense provides compares in accuracy to the EM7180?
> > I've been doing some testing with the MPL and found that the 6-axis is
> > pretty good, but the heading is pretty variable with +- 4 degrees
> standard
> > deviation. That is after using their built in calibration.
> >
> > —
> > You are receiving this because you were mentioned.
> > Reply to this email directly, view it on GitHub
> > <#6 (comment)
>,
> > or mute the thread
> > <https://github.com/notifications/unsubscribe-
> auth/AGY1qsiVgVlWO-7nVx_jfcRp-czWVND-ks5tweEMgaJpZM4EbfGw>
> > .
> >
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub<https://github.com/
> kriswiner/MPU6050#6#issuecomment-387494994>, or mute the thread<
> https://github.com/notifications/unsubscribe-
> auth/AFAUW_8Tmu_PzdWsr7pUZ6_t_VSnjJRDks5tweGBgaJpZM4EbfGw>.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#6 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/
AGY1qqYuB1sz6NbXsnIXLly3bzyqBTkxks5tweJYgaJpZM4EbfGw>
> .
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<https://github.com/
kriswiner/MPU6050#6#issuecomment-387496643>, or mute the thread<
https://github.com/notifications/unsubscribe-auth/
AFAUW558HQN6C6RyrAp6ZAC1JOu4NFDUks5tweLZgaJpZM4EbfGw>.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qnXhIw-w8uir_-URFVavz1yn68fZks5tweNTgaJpZM4EbfGw>
.
from mpu6050.
kriswiner
commented on August 17, 2024
Here
<https://www.digikey.com/products/en/sensors-transducers/motion-sensors-imus-inertial-measurement-units/567?k=Thales%20Visionix%20Navchip>
is an example of a much more expensive 6 DoF solution; I can't quite figure
out what this does that the $35 USFS (EM7180 + MPU9250) doesn't...except
cost and weight a lot more and require an odd connector interface, etc. Who
is the customer for this kind of product?
On Tue, May 8, 2018 at 11:24 AM, Tlera Corporation <[email protected]>
wrote:
… They are very efficient, never thought about licensing. We are still in
the middle of testing ST sensors vs MPU9250, EM7180 versus Madgwick/Mahoney
vs. our own, etc. Might be premature but if you need +/- 1 degree heading
accuracy, we can discuss licensing our methods for getting there.
On Tue, May 8, 2018 at 11:22 AM, Stephan Edelman ***@***.***
> wrote:
> Kris,
>
> Do you license your algorithms? How computationally expensive are your
> algorithms compared to Madgewick / Mahoney?
>
> Regards,
>
> Stephan.
> ----
> Stephan Edelman
> NewAce Corporation
> 866.779.1518 x221
> 416.460.9602
>
> On May 8, 2018, at 2:18 PM, Kris Winer ***@***.***<mailto:
> ***@***.***>> wrote:
>
> No idea, I have never used Invensense's MPL. We typically get +/- 2 degree
> rms heading error with the EM7180, and can get +/- 1 degree heading error
> with our own propriatary fusion algorithms. This depends on excellent
> calibration of the sensors. +/- 4 degrees is typical of what I would
> expect
> from the MPU9250 using simple Madgwick or Mahony fusion.
>
> On Tue, May 8, 2018 at 11:16 AM, burnhamd ***@***.***<mail
> ***@***.***>> wrote:
>
> > Hey Kris, based on your suggestions I am using the 9250 for my
> > application. Any idea how the performance of the Motion library (MPL)
> > invensense provides compares in accuracy to the EM7180?
> > I've been doing some testing with the MPL and found that the 6-axis is
> > pretty good, but the heading is pretty variable with +- 4 degrees
> standard
> > deviation. That is after using their built in calibration.
> >
> > —
> > You are receiving this because you were mentioned.
> > Reply to this email directly, view it on GitHub
> > <#6 (comment)>,
> > or mute the thread
> > <https://github.com/notifications/unsubscribe-auth/
> AGY1qsiVgVlWO-7nVx_jfcRp-czWVND-ks5tweEMgaJpZM4EbfGw>
> > .
> >
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub<https://github.com/kris
> winer/MPU6050/issues/6#issuecomment-387494994>, or mute the thread<
> https://github.com/notifications/unsubscribe-auth/
> AFAUW_8Tmu_PzdWsr7pUZ6_t_VSnjJRDks5tweGBgaJpZM4EbfGw>.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#6 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AGY1qqYuB1sz6NbXsnIXLly3bzyqBTkxks5tweJYgaJpZM4EbfGw>
> .
>
from mpu6050.
Batilan
commented on August 17, 2024
Hi Kris,
Great topic and great linked articles! Any chance you will include the STM IIS2MDC magnetometer in your research? However I guess you have more than enough sensors to compare already :-). Probably you already saw this nice overview of STM magnetometers.
from mpu6050.
kriswiner
commented on August 17, 2024
As far as I can tell, the LIS2MDL and IIS2MDC are identical.
On Sat, May 19, 2018 at 8:29 AM, Tlera Corporation <[email protected]>
wrote:
… Well we like the LIS2MDL very much and the IIS2MDC seems to be a
successor, but I will have to look into it. This
<https://www.tindie.com/products/onehorse/all-st-motion-sensor-breakout-board/>
is our latest breakout for the all-ST sensor suite including the LIS2MDL,
and we are producing a version with the EM7180 motion co-processor right
now. We will have accuracy data for this sensor suite compared to the
MPU9250 on github in a few weeks. For now I can tell you it performs as
well or better that the MPU9250 and with our own sensor fusion algorithms
we can routinely obtain 1 degree heading accuracy. So the sensor are really
quite good.
On Sat, May 19, 2018 at 3:37 AM, Batilan ***@***.***> wrote:
> Hi Kris,
>
> Great topic and great linked articles! Any change you will include the STM
> IIS2MDC magnetometer
> <http://www.st.com/content/st_com/en/products/mems-and-sensors/e-compasses/iis2mdc.html>
> in your research? However I guess you have more than enough sensors to
> compare already :-). Probably you already saw this nice overview of STM
> magnetometers.
> <http://www.st.com/en/mems-and-sensors/e-compasses.html?querycriteria=productId=SC1449>
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#6 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AGY1qm72w6PTzU029CpQTdW1IBCyVZ-Lks5tz_XZgaJpZM4EbfGw>
> .
>
from mpu6050.
CZEMacLeod
commented on August 17, 2024
@kriswiner I notice earlier in this thread you were discussing the LIS3MDL and later then go with the LIS2MDL. Do you have any discussion on the differences and why you picked the 2 vs. the 3? I currently have a GPS board with the LIS3MDL and want to understand what limitations I may encounter and if I should try and change chip... Unfortunately they don't seem to be pin compatible so I can't easily switch chip and investigate myself just now.
from mpu6050.
kriswiner
commented on August 17, 2024
The LIS2MDL offers some advantages but ther perfromance of the LIS3MDL
should be fine. The 2MDL uses anisotropic magnetoresistance instead of Hall
effect and is less susceptible to temperature variations. It als has a
single wide-range sensitivity.
…On Mon, Jul 30, 2018 at 4:47 AM, Cynthia MacLeod ***@***.***> wrote:
@kriswiner <https://github.com/kriswiner> I notice earlier in this thread
you were discussing the LIS3MDL and later then go with the LIS2MDL. Do you
have any discussion on the differences and why you picked the 2 vs. the 3?
I currently have a GPS board with the LIS3MDL and want to understand what
limitations I may encounter and if I should try and change chip...
Unfortunately they don't seem to be pin compatible so I can't easily switch
chip and investigate myself just now.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qldF5Ua1FIjeDZF89gwzbLMNEp27ks5uLvJvgaJpZM4EbfGw>
.
from mpu6050.
dtornqvist
commented on August 17, 2024
I have designed my own breakout board for the ICM-20948. If you are interested, check it out! I would love to get some comments as this is one of my first designs.
https://github.com/dtornqvist/icm-20948-breakout
from mpu6050.
dtornqvist
commented on August 17, 2024
Thanks a lot for all constructive comments! :-)
Currently, I try to live with EAGLE free and is therefore limited to two layers. But I guess I will have to upgrade for more complicated designs.
Thanks for the remark about the capacitor footprints, I changed those.
I have removed everything underneath the ICM-package and moved away the vias. Please check if you think they are far away enough.
I added a solder jumper to set the ICM-address.
I read up on how to make ground planes and added on both sides.
The VCC power traces are 0.4mm, but the 1.8v are 0.2mm. I see now that I missed making them 0.25. Since those are only reference for the signal levels, do you think it is necessary?
Pull-ups on the i2c bus should not be needed as the level translator contains internal pull-ups.
I downloaded the design rules from OSH Park, which were more strict than the original settings i had. The remaining issues now all relate to the footprint of the ICM. My current footprint is from the Sparkfun MPU-9250. Do you know any better footprints or do I have to update manually? Is it possible to get a footprint for this module that fulfill the OSH Park specifications?
from mpu6050.
kriswiner
commented on August 17, 2024
I have a footprint that I use. The only caveat is I would make the lead pad
lengths a bit shorter if I were doing it again. Maybe I already did on this
design:
https://oshpark.com/shared_projects/zlx9tPml
note this is before I minimized the passive footprints, although these are
smaller than the Sparkfun version.
…On Sun, Jan 20, 2019 at 2:01 AM David ***@***.***> wrote:
Thanks a lot for all constructive comments! :-)
Currently, I try to live with EAGLE free and is therefore limited to two
layers. But I guess I will have to upgrade for more complicated designs.
Thanks for the remark about the capacitor footprints, I changed those.
I have removed everything underneath the ICM-package and moved away the
vias. Please check if you think they are far away enough.
I added a solder jumper to set the ICM-address.
I read up on how to make ground planes and added on both sides.
The VCC power traces are 0.4mm, but the 1.8v are 0.2mm. I see now that I
missed making them 0.25. Since those are only reference for the signal
levels, do you think it is necessary?
Pull-ups on the i2c bus should not be needed as the level translator
contains internal pull-ups.
I downloaded the design rules from OSH Park, which were more strict than
the original settings i had. The remaining issues now all relate to the
footprint of the ICM. My current footprint is from the Sparkfun MPU-9250.
Do you know any better footprints or do I have to update manually? Is it
possible to get a footprint for this module that fulfill the OSH Park
specifications?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qsjC3qQWX6q4kxVVw3X9pE-Rsrxyks5vFD6VgaJpZM4EbfGw>
.
from mpu6050.
kriswiner
commented on August 17, 2024
If the 1.8 V traces are not power traces but only signal traces then 8 mil
is sufficient. I would not use 6 mil traces anywhere on a 2 layer design.
On Sun, Jan 20, 2019 at 11:41 AM Tlera Corporation <[email protected]>
wrote:
… I have a footprint that I use. The only caveat is I would make the lead
pad lengths a bit shorter if I were doing it again. Maybe I already did on
this design:
https://oshpark.com/shared_projects/zlx9tPml
note this is before I minimized the passive footprints, although these are
smaller than the Sparkfun version.
On Sun, Jan 20, 2019 at 2:01 AM David ***@***.***> wrote:
> Thanks a lot for all constructive comments! :-)
>
> Currently, I try to live with EAGLE free and is therefore limited to two
> layers. But I guess I will have to upgrade for more complicated designs.
>
> Thanks for the remark about the capacitor footprints, I changed those.
>
> I have removed everything underneath the ICM-package and moved away the
> vias. Please check if you think they are far away enough.
>
> I added a solder jumper to set the ICM-address.
>
> I read up on how to make ground planes and added on both sides.
>
> The VCC power traces are 0.4mm, but the 1.8v are 0.2mm. I see now that I
> missed making them 0.25. Since those are only reference for the signal
> levels, do you think it is necessary?
>
> Pull-ups on the i2c bus should not be needed as the level translator
> contains internal pull-ups.
>
> I downloaded the design rules from OSH Park, which were more strict than
> the original settings i had. The remaining issues now all relate to the
> footprint of the ICM. My current footprint is from the Sparkfun MPU-9250.
> Do you know any better footprints or do I have to update manually? Is it
> possible to get a footprint for this module that fulfill the OSH Park
> specifications?
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#6 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AGY1qsjC3qQWX6q4kxVVw3X9pE-Rsrxyks5vFD6VgaJpZM4EbfGw>
> .
>
from mpu6050.
kriswiner
commented on August 17, 2024
On the ADO, you can use a solder jumper, but I prefer exposing this choice
to an edge pin for a lot of reasons but mostly because I don't like NC
outputs. Bad design practice. But your design, your choice.
I didn't receive any files for the new design. When ready, I am happy to
take another look if you want me to.
On Sun, Jan 20, 2019 at 11:41 AM Tlera Corporation <[email protected]>
wrote:
… If the 1.8 V traces are not power traces but only signal traces then 8 mil
is sufficient. I would not use 6 mil traces anywhere on a 2 layer design.
On Sun, Jan 20, 2019 at 11:41 AM Tlera Corporation ***@***.***>
wrote:
> I have a footprint that I use. The only caveat is I would make the lead
> pad lengths a bit shorter if I were doing it again. Maybe I already did on
> this design:
>
> https://oshpark.com/shared_projects/zlx9tPml
>
> note this is before I minimized the passive footprints, although these
> are smaller than the Sparkfun version.
>
> On Sun, Jan 20, 2019 at 2:01 AM David ***@***.***> wrote:
>
>> Thanks a lot for all constructive comments! :-)
>>
>> Currently, I try to live with EAGLE free and is therefore limited to two
>> layers. But I guess I will have to upgrade for more complicated designs.
>>
>> Thanks for the remark about the capacitor footprints, I changed those.
>>
>> I have removed everything underneath the ICM-package and moved away the
>> vias. Please check if you think they are far away enough.
>>
>> I added a solder jumper to set the ICM-address.
>>
>> I read up on how to make ground planes and added on both sides.
>>
>> The VCC power traces are 0.4mm, but the 1.8v are 0.2mm. I see now that I
>> missed making them 0.25. Since those are only reference for the signal
>> levels, do you think it is necessary?
>>
>> Pull-ups on the i2c bus should not be needed as the level translator
>> contains internal pull-ups.
>>
>> I downloaded the design rules from OSH Park, which were more strict than
>> the original settings i had. The remaining issues now all relate to the
>> footprint of the ICM. My current footprint is from the Sparkfun MPU-9250.
>> Do you know any better footprints or do I have to update manually? Is it
>> possible to get a footprint for this module that fulfill the OSH Park
>> specifications?
>>
>> —
>> You are receiving this because you were mentioned.
>> Reply to this email directly, view it on GitHub
>> <#6 (comment)>,
>> or mute the thread
>> <https://github.com/notifications/unsubscribe-auth/AGY1qsjC3qQWX6q4kxVVw3X9pE-Rsrxyks5vFD6VgaJpZM4EbfGw>
>> .
>>
>
from mpu6050.
dtornqvist
commented on August 17, 2024
Hi again Kris,
I have updated the ICS footprint and made sure all traces are at least 8 mil. I have not connected AD0 to an edge pin yet, mostly because I would have to route it to the level converter on the left side of the board and then back to the pin on the right side again...
Please have a look, the git repo should be updated:
https://github.com/dtornqvist/icm-20948-breakout
Thanks!
from mpu6050.
kriswiner
commented on August 17, 2024
Much better!
I have some further recommandations.
First required.
Place a ground plane cutout on the bottom side underneath the ICM package;
no copper beneath the package is the goal.
Increase the width of the ground planes to 10 mil and de-select thermals,
not required here.
Add silkscreen labels to denote PTH function.
I would also move the cap pair closer to the ICM.
Desired (these are my aesthetic preferences, no required for proper
function).
You have the separation between PTH headers at 0.6 inches, but many dev
boards (like the Teensy, for example) use a 0.7 inch separation. So your
chouce precludes direct mounting on these boards.
There is a lot of pcb between the headers and the pcb edge. I would
minimize this such that the header silkscreen edge matched the copper edge.
of course, I would drop the header silkscreen altogether since it add
nothing to the design but unnecessarily takes up a lot of space.
I would rotate the solder jumper by 90 degrees and scoot the caps and LDO
over to the left a bit to accomodate it. Then I would try to minimize the
board height.
The other problem is that optimally the ICM would be in the center of the
board. This is not possible in this design (unless you put the translator
on the back of the board).
Select 20 mils as the mask width so the vias are covered with solder mask
so as not to expose metal.
Close the gap in the ground plan above the ICM. The ground plane should be
continuous around the circuit if possible.
Might be more but take another stab at considering these recommendations.
Kris
…On Mon, Jan 21, 2019 at 1:10 AM David ***@***.***> wrote:
Hi again Kris,
I have updated the ICS footprint and made sure all traces are at least 8
mil. I have not connected AD0 to an edge pin yet, mostly because I would
have to route it to the level converter on the left side of the board and
then back to the pin on the right side again...
Please have a look, the git repo should be updated:
https://github.com/dtornqvist/icm-20948-breakout
Thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qlabNhP3cRf6lQbwC1-4b3HosAMwks5vFYPogaJpZM4EbfGw>
.
from mpu6050.
MBurtsev
commented on August 17, 2024
Has anyone tried BNO080/085 ?
from mpu6050.
kriswiner
commented on August 17, 2024
Doesn't matter how fancy the fusion algorithm is if the underlying sensors
are crappy. And they are on the BNO055/80/85. No chance of accurate
absolute orientation estimation with this bunch...
…On Mon, Jan 21, 2019 at 3:06 PM Maksim Burtsev ***@***.***> wrote:
Has anyone tried BNO080/085 ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qqEQmZ63tQbocU05H_dtbCp-7lXLks5vFkfvgaJpZM4EbfGw>
.
from mpu6050.
MBurtsev
commented on August 17, 2024
Is it real? It costs more than its competitors. I thought it was high quality.
from mpu6050.
kriswiner
commented on August 17, 2024
Same sensors as can be found on the BMX055, not very good...
…On Mon, Jan 21, 2019 at 10:05 PM Maksim Burtsev ***@***.***> wrote:
Is it real? It costs more than its competitors. I thought it was high
quality.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qpydySqzMFHzrfCSdropaxp3F0Jpks5vFqo0gaJpZM4EbfGw>
.
from mpu6050.
dtornqvist
commented on August 17, 2024
Hi again Kris,
I have updated the board with many of your points to get better placement of the components and utilize space better, also changed to 0.7 inch width (although I realized that my teensy is in fact 0.6 wide)
After you pointed out to not route under the icm package, I read up on the Invensense guidelines. They say on p1 (Trace Routing) that "Note: For best performance, design a ground plane under the sensor to reduce PCB signal noise from the board on which the sensor is mounted." So I guess that should be there, but they also clearly point out to not have any vias or signals underneath as I had from the beginning.
I am also wondering about the thermals. I might try the soldering oven in our makerspace. If not, I will use the heatgun for the icm and hand solder the rest. Wouldn't the thermals help so I don't have to heat the whole board then?
Thanks!
David
from mpu6050.
kriswiner
commented on August 17, 2024
Hi David,
I am sorry but you are correct about the Teensy width. The PTHs are indeed
0.6 inches separation; it is the total pcb width that is 0.7 inches so my
apologies if you changed this on my recommendation.
I would pay no attention to the Invensense gidelines and keep copper
outside of the pckage area, both sides.
The thermals is a detail, choose whichever one you like but I usually go
with the choice that maximized the ground pour.
…On Tue, Jan 22, 2019 at 2:08 PM David ***@***.***> wrote:
Hi again Kris,
I have updated the board with many of your points to get better placement
of the components and utilize space better, also changed to 0.7 inch width
(although I realized that my teensy is in fact 0.6 wide)
After you pointed out to not route under the icm package, I read up on the Invensense
guidelines
<https://www.invensense.com/wp-content/uploads/2015/02/InvenSense-MEMS-Handling.pdf>.
They say on p1 (Trace Routing) that "Note: For best performance, design a
ground plane under the sensor to reduce PCB signal noise from the board on
which the sensor is mounted." So I guess that should be there, but they
also clearly point out to not have any vias or signals underneath as I had
from the beginning.
I am also wondering about the thermals. I might try the soldering oven in
our makerspace. If not, I will use the heatgun for the icm and hand solder
the rest. Wouldn't the thermals help so I don't have to heat the whole
board then?
Thanks!
David
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qlZzMzO0dcgU_B6bEydnrlKzYIGxks5vF4vRgaJpZM4EbfGw>
.
from mpu6050.
kriswiner
commented on August 17, 2024
One thing you could do on the new design is to use a 10 K pullup to 1.8 V for ADO and route the ADO to the unused pin. This way the default would be ADO==HIGH and if someone wanted to change the address, they would ground the ADO pin. This avoids mixing the power rails (as long as hte user does not apply 3V3 to the ADO pin and eliminates the need for the solder jumper, meaning you can go back to the 0.6 inch header separation.
from mpu6050.
MBurtsev
commented on August 17, 2024
It would be cool if someone had tested these sensors and made a video.
from mpu6050.
MBurtsev
commented on August 17, 2024
Need some objectivity in the estimates.
from mpu6050.
kriswiner
commented on August 17, 2024
Why don't you test them then?
…On Wed, Jan 23, 2019 at 3:09 AM Maksim Burtsev ***@***.***> wrote:
Need some objectivity in the estimates.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qm-ZqXa0eGeGVVuk1kf088CmL_VZks5vGELQgaJpZM4EbfGw>
.
from mpu6050.
dtornqvist
commented on August 17, 2024
Thanks Kris,
I went back to 0.6 inch width and removed the solder jumper. I went through the level translator with the signal so I don't need the pull-up. I also removed the ground plane under the ICM.
A question for putting it directly on a Teensy. I have a Teensy 3.6, so I was thinking I could put it so that the left pins align with pins 2-4. The right pins then align with pins 21-23 which are analog outputs. Can the board get ground and 3.3v from them? I see in the data sheet for the icm that the largest draw is 3.11mA, but I don't find if that could be supported from the Teensy analog outputs.
from mpu6050.
kriswiner
commented on August 17, 2024
Yes, all analog pins double as digital pins and you can use
digitalWrite(HIGH/LOW) as power pins up to the current limit of the NXP
chip, which is usually 20 mA per pin and total current <= 25 mA. You can
check the NXP data sheet to be sure. So the ICM should work just fine
mounted this way.. Not everyone will do this, most would use it on a
breadboard. If you are planning to sell it, that is...
On the ADO, you might want a 10K pull up/down anyway since you want the
address to default reliably to one or the other, and if you leave it
floating you force the user to supply a signal there. Not a good idea to
leave it floating since the address could end up being either, which is
annoying.
…On Wed, Jan 23, 2019 at 10:52 AM David ***@***.***> wrote:
Thanks Kris,
I went back to 0.6 inch width and removed the solder jumper. I went
through the level translator with the signal so I don't need the pull-up. I
also removed the ground plane under the ICM.
A question for putting it directly on a Teensy. I have a Teensy 3.6, so I
was thinking I could put it so that the left pins align with pins 2-4. The
right pins then align with pins 21-23 which are analog outputs. Can the
board get ground and 3.3v from them? I see in the data sheet for the icm
that the largest draw is 3.11mA, but I don't find if that could be
supported from the Teensy analog outputs.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1quHpJoyMMTOOzSaU8wTTK2oWBdScks5vGK-AgaJpZM4EbfGw>
.
from mpu6050.
dtornqvist
commented on August 17, 2024
That's great!
The data sheet for the level translator NTS0104, p17 says: "Each A port I/O has an internal 10 k pull-up resistor to VCC(A), and each B port I/O has an internal 10 k pull-up resistor to VCC(B)". Do you still think I need an extra pull-up?
I am just doing this board to learn and it has been really great with all the advice you have given! If you or someone else want to modify/sell its just to go ahead. I will make a couple myself to test using a soldering oven and to test the IMU.
Thanks!
from mpu6050.
kriswiner
commented on August 17, 2024
Probably don't need the pullup then.
I would use an NCV8170 DFN-4 LDO and probably a smaller logic level
translator for any board I would design.
I am interested to see if you can get it to work. If so, let me know.
Does the interrupt need to be on 1.8 V also? I suppose you need the
translator for this too. So four signals for translation. One reason I
don't like this chip at all...;>
…On Wed, Jan 23, 2019 at 12:24 PM David ***@***.***> wrote:
That's great!
The data sheet for the level translator NTS0104, p17
<https://www.nxp.com/docs/en/data-sheet/NTS0104.pdf> says: "Each A port
I/O has an internal 10 k pull-up resistor to VCC(A), and each B port I/O
has an internal 10 k pull-up resistor to VCC(B)". Do you still think I need
an extra pull-up?
I am just doing this board to learn and it has been really great with all
the advice you have given! If you or someone else want to modify/sell its
just to go ahead. I will make a couple myself to test using a soldering
oven and to test the IMU.
Thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qgKGLzpX7XDFOAJRMMU0EnQlQBZrks5vGMT6gaJpZM4EbfGw>
.
from mpu6050.
dtornqvist
commented on August 17, 2024
I wanted to make it as simple as possible to solder as this is the smallest thing I have ever done. I will let you know how it goes, but it might take a while before i get the cards, components and get down to the lab.
The interrupt levels seem tied to VDDIO as well, so yes very annoying chip...
from mpu6050.
dtornqvist
commented on August 17, 2024
I can happily say that the board seems to work just fine! I also made an initial version of an Android library for it, see: https://github.com/dtornqvist/icm-20948-arduino-library
Thanks for all help!
from mpu6050.
kriswiner
commented on August 17, 2024
Glad it works for you!
Maybe you can sell them now at Tindie...
…On Sat, Feb 16, 2019 at 11:31 AM David ***@***.***> wrote:
I can happily say that the board seems to work just fine! I also made an
initial version of an Android library for it, see:
https://github.com/dtornqvist/icm-20948-arduino-library
Thanks for all help!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qrsuLFWGBn6Huz0sCw90sPg0Aa1lks5vOFyLgaJpZM4EbfGw>
.
from mpu6050.
davhak
commented on August 17, 2024
Dear Kris,
Could you please share your recommendation which of the modern ST 6dof acc+gyr sensor is best to combine with ST magnetometer like LIS2MDL? Initially i was thinking to use the LSM6DSOX+LIS2MDL pair but then came across your post (https://community.st.com/s/question/0D50X0000B6Re9V/i-am-seeing-odd-current-behavior-with-the-lsm6dsox-but-not-in-lsm6dsm-due-to-int2-connection-to-slave-interrupt). ST has plenty of dev. boards with various acc+gyr and magnetometers but it is not clear which of the sensors LSM6DSM / LSM6DSOX / ISM330DHCX / LSM6DSRX / etc. serves best for new design and works best with magnetometer like LIS2MDL in the Mode 2 (i.e. when mag. is connected to acc+gyr as external sensor). Of course if the sensor has machine learning core or FSM it can be a big plus but after seeing your post at ST forum opens new questions so any suggestion from your side would be of great help.
Thanks a lot for any feedback.
from mpu6050.
kriswiner
commented on August 17, 2024
If you want absolute orientation estimation then LSM6DSM + LIS2MDL can work
<https://hackaday.com/wp-content/uploads/2019/03/hackaday_journal-gregorytomasch_kriswiner-heading_accuracy_using_mems_sensors.pdf>
very well. This is what we use. I like and have have used the LSM6DSO for
the embedded finite state machine and lower overall power usage.
I think the problem I am seeing with the LSM6DSO is due to the connection
between the LSM6DSO INT2 and the LIS2MDL INT. I redesigned this board to
disconnect the mag interrupt from the LSM6DSO (not really needed) and
pulled up LSM6DSO INT2 by a 10 or 100 K resistor (can't remember) thinking
this would eliminate the spurious current I was seeing. I haven't gone back
to test whether this is the case.
In general, I would recommend a weak pullup in LSM6DSX INT2 and notc
connecting it to the mag. Still OK to connect it to the MCU though and this
can be useful for the LSM6DSO since you can program INT1 to trigger from
the finite state machine and INT2 to trigger from embedded functions, etc.
Not sure if this answers your question. If not, please ask again.
…On Sun, Mar 29, 2020 at 3:43 AM davhak ***@***.***> wrote:
Dear Kris,
Could you please share your recommendation which of the modern ST 6dof
acc+gyr sensor is best to combine with ST magnetometer like LIS2MDL?
Initially i was thinking to use the LSM6DSOX+LIS2MDL pair but then came
across your post (
https://community.st.com/s/question/0D50X0000B6Re9V/i-am-seeing-odd-current-behavior-with-the-lsm6dsox-but-not-in-lsm6dsm-due-to-int2-connection-to-slave-interrupt).
ST has plenty of dev. boards with various acc+gyr and magnetometers but it
is not clear which of the sensors LSM6DSM / LSM6DSOX / ISM330DHCX /
LSM6DSRX / etc. serves best for new design and works best with magnetometer
like LIS2MDL in the Mode 2 (i.e. when mag. is connected to acc+gyr as
external sensor). Of course if the sensor has machine learning core or FSM
it can be a big plus but after seeing your post at ST forum opens new
questions so any suggestion from your side would be of great help.
Thanks a lot for any feedback.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTDLKVSXWTRN5EQ4CXAQADRJ4Q6TANCNFSM4BDN6GYA>
.
from mpu6050.
davhak
commented on August 17, 2024
Dear Kris,
Thanks a lot for your time, the paper and information.
Indeed, the main goal is to get the absolute orientation. Since the device is going to be powered from batter the low power usage is also of a concern. So having your recommendations in mind one could then stick with LSM6DSOX+LIS2MDL option.
Thanks again for your help!
from mpu6050.
kriswiner
commented on August 17, 2024
LSM6DSM is a very low power sensor, using 0.45 mA in normal mode, while the
LSM6DSO I believe uses 0.35 or 0.4 mA. Not too much difference.
…On Sun, Mar 29, 2020 at 12:09 PM davhak ***@***.***> wrote:
Dear Kris,
Thanks a lot for your time, the paper and information.
Indeed, the main goal is to get the absolute orientation. Since the device
is going to be powered from batter the low power usage is also of a
concern. So having your recommendations in mind one could then stick with
LSM6DSOX+LIS2MDL option.
Thanks again for your help!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTDLKUVCHQ7ALVEHFSFIN3RJ6MFHANCNFSM4BDN6GYA>
.
from mpu6050.
Related Issues (20)
- Initial accelerometer calibration HOT 46
- FIFO_R_W HOT 7
- Merge the two projects: Aritro Mukherjee and yours HOT 1
- Magnetometer calibration expected result could not achieved HOT 1
- icm 20948 wake on motion interrupt HOT 1
- Calibration question HOT 2
- How to produce the Mxy Mxz Myz point picture? HOT 6
- Using the libriary in a NUCLEO-F746ZG and MBED? HOT 1
- Not sure how to compile successfully for Teensy 4.0. HOT 1
- Calibration Function HOT 6
- offset increasing HOT 3
- who_am_i giving register giving random address HOT 1
- Madgwick Quaternions without accelerometer data HOT 3
- Question : Teensy 3.1 *2 more power than >> Stm32F401 HOT 1
- fifo_count is always 8 after 80 msec @1K hz
- Problem with continues reading FIFO HOT 2
- Good job. Is your libary maintained yet? HOT 3
- MPU6050 Calibrated Acc and Gyro in different measurement range HOT 2
- does calibrateMPU6050 method push biases to hardware register? HOT 4
- Direction for the compass inside Ublox M8N Gps. HOT 8
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from mpu6050.