Prop Shield Beta Test

Status
Not open for further replies.
PaulStoffregen said:
Also, please let me know if are you able to resize the window? If you can, does the graphic part grow as you change the window size?
Click to expand...

On Windows I cannot resize the window. Maximize and titlebar icon is grey, and no resize borders. Image below with a yellow highlight where I see the active jitter as it sits after waving it around.
nxp_cal1.PNG
I powered down and pulled off the ESP board and the speaker - then wiggled it around on the USB cable and got the second rounder image.
nxp_cal2.PNG
<edit>: interesting VOID area persists after sitting and moving - it is visible in the _Cal2 image.
 
Last edited:
Thanks, for now, I went with the T3.2 above. I cut another Arduino expansion header to size to fit the center pins (actually a few attempts), with file and like to get them to fit properly... I then used some extra long breakaway headers, that I soldered to T3.2, so the bottom part connects into the shield headers, and they extend up above the Teensy such that I can hook up jumpers and/or Logic Analyzer...

Next up hook up Dotstar. Currently trying to decide what connectors I want to use...
 
First Test

I soldered up headers to my PropShield today.
I downloaded and installed Arduino 1.6.8 and Teensyduino 1.28B1 without issues.
I have a Teensy 3.1 plugged into the PropShield.
My PC is a 3.4 Mhz 6-core Haswell-E running Windows 10 with an AMD Radeon R9-200 graphics board

I compiled the MadgwickIMU program at 120 Mhz and it seemed to compile and run fine.
I compiled the CalibrateMagnetometer program at 120 Mhz and it seemed to compile and run fine.
When running the Windows IMU.exe program, Windows Sysinternals Process Explorer shows less than 5% CPU usage and less than 3% GPU usage.
The graphics window seem smooth and responsive.
I ran FRAPS on the GUI window and it reported a consistent 21 frames/second.
On my system I am unable to resize or maximize the window.I am unable to catch the corner to drag to resize, and the maximize Icon in the upper left corner is greyed out.

Here's screencap with FRAPS running:
FRAPS IMU.jpg
 
Last edited:
I finally soldered my 3.2 to the shield and switched to that. I updated my sources, and moved on to Arduino 1.6.8 to run the CalibrateMagnetnometer example. The first few times I ran it, I kept getting a configuration error, but now it runs fine.

On my Fedora 22 system, I can resize the window, and the graphic inside DOES resize. I am using the mate window manager.
 
mag calibration

I was able to mostly fill in the calibration sphere by much trial and error, slowly pointing the board in different directions. I clicked on the item to load the calibration but I don't know if it did anything.
Mag-Cal-window.jpg
To compile the Madgwick example I had to separately download the library from https://github.com/arduino-libraries/MadgwickAHRS

The Madgwick sketch driving the orientation display example in Processing sort of works, but there are some regions where the graphical motion wobbles in a way the board doesn't, and some angles where the image abruptly flips 180 degrees when the real board turns smoothly. Maybe the calibration didn't get loaded, or used, or wasn't accurate enough? Or it's some kind of "gimbal lock" coordinate difficulty (if that's even meaningful with this type of sensor?)
 
Last edited:
I've added the advanced Freescale sensor fusion algorithm to the NXPMotionSense library.

There's a new "Orientation" example showing how to use it. I tried to keep the API very similar to the existing Madgwick library. The same Processing sketch can be used to view the results.
 
Last edited:
It might be useful in NXPMotionSense.h and in the library documentation to note that bytes 76-127 of the EEPROM space are used by the calibration part of the library.

It might be useful to switch the reading and writing of the EEPROM information to use eeprom_read_block and eeprom_write_block, rather than iterating byte by byte.
 
@Paul, it might be useful to include a link to the madgwickAHRS lib, or add in the lib within the nxpmotionsense lib. The madgwickAHRS licence is:
License

Copyright (c) Arduino LLC. All right reserved.

This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version.
Click to expand...
 
the updated gui is resizable on Win7Pro SP1. Looks good. A feedback whether the cal data was written to EEPROM successfully would be nice. I know I'ts not in line with the linux philosophy of "only talk if something went wrong", but as a windows user I expected some popup with a message at that point. Does the NXPMotionSense lib support reading the cal data back from the EEPROM?

Maybe we should collect some cal data samples and look for an average? PJRC could program that average to the prop shield with the bed-of-nails test jig I'm sure Paul has to enhance initial accuracy and customer experience?

Edit: I still see the sphere rotate while the PropS is stationary, is this normal? The "wiggle" where red dots are updated rotates with the sphere and thus is stationary relative to all dots.
 
Last edited:
MichaelMeissner said:
It might be useful in NXPMotionSense.h and in the library documentation to note that bytes 76-127 of the EEPROM space are used by the calibration part of the library.
Click to expand...

Yes, agreed. The details like location are likely to change somewhat before the final release.

If I forget, please remind me of this after I've made a page to document the library.

It might be useful to switch the reading and writing of the EEPROM information to use eeprom_read_block and eeprom_write_block, rather than iterating byte by byte.
Click to expand...

Are those functions available through Arduino's EEPROM library API? Even though Teensyduino emulates the avr-libc eeprom functions, I'd prefer to use only Arduino's API. I like to imagine a world where things aren't hard coded to AVR...


Ben said:
A feedback whether the cal data was written to EEPROM successfully would be nice.
Click to expand...

Yes, this is on my list. :)

Does the NXPMotionSense lib support reading the cal data back from the EEPROM?
Click to expand...

No, not yet, but it probably should.

