PDA

View Full Version : Prop Shield Beta Test



Pages : 1 [2] 3

mortonkopf
03-18-2016, 10:36 AM
Seriously all I need to do is make APA102 LEDs work with the teensy so should I wait or use the OCTOWS2811 shield? I don't need the gyro or the sound amplifier.
Hi 3D Joy, the octows2811 adapter is set up for three wire leds (such as ws2811/12/b) where data and clock are fed down the same line. APA102 leds are four wire where clock and data are separate wires. Sorry if I have misunderstood.

mortonkopf
03-18-2016, 11:23 AM
FWIW - Mine works.
I've put hours on my AMP and it is working well from +/- 0.5W speaker and headphone. it is fully socketed to a T_3.2.
@defragster, can you please clarify, exactly how to use the AMP connections? treat me like I don't have a clue (guess what, I don't have a clue). I would like to test the AMP with led output at the same time.

MichaelMeissner
03-18-2016, 11:46 AM
Michael, do you mean the 5DCG pin area when you say APA102 connection?
Regarding your test on 'neopixels', was this from the 5DCG pins?

Yes, I meant the 5DCG pins at the back of the shield (with the USB connection being on the top) that bring out pins 11 and 13 translated to VIN (normally 5v), and are presumably there for APA102 (dotstar) lights. I will try it later with wires properly soldered in place to see if I can use the lights on it.

KurtE
03-18-2016, 01:51 PM
Yes, I meant the 5DCG pins at the back of the shield (with the USB connection being on the top) that bring out pins 11 and 13 translated to VIN (normally 5v), and are presumably there for APA102 (dotstar) lights. I will try it later with wires properly soldered in place to see if I can use the lights on it.
I hooked up my dotstar there. What I did was to solder in breakout pins to those 4 pins, then used a servo extension cable, where on one end I swapped the Red and yellow pins in a connector. Plugged one end onto the DCG (not 5 pin), and plugged other end into connector of Dotstar (after I moved it to the input side of the strand). Again not on VCC pin... My dotstar also had power wires coming out, so I hooked it up using the adafruit connector: https://www.adafruit.com/products/368
And power mine with a 5v 4amp wall wart that came with one of my Odroid Xu4's. This all appears to work fine. Note: the strand test also appeared to work without power connected to the strand but the leds were pretty dim...

I have also been tempted to try using a Neopixel instead of a dotstar. But as the external memory also uses the same SPI lines, with a different chip select, not sure if one could get both to work.

defragster
03-18-2016, 03:48 PM
@defragster, can you please clarify, exactly how to use the AMP connections? treat me like I don't have a clue (guess what, I don't have a clue). I would like to test the AMP with led output at the same time.

@mortonkopf :: Hopefully this does it - I tried it and it worked - was too simple . . .

The AMP pins are the ones on the USB end. The +/- (PLUS/MINUS) inner two pins go to corresponding speaker lines ( I saw 8ohm speaker requirement ) - or to the Active/GND lines on a set of headphones. (These +/- are inside and not used with the outer 5V and GND for simple audio speaker connect.)

Once you have the physical connection you have to enable the electrical drive on those pins in the sketch with Pin_5 Output High - my use on Talkie here (https://forum.pjrc.com/threads/33446-Talkie-speech-library?p=99736&viewfull=1#post99736):



pinMode(5, OUTPUT);
digitalWrite(5, 1);//Enable Amplified.
// analogReference(INTERNAL); // drop volume level :: OPTIONAL


If you can't get that to work let Paul know ASAP . . . I just now understand why 'AMP' is on the silkscreen - I read it and used it but never associated it to the label, same for pin_7 and LED - makes sense now. My board has been surely abused as I put wire ends in and out of +/- with no solder too many times on the live circuit and no problems so my board is robust and functional - like all my Teensy's so far way too much loose wire fondling on the live board and no damage yet.

{ < Message to our Sponsor > :: Paul good work on the silk screen TOP and BOTTOM. I was thinking of the end pins - but now see the noted items above in context after days of use - A card/sheet would really tie all that together. }

Paul: Outside the AMP pins are 5V and GND - What's the idea there? Are those for feeding in power to drive the LED's at the other end? Are they common to VIN?

mortonkopf
03-18-2016, 04:32 PM
Thanks for that, will have a bash at it now.

Ben
03-18-2016, 04:34 PM
Are they common to VIN?

Yes, the 5V pins on both ends are connected to each other and to the Teensy's Vin pin.

Edit:


The AMP pins are the ones on the USB end. The +/- (PLUS/MINUS) inner two pins go to corresponding speaker lines ( I saw 8ohm speaker requirement ) - or to the Active/GND lines on a set of headphones. (These +/- are inside and not used with the outer 5V and GND for simple audio speaker connect.)
Be aware that you should not use the amp output as an input to any active circuitry, because it is a bridged amp configuration. This includes Headphones with noise cancelling, bluetooth and cordless headphones. Basically anything that has either a power input or a battery is not suitable.

Edit2:
When I saw "Led" on the silkscreen I searched for an led in the schematic for a good minute before I realised. Maybe change the Pin description to 5Vbuf or something? Or it was clear to everyone and I was just a bit slow on the uptake :cool:

Edit3: :rolleyes:
I updated the rolling average gyro test program. I will add rolling standard deviation once I remember how to do that recursively and without a 1000-member array. I *plan* to expand this to the accel and mag once it works for gyro and I'll propably change the data types from float to the original raw integers. My intention is to build a useful troubleshooting tool to pinpoint problems with the IMU sensors. Comments and commits welcome

-Ben

KurtE
03-18-2016, 06:57 PM
Thinking out loud, about magnetometer and calibration,

I have played around a little, with a couple of IMUs. As I mentioned, I have an Adafruit BNO055 on one of my boards, which I am just starting to experiment with.

But before this, I have a Sparkfun Razor IMU that was on one of my Hexapods, that I was (will be again soon) running ROS on. I have seen some reports of people having issues getting the magnetometer to calibrate. If I remember correctly the Ros wiki (http://wiki.ros.org/razor_imu_9dof#Calibrating_the_magnetometer) for it, had you do the calibration after you mounted your IMU on your Robot.

I know another person had better luck with hers when she printed a 3d stand and moved the Razor a few inches away from the rest of her electronics and servo motors.

So might be interesting to do some tests to see how much some of the other stuff influences the data, like if the Audio amp is active or you are running the Leds.

Again just thinking out loud.

mortonkopf
03-18-2016, 06:57 PM
@Paul - pin 2 on octows2811 adaptor seems to be interfered with when also using the prop Shield. I have swapped out the prop shield with attached T3 and replaced with solo T3 and the adaptor runs rainbow seamlessly. Only Pin2 seems to be affected.

JBeale
03-18-2016, 07:37 PM
I will add rolling standard deviation once I remember how to do that recursively and without a 1000-member array.

Is this what you're thinking of? http://jonisalonen.com/2014/efficient-and-accurate-rolling-standard-deviation/

MichaelMeissner
03-18-2016, 08:02 PM
@Paul - pin 2 on octows2811 adaptor seems to be interfered with when also using the prop Shield. I have swapped out the prop shield with attached T3 and replaced with solo T3 and the adaptor runs rainbow seamlessly. Only Pin2 seems to be affected.

IIRC, on the schematic pin 2 is used by the i2c devices on the prop shield connecting the INT1 pins. I presume this is so the i2c devices can signal if there is I/O available which you can use attachInterrupt to get notified immediately. I tended to use pin 2 as a general switch, since the normal tactical switch is 0.3" long, and would connect directly to ground.

Ben
03-18-2016, 11:16 PM
Is this what you're thinking of? http://jonisalonen.com/2014/efficient-and-accurate-rolling-standard-deviation/
Yes, thank you for the link. I remembered it made use of binomial expansion. I'll also rewrite the mean calculation, I have a feeling the current rather crude implementation is prone to rounding errors. OTOH, the data rate from the sensors is slow enough to calculate with double precision... I don't know yet how I'll do this.

IIRC, on the schematic pin 2 is used by the i2c devices on the prop shield connecting the INT1 pins. I presume this is so the i2c devices can signal if there is I/O available which you can use attachInterrupt to get notified immediately. I tended to use pin 2 as a general switch, since the normal tactical switch is 0.3" long, and would connect directly to ground.
I don't see many applications where you'd need both the Prop Shield and the OctoWS adaptor in the same project. I think the days of the WS8211 leds are coming to an end, the new APA102s are much easier to use (IMHO) and can be connected to the Prop Shield directly.

@defragster: thanks for the data dump, yes I can see what I was looking for. Your gyro recovers, mine introduces offset after shaking. That seems to be the cause for the odd behaviour of my Prop Shield.

GremlinWrangler
03-18-2016, 11:38 PM
My Prop board made it all the way around the world so get to join the fun now.

MichaelMeissner
03-18-2016, 11:43 PM
In terms of APA102's supplanting WS2812B's, I dunno. Right now, you can't get things like rings in APA102 format, but for use with the prop shield, it might be rare to use the octows2811 shield as well. One use case might be a big light display that needs some sound using the amplifier.

Also, so far, you don't see things like rings or separate leds in the APA102 format (but for those, you would likely just hook it to the prop shield directly, and not use the octows2811).

defragster
03-19-2016, 07:49 AM
@Ben - Glad it helped ... if only to show your test was sane and my hardware worked. Would it help to have a millis() runtime indicator on each line for reference? With that I could have saved the whole text file with just a list of timestamps for notes - instead of cutting a few lines - losing context in notepad as I hit "F5" for the time stamp.

@MM - you can buy bulk 5x10 sheets of APA102's at Amazon (http://www.amazon.com/Mokungit-100Pcs-APA102-Heatsink-White/dp/B01AHC9NDK/ref=pd_sim_sbs_267_3), and Adafruit has just a few non-linear things so far.

Ben
03-19-2016, 04:56 PM
@MM: I see your point. Just to be clear, I didn't mean to sound offensive. It's sometimes hard to not sound harsh without nonverbal communication, like in a forum. :)

mortonkopf
03-19-2016, 05:17 PM
Well, seeing as this is Beta Testing, I put the octows2811 adaptor with the shield as thats what someone might want to do. Best to head these things off at the pass, and put it up in clear bold lettering on the prop Shield page that this is not a solution. Its difficult to determine now how users may have thought of a potential solution to a project brief. Actually, I am enjoying a bit of mix and match, it is giving some ideas.

Re the apa102 vs ws2811, different beasts, both at the moment with a strong role on the 'spectrum' of leds.

Right, back to the workbench.

JBeale
03-19-2016, 11:48 PM
The pressure sensor / temperature sensor on the prop shield seems to work OK.
I used the "MPL3115A2 Barometric Pressure Sensor Library Example Code" from Nathan Seidle/Sparkfun, modified to do some averaging and print out one point every 10 seconds. The pressure reads about 4 millibar lower than the nearby airport reports. Here is a plot of 18 hours of pressure & temp data covering from 10:30 pm last night to 4:30 pm this afternoon. Sensor was indoors; in the morning we opened the windows, causing more temperature fluctuations.
6748

PaulStoffregen
03-20-2016, 12:04 AM
I added code to CalibrateMagnetometer.ino to blink the LED slowly while the sketch runs. When a config is received and written to EEPROM, the Led blinks fast for two seconds.
https://github.com/PaulStoffregen/NXPMotionSense/compare/master...Ben-Rheinland:master

Thanks! I've merged it.

https://github.com/PaulStoffregen/NXPMotionSense/commit/6494caffc5e046b7663b6577b6fc2ec27567a934

blackketter
03-20-2016, 01:28 AM
Finally got some time today to bring up the prop shield.

String of 72 APA102 LEDs working just fine on the LED output.

Took me too long to realize that I needed to solder another pin for the DAC output to get to shield. Sound is playing but is substantially quieter than I expected. Looking into this now...

defragster
03-20-2016, 01:30 AM
... needed to solder another pin for the DAC output to get to shield. Sound is playing but is substantially quieter than I expected. Looking into this now...

Did you enable pin 5 output HIGH if you are using th eAMP +/-: Prop-Shield-Beta-Test (https://forum.pjrc.com/threads/33328-Prop-Shield-Beta-Test?p=99763&viewfull=1#post99763)

GremlinWrangler
03-20-2016, 09:01 AM
Well it had to be done -- https://github.com/GremlinWrangler/SaberSounds is a try at doing live synth of a light saber like effect, complete with strike/clash detection. None of this is very pretty but currently the biggest issue is that the audio is easily missable in a quiet room at a foot away from the speaker, so much quieter than those cheesy greeting cards. Unsure if this is my speaker being poorly matched to the amp, or the class D amp just can't do much with the fairly bass heavy audio I'm generating.

defragster
03-20-2016, 09:24 AM
@GW - Just for reference - How loud is it if you try the Talkie library (https://forum.pjrc.com/threads/33446-Talkie-speech-library?p=99736&viewfull=1#post99736)? on my .5W 8ohm speaker it was over driving it at some points and certainly seemed louder than needed within a foot - To keep it down I was using
analogReference(INTERNAL); // drop volume level - It powered my headphones fine in either case - they have a volume knob and I turned it down.

Note: With the non-blocking edits made - if you had a finite number of clips (properly formatted) you could just dump them out and cycle between them as you saw fit.

Ben
03-20-2016, 12:43 PM
My TestGyroscope program has evolved into something useful and is now called SensorStatistics.ino (GitHub link (https://github.com/Ben-Rheinland/NXPMotionSense/blob/master/examples/SensorStatistics/SensorStatistics.ino)).


//TODO add description here
//DONE other 8 sensor readings
//TODO "outer loop" to log last n results
//DONE calculate measured mag strength sqrt(mx^2+my^2+mz^2) and add to stats
//DONE calculate measured acceleration strength and add to stats.

#include <NXPMotionSense.h>

NXPMotionSense imu;
const int ledPin = 13;
int ledState = LOW;
elapsedMillis ledMillis = 0;
//elapsedMillis serialMillis = 0;

void setup() {
Serial.begin(115200);
while (!Serial) ; // wait for serial port open
imu.begin();
pinMode(ledPin, OUTPUT);
Serial.println("SensorStatistics.ino version 0.1");
Serial.println("T = time in milliseconds");
Serial.println("All other lines: First value is mean,");
Serial.println("second value is variance.");
Serial.println("Each reading is calculated from 1000 sensor samples.");
Serial.println("AMag and MMag are absolute magnitude of acceleration");
Serial.println("vector and magnetic field vector respectively.");
}

int dataCount = 0;
double mean[11]; //means of ax, ay, az, gx, gy, gz, mx, my, mz, accMag, magMag;
double variance[11]; //variances of ax, ay, az, gx, gy, gz, mx, my, mz, accMag, magMag;


void loop() {
int data[9]; //sensor readings of ax, ay, az, gx, gy, gz, mx, my, mz;
double accMagnitude; //Magnitude of acceleration vector
double magMagnitude; //Magnitude of magnetic field vector
double delta;

if (imu.available()) {
imu.readMotionSensor( data[0], data[1], data[2], \
data[3], data[4], data[5], \
data[6], data[7], data[8] );

//calculate acceleration and magnetic field magnitudes
accMagnitude = sqrt( pow(data[0],2) + pow(data[1],2) + pow(data[2],2) );
magMagnitude = sqrt( pow(data[6],2) + pow(data[7],2) + pow(data[8],2) );

//if this is the first round, initialize the arrays
if (dataCount == 0) {
for (int i=0; i<11; i++) {
mean[i] = 0.0;
variance[i] = 0.0;
}
}
dataCount++; //It's important to do increment _before_ the following computations!

//Update statistics data
for (int i=0; i<9; i++) {
delta = data[i] - mean[i];
mean[i] += delta / dataCount;
variance[i] += delta * (data[i] - mean[i]); //this accumulates delta^2.
// Final division by sample count is done
// after all samples have been collected
}

delta = accMagnitude - mean[9];
mean[9] += delta / dataCount;
variance[9] += delta * (accMagnitude - mean[9]);

delta = magMagnitude - mean[10];
mean[10] += delta / dataCount;
variance[10] += delta * (magMagnitude - mean[10]);

//print heartbeat every 50 samples
if (dataCount % 50 == 0) {
Serial.print(".");
}

// if 1k values have been sampled,
// finish calculations and print results
if (dataCount >= 999) {
for (int i=0; i<11; i++) {
variance[i] /= (dataCount -1);
}

printStats();
dataCount = 0;
}
}


/*
// print a time stamp every 20 seconds
if (serialMillis >= 20000) {
serialMillis -= 20000;
Serial.print("T ");
Serial.println(millis());
Serial.println("");
}*/

// blink Led
if (ledMillis >= 1000) {
ledMillis -= 1000;
if (ledState == LOW) digitalWrite(ledPin, ledState = HIGH);
else digitalWrite(ledPin, ledState = LOW);
}
}

void printStats() {
Serial.println("");

Serial.print("T ");
Serial.println(millis());

Serial.print("AX ");
Serial.print(mean[0], 5);
Serial.print(" ");
Serial.println(variance[0], 5);

Serial.print("AY ");
Serial.print(mean[1], 5);
Serial.print(" ");
Serial.println(variance[1], 5);

Serial.print("AZ ");
Serial.print(mean[2], 5);
Serial.print(" ");
Serial.println(variance[2], 5);

Serial.print("GX ");
Serial.print(mean[3], 5);
Serial.print(" ");
Serial.println(variance[3], 5);

Serial.print("GY ");
Serial.print(mean[4], 5);
Serial.print(" ");
Serial.println(variance[4], 5);

Serial.print("GZ ");
Serial.print(mean[5], 5);
Serial.print(" ");
Serial.println(variance[5], 5);

Serial.print("MX ");
Serial.print(mean[6], 5);
Serial.print(" ");
Serial.println(variance[6], 5);

Serial.print("MY ");
Serial.print(mean[7], 5);
Serial.print(" ");
Serial.println(variance[7], 5);

Serial.print("MZ ");
Serial.print(mean[8], 5);
Serial.print(" ");
Serial.println(variance[8], 5);

Serial.print("AMag ");
Serial.print(mean[9], 5);
Serial.print(" ");
Serial.println(variance[9], 5);

Serial.print("MMag ");
Serial.print(mean[10], 5);
Serial.print(" ");
Serial.println(variance[10], 5);

Serial.println("");
}




The Program calculates the mean and variance of the 9 sensor values and of the magnitudes of acceleration and magnetic field strength.
In an ideal, noise free world, with perfect sensors and with the prop shield being stationary, all variances would be zero, and the magnitudes of acceleration and magnetic field strength would be independent of prop shield orientation. The gyro readings would be all zero, both mean and variance.

This is a sample output from my prop shield (which has a suspected broken gyro). T is a millis() timestamp:

T 1150063
AX -7637.22122 182.69951
AY -1277.98999 83.55501
AZ 355.83183 101.10195
GX -19.12713 17.90066
GY 14.48048 37.11360
GZ -2.34635 19.14245
MX 913.69469 79.64517
MY -195.30831 91.81868
MZ 931.63063 103.74820
AMag 7751.59396 181.01568
MMag 1319.50707 95.08322


The calculation is performed on the raw integer values provided by the sensors, so for conversion to SI units you need to multiply by:

#define G_PER_COUNT 0.0001220703125f // = 1/8192
#define DEG_PER_SEC_PER_COUNT 0.0625f // = 1/16
#define UT_PER_COUNT 0.1f
(Source: NXPMotionSense.h)

The algorithms used do not suffer from catastrophic cancellation when doing the float math and don't require to keep all readings in an array[SampleSize].

So I hope this sketch can give information on the data quality the sensors provide and help with troubleshooting.

Maybe those numbers can be plugged into NXPMotionSense/SensorFusion.cpp to provide even better accuracy and offset cancellation?

KurtE
03-20-2016, 01:29 PM
Hi Ben,

Good stuff,

Thought I would run it and see what type of results I get... Not sure if this helps or not.


T 548469
AX -643.66767 52.81129
AY 1215.78378 49.13958
AZ 8315.81181 111.01866
GX -11.18619 11.80698
GY 13.84985 6.06160
GZ -7.45946 4.52115
MX 529.05205 50.22975
MY 153.87087 66.25686
MZ -531.27027 75.43389
AMag 8428.83546 109.93706
MMag 765.47336 62.74468

Frank B
03-20-2016, 03:31 PM
I made a little tool to transfer files from and to the serial flash.

Would be great if you could test it.
I plan to extend it, to allow access to the internal eeprom, and maybe, SD.

Usage:



open Arduino, set USB-Mode to "Raw Hid"
load teensytransfertool.ino, compile, and flash it to the teensy


On PC:


The gz - file contains the Linux-version, the *.zip the Windows-version

Commandline:

List files : teensytransfer -l
Write file to flash : teensytransfer [-w] filename

Read file from flash : teensytransfer -r filename > file
Delete file from flash : teensytransfer -e filename

It should work for the optional flash on the audio shield, too (not tested)

Sorry, at the moment there is no MAC version (I don't know how to compile it - any hints ? :) )

https://github.com/FrankBoesing/TeensyTransfer



Edit: It would be great if there was a "Serial + Raw Hid" mode..

blackketter
03-20-2016, 05:06 PM
Did you enable pin 5 output HIGH if you are using th eAMP +/-: Prop-Shield-Beta-Test (https://forum.pjrc.com/threads/33328-Prop-Shield-Beta-Test?p=99763&viewfull=1#post99763)

I did. Part of the problem was in my code. Gain set too low.

Set up a trivial 1k sine generator and seeing approx 1.25vpp on the DAC output and at peak I'm seeing a 1:3 duty cycle on the amplifier output, which works out to about 1 watt. All good.

blackketter
03-20-2016, 05:14 PM
I made a little tool to transfer files from and to the serial flash.


This is awesome!
Don't see the source to the uploader tool, will that be added?

manitou
03-20-2016, 05:25 PM
My TestGyroscope program has evolved into something useful and is now called SensorStatistics.ino

data from my shield


T 402357
AX 228.78078 58.08316
AY 206.97097 60.35888
AZ 8448.96897 109.68140
GX -36.82182 10.15259
GY 57.46747 5.83436
GZ 1.26026 4.80394
MX 585.61662 34.81780
MY 362.76176 28.28387
MZ 233.38338 71.03423
AMag 8454.60658 109.85294
MMag 727.39721 38.06576

Frank B
03-20-2016, 05:30 PM
This is awesome!
Don't see the source to the uploader tool, will that be added?

i forgot to "sync" .)
It's online now, in the "extras" folder.
Yes, it needs a bit cleanup... :) its a bit "quick and dirty..."

I use a "LUBUNTU" VM with mingw to compile it.

Edit:
The hid - parts are (c) Paul Stoffregen

WMXZ
03-20-2016, 05:43 PM
Edit: It would be great if there was a "Serial + Raw Hid" mode..

I think you can use SEREMU when Raw HID

Frank B
03-20-2016, 05:52 PM
I know, but that gives no COM.
I don't need it for transfer, but it would be handy, because you don't need to switch between Raw Hid and Serial ... or can use both simultanously.


Edit:

Fixed a little bug..

JBeale
03-20-2016, 08:21 PM
Thanks for the stats program Ben. I ran my device for a while in two different orientations 90 degrees apart. I found that the indicated magnetic field magnitude changed by a factor of two, so it looks like my device is not calibrated at all, even though I ran Paul's calibration routine twice a few days ago and the data is supposed to be in non-volatile memory (?) Device is attached with blu-tack to a PVC pipe with nothing obviously magnetic nearby.

Orientation #1:

T 1151535
AX 95.78476 82.97887
AY -146.31886 85.62780
AZ 8420.29286 127.10109
GX -3.97540 10.94797
GY 1.13623 5.25695
GZ 1.24945 4.23888
MX -151.51830 63.28133
MY 301.91118 63.38867
MZ 323.56851 105.54708
AMag 8422.11877 126.86002
MMag 467.91951 88.26177
Orientation#2:

T 3503084
AX 8088.87297 77.19855
AY 951.09982 85.89620
AZ -60.34327 121.99499
GX -3.57672 11.01727
GY 0.12062 4.99525
GZ 1.35267 4.24195
MX -440.87618 79.11492
MY 249.32266 58.89927
MZ 850.53691 106.00579
AMag 8144.83313 76.43046
MMag 989.99544 99.65079

Wozzy
03-20-2016, 08:28 PM
I've noticed a discrepancy, in my output when using either the Madgwick or Mahony AHRS.
I see it in multiple examples, but it's very noticible when I run the MadgwickIMU (https://github.com/PaulStoffregen/NXPMotionSense/tree/master/examples/MadgwickIMU) sketch in the NXPMotionSense library
with the CurieIMU Visualizer (https://www.arduino.cc/en/Tutorial/Genuino101CurieIMUOrientationVisualiser) withing the Processing IDE

It seems as if Pitch and Roll are Swapped relative to the Inked Direction Vectors stenciled on the board.
The stencil does seem to agree with the FXOS8700 orientation.
6759
Pitch should be about the short axis of the Prop Shield (About the Y-Axis)
Roll should be about the long axis of the Prop Shield (about the X-Axis)

Also It seems like Roll feeds into Pitch.
When the device is Yawed 90 degrees both Pitch and Roll output Pitch.
Is anyone else seeing this?
Maybe I mucked up one of the library files.

defragster
03-20-2016, 08:37 PM
@Ben - I started your code this morning - my unit mostly motionless on my desk . . . I just rotated it some part of 90° at "T 9398309"

The file ( I had to ZIP it ) : 6760

JBeale
03-20-2016, 08:39 PM
Also It seems like Roll feeds into Pitch as the device is Yawed at 90 degrees both Pitch and Roll output Pitch.
Is anyone else seeing this?.
Yes, that is what I observed also. I assumed it was because the calibration had failed somehow.

sumotoy
03-20-2016, 08:50 PM
Wozzy,
I've noted this as well. I have modified a bit the visualizer for Processing to observe this.
Looks like there's axis swap somewhere, I hope this will fixed soon since this Prop Shield it's really enjoyable!
Following Processing Code for Visualizer....


import processing.serial.*;
Serial myPort;

int newLine = 13; // new line character in ASCII
float yaw;
float pitch;
float roll;
String message;
String [] ypr = new String [3];

void setup()
{
size(600, 500, P3D);

/*Set my serial port to same as Arduino, baud rate 9600*/
myPort = new Serial(this, Serial.list()[0], 9600); // if you have only ONE COM port active
//myPort = new Serial(this, "COM5", 9600); // if you know the 101 COM port

textSize(16); // set text size
textMode(SHAPE); // set text mode to shape
}

void draw()
{
serialEvent(); // read and parse incoming serial message
background(255); // set background to white

translate(width/2, height/2); // set position to centre

pushMatrix(); // begin object

rotateX(pitch); // RotateX pitch value
rotateY(-yaw); // yaw
rotateZ(-roll); // roll

drawArduino(); // function to draw rough Arduino shape

popMatrix(); // end of object

// Print values to console
print(pitch);
print("\t");
print(roll);
print("\t");
print(-yaw);
println("\t");

myPort.write("s"); // write an "s" to receive more data from Arduino
}

void serialEvent()
{
message = myPort.readStringUntil(newLine); // read from port until new line (ASCII code 13)
if (message != null) {
ypr = split(message, ","); // split message by commas and store in String array
yaw = float(ypr[0]); // convert to float yaw
pitch = float(ypr[1]); // convert to float pitch
roll = float(ypr[2]); // convert to float roll
}
}
void drawArduino() {
/* function contains shape(s) that are rotated with the IMU */
stroke(0, 90, 90); // set outline colour to darker teal
fill(130, 130, 130); // set fill colour to lighter teal
box(300, 50, 100); // draw Arduino board base shape

//stroke(0); // set outline colour to black
//fill(80); // set fill colour to dark grey
stroke(13, 250, 109);
line(-180, 0, 0, 180, 0, 0);
stroke(19, 13, 250);
line(0, -80, 0, 0, 80, 0);
stroke(250, 13, 40);
line(0, 0, -80, 0, 0, 80);
//translate(60, -10, 90); // set position to edge of Arduino box
//box(170, 20, 10); // draw pin header as box

//translate(-20, 0, -180); // set position to other edge of Arduino box
//box(210, 20, 10); // draw other pin header as box
}

PaulStoffregen
03-20-2016, 09:34 PM
I saw the axis swap also. I'm also finding a number of other little issues, while integrating Mahony into the calibration program. Fixing coming soon....

Wozzy
03-20-2016, 10:04 PM
Wozzy,
I have modified a bit the visualizer for Processing to observe this.
Looks like there's axis swap somewhere, I hope this will fixed soon since this Prop Shield it's really enjoyable!


Thanks Sumotoy
I did something very similar to correct the axis Swap.
The bigger problem which I can't seem to find the error is the Roll feeding into Pitch when the Prop Shield is Yawed 90 deg from the startup position.

I ran your Processing code, and still see the crosstalk problem.
I also reloaded all the libraries, and tried several different calibrations.

Wozzy
03-20-2016, 10:24 PM
Here are my Calibration results and results from Ben's TestGyroscope program at several orientations:

Magnetic Calibration

Hard Iron Offset
-0.59
2.52
71.00

Soft Iron Mapping
0.9668 -0.0220 0.0160
-0.0220 0.9792 0.0451
0.0160 0.0451 1.0592

Expected Magnetic Field Strength
50.00 uT


TestGyroscope Output
Startup...................
T 21220
AX 171.63163 164.09663
AY 27.79179 92.04478
AZ 8481.54555 141.54477
GX -4.91191 10.38101
GY 0.40340 5.09261
GZ 0.83483 5.15205
MX 27.25225 22.35514
MY 234.22623 66.75037
MZ 306.24625 58.61465
AMag 8483.34253 141.58025
MMag 386.61695 66.34669

Pitched 45...................
T 71573
AX 3859.75976 114.60355
AY -156.56056 135.95800
AZ 7678.44645 123.94878
GX -4.77978 13.56268
GY -0.06006 4.96833
GZ 0.66266 6.59851
MX -179.24925 40.78250
MY 245.70270 66.92656
MZ 342.29930 53.00151
AMag 8595.40816 129.20368
MMag 458.00782 58.36403

Yawed 90...................
T 111856
AX 145.37738 593.37147
AY 146.01802 1537.11791
AZ 8478.45445 152.15799
GX -3.48949 43.99964
GY 0.70771 6.19304
GZ 1.74775 1292.22689
MX 189.79980 30.24445
MY -5.75075 42.11116
MZ 302.79580 58.25485
AMag 8481.08300 157.42702
MMag 357.52273 50.35370

Yawed 90 & Pitched 45...................
T 152139
AX 3849.22122 133.03217
AY 77.25325 780.29552
AZ 7678.92693 142.10989
GX -4.79179 102.90450
GY 0.84184 7.77256
GZ 1.24324 31.32454
MX -16.20420 42.83401
MY -2.72773 95.92579
MZ 255.96797 55.01500
AMag 8590.07022 138.97610
MMag 256.75076 62.30623

Yawed 90 & Rolled 45...................
T 212563
AX 414.65065 280.96701
AY 5123.15115 101.65950
AZ 6492.55656 159.73803
GX -4.44645 7.60810
GY -0.43343 11.82497
GZ 1.32833 9.90011
MX 176.36436 30.44626
MY -277.17518 250.87008
MZ 418.87788 35.18547
AMag 8280.83984 137.03049
MMag 532.58679 56.70108

Return back to startup orientation...................
T 262918
AX 169.65365 84.30077
AY 41.98599 58.51283
AZ 8481.44945 143.56433
GX -5.08809 7.22269
GY -0.50050 4.07991
GZ 0.82482 6.35706
MX 33.14715 37.86310
MY 237.66567 40.26486
MZ 302.91992 59.26813
AMag 8483.25837 143.64890
MMag 386.55250 58.66205

blackketter
03-20-2016, 11:13 PM
Well it had to be done -- https://github.com/GremlinWrangler/SaberSounds is a try at doing live synth of a light saber like effect, complete with strike/clash detection.

Great idea! Gotta add that to my string of LEDs with some visual effects.


None of this is very pretty but currently the biggest issue is that the audio is easily missable in a quiet room at a foot away from the speaker, so much quieter than those cheesy greeting cards. Unsure if this is my speaker being poorly matched to the amp, or the class D amp just can't do much with the fairly bass heavy audio I'm generating.

It's probably a combination. An efficient speaker can be pretty loud even at 1W. The easiest way to make it more efficient is to put it in a sealed enclosure (and making sure the seal is tight). You can even buy inexpensive speakers already in an enclosure. I'm using one of these (http://www.digikey.com/product-detail/en/pui-audio-inc/ASE03008MR-LW150-R/668-1432-ND/4700907), which is well matched to the 1W amp:

6761

And little speakers aren't going to generate much bass at all. Size does matter.

Ideally the amp chip would have a little more power (2.5W seems to be a sweet spot to me), not sure if that's something that can be looked at at this time in the development cycle.

JBeale
03-20-2016, 11:42 PM
You can add the following functions to Ben's stats program to get a 23-column table to plot and look for any trends.
I like the KST Plot (https://kst-plot.kde.org/) program for that purpose, you can double-click on a .csv file and it immedately gives you plots for each column.
Looks like the variance of the accel(x,y,z) channels are good for seeing if someone walked into the room, as it sees the vibration of the floor.

void printHeaderLine() {
Serial.print("T,Ax,AxV,Ay,AyV,Az,AzV,Gx,GxV,Gy,GyV,Gz,GzV,");
Serial.println("Mx,MxV,My,MyV,Mz,MzV,AMag,AMagV,MMag,MMagV");
}
void printStatsLine() {
Serial.print(millis()/1000.0,1);
for (int i=0;i<11;i++) {
Serial.print(",");
Serial.print(mean[i], 2);
Serial.print(",");
Serial.print(variance[i], 2);
}
Serial.println();
}

https://lh3.googleusercontent.com/-ScXdSjikFRk/Vu82MqH3_3I/AAAAAAAAEn8/Fu5CfIZ-01IV46lewtNHJZLh1skcFawmQCCo/s1152-Ic42/Kst%2B-%2BCG9axis1.csv%2B3202016%2B44429%2BPM.jpg

defragster
03-21-2016, 03:57 AM
... which is well matched to the 1W amp:

OP says : 2 watt audio amp (https://forum.pjrc.com/threads/33328-Prop-Shield-Beta-Test?p=98180&viewfull=1#post98180)

This larger 2W (3W max) listed; (http://www.digikey.com/product-detail/en/pui-audio-inc/ASE02808MR-LW150-R/668-1431-ND/)

blackketter
03-21-2016, 04:52 AM
OP says : 2 watt audio amp (https://forum.pjrc.com/threads/33328-Prop-Shield-Beta-Test?p=98180&viewfull=1#post98180)

Crazy, not sure how I got 1W into my head for the spec of that amplifier. Sorry 'bout that.

I'm glad, though I'm not sure what the true output will be.

I'm a poor EE, but looking at the datasheet, I'm calculating a maximum power of 1.17W.

EDIT: dac1.analogReference() does the trick. Seeing full power output now. This should probably be documented somewhere...

Frank B
03-21-2016, 09:27 PM
TeensyTransfer:

Blackketter (thank you!) was so kind and has compiled a MAC version.
I do not know if it works .. (hint, hint :)

Pensive
03-21-2016, 11:05 PM
Hi everyone

Can anyone confirm - Which pins are absolutely required for operation of the Accelerometer?

I'm guessing SDL (SCL?),SDA, 3.3v, GND should provide power and i2c connectivity, but will i need 5v, or IRQ? Does the i2c run at 3.3v on Teensy-LC and Teensy 3.2?



Sorry bit late in the game here, but i need to add sensitive shock sensing to my project and the prop board is ideal, but I can't stack it - I have to mount adjacent as my enclosure is very tight, and similarly i'm all out of pins.

First step will be a simple shock sensor demo with a software buffer to store the peak shock levels in the last XX milliseconds

Thanks

J

manitou
03-22-2016, 12:12 AM
I have run shield I2C with just 3.3v/GND/SCL/SDA. The schematic also suggests you just need those 4 wires for I2C.

EDIT: Actually, connecting pin 2's (I2C IRQ) is probably a good idea.

Wozzy
03-22-2016, 01:47 AM
i need to add sensitive shock sensing to my project and the prop board is ideal, but I can't stack it - I have to mount adjacent as my enclosure is very tight, and similarly i'm all out of pins.

If you're really tight on space you might consider Onehorse's BNO-055 9-axis motion sensor with hardware fusion (https://www.tindie.com/products/onehorse/bno-055-9-axis-motion-sensor-with-hardware-sensor-fusion/)

Edit... I just stumbled on to a great comparison that Kris wrote: 9 DoF Motion Sensor Bakeoff (https://github.com/kriswiner/MPU-6050/wiki/9-DoF-Motion-Sensor-Bakeoff)

manitou
03-22-2016, 10:43 AM
If you're really tight on space you might consider Onehorse's BNO-055 9-axis motion sensor with hardware fusion (https://www.tindie.com/products/onehorse/bno-055-9-axis-motion-sensor-with-hardware-sensor-fusion/)

Edit... I just stumbled on to a great comparison that Kris wrote: 9 DoF Motion Sensor Bakeoff (https://github.com/kriswiner/MPU-6050/wiki/9-DoF-Motion-Sensor-Bakeoff)

maybe Kris will update his bakeoff with the prop shield sensors ....

PaulStoffregen
03-22-2016, 03:36 PM
After much frustration with wrong results in Arduino's orientation visualizer example, I finally arrived at this conclusion:


https://www.youtube.com/watch?v=SHJ2n1Kwe58

JBeale
03-22-2016, 03:53 PM
I didn't watch with the audio on, but I gather the Processing sketch assumes the orientation angles are relative to the viewer's stationary reference frame, instead of the moving object frame which of course is what the Prop Shield generates as you turn it.

Ben
03-22-2016, 04:03 PM
Ok, I very carefully tried to follow your thoughts. While there definitely is a bug, your audio comment confuses me quite a but, even with the text overlay.
Anyway, what I think is important to notice is that roll and yaw are visualized correctly all the time. The only thing that's behaving wrong is the visual response to any pitch != 0 if (yaw !=0 || yaw != PI).

My wild guess, by looking sharply at what's happening in the vid, is there is a factor sin(yaw) mixed in the roll that shouldn't be there. Because the bug doesn't show at 0 and Pi and is strongest at Pi/2 -> sin(x).

Edit: Ok scrap what I said, I looked at the function descriptions of the rotateX(), rotateY() and rotateZ() functions. I think the behavior of these functions is by design and they are just not intended to be used the way the are in the sketch:

Coordinates are always rotated around their relative position to the origin. (Source: https://processing.org/reference/rotateZ_.html)

We need to do some math with the data before it can be plugged into the rotate-functions. I'm sorry I don't have more time on my hands right now to look into this :(

JBeale
03-22-2016, 04:43 PM
Based on the below information, may be able to fix the visualization by simply inverting the order of the rotation operations:

https://en.wikipedia.org/wiki/Euler_angles
Intrinsic rotations
Intrinsic rotations are elemental rotations that occur about the axes of the rotating coordinate system XYZ, which changes its orientation after each elemental rotation.
Extrinsic rotations
Extrinsic rotations are elemental rotations that occur about the axes of the fixed coordinate system xyz.
Conversion between intrinsic and extrinsic rotations
Any extrinsic rotation is equivalent to an intrinsic rotation by the same angles but with inverted order of elemental rotations, and vice versa.

A rotation represented by Euler angles (α, β, γ) = (−60°, 30°, 45°), using z-x’-z″ intrinsic rotations:
https://upload.wikimedia.org/wikipedia/commons/thumb/7/73/EulerG.png/320px-EulerG.png
The same rotation represented by (γ, β, α) = (45°, 30°, −60°), using z-x-z extrinsic rotations
https://upload.wikimedia.org/wikipedia/commons/thumb/3/38/EulerX.png/320px-EulerX.png

https://upload.wikimedia.org/wikipedia/commons/8/85/Euler2a.gif

WMXZ
03-22-2016, 05:03 PM
IMO, the sequence of rotation is not correct
with

rotateY(-yaw); // yaw
rotateX(pitch); // RotateX pitch value
rotateZ(-roll); // roll

I get what I consider correct rotations

As I have no poti etc
I run the following program in processing


float yaw;
float pitch;
float roll;

void setup()
{
size(600, 500, P3D);

textSize(16); // set text size
textMode(SHAPE); // set text mode to shape

pitch=0.0;
roll=0.0;
yaw=1.0;

}

void draw()
{
pitch = pitch +0.01;
yaw = yaw+0.0;
roll = roll +0.0;

background(255); // set background to white

translate(width/2, height/2); // set position to centre

pushMatrix(); // begin object

rotateY(-yaw); // yaw
rotateX(pitch); // RotateX pitch value
rotateZ(-roll); // roll

drawArduino(); // function to draw rough Arduino shape

popMatrix(); // end of object

// Print values to console
print(pitch);
print("\t");
print(roll);
print("\t");
print(-yaw);
println("\t");

}

void drawArduino() {
/* function contains shape(s) that are rotated with the IMU */
stroke(0, 90, 90); // set outline colour to darker teal
fill(0, 130, 130); // set fill colour to lighter teal
box(300, 10, 200); // draw Arduino board base shape

stroke(0); // set outline colour to black
fill(80); // set fill colour to dark grey

translate(60, -10, 90); // set position to edge of Arduino box
box(170, 20, 10); // draw pin header as box

translate(-20, 0, -180); // set position to other edge of Arduino box
box(210, 20, 10); // draw other pin header as box
}

sumotoy
03-22-2016, 10:02 PM
After much frustration with wrong results in Arduino's orientation visualizer example, I finally arrived at this conclusion:


https://www.youtube.com/watch?v=SHJ2n1Kwe58
Ouch! You right, sorry you loose all this time around. The arduino visualizer it's simply wrong.
Late in 2012, the old friend Fabio (missed him a lot...) wroted something like the attachment.
It has modified to accomodate Processing 3 but of course it expect a different serial format so actually needs to be modified for run with prop-shield.
He choosed to start a 3d visualization from a fixed angle, then have to align the IMU board to that angle and press a button...
Dunno if this is a correct way to go, I was sure that compass it's enough to give a start point for the 3D rotation but I don't know really processing enough...

WMXZ
03-23-2016, 07:43 AM
The arduino visualizer it's simply wrong.
Well, no so much.
there are only three rotations.
As I said and as you may observe from the animation in JBeale's post, the sequence of rotations are
- yaw
- pitch
- roll

and not
- pitch
- raw
- roll

Note: if you wanted to undo the rotations, you must start with roll, followed by pitch and in the end with yaw

What I do not like is the choice of axes (i.e. roll around z axis), and I will continue to use x- forward, y to the left and z upward, i.e yaw (heading) rotation around z, pitch: rotation around y; ans roll rotation around x axis). But if you have to be compatible to say aircraft notation, so it be.

WMXZ
03-23-2016, 11:06 AM
For the records,
my prop shield arrived today!

summary of itinerary:
4 days US (Sherwood to NY)
11 days Italy (mostly Custom clearance)

Out of curiosity: Is there still someone who is waiting for his/her shipment, or do I hold the record?

WMXZ
03-23-2016, 12:48 PM
@Paul,
any design reason to have the spi clk on pin13 and not pin14?
this way one cannot use I2S (i.e audio boards) together with the Prob shield.

PaulStoffregen
03-23-2016, 12:58 PM
maybe Kris will update his bakeoff with the prop shield sensors ....

Probably best to do so *after* the final calibration software is published.

I'm seriously considering adding cal of the accelerometer and gyro offsets to the cal app. Anyone have opinions or feedback about that?

Wozzy
03-23-2016, 01:01 PM
I'm not sure that the Pitch/Roll with Yaw problem lies with the Curie visualizer alone.
Last night I was Stripcharting the Heading, Pitch, & Roll outputs from both the NXP_Sensor_Fusion and Mahony AHRS algorithms.
It seems that the issue is also present there as well.
I'll see if I can perform more testing and make a video tonight when I can get back to my play bench.

Wozzy
03-23-2016, 01:15 PM
I'm seriously considering adding cal of the accelerometer and gyro offsets to the cal app. Anyone have opinions or feedback about that?

Offsets can be accomplished with a ZERO button or a software button in a gui.
I guess in the simplest case, a timer could be used to give the user a set time to position and steady the IMU before the tare data is acquired.

Changing the sensitivities would likely be beyond the capability of the average user as precision fixtures and alignment would be required.

WMXZ
03-23-2016, 02:09 PM
Probably best to do so *after* the final calibration software is published.

I'm seriously considering adding cal of the accelerometer and gyro offsets to the cal app. Anyone have opinions or feedback about that?

While accelerometer calibration can be done with earth gravity, for gyro we would need some spinning device.
Some people I know use old-fashioned disk player to get 2 or 3 well defined rotation rates.

So, maybe someone with more mechanical skills develops a cost-effective gyro calibration sketch (teensy controlled rotating plate) to be used for gyro calibration.

manitou
03-23-2016, 02:36 PM
another standalone processing visualization tester using key presses for yaw, pitch, and roll. rotation ordered per post #306

// tty3d y p r 1 9 0 + -
float sign=1.0, delta=0.1;
float yaw;
float pitch;
float roll;
String message;
String [] ypr = new String [3];

void setup()
{
size(600, 500, P3D);

textSize(16); // set text size
textMode(SHAPE); // set text mode to shape
}

void draw()
{
background(255); // set background to white
lights();

translate(width/2, height/2); // set position to centre

pushMatrix(); // begin object

rotateY(-yaw); // yaw
rotateX(pitch); // RotateX pitch value
rotateZ(-roll); // roll

drawArduino(); // function to draw rough Arduino shape

popMatrix(); // end of object


}

void keyPressed()
{
if(key == 'y') yaw += sign*delta;
if(key == 'p') pitch += sign*delta;
if(key == 'r') roll += sign*delta;
if(key == '+') sign = 1.0;
if(key == '-') sign = -1.0;
if(key == '1') delta = 0.1;
if(key == '9') delta = 3.14159/4.; // 45 degrees
if(key == '0') roll=yaw=pitch= 0.0;
// Print values to console
print(pitch);
print("\t");
print(roll);
print("\t");
print(yaw);
println("\t");
}
void drawArduino() {
/* function contains shape(s) that are rotated with the IMU */
stroke(0, 90, 90); // set outline colour to darker teal
fill(0, 130, 130); // set fill colour to lighter teal
box(300, 10, 200); // draw Arduino board base shape

stroke(0); // set outline colour to black
fill(80); // set fill colour to dark grey

translate(60, -10, 90); // set position to edge of Arduino box
box(170, 20, 10); // draw pin header as box

translate(-20, 0, -180); // set position to other edge of Arduino box
box(210, 20, 10); // draw other pin header as box
}

Ben
03-23-2016, 02:45 PM
I'm seriously considering adding cal of the accelerometer and gyro offsets to the cal app. Anyone have opinions or feedback about that?
I'd like to propose a UI detail: Don't tell the user to hold the board still for "n" seconds, instead tell the user to put the board on an even surface and then use the variance of the incoming data do determine if the prop shield is held "still enough". Don't use data if variance is too high, use it and signal the user to do whatever comes next if variance is low enough.


Edit:
I made a 3D model of the Prop Shield to replace drawArduino() function in processing 3 by drawPropShield().
@Paul: Is it ok to post the source code or does this fall under the "no pictures" rule? The model shows the approximate size and position of all major components as well as the plated through-holes.

PaulStoffregen
03-23-2016, 03:42 PM
instead tell the user to put the board on an even surface and then use the variance of the incoming data do determine if the prop shield is held "still enough".

Yes, this is basically what I was thinking, looking at the changes in acceleration and for low values from the gyro.

PaulStoffregen
03-23-2016, 03:56 PM
Looks like the visualizers *and* Madgwick filter are using the same external frame Euler angle references.

If you run Madgwick and just watch the data, you can see spinning Teensy + Prop Shield on axis of the USB cable gives roll when the board is oriented one way, but it give pitch when you change the heading/yaw orientation by 90 degrees.

Somehow, I expect an IMU to give roll, pitch and yaw readings like you'd expect from inside an airplane. When the nose of the plane starts pointing downward, that's minus pitch, regardless of whether you're flying from Seattle to LA or NYC. Madgick reports it as pitch if you're flying towards Los Angles, but consides it roll when you're heading towards New York, or some of both if you're flying to Miami.

NXPSensorFusion (Freescale's algorithm) gives roll, pitch & yaw as you'd experience from the aircraft's (intrinsic) perspective.

I managed to change the visualizer to use intrinsic roll, pitch, yaw. Here's the code:



import processing.serial.*;
Serial myPort;

int newLine = 13; // new line character in ASCII
float yaw;
float pitch;
float roll;
String message;
String [] ypr = new String [3];

void setup()
{
size(600, 500, P3D);
lights();

/*Set my serial port to same as Arduino, baud rate 9600*/
//myPort = new Serial(this, Serial.list()[0], 9600); // if you have only ONE COM port active
myPort = new Serial(this, "/dev/ttyACM0", 9600); // if you know the 101 COM port

textSize(16); // set text size
textMode(SHAPE); // set text mode to shape
}

void draw()
{
serialEvent(); // read and parse incoming serial message
background(255); // set background to white

translate(width/2, height/2); // set position to centre

pushMatrix(); // begin object

float c1 = cos(-roll);
float s1 = sin(-roll);
float c2 = cos(pitch);
float s2 = sin(pitch);
float c3 = cos(-yaw);
float s3 = sin(-yaw);
applyMatrix( c2*c3, s1*s3+c1*c3*s2, c3*s1*s2-c1*s3, 0,
-s2, c1*c2, c2*s1, 0,
c2*s3, c1*s2*s3-c3*s1, c1*c3+s1*s2*s3, 0,
0, 0, 0, 1);

drawArduino(); // function to draw rough Arduino shape

popMatrix(); // end of object

// Print values to console

print(roll);
print("\t");
print(pitch);
print("\t");
print(-yaw);
println();

myPort.write("s"); // write an "s" to receive more data from Arduino
}

void serialEvent()
{
message = myPort.readStringUntil(newLine); // read from port until new line (ASCII code 13)
if (message != null) {
ypr = split(message, ","); // split message by commas and store in String array
yaw = float(ypr[0]); // convert to float yaw
pitch = float(ypr[1]); // convert to float pitch
roll = float(ypr[2]); // convert to float roll
}
}
void drawArduino() {
/* function contains shape(s) that are rotated with the IMU */
stroke(0, 90, 90); // set outline colour to darker teal
fill(0, 130, 130); // set fill colour to lighter teal
box(300, 10, 200); // draw Arduino board base shape

stroke(0); // set outline colour to black
fill(80); // set fill colour to dark grey

translate(60, -10, 90); // set position to edge of Arduino box
box(170, 20, 10); // draw pin header as box

translate(-20, 0, -180); // set position to other edge of Arduino box
box(210, 20, 10); // draw other pin header as box
}

Ben
03-23-2016, 04:02 PM
Oh oops I didn't refresh and edited my post because I thought it was still the latest. Please see my edit in #314 (100*pi :) )

PaulStoffregen
03-23-2016, 04:25 PM
Is it ok to post the source code or does this fall under the "no pictures" rule?

A model is fine.

Ben
03-23-2016, 04:34 PM
You can use this drawPropShield() function instead of drawArduino(). I don't know whether I got the orientation right, propably not, but that should be fixed easily by cyclically exchanging the function parameters.


int fpsMillis = 0;
int fps = 0;

void setup()
{
size(600, 500, P3D);
textSize(16); // set text size
textMode(SHAPE); // set text mode to shape
sphereDetail(15);
}

void draw()
{
background(255); // set background to white

if (millis() - fpsMillis > 500) {
fpsMillis = millis();
fps = (int)frameRate;
}
fill(0);
text(fps + " fps",10,20);

translate(width/2, height/2, 200); // set position to centre
pushMatrix(); // begin object
rotateX( sin(millis()/700.f)/1.6 - 3.1415f/4 );
rotateY( sin(millis()/2000.f)/2);
drawPropShield();
popMatrix(); // end of object
}

void drawPropShield() {

stroke(0); // black outline
fill(0, 128, 0); // fill color PCB green
box(190, 6, 70); // PCB base shape

fill(255, 215, 0); // gold color
noStroke();

//draw 14 contacts on Y- side
translate(65, 0, 30);
for (int i=0; i<14; i++) {
sphere(4.5); // draw gold contacts
translate(-10, 0, 0); // set new position
}

//draw 14 contacts on Y+ side
translate(10, 0, -60);
for (int i=0; i<14; i++) {
sphere(4.5); // draw gold contacts
translate(10, 0, 0); // set position
}

//draw 5 contacts on X+ side (DAC, 3v3, gnd)
translate(-10,0,10);
for (int i=0; i<5; i++) {
sphere(4.5);
translate(0,0,10);
}

//draw 4 contacts on X+ side (G C D 5)
translate(25,0,-15);
for (int i=0; i<4; i++) {
sphere(4.5);
translate(0,0,-10);
}

//draw 4 contacts on X- side (5V - + GND)
translate(-180,0,10);
for (int i=0; i<4; i++) {
sphere(4.5);
translate(0,0,10);
}

//draw audio amp IC
stroke(128);
fill(24); //Epoxy color
translate(30,-6,-25);
box(13,6,13);

//draw pressure sensor IC
stroke(64);
translate(32,0,0);
fill(192);
box(10,6,18);

//draw gyroscope IC
stroke(128);
translate(27,0,0);
fill(24);
box(16,6,16);

//draw flash memory IC
translate(40,0,-15);
box(20,6,20);

//draw accelerometer/magnetometer IC
translate(-5,0,25);
box(12,6,12);

//draw 5V level shifter ICs
translate(42.5,2,0);
box(6,4,8);
translate(0,0,-20);
box(6,4,8);
}

Edit: Screenshot:
6801

manitou
03-23-2016, 05:31 PM
I managed to change the visualizer to use intrinsic roll, pitch, yaw.

FWIW, lights() needs to be in draw() to remain persistent.

defragster
03-23-2016, 05:31 PM
Looks like the visualizers *and* Madgwick filter are using the same external frame Euler angle references.

If you run Madgwick and just watch the data, you can see spinning Teensy + Prop Shield on axis of the USB cable gives roll when the board is oriented one way, but it give pitch when you change the heading/yaw orientation by 90 degrees.

It this related to Gimbal Lock like here Gimbal Lock – Rotation order while Animating a Character (http://www.cgmeetup.net/home/gimbal-lock-rotation-orders-for-animation/)
> At 2 minutes building to 2:20+ it shows the character having spastic axis rotation - fixed there by changing the order of axis evaluation. This seems to be what WMXZ was alluding to in his post #306


... reports it as pitch if you're flying towards Los Angles, but consides it roll when you're heading towards New York, or some of both if you're flying to Miami.


If a plane from Boston to Seattle diverts to Dallas and suffers a horizon shift . . . which way are the survivors facing?

manitou
03-23-2016, 05:52 PM
the processing sketch i posted in #313 uses the rotation ordering suggested in #306.

sumotoy
03-23-2016, 08:38 PM
Ok, I have tried paul suggestion and all the others, holding the board from the usb cable, maintain vertical and slowly rotating it switch upside down and viceversa every 90°.

PaulStoffregen
03-24-2016, 01:00 AM
I've updated NXPMotionSense and MahonyAHRS. Madgick still needs work, but the Massimo gave me access to it... so fixes coming soon.

https://github.com/PaulStoffregen/NXPMotionSense

https://github.com/PaulStoffregen/MahonyAHRS

I put an updated copy of the visualizer with Ben's awesome rendering of the prop shield and proper intrinsic rotations here:

https://github.com/PaulStoffregen/NXPMotionSense/blob/master/OrientationVisualiser/OrientationVisualiser.pde

The protocol has changed from Arduino's Curie example to Adafruit's BNO055 bunny (https://github.com/adafruit/Adafruit_BNO055/blob/master/examples/bunny/bunny.ino) example.

The Orientation and Mahony examples have been updated. Things seem to be working much better now that it's all intrinsic rotation, as you'd expect for roll, pitch & yaw!


(edit: and yes, I know there's redundant math in the Mahony functions.... will make it more efficient tomorrow)

sumotoy
03-24-2016, 01:09 AM
Thanks Paul, awesome! ;)

Jp3141
03-24-2016, 02:30 AM
Can't you just add:

SPI.setSCK(14); (SCLK connected on Teensy pin 14)

to your SPI code ?


@Paul,
any design reason to have the spi clk on pin13 and not pin14?
this way one cannot use I2S (i.e audio boards) together with the Prob shield.

WMXZ
03-24-2016, 07:17 AM
Can't you just add:

SPI.setSCK(14); (SCLK connected on Teensy pin 14)

to your SPI code ?

Sorry, I was referring to prop shield that is using pin13 for spi0_clk, while audio boards use pin13 for I2S0_RDX0 and pin14 for spi0_clk.
So you cannot use prop shield and audio board together.

There maybe other incompatibilities between audio board and prop shield, that is why I asked.
Also, I assume that Paul thought about this, but decided this way.

PaulStoffregen
03-24-2016, 09:36 AM
I'm not sure that the Pitch/Roll with Yaw problem lies with the Curie visualizer alone.
Last night I was Stripcharting the Heading, Pitch, & Roll outputs from both the NXP_Sensor_Fusion and Mahony AHRS algorithms.
It seems that the issue is also present there as well.

Yes, until yesterday, they were all wrong. I had copied the Madgwick's incorrect quaternion to angles code, because NXPSensorFusion wasn't working with the buggy visualizer.

NXPSensorFusion and Mahony are now fixed, and the visualizer provided with the library is correct. I'm going to update Madgwick right after I get caught up on answering forum threads, and with any luck I'll get Arduino to update their web page with their buggy visualizer.

I also sent a pull request which Adafruit merged, to fix their visualizer. Later today or this week I might try looking around the Arduino world to find other copies. This same wrong code seems to have been very widely copied over the last few years.

Frank B
03-24-2016, 06:28 PM
A question...
Are there speakers that do not affect the magnetometer?

:confused:

Or, as an alternative, can the algorithms work without using the magnetometer-data ?
How to use the amp without loooong cables ? Any ideas ?

JBeale
03-24-2016, 06:54 PM
A piezo speaker would not necessarily affect the magnetometer. There are "magnetically shielded" moving-coil speakers but I doubt they are 100% shielded.

cartere
03-24-2016, 07:37 PM
New visualizer is wonderful! It has been a long day, installed Ubantu (very first time Linux attempt), installed Arduino and Teensyduino, Processing ( anyone know how to make an icon to run it instead of using "sh") Now I have Teensy programed and watching the Prop Shield twist and turn :)

Ben
03-25-2016, 01:02 AM
A piezo speaker would not necessarily affect the magnetometer. There are "magnetically shielded" moving-coil speakers but I doubt they are 100% shielded.
Piezo speaker is a good idea. Keep in mind they don't work well below ~1kHz, so not hifi at all and far from ideal even for voice. And you are right, magnetic shielding of MC-speakers is not good enough for a compass to work near it. Even if the speaker had a good enough shielding, that shielding itself would also distort the earths magnetic field around it, so that wouldn't help _that_ much (although, I guess, you could calibrate against that).

Wozzy
03-25-2016, 03:24 AM
The latest NXP Motion Sense library updates all seem to be working beautifully.
I get great results with the either NXP, Madgwick or Mahony AHRS filters.
Smooth and accurate motion with the visualizer.
It does seem to matter how the Prop Shield is oriented on power up.
I'm still trying to characterize this.
For me I get best results with +Y oriented North and the base flat when I power on the Teensy and Prop Shield.

I've created some additions to Ben's beautiful Prop Shield model in Processing to add a Teensy and headers.
(Thank you Ben and Paul)
6837

The only puzzling thing is that I need to reverse YAW.
Also I needed to remove the ":" after the com port define on my Windows 10 PC.
Here is the Processing code:

import processing.serial.*;
Serial myPort;

float yaw = 0.0;
float pitch = 0.0;
float roll = 0.0;

void setup()
{
size(600, 600, P3D);

// if you have only ONE serial port active
//myPort = new Serial(this, Serial.list()[0], 9600); // if you have only ONE serial port active

// if you know the serial port name
myPort = new Serial(this, "COM8", 9600); // Windows "COM#:"
//myPort = new Serial(this, "/dev/ttyACM0", 9600); // Linux "/dev/ttyACM#"
//myPort = new Serial(this, "/dev/cu.usbmodem1217321", 9600); // Mac "/dev/cu.usbmodem######"

textSize(24); // set text size
textMode(SHAPE); // set text mode to shape

}

void draw()
{
serialEvent(); // read and parse incoming serial message
background(200,200,255); // set background color
lights();

translate(width/2, height/2); // set position to centre
scale(2);
pushMatrix(); // begin object

float c1 = cos(radians(roll));
float s1 = sin(radians(roll));
float c2 = cos(radians(-pitch));
float s2 = sin(radians(-pitch));
//float c3 = cos(radians(yaw));
//float s3 = sin(radians(yaw));
float c3 = cos(radians(-yaw));
float s3 = sin(radians(-yaw));
applyMatrix( c2*c3, s1*s3+c1*c3*s2, c3*s1*s2-c1*s3, 0,
-s2, c1*c2, c2*s1, 0,
c2*s3, c1*s2*s3-c3*s1, c1*c3+s1*s2*s3, 0,
0, 0, 0, 1);

drawPropShield();
drawTeensy();
drawText();
//drawArduino();


popMatrix(); // end of object

// Print values to console
print(roll);
print("\t");
print(-pitch);
print("\t");
print(yaw);
println();
}

void serialEvent()
{
int newLine = 13; // new line character in ASCII
String message;
do {
message = myPort.readStringUntil(newLine); // read from port until new line
if (message != null) {
String[] list = split(trim(message), " ");
if (list.length >= 4 && list[0].equals("Orientation:")) {
yaw = float(list[1]); // convert to float yaw
pitch = float(list[2]); // convert to float pitch
roll = float(list[3]); // convert to float roll
}
}
} while (message != null);
}

void drawArduino()
{
/* function contains shape(s) that are rotated with the IMU */
stroke(0, 90, 90); // set outline colour to darker teal
fill(0, 130, 130); // set fill colour to lighter teal
box(300, 10, 200); // draw Arduino board base shape

stroke(0); // set outline colour to black
fill(80); // set fill colour to dark grey

translate(60, -10, 90); // set position to edge of Arduino box
box(170, 20, 10); // draw pin header as box

translate(-20, 0, -180); // set position to other edge of Arduino box
box(210, 20, 10); // draw other pin header as box
}

void drawPropShield()
{
// 3D art by Benjamin Rheinland
stroke(0); // black outline
fill(0, 128, 0); // fill color PCB green
box(190, 6, 70); // PCB base shape

fill(255, 215, 0); // gold color
noStroke();

//draw 14 contacts on Y- side
translate(65, 0, 30);
for (int i=0; i<14; i++) {
sphere(4.5); // draw gold contacts
translate(-10, 0, 0); // set new position
}

//draw 14 contacts on Y+ side
translate(10, 0, -60);
for (int i=0; i<14; i++) {
sphere(4.5); // draw gold contacts
translate(10, 0, 0); // set position
}

//draw 5 contacts on X+ side (DAC, 3v3, gnd)
translate(-10,0,10);
for (int i=0; i<5; i++) {
sphere(4.5);
translate(0,0,10);
}

//draw 4 contacts on X+ side (G C D 5)
translate(25,0,-15);
for (int i=0; i<4; i++) {
sphere(4.5);
translate(0,0,-10);
}

//draw 4 contacts on X- side (5V - + GND)
translate(-180,0,10);
for (int i=0; i<4; i++) {
sphere(4.5);
translate(0,0,10);
}

//draw audio amp IC
stroke(128);
fill(24); //Epoxy color
translate(30,-6,-25);
box(13,6,13);

//draw pressure sensor IC
stroke(64);
translate(32,0,0);
fill(192);
box(10,6,18);

//draw gyroscope IC
stroke(128);
translate(27,0,0);
fill(24);
box(16,6,16);

//draw flash memory IC
translate(40,0,-15);
box(20,6,20);

//draw accelerometer/magnetometer IC
translate(-5,0,25);
box(12,6,12);

//draw 5V level shifter ICs
translate(42.5,2,0);
box(6,4,8);
translate(0,0,-20);
box(6,4,8);
}

void drawTeensy() {
/* Draw Teensy 3.x Board */
translate(-77.5, -23, 10); // set position of Teensy 3.x
stroke(40, 0, 60); // set outline colour
fill(90, 0, 120); // set fill colour
box(140, 6, 70); // draw Arduino board base shape

/* Draw MCU */
translate(20, -4, 0); // set position to other edge of Teensy box
stroke(50, 50, 50); // set outline colour
fill(0, 0, 0); // set fill colour
box(40, 2, 40); // draw MCU

fill(255, 215, 0); // gold color
noStroke();

//draw 14 contacts on Y- side
translate(45, 4, 30);
for (int i=0; i<14; i++) {
sphere(4.5); // draw gold contacts
translate(-10, 0, 0); // set new position
}

//draw 14 contacts on Y+ side
translate(10, 0, -60);
for (int i=0; i<14; i++) {
sphere(4.5); // draw gold contacts
translate(10, 0, 0); // set position
}

//draw 5 contacts on X+ side (DAC, 3v3, gnd)
translate(-10,0,10);
for (int i=0; i<5; i++) {
sphere(4.5);
translate(0,0,10);
}

/* Draw USB Cable */
translate(-125, -6, -30); // set position
stroke(40, 0, 60); // set outline colour
fill(200, 200, 200); // set fill colour
box(25, 8, 35); // draw USB Connector

/* Draw Headers */
stroke(0); // set outline colour to black
fill(80); // set fill colour to dark grey

translate(60, 19, 32); // set position to edge
box(140, 21, 6); // draw pin header as box

translate(0, 0, -64); // set position to other edge
box(140, 21, 6); // draw other pin header as box
}

void drawText() {
fill(130, 0, 0, 200);
text("Madgwick", -50, 60, 30);
//text("Mahony", -40, 60, 30);
//text("NXP Motion Sense", -100, 60, 30);
//text("TEENSY 3.1 &", -90, 60, 30);
//text("PROP SHIELD", -90, 80, 30);
}

sumotoy
03-25-2016, 04:28 PM
Since I have several Teensy's my COM it's over 40 actually, to get serial work I'm forced to use:

myPort = new Serial(this, Serial.list()[0], 9600);
Using
myPort = new Serial(this, "COM41", 9600); not work on my wintel7/Processing3.0.2

WMXZ
03-25-2016, 04:45 PM
Since I have several Teensy's my COM it's over 40 actually, to get serial work I'm forced to use:

myPort = new Serial(this, Serial.list()[0], 9600);
Using
myPort = new Serial(this, "COM41", 9600); not work on my wintel7/Processing3.0.2

you may wanted to uninstall unused COM ports

1. Right-click “Command Prompt” in Accessories and choose "Run as Administrator”

2. Enter “set devmgr_show_nonpresent_devices=1″ – without the quotes obviously

3. Enter “start devmgmt.msc”

4. In the box that opens, select “Show hidden devices” in the ‘view’ menu.

Now if you expand the section on COM ports, all the COM ports that have ever
been created will be displayed, the non present ones being in grey. You can
uninstall away anything that you don’t want (right click, select uninstall).

run as administrator seems important

I removed multiple times old COM ports of unused teensies (on win10)

sumotoy
03-25-2016, 05:17 PM
Thanks, I know this, I also have a small app that do the same thing, but nice you posted the procedure, it can be useful for many users.
But I have really a lot of different opened projects and MCU's so my COM's will grow up in few days again, otherwise I will spend hours looking the infamous 'Installing new driver' every time I insert a new MCU!

PaulStoffregen
03-25-2016, 08:46 PM
Using
myPort = new Serial(this, "COM41", 9600); not work on my wintel7/Processing3.0.2

How about this?



myPort = new Serial(this, "\\\\.\\COM41", 9600);

sumotoy
03-25-2016, 08:53 PM
Yes! That worked!

PaulStoffregen
03-25-2016, 09:19 PM
Great. I've updated the example.

https://github.com/PaulStoffregen/NXPMotionSense/commit/b745b9e1bee85094527c67edcdf78092b76b6245

Ben
03-25-2016, 11:07 PM
I tried the updated OrientationVisualizer. Can't comment on the COM-Port syntax, but I had to negate yaw to -yaw like @Wozzy mentioned in post #333 (https://forum.pjrc.com/threads/33328-Prop-Shield-Beta-Test?p=100441&viewfull=1#post100441).
With the current state of the github repo:

float c1 = cos(radians(roll));
float s1 = sin(radians(roll));
float c2 = cos(radians(-pitch));
float s2 = sin(radians(-pitch));
float c3 = cos(radians(yaw));
float s3 = sin(radians(yaw));

I experience two bugs: The visualized yawing of the board is inverted and there are instabilities (sudden "flipovers") when wiggling the board at about +90° and -90° pitch.

if I change that to

pushMatrix(); // begin object

float c1 = cos(radians(roll));
float s1 = sin(radians(roll));
float c2 = cos(radians(-pitch));
float s2 = sin(radians(-pitch));
float c3 = cos(radians(-yaw));
float s3 = sin(radians(-yaw));
applyMatrix( c2*c3, s1*s3+c1*c3*s2, c3*s1*s2-c1*s3, 0,
-s2, c1*c2, c2*s1, 0,
c2*s3, c1*s2*s3-c3*s1, c1*c3+s1*s2*s3, 0,
0, 0, 0, 1);

drawPropShield();
//drawArduino();

popMatrix(); // end of object

// Print values to console
print(roll);
print("\t");
print(-pitch);
print("\t");
print(-yaw);
println();
then both bugs no longer show up!

I'd like to remind/inform you all that my choice of having the 3D models non-USB end (Where the 5V buffers are) facing to the right on the monitor with no rotation was an entirely random decision. So when fiddling around with swapping/inverting axis keep in mind the orientation of the boards virtual representation has a "random" initial orientation.

JBeale
03-26-2016, 03:19 PM
I tried out https://github.com/PaulStoffregen/MahonyAHRS but in the serial monitor I just get a bunch of

config error FXOS8700
config error FXOS8700
config error FXOS8700
so maybe I have the wrong version of the accelerometer library(?)

Ben
03-26-2016, 03:24 PM
You need the latest NXPMotionSense and MahonyAHRS libraries from Pauls GitHub to make it work, not just the new *.ino

@Paul: Please add

//reset position to zero
translate(-76.5,4,10);
to the end of drawPropShield(). I realized that failing to do so will offset subsequent drawSomething() calls because the position is only reset by the beginning of each draw() call.

EDIT: I'm sorry the translate() numbers were wrong, now it's corrected!

PaulStoffregen
03-26-2016, 03:50 PM
Yesterday I changed the calibration data format. The calibration app's source was updated last night on github. I still need to build new binaries. Going to improve a few things in the GUI first, and try to fix the crashing on macintosh.

I've seen the "config error FXOS8700" problem a few times. You need to power cycle. The FXOS8700 gets stuck sometimes, and so far I haven't managed to find out why and what to do to get it unstuck without power cycling. Another issue on my to-do list.

The orientation visualizer needs a heading/yaw reset button. A fixed translate isn't the right way, unless everyone in the world orients their monitors in the same geomagnetic direction. But we can assume all monitors are vertical with respect to gravity seen by the accelerometer, so a reset button should only affect yaw/heading.

Edit: also on my to-do list is making sure all these libs and programs are following the same NED right hand rule convention...

WMXZ
03-26-2016, 04:03 PM
I've seen the "config error FXOS8700" problem a few times. You need to power cycle. The FXOS8700 gets stuck sometimes, and so far I haven't managed to find out why and what to do to get it unstuck without power cycling. Another issue on my to-do list.


It may not be related, but I added a I2C bus reset

// change pin mux to digital I/O
pinMode(sda,INPUT);
pinMode(scl,OUTPUT);
digitalWrite(scl,HIGH);

int16 count=0;
while(digitalRead(sda) == 0 && count++ < 10)
{
digitalWrite(scl,LOW);
delayMicroseconds(5); // 10us period == 100kHz
digitalWrite(scl,HIGH);
delayMicroseconds(5);
}

to my code, to force all I2C devices to reset.

veng1
03-26-2016, 05:47 PM
Are these in the store yet? I'm ready to buy one.

PaulStoffregen
03-26-2016, 06:56 PM
They'll be start shipping Monday. Sometime tomorrow I'm going to publish the product pages and ask for feedback here.

Several distributors should start stocking them next week too. :)

KurtE
03-26-2016, 07:23 PM
They'll be start shipping Monday. Sometime tomorrow I'm going to publish the product pages and ask for feedback here.

Several distributors should start stocking them next week too. :)
Congratulations!

Sorry I have not been able to do as much testing here as I would like to have... Too busy with some other Teensy projects.
Is there a complete set of Libraries/programs, that we should all download and test before Monday?

Kurt

Ben
03-26-2016, 07:33 PM
The orientation visualizer needs a heading/yaw reset button. A fixed translate isn't the right way, unless everyone in the world orients their monitors in the same geomagnetic direction. But we can assume all monitors are vertical with respect to gravity seen by the accelerometer, so a reset button should only affect yaw/heading.

I did something quite similar to this today:

https://github.com/Ben-Rheinland/NXPMotionSense/blob/master/OrientationVisualiser/OrientationVisualiser.pde

Run this, let the visualizer window be in focus (klick somewhere inside the window) and hit "h" on your keyboard.

-Ben

WMXZ
03-26-2016, 07:37 PM
They'll be start shipping Monday. Sometime tomorrow I'm going to publish the product pages and ask for feedback here.

Several distributors should start stocking them next week too. :)
great, now we need a Teensy with the right footprint that has build-in Floating point!

cyborgv2
03-26-2016, 08:02 PM
Bummed out: not been free to do any testing but been keeping up with this thread and reading as much code as I can... finally sat down tonight in front of my desktop to start with some physical testing and my power pack starts smoking as soon as I turn in on! New power pack, turn it on and Teensy starts smoking :(

defragster
03-26-2016, 10:21 PM
Good work Paul - Mine still works! No Issues with IMU unit. Just ran an updated TALKIE sample.

I made PULL request (https://github.com/PaulStoffregen/Talkie/pull/1) so you can own the non-blocking Talkie edits with sound queue I made.
<edit>: I tested this only against the Prop Shield - but no changes were made that should affect other usage.

I ordered Adafruit APA102's - they'll finally get here Monday . . . UPS shipping ground across country sure is slow - especially when they sit on the order for 2 days - making it Monday to Monday!

pictographer
03-27-2016, 12:05 AM
Success with Raw SerialFlash Hardware Test, but some weird Arduino behavior along the way.

In Arduino 1.6.8/Teensyduino 1.28-beta1, first couple of times I tried to compile, I got a message about the compiler quitting with no error messages. Third time I noticed that compiler output was appearing in another sketch other than the one I was trying to compile and upload.

I quit Arduino and restarted. I closed all the other sketches. Then the test program compiled uploaded and ran.



Raw SerialFlash Hardware Test


Read Chip Identification:
JEDEC ID: EF 40 17
Part Nummber: W25Q64FV
Memory Size: 8388608 bytes
Block Size: 65536 bytes


Reading Chip...


Writing 4096 signatures


Double Checking All Signatures:
all 4096 signatures read ok


Checking Signature Pairs
all 2047 signature pairs read ok


Checking Read-While-Write (Program Suspend)
write 256 bytes at 256
write time was 443 microseconds.
read-while-writing: 00 00 00 00 15 F5 95 4B
test passed, good read while writing


Checking Read-While-Erase (Erase Suspend)
erase time was 174105 microseconds.
erase correctly erased 65536 bytes
read-while-erasing: 00 00 00 00 15 F5 95 4B
test passed, good read while erasing


All Tests Passed :-)


Test data was written to your chip. You must run
EraseEverything before using this chip for files.

defragster
03-27-2016, 12:10 AM
... weird Arduino behavior along the way.

In Arduino 1.6.8/Teensyduino 1.28-beta1, first couple of times I tried to compile, I got a message about the compiler quitting with no error messages. Third time I noticed that compiler output was appearing in another sketch other than the one I was trying to compile and upload.


The IDE has done this as long as I can remember. If you have multiple IDE windows - all compile output registers in the last/current active window. If you change to 'notepad' - output stays on last IDE - but switching to another IDE instance will have the compile output appear only in that 'current' window, not restricted to the one where the compile was initiated.

Wozzy
03-27-2016, 03:55 AM
I tried out the MPL3115A2 barometer on the Prop Shield.
I had success with both the AdaFruit (https://github.com/adafruit/Adafruit_MPL3115A2_Library) and Sparkfun (https://github.com/sparkfun/MPL3115A2_Breakout/tree/V_H1.1_L1.2.0/Libraries/Arduino) libraries.

With the Adafruit library, I noticed that there were significant offsets compared to NOAA weather, local altitude and a temperature logger.
I modified the library to output Raw, Tared and Offset data.
Here is a plot of the data with Tare and Offset applied.
Note that at 11 minutes I moved it to the ceiling and then the floor a delta of about 8 ft.
Then at 14 minutes I placed it on top of a warm power supply, then near a muffin fan.
I notice that there are transients in the pressure and altitude as the temperature changes.
I've seen the same phenomenon with the Bosch BMP280 barometer sensor.

Here's the plot:
6853

And here's the modified Adafruit library (https://github.com/adafruit/Adafruit_MPL3115A2_Library) code:

/************************************************** ************************/
/*!
@file Adafruit_MPL3115A2.cpp
@author K.Townsend (Adafruit Industries)
@license BSD (see license.txt)

Example for the MPL3115A2 barometric pressure sensor

This is a library for the Adafruit MPL3115A2 breakout
----> https://www.adafruit.com/products/1893

Adafruit invests time and resources providing this open source code,
please support Adafruit and open-source hardware by purchasing
products from Adafruit!

@section HISTORY

v1.0 - First release
*/
/************************************************** ************************/
/****************Modified by R. Wozniak Mar-26-2016************************/

#include <Wire.h>
#include <Adafruit_MPL3115A2.h>

Adafruit_MPL3115A2 baro = Adafruit_MPL3115A2();


float startTime;
float acqTime;
float startPressure; // For Tare Values
float startAltitude; // For Tare Values
float startTemperature; // For Tare Values
float offsetPressureCorr = 102600.00; // Local Barometric Pressure at startup for correction (Pa) // 100mb = 1Pa, 3377in Hg = 1Pa
float offsetAltitudeCorr = 63.01; // Local Altitude at startup for correction (m)
float offsetTemperatureCorr = 25.22; // Local Temperature at startup for correction (Deg C)
float rawPressure;
float rawAltitude;
float rawTemp;

void setup() {
Serial.begin(9600);
while (!Serial) ; // wait for serial port open
Serial.println("Adafruit_MPL3115A2 test!");
Startup();
}

void loop() {

acqTime=millis();
rawPressure = baro.getPressure();
rawAltitude = baro.getAltitude();
rawTemp = baro.getTemperature();

printRaw();
printTare();
printCorrected();
delay(100);
}

void Startup()
{
if (! baro.begin()) {
Serial.println("Couldnt find sensor");
return;
}

Serial.print("Recording Tare Values... Please wait 1 minute");

baro.getPressure(); //First is reading always wrong
for (int i=0; i <= 9; i++){
startPressure += baro.getPressure();
startAltitude += baro.getAltitude();
startTemperature += baro.getTemperature();
Serial.print(".");
}
startPressure = startPressure/10.0;
startAltitude = startAltitude/10.0;
startTemperature = startTemperature/10.0;

Serial.println();
Serial.print("Startup Tare Values Pressure (Pa), Altitude (m), Temperature (deg C):");
Serial.print(startPressure,3);
Serial.print(", ");
Serial.print(startAltitude,3);
Serial.print(", ");
Serial.print(startTemperature,3);
Serial.println();
startTime=millis();
}

void printRaw(){

Serial.println(); Serial.println("Raw MPL3115A3 Values: Time(Sec), Pressure(Pa), Altitude(m), Temperature(deg C)");

Serial.print((acqTime-startTime)/1000.0f,3);
Serial.print(", ");

Serial.print(rawPressure); Serial.print(", "); // Raw Pressure in Pascals
//Serial.print(rawPressure/3377,3); Serial.print(", "); // Raw Pressure in inHG
//Serial.print(rawPressure/100); Serial.print(", "); // Raw Pressure in milliBar

Serial.print(rawAltitude,3); Serial.print(", "); // Raw Altitude in meters
//Serial.print(rawAltitude*3.28084,3); Serial.print(", "); // Raw Altitude in ft

Serial.print(((rawTemp)),3); Serial.print(", "); // RawTemperature in Deg C
//Serial.print(((rawTemp*9/5)),3); // Raw Temperature in Deg F
Serial.println();
}

void printTare(){

Serial.println(); Serial.println("Tare Offset Values: Time(Sec), Pressure(mb), Altitude(ft), Temperature(deg F)");

Serial.print((acqTime-startTime)/1000.0f,3);
Serial.print(", ");

float pressure = rawPressure - startPressure;
//Serial.print(pressure); Serial.print(", "); // Tare Offset Pressure in Pascals
//Serial.print(pressure/3377,3); Serial.print(", "); // Tare Offset Pressure in Pascals Pressure in inHG
Serial.print(pressure/100); Serial.print(", "); // Tare Offset Pressure in Pascals Pressure in milliBar

float altitude = rawAltitude - startAltitude;
//Serial.print(altitude,3); Serial.print(", "); // Tare Offset Altitude in meters
Serial.print(altitude*3.28084,3); Serial.print(", "); // Tare Offset Altitude in ft

float temp = rawTemp - startTemperature;
//Serial.print(((temp)),3); Serial.print(", "); // Tare Offset Temperature in Deg C
Serial.print(((temp*9/5)),3); // Tare Offset Temperature in Deg F
Serial.println();
}

void printCorrected(){

Serial.println(); Serial.println("Corrected Values: Time(Sec), Pressure(mb), Altitude(ft), Temperature(deg F)");

Serial.print((acqTime-startTime)/1000.0f,3);
Serial.print(", ");

float pressure = (rawPressure - startPressure) + offsetPressureCorr;
//Serial.print(pressure); Serial.print(", "); // Corrected Pressure in Pascals
//Serial.print(pressure/3377,3); Serial.print(", "); // Corrected Pressure in inHG
Serial.print(pressure/100); Serial.print(", "); // Corrected Pressure in milliBar

float altitude = rawAltitude - startAltitude + offsetAltitudeCorr;
//Serial.print(altitude,3); Serial.print(", "); // Corrected Altitude in meters
Serial.print(altitude*3.28084,3); Serial.print(", "); // Corrected Altitude in ft

float temp = rawTemp - startTemperature + offsetTemperatureCorr;
//Serial.print(((temp)),3); Serial.print(", "); // Corrected Temperature in Deg C
Serial.print(((temp*9/5)+32),3); // Corrected Temperature in Deg F
Serial.println();
}

defragster
03-27-2016, 09:37 AM
Fixed a little bug..

Nice work Frank!

Windows10 with Prop board ( -w , -l and -r on foo.txt worked! As of course did -? ):
I pulled the code to libraries and a simple file foo.txt that was "dir > foot.txt" and then "dir >> foot.txt" extended the file and then showed and read the larger version!

Then looking for another file I did the 12K ZIP file : "C:\tCode\libraries\TeensyTransfer\extras\teensytra nsfer>teensytransfer.exe -w ..\teensytransfer.zip"

Filename was accepted - but too long:: teensytransfer.zip :: TeensyTransfer/issues/4 (https://github.com/FrankBoesing/TeensyTransfer/issues/4)

C:\tCode\libraries\TeensyTransfer\extras\teensytra nsfer>teensytransfer.exe -w ..\teensytransfer.zip

So now I get this with -l ::
C:\tCode\libraries\TeensyTransfer\extras\teensytra nsfer>teensytransfer.exe -l
874 foo.txt
12612 teensytransfer.zteensytransfer.zteensytransfer.zte ensytransfer.

Now of course I cannot erase that file.
I can write other files after it: ..\..\LICENSE and ..\..\README.md

And I can read those files, of course file names are case sensitive.

I even renamed teensytransfer.zip to Ttrans.zip and wrote that and then "teensytransfer.exe -r Ttrans.zip > ttzip.read" gave a usable file of the right size!

<edit>:
> ... so the problem isn't binary files or file type, but length of file name
> Do you take control of the entire FLASH space? Using :: #include <SerialFlash.h>
> With SerialFlash I can share and use this space in other sketches?
> Can you show how much room is left to show on list?
> I had to make this a comment to compile :: // #define _HAVE_EEPROM

> TYQT is HID aware - is there a way I can enter commands from there?

Seremu (open) \\.\HID#VID_16C0&PID_0486&MI_01#9&B0DB20&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}

And to TYQT serialEvent() works:

void serialEvent() {
while (Serial.available())
Serial.write( Serial.read() );
}

From a comment the other day and the code it seems FrankB knew he could Serial.print(). I put in hacks to get ttransfer.transfer( 1 ); to show the output of 'list' with Serial.print(). Not sure of the value/utility of this - but the TeensyTransfer code could be made a subroutine of other code. Odd that serialEvent() works when (!Serial) never goes true - which is why he was looking for a RAW_HID+USB it seems.

Frank B
03-27-2016, 01:04 PM
I had to make this a comment to compile :: // #define _HAVE_EEPROM
Hm we seem to have different versions ?
What is the error you get ?

I fixed the problem with the length of the filename (buffer-overflow). It is now limited to 63 characters.


Do you take control of the entire FLASH space?

Yes, the SerialFlash library does it :)



With SerialFlash I can share and use this space in other sketches?

Yes.


There was a request for a sorted output of -l (list files):
You can use "sort" to sort the output. The Syntax for Windows is:


Rem Sort Filesizes:
teensytransfer -l | sort




Rem Sort Filenames
teensytransfer -l | sort /+10


For reversed sorting, add "/r" to the options. For linux, see "sort --help"


Edit: I think there is a little confusion re: Serial/Seremu:

The Teensy Serial Monitor and TyQt both can work with seremu: You can still use "Serial.print()" in your sketches if you use "Raw Hid". But you get no "COM" device.

If you really need a "COM", you can use the included example-sektech to upload your files, and then switch back to usb-mode "Serial".
Or, you could try to edit the Teensy-core, which would give you both simultanously.

I have'nt found time to do it.

Edit: MAC executable is still unchanged (old) + untested.

Pensive
03-27-2016, 03:25 PM
Hi Paul,

I've done a little video review of the Prop Shield to post on youtube; When are the covers coming off - when can I upload the video?

Thanks

Jon

PaulStoffregen
03-27-2016, 04:19 PM
Here is a new build of a calibration app. NXPMotionSense recently changed to a new calibration data set & protocol. This is the first calibration app to write the new format.... so make sure you're running the latest on your Teensy.

This version adds much more info to the GUI.

I've tried to fix the problem(s) that were crashing on Mac. Both Windows and Mac still crash when you quit, but the question is whether they're stable while still running?

http://www.pjrc.com/teensy/beta/imuread/gui.linux64

http://www.pjrc.com/teensy/beta/imuread/gui.mac.zip

http://www.pjrc.com/teensy/beta/imuread/gui.exe

Known issues:

1 - crashes on quit
2 - doesn't confirm calibration written (but the protocol now can do it)
3 - poor ability to reduce variance error
4 - missing accelerometer & gyroscope cal
5 - nothing in the left-side panel yet...

KurtE
03-27-2016, 05:23 PM
Hi Paul,

Might help to have more information/instructions.

First attempt failed. Did not notice that calibration program changed names... So was not getting valid data... Updated to new one...

In App need to select appropriate com port.

Now what? I assume move the board around in many different directions, trying to get a sphere shape. But so far with mine, not able to get a good sphere...
Also so far file->Send Calibration is always grayed out.

6855

Edit: Should mention Windows 10 64bit

Frank B
03-27-2016, 06:11 PM
Downloaded newest version (+lib from github, too).

Works good and stable (Win 10 64Bit).

Perhaps add a Message "Close Serial Monitor", if port is not available.

Wozzy
03-27-2016, 06:33 PM
Perhaps add a Message "Close Serial Monitor", if port is not available.

I also noticed that on my WIN10 PC the Motion Sensor Calibration Tool does not read the port unless another program has read it first.

It's OK if I remove the line: while (!Serial) ; // wait for serial port open

Here's a screen capture.
6857
No matter how hard I try, I can't get below 5% error with less that 1% gaps.
Too bad you can't manually delete points, as there are always a few strays.

KurtE: Is there a lot of ferrous metal near your work bench?

Frank B
03-27-2016, 06:35 PM
I have 5% error, too, but i managed to get 0% gaps (waited a while with the teensy on my shoulder :)

Wozzy
03-27-2016, 07:13 PM
Right now it is on my nice and tidy(not) desk:
But I also wonder if it has to do with that I have the Teensy mounted above it.
I have also had the issues that the program would not do anything, but then maybe run the Arduino monitor, close it, then run...

My Teensy is mounted exactly the same way as yours. (BTW... have we gotten clearance to post photos yet?)
There's probably magnets in that servo and an iron core transformer in that power brick.

Yes, that works... my workaround also is to momentarily run Arduino Serial Monitor after compiling Calibrate Sensors, or repowering the PropShield.

PaulStoffregen
03-27-2016, 07:34 PM
Has anyone tried the latest (msg #358) on Macintosh? Is it more stable?

So far I've tested only on 10.7.5 (Lion).

KurtE
03-27-2016, 07:40 PM
Forgot and deleted post, although you could not really see anything

defragster
03-27-2016, 09:28 PM
I also noticed that on my WIN10 PC the Motion Sensor Calibration Tool does not read the port unless another program has read it first.

I was seeing that on older versions too - had to first hit the Teensy with TYQT then release port and the app would pick up, only I never diagnosed that far. while(!Serial) should be banned. I'm on Win10x64 - will try calibration again.

Frank: your TeensyTransfer has issues I'll (re)open on Github.
You missed the LONGNAME trashing that ISSUE was about? Two files uploaded below are orphaned trash.

C:\tCode\libraries\TeensyTransfer\extras\teensytra nsfer>TeensyTransfer -l | sort /r
12612 Ttrans.zip
12612 teensytransfer.zteensytransfer.zteensytransfer.zte ensytransfer.
1072 LICENSE
874 foo.txt
696 foofoofoofoo.txtfoofoofoofoo.txtfoofoofoofoo.txtfo ofoofoofoo.tx
623 README.md


C:\tCode\libraries\TeensyTransfer\TeensyTransfer.c pp: In member function 'void TeensyTransfer::eeprom_read()':
C:\tCode\libraries\TeensyTransfer\TeensyTransfer.c pp:303:19: error: 'eeprom_size' was not declared in this scope
sz = eeprom_size();

KurtE
03-27-2016, 09:46 PM
Has anyone tried the latest (msg #358) on Macintosh? Is it more stable?

So far I've tested only on 10.7.5 (Lion).
I just ran it on El Capitan 10.11.4 and it ran. Was able to save calibration, and it did not show the issue on windows of needing to open up Arduino monitor...

Crashed on exit

Frank B
03-27-2016, 09:47 PM
Yes it's limited to 63 characters. Thats intended - a question of definition if it is trashing..
Of course, i could print an error and defer upload if the filename is longer than 63 Chracters. Would that be better ?

RE: sz = eeprom_size();
hm. somehow an old version is on github..wonder why. i'll update it.

pictographer
03-27-2016, 09:54 PM
Has anyone tried the latest (msg #358) on Macintosh? Is it more stable?

So far I've tested only on 10.7.5 (Lion).

Just tried it with 10.9.5 on my ancient MacBook Pro. The desktop application runs, but I wasn't able to built the Teensy application in the little time I had for giving it a try. I grabbed files from github yesterday, but nothing would compile without moving files around and changing #include <> to #include "". I suppose I need to learn where to put library files.

So far, I've only seen serial output from the motion-related chips and I haven't been able to make sense of it.

defragster
03-27-2016, 10:13 PM
GUI.exe :: Motion Sense Calibration Tool : Won't Quit/Close/Exit [Win10x64pro] { three times used TaskMan end task }

Looks good, Error was around 1.7 - but filling all the gaps runs it higher. Sends Calibration - no 'on screen' confirmation that it was received - I do see LED pattern.

6861

After this image I just got Gaps 0.0% with 2% Fit Error.

Got it near (3+ inches) my magnetic closure phone case and got the cool 'solar flare' effect - Would it help to detect those events and suggest starting a new calibration session?

I found going to port:NONE and then back was the only way to restart the sample set?

defragster
03-27-2016, 10:24 PM
Yes it's limited to 63 characters. Thats intended - a question of definition if it is trashing..
Of course, i could print an error and defer upload if the filename is longer than 63 Chracters. Would that be better ?


File is uploaded - The name is only "foofoofoofoo.txt" but LIST shows it as "696 foofoofoofoo.txtfoofoofoofoo.txtfoofoofoofoo.txtfo ofoofoofoo.tx"
I did find I can READ and ERASE it with the original name.
{also with "teensytransfer.zip" displayed as "teensytransfer.zteensytransfer.zteensytransfer.zte ensytransfer." }



RE: sz = eeprom_size();
hm. somehow an old version is on github..wonder why. i'll update it.
Let me know what might be odd - should I use the TD1.28b1 SerialFlash library? It seems I have a local copy?
<edit>: Removed local SerialFlash - Sketch works the same, but still need to comment out the "//#define _HAVE_EEPROM" in TeensyTransfer.h

Ben
03-27-2016, 10:35 PM
I tested the new GUI on Win7 pro 64bit. Only issue was that I had to open the arduino serial monitor once to get past
while (!Serial) ; // wait for serial port open

Selecting the COM port in the GUI didn't help. Since that also stalls the led heartbeat I though my teensy was faulty for a second. Maybe change the heartbeat to interrupt-based or to change waiting for serial to non-blocking?

Lowest fit error I can get is about 4%

KurtE
03-27-2016, 10:59 PM
Maybe a little off the wall, but for the fun of it, I tried hooking up some Neopixels (Adafruit Jewel with 7 Neopixels) to the shield instead of APA102 leds... I used the Data pin (pin 11). Probably means that you can not use the storage with this hookup, but the Neopixel strandtest worked, after I changed pin=11 and added a setmode/digitalWrite for pin 7.

I mucked up a quick update to the heading program earlier to simply set one of the 6 outer Neopixels Red if the heading/60... Appears to work.


#include <Adafruit_NeoPixel.h>

#include <NXPMotionSense.h>
#include <Wire.h>
#include <EEPROM.h>

#define PIN 11
#define NUM_LEDS 7 //number of leds in strip length on one side


NXPMotionSense imu;
NXPSensorFusion filter;

Adafruit_NeoPixel strip = Adafruit_NeoPixel(7, PIN, NEO_GRB + NEO_KHZ800);
uint16_t loop_count = 0;

void setup() {
Serial.begin(9600);
imu.begin();
filter.begin();
pinMode(7, OUTPUT);
digitalWrite(7, HIGH);

strip.begin();
strip.show(); // Initialize all pixels to 'off'

for (int i=0; i < 4; i++) {
strip.setPixelColor(0, i*32, 0, 0);
strip.show();
delay(250);
}

}

void loop() {
float ax, ay, az;
float gx, gy, gz;
float mx, my, mz;
float heading;

if (imu.available()) {
// Read the motion sensors
imu.readMotionSensor(ax, ay, az, gx, gy, gz, mx, my, mz);

// Update the SensorFusion filter
filter.update(gx, gy, gz, ax, ay, az, mx, my, mz);
}

// roll = filter.getRoll();
// pitch = filter.getPitch();
heading = filter.getYaw();

// Serial.println(heading, 3);

strip.setPixelColor(0, loop_count & 0x1f, (loop_count >> 5) & 0x1f, (loop_count >> 10) & 0x1f);
loop_count += 4;

for (int x = 1; x < NUM_LEDS; x++) {
strip.setPixelColor(x, 0, 0, 0);
}
int iHeading = heading / 60 + 1;
strip.setPixelColor(iHeading, 80, 0, 0);
strip.show();
}

PaulStoffregen
03-28-2016, 12:48 AM
Got it near (3+ inches) my magnetic closure phone case and got the cool 'solar flare' effect - Would it help to detect those events and suggest starting a new calibration session?


I'm going to try some ideas to handle these cases much better. Ideally, when the gaps are under 20%, it should become possible to automatically purge this bad data, and most of the lower quality data causing the variance error. But rejecting bad data is tricky, because you don't know the good from the bad until you have a solid cal. If you start discarding data on non-random criteria, there's risk of an unstable feedback loop where a less than perfect cal causes wrong assumptions and discards good data that would have led to the cal improving. I worry & lose sleep over such things....

Also on my wish list is displaying obviously bad data in a different color, maybe black or gray.

I've also toyed with the idea of displaying new data in a brighter color, maybe even as a light source, and have it slowly "cool" to the normal color as the data ages. The idea would be to more easily see where you're adding new data, so it'd easier to figure out which way you need to turn.

At this moment I'm finalizing the product pages, so more work on the cal app will come in a tomorrow or Tuesday.

Wozzy
03-28-2016, 01:21 AM
Here's a link to a short video (https://youtu.be/kmaK-zkpmg8) I made of the Prop Shield + Teensy 3.1 + APA102 + FastLED 3.1
Warning there is an audio track.
https://youtu.be/kmaK-zkpmg8
6862
Built on NXPMotionSense library and also FastLED V3.1 fadeToBlackBy function.
Pitch = Position
Yaw = Hue
Roll = Saturation

All in all it's pretty responsive for a quickie program.

Here is the code:

#include <NXPMotionSense.h>
#include <Wire.h>
//#include <EEPROM.h>
#include "FastLED.h"
FASTLED_USING_NAMESPACE

NXPMotionSense imu;
NXPSensorFusion filter;

#define DATA_PIN 11
#define CLK_PIN 13
#define LED_TYPE APA102
#define COLOR_ORDER BGR
#define NUM_LEDS 144
CRGB leds[NUM_LEDS];
#define BRIGHTNESS 255
#define FRAMES_PER_SECOND 200
#define ARRAY_SIZE(A) (sizeof(A) / sizeof((A)[0]))
uint8_t gHue = 20; // rotating "base color" used by many of the patterns
uint8_t gSat = 255;
uint8_t pos = 72;

void setup() {
imu.begin();
filter.begin(100);

pinMode(7, OUTPUT);
digitalWrite(7, HIGH);
// tell FastLED about the LED strip configuration
FastLED.addLeds<LED_TYPE,DATA_PIN,CLK_PIN,COLOR_ORDER,DATA_RATE_MH Z(12)>(leds, NUM_LEDS).setCorrection(TypicalLEDStrip);
// set master brightness control
FastLED.setBrightness(BRIGHTNESS);
}

void loop() {
float ax, ay, az;
float gx, gy, gz;
float mx, my, mz;

if (imu.available()) {
// Read the motion sensors
imu.readMotionSensor(ax, ay, az, gx, gy, gz, mx, my, mz);

// Update the SensorFusion filter
filter.update(gx, gy, gz, ax, ay, az, mx, my, mz);

gHue = abs(2*filter.getYaw()*255/360);
gSat = 255-abs(filter.getRoll()*255/360);
pos = abs((filter.getPitch() * NUM_LEDS / 180) - (NUM_LEDS/2));
fadeToBlackBy( leds, NUM_LEDS, 8);
leds[pos] += CHSV( gHue, gSat, 255);
FastLED.show();
}
}

defragster
03-28-2016, 02:17 AM
I'm going to try some ideas to handle these cases much better. Ideally, when the gaps are under 20%, it should become possible to automatically purge this bad data, and most of the lower quality data causing the variance error. But rejecting bad data is tricky

Tricky was my expectation. That why I went as far as "suggest starting a new calibration session". If you did the colorization of such odd 'solar flare' type data - and show the percentage of data that is being used to alter the current state of the 'calibration update'. Maybe when 'Send Calibration' is selected you could pop up a dialog: " xx% of the data in this sample session appears out of bounds - Yes to save, no to start a new session "

This time I neared the magnet on purpose - the other day it was inadvertent because I was staring at the screen I wasn't watching my hand - but then I also knew I got near something drastic - so I looked to see what was around me.

BTW: with it lying on my desk I pushed my Cortex powered 'BAND' around it and nothing odd happened this time.

ALSO: to multitask here - Frank updated his TeensyTransfer and it compiles for me - he fixed the one long name garbage - then I found another oddity I told him about.

Frank B
03-28-2016, 05:16 PM
ALSO: to multitask here - Frank updated his TeensyTransfer and it compiles for me - he fixed the one long name garbage - then I found another oddity I told him about.

Yup, it's a little bug in SerialFlash. I created a pullrequest for fix, already.

defragster
03-28-2016, 07:30 PM
Frank - will free'd flash automatically ERASE and recycle? Having PC write access to Teensy flash it cool.

The SPIFFS on ESP8266 allows that - they implemented the SPI Flash File System and on a 4MB Flash, 1MB is code space and the other 3MB can be a SPIFFS device that takes OTA/FTP or Sketch FS operations, though coming in OTA/FTP requires a restart to see it.


Yup, it's a little bug in SerialFlash. I created a pullrequest for fix, already.
Good work again Frank, hopefully it'll make it in 1.28? This is too odd:


C:\tCode\libraries\TeensyTransfer\extras>dir > who2
C:\tCode\libraries\TeensyTransfer\extras>teensytransfer.exe -w who2
C:\tCode\libraries\TeensyTransfer\extras>teensytransfer.exe -l
874 foo.txt
12612 Ttrans.zip
623 README.md
1072 LICENSE
634 foo2☻z
688 foo2foofoofoo
792 who2♥↑
C:\tCode\libraries\TeensyTransfer\extras>teensytransfer.exe -e who2
teensytransfer: File not found

Frank B
03-28-2016, 08:41 PM
Frank - will free'd flash automatically ERASE and recycle?
No, the library does'nt do this - but you can erase the whole chip. May be i add an option for this..

This is too odd:

This happens only with filename with length of 15, 31, 47, or 63 bytes. So not a really big problem.
It happend to be so obvious, because TeensyTransfer shortens too long filesnames to 63 (64 incl trailing #0)

Best is, you erase the whole chip,and apply the patches to the lib (or use short filenames)

defragster
03-28-2016, 09:47 PM
FrankB - I went to your SerialFlash [patch_3] fork and then built 'teensytransferflash' - from a write of 'who3' lists as "who3♥E". This is a short name (ending in a number) - not a long name issue?



Multiple libraries were found for "SerialFlash.h"
Used: C:\tCode\libraries\SerialFlash

// line 242 of SerialFlashDirectory.cpp reads: addr += sizeof(buf);

Frank B
03-28-2016, 09:54 PM
Might be the other issue i fixed..
Did you apply both patches to SerolFlash, and erased the chip ?

If yes, can you somehow post an example that i can try myself ?
Perhaps a batchfile ?

maybe there is a third bug somewhere..

Edit: Maybe its better to open a new thread

Edit: Pls. restart arduino after patching, to be sure..


EDIT: Ok, the third bug was mine :)

defragster
03-28-2016, 10:13 PM
Frank - done - see this new thread : Teensy-Transfer-Tool-HID-access-to-SerialFlash (https://forum.pjrc.com/threads/33783-Teensy-Transfer-Tool-HID-access-to-SerialFlash)

{I pulled the github patch_3 - perhaps wrongly assumed it was cumulative. And I did not ERASE my flash.}

PaulStoffregen
03-28-2016, 11:03 PM
The Prop Shield pages are now on the website.

http://www.pjrc.com/store/prop_shield.html

http://www.pjrc.com/store/prop_shield_lowcost.html

I'd like to invite everyone to comment or give feedback. As you can see, there's still a few TODO items. I've almost certainly missed some important details too.

It's now ok to post photos of the beta prop shields. :)

Plenty of both are in stock. Anyone can place orders. They will start shipping Tuesday, March 29.

defragster
03-28-2016, 11:38 PM
Looks good Paul - my APA102'2 should be here in next hours. I saw TODO on current/LED count - I have a 30 LED Dotstar strip - how many LED's can I expect to work from a T_3.2 : five? [3*20ma * 5 = 300ma]

Would it make sense to put the MAJOR detail on the lowcost page and the NXP specific details only on the http://www.pjrc.com/store/prop_shield.html page and a LINK to the lowcost for the rest?

At $8.40 I assume more of those will be sold. Those opting for the wit MOTION version could find those added details, and that page could grow and grow - and those without would have just the AMP/FLASH/LED info in front of them which is quite a lot for the price - but doesn't seem apparent with how empty the lowcost page is right now.

PaulStoffregen
03-29-2016, 12:03 AM
I'll copy all the non-motion info soon, probably sometime next week.

JBeale
03-29-2016, 12:08 AM
"This shield features 10DOF motion sensors, 2 watt audio amp, high speed 5V buffers for driving APA102 LEDs, and an 8 Mbyte flash memory for images, sound clips, or data logging."
I gather the altimeter/pressure sensor is the 10th DOF ? It also has a temperature sensor, if that matters to anyone. Nice looking page anyway.

el_supremo
03-29-2016, 02:02 AM
Hi Paul:
A few typos etc. on the prop shield page.
http://www.pjrc.com/store/prop_shield.html

> The Prop Shield is meant interactive light
There's something missing here. This same error occurs on the low-cost Prop shield page.

> the Arduino Serial Monitor will show you computed Header
Heading?

> As you turn the board in each direct
direction

> The Prop Shield has 5V buffers meant to sending data
send

> to prevent other SPI chips from intefering
interfering

Pete

el_supremo
03-29-2016, 02:27 AM
the audio library will create a 1.2Vp-p signal at the DAC pin
Paul: perhaps point out that the DAC pin on the T3.2 must be wired to the DAC pin on the Prop shield since they aren't connected by the 14-pin headers?

Pete

defragster
03-29-2016, 05:37 AM
AdaFruit box got here - I can confirm the Prop Shield I got runs the sample code shown here (http://pjrc.com/store/prop_shield.html).

I can also pass along a tip, that swapping the Data and Clock line will allow some LED's to light - but in a way that is more disturbing than programmatically satisfying. Typing this reminded me someone already posted that the Prop Shield ordering of GND/CLK/DATA/5V != DotStar's GND/DATA/CLK/5V. And additionally that pulling the 5V line alone from the plug does not stop the DotStar from keeping some of those LED's lit, i.e. it must find some helpful voltage from said Clock and Data lines, made me think that flipping off my USB power switch might someday keep me from disaster, so far the Teensy has been robust enough tolerate my treating voltage like a compiler error - just edit it and try again without rebooting or unplugging anything.


I'll copy all the non-motion info soon, probably sometime next week.
Okay, I thought you were doing that on purpose to prevent duplication where one might not match the other someday without two updates.

syso
03-29-2016, 07:58 AM
@PaulStoffregen: So far I didn't see any problems with my board, but some indirect issue on OSX with the IMU GUI, which is used to calibrate.
Even after successful calibration, the File->Send Calibration is greyed out.

Update: I figured out this is due to the high error. Another error after calibration is: The values will always increase / the Processing demo will always keep rotating slowly.

Update2: MacBook Pro owners: Keep your Prop Shield at least 2-3 meters away from your MacBook. Either due to the aluminum unibody or magnets (or maybe interference) the calibration fails!

6870

defragster
03-29-2016, 09:22 AM
I cannot get stable data from filter.update()

I got my APA102's running - put R/G/B on the x/y/z axis values of the three sensors individually and that was good and stable - from within the CalibrateSensors sketch. I wrote a Min/Max function to track the values seen on each sensor so I could use the map() function to scale for my 30 LED strip.

Then I copied at Wozzy's prior post#375 sketch and tried that and got no lit LED's - changing the NUM_LEDS to match my 30 strip instead of his 144, I PM'd him about that in case his scaling included his 144.

I picked up the use of the filter.update(gx, gy, gz, ax, ay, az, mx, my, mz); and that seemed like a good step.

I just get Roll/Pitch/Yaw in a random display of R-G-B - very twinkly! When I check my Min/Max values that start at 1000,-1000 they are quickly set to full range values.

MinMax x, y, z __ val =0 / 359 __ val =-179 / 179 __ val =-89 / 89

This can only happen if the full range of values are seen - and I get that without moving my Prop Shield? When I start without moving the PropShield on the other three sensors I get an expected similar effect - but that is because Min/Max are changed to the power up value plus jitter until movement expands the Min/Max.

Writing that I wondered if I had an OLD libraries\NXPMotionSense - but I was current and a Sync'd copy does the same with an IDE restart. Is there something I failed to copy from Wozzy's simple example that would explain why I cannot get stable data from filter.update()? And does Wozzy's example work for others on a 30 LED strip?

My code is this: 6871

I started with the Prop_STORE sketch - just calling it loop2() and setup2() above the CalibrateSensors code, then call as needed. As noted for any one sensor x,y,z the same code gives stable results - except I could never isolate my movement to a single LED R.G.B scrolling perfectly to tell me which axis was which - I expected Y/P/R from Wozzy to do that?

My MAG calibration got to 2% and was stable -does that say all three sensors are working together or MAG only?

Wozzy
03-29-2016, 11:17 AM
I cannot get stable data from filter.update()
I copied at Wozzy's prior post#375 sketch and tried that and got no lit LED's

Defragster,
I'm away from my workbench right now, but earlier, I did cut and paste the code from the forum post#375 into my Arduino IDE just to verify that there were no errors there.
I'm running my Teensy 3.1 at 120Mhz. I did need to play with the FastLED DATA_RATE_MHZ(12) value to get stable results.
I'm running Arduino1.6.8 and Teensyduino 1.28B1 , Stock FastLED3.1 and the latest (as of yesterday) NXPMotionSense library.
Also interestiing that My APA102 strip had the wires in the same order as the Prop Shield Gnd-Clk-Data-5V.
Also, the LEDs on my strip are in BGR order and not RGB order.

Pensive
03-29-2016, 11:59 AM
The Prop Shield pages are now on the website.
It's now ok to post photos of the beta prop shields. :)

Here's the video review I did, I hope I pointed at the right chips....the chip codes dont match up with the schematic so I counted the pins!


https://www.youtube.com/watch?v=5gNlZPqD9JY

macaba
03-29-2016, 12:48 PM
Here's the video review I did, I hope I pointed at the right chips....the chip codes dont match up with the schematic so I counted the pins!

Thanks for the review video, I've ordered one from you :)

PaulStoffregen
03-29-2016, 02:33 PM
Hi Paul:
A few typos etc. on the prop shield page.


Thanks! Fixed now.

KurtE
03-29-2016, 03:22 PM
AdaFruit box got here - I can confirm the Prop Shield I got runs the sample code shown here (http://pjrc.com/store/prop_shield.html).
Typing this reminded me someone already posted that the Prop Shield ordering of GND/CLK/DATA/5V != DotStar's GND/DATA/CLK/5V.
Yep I mentioned that earlier.

Also I found in my case the connectors were connected to the output side of the strip and not the input. So was not getting much of anything, until I moved connectors to other side.

I just tried Wozzy's sample program for the APA102s... It works :D, but needed to edit the program to make it work correctly when NUM_LEDS != 144.

In particular where pos was calculated. It was:

pos = abs((filter.getPitch() * 144 / 180) - 72);

currently I have it as:

pos = abs((filter.getPitch() * NUM_LEDS / 180) - (NUM_LEDS/2));

Kurt

defragster
03-29-2016, 03:54 PM
Thanks Kurt - that was my speculation to Wozzy in PM - the scaling factors he derived had the NUM_LEDS factored in as a constant not the #define as you did. I was willing to wait on that - except it is clear I am getting FUNNY numbers from my filter.update() given that my Min/Max watcher sees near the full range of values while the Prop Shield is unmoved in the first 2000 reads. I get beautiful response and operation on x,y,z from the other three sets of sensors.

Hoping Paul can make it through my post - at least to say if the MAG Calibration uses only MAG or all three sensors to confirm if .update() effectively should work - as that reading why my code breaks AFAIK.

Kurt - can you try my posted code on your system? <edit>: call to loop2() at line 138 is the one using Y/R/P - swap the commented loop2() call line to see other sensors work

<edit> :: you made the right edit to the Wozzy code - it works the LED's with the edited "pos =" line. The other problem must be mine ???

Frank B
03-29-2016, 04:58 PM
My built with connectorboard v2 - all pins accessible:

6875

cyborgv2
03-29-2016, 07:17 PM
My built with connectorboard v2 - all pins accessible:

Beautiful :)

KurtE
03-29-2016, 08:17 PM
Kurt - can you try my posted code on your system? <edit>: call to loop2() at line 138 is the one using Y/R/P - swap the commented loop2() call line to see other sensors work
<edit> :: you made the right edit to the Wozzy code - it works the LED's with the edited "pos =" line. The other problem must be mine ???
It runs, not sure what it is supposed to do?

defragster
03-29-2016, 08:21 PM
<edit>:: I just moved the R/G/B for Roll/Pitch/Yaw code into Wozzy's sketch and it is working as expected. Not sure why it is failing in the other sketch - but all is well with Fusion on my Prop board.

Fairly stable and consistent. Oddly it has the gimbel lock apparent with one LED color per R/P/Y - nose up has two move in counter sync with each other - nose down they move in sync.


It runs, not sure what it is supposed to do?

As you move the PropShield the RGB lights should follow the Roll/Pitch/Yaw in some deterministic fashion - they should not be a twinkling mess. If you have SerMon - every so often you'll see my Max/Min pass by - showing the extremes of three sensors and then RPY, I see that 4th group as noted above showing the device is giving scattershot/full range readings while stationary- but my device works fine on Wozzy's code with your suggested re-scaling.

Pensive
03-29-2016, 08:37 PM
My built with connectorboard v2 - all pins accessible:

6875

There is something very elegant in it's simplicity - great work!

MichaelMeissner
03-30-2016, 12:43 AM
As i reported earlier, I had a solder mis-hap (trying to de-solder a right angle female header I put on the APA102 pin output), and the i2c sensors seemed to go missing. I did try to clean up the solder some more, and it looks like the sensors now respond to i2c detect requests once again, and the prop shield test spews a lot of numbers (I may have missed updates).

I was trying to access the flash memory, and I can't get anywhere. I've tried teensytethertool (on a Fedora 22 workstation) and -w file doesn't seem to work. I've downloaded new versions of the tool, and I'm still having problems (and not having the serial monitor means I can't put in println's to trace things).

I decided to try the RawHardwareTest from SerialFlash, and I get:



Raw SerialFlash Hardware Test

Read Chip Identification:
JEDEC ID: 0 0 0
Part Nummber: (unknown chip)
Memory Size: 1048576 bytes
Block Size: 65536 bytes

Reading Chip...
Previous data found at address 0
You must fully erase the chip before this test
found this: 00 00 00 00 00 00 00 00
correct: 00 00 00 00 15 F5 95 4B

Tests Failed :{

The flash chip may be left in an improper state.
You might need to power cycle to return to normal.


So I go to EraseEverything also from SerialFlash:



Flash Memory has 1048576 bytes.
Erasing ALL Flash Memory:
estimated wait: 3 seconds.
Yes, full chip erase is SLOW!
Erase completed
actual wait: 0 seconds.


I reran RawHardwareTest, and it gives me the same answer.

Just to be sure, I power cycle the Teensy 3.2 + prop shield, and I get the same thing as well.

Am I using the right sketches?

Would it be possible to have a 2 sketches in 1.28 examples, one that tests all of the functionality in the normal shield, and the other that tests things in the LC shield to verify that everything is as expected? Note, these would need to be standalone and not need separate tools to visualize the data or use a tool to download files to simplify complex setup issues.

manitou
03-30-2016, 11:48 AM
Am I using the right sketches?

Would it be possible to have a 2 sketches in 1.28 examples, one that tests all of the functionality in the normal shield, and the other that tests things in the LC shield to verify that everything is as expected? Note, these would need to be standalone and not need separate tools to visualize the data or use a tool to download files to simplify complex setup issues.

Using the SerialFlash examples as you did should work. You need to run EraseEverything first, and it should report 8 MB and take about 19 seconds. How is your teensy 3.2 attached to your prop shield? Seems that your de-soldering trauma may have messed up SPI access to shield's flash. flash uses 3.3v,grnd,11,12,13 with CS on pin 6.

EDIT:
Paul. it might be helpful if EraseEverything did some validation checks. As it is, it says things are erased even if SPI is disconnected. You might print the id[] and verify it's non-zero. After erase, you could read page 0 and verify that it is 256 0xff's. (of course, it could report 0xff's even if erase failed, but in my testing it seems to report 0's with disconnected/mis-wired SPI)

manitou
03-30-2016, 02:25 PM
The Prop Shield pages are now on the website.

http://www.pjrc.com/store/prop_shield.html

http://www.pjrc.com/store/prop_shield_lowcost.html

I'd like to invite everyone to comment or give feedback. As you can see, there's still a few TODO items. I've almost certainly missed some important details too.


In the Technical Details section you might add links to the data sheets for sensors, audio amp, and serial flash (and maybe do as Sparkfun does, and make your own copy of the PDFs on pjrc.com)

MichaelMeissner
03-30-2016, 02:45 PM
Using the SerialFlash examples as you did should work. You need to run EraseEverything first, and it should report 8 MB and take about 19 seconds. How is your teensy 3.2 attached to your prop shield? Seems that your de-soldering trauma may have messed up SPI access to shield's flash. flash uses 3.3v,grnd,11,12,13 with CS on pin 6.

EDIT:
Paul. it might be helpful if EraseEverything did some validation checks. As it is, it says things are erased even if SPI is disconnected. You might print the id[] and verify it's non-zero. After erase, you could read page 0 and verify that it is 256 0xff's. (of course, it could report 0xff's even if erase failed, but in my testing it seems to report 0's with disconnected/mis-wired SPI)

It looks like the CLK (pin 13) pin on the APA102 pinout is damaged, but the DATA (pin 11) pin is ok, as are ground and 5v pins.

I am getting sound through the DAC/amp when I enable it.

Note, I never tried the flash memory before, so I can't necessarily blame the attempt at un-soldering the APA102 leds.

I did run a blink test where each digital pin was turned on and then off, and I could see all of the main pins (0-23) did provide power when I put the Teensy + prop shield into a breadboard (this includes pins 6, 11-13). I'm now suspecting that I may not have proper solder connections to the shield itself for the SPI/flash pins (6, 11-13). So I'll check it tonight.

This is why I was hoping there was a sketch that checked to see if all of the proper connections were made. Given it should take 19 seconds to erase, and it took 0, I imagine something isn't soldered.

PaulStoffregen
03-30-2016, 03:12 PM
In the Technical Details section you might add links to the data sheets for sensors, audio amp, and serial flash (and maybe do as Sparkfun does, and make your own copy of the PDFs on pjrc.com)

Added. :)

JBeale
03-30-2016, 05:26 PM
Paul. it might be helpful if EraseEverything did some validation checks. As it is, it says things are erased even if SPI is disconnected. You might print the id[] and verify it's non-zero. After erase, you could read page 0 and verify that it is 256 0xff's. (of course, it could report 0xff's even if erase failed, but in my testing it seems to report 0's with disconnected/mis-wired SPI)

Is it possible to set weak pull-down resistors on the data input line for this test, so that you can tell for sure if the line is being driven high externally, or left floating?

Frank B
03-30-2016, 05:40 PM
This would help for the case when there is no flash connected or it puts its output to high-impendance, better than nothing.
But the id should be invalid in this case, too.

Maybe read the first bytes (128?) of each page ? or, if less than 8..16MB (to save time), read the whole flash, to be sure ?

Frank B
03-30-2016, 06:06 PM
(and not having the serial monitor means I can't put in println's to trace things).

The serial monitor works with RAW_HID, you can use Serial.print() !

But if your hardware is not working, this is meaningless.. :(

defragster
03-30-2016, 06:42 PM
RAW_HID can have a bit more lag to catch initial messages.

On pushing sketches or 'TYQT Reset' I've seen this more than a few times talking to the NXP hardware:
config error FXOS8700
I suppose the hardware is just caught in an odd state mid i2c transaction - but to recover takes a power cycle.

Here is the sketch I got working from the Wozzy APA102 sketch that puts R=Roll, G=Yaw, B=Pitch from the Fusion data. I put in sampling to get a centered WHITE LED from start position. Noted before Nose up/down the R/G pixels gimbal lock out/in sync. This is the same I was trying to do within the calibration sketch ("I cannot get stable data from filter.update()")and the RGB were all over the place - as if the sensors were not pulling together in the fusion data - though each sensor alone gave good data plotting the x,y,z in the same way.

6889 <edited sketch - will set point after seeing same point 10 times>

Frank B
03-30-2016, 07:18 PM
TyQT has a little bug with HID, too - when i have my other TODO's done, i'll post an example. Sometimes the monitor duplicates a character (somewhere near 128 bytes..127 or 129?).

manitou
03-30-2016, 08:42 PM
RAW_HID can have a bit more lag to catch initial messages.

On pushing sketches or 'TYQT Reset' I've seen this more than a few times talking to the NXP hardware:
config error FXOS8700

I suppose the hardware is just caught in an odd state mid i2c transaction - but to recover takes a power cycle.



Post #344 noted that you might be able to reset the I2C slaves (digital IO to the SCL/SDA) and avoid power cycle. i2c_t3 lib has a busReset_() that does this. you need to configure the pins back to I2C mode after the digital IO (part of busReset_())

I haven't tried it though ...

As Paul notes, it would be nice to know what causes the I2C to hang.

PaulStoffregen
03-31-2016, 12:18 AM
Bugfix for my flash problem:

In SerialFlashChip.cpp,
void SerialFlashChip::write(uint32_t addr, const void *buf, uint32_t len) {

add a delay:
.....


I've *finally* added this on github.

https://github.com/PaulStoffregen/SerialFlash/commit/c9c66e24b9e4e7cf0e3a64146044972faed6b11e

Sorry this took so very long. I've been pretty distracted by motion sensors and tons of mundane but critical PJRC business stuff the last couple weeks!

For now (and for Teensyduino 1.28) I'd like to go with the safest approach. We can optimize later. Eventually I want to seriously optimize all this to use the SPI FIFOs, so probably look at the timing issue then....

MichaelMeissner
03-31-2016, 12:34 AM
FWIW, I resoldered the pins 2, 6, 11-13, 18-19, 3.3v, AGND, 5v, and now I can run the various flash memory programs (EraseEveryThing, RawHardwareTest, and TeensyTransfer). I was able to download, list, and erase small files.

dpharris
03-31-2016, 01:17 AM
I have ordered a loaded and an unloaded Prop shield and they are winging their way to me. Looking foward to them.

defragster
03-31-2016, 01:52 AM
Post #344 noted that you might be able to reset the I2C slaves (digital IO to the SCL/SDA) and avoid power cycle. i2c_t3 lib has a busReset_() that does this. you need to configure the pins back to I2C mode after the digital IO (part of busReset_())

I haven't tried it though ...

As Paul notes, it would be nice to know what causes the I2C to hang.

Thanks Manitou - I missed that : force all I2C devices to reset (https://forum.pjrc.com/threads/33328-Prop-Shield-Beta-Test?p=100542&viewfull=1#post100542). I've seen it a a few times - and had it on the clipboard and it always got dumped before I got here.

My APA102 sketch is stable looking and good - like yesterday but restarted today. Right now the R&G&B are centered side by side since my earlier post ...

@MichaelM: Good job NOT toasting but recovering your Prop Shield

drichelson
03-31-2016, 03:27 AM
Hi, this thing looks awesome! I just ordered 2. Can someone describe the level of compatiblity with OctoWS2811 and specifically the OCTOWS2811 board sold by PJRC?

defragster
03-31-2016, 07:11 AM
Paul - Now that there are multiple PJRC product shields - a table of pin usage might help answer questions like P#418.

mortonkopf
03-31-2016, 10:00 AM
Frank. I am testing your teensy transfer on Mac. Setup is MacBook Pro (mid 2012 spec), Arduino IDE 1.6.7 with Teensyduino 1.2.7. These are both fresh installations this morning, with the latest SerialFlash from Paul's github, and a fresh download from yours: https://github.com/FrankBoesing/TeensyTransfer

The transfer tool works well for -w and -l. output is:

###:~ Home$ /Users/Home/Documents/Arduino/libraries/TeensyTransfer/extras/teensytransfer [-w] tty000 /Users/Home/Documents/Arduino/libraries/TeensyTransfer/test.rtf
###:~ Home$ /Users/Home/Documents/Arduino/libraries/TeensyTransfer/extras/teensytransfer -l
341 /Users/Home/Documents/Arduino/libraries/TeensyTransfer/test.rtf

from the IDE serial window, using the listless sketch, the window output is:

All Files on SPI Flash chip:
/Users/Home/Documents/Arduino/libraries/TeensyTransfer/test.rtf 341 bytes

I will now see about reading the file contents.
Question: what is the correct syntax / location to use, as it looks as though I am currently giving the written file a filename that is the whole file path?

mortonkopf
03-31-2016, 10:04 AM
Have used the read teensy transfer function. Output is:


###:~ Home$ /Users/Home/Documents/Arduino/libraries/TeensyTransfer/extras/teensytransfer -r tty000 /Users/Home/Documents/Arduino/libraries/TeensyTransfer/test.rtf
{\rtf1\ansi\ansicpg1252\cocoartf1348\cocoasubrtf17 0
{\fonttbl\f0\fswiss\fcharset0 Helvetica;}
{\colortbl;\red255\green255\blue255;}
\paperw11900\paperh16840\margl1440\margr1440\vieww 10800\viewh8400\viewkind0
\pard\tx566\tx1133\tx1700\tx2267\tx2834\tx3401\tx3 968\tx4535\tx5102\tx5669\tx6236\tx6803\pardirnatur al

\f0\fs24 \cf0 this is a test}
this is output for an rtf file containing the text "this is a test".

mortonkopf
03-31-2016, 11:20 AM
And, finally, using SerialFlash file.read(buffer, 512); read from the flash file and print contents to serial monitor for given number of char:


#include <SerialFlash.h>
#include <SPI.h>

const int FlashChipSelect = 6; // digital pin for flash chip CS pin

void setup() {
// wait for Arduino Serial Monitor
while (!Serial) ;
delay(100);
Serial.println("All Files on SPI Flash chip:");

if (!SerialFlash.begin(FlashChipSelect)) {
error("Unable to access SPI Flash chip");
}
}

void spaces(int num) {
for (int i=0; i < num; i++) {
Serial.print(" ");
}
}

char buffer[512];

void loop() {
SerialFlashFile file;
file = SerialFlash.open("/Users/Home/Documents/Arduino/libraries/TeensyTransfer/test.rtf");
//your file name
if (file) { // true if the file exists
Serial.println("exists!");

file.read(buffer, 512);}
for (int x=0;x<512;x++){
Serial.print(buffer[x]);}
Serial.println("...end");
blinkLed();
}

void error(const char *message) {
while (1) {
Serial.println(message);
delay(2500);
}
}

void blinkLed()
{
digitalWrite(13, HIGH);
delay(1);
digitalWrite(13, LOW);
}

serial monitor output is:

exists!
{\rtf1\ansi\ansicpg1252\cocoartf1348\cocoasubrtf17 0
{\fonttbl\f0\fswiss\fcharset0 Helvetica;}
{\colortbl;\red255\green255\blue255;}
\paperw11900\paperh16840\margl1440\margr1440\vieww 10800\viewh8400\viewkind0
\pard\tx566\tx1133\tx1700\tx2267\tx2834\tx3401\tx3 968\tx4535\tx5102\tx5669\tx6236\tx6803\pardirnatur al

\f0\fs24 \cf0 this is a test}...end

the object is now to use the file to hold Led data sets, and send data to the led strip rather than to the monitor (debug).

Frank B
03-31-2016, 11:25 AM
Great that it works on MAC !
It's still an old version with some minor bugs (and the files must be in the same directory as teensytransfer, on MAC in this old version)- and i can't compile it :)
Unfortunately, now, the MAC Version is not able to access the Teensy EEPROM.

I'll add some more functions (parallel connected flash, perhaps erase chip) in the days, and then ask somebody who owns a MAC to do a fresh compile..
I'll open a new thread then, which will contain a "howto".

MichaelMeissner
03-31-2016, 11:30 AM
Paul - Now that there are multiple PJRC product shields - a table of pin usage might help answer questions like P#418.

I put together the following spreadsheet to keep track of all of the Teensy's and shields. Unfortunately, it is starting to get too big to fit without having to scroll horizontally: https://docs.google.com/spreadsheets/d/1LSi0c17iqtvpKuNSYksMG306_FpWdJcniSRR6aGNNYQ/edit#gid=1103027528

JBeale
03-31-2016, 03:29 PM
I put together the following spreadsheet to keep track of all of the Teensy's and shields. Unfortunately, it is starting to get too big to fit without having to scroll horizontally: https://docs.google.com/spreadsheets/d/1LSi0c17iqtvpKuNSYksMG306_FpWdJcniSRR6aGNNYQ/edit#gid=1103027528
Very nice; that's a great summary of the pinouts. Is that link suitable for long-term reference?

MichaelMeissner
03-31-2016, 04:26 PM
Very nice; that's a great summary of the pinouts. Is that link suitable for long-term reference?

I don't plan on changing the location (but I will from time to time add more microprocessors, etc.).

blackketter
03-31-2016, 04:52 PM
I put together the following spreadsheet to keep track of all of the Teensy's and shields. Unfortunately, it is starting to get too big to fit without having to scroll horizontally: https://docs.google.com/spreadsheets/d/1LSi0c17iqtvpKuNSYksMG306_FpWdJcniSRR6aGNNYQ/edit#gid=1103027528
Awesome! This would be perfect information for the upcoming(?) wiki...

MichaelMeissner
03-31-2016, 05:42 PM
I was trying to hack the WAV player example to use the prop shield flash memory, and I'm not sure I'm missing something obvious. After posting it, I did discover I forgot to enable the SerialFlash chip, and I edited to to add that initialization, and corrected the pin for the AMP.

First of all, I was using this sketch to test to see if the speaker, etc. was connected, and I could use +/- to increase/decrease the pitch, and it works fine:



#include <SPI.h>
#include <SD.h>
#include <Wire.h>
#include <Audio.h>
#include <SerialFlash.h>

// from: https://forum.pjrc.com/threads/33328-Prop-Shield-Beta-Test?p=99236&viewfull=1#post99236
// modified by Michael Meissner

// GUItool: begin automatically generated code
AudioSynthWaveformSine sine1; //xy=180,469
AudioOutputAnalog dac1; //xy=380,468
AudioConnection patchCord1(sine1, dac1);
// GUItool: end automatically generated code

int freq = 1000;

void setup() {
Serial.begin(115200);
while (!Serial)
;
Serial.println("Setting up");
pinMode(5, OUTPUT);
digitalWrite(5, 1); // Enable Amplified.
AudioMemory(12);
sine1.amplitude(1.0);
sine1.frequency(freq);
Serial.println("Send + to increase freq, - to decrease freq, a to turn off amp, A to turn on amp, or num for freq.");
}

void loop()
{
if (Serial.available()) {
int ch = Serial.read();
switch (ch)
{
case '+':
freq += 100;
sine1.frequency(freq);
Serial.print ("New frequency ");
Serial.println (freq);
break;

case '-':
freq -= 100;
sine1.frequency(freq);
Serial.print ("New frequency ");
Serial.println (freq);
break;

case 'a':
digitalWrite (5, 0);
Serial.println ("Amp off");
break;

case 'A':
digitalWrite (5, 1);
Serial.println ("Amp on");
break;

case '0':
case '1':
case '2':
case '3':
case '4':
case '5':
case '6':
case '7':
case '8':
case '9':
{
bool looping = true;
freq = ch - '0';
do
{
if (Serial.available ())
{
ch = Serial.read ();
if (ch >= '0' && ch <= '9')
freq = (freq * 10) + (ch - '0');
else
looping = false;
}
}
while (looping);
}

Serial.print ("New frequency ");
Serial.println (freq);
sine1.frequency(freq);
break;

case ' ':
case '\n':
case '\t':
case '\r':
break;

default:
Serial.print ("Unknown character '");
Serial.print ((char) ch);
Serial.print ("'");
}
}
}


I converted 4 WAV files of Halloween sounds to RAW using the following command on Linux:



$ for x in SDTEST{1,2,3,4}; do sox $x.WAV --bits 16 --rate 44100 --channels 1 $x.RAW; done


I erased the flash memory with: ./hardware/teensy/avr/libraries/SerialFlash/examples/EraseEverything/EraseEverything.ino

I downloaded TeensyTransfer to the Teensy, and used teensytransfer to copy the 4 RAW files to the flash memory:



$ teensytransfer -l
$ for x in SDTEST{1,2,3,4}; do teensytransfer -w $x.RAW; done
$ teensytransfer -l
232072 SDTEST1.RAW
382464 SDTEST2.RAW
203676 SDTEST3.RAW
296704 SDTEST4.RAW


I uploaded this sketch to the Teensy:



// Originally from Teensy release:
// hardware/teensy/avr/libraries/Audio/examples/WavFilePlayer/WavFilePlayer.ino
//
// Simple WAV file player example
//
// Three types of output may be used, by configuring the code below.
//
// 1: Digital I2S - Normally used with the audio shield:
// http://www.pjrc.com/store/teensy3_audio.html
//
// 2: Digital S/PDIF - Connect pin 22 to a S/PDIF transmitter
// https://www.oshpark.com/shared_projects/KcDBKHta
//
// 3: Analog DAC - Connect the DAC pin to an amplified speaker
// http://www.pjrc.com/teensy/gui/?info=AudioOutputAnalog
//
// To configure the output type, first uncomment one of the three
// output objects. If not using the audio shield, comment out
// the sgtl5000_1 lines in setup(), so it does not wait forever
// trying to configure the SGTL5000 codec chip.
//
// The SD card may connect to different pins, depending on the
// hardware you are using. Uncomment or configure the SD card
// pins to match your hardware.
//
// Data files to put on your SD card can be downloaded here:
// http://www.pjrc.com/teensy/td_libs_AudioDataFiles.html
//
// This example code is in the public domain.

#include <Audio.h>
#include <Wire.h>
#include <SPI.h>
#include <SD.h>
#include <SerialFlash.h>

AudioPlaySerialflashRaw playRaw1;
AudioOutputAnalog audioOutput;

#define PROP_AMP_ENABLE 5
#define FLASH_CHIP_SELECT 6

void setup() {
Serial.begin(9600);

// wait up to 3 seconds for the Serial device to become available
long unsigned debug_start = millis ();
while (!Serial && ((millis () - debug_start) <= 3000))
;

Serial.println ("Start prop shield wav player");

// Enable the amplifier on the prop shield
pinMode(PROP_AMP_ENABLE, OUTPUT);
digitalWrite(PROP_AMP_ENABLE, HIGH);

// Audio connections require memory to work. For more
// detailed information, see the MemoryAndCpuUsage example
AudioMemory(8);

// Start SerialFlash
if (!SerialFlash.begin(FLASH_CHIP_SELECT)) {
while (1)
{
Serial.println ("Cannot access SPI Flash chip");
delay (1000);
}
}
}

void playFile(const char *filename)
{
Serial.print("Playing file: ");
Serial.println(filename);

// Start playing the file. This sketch continues to
// run while the file plays.
playRaw1.play(filename);

// A brief delay for the library read WAV info
delay(5);

// Simply wait for the file to finish playing.
while (playRaw1.isPlaying()) {
// uncomment these lines if you audio shield
// has the optional volume pot soldered
//float vol = analogRead(15);
//vol = vol / 1024;
// sgtl5000_1.volume(vol);
}
}


void loop() {
playFile("SDTEST1.RAW"); // filenames are always uppercase 8.3 format
delay(500);
playFile("SDTEST2.RAW");
delay(500);
playFile("SDTEST3.RAW");
delay(500);
playFile("SDTEST4.RAW");
delay(1500);
}


And it hangs after printing Playing the SDTEST1.RAW lin.

I put the .WAV and .RAW files here: http://www.the-meissners.org/tmp/SDTEST.zip.

manitou
03-31-2016, 06:08 PM
do you need to define an AudioConnection?

MichaelMeissner
03-31-2016, 06:10 PM
do you need to define an AudioConnection?

Probably, I'll look at it tonight. As I said, I probably was missing something obvious. I didn't use the audio tool, but instead tried to hack up the WavFilePlayer example.

macaba
03-31-2016, 08:23 PM
I've received and assembled my prop shield (awesome bit of kit!) and did some benchmarking of the actual filter compute methods:

Teensy 3.2 @ 120MHz
NXPSensorFusion - 3500 us
Madgwick - 225uS
Mahony - 127uS

Notes and observations:

- In the Madgwick example, I believe filter.updateIMU should be changed as a default to filter.update (which is commented out on the line below).
- The Mahony example gives me a -14 degree Roll offset compared to the other 2.
- I was not able to get the calibration gui.exe to work on Windows 7 without opening Arduino monitor first to trigger data sending. It worked fine on OSX 10.11.4 first time.
- More usage is required but it feels like the NXPSensorFusion is currently giving the best results which may make it worth the CPU load.

defragster
03-31-2016, 09:05 PM
Probably, I'll look at it tonight. As I said, I probably was missing something obvious. I didn't use the audio tool, but instead tried to hack up the WavFilePlayer example.

Funny thing - I decided to try it - it ran FINE with no files of those names actually on the flash. I put the files on from the ZIP and like @MM - it prints this and stops:

Start prop shield wav player
Playing file: SDTEST1.RAW

Frank B
04-01-2016, 12:05 AM
Question: what is the correct syntax / location to use, as it looks as though I am currently giving the written file a filename that is the whole file path?
Yes, that's an issue in the old MAC Version. It is solved for Windows and Linux.
Unfortuantely, i can't compile it for MAC.

Here are some explanations:
https://forum.pjrc.com/threads/33859-TeensyTransfer?p=101178#post101178

manitou
04-01-2016, 01:44 AM
Probably, I'll look at it tonight. As I said, I probably was missing something obvious. I didn't use the audio tool, but instead tried to hack up the WavFilePlayer example.

i added AudioConnection patchCord1(playRaw1, audioOutput);
to the sketch and it is playing TOPGUN.RAW clip (24s) just fine!
I converted audio ogg to wav to raw and teensytransfer TOPGUN.RAW 2116800 bytes

Take my breath away ...

defragster
04-01-2016, 02:14 AM
i added AudioConnection patchCord1(playRaw1, audioOutput); ...

That did it - now I have EARIE Halloween sounds in the air. Nice sampleS @MichaelM ... thanks manitou

MichaelMeissner
04-01-2016, 02:39 AM
Thanks Manitou. I missed the AudioConnection. It works fine now.

Defragster: The sounds are from soundbible.com, which includes public domain sounds (the first, third, and fourth) and personal use only (second) sounds:

http://soundbible.com/1627-Female-Scream-Horror.html;
http://soundbible.com/130-Werewolf-Howl.html;
http://soundbible.com/1362-Old-Door-Creaking.html; and
http://soundbible.com/1352-Large-Metal-Rusty-Door.html.


Paul, I think it would be helpful if 1.28 had something similar the above exercise (feel free to copy/edit my version or use your own version) to show a useful way to use the prop shield, assuming TeensyTransfer is also included. However, I suspect you might not want to use the werewolf howling, since that is not public domain. Perhaps this version of many wolves howling, which is PD: http://soundbible.com/278-Many-Wolves-Howling.html.

FWIW, the sounds you provide for the audio shield are too large to use on the prop shield.

<edit>
The speaker I'm using is the Breadboard-Friendly PCB Mount Mini Speaker - 8ohm, 0.2w that I got from Adafruit: https://www.adafruit.com/products/1898.

I'm not a fan of their thin plastic speaker (https://www.adafruit.com/products/1891) or their mini metal speaker (https://www.adafruit.com/products/1890), since the wires seems to come unsoldered, and there is nothing to attach the speaker to

PaulStoffregen
04-01-2016, 08:56 AM
I also noticed that on my WIN10 PC the Motion Sensor Calibration Tool does not read the port unless another program has read it first.

It's OK if I remove the line: while (!Serial) ; // wait for serial port open


Hopefully this patch will fix it.

https://github.com/PaulStoffregen/IMUread/commit/89f76f91fdaf30ed691a8e8a46e60d8de2fd4f9c

I'm also working on ideas to get the variance error down, but that's much harder...

PaulStoffregen
04-01-2016, 09:00 AM
Crashed on exit

After several attempts, this bug turned out to be a little embarrassing... the redraw timer was still running, causing an attempt to redraw after the window was gone, as the program was shutting down.

Simple to fix, once understood.

https://github.com/PaulStoffregen/IMUread/commit/5225e32aac653f1a8663b661080a9f485c690b93

MichaelMeissner
04-01-2016, 11:40 AM
Paul, I know the LC (witout) prop shield does not have the 3 sensors, but does it still have the pull-up resistors so SDA/SCL can be used for an i2c bus? Or would I need to add the appropriate resistors with the LC prop shield?

mortonkopf
04-01-2016, 12:42 PM
Yes, that's an issue in the old MAC Version. It is solved for Windows and Linux.
Unfortuantely, i can't compile it for MAC.

Here are some explanations:
https://forum.pjrc.com/threads/33859-TeensyTransfer?p=101178#post101178
RE Mac, if nobody has this in their sight to compile the Teensytransfer for Mac, I will have a look at it over the weekend.

PaulStoffregen
04-01-2016, 01:34 PM
Paul, I know the LC (witout) prop shield does not have the 3 sensors, but does it still have the pull-up resistors so SDA/SCL can be used for an i2c bus?

Yes, it has the 2.2K resistors. The other schematic is on my TO-DO list....

PaulStoffregen
04-01-2016, 01:40 PM
Here's a new version of the calibration program.

Mac:
http://www.pjrc.com/teensy/beta/imuread/MotionCal.dmg

Windows:
http://www.pjrc.com/teensy/beta/imuread/MotionCal.exe

Linux 64 bit:
http://www.pjrc.com/teensy/beta/imuread/MotionCal.linux64

Changes since the last version:


Variance error automatically improves, when gaps under 25%
Fix crash on quit
Fix Teensy stuck in while (!Serial) with Windows - TODO: needs testing
Windows and Mac versions signed - TODO: needs verify on El Capitan
Mac version uses DMG disk image
Name changed to "MotionCal"

PaulStoffregen
04-01-2016, 01:44 PM
Oh, I should mention the variance reduction begins slowly when gaps gets to 25%. The rate steadily increases as gaps is reduced, until gaps gets to 1% or less.

At least that's how it's supposed to work.....

In theory this should allow getting much better calibration, with all errors under 2% without a huge amount of work. Maybe? Please let me know how it actually works for you in practice?

pictographer
04-01-2016, 02:52 PM
[Edit: Success!
6896
Things I was missing:

The URL in the About box does point to a page that points to the Git Hub project that has the Teensy side of the calibration. It would still be good for the PC side "Motion Sensor Calibration Tool" to report troubles communicating with the Teensy/Prop shield.
No Teensy files need to be edited if the entire directory from Git Hub is copied into ~/Documents/Arduino/libraries. I'm using Arduino 1.6.8/Teensyduino 1.28-beta1 on OS X 10.9.5 Mavericks.
Can't have the Arduino IDE running while MotionCal is trying to talk to the Teensy. May need to restart MotionCal or the Teensy multiple times before they find each other.
Some patterns of movement during calibration lead to convergence quicker than others. Waving the Prop Shield around seems to help. Putting it down on the desk, not so much.


Things I'm still wondering about:

Why does the calibration get dramatically worse sometimes?
Why does the sphere of dots slowly roll when the Prop Shield is relatively still and certainly not rolling?
Why do the Accelerometer and Gyroscope fields report all zeros?
After "Send Calibration" is performed, is there anything needed in subsequent sketches to make use of the calibration?
Is there any way to capture the calibration data or metadata other than attempting a screen shot as quickly as possible after sending the calibration?
Which parameter(s) should be optimized? I'm assuming first priority would be getting the "Fit Error" as low as possible. Is 1.8% a good number?
How long should the calibration process take? It seems long to me.
When should re-calibration be done? Obviously if the environment changes or the readings get worse, but is it expected that it's done daily, annually, just once, etc?

]


MotionCal feature request: Add a menu item to load the appropriate hex file to the Teensy.

If this is not a good idea, perhaps add some help text with the URL of the instructions for preparing the Teensy for Prop Shield calibration.


[Edit: and error messages about being unable to communicate with the Teensy/Prop Shield would be helpful, too.]

macaba
04-01-2016, 04:00 PM
Please let me know how it actually works for you in practice?

Thank you Paul, I'll report back the results on El Capitan in about 2 hours.

MichaelMeissner
04-01-2016, 04:26 PM
I'm wondering whether anybody has started making a prop shield version of a light saber? It would seem to be the right size to fit in the general saber handles, and all you would need is a speaker, battery, and appropriate LEDs.

Robin
04-01-2016, 04:37 PM
I'm wondering whether anybody has started making a prop shield version of a light saber? It would seem to be the right size to fit in the general saber handles, and all you would need is a speaker, battery, and appropriate LEDs.

I've been debating whether or not to find someone in the 501st or Rebel Legion who looks like a good candidate to send a Prop Shield to do just that. :)

cartere
04-01-2016, 08:07 PM
Under Ubantu 14.04 do not get a port using MotionCal.linux64, menu item is there nothing under it when clicked. Can see the data spew in serial monitor but with monitor closed nothing in MotionCal.

PaulStoffregen
04-01-2016, 08:17 PM
That's very strange. To show up in the ports menu, the /dev/ttyACM0 file only needs to exist when the readdir() is used on "/dev/". It doesn't even need to be readable or usable to appear in the menu.

I develop on Ubuntu 14.04, where it's always worked. So I have no idea why or how it could possible do such a thing!

macaba
04-01-2016, 08:19 PM
Thank you Paul, I'll report back the results on El Capitan in about 2 hours.

I can report good results on 10.11.4 with all errors under 2% as you said. It also exits seamlessly now. :)

PaulStoffregen
04-01-2016, 08:19 PM
Hmmm... the Mac version might have a problem with lingering after quit, perhaps preventing a Mac from shutting down without a force quit. Maybe? Or maybe that was an older copy lingering on my mac?

If anyone with a newer Mac can test, please let me know?

cartere
04-01-2016, 08:23 PM
Downloaded, marked executable from gui, double clicked, comes up fine just no port.

manitou
04-01-2016, 08:57 PM
works for me under ubuntu 14.04 (make sure you built with Serial and not Raw HID)

KurtE
04-01-2016, 09:09 PM
It appeared to run Ok on my MAC 10.11.4

MichaelMeissner
04-02-2016, 06:01 AM
I've been debating whether or not to find someone in the 501st or Rebel Legion who looks like a good candidate to send a Prop Shield to do just that. :)

It probably wouldn't hurt to ask. I was curious, because I hadn't seen much about light saber build requests recently.

In early 2015, there was this post by forstyjr: https://forum.pjrc.com/threads/27861-Light-Saber-sound-card-project. It ends with the sound card being a little too big, and then nothing. Obviously the smaller footprint of the prop shield would help here.

And then in November, there was this post by Grimmdus: https://forum.pjrc.com/threads/31349-Teensy-3-2-Lightsaber, and on another group: http://forums.thecustomsabershop.com/showthread.php?18795-Teensy-Lightsaber. It looks like the sound stuff was working (using the audio shield) but then the focus changed to driving the LEDs, and getting into much higher power LEDs than your normal APA102's or WS2812's.

And there was this also in November by Jared Barney: https://trello.com/b/1MbM08rb/long-hilt-teensy-lightsaber-project.

A month ago there was a posting on Reddit: https://www.reddit.com/r/arduino/comments/44hybi/help_with_teensy_sound_installation/

Here is a DIY lightsaber kit that uses an Arm Cortex M3 and various things in the prop shield: http://www.artekit.eu/diy-lightsaber-audio-board/. This isn't a Teensy, but somehow it came up on the google search.

Other than these, it seems a lot of people tend to use off the shelf solutions, either by just taking the toy sabers and harvesting the electronics as it, or using something like the ultrasabers.com soundcard.

Soundbible does have personal use wav/mp3's of the various saber sounds (http://soundbible.com/tags-lightsaber.html), but I suspect a company like PJRC.com needs to be careful of such things.

Soundsnap has more sounds, but I can't see what the rights are to them: http://www.soundsnap.com/tags/light_saber.

GremlinWrangler
04-02-2016, 06:15 AM
MichaelM, agree that it was the first thing I thought of looking at the prop shield and have been noodling around with synthasis of effects via the audio library as per a prior post. So far have come up against the fact the speaker size that might conceivably fit in an handle of such a thing doesn't handle the bass that my brain insists is needed.

Now trying to re-design the effects for less THX and more treble. The idea is to allow seamless flowing audio, rather than restricting play to audio clips, though suspecting a SD card full of audio from one of those above linked sites is a far more robust and simpler route to a result.

MichaelMeissner
04-02-2016, 06:29 AM
Well one silly thought is to run the speaker wire up your arm, and wear a giant subwoofer on your back. Of course you then probably need the resources of the full sound card with stereo, and not the tiny mono amp on the prop shield. Or maybe something like a nRF2401+ connection to a separate teensy that does the sound (and you have a simple command, like play sound 1).

<edit>
In the end, the prop shield is a compromise to keep the cost/size/power down. It can do many things, but there are things beyond its envelope.

GremlinWrangler
04-02-2016, 06:48 AM
Concur that the prop shield beats my prior project light saber project which had to graft together various sub units and pray they didn't fall apart while in use. Though may need to go shopping with onehorse for a power converter to finish it off.

As you note the right solution to the low frequency volume problem is to have a single subwoofer base station that your saber/s cue via RF.

MichaelMeissner
04-02-2016, 09:17 PM
Bummer, I was about to move a larger sound (2 minutes, 39 seconds) to the prop shield and it is too large for the flash memory. The mp3 variant is 4.4 megabytes, the ogg variant is 3.3 megabytes. However, when I convert it to RAW, it is 14 megabytes (and 27 megabytes if converted to wav). Too bad we don't (currently) have ogg converters in SerialFlash.

I have other ways to play this sound (audio shield, and some standalone mp3 players), but it would have been nice to keep it on the smaller form factor of the prop shield.

Frank B
04-02-2016, 09:22 PM
Maybe i update my m3-lib to use Pauls SerialFlash next week....

manitou
04-02-2016, 09:30 PM
I was checking 3.3v power usage with meter, all seemed reasonable at first. But now reading the gyro consumes 20ma ?? (datasheet says 2.7 ma active). I wonder if I fried something jumpering meter inline here and there??? gyro seems to be sending out different values when unit is moved ....

SPI flash was only taking 2.8ma doing erase and 1.5ma doing reads. altimeter 2.5ma, accel/mag 0.26ma

prop shield power consumption

With a second prop shield I re-tested the the power consumption with a DMM. The previous measurements were confirmed and conistent with the datasheet specs. Reading the motion sensors (imu.readMotionSensor(ax, ay, az, gx, gy, gz, mx, my, mz)) in the loop of the Orientation example only consumes 4 ma on the 3.3v feed. The Vin (5v) draws another 1.4 ma.

With the audio amp running a sine-wave sketch, Vin draws 120 ma to 8-ohm 0.5 watt speaker. If I increase the volume (analogReference(EXTERNAL)), the current goes to 280ma. If I play a .RAW music clip the average draw is 25 ma, and with EXTERNAL grows to 62 ma. LED strips can draw lots more power!

The gyro power anomaly I observed was from running an Arduino sketch (https://github.com/sabas1080/FXAS21002C_Arduino_Library) to exercise just the gyro. This sketch aggressively configures the gyro, and the gyro draws 24ma (even though the datasheet says 2.7ma active). @onehorse 's prop shield sketch (https://github.com/kriswiner/Teensy_Prop_Shield) provided in an earlier post also uses this aggressive gyro configuration and subsequently averages around 15ma in the readSensor loop. (The altimeter configuration also draws 20ma.) Paul's gyro configuration is much more power-friendly.

JBeale
04-03-2016, 04:55 AM
Using the current code I got a good mag cal (under 2%) and observed good performance with the orientation visualiser in Processing, *except* when the board is oriented vertically and rotated slowly around the long axis, the image onscreen rotates erratically. Looks like a numerical instability near that one orientation. I can do a video demonstating the effect if the description is unclear.

defragster
04-03-2016, 06:07 AM
Using the current code I got a good mag cal (under 2%) and observed good performance with the orientation visualiser in Processing, *except* when the board is oriented vertically and rotated slowly around the long axis, the image onscreen rotates erratically. Looks like a numerical instability near that one orientation. I can do a video demonstating the effect if the description is unclear.

I got 2% once - it seems the longer it takes to fill the gaps, the more likely out of bounds data gets counted in the sample, pushing the 2% number higher.

In my YawPitRol sketch built on the Wozzy sketch I noted I saw the two YAW/ROLL axis lock out of sync vertically up and in sync vertically down when using the Fusion data. This was noted with the Processing image of the board by some (until the axis order was corrected) and I found a link on Gimbal lock noted in this post (https://forum.pjrc.com/threads/33328-Prop-Shield-Beta-Test?p=100286&highlight=gimbal#post100286) with a video showing it being corrected on a CGI robot.

Ben
04-03-2016, 10:23 AM
Using the current code I got a good mag cal (under 2%) and observed good performance with the orientation visualiser in Processing, *except* when the board is oriented vertically and rotated slowly around the long axis, the image onscreen rotates erratically. Looks like a numerical instability near that one orientation. I can do a video demonstating the effect if the description is unclear.

Please try this:

https://github.com/Ben-Rheinland/NXPMotionSense/blob/master/OrientationVisualiser/OrientationVisualiser.pde

It's only tested on Windows, but I don't see what could go wrong on Mac/Linux. Hit the h key on your keyboard after bringing the visualizer window into focus to bring up the help.

Pensive
04-03-2016, 01:17 PM
I just recommended the prop-shield-LC to a customer for running neopixels at 5V, with a Teensy 3.2.

While this technically will work fine (if those pinouts work for APA102s they must be fine for neopixels) has anyone tried sticking a neopixel strip on one of the APA102 output pins?

my next adafruit order will surely feature a few neopixel and apa102 strips.....

MichaelMeissner
04-03-2016, 01:30 PM
I just recommended the prop-shield-LC to a customer for running neopixels at 5V, with a Teensy 3.2.

While this technically will work fine (if those pinouts work for APA102s they must be fine for neopixels) has anyone tried sticking a neopixel strip on one of the APA102 output pins?

my next adafruit order will surely feature a few neopixel and apa102 strips.....

Well in theory if the conversions were too slow, it could affect the timing of the WS2812B's. I was able to run a 16 LED WS2812B/neopixel ring with no problems off of the APA102 leds (I used the data pin which is connected to pin 11). I suspect you really need to test a much larger strip to be sure of the timing.

I'm sure Pensive knows, but for those that don't, the WS2812B/neopixel only have one data pin, unlike the APA102/dotstar which has separate clock and data pins. This means that the communication must meet some rigid timing windows for the data to be recognized. Some level converters, such as those designed for i2c/spi conversions are too slow to be used WD2812B.

KurtE
04-03-2016, 01:54 PM
As I mentioned back in posting #373 (https://forum.pjrc.com/threads/33328-Prop-Shield-Beta-Test?p=100658&viewfull=1#post100658), I also have tried using Neopixels, using the Data pin.

Again I only tried it with 7 Neopixels. As Michael mentioned, not sure how timings work, My gut told me that since it looks like the Level converters are setup as I believe output only, that they should be able to go at high speed.

The other things I have not tried yet, is if you can at times still access the flash memory and at other times access the Neopixels. For example if you were doing output to Neopixels and wanted to do a read from the flash memory, you would need to disable the Neopixels (digitalWrite(7, LOW) ) Startup SPI and hopefully be able to access your data, then stop SPI, and enable Neopixels... Again not sure if this would work at all and if so, what if anything would need to be changed in any of the libraries...

JBeale
04-03-2016, 02:30 PM
Please try this:
https://github.com/Ben-Rheinland/NXPMotionSense/blob/master/OrientationVisualiser/OrientationVisualiser.pde

Thank you! Yes, I can confirm that version of the Processing Visualizer works perfectly for me in any orientation. I hope Paul can update his version (https://github.com/PaulStoffregen/NXPMotionSense/blob/master/OrientationVisualiser/OrientationVisualiser.pde) accordingly.

Frank B
04-03-2016, 08:48 PM
Thank you! Yes, I can confirm that version of the Processing Visualizer works perfectly for me in any orientation. I hope Paul can update his version (https://github.com/PaulStoffregen/NXPMotionSense/blob/master/OrientationVisualiser/OrientationVisualiser.pde) accordingly.

I can confirm it, too.

PaulStoffregen
04-03-2016, 09:32 PM
Here's yet another version of the calibration tool.


Windows:
http://www.pjrc.com/teensy/beta/imuread/MotionCal.exe

Linux (64 bit):
http://www.pjrc.com/teensy/beta/imuread/MotionCal.linux64

Macintosh:
http://www.pjrc.com/teensy/beta/imuread/MotionCal.dmg


This version adds many GUI improvements, especially on Windows.

Functionally, it should be the same as the prior build (msg #442).

defragster
04-03-2016, 09:45 PM
... output to Neopixels and wanted to do a read from the flash memory, you would need to disable the Neopixels (digitalWrite(7, LOW) ) Startup SPI and hopefully be able to access your data, then stop SPI, and enable Neopixels...

Paul made note of pin 7 toggle and 'active' for APA102's - in the case of APA102's he suggested SPI data would show on the APA's if the pin7 isn't dropped. I wrapped my FastLED function to toggle ON/off that - alternatively you could wrap the SPI calls with the inverse to keep Neopixels from getting confused.

Wozzy
04-03-2016, 10:50 PM
Hey Paul...

The new Motion Sensor Calibration Tool (Windows) looks good and works well.
I got my best cal yet: 0.0% gaps, 0.9% Variance, 0.9% Wobble, 0.9% Fit Error
Now I'm going to take my new calibration out for a spin :D

defragster
04-03-2016, 10:57 PM
Here's yet another version of the calibration tool.
... Windows:
This version adds many GUI improvements, especially on Windows.


Before it was getting data I saw this displayed "?" - hightlighted.
6905

The App might say somewhere what sketch to run this against - like the web page does. At some point should the app show what version of TeensyDuino it was built to run against?

This sketch does EXIT for me - though it seemed to be stalled until I clicked - NONE on the port?

I noticed that the Error % no longer 'only' increases at the end - in fact I got it to drop down to 1.5% after it went up to 2.2%! Then I wrote calibration and all seems well.

defragster
04-04-2016, 02:30 AM
Paul: Have you got a sketch I can use to test my PropS's flash? It is giving Frank Fits all of a sudden after it worked so well on TeensyTransfer. It runs RawHardwareTest and EraseEverything in SerialFlash, but trying to use CopyFromSerial says it wrote two files but ListFiles won't show them. { I can send it to you at any time if you wanted to explore it }. I've swapped Teensy's already - and DotStar/Talkie audio/IMU still generally function.

I'm thinking something in a sketch to create files and write data to files and then open them and find the data. I didn't see that in the examples - maybe there is one on the Forum? I could try to create a sketch - but would be better to have one known to work looking to confirm hardware function.

<edit> Just found this from sumotoy to work - FIRST TIME ONLY after Format ??? - https://forum.pjrc.com/threads/33594-SerialFlash-filesystem-question?p=99902&viewfull=1#post99902

<edit 2>: Found my Prop Shield flash to be still working - just trying to use GitHub tree in FLUX it seems - and the sumotoy code did catch an issue that should be resolved.

manitou
04-04-2016, 12:10 PM
I just revised the sketch (https://github.com/kriswiner/Teensy_Prop_Shield) to improve the fusion rate. I moved the accel and gyro temp fetch into the 2 Hz loop. Now the fusion runs at 780 Hz (with the Teensy at 72 MHz) when the accel is in the active state and 840 Hz when the accel enters low-power mode after 36 seconds of no activity (user configurable). I also corrected the Madgwick fusion call for the actual alignment of the prop shield sensors and changed the Euler angles for the heading reads from 0 to 360 like a compass. I also changed the order of the bias calibrations so the accel, then gyro and lastly mag are calibrated since the two former require no motion and the latter requires figure-eight motion. Everything should be working properly now.

I''m not sure I get all this fusion logic, but @onehorse you seem to run the filter update whether you have new sensor data or not. Paul's sketches only run the filter update if imu.available(), e.g., only if new sensor data is available.

question: is it beneficial/necessary to run filter even without new sensor data?

PaulStoffregen
04-04-2016, 01:13 PM
I'm just now trying to get caught up to the last few days of forum stuff, while I was working intensely on the calibration program. Let's see if I can get these answered quickly...



Things I'm still wondering about:
[LIST=1]
Why does the calibration get dramatically worse sometimes?


The two likely scenarios involve getting the sensor near a magnet or strong electrical current (which isn't balanced by an equal return current in another close-by wire), or sitting the board on or near iron or ferrous metal that shields it from the Earth's magnetic field.

This comment in the code, and some others in the function just above it, might help to explain some of the issues with how data is interpreted.

https://github.com/PaulStoffregen/MotionCal/blob/master/rawdata.c#L100



Why does the sphere of dots slowly roll when the Prop Shield is relatively still and certainly not rolling?


The fusion algorithms primarily use the gyroscope for rapid response, and the accelerometer and magnetometer for long-term stable correction. The problem is the magnetometer output is changing as the cal takes form, so a lot of very slow correction can be needed. I've tried a few times to jump-start that process, but the algorithms are complex and my main focus has been on improving the cal itself, and fixing a number of GUI issues.

If you've achieved a good cal, eventually it should come to a stop.



Why do the Accelerometer and Gyroscope fields report all zeros?


I haven't implemented calibration of those. It's planned, but may not happen for weeks or even months.



After "Send Calibration" is performed, is there anything needed in subsequent sketches to make use of the calibration?


The calibration is used automatically.



Is there any way to capture the calibration data or metadata other than attempting a screen shot as quickly as possible after sending the calibration?


You can run File > Examples > NXPMotionSense > PrintCalibration



Which parameter(s) should be optimized? I'm assuming first priority would be getting the "Fit Error" as low as possible. Is 1.8% a good number?


Yes. 4% is good and 2% is excellent.

In the latest versions, the Send Cal button enables when all 4 meet a reasonable criteria.



How long should the calibration process take? It seems long to me.


It really depends on how quickly you manage to move the sensor through enough angular positions. Maybe I should shoot a video showing a few tricks I've learned? (a decent quality video will draw a lot of time away from other stuff....)

One technique that's surprisingly effective is holding the USB cable a few inches away from the Teensy and rapidly twirling & waving the cable around. Doing that with a vigorous motion that feels somewhat risky or irresponsible for a few seconds with the cable pointing up and a few seconds pointing down usually get the gaps to under 10%.



When should re-calibration be done? Obviously if the environment changes or the readings get worse, but is it expected that it's done daily, annually, just once, etc?


That's a good question.

My hope is just once after final assembly can be adequate. Maybe OneHorse and others who've worked with these types of sensors can comment?

Freescale publishes code that preforms the calibration continuously. I don't like it. The main reason the Prop Shield was delayed so long was how confusing the sensor is (basically doesn't work and does very wrong things) when that code produces poor calibration. Even on a good day, it rarely achieves a fit as good as you can get and visually confirm with the calibration tool.



MotionCal feature request: Add a menu item to load the appropriate hex file to the Teensy.

If this is not a good idea, perhaps add some help text with the URL of the instructions for preparing the Teensy for Prop Shield calibration.


That is a good idea, but quite a lot of work. Perhaps version 2.0.



[Edit: and error messages about being unable to communicate with the Teensy/Prop Shield would be helpful, too.]

Yes. Probably the only other feature that's likely to happen soon (next few weeks) is improved status display. As you might guess from my absence over the last few days, GUI programming takes a lot of fiddly work. I believe now, or with better status display, we're pretty much a solid 1.0 release point.

PaulStoffregen
04-04-2016, 01:19 PM
- I was not able to get the calibration gui.exe to work on Windows 7 without opening Arduino monitor first to trigger data sending.

Any chance you could retest this? Or can anyone else who saw this problem give the latest version a try?

I'm pretty sure this commit (https://github.com/PaulStoffregen/MotionCal/commit/89f76f91fdaf30ed691a8e8a46e60d8de2fd4f9c) fixed it, but I wasn't able to recreate this problem on my Windows test machine.

PaulStoffregen
04-04-2016, 01:50 PM
... good performance with the orientation visualiser in Processing, *except* when the board is oriented vertically and rotated slowly around the long axis, the image onscreen rotates erratically. Looks like a numerical instability near that one orientation.

Yup, that's gimble lock (https://en.wikipedia.org/wiki/Gimbal_lock). It's a well known problem with using the 3-number roll, pitch, yaw angles to represent orientation.

Eventually I'll probably change the visualizer to optionally use quaternion. But roll, pitch & yaw are much easier to understand for an example program...

PaulStoffregen
04-04-2016, 01:56 PM
question: is it beneficial/necessary to run filter even without new sensor data?

No, definitely do not run the filter twice (or more) with the same data.

Edit: Why, you might ask...

These filters do basically 2 things. They compute the integral of the gyroscope signal, and they use the gradually (low pass) adjust the absolute value using the estimated gravity direction from the accelerometer and heading from the magnetometer.

Computing the change in angular position is much like ordinary linear motion. Imagine you're traveling in a car. Or a gadget you're building to estimate miles is, and all you can access is the speedometer. You could record the speed every second. Then to figure out how far you've driven, you'd multiply the miles/hour by 1/3600th of an hour, for how much distance was traversed during that second. They you add that distance to your accumulated total.

Obviously you don't want to accumulate it twice!

When gyroscope data is integrated correctly, you should be able to rapidly turn 90 degrees and see the angle change by 90 (or by 1.57 is displaying radians). Assuming the filter output was still before you started, if you suddenly stop after 90 degrees, in theory the filter should accumulate the gyroscope data for a rapid 90 degree response, which should closely match the gravity and magnetic field at the new orientation. Rarely do the filters work so perfectly, but it can be pretty close.

But if you count readings more than once, you end up doing all sorts of crazy things, like scaling the data so you end up with approximately correct angles. The huge problem with those sorts of kludges is they're highly dependent on program timing. If you add some code to play a sound, or update some Neopixel LEDs, or communicate with a wireless module, all of a sudden you're not collecting an processing the same number of duplicates.

If you look around the Arduino world, there's a lot of poorly designed code and libraries. I've recently been talking with the Arduino devs about ideas for an official Arduino API for these types of motion sensors. I can't share technical details at this time, but I can tell you I'm interested in a lot more than just Teensy and the Prop Shield. I really do want to work towards a future where we have good compatibility between different sensor libraries and filter/fusion libraries and sketch code, and were things are designed to give proper results even when combined with other code that changes the program's overall loop() timing.

Ben
04-04-2016, 02:29 PM
Yup, that's gimble lock (https://en.wikipedia.org/wiki/Gimbal_lock). It's a well known problem with using the 3-number roll, pitch, yaw angles to represent orientation.

Any idea why this doesn't occur with yaw inverted? I inverted yaw to match the real world movement to the visualizer and that "by accident" also seems to solve the gimbal lock problem.

Frank B
04-04-2016, 09:52 PM
MP3Player with Prop-Shield:

https://forum.pjrc.com/threads/27059-MP3-Player-Lib-with-example?p=101537&viewfull=1#post101537

macaba
04-04-2016, 10:12 PM
Any chance you could retest this? Or can anyone else who saw this problem give the latest version a try?

I'm pretty sure this commit (https://github.com/PaulStoffregen/MotionCal/commit/89f76f91fdaf30ed691a8e8a46e60d8de2fd4f9c) fixed it, but I wasn't able to recreate this problem on my Windows test machine.

All fixed here, thank you.

Wozzy
04-06-2016, 01:41 AM
I cobbled together some modifications to the visualizer that adds the ability to log data from the Prop Shield to a log file.
It's built off of the OrientationVisualizer Processing sketch, and adds a keyboard command "L" to toggle logging to a data file on the PC.
The logged data is appended to the file, so the Kst plotting tool can update the plots in realtime.

Here's a screen capture: 6936

Here's a video: https://youtu.be/5mccPaAEya8

Here's a link to my first attempt at a GitHub repository: https://github.com/Wozzy-T-3/Teensy-Prop-Shield-Visualizer

Keyboard Menu (When focus is Processing graphics output window)

press H to show/hide Help
press F to show/hide Fps
press U to show/hide orientation Update rate
press N to show/hide yaw, pitch and roll Numbers
press L to open to start/stop data Logging
press Z or X to adjust yaw to match view angle

onehorse
04-06-2016, 05:16 PM
No, definitely do not run the filter twice (or more) with the same data.

It depends on what you mean by "filter".

The Madgwick (and Mahony IIRC) filters are error minimization filters that use steepest descent methods to iterate toward a stable solution that minimizes the error construct. I highly recommend anyone who doubts this to read Madgwick's surprisingly accessible paper (http://www.x-io.co.uk/open-source-imu-and-ahrs-algorithms/) where the mathematics is explained with rigor and clarity. These filters perform best when they can iterate on a given set of data four or five times.

Where does this assertion come from? Two places.

Anyone who has calculated (https://en.wikipedia.org/wiki/Methods_of_computing_square_roots) a square root or used steepest descent in College calculus understands that most solutions require a handful of iterations to get to a good approximation, in this case orientation estimation.

Practically, I have noticed (https://github.com/kriswiner/MPU-6050/wiki/Affordable-9-DoF-Sensor-Fusion) that accurate orientation solutions are possible with minimum latency when the fusion rate is 4 or 5 times the sensor data sample rate. Possible because without adequate calibration the orientation estimate will be poor and drifty no matter what the sensor fusion algorithm. Accurate means when you perform the 90-degree angle turning test with the sensor flat on a table after proper calibration, you get 90 degree changes in yaw with a standard deviation of 4 degrees (possible with Madgwick and well-calibrated, accurate MEMS sensors). It is possible to do even better with additional filter elements (see the EM7180 solution (https://www.tindie.com/products/onehorse/ultimate-sensor-fusion-solution/)).

So practically what this means is that for 200 - 400 Hz gyro (and accel) sample rates, the Madgwick sensor fusion update rate needs to be ~1 kHz, which can easily be achieved with a Teensy 3.X. If you try to run the same algorithm and data rates with my beloved Arduino 3.3V 8 MHz Pro Mini the latency will be so bad that you will never get to a stable orientation estimate.

My general rule for human-based motion detection is 200 Hz gyro/accel data rate, 40 Hz bandwidths, 1 kHz fusion rate. This can produce 4 degree yaw (or heading) accuracy. If you run with 200 Hz data rates and 200 Hz Madgwick fusion rates it will not. Or at least I remain to be convinced this is possible.

Now interestingly, many Kalman filters (Madgwick is not a Kalman filter) only have to be run at ~10% of the data sample rate since they are designed to correct for mild "long-term" drift. The best sensor fusion algorithms have a fast quaternion update and a slow Kalman filter for drift correction as well as magnetic anomaly detection and continuous mag calibration, etc.

For the prop shield, I would recommend turning off the automatic calibration since this will produce wildly varying results in even a short time. I would do the manual calibration each time before use. It is possible to do the manual calibration once and store the results in the sketch for subsequent use. This works as long as the environment (magnetic fields) don't change too much and, most importantly, the temperature doesn't change too much. If you calibrate indoors at 64 degrees and take the device outside where it is 85 degrees, you shouldn't expect your calibration will remain the same. Bottom line, design your device so that the user can calibrate as needed.

I encourage everyone to use their prop shield (and other sensor fusion devices) to take the 90-degree corner turning test. After calibration hold the device against a desk or table edge for repeatability and stability, note the heading (accurate pitch and roll are easy and don't require 9 DoF), turn the device 90 degrees, note the heading, repeat until you have made one or two full revolutions. Calculate the mean angle change (typically 90.5 or 89.5, for example) and, more interestingly, the standard deviation (use excel if necessary). The prop shield should be able to get to ~5 degree standard deviation. This is a simple but demanding test of the underlying sensor quality, since with excellent sensors the Madgwick filter by itself can achieve 2 degree heading accuracy in this test.

And that's about it...

turtle9er
04-09-2016, 04:12 AM
Hi,

Just started playing with the prop shield and have an idea in mind for its use, but it would require saving data to an SD card. Would it be possible to use an SD card since the SPI pins are already being used by the on board memory.

defragster
04-09-2016, 04:37 AM
SPI is a shared resource as long as you find and can use a unique CS pin ideally it will work at the same time with the other three SPI pins in use. Haven't heard anyone else trying it and saying it failed or why it shouldn't work.

MichaelMeissner
04-09-2016, 04:53 AM
Hi,

Just started playing with the prop shield and have an idea in mind for its use, but it would require saving data to an SD card. Would it be possible to use an SD card since the SPI pins are already being used by the on board memory.

Note, if you don't need the storage to be removable and only need 8 megabytes, the prop shield includes flash memory that you can read/write to it like a SD card. The Teensy Transfer tool (https://forum.pjrc.com/threads/33859-TeensyTransfer) allows you to copy files to/from the flash memory card.


SPI is a shared resource as long as you find and can use a unique CS pin ideally it will work at the same time with the other three SPI pins in use. Haven't heard anyone else trying it and saying it failed or why it shouldn't work.
Paul did post this about SPI and pin usage: https://forum.pjrc.com/threads/33014-SPI-Chip-Selects-(Teensy-3-1-vs-3-2)?p=96072#post96072

Now, Paul did not indicate the SD driver used the special SPI signals like some of the optimized SPI devices, so in theory you could use any free pin. But even if it does use the special SPI signals, you could still use pins 20/21 (or 22/23) as additional SPI selects. Note, this is all theoretical to me, as I haven't actually programmed any SPI device.

mjs513
04-09-2016, 09:35 PM
Hi Paul

Just a couple quick comments and questions. Especially since I just picked up a prop-shield. You stated that:

I haven't implemented calibration of those. It's planned, but may not happen for weeks or even months.

Question: have you looked at implementing the calibration GUI like that used for FreeIMU that Fabio put together. I have run this on serveral different sensors and found it very reliable. I think you are already familiar with the GUI.

For Gyro calibration (gyro zeroing) I have been using a run time calibration at startup. I pulled the method from the code used for ardupilot and allowed the user to "re-zero" from a processing sketch. If you are interested I can post the process and code somewhere.

Update 4/10: Just finished calibrating the Prop-shield and running the Madgwick Filter. All I say is really nice, seems very stable did not notice any major drifting in yaw but I only ran it for a few minutes. Now the fun can begin.

v/R
Mike

mjs513
04-12-2016, 11:40 AM
Hi

I am digging deeper into the Prop-shield code base and I do have a few questions.

1. We do a magnetic calibration but I am not sure where that calibration is actually applied.
2. In looking at the altimeter I do not see any way to get pressure returned.
3. In an Arduino library I have for the MPL3115 I did notice that there is a calibration procedure that was implemented do we need to do that here.
4. Again for the altitude it looks like we have to do our own conversion in any sketch we develop - is this correct.
5. I see that there is a Kalman filter implemented in SensorFusion.cpp file but I don't see an example in the examples file. Not a problem just wanted to know it is ready to go. Also do you have Freescale reference document # for the Kalman filter?
6. It looks like the sensors are set for +/-2g and +/-2000 for gyro - is this correct? To change these values we would have to modify the cpp file.

Update 4-12
How do you hook the prop-shield up to an Arduino? Just tried and using a I2C scanner it could not find anything - using a Arduino101.

Thanks
Mike

PS. Great summary by OneHorse, just got through it.

manitou
04-13-2016, 11:45 AM
How do you hook the prop-shield up to an Arduino? Just tried and using a I2C scanner it could not find anything - using a Arduino101.


I've hooked shield to non-teensy devices (e.g., arduino 3.3v pro mini, mbed K64F) with no problem. For I2C just need 3.3v,GND,SCL,SDA. Check the schematic or the pin table on the store page
https://www.pjrc.com/store/prop_shield.html

mjs513
04-13-2016, 04:28 PM
Hi Manitou

Thanks for getting back to me. That's what I thought I had done. I grabbed the other prop shield I had and hooked it and it worked fine. May have had a bad connection but I had to be sure. It works fine. Now the fun begins....

Thanks again
Mike

MichaelMeissner
04-14-2016, 01:06 PM
I noticed that Adafruit is now carrying both flavors of the prop shield, and on this week's Ask An Engineer (https://www.youtube.com/watch?v=scRuxHiZCzw) Limor announced Adafruit carrying it (it is roughly 44 minutes and 50 seconds into the video). It looks like since yesterday, they sold a few of the LC shield and about 15-20 of the motion sensor shield.

I would suspect that tomorrow (Friday), Sparkfun will probably also carry it.

mjs513
04-14-2016, 06:21 PM
Just got through the video. Think the Prop-Shield is going to go very popular. Its a great little board with a lot of features. Just slogged my way though the code and got a working on the Mega and the curie. You definitely need to change the I2C bus to 400Hz, it make a big difference if you want to run the sensors at 100Hz. Still working it to get it working nicely.

mjs513
04-15-2016, 12:31 PM
Doing some testing with the Prop Shield and I am noticing some very strange Gyro readings which especially noticeable on the x axis of the board. I have attached separate plots for reference that I took from the serialploter in the Arduino IDE.

697169726973

In all cases I am seeing periodic spikes in the raw gyro readings. In the case of gx data is varying from slightly negative to 15000. Which is strange since the board is just resting on my desk. For gy the range is makes more sense but it appears to overlaid on top of some sort of sine wave pattern. Gz appears to be just very spike. The data uses the default settings. Any suggestions or recommendations would be helpful, including what I am doing wrong.

Thanks
Mike

PhilB
04-15-2016, 10:31 PM
Does anyone know the maximum current @ 5V the PropShield can pass through to the 5DCG APA102 port?
I've been using an external 5V power supply, with the ground tied to the Propshield/Teensy3.1, to power the LED strip, but I'm guessing that the idea is to connect directly to the 5DCG APA102 port.
Thanx

I looked for an answer to this question but didn't see it. Actually, the precise question is how much current can be passed from the T3.2's VUSB & GND pads through to the APA102 +5V and GND pads on the propshield assuming soldered header pins? It's still a TODO in the product page. Anyone know the answer?

To be specific, I will be using a portable USB charger and have a USB breakout that I'd solder to the T3.2's USB pads and then just hook up the APA102 string to the connector at the other end of the propshield. To be safe, I will probably bypass it for now.

PaulStoffregen
04-16-2016, 02:02 PM
I looked for an answer to this question but didn't see it. Actually, the precise question is how much current can be passed from the T3.2's VUSB & GND pads through to the APA102 +5V and GND pads on the propshield assuming soldered header pins? It's still a TODO in the product page. Anyone know the answer?


I designed the PCB with 4 layers specifically to have a dedicated GND and 5V plane able to conduct a lot of current for the LEDs and audio amp, and hopefully distribute it and keep the return path very close inside the PCB so minimal magnetic field is created (interfering with the magnetometer).

As a quick test, I just passed 2 amps through a board here, from one end to the other. GND to GND measures 10 mV with 2 amps flowing. 5V to 5V measures 12 mV with 2 amps.

Wozzy
04-16-2016, 02:17 PM
As a quick test, I just passed 2 amps through a board here, from one end to the other. GND to GND measures 10 mV with 2 amps flowing. 5V to 5V measures 12 mV with 2 amps.

Thanks for checking that Paul.
I didn't want to risk my Prop Shield trying to find the limit.

PhilB
04-16-2016, 07:13 PM
Yes, thanks for checking. My guess is it could handle more but 2A is a reasonable limit for my needs.

solardude
04-17-2017, 10:43 PM
It depends on what you mean by "filter".

The Madgwick (and Mahony IIRC) filters are error minimization filters that use steepest descent methods to iterate toward a stable solution that minimizes the error construct. I highly recommend anyone who doubts this to read Madgwick's surprisingly accessible paper (http://www.x-io.co.uk/open-source-imu-and-ahrs-algorithms/) where the mathematics is explained with rigor and clarity. These filters perform best when they can iterate on a given set of data four or five times.

Where does this assertion come from? Two places.

Anyone who has calculated (https://en.wikipedia.org/wiki/Methods_of_computing_square_roots) a square root or used steepest descent in College calculus understands that most solutions require a handful of iterations to get to a good approximation, in this case orientation estimation.

Practically, I have noticed (https://github.com/kriswiner/MPU-6050/wiki/Affordable-9-DoF-Sensor-Fusion) that accurate orientation solutions are possible with minimum latency when the fusion rate is 4 or 5 times the sensor data sample rate. Possible because without adequate calibration the orientation estimate will be poor and drifty no matter what the sensor fusion algorithm. Accurate means when you perform the 90-degree angle turning test with the sensor flat on a table after proper calibration, you get 90 degree changes in yaw with a standard deviation of 4 degrees (possible with Madgwick and well-calibrated, accurate MEMS sensors). It is possible to do even better with additional filter elements (see the EM7180 solution (https://www.tindie.com/products/onehorse/ultimate-sensor-fusion-solution/)).

So practically what this means is that for 200 - 400 Hz gyro (and accel) sample rates, the Madgwick sensor fusion update rate needs to be ~1 kHz, which can easily be achieved with a Teensy 3.X. If you try to run the same algorithm and data rates with my beloved Arduino 3.3V 8 MHz Pro Mini the latency will be so bad that you will never get to a stable orientation estimate.

My general rule for human-based motion detection is 200 Hz gyro/accel data rate, 40 Hz bandwidths, 1 kHz fusion rate. This can produce 4 degree yaw (or heading) accuracy. If you run with 200 Hz data rates and 200 Hz Madgwick fusion rates it will not. Or at least I remain to be convinced this is possible.

Now interestingly, many Kalman filters (Madgwick is not a Kalman filter) only have to be run at ~10% of the data sample rate since they are designed to correct for mild "long-term" drift. The best sensor fusion algorithms have a fast quaternion update and a slow Kalman filter for drift correction as well as magnetic anomaly detection and continuous mag calibration, etc.

For the prop shield, I would recommend turning off the automatic calibration since this will produce wildly varying results in even a short time. I would do the manual calibration each time before use. It is possible to do the manual calibration once and store the results in the sketch for subsequent use. This works as long as the environment (magnetic fields) don't change too much and, most importantly, the temperature doesn't change too much. If you calibrate indoors at 64 degrees and take the device outside where it is 85 degrees, you shouldn't expect your calibration will remain the same. Bottom line, design your device so that the user can calibrate as needed.

I encourage everyone to use their prop shield (and other sensor fusion devices) to take the 90-degree corner turning test. After calibration hold the device against a desk or table edge for repeatability and stability, note the heading (accurate pitch and roll are easy and don't require 9 DoF), turn the device 90 degrees, note the heading, repeat until you have made one or two full revolutions. Calculate the mean angle change (typically 90.5 or 89.5, for example) and, more interestingly, the standard deviation (use excel if necessary). The prop shield should be able to get to ~5 degree standard deviation. This is a simple but demanding test of the underlying sensor quality, since with excellent sensors the Madgwick filter by itself can achieve 2 degree heading accuracy in this test.

And that's about it...

Onehorse - I wanted to ask you a question since you have a good understanding of the NXP sensors on the Prop shield & the Madgwick filter.

I'm testing this sensor for a solar panel tracking application where the solar panel is tilted towards the sun's heading so this is a stationary application with little to no movement.

What settings do you think would provide the heading results using the Madgwick filter?

Any advice would be apperciated about this.

Thanks!

mjs513
07-24-2017, 12:43 AM
@PaulStoffregen In an earlier post you mentioned a more standardized approach to sensor libraries:

If you look around the Arduino world, there's a lot of poorly designed code and libraries. I've recently been talking with the Arduino devs about ideas for an official Arduino API for these types of motion sensors. I can't share technical details at this time, but I can tell you I'm interested in a lot more than just Teensy and the Prop Shield. I really do want to work towards a future where we have good compatibility between different sensor libraries and filter/fusion libraries and sketch code, and were things are designed to give proper results even when combined with other code that changes the program's overall loop() timing.

Was wondering if there was any progress on this front. If not can you share what your views are. Its been over a year since that post and was wondering maybe its time to take the bull by the horns.

Thanks
Mike