A short while ago, I discovered that Wii Fit could be used to track my progress as I walked on a treadmill. Wii Fit has a game where you jog in place in front of your TV to travel through a virtual landscape. Instead of bouncing up and down on the floor, I put my wiimote in my pocket, hopped on the treadmill and had a much better virtual exercise experience. And of course this got me thinking: if the wii can track movement, why can't the iPhone do the same?

At about this same time, we got a reader question over at TUAW about the Nike+ sports kit -- whether the iPhone would be able to replace the sports kit. All in all, I was at a very iPhone-accelerometer place in my thinking. So I decided to mess around with the accelerometer and with walking and to see if I could figure out some of the math for myself. (I later found and posted about this Google Code project but what you see here was developed independently.)

The iPhone accelerometer delivers its force vector in x, y, and z values that range between -1 and 1. These samples update over time as the iPhone responds to movement.

Because the iPhone's orientation is an unknown when you stick it into a pocket, you need to track how that force vector changes over time and the easiest way to do that is to take the dot product between successive intervals.

With normalized vectors (that is, when the vector length is exactly one), this produces a cosine value of the angle between them. In theory, when an object stops motion and reverses, that angle should equal 180 degrees. In practice, using a pocket-based detection system means that much more gradual angles need detecting as the iPhone slips around in your pocket.

I found that looking for angles above 90 degrees (cosine values below zero) worked great if you were holding the iPhone in your hand and shaking it side to side. Perfect detection system because the iPhone was rigidly in-line with the hand movement.

With the iPhone in your pocket, I needed to look for much more subtle changes. The iPhone was sliding along in there rather than moving in perfect sync with up and down movements of the body's pace.

I found that I needed to do two things: first, to look for very slight angle changes (where the cosine was less than, for example, 0.75--very shallow angles indeed) and second, to put a block in for ongoing pocket-based rotation. This involved responding to only the first triggering change and ignoring follow-up movements until there was a break in that first set of movements.

Roughly speaking then, this is what I did:

float dot = (px * xx) + (py * yy) + (pz * zz);
float a = ABS(sqrt(px * px + py * py + pz * pz));
float b = ABS(sqrt(xx * xx + yy * yy + zz * zz));

dot /= (a * b);
        
if (dot < sensitivity) // bounce
{
    if (!isChange)
    {
        isChange = YES;
         // count increases and all work done here
    } else {
        isChange = NO;
    }
    px = xx; py = yy; pz = zz;
}

Here, px, py, and pz refer to the previous vector and xx, yy, zz refer to the current one. After obtaining the dot product, I compare it against a sensitivity check (I actually had a slider in my program, so I could adjust that sensitivity) and see whether or not there was a new change in direction.

This approach actually worked pretty well and provided a good pace count for the iPhone. My friend John the mathematician suggests that I look for derivative sign changes in the acceleration over time to supplement this approach, which I'll try to give a spin sometime this week.