search

kriswiner / MPU6050

Basic MPU6050 Arduino sketch of sensor function
716 stars 191 forks source link

LSM9DS1 vs. MPU-9250 vs. BMX055 #6

Open maziarzamani opened 9 years ago

maziarzamani commented 9 years ago

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.

saedelman commented 4 years ago

Hello Kris,

Do you license use of your Tomasch fusion algorithm (in binary or otherwise)?

Regards,

Stephan.

Stephan A. Edelman NewAce Corporation Tel: 416 848 1985 x221 Toll Free: 866 779 1518 x221 Fax: 416 479 0570

From: Kris Winer [notifications@github.com] Sent: Sunday, March 29, 2020 3:27 PM To: kriswiner/MPU6050 Cc: Stephan A. Edelman; Comment Subject: Re: [kriswiner/MPU6050] LSM9DS1 vs. MPU-9250 vs. BMX055 (#6)

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 notifications@github.com 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 https://github.com/kriswiner/MPU6050/issues/6#issuecomment-605684490, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKUVCHQ7ALVEHFSFIN3RJ6MFHANCNFSM4BDN6GYA .

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/kriswiner/MPU6050/issues/6#issuecomment-605686786, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABIBIW4LT567EFW26TSC4D3RJ6OINANCNFSM4BDN6GYA.

kriswiner commented 4 years ago

Hi Stephan,

Yes, we can either license to you for individual use for a fixed fee or license to you for inclusion in manufactured commercial products for a fixed fee plus royalty.

Please let me know what you have in mind.

Kris

On Sun, Mar 29, 2020 at 12:48 PM Stephan Edelman notifications@github.com wrote:

Hello Kris,

Do you license use of your Tomasch fusion algorithm (in binary or otherwise)?

Regards,

Stephan.

Stephan A. Edelman NewAce Corporation Tel: 416 848 1985 x221 Toll Free: 866 779 1518 x221 Fax: 416 479 0570

From: Kris Winer [notifications@github.com] Sent: Sunday, March 29, 2020 3:27 PM To: kriswiner/MPU6050 Cc: Stephan A. Edelman; Comment Subject: Re: [kriswiner/MPU6050] LSM9DS1 vs. MPU-9250 vs. BMX055 (#6)

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 notifications@github.com 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 https://github.com/kriswiner/MPU6050/issues/6#issuecomment-605684490, or unsubscribe < https://github.com/notifications/unsubscribe-auth/ABTDLKUVCHQ7ALVEHFSFIN3RJ6MFHANCNFSM4BDN6GYA

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub< https://github.com/kriswiner/MPU6050/issues/6#issuecomment-605686786>, or unsubscribe< https://github.com/notifications/unsubscribe-auth/ABIBIW4LT567EFW26TSC4D3RJ6OINANCNFSM4BDN6GYA

.

— 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-605689728, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKUEA425BNQ4UCQMM2LRJ6QXFANCNFSM4BDN6GYA .

saedelman commented 4 years ago

Hello Kris,

The ultimate goal is for inclusion in a commercial product, but we would have to ascertain whether the cost/benefit of the increased accuracy is warranted. Could you outline pricing and royalties?

Could we evaluate the performance in our setup? Could you provide a crippled version for evaluation (runtime limited binary) that we could link with our code? We're operating in a >1G environment and most fusion algorithms we have tried behaved eradically.

Regards,

Stephan.

Stephan A. Edelman NewAce Corporation Tel: 416 848 1985 x221 Toll Free: 866 779 1518 x221 Fax: 416 479 0570

From: Kris Winer [notifications@github.com] Sent: Sunday, March 29, 2020 4:09 PM To: kriswiner/MPU6050 Cc: Stephan A. Edelman; Comment Subject: Re: [kriswiner/MPU6050] LSM9DS1 vs. MPU-9250 vs. BMX055 (#6)

Hi Stephan,

Yes, we can either license to you for individual use for a fixed fee or license to you for inclusion in manufactured commercial products for a fixed fee plus royalty.

Please let me know what you have in mind.

Kris

On Sun, Mar 29, 2020 at 12:48 PM Stephan Edelman notifications@github.com wrote:

Hello Kris,

Do you license use of your Tomasch fusion algorithm (in binary or otherwise)?

Regards,

Stephan.

Stephan A. Edelman NewAce Corporation Tel: 416 848 1985 x221 Toll Free: 866 779 1518 x221 Fax: 416 479 0570

From: Kris Winer [notifications@github.com] Sent: Sunday, March 29, 2020 3:27 PM To: kriswiner/MPU6050 Cc: Stephan A. Edelman; Comment Subject: Re: [kriswiner/MPU6050] LSM9DS1 vs. MPU-9250 vs. BMX055 (#6)

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 notifications@github.com 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 https://github.com/kriswiner/MPU6050/issues/6#issuecomment-605684490, or unsubscribe < https://github.com/notifications/unsubscribe-auth/ABTDLKUVCHQ7ALVEHFSFIN3RJ6MFHANCNFSM4BDN6GYA

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub< https://github.com/kriswiner/MPU6050/issues/6#issuecomment-605686786>, or unsubscribe< https://github.com/notifications/unsubscribe-auth/ABIBIW4LT567EFW26TSC4D3RJ6OINANCNFSM4BDN6GYA

.

— 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-605689728, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKUEA425BNQ4UCQMM2LRJ6QXFANCNFSM4BDN6GYA .

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/kriswiner/MPU6050/issues/6#issuecomment-605692859, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABIBIW32CFC56G7CA7ZVC63RJ6TGLANCNFSM4BDN6GYA.

kriswiner commented 4 years ago

Best to move this doscussion to regular e-mail, I'm at tleracorp@gmail.com.

I think to start it would be best if you simply buy one of the USFS-MAX boards to test and see if the accuracy available is even in the ballpark of what your application requires. Then, if so, we could discuss a fixed fee for use of the binary firmware for evaluation in your custom firmware, and royalties for sales of commercial products using this technology.

On Sun, Mar 29, 2020 at 1:18 PM Stephan Edelman notifications@github.com wrote:

Hello Kris,

The ultimate goal is for inclusion in a commercial product, but we would have to ascertain whether the cost/benefit of the increased accuracy is warranted. Could you outline pricing and royalties?

Could we evaluate the performance in our setup? Could you provide a crippled version for evaluation (runtime limited binary) that we could link with our code? We're operating in a >1G environment and most fusion algorithms we have tried behaved eradically.

Regards,

Stephan.

Stephan A. Edelman NewAce Corporation Tel: 416 848 1985 x221 Toll Free: 866 779 1518 x221 Fax: 416 479 0570

From: Kris Winer [notifications@github.com] Sent: Sunday, March 29, 2020 4:09 PM To: kriswiner/MPU6050 Cc: Stephan A. Edelman; Comment Subject: Re: [kriswiner/MPU6050] LSM9DS1 vs. MPU-9250 vs. BMX055 (#6)

Hi Stephan,

Yes, we can either license to you for individual use for a fixed fee or license to you for inclusion in manufactured commercial products for a fixed fee plus royalty.

Please let me know what you have in mind.

Kris

On Sun, Mar 29, 2020 at 12:48 PM Stephan Edelman <notifications@github.com

wrote:

Hello Kris,

Do you license use of your Tomasch fusion algorithm (in binary or otherwise)?

Regards,

Stephan.

Stephan A. Edelman NewAce Corporation Tel: 416 848 1985 x221 Toll Free: 866 779 1518 x221 Fax: 416 479 0570

From: Kris Winer [notifications@github.com] Sent: Sunday, March 29, 2020 3:27 PM To: kriswiner/MPU6050 Cc: Stephan A. Edelman; Comment Subject: Re: [kriswiner/MPU6050] LSM9DS1 vs. MPU-9250 vs. BMX055 (#6)

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 notifications@github.com 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 <https://github.com/kriswiner/MPU6050/issues/6#issuecomment-605684490 , or unsubscribe <

https://github.com/notifications/unsubscribe-auth/ABTDLKUVCHQ7ALVEHFSFIN3RJ6MFHANCNFSM4BDN6GYA

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub< https://github.com/kriswiner/MPU6050/issues/6#issuecomment-605686786>, or unsubscribe<

https://github.com/notifications/unsubscribe-auth/ABIBIW4LT567EFW26TSC4D3RJ6OINANCNFSM4BDN6GYA

.

— 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-605689728, or unsubscribe < https://github.com/notifications/unsubscribe-auth/ABTDLKUEA425BNQ4UCQMM2LRJ6QXFANCNFSM4BDN6GYA

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub< https://github.com/kriswiner/MPU6050/issues/6#issuecomment-605692859>, or unsubscribe< https://github.com/notifications/unsubscribe-auth/ABIBIW32CFC56G7CA7ZVC63RJ6TGLANCNFSM4BDN6GYA

.

— 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-605694384, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKURX4ZR7EB74SMU4BLRJ6UJTANCNFSM4BDN6GYA .

Mattecnick commented 4 years ago

Hi, @kriswiner have you ever tried the ICM 20948, the replacement for the MPU9250 which are now "end of life" products? Have you any suggestions about them and the new 9-axis DMP they come with? thank you

kriswiner commented 4 years ago

Yes, it works well enough. The reason we don't use it is because of the split power rail. And it is not as accurate at this https://www.tindie.com/products/onehorse/max32660-motion-co-processor/.

On Tue, Apr 14, 2020 at 6:21 AM Mattecnick notifications@github.com wrote:

Hi, @kriswiner https://github.com/kriswiner have you ever tried the ICM 20948, the replacement for the MPU9250 which are now "end of life" products? Have you any suggestions about them and the new 9-axis DMP they come with? thank you

— 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-613438547, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKUGINLC5JSUU4KWNC3RMRPMNANCNFSM4BDN6GYA .

Mattecnick commented 4 years ago

what do you mean with "split power rail"? and about accuracy yes, but the ICM is too ten times cheaper and in my applicantion that counts :)

kriswiner commented 4 years ago

VDD 3.3 V, VDDIO 1.8 V

You usually get what you pay for....

On Tue, Apr 14, 2020 at 10:29 AM Mattecnick notifications@github.com wrote:

what do you mean with "split power rail"? and about accuracy yes, but the ICM is too ten times cheaper and in my applicantion that counts :)

— 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-613576287, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKSJCSVENJ3ZKEV2SFTRMSMRJANCNFSM4BDN6GYA .

Mattecnick commented 4 years ago

datasheet says that VDD is 3.3V compatible, but it's OK too to power the device with only one 1.8V source, for both VDD and VDDIO Cattura

kriswiner commented 4 years ago

true, and this is fine if your MCU is using 1.8 V in the digital domain. Most don't.

On Tue, Apr 14, 2020 at 10:40 AM Mattecnick notifications@github.com wrote:

datasheet says that VDD is 3.3V compatible, but it's OK too to power the device with only one 1.8V source, for both VDD and VDDIO [image: Cattura] https://user-images.githubusercontent.com/33390704/79256052-a6106b00-7e87-11ea-8b89-e1a6cfaf5345.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-613581382, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKXLBEVAUYWU5R3SMTDRMSNYBANCNFSM4BDN6GYA .

Mattecnick commented 4 years ago

True, but it's even true that it's enough your MCU reads 1.8v as logic 1. So, you can put the I2C pull-up to 1.8V and use the bus between the devices, and voltage dividers if you need to drive ICM pins from your MCU. As example, I'm studying a solution with ESP32 and ICM 20948 and I think it will work, taking care of those points

Il mar 14 apr 2020, 19:42 Kris Winer notifications@github.com ha scritto:

true, and this is fine if your MCU is using 1.8 V in the digital domain. Most don't.

On Tue, Apr 14, 2020 at 10:40 AM Mattecnick notifications@github.com wrote:

datasheet says that VDD is 3.3V compatible, but it's OK too to power the device with only one 1.8V source, for both VDD and VDDIO [image: Cattura] < https://user-images.githubusercontent.com/33390704/79256052-a6106b00-7e87-11ea-8b89-e1a6cfaf5345.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-613581382, or unsubscribe < https://github.com/notifications/unsubscribe-auth/ABTDLKXLBEVAUYWU5R3SMTDRMSNYBANCNFSM4BDN6GYA

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU6050/issues/6#issuecomment-613582307, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH6YA4DOYM2VWBJXKMBSCWLRMSN7JANCNFSM4BDN6GYA .

saedelman commented 4 years ago

Just use a bi-directional level shifter - TXB0104-Q1.

Regards,

Stephan.

--

Stephan A. Edelman

NewAce Corporation

Toll Free: 866 779 1518 x221

Tel: +1 416 848 1985 x221

Fax:+1 416 479 0570

From: Mattecnick [mailto:notifications@github.com] Sent: Tuesday, April 14, 2020 2:58 PM To: kriswiner/MPU6050 Cc: Stephan A. Edelman; Comment Subject: Re: [kriswiner/MPU6050] LSM9DS1 vs. MPU-9250 vs. BMX055 (#6)

True, but it's even true that it's enough your MCU reads 1.8v as logic 1. So, you can put the I2C pull-up to 1.8V and use the bus between the devices, and voltage dividers if you need to drive ICM pins from your MCU. As example, I'm studying a solution with ESP32 and ICM 20948 and I think it will work, taking care of those points

Il mar 14 apr 2020, 19:42 Kris Winer notifications@github.com ha scritto:

true, and this is fine if your MCU is using 1.8 V in the digital domain. Most don't.

On Tue, Apr 14, 2020 at 10:40 AM Mattecnick notifications@github.com wrote:

datasheet says that VDD is 3.3V compatible, but it's OK too to power the device with only one 1.8V source, for both VDD and VDDIO [image: Cattura] < https://user-images.githubusercontent.com/33390704/79256052-a6106b00-7e87-11ea-8b89-e1a6cfaf5345.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-613581382, or unsubscribe < https://github.com/notifications/unsubscribe-auth/ABTDLKXLBEVAUYWU5R3SMTDRMSNYBANCNFSM4BDN6GYA

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU6050/issues/6#issuecomment-613582307, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH6YA4DOYM2VWBJXKMBSCWLRMSN7JANCNFSM4BDN6GYA .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU6050/issues/6#issuecomment-613622252 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIBIW5ECMDXAN4YGNKOCJDRMSW3BANCNFSM4BDN6GYA .Image removed by sender.

kriswiner commented 4 years ago

The split rail is not a show stopper, just inconvenient and requires extra design considerations/components to make it work. There are plenty of other reasons not to use the ICM20948, but it can be a pretty good solution for some applications and if you can get a breakout board for $5 then this is probably the best way to go.

On Tue, Apr 14, 2020 at 12:07 PM Stephan Edelman notifications@github.com wrote:

Just use a bi-directional level shifter - TXB0104-Q1.

Regards,

Stephan.

--

Stephan A. Edelman

NewAce Corporation

Toll Free: 866 779 1518 x221

Tel: +1 416 848 1985 x221

Fax:+1 416 479 0570

From: Mattecnick [mailto:notifications@github.com] Sent: Tuesday, April 14, 2020 2:58 PM To: kriswiner/MPU6050 Cc: Stephan A. Edelman; Comment Subject: Re: [kriswiner/MPU6050] LSM9DS1 vs. MPU-9250 vs. BMX055 (#6)

True, but it's even true that it's enough your MCU reads 1.8v as logic 1. So, you can put the I2C pull-up to 1.8V and use the bus between the devices, and voltage dividers if you need to drive ICM pins from your MCU. As example, I'm studying a solution with ESP32 and ICM 20948 and I think it will work, taking care of those points

Il mar 14 apr 2020, 19:42 Kris Winer notifications@github.com ha scritto:

true, and this is fine if your MCU is using 1.8 V in the digital domain. Most don't.

On Tue, Apr 14, 2020 at 10:40 AM Mattecnick notifications@github.com wrote:

datasheet says that VDD is 3.3V compatible, but it's OK too to power the device with only one 1.8V source, for both VDD and VDDIO [image: Cattura] <

https://user-images.githubusercontent.com/33390704/79256052-a6106b00-7e87-11ea-8b89-e1a6cfaf5345.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-613581382 , or unsubscribe <

https://github.com/notifications/unsubscribe-auth/ABTDLKXLBEVAUYWU5R3SMTDRMSNYBANCNFSM4BDN6GYA

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU6050/issues/6#issuecomment-613582307, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AH6YA4DOYM2VWBJXKMBSCWLRMSN7JANCNFSM4BDN6GYA

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU6050/issues/6#issuecomment-613622252> , or unsubscribe < https://github.com/notifications/unsubscribe-auth/ABIBIW5ECMDXAN4YGNKOCJDRMSW3BANCNFSM4BDN6GYA> .Image removed by sender.

— 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-613627260, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKWEZ436BSG6B4QNJD3RMSX6RANCNFSM4BDN6GYA .

Mattecnick commented 4 years ago

I'm curious about the other reasons you mentioned... Can you please tell me the most relevant?

Il giorno mar 14 apr 2020 alle ore 21:11 Kris Winer < notifications@github.com> ha scritto:

The split rail is not a show stopper, just inconvenient and requires extra design considerations/components to make it work. There are plenty of other reasons not to use the ICM20948, but it can be a pretty good solution for some applications and if you can get a breakout board for $5 then this is probably the best way to go.

On Tue, Apr 14, 2020 at 12:07 PM Stephan Edelman <notifications@github.com

wrote:

Just use a bi-directional level shifter - TXB0104-Q1.

Regards,

Stephan.

--

Stephan A. Edelman

NewAce Corporation

Toll Free: 866 779 1518 x221

Tel: +1 416 848 1985 x221

Fax:+1 416 479 0570

From: Mattecnick [mailto:notifications@github.com] Sent: Tuesday, April 14, 2020 2:58 PM To: kriswiner/MPU6050 Cc: Stephan A. Edelman; Comment Subject: Re: [kriswiner/MPU6050] LSM9DS1 vs. MPU-9250 vs. BMX055 (#6)

True, but it's even true that it's enough your MCU reads 1.8v as logic 1. So, you can put the I2C pull-up to 1.8V and use the bus between the devices, and voltage dividers if you need to drive ICM pins from your MCU. As example, I'm studying a solution with ESP32 and ICM 20948 and I think it will work, taking care of those points

Il mar 14 apr 2020, 19:42 Kris Winer notifications@github.com ha scritto:

true, and this is fine if your MCU is using 1.8 V in the digital domain. Most don't.

On Tue, Apr 14, 2020 at 10:40 AM Mattecnick notifications@github.com wrote:

datasheet says that VDD is 3.3V compatible, but it's OK too to power the device with only one 1.8V source, for both VDD and VDDIO [image: Cattura] <

https://user-images.githubusercontent.com/33390704/79256052-a6106b00-7e87-11ea-8b89-e1a6cfaf5345.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-613581382 , or unsubscribe <

https://github.com/notifications/unsubscribe-auth/ABTDLKXLBEVAUYWU5R3SMTDRMSNYBANCNFSM4BDN6GYA

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/kriswiner/MPU6050/issues/6#issuecomment-613582307 , or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AH6YA4DOYM2VWBJXKMBSCWLRMSN7JANCNFSM4BDN6GYA

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU6050/issues/6#issuecomment-613622252> , or unsubscribe <

https://github.com/notifications/unsubscribe-auth/ABIBIW5ECMDXAN4YGNKOCJDRMSW3BANCNFSM4BDN6GYA

.Image removed by sender.

— 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-613627260, or unsubscribe < https://github.com/notifications/unsubscribe-auth/ABTDLKWEZ436BSG6B4QNJD3RMSX6RANCNFSM4BDN6GYA

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU6050/issues/6#issuecomment-613629452, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH6YA4B4K3ZEYDIJDIFRHH3RMSYORANCNFSM4BDN6GYA .

kriswiner commented 4 years ago

black box, limited rate, limited accuracy

On Tue, Apr 14, 2020 at 1:52 PM Mattecnick notifications@github.com wrote:

I'm curious about the other reasons you mentioned... Can you please tell me the most relevant?

Il giorno mar 14 apr 2020 alle ore 21:11 Kris Winer < notifications@github.com> ha scritto:

The split rail is not a show stopper, just inconvenient and requires extra design considerations/components to make it work. There are plenty of other reasons not to use the ICM20948, but it can be a pretty good solution for some applications and if you can get a breakout board for $5 then this is probably the best way to go.

On Tue, Apr 14, 2020 at 12:07 PM Stephan Edelman < notifications@github.com

wrote:

Just use a bi-directional level shifter - TXB0104-Q1.

Regards,

Stephan.

--

Stephan A. Edelman

NewAce Corporation

Toll Free: 866 779 1518 x221

Tel: +1 416 848 1985 x221

Fax:+1 416 479 0570

From: Mattecnick [mailto:notifications@github.com] Sent: Tuesday, April 14, 2020 2:58 PM To: kriswiner/MPU6050 Cc: Stephan A. Edelman; Comment Subject: Re: [kriswiner/MPU6050] LSM9DS1 vs. MPU-9250 vs. BMX055 (#6)

True, but it's even true that it's enough your MCU reads 1.8v as logic 1. So, you can put the I2C pull-up to 1.8V and use the bus between the devices, and voltage dividers if you need to drive ICM pins from your MCU. As example, I'm studying a solution with ESP32 and ICM 20948 and I think it will work, taking care of those points

Il mar 14 apr 2020, 19:42 Kris Winer notifications@github.com ha scritto:

true, and this is fine if your MCU is using 1.8 V in the digital domain. Most don't.

On Tue, Apr 14, 2020 at 10:40 AM Mattecnick < notifications@github.com> wrote:

datasheet says that VDD is 3.3V compatible, but it's OK too to power the device with only one 1.8V source, for both VDD and VDDIO [image: Cattura] <

https://user-images.githubusercontent.com/33390704/79256052-a6106b00-7e87-11ea-8b89-e1a6cfaf5345.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-613581382 , or unsubscribe <

https://github.com/notifications/unsubscribe-auth/ABTDLKXLBEVAUYWU5R3SMTDRMSNYBANCNFSM4BDN6GYA

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU6050/issues/6#issuecomment-613582307 , or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AH6YA4DOYM2VWBJXKMBSCWLRMSN7JANCNFSM4BDN6GYA

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU6050/issues/6#issuecomment-613622252> , or unsubscribe <

https://github.com/notifications/unsubscribe-auth/ABIBIW5ECMDXAN4YGNKOCJDRMSW3BANCNFSM4BDN6GYA

.Image removed by sender.

— 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-613627260 , or unsubscribe <

https://github.com/notifications/unsubscribe-auth/ABTDLKWEZ436BSG6B4QNJD3RMSX6RANCNFSM4BDN6GYA

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU6050/issues/6#issuecomment-613629452, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AH6YA4B4K3ZEYDIJDIFRHH3RMSYORANCNFSM4BDN6GYA

.

— 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-613675521, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKTPZ67ETCTYB4VNI7LRMTEKBANCNFSM4BDN6GYA .

SoulPedal commented 4 years ago

I'm in the same boat with our 9250. Power is critical for my units, cost not so much at this stage. I've had to hand solder a few of those along with an older one from micro and they are difficult, even for pick and place automation sometimes. I keep my thermals as an epoxy covered ground plane under the package, so no contact. Maybe it's the process IDK.
My motion algorithm essentially is 6 axis, in fact, magnets are my enemy so gyro/accel stability is important, (but not landing rockets either). I have on occasion watched gyro data before and after calibration, and have a sense for a very slight variation just a couple bits wide. Could be environment IDK.

Anyway, I didn't mean to hijack this post, I'm a bit new to Github really but I have some help now. But it's the same question really. I'd love some high level advice on my situation. I also have to be careful in the math load for now. My processor doesn't have floating point, so for example I have an aTan function using a fixed floating point algorithm and that alone takes 850 uS. The integration functions are likely similar in load, but that's enough time and becomes the CPU's main chore so to speak on minimal power. I've changed update rates on the fly for even more power savings, as was an agreed possible strategy confirmed by Karthik Katingari, Software Director at Invensense during my visit I think it was 2018? I wonder if you were there at TDK in San Jose? I never even thought to ask!

Thanks!

SoulPedal commented 4 years ago

Speaking of rockets, I got a note from someone recently that Invensense is involved in SpaceX. Do you know what Elon's using there? They probably just collect raw data and do their own Fusion as well. The precision would have to be insanely tight! So I'd consider what they're using in this decision actually. Elon anything turns to gold.

kriswiner commented 4 years ago

Sounds like you could use a motion co-processor to take the load off your host MCU. You could start here https://github.com/kriswiner/EM7180_SENtral_sensor_hub/wiki.

On Fri, Apr 17, 2020 at 10:35 AM 215 notifications@github.com wrote:

I'm in the same boat with our 9250. Power is critical for my units, cost not so much at this stage. I've had to hand solder a few of those along with an older one from micro and they are difficult, even for pick and place automation sometimes. I keep my thermals as an epoxy covered ground plane under the package, so no contact. Maybe it's the process IDK. My motion algorithm essentially is 6 axis, in fact, magnets are my enemy so gyro/accel stability is important, (but not landing rockets either). I have on occasion watched gyro data before and after calibration, and have a sense for a very slight variation just a couple bits wide. Could be environment IDK.

Anyway, I didn't mean to hijack this post, I'm a bit new to Github really but I have some help now. But it's the same question really. I'd love some high level advice on my situation. I also have to be careful in the math load for now. My processor doesn't have floating point, so for example I have an aTan function using a fixed floating point algorithm and that alone takes 850 uS. The integration functions are likely similar in load, but that's enough time and becomes the CPU's main chore so to speak on minimal power. I've changed update rates on the fly for even more power savings, as was an agreed possible strategy confirmed by Karthik Katingari, Software Director at Invensense during my visit I think it was 2018? I wonder if you were there at TDK in San Jose? I never even thought to ask!

Thanks!

— 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-615373938, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKTV2ECYPBZUF4QFDQTRNCHOPANCNFSM4BDN6GYA .

solisqq commented 4 years ago

What do you think about BMI088? Most of DIY multirotors use MPU6050, but BMI088 seems like a good choice on paper. It has by default Butterworth low pass which ive used previously with MPU. Not sure what kind of low pass comes with MPU by default. For me the best choice was to avoid default LP and do LP filtering on external uC. Ive bought BMI088 but didnt test it yet. Its labeled as for multirotors purpose, but is it really better choice over MPU6050?

kriswiner commented 4 years ago

The MPU6050 (acc/gyro) was obsoleted years ago by Invensense' own MPU6500, and the MPU9250 (MPU6500 + AK8963) was the standard for quite a while in accurate 9 DoF IMUs. However, the MPU9250 is not a low power sensor (by today's standards, although this is immaterial for UAVs) and is no longer in production.

The Bosch IMUs have not performed well in the past compared to the MPU9250 (BMX050 and BNO055) so I generally don't bother testing them these days. I am not against Bosch sensors per se, I use their BME280 and BMA400 for wake-on-motion applications in a lot of products. It's just that their IMUs are so-so and their magnetometers are not very good.

If the BMI088 still uses a Hall sensor magnetometer I wouldn't bother with it, standard today is magnetorestance films not Hall sensors.

I have found the LSM6DSM + LIS2MDL to be an excellent replacement for the MPU9250, albeit in two sensor packages rather than one. It is a low-power sensor suite, which is great for wearable applications, but the sensors are superb with low jitter (better than the MPU9250 sensors), support high sample rates, and with proper calibration can achieve absolute heading accuracy of < 1 degree and rms heading errors less than 0.5 degrees routinely https://www.tindie.com/products/onehorse/max32660-motion-co-processor/. See also here https://hackaday.com/wp-content/uploads/2019/03/hackaday_journal-gregorytomasch_kriswiner-heading_accuracy_using_mems_sensors.pdf and here https://hackaday.io/project/160283-max32660-motion-co-processor.

Maybe the BMI088 can also do as much, but I won't waste my time finding out. I suggest you test your BMI088 against an MPU9250 and see how it performs yourself. I would be interested to learn what you find out....

On Fri, May 29, 2020 at 3:08 AM solisqq notifications@github.com wrote:

What do you think about BMI088? Most of DIY multirotors use MPU9250/MPU6050, but BMI088 seems like a good choice on paper. It has by default Butterworth low pass which ive used previously with MPU. Not sure what kind of low pass comes with MPU by default. For me the best choice was to avoid default LP and do LP filtering on external uC. Ive bought BMI088 but didnt test it yet. Its labeled as for multirotors purpose, but is it really better choice over MPU6050?

— 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-635891051, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKRCS5M3VDWHY4AICU3RT6CRZANCNFSM4BDN6GYA .

solisqq commented 4 years ago

Ive tested Pololu Altimu-10 v5 (LSM6DSM+LIS2MDL+LPS25H) about 2 years ago. IMO it was a good 9-DOF and as youve written - excellent replacement for the MPU9250. Ive really enjoyed high ODR of the accelerometer, but gyro was a bit off from the MPU one. If I could I would use LSM6DSM acc and MPU6050 gyro for multirotor purpose. But I've had to choose between them and as it comes for multirotors bettery gyro is the only way (ofc. in my opinion)...

As it comes to BMI088 - on the beginning I was really dissatisfied that I cant get raw data. Everything was passed by Butterworths LP at max. 2kHz. It would be fine if it was 4th order filtering (which Ive tested is the best for my purpose), but as I suspect its only 2nd order filtering. So I had to do filtering on my uC anyway, BUT.... Ive noticed that BMI088 is a bit more robustness to vibrations. Like if it had some mechanical damping built in. Ofcourse it is disadvantage at some point (higher response time), but it had still better timing than digital filtering that Ive used with MPU at higher ODR.

I will test it over this weekend or next one and give feedback :). Thank you for your response.

vikrantsingh47 commented 4 years ago

The MPU6050 (acc/gyro) was obsoleted years ago by Invensense' own MPU6500, and the MPU9250 (MPU6500 + AK8963) was the standard for quite a while in accurate 9 DoF IMUs. However, the MPU9250 is not a low power sensor (by today's standards, although this is immaterial for UAVs) and is no longer in production. The Bosch IMUs have not performed well in the past compared to the MPU9250 (BMX050 and BNO055) so I generally don't bother testing them these days. I am not against Bosch sensors per se, I use their BME280 and BMA400 for wake-on-motion applications in a lot of products. It's just that their IMUs are so-so and their magnetometers are not very good. If the BMI088 still uses a Hall sensor magnetometer I wouldn't bother with it, standard today is magnetorestance films not Hall sensors. I have found the LSM6DSM + LIS2MDL to be an excellent replacement for the MPU9250, albeit in two sensor packages rather than one. It is a low-power sensor suite, which is great for wearable applications, but the sensors are superb with low jitter (better than the MPU9250 sensors), support high sample rates, and with proper calibration can achieve absolute heading accuracy of < 1 degree and rms heading errors less than 0.5 degrees routinely https://www.tindie.com/products/onehorse/max32660-motion-co-processor/. See also here https://hackaday.com/wp-content/uploads/2019/03/hackaday_journal-gregorytomasch_kriswiner-heading_accuracy_using_mems_sensors.pdf and here https://hackaday.io/project/160283-max32660-motion-co-processor. Maybe the BMI088 can also do as much, but I won't waste my time finding out. I suggest you test your BMI088 against an MPU9250 and see how it performs yourself. I would be interested to learn what you find out.... … On Fri, May 29, 2020 at 3:08 AM solisqq @.***> wrote: What do you think about BMI088? Most of DIY multirotors use MPU9250/MPU6050, but BMI088 seems like a good choice on paper. It has by default Butterworth low pass which ive used previously with MPU. Not sure what kind of low pass comes with MPU by default. For me the best choice was to avoid default LP and do LP filtering on external uC. Ive bought BMI088 but didnt test it yet. Its labeled as for multirotors purpose, but is it really better choice over MPU6050? — 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/ABTDLKRCS5M3VDWHY4AICU3RT6CRZANCNFSM4BDN6GYA .

how is LSM9DS1 compared to LSM6DSM + LIS2MDL ?

kriswiner commented 4 years ago

not very good...

On Sun, Jun 21, 2020 at 11:51 AM vikrant singh notifications@github.com wrote:

The MPU6050 (acc/gyro) was obsoleted years ago by Invensense' own MPU6500, and the MPU9250 (MPU6500 + AK8963) was the standard for quite a while in accurate 9 DoF IMUs. However, the MPU9250 is not a low power sensor (by today's standards, although this is immaterial for UAVs) and is no longer in production. The Bosch IMUs have not performed well in the past compared to the MPU9250 (BMX050 and BNO055) so I generally don't bother testing them these days. I am not against Bosch sensors per se, I use their BME280 and BMA400 for wake-on-motion applications in a lot of products. It's just that their IMUs are so-so and their magnetometers are not very good. If the BMI088 still uses a Hall sensor magnetometer I wouldn't bother with it, standard today is magnetorestance films not Hall sensors. I have found the LSM6DSM + LIS2MDL to be an excellent replacement for the MPU9250, albeit in two sensor packages rather than one. It is a low-power sensor suite, which is great for wearable applications, but the sensors are superb with low jitter (better than the MPU9250 sensors), support high sample rates, and with proper calibration can achieve absolute heading accuracy of < 1 degree and rms heading errors less than 0.5 degrees routinely https://www.tindie.com/products/onehorse/max32660-motion-co-processor/. See also here https://hackaday.com/wp-content/uploads/2019/03/hackaday_journal-gregorytomasch_kriswiner-heading_accuracy_using_mems_sensors.pdf and here https://hackaday.io/project/160283-max32660-motion-co-processor. Maybe the BMI088 can also do as much, but I won't waste my time finding out. I suggest you test your BMI088 against an MPU9250 and see how it performs yourself. I would be interested to learn what you find out.... … <#m-4840088335655213634> On Fri, May 29, 2020 at 3:08 AM solisqq @.***> wrote: What do you think about BMI088? Most of DIY multirotors use MPU9250/MPU6050, but BMI088 seems like a good choice on paper. It has by default Butterworth low pass which ive used previously with MPU. Not sure what kind of low pass comes with MPU by default. For me the best choice was to avoid default LP and do LP filtering on external uC. Ive bought BMI088 but didnt test it yet. Its labeled as for multirotors purpose, but is it really better choice over MPU6050? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6 (comment) https://github.com/kriswiner/MPU6050/issues/6#issuecomment-635891051>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKRCS5M3VDWHY4AICU3RT6CRZANCNFSM4BDN6GYA .

how is LSM9DS1 compared to LSM6DSM + LIS2MDL ?

— 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-647166543, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKTR3DNN7GCKLD5HKNDRXZJDNANCNFSM4BDN6GYA .

vikrantsingh47 commented 4 years ago

not very good... On Sun, Jun 21, 2020 at 11:51 AM vikrant singh notifications@github.com wrote: … The MPU6050 (acc/gyro) was obsoleted years ago by Invensense' own MPU6500, and the MPU9250 (MPU6500 + AK8963) was the standard for quite a while in accurate 9 DoF IMUs. However, the MPU9250 is not a low power sensor (by today's standards, although this is immaterial for UAVs) and is no longer in production. The Bosch IMUs have not performed well in the past compared to the MPU9250 (BMX050 and BNO055) so I generally don't bother testing them these days. I am not against Bosch sensors per se, I use their BME280 and BMA400 for wake-on-motion applications in a lot of products. It's just that their IMUs are so-so and their magnetometers are not very good. If the BMI088 still uses a Hall sensor magnetometer I wouldn't bother with it, standard today is magnetorestance films not Hall sensors. I have found the LSM6DSM + LIS2MDL to be an excellent replacement for the MPU9250, albeit in two sensor packages rather than one. It is a low-power sensor suite, which is great for wearable applications, but the sensors are superb with low jitter (better than the MPU9250 sensors), support high sample rates, and with proper calibration can achieve absolute heading accuracy of < 1 degree and rms heading errors less than 0.5 degrees routinely https://www.tindie.com/products/onehorse/max32660-motion-co-processor/. See also here https://hackaday.com/wp-content/uploads/2019/03/hackaday_journal-gregorytomasch_kriswiner-heading_accuracy_using_mems_sensors.pdf and here https://hackaday.io/project/160283-max32660-motion-co-processor. Maybe the BMI088 can also do as much, but I won't waste my time finding out. I suggest you test your BMI088 against an MPU9250 and see how it performs yourself. I would be interested to learn what you find out.... … <#m-4840088335655213634> On Fri, May 29, 2020 at 3:08 AM solisqq @.***> wrote: What do you think about BMI088? Most of DIY multirotors use MPU9250/MPU6050, but BMI088 seems like a good choice on paper. It has by default Butterworth low pass which ive used previously with MPU. Not sure what kind of low pass comes with MPU by default. For me the best choice was to avoid default LP and do LP filtering on external uC. Ive bought BMI088 but didnt test it yet. Its labeled as for multirotors purpose, but is it really better choice over MPU6050? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6 (comment) <#6 (comment)>>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKRCS5M3VDWHY4AICU3RT6CRZANCNFSM4BDN6GYA . how is LSM9DS1 compared to LSM6DSM + LIS2MDL ? — 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/ABTDLKTR3DNN7GCKLD5HKNDRXZJDNANCNFSM4BDN6GYA .

any particular reasons for that? i am looking to make a drone using stm32h7

kriswiner commented 4 years ago

Test data shows there is a reason ST designed the LSM6DSM and LIS2MDL. So:

1) LSMDS1 is old tech 2) poor measured results compared to LSM6DSM + LIS2MDL 3) LIS2MDL uses AMR layer not Hall sensors, far superior

