Micro-scale accelerometers are not that much different from the machine previously described but generally use a cantilevered beam instead of a spring. To track more than one axis, sometimes three discrete accelerometers are placed out of plane with respect to one another. Alternatively, more complex models use elements that can sense all three directions within a single integrated sensor. These generally give better results.

The only important difference from the aforementioned examples, besides MEMS being thousands of times smaller in scale than the mass and spring, is how to measure the deflection of the test mass. There are three common methods employed in accelerometers. For most game devices where extreme accuracy isn’t required, the deflection is usually measured as a change in capacitance. This is somewhat the same way that capacitive touch screens work, as described in Chapter 20, and is shown in Figure 21-2.

Figure 21-2. MEMS cantilever accelerometer

The beam deflects under the influence of the external accelerations of the test mass and brings two charged plates farther or closer together. This changes the capacitance of the system. This change can then be calibrated to the imposed acceleration.

Other methods include integrating a piezoresister in the beam itself so that the deflection of the beam changes the resistance of the circuit. Although this ultimately gives better results, these are harder to manufacture. For the most demanding applications, there are accelerometers using piezoelectric elements based on quartz crystals. These are very sensitive even during high-frequency changes in acceleration but are generally not used in sensing human-input motion.

To help you better experiment with accelerometers, we’ve collected the specifications on a few of the most common accelerometers in use at the time of writing. The future may hold cheap accelerometers based on quantum tunneling that can provide almost limitless accuracy, but Table 21-1 outlines what you’ll generally be working with for now.

The 2g limit for phones can cause problems when you’re attempting to record motion. This limitation will be discussed later in this chapter. The larger range of Wii and Sony controllers demonstrate that they are dedicated to gaming where larger accelerations are expected.

The human arm is capable of exceeding the ±2g range of the iPhone’s sensor easily. The values reported by the API will actually exceed 2g up to about 2.3g. The accuracy of these values that exceed the specification is unknown. Regardless, they are probably at least as accurate as the option of trying to recreate the data, so if required they can be used. All values above this upper limit will be reported as the upper limit such that if you graphed the values, they would look like Figure 21-3.

Figure 21-3. Acceleration graph showing clipping

There are several different ways to handle data clipping. One is to discard the data and alert the user that he has exceeded the available range. Another is to attempt to recreate the missing data. If you are recording the data for later processing, you can use both segment 1 and segment 2 to fit the curve between the point at which the data began to be clipped and the point in which meaningful data collection is resumed. This is highly application dependent, and the curve used to fit the data will have to be matched to the activity at hand. If you are recording the data for later processing, you can use both segment 1 and segment 2 to give your data.

If you are attempting to process the signal in real time, you’ll have only segment 1 to work from. This could result in a discontinuity when meaningful data collection resumes, and you’ll have to decide how to deal with that given the particulars of what you are doing with the data.

Here we will show you how to implement code for a simple game that asks the user to move an avatar to a target by tilting the phone. First, we will briefly show an example of determining the rotation about a single axis. Let’s assume we have an accelerometer rotated at some arbitrary angle, α, which is what our algorithm will solve for. As previously discussed, accelerometers generally report values as multiples of near earth gravity, g. For the following example, we are concerned only with the x- and y-axis values, a_x and a_y, respectively. If the device were in the “upright” position, then a_x would equal 0 and a_y would equal 1. After rotating the device, we’d see different values that are related to our angle α by use of the arctangent function. In this case, because the single-argument atan function included in most programming languages doesn’t differentiate between diametrically opposed directions, it is beneficial to use the two-argument function. The relevant C code is as follows:

#define PI 3.14159

