Prop Shield - large drift

Status
Not open for further replies.

orbitronics

Well-known member
I just got two prop shields delivered, and i've got 'orientation' uploaded and the corresponding pde file up, but i've noticed (seeing the sensor data) that there's a very large drift; it takes about 8 seconds to do a 90 degree turn yaw (i noticed it's only the yaw that has terrible drift). this is obviously when the hardware is still.

Any ideas? I did calibrate too.
 
Have you given Kris Winer's sketch yet. A couple things missing from the current implementation of the prop-shield lib is a zeroing of the gryo's and accelerometer calibration which may be contributing to the drift. Here is the link: https://github.com/kriswiner/Teensy_Prop_Shield. Also, if you are using Madgwick filter try using Mahoney or vice versa.
 
I just got two prop shields delivered, and i've got 'orientation' uploaded and the corresponding pde file up, but i've noticed (seeing the sensor data) that there's a very large drift; it takes about 8 seconds to do a 90 degree turn yaw (i noticed it's only the yaw that has terrible drift). this is obviously when the hardware is still.

Any ideas? I did calibrate too.

It has been over a couple of months since I received my prop shield and piggy backed it onto a Teensy 3.6 with proper headers for trial, so my memory maybe a little hazy on this subject.

Like you I saw large gyro drift which started slow and speedup the longer I left it standing stationary. I disconnected power and reconnected the power and noticed that it was now giving the drift in the opposite direction then slowed and reversed direction and slowly speedup again.

This I thought might be due to internal heating of the gyro chip.
 
Paul created a Custom GYRO calibration program - the Teensy runs and the PC code gathers the output data and shows a mapping of the points hit. When the bounds of the are well filled there is a set of calibration data at hand that is written into the PROP Flash for recall. When the user sketch is started that calibration data is loaded so gravity is understood relative to the other 6 DOFs. I haven't worked with that since the Prop went through Beta - but AFAIK that is still the way to calibrate and work with the PROP shield.
 
Paul created a Custom GYRO calibration program - the Teensy runs and the PC code gathers the output data and shows a mapping of the points hit. When the bounds of the are well filled there is a set of calibration data at hand that is written into the PROP Flash for recall. When the user sketch is started that calibration data is loaded so gravity is understood relative to the other 6 DOFs. I haven't worked with that since the Prop went through Beta - but AFAIK that is still the way to calibrate and work with the PROP shield.

Just to be clear I too used the calibration tool and tried different clock settings.
The effect of reducing the clock from 180 MHz to 48 MHz on the Teensy 3.6 was very noticeable.
It reduced the drift, but it was still present.
 
Last edited:
Paul created a Custom GYRO calibration program - the Teensy runs and the PC code gathers the output data and shows a mapping of the points hit. When the bounds of the are well filled there is a set of calibration data at hand that is written into the PROP Flash for recall. When the user sketch is started that calibration data is loaded so gravity is understood relative to the other 6 DOFs. I haven't worked with that since the Prop went through Beta - but AFAIK that is still the way to calibrate and work with the PROP shield.
I followed this exactly as it's on the prop shield page - i still get the drift.
 
I can't compile Madgwick/MahonyIMU as i get the following error,

Code:
Arduino: 1.8.3 (Mac OS X), TD: 1.37, Board: "Teensy 3.2 / 3.1, Serial, 96 MHz (overclock), Faster, US English"

/Applications/Arduino.app/Contents/Java/hardware/teensy/avr/libraries/NXPMotionSense/examples/MadgwickIMU/MadgwickIMU.ino:7:26: fatal error: MadgwickAHRS.h: No such file or directory
compilation terminated.
Error compiling for board Teensy 3.2 / 3.1.

This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.

I am opening these form the examples pane so a bit confused why it's not including the header files. This is also vanilla and fresh installs of both arduino and teensyduino.

Also, i had noticed, reducing the clock makes the drift very very low, UNTIL i start moving the prop shield, then the drift speeds up to the unacceptable volume.

Trying Kris's code now.
 
Have you given Kris Winer's sketch yet. A couple things missing from the current implementation of the prop-shield lib is a zeroing of the gryo's and accelerometer calibration which may be contributing to the drift. Here is the link: https://github.com/kriswiner/Teensy_Prop_Shield. Also, if you are using Madgwick filter try using Mahoney or vice versa.

I've given this a go, is there a trivial way to get more user friendly data out, or to link it to the pde visualiser ?

Judging by the serial terminal output, there's minimal drift, but the numbers are slightly fluctuating - i have no idea if this is acceptable:

https://pastebin.com/VRHwKLzi
 
Last edited:
Madgwick and Mahoney are separate libraries that you have to install if you are using the NXPMotionSense Examples: https://github.com/PaulStoffregen/MahonyAHRS and https://github.com/arduino-libraries/MadgwickAHRS. Yes you can link it to the visualizer. Take a look at the visualizer sketch in the nxpmotionsens example and just adjust your output in Kris's code to match. It should work.