On Sun, Jun 21, 2020 at 12:18 PM vikrant singh notifications@github.com wrote:

not very good... On Sun, Jun 21, 2020 at 11:51 AM vikrant singh notifications@github.com wrote: … <#m8456526962740247451> The MPU6050 (acc/gyro) was obsoleted years ago by Invensense' own MPU6500, and the MPU9250 (MPU6500 + AK8963) was the standard for quite a while in accurate 9 DoF IMUs. However, the MPU9250 is not a low power sensor (by today's standards, although this is immaterial for UAVs) and is no longer in production. The Bosch IMUs have not performed well in the past compared to the MPU9250 (BMX050 and BNO055) so I generally don't bother testing them these days. I am not against Bosch sensors per se, I use their BME280 and BMA400 for wake-on-motion applications in a lot of products. It's just that their IMUs are so-so and their magnetometers are not very good. If the BMI088 still uses a Hall sensor magnetometer I wouldn't bother with it, standard today is magnetorestance films not Hall sensors. I have found the LSM6DSM + LIS2MDL to be an excellent replacement for the MPU9250, albeit in two sensor packages rather than one. It is a low-power sensor suite, which is great for wearable applications, but the sensors are superb with low jitter (better than the MPU9250 sensors), support high sample rates, and with proper calibration can achieve absolute heading accuracy of < 1 degree and rms heading errors less than 0.5 degrees routinely https://www.tindie.com/products/onehorse/max32660-motion-co-processor/. See also here https://hackaday.com/wp-content/uploads/2019/03/hackaday_journal-gregorytomasch_kriswiner-heading_accuracy_using_mems_sensors.pdf and here https://hackaday.io/project/160283-max32660-motion-co-processor. Maybe the BMI088 can also do as much, but I won't waste my time finding out. I suggest you test your BMI088 against an MPU9250 and see how it performs yourself. I would be interested to learn what you find out.... … <#m-4840088335655213634> On Fri, May 29, 2020 at 3:08 AM solisqq @.***> wrote: What do you think about BMI088? Most of DIY multirotors use MPU9250/MPU6050, but BMI088 seems like a good choice on paper. It has by default Butterworth low pass which ive used previously with MPU. Not sure what kind of low pass comes with MPU by default. For me the best choice was to avoid default LP and do LP filtering on external uC. Ive bought BMI088 but didnt test it yet. Its labeled as for multirotors purpose, but is it really better choice over MPU6050? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6 https://github.com/kriswiner/MPU6050/issues/6 (comment) <#6 (comment) https://github.com/kriswiner/MPU6050/issues/6#issuecomment-635891051>>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKRCS5M3VDWHY4AICU3RT6CRZANCNFSM4BDN6GYA . how is LSM9DS1 compared to LSM6DSM + LIS2MDL ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6 (comment) https://github.com/kriswiner/MPU6050/issues/6#issuecomment-647166543>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKTR3DNN7GCKLD5HKNDRXZJDNANCNFSM4BDN6GYA .

