Prop Shield Beta Test

Status
Not open for further replies.
Flash:
@Paul, i think we can replace all the delayMicroseconds in that lib with faster delays - but, maybe, this needs some testing with other chips ?

Edit: just tested it with with the W25Q64FV. Indeed, it works.
The Datasheet mentions a delay of 5 ns "relative to clk" - with SPI @ 30MHz a clk is 33ns.
 
Last edited:
Flash:
@Paul, i think we can replace all the delayMicroseconds in that lib with faster delays - but, maybe, this needs some testing with other chips ?

Edit: just tested it with with the W25Q64FV. Indeed, it works.
The Datasheet mentions a delay of 5 ns "relative to clk" - with SPI @ 30MHz a clk is 33ns.

FWIW, I re-ran my SerialFlash tests on prop shield with teensy 3.1 @120mhz and experienced no problems ...
 
Nice !
Seems like a very useful shield ! Eager to test it out and thanks for putting me in the list !
 
Wow! Very rare, such a fast delivery ... thank you, guys! But when I see the size of the PCB - the question arises: "When will we be able to transport this via the network ... ?" :cool:
 
Lucky you in Germany... To France, it seems to take more time. My small packet left the USPS distribution center in Los Angeles only yesterday...
 
Got Paul's Magnometer_Test code running after commenting out the code for the devices I don't have:
Code:
Magnetic TestBegin FXOS8700
id = C7
FXOS8700CConfigured
FXOS8700:  -10.20  -6.40  78.00
FXOS8700:   -9.60 -24.90  59.80
FXOS8700:    1.40 -37.70  70.20
FXOS8700:    2.50 -19.10  96.10
FXOS8700:    7.80 -40.70  91.20
FXOS8700:    2.90 -17.40 104.00
FXOS8700:   10.90 -17.90  97.20
FXOS8700:   -7.10 -14.50  81.00
FXOS8700:  -12.10 -13.70  60.10
FXOS8700:   -5.80 -33.20  64.90
FXOS8700:    2.10 -35.50  86.30
FXOS8700:    5.50 -16.50 103.10
FXOS8700:  -24.40 -49.70 101.80
FXOS8700:  -34.70  24.70  97.30
FXOS8700:  -54.00  48.40 108.60
FXOS8700:  -81.30 149.10 168.20
FXOS8700:   86.20  18.60 302.50
FXOS8700:   81.30  28.70 301.20
FXOS8700:   43.40  96.50 270.80
FXOS8700:  -25.10 167.90  84.00

Quick test was performed waving around the Teensy 3.2 with Prop Shield by the USB cable.

By the way, I went ahead and soldered the headers that came with the Prop Shield, but if I thought about it some more, I might have used different headers, like long pin female machine headers or something. For testing, I'll need to figure out a convenient way of getting to some of the Teensy GPIO.
 
I gather the FXOS8700 has a 3-axis accelerometer and a 3-axis magnetometer. I don't know the details but is your code reporting the X,Y,Z components of the local magnetic field? If it is a uniform field I would expect the magnitude of the vector (sqrt of sum of squares) to stay the same, but clearly (-10, -6, 78) doesn't have the same magnitude as (81, 28, 301). Were you waving it near a magnet or large chunk of metal? Or the three axes have very different sensitivities, and have not been calibrated (normalized)?
 
Here's newer code to read all the motion sensors.

https://github.com/PaulStoffregen/NXPMotionSense

The magnetic sensor has significant offsets which require calibration to remove. If you install it near any ferrous metals, it also need "soft iron" calibration. I've been working on a nice GUI-based tool for this, but it's not quite ready. For now, I'd recommend using only the accelerometer and gyroscope as 6DOF.

I'd hoped to get a 1st beta published today... but Arduino just made a 1.6.8 release, so for right now I've got a put together a Teensyduino beta to support it.
 
One discrepancy I noticed is that the code assembles a 16-bit value, but the datasheet says we're dealing with two 7-bit quantities.
 
I see the data sheet for the NXP FXAS21002 turn-rate sensor http://cache.nxp.com/files/sensors/doc/data_sheet/FXAS21002.pdf?pspll=1 mentions a rate sensing noise of 0.025 (degrees/sec) / sqrt(Hz). If I'm reading that right, the noise level with one second integration is around 0.025 degrees per second, which is a rotation rate of one full turn in 4 hours (!) In other words, could clearly resolve the rotation rate of the minute hand of a clock (if it moved smoothly, instead of ticking), with a noise level only 6x more than the rotation of the earth. That seems like a phenomenal degree of sensitivity. The offset drift with temperature, 0.02 (X,Y) and 0.01 (Z) deg/sec per degree C also seems good. I look forward to trying this thing out!
 
Last edited:
I'm pretty sure it's not good. There's a constant offset in addition to noise. Maybe we can characterize and calibrate it out? So far, I haven't done that...
 
Paul noted 1.6.8 IDE release - I saw this: Reference.CurieIMU

<edit - add> :: The Curie IMU library enables an Arduino or Genuino 101 to read the output of the on-board IMU (Inertial Measurement Unit) containing an accelerometer and a gyroscope and elaborate the raw data coming from it.
 