i managed to do that but kris's code has a kind of 0.7s delay per reading, any ideas on how to get around that ?
 
If you look at about line 509 you will see there is a built in delay between prints:
Code:
   if (delt_t > 500) { // update LCD once per half-second independent of read rate
you can reduce this to some other value. If you look at his print of the actual update rate its about 1678Hz on a T3.5. If you leave in all the prints that will be most of the other delay you see. Print to serial monitor eats up a lot time.
 
If you look at about line 509 you will see there is a built in delay between prints:
Code:
   if (delt_t > 500) { // update LCD once per half-second independent of read rate
you can reduce this to some other value. If you look at his print of the actual update rate its about 1678Hz on a T3.5. If you leave in all the prints that will be most of the other delay you see. Print to serial monitor eats up a lot time.

thank you, i changed that delay to 1, i only have the yaw, pitch and roll outputting through the uart (which i can also read via serial terminal), it's still a bit slow, roughly 200ms, and the values are a bit jumpy, makes the 3d model very poppy. did you have success with kris's code?
 
Yeah. I haven't really tried it the way you are. I am in the process of converting it over to a lib format but that is a ways off. So I am getting into more and more of the details. You can try a do an issue over on the GitHub page. KW tends to be very responsive.
 
Just wanted to let you know that I developed a library from Kris Winer's code for use with the prop shield. I also modified the FreeIMU Calibration GUI (does magnetometer and accelerometer) for use with the prop shield. I noticed the drift and will be working on that in future releases (taking some pieces from the FreeIMU lib and adding them). If interested you can check it out here: https://github.com/mjs513/PRJC-PropShield-Practice-Sketches/tree/master/MotionSense
 
Just wanted to let you know that I developed a library from Kris Winer's code for use with the prop shield. I also modified the FreeIMU Calibration GUI (does magnetometer and accelerometer) for use with the prop shield. I noticed the drift and will be working on that in future releases (taking some pieces from the FreeIMU lib and adding them). If interested you can check it out here: https://github.com/mjs513/PRJC-PropShield-Practice-Sketches/tree/master/MotionSense
Great, i'd be very interested in testing this as i'm still having issues. Any ETA?

I modified Kris's output to just show pitch roll and yaw, injecting it to the existing pjrc processing project to get some 3d output, but there's incredible latency doing that. It's almost like the data is coming too slowly, even when i change the delay value to sub 10ms.
 
Need a few more days to get it all working with processing which I haven't used for awhile. Will keep you posted
 
Ok. Got it all updated. There are two processing GUIs you can use that I added to the MotionSensor folder on the GitHub page. Give it a try and let me know. https://github.com/mjs513/PRJC-PropShield-Practice-Sketches/tree/master/MotionSense

Here are a couple of screen shots:
Mainwindow.PNG
Setup.PNG
 
Last edited:
Hi All

I did some bug fixes and added a filter on the accel and magnetometer to reduce the jitter that you normally see. Haven't done a long term test but yaw drift seems to be minimized now.
 
Hi All

I did some bug fixes and added a filter on the accel and magnetometer to reduce the jitter that you normally see. Haven't done a long term test but yaw drift seems to be minimized now.

Hello! Sorry for being quiet, i've just had a pile of other stuff on and want a clear head when i get back into this (which is a 2nd priority atm). Thanks for letting me know of your progress, as far as i'm concerned, if your code is basically like how the pjrc setup/tutorial describes but without that horrible drift, then it'd be perfect for my use.
 
@orbitronics. It is very similar. The primary difference is that there are two methods for calibration. The first is the built-in version that @onehorse uses in his sketch and the second is via the calibration program which does a magnetometer and accelerometer calibration which you save to a file in the library folder. I pretty much use this option. It is explained in the GitHub readme for the library. There are also one other library you will need to copy to your library folder as well (AP_FILTER). The processing sketches are in the processing folder.
 
@orbitronics. It is very similar. The primary difference is that there are two methods for calibration. The first is the built-in version that @onehorse uses in his sketch and the second is via the calibration program which does a magnetometer and accelerometer calibration which you save to a file in the library folder. I pretty much use this option. It is explained in the GitHub readme for the library. There are also one other library you will need to copy to your library folder as well (AP_FILTER). The processing sketches are in the processing folder.

Sorry for not getting back to you sooner. I tried having a look at your library but was having a little trouble setting it up.

Let me know if you have time to write a short idiots guide to getting up and running with this and i'll be sure to let you know how i get on.
 
The write-up on the GitHub page gives a pretty good over view. Anything specific you are having problems with that you would like me to focus on?
 
@mjs513, I'm interested in using your psIMU library. I get a compile error due to missing "CommunicationUtils.h". That doesn't seem to be in the AP_FILTER library - where can I find it?
Thanks,
TE
 
@techlin. Thanks for posting about the missing files. I just uploaded them to the GitHub page. They now reside within the psIMU folder. It should now compile.

Thanks
Mike
 
Status
Not open for further replies.
Back
Top