MENU

 

20-Jan-2017

Why You Need a Gyro to Measure Position

By Doug Harriman (Chief Technology Officer)

The Bowflex SelectTech 560® (ST560) is a “smart” dumbbell, a piece of exercise equipment with embedded sensors and processing to provide training feedback during your workout.  The ST560 has an inertial measurement unit (IMU) to determine the motion of the device.  Custom algorithms convert the raw motion data into information about the quality and speed of an exercise repetition, as well as allowing the device to count successful repetitions.  This knowledge can be used to enhance the effectiveness of a workout, as well as providing a simple method to record the workouts completed.  It can also make that information available to social media for informal competition with friends.  Simplexity Product Development was heavily involved in the development of the ST560, owning the majority of the product firmware, as well as creating all of the data processing algorithms used to convert raw sensor data into the key exercise metrics. 

To explain exactly why a gyro is required, I'll work through a simplified, two-dimensional example of the ST560 motion for the use case of a bicep curl.  For this example, the motion we're looking at is the rotation of the device about my elbow.  My forearm is about 14” long (355 mm), and we'll assume I do a rep that moves the dumbbell through 180 degrees of motion in just under one second, say 800 milliseconds (ms).  The path for the analysis is shown in the image to the left. 

A common misconception about products such as the ST560 and the HSI Loop CPR Training Device®, is that the only sensor required is an accelerometer.  In order to create a viable IMU for measuring the position of a device in free space, it is critical to have both a 3-axis accelerometer and a 3-axis rate gyroscope. 

At t=0, my arm is straight down.  I rotate the dumbbell about my elbow (red circle), until it's straight up at t=800 ms.  To keep the motion simple, we'll also assume that I accelerate for half the time (from t=0 to t=400 ms), then decelerate the other half (until t=800 ms). 

The basic concept of the ST560 device is that we want to use a low cost accelerometer to measure this motion.  To do so, we'll measure the acceleration of the device in the X and Z directions, then integrate each of those signals twice to convert acceleration to position in each direction. 

The next three charts show the position, velocity and acceleration of the device in both the X and Z directions.  This gives us an initial look at the signals we'll be dealing with from the accelerometer. 



Note that I've added the offset due to gravitational acceleration to the Z axis acceleration data.  The accelerometers will pick this up, so it's important to add in.

If you think about the motion profile and remember your basic calculus (acceleration is the time derivative of velocity, velocity is the time derivative of position), these plots should make sense.

To get a position measurement, we just need to remove the gravitational acceleration from the Z accelerometer, integrate twice, and we have position.  Sounds easy, right? 

Here's where things start to get tricky.  The plots above all operate under the assumption that the accelerometer X channel measures X acceleration and the Z channel measures Z acceleration.  What happens if the user rotates the device during motion?  In fact, when I do a bicep curl, I tend to grip the dumbbell tightly, which causes the whole device to rotate in space to stay aligned with my arm.  So, instead of the accelerometer channels staying aligned with the global reference frame used for the motion measurement, they actually measure in a rotating reference frame.  The figure to the left shows how the X-Z axes rotate (small black arrows) during the motion.

The figure below shows what the rotation does to the measured acceleration signals.  The non-rotated measurements are shown in blue, while the rotated coordinate frame measurements are shown in red.

Clearly, these signals are very different.  To look at the data in another way, the chart to the left shows the X-Z acceleration vector at snapshots every 100 ms during motion.  Again, the blue arrows represent the non-rotated measurements, while the red arrows show the measurements from a rotated coordinate frame.  The number near the arrow head is the time at which the measurement was taken.  Note that at t=0, the arrows are on top of each other, as the local reference frame is aligned to the global reference frame.

As the plot clearly shows, as the device begins to rotate, the measured acceleration vector begins to rotate away from the value which we want to measure.  If we were to integrate the rotated signals, we'd end up estimating a completely incorrect position.  In fact, with the rotated signals, it's not clear how to remove gravity from the measurement, as we know the gravity signal is not 100% in the Z measurement.  How much of the 1 G of gravity should be subtracted from each of the measurements? 

If we knew the exact motion ahead of time, we might have a chance.  However, when we want to measure general motion for something like the ST560 dumbbell, we simply don't have enough information.

Enter the Gyroscope!

As you've guessed by now, the solution to the problem is to introduce a gyroscope into the design.  Rate gyros are standard components in low cost cell phone IMU's.  A rate gyro measures the rate of rotation of a body.  Used in combination with an accelerometer, you theoretically have all of the information you need to estimate the orientation of the device.   I say “theoretically” because there are few practical issues with these devices that complicate the situation.  I'll address those in a future blog posting.  For now, we'll assume we have ideal sensors.

Since I've conveniently thrown out a bit of reality, we can use the following high level algorithm for estimating the position of our device in 2D space.  The steps go as follows:

  1. Whenever we're not in motion, establish a baseline orientation. 
    1. We can tell if we're not in motion because the magnitude of acceleration vector will measure 1.0 while there will be zeros on the gyro signals for some period of time (you'll have to figure out how long that time is for your application). 
    2. When you're not in motion, you're only measuring gravity, so you know which way is down.  For the 2D case, that's all you need to establish your baseline orientation.
  2. From the baseline orientation, start integrating the gyro signals.  The integrated gyro signal represents the orientation of the device.
  3. Measure the signals on the accelerometer channels. 
  4. Using the orientation information from step 2, rotate the accelerometer data to align it to the global reference frame.
  5. Subtract off the gravity signal from the globally oriented Z acceleration signal.
  6. Integrate the globally oriented acceleration signals twice to get acceleration to get position.
     