any particular reasons for that? i am looking to make a drone using stm32h7

— 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-647169523, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKSU5SRB6MK54V7T7FTRXZMIDANCNFSM4BDN6GYA .

vikrantsingh47 commented 4 years ago

Test data shows there is a reason ST designed the LSM6DSM and LIS2MDL. So: 1) LSMDS1 is old tech 2) poor measured results compared to LSM6DSM + LIS2MDL 3) LIS2MDL uses AMR layer not Hall sensors, far superior On Sun, Jun 21, 2020 at 12:18 PM vikrant singh notifications@github.com wrote: … not very good... On Sun, Jun 21, 2020 at 11:51 AM vikrant singh @. wrote: … <#m8456526962740247451> The MPU6050 (acc/gyro) was obsoleted years ago by Invensense' own MPU6500, and the MPU9250 (MPU6500 + AK8963) was the standard for quite a while in accurate 9 DoF IMUs. However, the MPU9250 is not a low power sensor (by today's standards, although this is immaterial for UAVs) and is no longer in production. The Bosch IMUs have not performed well in the past compared to the MPU9250 (BMX050 and BNO055) so I generally don't bother testing them these days. I am not against Bosch sensors per se, I use their BME280 and BMA400 for wake-on-motion applications in a lot of products. It's just that their IMUs are so-so and their magnetometers are not very good. If the BMI088 still uses a Hall sensor magnetometer I wouldn't bother with it, standard today is magnetorestance films not Hall sensors. I have found the LSM6DSM + LIS2MDL to be an excellent replacement for the MPU9250, albeit in two sensor packages rather than one. It is a low-power sensor suite, which is great for wearable applications, but the sensors are superb with low jitter (better than the MPU9250 sensors), support high sample rates, and with proper calibration can achieve absolute heading accuracy of < 1 degree and rms heading errors less than 0.5 degrees routinely https://www.tindie.com/products/onehorse/max32660-motion-co-processor/. See also here https://hackaday.com/wp-content/uploads/2019/03/hackaday_journal-gregorytomasch_kriswiner-heading_accuracy_using_mems_sensors.pdf and here https://hackaday.io/project/160283-max32660-motion-co-processor. Maybe the BMI088 can also do as much, but I won't waste my time finding out. I suggest you test your BMI088 against an MPU9250 and see how it performs yourself. I would be interested to learn what you find out.... … <#m-4840088335655213634> On Fri, May 29, 2020 at 3:08 AM solisqq @.> wrote: What do you think about BMI088? Most of DIY multirotors use MPU9250/MPU6050, but BMI088 seems like a good choice on paper. It has by default Butterworth low pass which ive used previously with MPU. Not sure what kind of low pass comes with MPU by default. For me the best choice was to avoid default LP and do LP filtering on external uC. Ive bought BMI088 but didnt test it yet. Its labeled as for multirotors purpose, but is it really better choice over MPU6050? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6 <#6> (comment) <#6 (comment) <#6 (comment)>>>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKRCS5M3VDWHY4AICU3RT6CRZANCNFSM4BDN6GYA . how is LSM9DS1 compared to LSM6DSM + LIS2MDL ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6 (comment) <#6 (comment)>>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKTR3DNN7GCKLD5HKNDRXZJDNANCNFSM4BDN6GYA . any particular reasons for that? i am looking to make a drone using stm32h7 — 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/ABTDLKSU5SRB6MK54V7T7FTRXZMIDANCNFSM4BDN6GYA .

thanks for the response. would you know what protocol LSM6DSM + LIS2MDL would use, as opposed to LSM9DS1, for connecting to a mcu like stm32h7?

kriswiner commented 4 years ago

Same, either SPI or I2C.

On Mon, Jun 29, 2020 at 10:41 AM vikrant singh notifications@github.com wrote:

Test data shows there is a reason ST designed the LSM6DSM and LIS2MDL. So: 1) LSMDS1 is old tech 2) poor measured results compared to LSM6DSM + LIS2MDL 3) LIS2MDL uses AMR layer not Hall sensors, far superior On Sun, Jun 21, 2020 at 12:18 PM vikrant singh notifications@github.com wrote: … <#m-1557585830512243487> not very good... On Sun, Jun 21, 2020 at 11:51 AM vikrant singh @. wrote: … <#m8456526962740247451> The MPU6050 (acc/gyro) was obsoleted years ago by Invensense' own MPU6500, and the MPU9250 (MPU6500 + AK8963) was the standard for quite a while in accurate 9 DoF IMUs. However, the MPU9250 is not a low power sensor (by today's standards, although this is immaterial for UAVs) and is no longer in production. The Bosch IMUs have not performed well in the past compared to the MPU9250 (BMX050 and BNO055) so I generally don't bother testing them these days. I am not against Bosch sensors per se, I use their BME280 and BMA400 for wake-on-motion applications in a lot of products. It's just that their IMUs are so-so and their magnetometers are not very good. If the BMI088 still uses a Hall sensor magnetometer I wouldn't bother with it, standard today is magnetorestance films not Hall sensors. I have found the LSM6DSM + LIS2MDL to be an excellent replacement for the MPU9250, albeit in two sensor packages rather than one. It is a low-power sensor suite, which is great for wearable applications, but the sensors are superb with low jitter (better than the MPU9250 sensors), support high sample rates, and with proper calibration can achieve absolute heading accuracy of < 1 degree and rms heading errors less than 0.5 degrees routinely https://www.tindie.com/products/onehorse/max32660-motion-co-processor/. See also here https://hackaday.com/wp-content/uploads/2019/03/hackaday_journal-gregorytomasch_kriswiner-heading_accuracy_using_mems_sensors.pdf and here https://hackaday.io/project/160283-max32660-motion-co-processor. Maybe the BMI088 can also do as much, but I won't waste my time finding out. I suggest you test your BMI088 against an MPU9250 and see how it performs yourself. I would be interested to learn what you find out.... … <#m-4840088335655213634> On Fri, May 29, 2020 at 3:08 AM solisqq @.> wrote: What do you think about BMI088? Most of DIY multirotors use MPU9250/MPU6050, but BMI088 seems like a good choice on paper. It has by default Butterworth low pass which ive used previously with MPU. Not sure what kind of low pass comes with MPU by default. For me the best choice was to avoid default LP and do LP filtering on external uC. Ive bought BMI088 but didnt test it yet. Its labeled as for multirotors purpose, but is it really better choice over MPU6050? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6 https://github.com/kriswiner/MPU6050/issues/6 <#6 https://github.com/kriswiner/MPU6050/issues/6> (comment) <#6 https://github.com/kriswiner/MPU6050/issues/6 (comment) <#6 (comment) https://github.com/kriswiner/MPU6050/issues/6#issuecomment-635891051>>>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKRCS5M3VDWHY4AICU3RT6CRZANCNFSM4BDN6GYA . how is LSM9DS1 compared to LSM6DSM + LIS2MDL ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6 https://github.com/kriswiner/MPU6050/issues/6 (comment) <#6 (comment) https://github.com/kriswiner/MPU6050/issues/6#issuecomment-647166543>>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKTR3DNN7GCKLD5HKNDRXZJDNANCNFSM4BDN6GYA . any particular reasons for that? i am looking to make a drone using stm32h7 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6 (comment) https://github.com/kriswiner/MPU6050/issues/6#issuecomment-647169523>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKSU5SRB6MK54V7T7FTRXZMIDANCNFSM4BDN6GYA .