float find2dAngle(void){

    //LOCAL VARIABLES
    float alpha,
    double ax, ay;

    //POLL ACCELEROMETER FOR ACCELERATIONS, API SPECIFIC
    ax = getXacceleration();
    ay = getYacceleration();

    //FIND ANGLE
    alpha = atan2(ay,ax);

    if (alpha >= 0){
        alpha = alpha * (180/PI);
    else {
        alpha = alpha * (-180/PI) + 180;
    }

    return alpha;
}

This is pretty straightforward, but there are a few things to point out. First, the way in which your program will get results from the accelerometer will vary greatly between platforms, so we have encapsulated that API-specific code in a getXacceleration() function. In fact, most operating systems will be continuously polling the accelerometer in a separate thread, so you’ll have to have a logical operator that tells your accelerometer object when you actually want to see those values passed to your program. Example Objective-C code for the accelerometer in the iPhone will be shown later. Secondly, you’ll notice that we are using an if statement that changes the radians to degrees in such a way as to return proper 0°–360° answers. This avoids having to pay attention to the sign, as atan2 returns only answers between 0° and 180°, using a negative value to represent the other half of the range. For example, an output of 0° means the device is vertical, an output of 90° means the device is rotated 90° to the left, and an output of 180° means the device is upside down.

Now let’s extend this to two dimensions. This will tell us not only how far the phone is from vertical about one axis, but its inclination about the y-axis as well.

Now let’s say that we want to develop a game in which we control a sprite moving in a 2D world. The user would hold the device as if it were lying on a table and look down from above. He or she would then tilt the phone out of that plane to get the sprite to move in the desired direction. The fraction of gravity that the accelerometer is now experiencing in the x- and y-directions will be inputs into our simulation.

The example will be demonstrated using Objective-C code for the iPhone, and we’ll be using the Qwartz2D graphics framework. If you aren’t familiar with Objective-C, don’t worry—we’ll explain what we are doing in each step, and you can port that code to whatever language you are working in.

The first step will be to set up our accelerometer. In this case we are going to initialize it in our tiltViewController.m file so that we have:

- (void)viewDidLoad
{
    UIAccelerometer *accelerometer = [UIAccelerometer sharedAccelerometer];
    accelerometer.delegate  = self;
    accelerometer.updateInterval = kPollingRate;
    [super viewDidLoad];
}

The important concept here is that we have defined a name for our accelerometer object, accelerometer, and we have set its updateInterval property to kPollingRate. This constant was defined in tiltViewController.h as (1.0f/60.0f), which corresponds to 60 Hz. In other words, this tells the operating system to update our program’s accelerometer object 60 times a second. Also in tiltViewController.m, we write what happens when the accelerometer object gets updated via the accelerometer’s didAccelerate: function as follows:

- (void)accelerometer:(UIAccelerometer *)accelerometer 
didAccelerate:(UIAcceleration *)acceleration{
    [(SpriteView *)self.view setAcceleration:acceleration];
    [(SpriteView *)self.view draw];
}

This function is called every time the acceleration object is updated and does two things. First, it takes the acceleration data from the accelerometer and passes it to the SpriteView class, which we’ll talk about in a second. Then it tells the SpriteView to go ahead and redraw itself.

The SpriteView class is where the action happens and consists of a header file, SpriteView.h, where we define the following global variables:

Additionally, we’ve defined the following global constants:

Now we’ll show you how we use these variables in SpriteView.m to move our sprite on our screen as a result of the accelerometer values. First, we have some initialization to do, which takes place in the initWithCoder: method that runs the first time the view is loaded:

-(id)initWithCoder:(NSCoder *)coder {
    if((self = [super initWithCoder:coder])){
        self.sprite = [UIImage imageNamed:@"sprite.png"];
        self.currentPos = CGPointMake((self.bounds.size.width / 2.0f) +
(sprite.size.width / 2.0f), (self.bounds.size.height /2.0f)+(sprite.size.height /2.0f));
        xVelocity = 0.0f;
        yVelcoity = 0.0f;

        convertX = self.bounds.size.width / kWorldWidth;
        convertY = self.bounds.size.height / kWorldHeight;

    }
    return self;
}

Most of this is pretty straightforward. We tell our program where to find the sprite image we’ve chosen and set its initial position to the center of the screen. We also set its initial velocity to 0 in both directions. We then go ahead and initialize our convertX and convertY variables based on the self.bounds.size property, which gives the bounds of the view in pixels. We’ll show exactly how this affects our program later. Next, we’ll write a custom mutator for the CurrentPos variable:

- (void)setCurrentPos:(CGPoint)newPos {
    prevPos = currentPos;
    currentPos = newPos;

    if(currentPos.x <0){
        currentPos.x = 0;
        xVelocity = 0.0f;
    }
    if(currentPos.y <0){
        currentPos.y = 0;
        yVelcoity = 0.0f;
    }
    if(currentPos.x > self.bounds.size.width - sprite.size.width){
        currentPos.x = self.bounds.size.width - sprite.size.width;
        xVelocity = 0.0f;
    }
    if(currentPos.y > self.bounds.size.height - sprite.size.height){
        currentPos.y = self.bounds.size.height - sprite.size.height;
        yVelocity = 0.0f;
    }

    CGRect curSpriteRect = CGRectMake(currentPos.x, currentPos.y, 
currentPos.x+sprite.size.width, currentPos.y+sprite.size.height);
    CGRect prevSpriteRect = CGRectMake(prevPos.x, prevPos.y, 
prevPos.x+sprite.size.width, currentPos.y+sprite.size.height);
    [self setNeedsDisplayInRect:CGRectUnion(curSpriteRect, prevSpriteRect)];

}

In case you are unfamiliar with Objective-C, when you define a class instance variable it will automatically define a mutator that simply updates the value of the variable to the value you are passing it. However, in the preceding example we are overriding that mutator to do some additional work. The first thing we do is to set the prevPos variable to the current position of the sprite and then update the currentPos with the value the mutator was given. However, our physics engine isn’t going to include collision response with the screen boundaries, so we go on to check if the sprite has reached the screen edge. If so, we simply tell the program to leave it on the edge and to set the velocity in that direction to 0. Lastly, we define a couple of rectangles based on the new position of the sprite and the old position of the sprite. After we union those rectangles together, we tell the operating system to redraw the screen in that area with the setNeedDisplayInRect: method. As you might recall, our accelerometer object is calling the draw method every time it updates, and it is in this method that we will put our physics engine:

- (void)draw {
    static NSDate *lastUpdateTime;

    if (lastUpdateTime != nil) {
        NSTimeInterval secondsSinceUpdate = -([lastUpdateTime
timeIntervalSinceNow]); //calculates interval in seconds from last update

        //Calculate displacement
        CGFloat deltaX = xVelocity * secondsSinceUpdate + 
((acceleration.x*g*secondsSinceUpdate*secondsSinceUpdate)/2); // METERS
        CGFloat deltaY = yVelocity * secondsSinceUpdate + 
((acceleration.y*g*secondsSinceUpdate*secondsSinceUpdate)/2); // METERS

        //Converts from meters to pixels based on defined World size
        deltaX = deltaX * convertX;
        deltaY = deltaY * convertY;

        //Calculate new velocity at new current position
        xVelocity = xVelocity + acceleration.x * g * secondsSinceUpdate; //assumes
acceleration was constant over last update interval
        yVelocity = yVelocity - (acceleration.y * g * secondsSinceUpdate); //assumes 
acceleration was constant over last update interval

        //Mutate currentPos which will update screen
        self.currentPos = CGPointMake(self.currentPos.x + deltaX, 
self.currentPos.y + deltaY);

    }

    [lastUpdateTime release];
    lastUpdateTime = [[NSDate alloc] init];

}

Previously, we discussed issues with timing when working with accelerometer data. In this case, Objective-C makes it very easy to get the correct elapsed time in seconds. We first define a static variable, lastUpdateTime, as an NSDate type. This type has a built-in function to give the time interval in seconds from now, which we assign to an NSTimeInterval variable. Skipping down to the last two lines, we are simply updating the last update time by releasing and reinitializing the variable. As it is static, it will remain even after the function returns. If you are using a lower-level language, you might have to write your own timeIntervalSinceNow function that takes into account the particular clock frequency of the system.

Now that we have our time interval in seconds, we can calculate our new position. Recall from Chapter 2:

which we have rearranged to be:

This gets programmed as:

        CGFloat deltaX = xVelocity * secondsSinceUpdate + ((acceleration.x*g*secondsSinceUpdate*secondsSinceUpdate)/2); // METERS

We then convert this displacement in meters to displacement in pixels using an appropriate ratio for the size of our world. Before we can move on, we have to calculate our new velocity at our new position. So we again assume the acceleration as constant over the update interval, and recalling:

from Chapter 2, we can solve for the new xVelocity with:

xVelocity = xVelocity + acceleration.x * g * secondsSinceUpdate;

As you can see from the complete method description, the code of the y-direction is similar. Finally, we call the currentPos mutator to set the new position based on the change in displacements. Recall that this is a custom mutator that also tells the operating system to update the display. After the draw method is finished, the accelerometer waits 1/60 of a second and then calls it again. You could extend this program by adding in friction, fluid resistance, and collisions with the screen boundaries using the methods outlined in the other chapters of this book.