One Question

[kriswiner]

One Question

[kriswiner]

It would help to know what breakout board you are using, some of the purple boards from China are nit designed correctly and will not work.

[kriswiner]

I am assuming you tried something like the MPU9250 initiation sequence in my MPU9250/STM32F4DiscoveryBoard repo?

[pou2014]

Yes. I tried to proceed similar to your code. Is there any way to find that the board is correctly designed or not?

[kriswiner]

One the two purple boards I bought pin 1 is not tied to VCC as it should be. This results in the magnetometer giving wild responses and the accel and gyro only sometimes work.

In general I would say if your MPU9250 boards are purple, throw them away and get one from embeddedmasters available on the invensense web site store.

[pou2014]

my board is not purple and is similar to the one is selling in following link.

http://www.aliexpress.com/store/product/F08402-MPU-9250-GY-9250-9-axis-Sensor-Module-I2C-SPI-Communication-freeship/1017068_1902934315.html

the problem is instability of the gyro ; the values are skipping frequently in the range of -1 to +10. for example = [0.3 0 0.9 1 4 0.3 0.2 6 0.1 11 9 0.6 ... ]. also the temperature sensor return 40 degrees in a room with 25 degrees.

[kriswiner]

The board looks OK, pin #1 seems to be attached to VCC. I don’t have experience with this particular board but the GY-521 boards with the MPU6050 I have used are just fine.

The temperature could be that much higher since it is not intended as an ambient temperature sensor but an internal gyro temperature. How you set up the gyro has a lot to do with the data returned. What is the sample rate? I would suggest 200 Hz. What is the bandwidth? I would suggest 40 Hz. Did you calibrate the gyro? This shouldn’t affect the apparent jitter. If you run the gyro at a high rate and no filtering you could get a lot of jitter.