Extra Credit!

In the analysis and algorithm above, we've made an implicit assumption that may be problematic in some designs.  Everything I've presented so far assumes that the accelerometer is mounted at the center of mass of your device.  If it's not, then a pure rotation of the device will induce an acceleration at the sensor.  For small mounting offsets and slow rotations, this signal may be fine to ignore.  If not, you can use your gyro data to remove this error signal.  The steps for doing that are:

  1. Read the rate gyro signals directly (no integration, we're after rotation rate).  Rotation rate is represented by ω.
  2. Estimate the angular acceleration by taking the time derivative of the gyro signals.  This can be estimated by simply subtracting the previous reading from the current reading and dividing by the sample time.  This angular acceleration is represented by α.
  3. Calculate the linear tangential and centripetal accelerations due to the rotation:

Acceltangental = α x r

where r represents the distance from the center of mass to the sensor.

Accelcentripital = ω2 / r

  1. Read the accelerometers.
  2. Subtract the acceleration values calculated in step 3 from the measured acceleration values before performing any rotations.
  3. Continue processing the signals as described previously.

For the Bowflex SelectTech 560, the use of both an accelerometer and a gyro was critical to generating usable position data.  The algorithm described above formed the basis of our data processing.  Of course, the realities of non-ideal sensors and operating in a three-dimensional environment complicated things significantly.  In a future post I'll address some of these issues, and explain why you may need a compass too!


Subscribe For More

To receive more articles like the one above in your inbox, sign-up to our newsletter below.

Blog Posts


Better Firmware Faster

19-Nov-2018

Demystifying What it Takes to be a CEO

18-Oct-2018

Considerations for Code Refactoring

24-Sep-2018

American Association for Clinical Chemistry Annual Meeting

30-Aug-2018

Simplexity's Answer to Growing Pains

09-Aug-2018

Consumer Electronics Show 2018 | Part Three | So, What is a Robot?

29-Jan-2018

Consumer Electronics Show 2018 | Part Two | CES 2018 and IoT

22-Jan-2018

Consumer Electronics Show 2018 | Part One

15-Jan-2018

Why on earth are heavy weights being suspended from this printer?

22-Dec-2017

10 Best Places to Buy Parts for Product Development

29-Nov-2017

Robust Firmware Stack Sizing

08-Nov-2017

Senaptec Strobe: A Study in Simplification

19-Oct-2017

Treatment, Prevention, and Medical Engineering Solutions

04-Oct-2017

Options in Product Development Models: Internal, CDM, or Design Specialist

20-Sep-2017

Designing Thermal Control Systems

30-Aug-2017

Simplexity’s 7 Steps to Simplification©

15-Aug-2017

Battle of the Buttons: UCSD vs. PSU

02-Aug-2017

Considerations For Medical and Biotech Designs

13-Jul-2017

Risk Mitigation in Product Design: Part 2

11-Jul-2017

Risk Mitigation in Product Design: Part 1

28-Jun-2017

San Diego's Biotech Consortium

09-Jun-2017

Appropriate Models for 3D Motion Analysis: Part 3

25-Apr-2017

University of Oregon’s Product Design Program Is One of a Kind

19-Apr-2017

Appropriate Models for 3D Motion Analysis: Part 2

14-Apr-2017

From Engineer to Leader: How Do You Get There?

12-Apr-2017

Appropriate Models for 3D Motion Analysis: Part 1

06-Apr-2017

Why Engineering Still Matters in Product Development

29-Mar-2017

How Mechatronics Improve Drone Technology

16-Feb-2017

Why You Need a Gyro to Measure Position

20-Jan-2017

Why I, As The CEO, Get The Same Bonus As All My Other Employees

13-Dec-2016

Mechatronics Aids In Embedded System Design

07-Dec-2016

Top 10 Tips for Designing Injection Molded Plastic Parts

22-Nov-2016

British school kids and car hackers: the widespread appeal of open source

14-Nov-2016

When should you consider designing custom gears?

07-Nov-2016

Conference Report: Open Source Hardware Summit

31-Oct-2016

What is a Motion Control System?

20-Oct-2016

The Top 10 Questions to ask a Product Development Firm

05-Oct-2016

The Potential of the Apple AirPods To Disrupt A Whole Industry

12-Sep-2016

How to Use Open Source Hardware in Product Development

01-Sep-2016

What is the mech in mechatronics?

16-Aug-2016

3 Tips for IoT Product Success

02-Aug-2016

When Should I Start Designing For High-Volume Manufacturing?

19-Jul-2016

Designing a 3D Printer for the Home

29-Jun-2016

It Turns Out That EMC Is Not Black Magic

22-Jun-2016

Selecting the correct motor type and size

06-Jun-2016

When brainstorming fails, throw an imaginary cat

18-May-2016

Five Tips for Mechatronic System Integration

09-May-2016

Three Tips for Designing High Volume Mechatronic Products

28-Apr-2016

What Is Mechatronics?

18-Apr-2016

If I could only do 3 things to simplify a design, what should they be?

06-Apr-2016