PJRC could program that average to the prop shield with the bed-of-nails test jig
Click to expand...

I've seriously considered doing something like this. The W25Q64 flash chip does have a 256 byte area which can be used for serial numbers or other stuff. I believe those 256 bytes survive the normal chip erase, but I haven't tested.

But calibration here is not so simple. We can't possibly collect enough motion data during the brief time it's pressed onto the pogo pins, where it stays in pretty much the same orientation the entire time. To calibrate the sensor here, we'd have to add another test where a person (or specially built machine) does the cal, similar to how you're doing it. Doing this would significantly increase the cost. I believe we're on target for the "wit" version to retail at approx $20.

I also *really* want people to run the cal, so they can see the data. Especially when something interferes with the magnetometer, figuring out why things don't work is almost impossible without this visualization (trust me... I've spent a lot of frustrating time, only to later learn there's a lot of strong but localized magnetic fields in various places around my workbench). This is the main reason I've delayed the prop shield for months.... to figure out this cal with opengl visualization, to make the magnetometer function observable and apparent.

I still see the sphere rotate while the PropS is stationary, is this normal?
Click to expand...

No, that's a bug. Or if not a bug, certainly not working as well as I'd like. I have a couple ideas/theories I'm going to try. As you can see in the source code, these algorithms are quite complicated. Not entire sure if I'll be able to fully fix this one.

The "wiggle" where red dots are updated rotates with the sphere and thus is stationary relative to all dots.
Click to expand...

That wiggling is the new data being added, but usually replaced immediately by the next new data. It actually happens faster than the GUI refresh rate.

Much of the work left to do involves algorithms to show metrics of the quality of your sphere, and for new data to tend to replace previously collected data that's not as good. This turns out to be a pretty difficult problem. Earlier I put a couple solid days into the code we have now... but it's far from where I want it to be. Much work remains to be done....
 
Last edited:
New version is nicely Windows resizable. Good uniform sphere. Did Send Calibration.

opps - reached to right and sphere got odd ... got near (couple inches) a magnetic closure on a phone wallet - repeated to be sure and the sphere went super nova.

Can LED do a sign of life blink? I tapped the unit on my ring and the GUI display stopped - don't know If I took it offline - restarted fine.

A couple times I start it up and it shows no dot data - turn of monitor none and back, nothing. Then none, TYQT monitor see's streaming data - monitor off and back to GUI port and there it is.
 
Calibration test:

My system is a Core i5 3570K @ max 3.4 GHz 8GB Ram, AMD Radeon 7700 Series GPU
Running gui.exe after a while 5..7% CPU Usage, GPU between 0.6.. 2.2%

I got a nice sphere, despite of my compact build with an additional "connector"board between the prop-shield chips and the Teensy,

Closing gui.exe gives an error:

"Gui.exe funktioniert nicht mehr.
Programm schliessen.
Program Debuggen"

(gui exe stopped working)
 
PaulStoffregen said:
No, that's a bug. Or if not a bug, certainly not working as well as I'd like. I have a couple ideas/theories I'm going to try. As you can see in the source code, these algorithms are quite complicated. Not entire sure if I'll be able to fully fix this one.
Click to expand...
It might be a problem with my hardware, sometimes when I move the Shield, like when filling the cal gui with data points, the orientation begins to drift on all axes in a weird but repeatable pattern. I'm using the "Orientation" example modified to 2000ms update intervals right now to record this behaviour on the arduino serial plotter. I'll edit a screenshot here in a couple minutes.

Edit:
Prop Shield Drift.png
 
Last edited:
Of course, but I don't actually know how :rolleyes: I'm more of a hardware guy... so any help/hint appreciated!
 
Use the MagdwickIMU example that comes with the library. Maybe grab the latest copy of the library, which has a little more documentation in the comments.
 
I've tried the GUI and the orientation sketches and both work as expected (although it'd be nice if the gui told you that the "Send calibration" was completed correctly).
This is really nice piece of hardware and together with this software it's really nice!
 
See here for a different(?) implementation of the Madgwick filter.

Make sure you pass the filter the data in the correct (for NED convention) order:

// Sensors x (y)-axis of the accelerometer/magnetometer is aligned with the x (y)-axis of the gyro on the prop shield;
// All three sensors have the positive z-axis up.
// The long axis of the prop shield is in the x-axis direction, which we will designate as North
// Then x is North, -y is East, and -z is Down for a NED convention
// Invert accel data since gravity == positive when up
// Pass gyro rate as rad/s
MadgwickQuaternionUpdate(-ax, ay, az, gx*PI/180.0f, -gy*PI/180.0f, -gz*PI/180.0f, mx, -my, -mz);
Click to expand...

Also, if the mag is not calibrated for offset you will just get garbage.
 
Looks to me like Ben's system is not accurately calibrated, or not calibrated at all. It would be easier to debug if (1) there was some confirmation that the calibration data was written to memory and (2) some quality metrics on the calibration data (self-consistency) and maybe (3) some real-time monitoring for self-consistency, eg. does the currently measured field vector have the same magnitude as the original calibration did, and does the magnitude change with time? If it's too big that implies a local magnetic source. If it's too small, it means presence of an opposing field, or that you've moved into a magnetically shielded chamber, or well away from the planet's surface...
 
I've been running it here for 2 hours. I changed the code to print once every 10 seconds. Here's what I'm seeing with the Orientation example.

sc.png

Edit: this was with the Teensy and Prop Shield hanging on the end of a short USB cable, dangling off a USB hub that's mounted to the side of my workbench.
 
Last edited:
Status
Not open for further replies.
Back
Top