From: pou2014
Sent: Wednesday, November 19, 2014 9:24 AM
To: kriswiner/MPU-9250
Cc: Kris Winer
Subject: Re: [MPU-9250] One Question (#4)

my board is not purple and is similar to the one is selling in following link.

http://www.aliexpress.com/store/product/F08402-MPU-9250-GY-9250-9-axis-Sensor-Module-I2C-SPI-Communication-freeship/1017068_1902934315.html

the problem is instability of the gyro ; the values are skipping frequently in the range of -1 to +10. for example = [0.3 0 0.9 1 4 0.3 0.2 6 0.1 11 9 0.6 ... ]. also the temperature sensor return 40 degrees in a room with 25 degrees.

—
Reply to this email directly or view it on GitHub.

[pou2014]

I simultaneously reading a MPU6050 accelerometer and i do not have such a problem. Gyros work normally and the temperature sensor shows the room temperature. although there is no difference in outputs when setting the DLPF or not, but everything seems to be OK.
i will test your recommendation. However I think this problem originates from the point that no pll clock is activated; what suffered me in the mpu6050 before setting the clock source bit.

[kriswiner]

There is a default clock selection, I believe, but it is always a good idea to set the gyro z-axis as the clock source. The MPU9250 uses the MPU6500 gyro/accelerometer which has a different register map than the MPU9150 and the MPU6050, which are the same except for the mag. Make sure you are using the correct register map to set your clock and everything else since an incorrect bit set can also cause problems.

I haven’t seen such strange out put from the MPU9250 using my program. I wonder if there is something peculiar about the STM32F4 that is interfering with the operation of the gyro?

From: pou2014
Sent: Wednesday, November 19, 2014 11:38 PM
To: kriswiner/MPU-9250
Cc: Kris Winer
Subject: Re: [MPU-9250] One Question (#4)

I simultaneously reading a MPU6050 accelerometer and i do not have such a problem. Gyros work normally and the temperature sensor shows the room temperature. although there is no difference in outputs when setting the DLPF or not, but everything seems to be OK.
i will test your recommendation. However I think this problem originates from the point that no pll clock is activated; what suffered me in the mpu6050 before setting the clock source bit.

—
Reply to this email directly or view it on GitHub.

[pou2014]

I have another Question. Have been you tested any integration process on the Gyro/Acc outputs?
how is possible to get accurate DT for integration.?

[kriswiner]

I have used integration and the best way to do this is to use the FIFO to provide a common time stamp for the gyro/accel data.

From: pou2014
Sent: Thursday, November 20, 2014 12:47 AM
To: kriswiner/MPU-9250
Cc: Kris Winer
Subject: Re: [MPU-9250] One Question (#4)

I have another Question. Have been you tested any integration process on the Gyro/Acc outputs?
how is possible to get accurate DT for integration.?

—
Reply to this email directly or view it on GitHub.

[pou2014]

How to do it? Could you please explain the entire process?

[kriswiner]

You may burst read the gyro and accel data written to the FIFO at a specified duty cycle and use the duty cycle to mark the data time. Then you have time-marked data and can perform the usual integration to get velocities and position, if you want. There are better ways to get orientation though through sensor fusion to get quaternions, etc. Relative position tracking is going to be inaccurate except for very short time due to gyro drift. Unless you have a magnetometer or GPS to help compensate for the drift you won't be able to get good position tracking for more than a few seconds.

[pou2014]

You mean FIFO unit of Micro?
Even if we use Sensor fusion algorithms, don't we need to know Dt?

[kriswiner]

Yes, you can use the dt from the FIFO collection duty cycle (rate).

[pou2014]

thanks.
what if i want to use timers to get time elapsed? Does it differ from the previous manner?
Do you know how to configure stm32f407 timers to get accurate time elapsed in ms?

[kriswiner]

I don't know specifically how for this processor, but most ARM processors have some sort of time elapsed utility like millis or some such, depending on the library. Internal to the processor, there are lots of ways to keep track of time.

[mariocannistra]

Hi pou2014 and Kris.
In addition to Kris answer, have a look at this page: http://stm32f4-discovery.com/2014/07/library-19-use-internal-rtc-on-stm32f4xx-devices/ about using the internal clock.
Do you have a crystal on your micro board ? If not, check the notes about that or using internal/external clock sources.

if you go with the internal source, read this about the calibration not specific for the 407 but should be still suitable: http://www.st.com/st-web-ui/static/active/en/resource/technical/document/application_note/CD00221839.pdf

if you want to add a crystal pay attention to the quality : higher ppm crystal will give you high drift rates. probably not important if you just want to measure the dt, more important if you will need a more precise time clock for other usages.

About dt and integration: I started doing odometry experiments with imu/dead reckoning one month ago and learned 2 things:

1. dt values you will measure in your sensor reading loop will not be constant depending on which and how many sensors you are reading. Each sensor takes a specific time to give you the reading. You can try different approaches like reading them at every round of the loop or reading them only when "possible" given their max update frequency. Obviously this will directly affect dt...

2. i've got different dt values from as low as 1 ms to 4 ms on a Teensy 3.1 using a mpu9150 and a MPL3115a2 barometer. All this logging in binary format to a microSD. Getting lower dt with these sensors on this micro seems not possible at 72 MHz. With your micro you could obtain better values.

I also have a LSM9DS0 and a BMP180 and will soon try with them. Will possibly see less noise from accel and more precision from altimeter.

When you will move on to calculating the integrals you will see VERY different results depending on the dt value. You will also have to choose an integral calculation algorithm suitable for variable dt or the result will not be correct. I did read on the web many info sources about rectangular, trapezoidal and simpson integral calc methods before choosing simpson. Even if my results are currently encouraging I'm still having issues. I'm currently considering other small size micros and could probably arrive to test the F407 if i will not find another with higher sys clock.

I'm trying to track my body movement using a strapdown approach like Madgwick did, but would like to avoid the shoe mounting since i would like to use this also on a bike and for some friends currently doing theatre shows in open spaces.

I'm currently using 9 dof sensor fusion algorithm by Madgwick but did not find a way to merge the altimeter data in a good way. Did you find some code about this?

I would be glad to share thoughts / experiences with you guys. Just drop me a line and i will do my best to reply when not busy at work.
Ciao,
Mario

[kriswiner]

"I'm currently using 9 dof sensor fusion algorithm by Madgwick but did not find a way to merge the altimeter data in a good way. Did you find some code about this?"

You have to use a Kalman filter to include the altimeter data in the sensor fusion. One of my team members has done this but I cannot share the code at the moment. If you or someone you know is familiar with constructing Kalman filters this addition should be straightforward.

BTW, did you know that you can overclock the Teeny 3.1 to at least 168 MHz? It doesn't have a floating point engine but it is a pretty capable processor for $17 delivered!

[mariocannistra]

Hi Kris.
I recently read about Kalman filters but never wrote one. I will search some info and try.
About the teensy clock: 168 MHz ? I remember 96 MHz in the Arduino IDE but didn't know of 168.. is this something that can be done without the risk of destroying the chip ? :-) I ordered a second one as a spare just yesterday but would like to avoid the risk... :-)
About doing position tracking, I don't have drift at the moment and i'm using 9 dof with magnetometer, heading started working properly after some changes to the initial code i started from and i've been able to mimick Madgwick experiment using a trial of MatLab and his published script for gait tracking.
Were you or somebody else able to do position tracking for more time in these conditions ?
I'm in the process of porting everything to python / matplotlib / scipy and so on... but i'm finding various issues due to the matlab specifics...

[kriswiner]

If you search the Teensy forum you will see posts on overclocking Teensy 3.1. I don't think it hurts them!

Position tracking is much harder than calculating absolute orientation. Errors build quickly when double integrating. I am trying to add GPS to periodically correct drift of the fused sensor data and use the fused sensor data to fill in gaps or delays in the GPS data. That is the idea. So far I am having hardware issues in the first GPS board I designed and assembled. So there is still lots to do.

[pou2014]

Hello mariocannistra
Thank you very much for sharing the experiences. I am not expert in working with micro controllers but I am really interested in learning about the subject and do projects.
about the mpu9250 : my problem is that i think it does not find suitable clock source which is supposed, according to the datasheet. if you think this problem may solve with external clock source from the FSYNC pin I have to check. for now i have no idea how to insert clock to mpu9250. Is that possible with configuring GPIOs or a crystal is needed?
I used the library you mentioned before and get the RTC data even in sub seconds. but seconds are not count properly. they count alternately by error of two. means : 1 2 3 45 6 7 8 910 11 .... every 4 seconds it counts 2 seconds together.
about the dt : I used RTC sunseconds to measure the dt but was not successful . It counts a loop of reading some sensors in a second which i think it is wrong.
I also confirm with you about variation of dt depending on what is going on in the loop. I am trying to configure a timer in order to let me know how many time is elapsed. Probably when you want to integrate a sensor output upon reading it, the dt may be equal to the sensor frequency but when you impose a sensor fusion algorithms before the integration, dt is not the same as sensor frequency. If I am wrong please let me know.
so I hope having a timer can solve the problem. yesterday I configured a timer in counting mode to know what time is elapsed, but the configuration was not successful and the data was not accurate. probably because of wrong setting of prescaler/autorealod/period values.

[mariocannistra]

i don't have a 9250 so tomorrow morning i will check the datasheet.
anyway, i have a 9150 and i suppose they are similar . i have bought a 9150 breakout board by sparkfun months ago and i used that with both an arduino pro micro and a teensy. in both cases i had to use just 4 wires : 2 for power and 2 for i2c (sda and scl). i'm polling for new data and not using the interrupt method (yet).
the clock source should be needed only on the micro for the RTC to work properly.
which board do you have exactly ? is it a stm32f407 NUCLEO board ? or which one ? if i correctly remember, the nucleo board does not have a quartz crystal mounted but should have the pads ready to solder one. i guess the usual 32.768 khz , i have bought some for the teensy as well, same reason. got ten crystals for 2 euros. i think 12 ppm so not an atomic clock precision... but good enough to measure dt in your main loop or time taken to read sensors.
there should be also an internal clock source and yes, i think you have to set some registers to have the rtc working properly. when i have to test and learn on these things i always use a separate smaller source file to focus just on one topic at a time. i suggest you do the same to solve the rtc thing first.
i have a nucleo board sitting there but did not have the opportunity to start working on it since september. bought it for a radio astronomy project but had to suspend due to space issues i have to solve for ... the antennas... :-)
are you familiar with freeImu library by fabio varesano ? there is dt calculated in the main loop in a very simple way. you can find it here on github ...several clones available . i started using the one being updated by mjs513. i am now working on custom code because that is made for many sensors while i am focusing on just a couple. now i don't remember well but probably it's also in some of the wonderful sketches by Kris here on github. if you didn't already, spend some time reading all the sources you can find googling around ... i think i read at least 50 and i'm continuing ... there's so much to learn every day...

[pou2014]

I use a stm32f4 discovery board. It has 8 MHZ crystal on-board but not the RTC crestal (The Pad is exist to solder a new one)

[mariocannistra]

ok, so i suggest you leverage the blog at this url http://stm32f4-discovery.com/2014/05/all-stm32f429-libraries-at-one-place/
the author has written several libraries listed on that page. item n. 19 is the library for the rtc: you can download it and test. here is the description for the library http://stm32f4-discovery.com/2014/07/library-19-use-internal-rtc-on-stm32f4xx-devices/ i suggest you read it carefully, since it also describes how the internal clock source can be used after setting the prescaler registers properly. it is very important. seems that without doing that the subsecond values will not be suitable for you measurements in the ms range.

[pou2014]

I have now tightly connected with the site. its RTC library really working but the accuracy of internal clock source is not high as the owner of site also mentioned. I use a way to test that the DT is true or not and that is testing numerical integration of one of gyro axis. I expect 90 degrees as result of integration while the IMU goes under 90 degrees of rotation about the selected axis. but neither the RTC nor the timers get true DT.

[pou2014]

Hello kriswiner
Regarding to our previous discussions about Integration DT I have confirmed that it is equal to the execution time which is the time when the samples are gained at each run of the while(1);
A problem still exist and that is when putting Gyro FS into 500 deg/sec the true DT is exe.time/2 and when putting it on 1000 deg/sec the true DT is exe.time/4. I couldn't yet find what is the reason?
Also how to check the true DT for accelerometers while integrating navigation vectors V & R.?

I have also faced with another issue while trying to change acceleration FS from 2g to 4,8&16g on mpu6050 on GY-88. It doesn't change when writing 0x01 to 0x03 on accel.Config register. Is there any other changes to be done?
Thanks.

[kriswiner]

Writing to the accel config register should be enough. Make sure the value is not being overwritten by some other function by checking (reading) the value before the data is read.

If the integration time is changing with the full scale then this could be a scaling error since time ~ 1/gyro rate. Check that the scaling is being done properly when you change the full scale.

Both of these problems should not occur with the sketches in my repository. If you find they have an error please let me know so I can fix it. Which code are you using?

[pou2014]

Actually I am not using your code and the problem refers to a cod of mine. However the process is similar. I don't understand your mean by FS error?! I have changed it, then I used the related sensitivity value to convert it to deg/sec and everything are working well except DT.
I just used your calibration code which I found that when setting CONFIG register to 0x00 (DLPF Disabled) no calibration is done.

[pou2014]

Hello Kris Winer
I found that you have used Madgwick method to compute Quaternian and update Euler Angles. In an article released by Madgwick "Estimation of IMU and MARG orientation using a gradient ..." have noticed that the input of algorithm is gravity measurements only. Have been you considered this issue and how did you elicit gravity from IMU measurements. If not, what will be happen to accuracy of the Euler angles?

[kriswiner]

I have read this paper many times. I essentially copied the Madgwick algorithm from this paper and made a few integer type changes. The MARG algorithm takes gyro, accelerometer, and magnetometer input and produces an iterative estimation of the orientation as a quaternion for output. It is possible to derive the gravity vector from the accelerometer data plus the quaternion. But the gravity vector is not really an input.

In any case, Madgwick's algorithm is a minimal sensor fusion solution. It will not be perfect. It gets better if there is sufficient iterations to reach an asymptotic solution. This usually means a sample data rate of 100 - 200 Hz and a sensor fusion algorithm rate of ~100 Hz, so that there is time for 4 or 5 gradient iterations for each new data sample.

What the simple algorithm lacks is any hysteresis, such as would be provided by an integral correction or running average of quaternions. It does not contain a low pass or high pass filter, although some low pass filtering of the input data is usual.

In other words,Madgwick's algorithm is a good place to start, but it is not a complete sensor fusion solution.

[pou2014]

Thank you for good explanation. When I just test the algorithm for the first time I observed nice result in x & y channels so that no integration windup occurred. But in the z channel I had windup. Is this the real performance of the algorithm or I just made a mistake somewhere?
Is this algorithm proposed only for stabilizing or is beneficial for any purpose such as controlling or tracking Euler angles?
How do you remove the gravity from IMU measurements, I think we are to guess gravity here !?

[kriswiner]

These algorithms are a pretty good basic sensor fusion solution for AHRS (heading) determination applicable for general use. If you are seeing windup there might be an error; I usually do not see this in my fairly gentle motion applications. There are standard ways to estimate gravity from quaternions. I don't know how off the top of my head but i would bet a goole search would quickly turn up some good references. All the hardware sensor fusion algorithms do this.

[pou2014]

Finally I have got to work with mpu9250 successfully. The problem was at acc & Gyro registers in my header file where determining the config register options. How ever i just had copied them from other codes. The DT also is now equal to EX. time!
off course a lot of things may be found on the google. I jut wanted to know your idea !

[kriswiner]

Glad you got it to work!

Kris

-----Original Message-----
From: pou2014 [mailto:[email protected]]
Sent: February 14, 2015 12:43 PM
To: kriswiner/MPU-9250
Cc: Kris Winer
Subject: Re: [MPU-9250] One Question (#4)

off course a lot of things may be found on the google. I jut wanted to know
your idea !
Finally I have got to work with mpu9250 successfully. The problem was at acc
& Gyro registers in my header file where determining the config register
options. The DT is now equal to EX. time!

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

[honuoc]

Hello kriswiner, thank you for your great work.
Hi pou2014, I got same problem with you about data output from magnetometer sensor. Could you share your code for STM32F4Disco board ( I used same MPU 9250 board as well)?
Thanks

[kriswiner]

I have code for the MPU9250 using the STM32F401 Nucleo board on mbed. I
think I have it reposited at github too, but just go to www.mbed.com and
look at the developers site and serch for MPU9250 and you'll find it.

-----Original Message-----
From: honuoc [mailto:[email protected]]
Sent: December 13, 2015 8:23 PM
To: kriswiner/MPU-9250
Cc: Kris Winer
Subject: Re: [MPU-9250] One Question (#4)

Hello kriswiner, thank you for your great work.
Hi pou2014, I got same problem with you about data output from magnetometer
sensor. Could you share your code for STM32F4Disco board ( I used same MPU
9250 board as well)?
Thanks

Reply to this email directly or view it on GitHub
#4 (comment) .
<https://github.com/notifications/beacon/AGY1qo9zQKj5-KMu3QhaBa4XmeZXgkaZks5
pPjungaJpZM4C8avo.gif>

[honuoc]

Thanks Kris, I will take a look.

[pou2014]

honuoc
The code I have used for MPU9250 magnetometer, is not different with those that can be found on the Github. Actually you have to search for AK86... (The magnetometer name) .With a simple search you can find it.
What is your problem with AK...?

[kriswiner]

I have no problem with AK...

-----Original Message-----
From: pou2014 [mailto:[email protected]]
Sent: December 14, 2015 8:14 AM
To: kriswiner/MPU-9250
Cc: Kris Winer
Subject: Re: [MPU-9250] One Question (#4)

honuoc
The code I have used for MPU9250 magnetometer, is not different with those
that can be found on the Github. Actually you have to search for AK86...
(The magnetometer name) .With a simple search you can find it.
What is your problem with AK...?

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

[honuoc]

My problem with magnetometer is that its output value is quite small event in 16bit mode (maximum is about 300) and irregularly. If I translated the sensor without rotation the magnetometer output changed. Is it normal?

[kriswiner]

Is that 300 mGauss? If it is 300 counts, that is rather low but this depends
on your Earth location and the orientation of the mag. The magnitude of the
mag field sqrt(Mx^2 + My^2 + Mz^2) should be close to ~500 mGauss. Is it?

-----Original Message-----
From: honuoc [mailto:[email protected]]
Sent: December 15, 2015 12:36 AM
To: kriswiner/MPU-9250
Cc: Kris Winer
Subject: Re: [MPU-9250] One Question (#4)

My problem with magnetometer is that its output value is quite small event
in 16bit mode (maximum is about 300) and irregularly. If I translated the
sensor without rotation the magnetometer output changed. Is it normal?

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

[pou2014]

The earth magnetic field is between 20 - 80 Microtesla.
so, depending on your location you have to check the calculated Heading and see is that correct or not. You can check heading & Mx My Mz with the android cellphones magnetometer....

[honuoc]

The point is that when I translated the sensor the output values of all three axes changed so much (from -50 to 50 for example). And, when I rotated the sensor around z axis, the z output also changed a lots.

[kriswiner]

What MPU9250 breakout are you using? Have you calibrated the sensors to
remove bias?

-----Original Message-----
From: honuoc [mailto:[email protected]]
Sent: December 15, 2015 6:02 PM
To: kriswiner/MPU-9250
Cc: Kris Winer
Subject: Re: [MPU-9250] One Question (#4)

The point is that when I translated the sensor the output values of all
three axes changed so much (from -50 to 50 for example). And, when I rotated
the sensor around z axis, the z output also changed a lots.

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

[honuoc]

I am using this board:
http://www.ebay.com/itm/SPI-IIC-MPU-9250-9-Axis-Attitude-Gyro-Accelerator-Magnetometer-Sensor-Module-/131185485892?hash=item1e8b43a844:g:Wg0AAOxy9X5Tayc9

I used your MPU9250.h and main.cpp code from mbed, just ported to CooCox (gcc). Btw, Accel and Gyro data are all fine.

[kriswiner]

These boards usually work well, but not the purple ones.

Have you calibrated the mag with a figure eight motion to remove the bias
offset.

I really don't know why your mag is misbehaving. They are of course
sensitive to stray currents and the like but I have no trouble getting a
steady heading after bias calibration.

-----Original Message-----
From: honuoc [mailto:[email protected]]
Sent: December 15, 2015 6:27 PM
To: kriswiner/MPU-9250
Cc: Kris Winer
Subject: Re: [MPU-9250] One Question (#4)

I am using this board:
http://www.ebay.com/itm/SPI-IIC-MPU-9250-9-Axis-Attitude-Gyro-Accelerator-Ma
gnetometer-Sensor-Module-/131185485892?hash=item1e8b43a844:g:Wg0AAOxy9X5Tayc
9

I used your MPU9250.h and main.cpp code from mbed, just ported to CooCox
(gcc). Btw, Accel and Gyro data are all fine.

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

[honuoc]

What do you mean by calibration? is it calling the function "initAK8963(magCalibration)" ? if it were, I did.

[kriswiner]

No, it is using the function described here:

https://github.com/kriswiner/MPU-6050/wiki/Simple-and-Effective-Magnetometer-Calibration

-----Original Message-----
From: honuoc [mailto:[email protected]]
Sent: December 15, 2015 6:48 PM
To: kriswiner/MPU-9250
Cc: Kris Winer
Subject: Re: [MPU-9250] One Question (#4)

What do you mean by calibration? is it calling the function
"initAK8963(magCalibration)" ? if it were, I did.

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