Forum Rule: Always post complete source code & details to reproduce any issue!
Page 1 of 2 1 2 LastLast
Results 1 to 25 of 32

Thread: Prop Shield - large drift

  1. #1

    Prop Shield - large drift

    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.

  2. #2
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,941
    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.

  3. #3
    Junior Member
    Join Date
    May 2017
    Posts
    8
    Quote Originally Posted by orbitronics View Post
    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.

  4. #4
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    7,072
    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.

  5. #5
    Junior Member
    Join Date
    May 2017
    Posts
    8
    Quote Originally Posted by defragster View Post
    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 by tarzan; 07-03-2017 at 10:26 AM.

  6. #6
    Quote Originally Posted by defragster View Post
    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.

  7. #7
    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.

  8. #8
    Quote Originally Posted by mjs513 View Post
    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 by orbitronics; 07-04-2017 at 11:18 AM.

  9. #9
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,941
    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.

  10. #10
    Quote Originally Posted by mjs513 View Post
    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 ?

  11. #11
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,941
    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.

  12. #12
    Quote Originally Posted by mjs513 View Post
    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?

  13. #13
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,941
    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.

  14. #14
    Junior Member
    Join Date
    May 2017
    Posts
    8
    Judging by the serial terminal output, there's minimal drift, but the numbers are slightly fluctuating - i have no idea if this is acceptable.
    To better understand the data you are receiving try displaying it on a graph.

    Advanced Arduino Telemetry and Data Visualization
    https://www.youtube.com/watch?v=r693Xb9t4dI

  15. #15
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,941
    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-PropS...er/MotionSense

  16. #16
    Quote Originally Posted by mjs513 View Post
    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-PropS...er/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.

  17. #17
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,941
    Need a few more days to get it all working with processing which I haven't used for awhile. Will keep you posted

  18. #18
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,941
    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-PropS...er/MotionSense

    Here are a couple of screen shots:
    Click image for larger version. 

Name:	Mainwindow.PNG 
Views:	70 
Size:	61.0 KB 
ID:	11018
    Click image for larger version. 

Name:	Setup.PNG 
Views:	52 
Size:	42.1 KB 
ID:	11019
    Last edited by mjs513; 07-15-2017 at 10:54 PM.

  19. #19
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,941
    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.

  20. #20
    Quote Originally Posted by mjs513 View Post
    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.

  21. #21
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,941
    @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.

  22. #22
    Quote Originally Posted by mjs513 View Post
    @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.

  23. #23
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,941
    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?

  24. #24
    Junior Member
    Join Date
    Aug 2017
    Posts
    7
    @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

  25. #25
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,941
    @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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •