Prop Shield Beta Test

Status
Not open for further replies.
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..
 
Last edited:
My TestGyroscope program has evolved into something useful and is now called SensorStatistics.ino

data from my shield
Code:
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
 
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
 
Last edited:
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..
 
Last edited:
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:
Code:
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:
Code:
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
 
Axis Swapped?

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 sketch in the NXPMotionSense library
with the CurieIMU Visualizer 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.
FXOS8700 Axis Orientation.JPG
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.
 
Last edited:
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.
 
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....
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);
  
  /*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
}
 
Last edited:
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,
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.
 
Here are my Calibration results and results from Ben's TestGyroscope program at several orientations:
Code:
[COLOR="#FF0000"]Magnetic Calibration[/COLOR]

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


[B]TestGyroscope Output[/B]
[COLOR="#FF0000"]Startup...................[/COLOR]
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

[COLOR="#FF0000"]Pitched 45...................[/COLOR]
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

[COLOR="#FF0000"]Yawed 90...................[/COLOR]
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

[COLOR="#FF0000"]Yawed 90 & Pitched 45...................[/COLOR]
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

[COLOR="#FF0000"]Yawed 90 & Rolled 45...................[/COLOR]
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

[COLOR="#FF0000"]Return back to startup orientation...................[/COLOR]
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
 
Last edited:
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, which is well matched to the 1W amp:

ASE03008MR-LW150-R_sml.jpg

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.
 
saving stats for plotting

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 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.
Code:
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();
}

Kst%2B-%2BCG9axis1.csv%2B3202016%2B44429%2BPM.jpg
 
Last edited:

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...
 
Last edited:
TeensyTransfer:

Blackketter (thank you!) was so kind and has compiled a MAC version.
I do not know if it works .. (hint, hint :)
 
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
 
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.
 
Last edited:
Last edited:
After much frustration with wrong results in Arduino's orientation visualizer example, I finally arrived at this conclusion:

 
Status
Not open for further replies.
Back
Top