X/Y/Z translation

[scottm]

I've got the sensor fusion toolbox running on both Windows and Android and connecting to a FRDM-KL25Z (I also have a FRDM-K22F but it doesn't seem to have the appropriate firmware available) with a FRDM-FXS-MULT2-B.  The orientation display works quite well.  What I really want to know, though, is whether it's possible to display translation.  I'd like to see how accurately it can show the board moving side to side or up and down while it's rotating.

I see that there's linear acceleration available in the display.  Am I just going to have to integrate that to get translational movement?

Thanks,

Scott

[michaelestanley]

Scott,

There is a build available for the K22F, but only under KDS.  You can also flash the board from the Sensor Fusion Toolbox if you just want to play with the standard build.

Double integration of acceleration sounds great until you realize that any noise and/or offset in the sensor also get doubly integrated, and quickly explodes.  Of the two, post-board-mount offset is probably the worst culprit.   The algorithms in the toolbox correct for gyro offset and drift, but not accelerometer.  We haven't included position charts in the published version of the fusion toolbox because we know how disappointing the results will be.

In the NEXT version under development, we plan to include routines to allow you to do a one-time calibration of the accelerometer that will dramatically improve accelerometer offsets/rotations before the signals are fed into the Kalman filter.  At that point, you've got a solution that should work well for positioning/navigation aid applications.   I believe Mark (the primary developer, and my partner in crime on the fusion library) plans to release the new version in late Q1.  If your product timeline needs something sooner, drop me an email at mike.stanley@nxp.com and we can discuss options.

Regards,

Mike

[scottm]

Thanks for the fast and informative response!  Before I trouble you any further I'll tell you what my application is and you can tell me if it's nuts to even try.  The board is in a hula hoop, so it mostly moves in what I guess would be a hypocycloid path.  Centrifugal forces can be around 6 Gs.  Not sure about linear acceleration, but there are a large variety of common moves, some fairly linear and some mostly rotational.  There are plenty of useful things that orientation sensing can let me do, but calculating linear movement, even if it has some drift, would be really handy.  The hoop's usually not going far from the hooper but there can be a lot going on

Also, I believe the library will work with other brands of sensors, right?  We use a Bosch BMX055 in all of the existing devices.  I thought Freescale had a 9-axis sensor in the works but I can't find it now .  Is there a Freescale alternative to the BMX055, and will it work with the sensor fusion library?

Thanks,

Scott

[michaelestanley]

Scott,

I'm not sure what the motion of a stationary point on a hula hoop looks like over time.  I think you would need to chart out the acceleration values over a number of rotations of the hoop to make sure that (from the sensor's perspective), you don't have some near constant accelerations.  Those could play havoc with the algorithms.

Yes, you are welcome to use the algorithms with any vendor's sensors.  You will need to replace the drivers, and NXP's support is (of course) limited to use of NXP sensors.  NXP does not have a 9-axis sensor available. You probably don't need a mag for this application.   I would recommend the MMA8652 accel and the FXAS21002 gyro.

I can't comment one way or the other on the device you mention.  I do know that use of a separate gyro can sometimes yield better performance than an integrated device, depending upon what design tradeoffs were or were not made with that integrated device.  Gyros like to have evacuated cavities for the MEMS, as gas can dampen motion of the MEMS masses, decreasing the gyro's Q factor (think power efficiency).  Conversely, consumer accels are typically not evacuated.  Gas damping for the accel is desirable to achieve an overdamped response curve.  It's something to consider as you evaluate options.

Regards,

Mike

[scottm]

I've already done some captures via Bluetooth (without the fusion algorithms) and I'll probably need to revisit that.  Can you tell me if the linear acceleration readings I'm seeing in the sensor fusion graphs include a centrifugal component, or is that removed by the algorithms using the gyro data? Seems like it would need to know the radius of the hoop for that, but I don't have a strong grasp of the underlying math of the fusion algorithms.

A basic off-body move called an isolation has the hoop vertical and the center fixed while the hoop rotates.  A single gyro axis does a beautiful job of capturing this.  An iso pop is a similar move but at some point in the rotation the center of the hoop translates one hoop diameter in a straight line in the plane of the hoop and returns on the same line.  If the sensor fusion algorithms can cancel out the centrifugal part from the steady rotation then it seems like this sort of move would be easy to capture.  Many moves involve a constant rotation component and a quick excursion and return on some axis.  Slow drift of the hoop's calculated position shouldn't be a major concern and hoop dancers tend to move around anyway.  It's the hypocycloid motion that concerns me.

