Prop Shield Beta Test

Status
Not open for further replies.
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:
  1. Why does the calibration get dramatically worse sometimes?


  1. 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.
 
- 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 fixed it, but I wasn't able to recreate this problem on my Windows test machine.
 
... 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. 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...
 
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.
 
Last edited:
Yup, that's gimble 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.
 
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: PC Screen Capture.jpg

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

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

GX.PNGGY.PNGgz.PNG

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
 
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.
 
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.
 
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.
 
Yes, thanks for checking. My guess is it could handle more but 2A is a reasonable limit for my needs.
 
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 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 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 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).

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!
 
@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
 
Status
Not open for further replies.
Back
Top