Last edited:
Hey,
I just noticed my name on the beta list and am emailing Robin. Very exciting, can't wait to put it through its paces.

I can't tell from the schematic whether this will be mechanically and electrically compatible with the LC or just the 3.2. Is it intended for both?

I'd also love to hear a little backstory on how the choices were made to include the various peripherals. I'm sure everybody has their own set that they'd love to see...

-dean
 
Blackketter: The label on the Prop board anti-static envelope says it is for Teensy 3.2 and LC. I imagine you might not be able to use some of the advanced audio stuff on the LC, and of course the LC runs at a slower speed than the 3.2 depending on how many calculations you need to do for the various sensors.

FWIW, I did put my LC with pins soldered into the prop board, and the i2c scanner was able to see the 3 sensors.
 
Last edited:
Got my board, Just testing it now, will update if I find any software issues.

Comment on the Hardware. Would be nice to have a duplicate program switch added to the board. In the configuration of Pro board under the Teensy, The Teensy's lower pads are no longer readily available, you can solder out some wires but there is no or little room to break them out as the IO pins encase the the area, specially with the speaker and Power pins potentially connected.
If we then mount the Teensy underneath so that we can gain access to the pads we then can't access the Program Switch.

The mounting holes are a little tight for generally available hardware, Would be good to have M3 or 1/8 size holes maybe. Could you get away with removing the 5v and GND at the speaker end and pushing the holes out? and thus larger?

The 5v and GND at either end of the board could potentially lead to confusion with incorrect connections as they are opposite to each other, where as if they where both 5v top GND bottom then you could also easily daisy chain.

The X-Y Silkscreen, might be worth putting a copy underneath as well, because as soon as the Teensy is put on top it will hide the direction.

-jfp
 
Johnnyfp -- you could always mount a wire connecting the program pin on the back to a button, and connect it to ground to move the program switch away from the Teensy. I believe the only pin you need to connect on the back set of pins is the DAC pin if you want to use the speaker.

<edit>
In trying it, I found 2-56 screws (US imperial measures) to work well for the mounting holes, though 2-56's are small enough I lost 3 hex nuts under the desk in trying to attach them.
 
Last edited:
My unit working! I cut removed a onehorse ESP unit - full pinned the T_3.2 and headers on the Prop.Shield (with 9 selectively long pins to hit the ESP again)

> SerialFlash ( RAWhwTest, EraseEverything from GitHub )
> i2c scanner found three device ID's
> 9DOF read and debug spew runs.
> I quick hacked the onehorse P#64 code to get something that is numbers? Missing details - did I read these are 7 bit values? Probably have to read some words there . . .
<edit>: these zero values cause the d1[] values to come up zero:
Code:
MPU9250magCalibration[3] = {0, 0, 0};  // Factory mag calibration and mag bias
Mag Calibration: Wave device in a figure eight until done!
Mag Calibration done!
Mag Cal_d1:0.00
Mag Cal_d1:0.00
Mag Cal_d1:0.00
__________Mag Cal_d2:0.61
__________Mag Cal_d2:1.71
__________Mag Cal_d2:1.30

** On Windows with Python 2.7.11 (needed for ESP8266 on Arduino) I didn't have pyserial needed for SerialFlash\..\rawfile-uploader.py
I couldn't find a way to install it - this link showed me this that worked from a CMD prompt:: pip install pyserial
pyserial-for-python-2-7-2
 
Last edited:
Received mine today. Probably gonna start testing friday afternoon, when my students are working on their own Teensy projects :D .
 
A kalman filter should be used to keep track of heading. This will automatically compensate for errors.

Accelerometers are accurate in the long term
Gyroscopes in the short term
The magnetometer will correct the drift

Quaternions will need to be used to avoid gimbal lock.

You won't find any of the sensors particularly useful on their own unless you wanted something simple like a tilt sensor

I don't know about this specific barometer but normally you have to input your local barometer pressure for your area on that day to get any reasonable data from them. A more accurate reading can be achieved by also using a temperature reading from ground level
 
Last edited:
A kalman filter should be used to keep track of heading. This will automatically compensate for errors.
Yes, a extended kalman filter is needed, as the angualar movement introduces nonlinearity. However...
Accelerometers are accurate in the long term
Gyroscopes in the short term
The magnetometer will correct the drift
...You are correct about the gyro and magnetometer part, but "Accelerometers are accurate in the long term" would mean they had no offset and zero drift. To my understanding accelerometers are like gyros as they measure the derivative of the physical state (location and direction respectively). So Accelerometers are the "short term" input for the filter, and GPS would be the drift corrector as it provides absolute position (with great uncertainty, but that's what the kalman filter will take care of). So with the Prop Shield having no GPS, I think it's important to provide a routine to build a calibration table at least for the accelerometer, preferably at several different temperatures, to compensate offset and drift as good as possible.

I'm sorry all I'm providing so far is theoretical babble - my shield is still on it's way, but it's already in Germany, yay :)

-Ben
 
Status
Not open for further replies.
Back
Top