The motion should look something like this: Hypocycloid Enter 200, 130, and 130 for the radii and click start and you'll see what I'm talking about. It looks like the motion of the sensor should briefly stall at multiple points for each hoop rotation.  There are a number of academic papers on hula hoop motion, but I get the feeling that they're mostly things drunk mathematicians write as gags for their department holiday parties.

At the time of the initial design about two years ago the Bosch part was the only 9-axis sensor available. Freescale was expecting one out within a year.  I assume that one got cancelled?  My first prototypes used an FXOS8700 and Bosch BMG160.  Board space is limited (< 5/8" wide, < 1/2" for future versions) so I'm trying to keep the component count down.  Our own SMT line is just barely adequate for some of the tiny DFN or QFN parts and even with a CM doing most of these boards, inspection and rework are a pain. Also, board flex is hard to avoid in a hoop and hidden lead parts can be trouble.  The BMX055 is at the far end of the board from its attachment point to try to reduce that.

That's good to know about the compromises with MEMS gyro and accelerometer construction.  The existing sensors have been good enough for things like determining when the hoop is not in use and can go to sleep and to create motion-reactive patterns in the LEDs.  I think the magnetometer is worth keeping because it allows for things like a simple odometer type measurement - you can just count zero-crossings to count revolutions.  Also, this is not a very cost-sensitive board.  The sensors account for less then 2% of the retail price.  It has a 120 MHz K22F and a minimum of 32 MB of external flash to work with and the effect on the power budget is minimal. Any sensor that I can cram in there that might potentially be useful down the line is worth considering.  I'd have capacitive touch sensors all the way around the circumference if I could figure out a cost effective way to do it.

Since the sensor fusion toolbox doesn't show translation, can you suggest any reasonably simple simulation framework that might?  Simulink's probably a little out of our budget for this project.

Thanks,

Scott

[michaelestanley · Accepted solution]

Scott,

The fusion algorithm is optimized to make the best possible estimate of device orientation.  Once it has that, it is trival to subtract computed gravity from the measured acceleration.  The toolbox has plots for both.  The sensor readings are plotted on the "Sensors" tab, and the linear acceleration on the "Dynamics" tab.  There are a number of free Matlab clones on the web that you can use to post-process log files.  Scilab and GNU Octive come to mind.

Regards,

Mike

[scottm]

My protégé here, who has some experience with mechatronics (and has been in school a whole lot more recently than me), also just suggested those two.  And my ex is a university professor who teaches rigid body dynamics so I can probably get some input there as well. Last time I gave her what I thought would be a fairly straightforward problem it turned into a student's master's thesis.  :smileywink:

I've been using the FRDM-KL25Z so far because I haven't been able to get it to work with the FRDM-K22F (which is much closer to the intended platform).  The Kinetis Interface Tool shows AGM01 - FRDM_K22F in the available firmware list but it says "No file at specified Firmware path" when I try to load it.  I did get the FSFK_K22F project to compile and load from KDS but I haven't looked at it closely and I'm not clear on whether that's supposed to work with the sensor toolbox.

I've only been able to get it to work over Bluetooth to an Android device (despite trying 3 different BT interfaces, but that's probably the fault of Windows), and hacking it to work with the Bluetooth radio in the hoop seems like it'd be more trouble than it's worth.  If I can get the K22F code running I'll see if I can adapt that to write to mass storage.  Worst case... we've got a working FRDM-KL25Z and a bunch of duct tape.

Thanks,

Scott

[michaelestanley]

Scott,

The K22F will definitely work with the toolbox.  I'm not sure why the toolbox couldn't locate the binary for you.  If you'll shoot me an email at mike.stanley@nxp.com, I'll respond with the .bin you need.  This should be equivalent to the one you got by compiling the project under KDS.

I actually find that Bluetooth works more reliably for me than the wired serial/USB, but you do have to have the appropriate Bluetooth drivers installed and you have to have previously paired with the device in the "Devices and Printers" page.

Mike