Forum Rule: Always post complete source code & details to reproduce any issue!
Page 4 of 21 FirstFirst ... 2 3 4 5 6 14 ... LastLast
Results 76 to 100 of 502

Thread: Prop Shield Beta Test

  1. #76
    Senior Member
    Join Date
    Sep 2013
    Location
    Hamburg, Germany
    Posts
    891
    I'd also say that this is a good opportunity to write a Kalman filter that processes the prop shield's data, with GPS being an optional extra. I've never done that myself, though.

  2. #77
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,576
    I'm porting Freescale's Kalman filter and soft iron calibration code now....

  3. #78
    Senior Member
    Join Date
    Nov 2015
    Location
    Wales
    Posts
    579
    Quote Originally Posted by Ben View Post
    "Accelerometers are accurate in the long term" would mean they had no offset and zero drift
    I was under the impression they only drift with temperature which can be compensated for.. but it's been a while
    Most accelerometers have calibration routines that spoof 1g forces on each axis so you can remove the offsets

    Quote Originally Posted by PaulStoffregen View Post
    I'm porting Freescale's Kalman filter and soft iron calibration code now....
    Can you post a link to this, it'd be interesting to see Freescale's code

    I found a lot of use out of the kalman filter from the multiWii project
    Last edited by Xenoamor; 03-10-2016 at 02:10 PM.

  4. #79
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Paul,

    do you want pull.request for NXPMotionSense, or is it too early ?
    There are some functions missing, like reading the temperature data, altitude or pressure.

    And, should it contain only "raw" data, or additionally "human readable" data like C or F (=floats ?) ?

  5. #80
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,256
    Quote Originally Posted by Frank B View Post
    Paul,

    do you want pull.request for NXPMotionSense, or is it too early ?
    There are some functions missing, like reading the temperature data, altitude or pressure.

    And, should it contain only "raw" data, or additionally "human readable" data like C or F (=floats ?) ?
    Speaking as a potential user, I think having helper functions that convert the data into human readable values is useful.

  6. #81
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,710
    IMU now has a standard in Arduino - unfortunately they picked a different chip than PJRC did when he did this last year - but prior link new to IDE 1.6.8 shows a developed API set for their 6DOF IMU interface. onehorse has a technically well developed quaternion and more interface to his MPU9250 unit - would have been cool had it come 'wit' that chipset - not sure if it maps well or not.

  7. #82
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,256

    Cool

    I haven't actually started using the prop shield yet, but I had some thoughts on layout:

    1) I plugged in an LC that I had bought from PJRC with the pins soldered on, and it was a very tight fit. I had to slightly bend the pins so that it would fit (but that may be due to the breadboards I've been using). On Teensy's where I have soldered pins (using the generic pins I have from other builds) the pins are thinner, and fit easier.

    2) If you are not going to solder the speaker wires and VIN ouput for APA102 leds directly to the board, you probably want to use a right angle female header (such as https://www.pololu.com/product/2704) for at least the speaker connections since the USB plug otherwise would be in the way. If you want to use Frank B's proto board (https://oshpark.com/shared_projects/cYQjHdCu) to bring out the bottom pads on the 3.2, you would also need to use a right angle header for the connectors for APA102 LEDs. It may be useful if PJRC could stock similar headers (and perhaps include them in the retail package).

    3) For protoboards/breadboards, it seems a shame to use a big 30 pin breadboard on something that is meant to be small and handheld. Some of the boards I've been thinking about using include:
    • Tiny breadboards (https://www.adafruit.com/products/65 and elsewhere) -- I'll probably use these for initial code development;
    • Adafruit perma-proto for small mint tin: https://www.adafruit.com/products/1214 -- these are nice, particularly if it fits inside the Altoids small min tin (I haven't tried it yet) -- having the power rails in the middle saves on space, but it may mean you will need to solder in the wires before soldering the prop shield to the perma-proto board;
    • Adafruit quarter sized perma-proto (https://www.adafruit.com/products/589) -- a little wider than the above board, but it has separate power rails for easy connection;
    • Azzy's Electronics 1"x2" protoboard (https://www.tindie.com/products/DrAz...otyping-board/) -- this gives one row of pins for each side, with a middle section of 3 rows of pins.

  8. #83
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    I have built my "Prop Teensy" with my "Connectorboard v2" (link below, same size and price as before, but single-sided, without vias and no traces on the teensy-side) and the Prop Shield under the Teensy. This allows to acces all pins / solderpads and the button.

    I don't know if this can cause troubles with the magnetometer. I hope, not.

    It is very compact. Teensy + Connectorboard is still a bit smaller than the shield. Sorry, no picture allowed...

    https://oshpark.com/shared_projects/0T6ZdhhG
    Last edited by Frank B; 03-10-2016 at 08:00 PM.

  9. #84
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,256
    Frank, I suspect there isn't room, but it would be useful if you release another version if one of the sides of the silkscreen could indicate which pin is which.

  10. #85
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Good idea..

  11. #86
    Woo hooo, it arrived... thank you very, very much.

    I'm soldering in male headers tonight, I'll begin in earnest tomorrow.

    First observation, if we've received the "retail package", is that there's only enough header supplier for the side connections; I would suggest enough to fill all the connections to the Teensy are provided. Extra headers (may be angled as previously suggested) for the amp and LED port would be a bonus.

  12. #87
    Technical questions... what are the total power requirements esp. the 3.3v? Also, what's the differance between the two 3.3v connections?.. and what about the the two gnd and agnd? Sorry thinking about my power supply; using a Teensy 3.1 (lower 3.3v power output.) But also, I wish to run Teensy and Prop from and external source, cutting Teensy's usb supply.
    Last edited by cyborgv2; 03-10-2016 at 09:42 PM.

  13. #88
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,576
    Quote Originally Posted by Frank B View Post
    do you want pull.request for NXPMotionSense, or is it too early ?
    Probably a bit early. I'm very actively working on the PC-side calibration program. I had hoped to wrap this up last week... but everything always takes longer than anticipated!

    Here's where the cal program is at so far. If you compile on Linux without a custom built wxwidgets lib, use "make imuread" to build only the command line which opens a bare opengl window.

    https://github.com/PaulStoffregen/IMUread

    Quote Originally Posted by MichaelMeissner View Post
    Speaking as a potential user, I think having helper functions that convert the data into human readable values is useful.
    Yes, I like this too...

    Quote Originally Posted by defragster View Post
    IMU now has a standard in Arduino - ... - but prior link new to IDE 1.6.8 shows a developed API set for their 6DOF IMU interface.
    I'm not very excited by their API on the Curie board. It's very complicated.

    My guess is things will eventually settle to a simple API, perhaps like Adafruit is using?

    onehorse has a technically well developed quaternion and more interface to his MPU9250 unit - would have been cool had it come 'wit' that chipset - not sure if it maps well or not.
    My (behind schedule) plan involves a hybrid of stuff I recently put on github, and Freescale's library (minus the MXQ dependency) and that PC/Mac program to visualize the calibration process. Perhaps this is a little on the ambitious side, but I feel pretty good about making it work.

    Freescale's library already has really good Kalman-based sensor fusion and magnetic calibration algorithms. I'm working now to integrate those. I look very briefly at Onehorse's stuff a while back. Will give it another look next week. But I'm very sure we're going to go with Freescale's code for the Kalman filter.


    Quote Originally Posted by cyborgv2 View Post
    Technical questions... what are the total power requirements esp. the 3.3v?
    Good question. On 3.3V, not a lot. The sensors are a few mA when fully active. Flash write/erase might add a bit. I haven't really worried about this. Answers in the datasheets...

    Also, what's the differance between the two 3.3v connections?.. and what about the the two gnd and agnd?
    The two 3.3V pins are connected together. Likewise for the GND pins. AGND is only used for the audio signal. For details, see the schematic posted on msg #14.

  14. #89
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,710
    Quote Originally Posted by PaulStoffregen View Post
    ...
    I'm not very excited by their API on the Curie board. It's very complicated.
    ...
    I look very briefly at Onehorse's stuff a while back. Will give it another look next week. But I'm very sure we're going to go with Freescale's code for the Kalman filter.
    That API list looked very involved and HELPFUL - detecting/supporting all that will need lots of resources from the Curie setup.

    Perhaps the 9250 chip was cost prohibitive? - having picked the 'FXOS8700' probably ends up on a new path - the onehorse software maturity w/support for hardware fusion w/Cortex M0 had me buy in.
    Last edited by defragster; 03-11-2016 at 03:48 AM.

  15. #90
    Senior Member johnnyfp's Avatar
    Join Date
    Jan 2014
    Location
    New Zealand
    Posts
    260
    You probably want to use a Complementary Filter rather than a Kalman filter as it's less complicated than a Kalman, but has very similar properties. Easier for us mortals to understand.

  16. #91
    Senior Member onehorse's Avatar
    Join Date
    Apr 2014
    Location
    Danville, California
    Posts
    921
    Thanks Paul for the gift of the Prop Shield! I'll need some help figuring out what to do with the audio amplifier but I know what to do with motion and pressure sensors. I combined my separate sketches for these sensors into one more or less integrated sketch that parametrizes the registers, configures all the sensors, does some simple offset calibration and outputs the data to the serial monitor. It's been almost two years since I used these sensors and I forgot all of the cool motion detection built in. The sketch allows tap and double tap detection, rotation rate threshold detection and direction detection as well as portrait/landscape detection. It's really a lot of fun to see how the sensor board responds to various motions and it is infinitely configurable. So have fun!

    I still need to get the Madgwick and Mahony sensor fusion connected and add a simple magnetometer calibration. All straightforward. These would not be my first choice for small accurate sensors but they work well enough and have a lot of built in features that can be quite useful.

  17. #92
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,710
    C:\tCode\Prop\Teensy_Prop_Shield\quaternonFilters. ino:174:38: error: 'eInt' was not declared in this scope


    My bad - #if 0 those two functions in quaternonFilters.ino - as noted not connected.

    Showing results - seems to see the taps too
    Last edited by defragster; 03-11-2016 at 08:27 AM.

  18. #93
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,576
    Quote Originally Posted by onehorse View Post
    I'll need some help figuring out what to do with the audio amplifier...
    The audio amp is really simple. Just use pinMode & digitalWrite high on pin 5 to enable it. Then use the audio lib to send sound to the DAC pin. If you start with any of the audio lib examples, delete all the SGTL5000 stuff, and change AudioOutputI2S to AudioOutputAnalog (i2s vs dac in the design tool).

  19. #94
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,256
    Paul, IIRC parts of the Audio library are Teensy 3.2 (and 3.1) only, due to the use of M4 instructions. The anti-static bag the shield came in says it is compatible with the LC and 3.2. When it is officially released, you may want to clarify what works on the LC (i.e. the 'wit' parts), and what doesn't (audio using the audio library).

    Or perhaps there is a simple library that works on the LC that plays pre-recorded sounds from both the shield's flash memory and from the program flash memory with 'const'.

    Or perhaps officially limit it to the 3.2.

  20. #95
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,576
    Thanks. That's a good point. Eventually I'm going to port parts of the audio lib to LC, and much prep work has already been done, but it's still not actually working.

  21. #96
    Senior Member onehorse's Avatar
    Join Date
    Apr 2014
    Location
    Danville, California
    Posts
    921
    I added the Mahony and Madgwick sensor fusion filters to the Teensy Prop Shield code; I am getting 660 Hz fusion rates at 72 MHz on a Teensy 3.1. This is a little lower than I would expect but adequate. There must still be some delays built in that can be eliminated for faster fusion speeds.

    I also got the mag calibration almost done, just need to cast the properly scaled mag bias values into the offset registers. The mag values in general seem about a factor of four too low. Not quite sure why yet.

  22. #97
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    You should use sqrtf instead of sqrt. sqrt is for doubles.

    Edit: same atan, asin or other functions.... use atanf and asinf !
    Last edited by Frank B; 03-11-2016 at 06:12 PM.

  23. #98
    Senior Member onehorse's Avatar
    Join Date
    Apr 2014
    Location
    Danville, California
    Posts
    921
    Yeah, you're probably right. Too bad Teensy doesn't have an FPU!

  24. #99
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    It will have.. but float.

    Even with FPU for doubles, that "f" functions are better, since all your vars are float - otherwise they are converted to double and back to float, i think (<- is this correct, Michael ?)

    Your code looks good. What's the license of the code from the Freescale-Appnotes you used ?
    Last edited by Frank B; 03-11-2016 at 07:29 PM.

  25. #100
    Senior Member
    Join Date
    Jun 2013
    Location
    So. Calif
    Posts
    2,828
    For (most) ARM Cortex M MCUs that have hardware floating point, it's most always a 'single' precision type. The word 'double' yields code for single. It's said that for an MCU without hardware floating point, if you use 'single' and don't need the precision of double, then there's a big size and speed advantage in being explicit with double. Or redefine its macro.

Posting Permissions

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