thanks for the response. would you know what protocol LSM6DSM + LIS2MDL would use, as opposed to LSM9DS1, for connecting to a mcu like stm32h7?

— 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-651264129, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKVEBUXCN6Q2POH6K4DRZDG5LANCNFSM4BDN6GYA .

kriswiner commented 3 years ago

It is way old and superseded by the LIS2MDL.

On Sun, Jul 26, 2020 at 12:45 PM oziqus notifications@github.com wrote:

why no one mentions here e.g. about lms303ah? after all, it is mainly about magnetometers?

— 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-664031895, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKRTHZFAHIBQN6BZVJLR5SBV3ANCNFSM4BDN6GYA .

Benik3 commented 3 years ago

Hello Kris.
It's very informative to read this topic and there is really LOT of information about each IC.
Didn't you think about making some simple table with ICs which you tested or which people asking, with some simple info like "not good, better use this", "good at this, but worse at this"...
Maybe it will help people to choose without keeping asking here and if someone will ask about new IC, it can be then added to the table.

kriswiner commented 3 years ago

I don't think this is necessary. For all applications there is really nothing better than the LSM6DSM and LIS2MDL right now. That could always change, but this choice is a safe one...

On Sun, Jul 26, 2020 at 1:16 PM Benik3 notifications@github.com wrote:

Hello Kris. It's very informative to read this topic and there is really LOT of information about each IC. Didn't you think about making some simple table with ICs which you tested or which people asking, with some simple info like "not good, better use this", "good at this, but worse at this"... Maybe it will help people to choose without keeping asking here and if someone will ask about new IC, it can be then added to the table.

— 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-664035011, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKR4PO2D5WARVD5YDH3R5SFK3ANCNFSM4BDN6GYA .

kriswiner commented 3 years ago

If you are using a cheap Chinese board that is poorly designed then you could get bad results even with the best sensors. But if the board is well designed it is likely you have selected a poor configuration for the sensors. In any case, I would recommend the LSM6DSM and LIS2MDL instead.

On Mon, Jul 27, 2020 at 10:31 AM oziqus notifications@github.com wrote:

A lot of people praise mpu9250 along with ak09916 (mag). I have different feelings when it is motionless, it can make noise by 2-5 degrees. There is any advice for 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-664533822, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKSTIID732IEBR3LVI3R5W2VPANCNFSM4BDN6GYA .

kriswiner commented 3 years ago

Typical mag jitter is +/- 5 milliGauss, worst case +/- 10

On Mon, Jul 27, 2020 at 10:46 AM oziqus notifications@github.com wrote:

Ok thanks for the answer, could you please show how your data looks (heading) when the mag is motionless? Maybe a comparison between ak09916 and LIS2MDL. Thank you.

