MPU9250 ODR about mpu6050 HOT 14 OPEN

Sorry, that is a typo. It is either 8 or 100 Hz for the mag. Yes, I have
used the data ready interrupt for the accel/gyro. I don't think there is one
for the mag in the MPU9250 package. I prefer just polling the data ready bit
in the status register though.

Kris

-----Original Message-----
From: Mauro Mombelli [mailto:[email protected]]
Sent: August 7, 2015 6:36 PM
To: kriswiner/MPU-6050
Cc: Kris Winer
Subject: Re: [MPU-6050] MPU9250 ODR (#9)

1200Hz the magne?? It is a lot, never saw more than 120Hz!

BTW witch register you are talking about? Also, did you have any data ready
interrupt?

On Sat, 8 Aug 2015 03:18 Kris Winer [email protected] wrote:

Hi Mauro,

Yes, I just used the info in the data sheet to set the sample rate of the
sensors. The mag can only be set at either 8 or 1200 Hz, the accel can go
up
to 1 kHz IIRC, while you can run the gyro at 8 kHz.

Kris

-----Original Message-----
From: Mauro Mombelli [mailto:[email protected]]
Sent: August 6, 2015 12:08 PM
To: kriswiner/MPU-6050
Subject: [MPU-6050] MPU9250 ODR (#9)

hi,
i'm making some research to understand the sensor's panorama, and i would
like to understand what is the ODR of MPU9250, i undertand that
accelerometer can go up to 4kHz, from your codde that magne is read at
100Hz, but what about gyro? also how did you find taht value? the
datasheet
is so inconsistent! maybe you directly look up to single chip DS?

Uff invsense make all think so complicated, ST datasheet are much better
:/

Also i have some modification to original DCM implementation, basically
just
some code refractor, see https://github.com/MauroMombelli/FreeDCM

Reply to this email directly or view it on GitHub
#9 .
<

https://github.com/notifications/beacon/AGY1qggzHbDHueZ_KRjAEtLGkV6dc0syks5
ok6gmgaJpZM4FnEwb.gif>

Reply to this email directly or view it on GitHub
#9 (comment).

Reply to this email directly or view it on GitHub
#9 (comment) .
<https://github.com/notifications/beacon/AGY1qkt_D0icXq7E6JJg_ZD9m4-GYn6Oks5
olVSTgaJpZM4FnEwb.gif>

from mpu6050.

Hi Mauro,

Yes, I just used the info in the data sheet to set the sample rate of the
sensors. The mag can only be set at either 8 or 1200 Hz, the accel can go up
to 1 kHz IIRC, while you can run the gyro at 8 kHz.

Kris

-----Original Message-----
From: Mauro Mombelli [mailto:[email protected]]
Sent: August 6, 2015 12:08 PM
To: kriswiner/MPU-6050
Subject: [MPU-6050] MPU9250 ODR (#9)

hi,
i'm making some research to understand the sensor's panorama, and i would
like to understand what is the ODR of MPU9250, i undertand that
accelerometer can go up to 4kHz, from your codde that magne is read at
100Hz, but what about gyro? also how did you find taht value? the datasheet
is so inconsistent! maybe you directly look up to single chip DS?

Uff invsense make all think so complicated, ST datasheet are much better :/

Also i have some modification to original DCM implementation, basically just
some code refractor, see https://github.com/MauroMombelli/FreeDCM

Reply to this email directly or view it on GitHub
#9 .
<https://github.com/notifications/beacon/AGY1qggzHbDHueZ_KRjAEtLGkV6dc0syks5
ok6gmgaJpZM4FnEwb.gif>

from mpu6050.

1200Hz the magne?? It is a lot, never saw more than 120Hz!

BTW witch register you are talking about? Also, did you have any data ready
interrupt?

On Sat, 8 Aug 2015 03:18 Kris Winer [email protected] wrote:

Hi Mauro,

Yes, I just used the info in the data sheet to set the sample rate of the
sensors. The mag can only be set at either 8 or 1200 Hz, the accel can go
up
to 1 kHz IIRC, while you can run the gyro at 8 kHz.

Kris

-----Original Message-----
From: Mauro Mombelli [mailto:[email protected]]
Sent: August 6, 2015 12:08 PM
To: kriswiner/MPU-6050
Subject: [MPU-6050] MPU9250 ODR (#9)

hi,
i'm making some research to understand the sensor's panorama, and i would
like to understand what is the ODR of MPU9250, i undertand that
accelerometer can go up to 4kHz, from your codde that magne is read at
100Hz, but what about gyro? also how did you find taht value? the datasheet
is so inconsistent! maybe you directly look up to single chip DS?

Uff invsense make all think so complicated, ST datasheet are much better :/

Also i have some modification to original DCM implementation, basically
just
some code refractor, see https://github.com/MauroMombelli/FreeDCM

Reply to this email directly or view it on GitHub
#9 .
<
https://github.com/notifications/beacon/AGY1qggzHbDHueZ_KRjAEtLGkV6dc0syks5
ok6gmgaJpZM4FnEwb.gif>

—
Reply to this email directly or view it on GitHub
#9 (comment).

from mpu6050.

That's is interesting as the competitorLSM9DS0 can do only 760Hz with gyroscope, this is a huge difference!

from mpu6050.

Mauro,

If you are interested in comparisons between sensors and sensor fusion
engines, have you seen this?

https://github.com/kriswiner/MPU-6050/wiki/Affordable-9-DoF-Sensor-Fusion

and this?

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

Kris

-----Original Message-----
From: Mauro Mombelli [mailto:[email protected]]
Sent: August 7, 2015 7:33 PM
To: kriswiner/MPU-6050
Cc: Kris Winer
Subject: Re: [MPU-6050] MPU9250 ODR (#9)

That's is interesting as the competitorLSM9DS0 can do only 760Hz with
gyroscope, this is a huge difference!

Reply to this email directly or view it on GitHub
#9 (comment) .
<https://github.com/notifications/beacon/AGY1qvyUWfy1fYgGzn9c6ewaWmfWJXu3ks5
olWHcgaJpZM4FnEwb.gif>

from mpu6050.

hi,
finally had some time.

I have experience with DCM and programming it, (my code is teted using a STM32f3discovery, 128Mhz with FPU and comes with 9DOF: L3GD20 as gyro LSM303DLHC as mangne and acc) so the first link is knew things.

The second link is really interesting, as i still have to play with baromenter.

ah, LSM9DS0 probably has Z axis that use a different scale than the other axis, that is why you get strange result (the LSM303DLHC does)

What i can't understand is if you are trying to use the sonsor at their max speed (witch seems not, as i think I2C should limit you because bandwidth, even at fast rate).

I really enjoy your test, but i see like me you are missing a "test rig", some sort of mechanical device that can rotate at a know speed and position, so using some stepper or encoder, to test the latency and precision of every sensor combination and algorithm combination.

As i have access to some CNC machine i'm thinking to build it up by myself, and i like to have your input on what you think is the best way (and i can send you copy so you can test by yourself)

from mpu6050.

@kriswiner has you got the sensor, did you test them in i2c at maximum ODR? What is the maximum polling speed you get? As far as i know the SPI should be a lot faster but i need some data to start with.

Also yesterday i was testing with the stm32f303 (it has FPU) and with a DCM with random data (no sensor) i can get the algorithm running at 55kHz.

I think is possible to get easily real case algoritm to run at 5kHz, that is why i'm so interested in your study.

anyway a LSM9DS0 is on the way to me, so i can personally run part of the test :)

from mpu6050.

Sensor fusion at more than 1 kHz is really overkill. The real benefit to faster processing is that you can run the fusion at 1 kHz with much lower clock speed and, hence, power. I usually run the sensor ODRs at ~200 Hz and the sensor fusion at 1 kHz. You can run faster, say, sample at 1 kHz and do the fusion at 4 or 5 kHz but i don't think there is any practical value in doing so for most human-paced applications. For ultra-fast motion, maybe. Like tracking motion of a hummingbird?

from mpu6050.

I was thinking to implement some basic Dead Reckoning to estimate position, in that case the quality means a lot.
Also on very fast and sudden acceleration (like running, flying acrobatic) you will get better results.

from mpu6050.

I'd like to see the dependence of dead reckoning accuracy on fusion speed. I suspect the greatest leverage in terms of accuracy will come with better sensor calibration rather than sensor fusion rate.

Please let me know what you find, I am interested in the dead reckoning problem too.

from mpu6050.

yes, calibration is another big factor, that is why i'm also taking into account greatly the "self-test" capability of the sensors; if all of them has it, i can exclude any user interaction for calibration, making it a "fast on the field" on top of a one "leave it all the night long turned on"

from mpu6050.

I'm writing some code in spare time, but without the sensor is quite hard.
(The LMS is coming, do you know how to get a sample/breakout for the MPU?
No problem soldering SMD here)

On Tue, 25 Aug 2015 20:42 Kris Winer [email protected] wrote:

I'd like to see the dependence of dead reckoning accuracy on fusion speed.
I suspect the greatest leverage in terms of accuracy will come with better
sensor calibration rather than sensor fusion rate.

Please let me know what you find, I am interested in the dead reckoning
problem too.

—
Reply to this email directly or view it on GitHub
#9 (comment).

from mpu6050.

I Mario,

I sell breakout board for all kinds of sensors including the LSM9DS0 and
MOU9250. See:

https://www.tindie.com/stores/onehorse/

Kris

-----Original Message-----
From: Mauro Mombelli [mailto:[email protected]]
Sent: August 26, 2015 12:54 AM
To: kriswiner/MPU-6050
Cc: Kris Winer
Subject: Re: [MPU-6050] MPU9250 ODR (#9)

I'm writing some code in spare time, but without the sensor is quite hard.
(The LMS is coming, do you know how to get a sample/breakout for the MPU?
No problem soldering SMD here)

On Tue, 25 Aug 2015 20:42 Kris Winer [email protected] wrote:

I'd like to see the dependence of dead reckoning accuracy on fusion speed.
I suspect the greatest leverage in terms of accuracy will come with better
sensor calibration rather than sensor fusion rate.

Please let me know what you find, I am interested in the dead reckoning
problem too.

Reply to this email directly or view it on GitHub
#9 (comment).

Reply to this email directly or view it on GitHub
#9 (comment) .
<https://github.com/notifications/beacon/AGY1qvQeiwCAGp8ZvLR1P2vwZ-ekVJeOks5
orWgkgaJpZM4FnEwb.gif>

from mpu6050.

*mauro :)

btw seems like they bring out only i2c, witch even if we dont want to go to full ODR, take a loot of speed; it has been estamated that on Cleanflight (a flight controller for multicopter/plane) that if you have FPU then the 72% of time is used for i2c communication. (see http://flysherlockair.com/2015/07/how-does-cleanflight-spend-its-time-lets-profile/)

from mpu6050.