Prop Shield Beta Test

Status
Not open for further replies.
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.
 
"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

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:
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 ?) ?
 
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.
 
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.
 
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:
 
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:
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.
 
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.
 
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:
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

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

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.


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.
 
...
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:
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. :)
 
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.
 
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:
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).
 
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.
 
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.
 
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.
 
You should use sqrtf instead of sqrt. sqrt is for doubles.

Edit: same atan, asin or other functions.... use atanf and asinf !
 
Last edited:
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:
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.
 
Status
Not open for further replies.
Back
Top