— 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-664542353, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKVM52FVTOCBDXT6IOLR5W4OXANCNFSM4BDN6GYA .

kriswiner commented 3 years ago

I don't think so, but better ask Bosch.

On Wed, Jul 29, 2020 at 1:07 PM oziqus notifications@github.com wrote:

I have a question regarding bno055. I have mag offsets saved, after restart I send them to the device, but I don't know acc and gyro offsets so I don't give them, sometimes it's fine and accepts mag offset and sometimes heading starts from 0.0. Is there a solution for 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-665893817, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKWNHPGTGBXYMBMGTLLR6B6P7ANCNFSM4BDN6GYA .

kriswiner commented 3 years ago

You can save these in emulated EEPROM on your MCU permanently, or in your sketch. I don't think you can save these in the sensor itself except on each power up. If you want to do the latter, see the data sheet.

What are you trying to do?

On Thu, Jul 30, 2020 at 3:49 PM oziqus notifications@github.com wrote:

I have a question about lis2mdl, how to save offsets? REG_L as min and REG_H as max?

— 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-666758199, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKWKQ5QNUIK5GRYP4I3R6H2HTANCNFSM4BDN6GYA .

kriswiner commented 3 years ago

I am not sure what you mean here. If you measure the offset bias, you can store this in memory and apply it when you parse the mag data to get properly scaled output.

On Thu, Jul 30, 2020 at 9:21 PM oziqus notifications@github.com wrote:

I do not want to write to the sensor ... I want to enter as start parameters and turn on offset canceling. But as I give _H as the max offset e.g. for the x axis, eg + 80 (0x50) the OUT_L_REG parameters almost stand still ... it doesn't shift even by 1 degree.

— 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-666909232, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKTNHOG2MJCWWNYCDBTR6JBGNANCNFSM4BDN6GYA .

kriswiner commented 3 years ago

You can use the hard iron offset registers to store the hard iron (offset bias) measured in a calibration sketch, or you can simply store these in the sketch memory and subtract the offsets in the main loop. Both produce the same result and noise level.

On Thu, Jul 30, 2020 at 9:33 PM oziqus notifications@github.com wrote:

want to use offset cancelation to correct hard iron. I enable the offset cancelation option in the IMU, I say OFFSET_X_REG_L and OFFSET_X_REG_H, I do the same for the y and z axes. Of course I can do it on the side of my program, but I suspect that if I do it on the IMU side with LPF turned on I will have less noises. I'm right ?

— 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-666912787, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKSZCQAXXYHNE7FVKBLR6JCQXANCNFSM4BDN6GYA .

kriswiner commented 3 years ago

file:///C:/Users/kris/AppData/Local/Temp/dm00427201-lis2mdl-ultra-low-power-high-performance-3d-magnetometer-stmicroelectronics.pdf

See sections 8 and 9

On Thu, Jul 30, 2020 at 10:30 PM Tlera Corporation tleracorp@gmail.com wrote:

You can use the hard iron offset registers to store the hard iron (offset bias) measured in a calibration sketch, or you can simply store these in the sketch memory and subtract the offsets in the main loop. Both produce the same result and noise level.

On Thu, Jul 30, 2020 at 9:33 PM oziqus notifications@github.com wrote:

want to use offset cancelation to correct hard iron. I enable the offset cancelation option in the IMU, I say OFFSET_X_REG_L and OFFSET_X_REG_H, I do the same for the y and z axes. Of course I can do it on the side of my program, but I suspect that if I do it on the IMU side with LPF turned on I will have less noises. I'm right ?

— 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-666912787, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKSZCQAXXYHNE7FVKBLR6JCQXANCNFSM4BDN6GYA .

kriswiner commented 3 years ago

Lis2MDL is what we use niw. AK09940 looks even better if you can work with a 1.8V power scheme.

On Fri, Jul 31, 2020 at 6:43 AM oziqus notifications@github.com wrote:

I have another question, what is the alternative to hmc5883l at the moment, honestly I have tried a few and in hmc it is the most resistant to noise (raw data).

— 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-667126499, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKSF3WKTBVFNROPCZQ3R6LC7TANCNFSM4BDN6GYA .

kriswiner commented 3 years ago

I said AK09940.

What you want is a magnetometer that uses magnetoresistive film not a Hall sensor. Hall sensors are going to be very noisy and more temperature dependent by comparison.

There are only three worth considering AFAIK: LIS2MDL, AK09940, and MMC5983.

We use the LIS2MDL now with excellent results https://www.tindie.com/products/onehorse/max32660-motion-co-processor/ (typical AHRS heading error of 0.3 degrees RMS when calibrated).

The MMC5983 and AK09940 have noise figures ~8x lower. And both use full-scale ranges 4-5x smaller and offer 18-bit resolution resulting in ~20

However, in our testing to date the MMC5983 seems to suffer from drift and it has an ASIC that has several undesirable quirks.

We have yet to test the AK09940; the 1.8 V requirement will complicate our USFS design and we are not sure if we will pursue this possibility yet.

On Fri, Jul 31, 2020 at 7:42 AM oziqus notifications@github.com wrote:

I have ak09916 on my desk. Data sample (still lying on the desk) noise 0-6 degrees. (sparkfun ICM-20948 9Dof IMU)

x: -0.6, y: 22.35, z: 98.55 heading:91.53777238469747 x: -1.8, y: 22.05, z: 96.15 heading:94.66685837143901 x: -0.15, y: 21.6, z: 98.1 heading:90.39788096183459 x: -1.35, y: 22.35, z: 96.6 heading:93.456619172042 x: -1.35, y: 22.35, z: 95.84999999999999 heading:93.456619172042 x: 0.9, y: 23.25, z: 97.05 heading:87.78320565925982 x: -0.6, y: 22.35, z: 97.80000000000001 heading:91.53777238469747

— 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-667155533, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKXBHKF7DQQRB7VKIV3R6LJ6LANCNFSM4BDN6GYA .

kriswiner commented 3 years ago

Yes

On Fri, Jul 31, 2020 at 8:09 AM oziqus notifications@github.com wrote:

AK09940 uses magnetoresistive film yes ?

— 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-667170389, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKQZU5FUTYTXB2EVCT3R6LNCNANCNFSM4BDN6GYA .

kriswiner commented 3 years ago

There is a new technology called Google...check it out.

On Fri, Jul 31, 2020 at 8:28 AM oziqus notifications@github.com wrote:

This mmc5983 is still in production? where can i buy?

— 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-667180760, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKQ7YFC5ST2P5MGQ6ZTR6LPIBANCNFSM4BDN6GYA .

hpmax commented 3 years ago

Hello, I came here to try to get an understanding of the relative performance of various MEMS sensors after being somewhat disappointed with the MS5611 and looking to replace an MPU9150 in a design.

At roughly 50S/s (25Hz), with no filtering, I was able to achieve about 1.3 Pascals of RMS noise on the MS5611. By averaging two samples (12.5Hz), I was able to reduce this to the .9-1 region. The LPS22H claims .7 Pascals with a bandwidth of 3.75Hz. This makes me think the noise performance of the MS5611 is slightly better (note that it is critical to poll the MS5611 at regular intervals, or you will add noise). Anyone have comments on the MS5611 vs LPS22HB (or if there is a better sensor?)

As for the IMU. Has anyone put the ICM-20984 (MPU-9250 is EOL, so its probably not good to use that), vs LSM6DSM vs the Bosch BMI260 which I haven't seen mentioned here, but is apparently a substantial improvement over the previous generation?

kriswiner commented 3 years ago

LPS22HB has an interrupt, so polling is not required.

ICM20984 is not a low noise sensor.

LSM6DSM and ICM42688 are more or less equivalent, but MMC5983A is the lowest noise mag we know of. So LSM6DSM (or ICM42688) + MMC5983A is a superior 9DoF solution.

On Thu, Aug 20, 2020 at 10:40 AM hpmax notifications@github.com wrote:

Hello, I came here to try to get an understanding of the relative performance of various MEMS sensors after being somewhat disappointed with the MS5611 and looking to replace an MPU9150 in a design.

At roughly 50S/s (25Hz), with no filtering, I was able to achieve about 1.3 Pascals of RMS noise on the MS5611. By averaging two samples (12.5Hz), I was able to reduce this to the .9-1 region. The LPS22H claims .7 Pascals with a bandwidth of 3.75Hz. This makes me think the noise performance of the MS5611 is slightly better (note that it is critical to poll the MS5611 at regular intervals, or you will add noise). Anyone have comments on the MS5611 vs LPS22HB (or if there is a better sensor?)

As for the IMU. Has anyone put the ICM-20984 (MPU-9250 is EOL, so its probably not good to use that), vs LSM6DSM vs the Bosch BMI260 which I haven't seen mentioned here, but is apparently a substantial improvement over the previous generation?

— 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-677804022, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKQBS2NPBLU4DK7PCMLSBVNX7ANCNFSM4BDN6GYA .

hpmax commented 3 years ago

I just found out there is also an LPS22HH which is apparently better than the LPS22HB.

Thoughts on the BMI260 or the AK09940? Several posts up you seemed to express reservations with the MMC5983...

kriswiner commented 3 years ago

MMC5983A has a quirky ASIC, but the results https://hackaday.io/project/160283/log/182097-max32660-motion-coprocessor-mmc5983ma-low-noise-magnetometer-results are worth the effort.

I have a low opinion of Bosch sensors for AHRS. Though I use the BMA400 for wake-on-motion watchdog..

AK09940 is probably OK if you can work at 1.8V.

On Thu, Aug 20, 2020 at 12:02 PM hpmax notifications@github.com wrote:

I just found out there is also an LPS22HH which is apparently better than the LPS22HB.

Thoughts on the BMI260 or the AK09940? Several posts up you seemed to express reservations with the MMC5983...

— 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-677843166, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKQQSHQ75ZBCOAPSODDSBVXNZANCNFSM4BDN6GYA .

hpmax commented 3 years ago

Fair enough. Are magnetometers really that useful to begin with? With magnetic variation, turning errors, acceleration errors, and it's predilection from getting messed up by being near any ferrous metals, are they really that reliable for navigation purposes at all?

kriswiner commented 3 years ago

Yes.

We use them on UAVs, on boats, cars, planes with success...

If you don't care about accurate heading, just use an accel/gyro and forget the mag. But you can't get accurate heading without one.

On Thu, Aug 20, 2020 at 12:18 PM hpmax notifications@github.com wrote:

Fair enough. Are magnetometers really that useful to begin with? With magnetic variation, turning errors, acceleration errors, and it's predilection from getting messed up by being near any ferrous metals, are they really that reliable for navigation purposes at all?

— 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-677851621, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKQV6BDHPDGZZRRL4TTSBVZKBANCNFSM4BDN6GYA .

Userpc1010 commented 3 years ago

Which of the listed sensors is the least sensitive to linear and centrifugal acceleration. Is there a publicly available fusion algorithm capable of operating at g-maneuvers of 3-4G to use it with analog device sensors?

kriswiner commented 3 years ago

Least sensitive? Meaning with the lowest full-scale range? They all support +/- 2 g. Is this your question?

Madgwick or Mahoney filters work at this accel rate but accuracy will suffer when the accel is greater than the Earth's gravity.

On Wed, Aug 26, 2020 at 6:44 AM Userpc1010 notifications@github.com wrote:

Which of the listed sensors is the least sensitive to linear and centrifugal acceleration. Is there a publicly available fusion algorithm capable of operating at g-maneuvers of 3-4G to use it with analog device sensors?

— 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-680888839, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKTGP6NDXH5MT5SCXELSCUGUTANCNFSM4BDN6GYA .

Userpc1010 commented 3 years ago

In the sensor specification, for example ADIS 16470 for gyroscopes, the sensitivity to linear accelerations "Linear Acceleration Effect" is 0.015 ° / sec / g, which sensitivity of the mpu 9250, it is not in the specification?

Is there an efficient way to get an absolute orientation quaternion without being affected by linear acceleration? I tried to change the Mahoney filter so that at the moment of g-maneuvers, when the magnitude of the acceleration vector along all axes is more than 1G, to pause the fusion of the gyroscope and accelerometer data, i.e. at the moment of acceleration, the quaternion rotates only with a gyroscope until the moment when the accelerations become less than 0.8G or more than 1.2G, but this gives an error of 5 - 10 degrees (if start moving smoothly and the acceleration does not reach 1.2G immediately), or have to shift the frames closer to 1G (0.9 - 1.1G) But then the gyroscope drift compensation almost never happens in movment. Is it possible to somehow compensate linear acceleration within 0.2G - 0.3G?