IPhone Accelerometer Hack
Hilke Mcnally
Before we can say what the accelerometer of the iPhone does, we need to understand the basics of what an accelerometer does in general. The accelerometer is a device that can measure the force of acceleration, whether caused by gravity or by movement. An accelerometer can therefore measure the speed of movement of an object it is attached to. This is the job of the accelerometer in the Nike + iPod used in running shoes. The piezoelectric sensors can tell if the shoe they are in is moving (in the instant that it is not, the device shuts itself down) and, based on the amount of time the shoe is on the ground vs. the amount of time it is in the air, the iPod can convert this information into an accurate measure of the speed at which the runner is moving.
Because an accelerometer senses movement and gravity, it can also sense the angle at which it is being held. This is what makes the Wii work: Instead of a joystick, the user or player manipulates a controller (rather like a remote control). The controller contains solid-state accelerometers, which can sense the tilt, movement and speed being applied to them, as well as the direction in relation to the Wii's screen. This allows the player to use natural, intuitive motion. When you play, for instance, a sword-fight game, the controller is used as if it was the sword, with the movement translated into electric signals to the computer.
The use of the accelerometer in the iPhone is similar to that in the Wii, although on a smaller scale. The movement and tilt of the device is noted by the sensors, so it can tell which way the screen is being held. This allows it to automatically adjust the visual output to make it appropriate to the direction of the screen. In this way you can view lists with the screen held vertically and watch videos with the screen held sideways.
I'm doing some test with iPhone 4S accelerometer. If I take the raw data in Z-axis (telephone rest over desktop) I get an acceleration 9.65-9.70 m/s2 (after g conversion by 9.8261).But if i have the telephone resting over edge, the measurement of the accelerometer value in the X-axis is so different, aprox. 9.80-9.85 m/s2 (after the same g conversion).My question is, if the gravity is the same, why this difference? It is not callibrated?
Yes, the iPhone accelerometer is calibrated and has an error under 1% in your case. If you collect measurements from other (hundreds of) users, you could calculate the mean error of the device (I guess it's about 1% though).
The problem is that it's not possible to determine gravity 100% exactly when all of the sensors (gyro and compass as well) show an intrinsic error. The lack of a precise external reference system leads to this error. Accelerometer and gyroscope are corrected mutually and if there is a slight drift it does affect the direction where the sensor fusion algorithm (Kalman-Filter or others) calculates gravity should be.
While gyroscope is very fast in detecting the direction it tends to drifting effects. Accelerometers are slower in reaction but provide a way to detect gravity. Magnetometers are even slower but can contribute to stabilising the overall result. Combine Gyroscope and Accelerometer Data shows some graphs of the raw and the processed sensor data.
I continued working with accelerometers. The results are not bad. About iPhone accelerometers calibrating, I can say that STMicroelectronics does calibration over his own sensor. Later, iPhone factory assemblies accelerometer onto circuit board. The soldering affects to accelerometer accuracy (thermal effects) and probably, the accelerometer requires a new calibration, but for consumer requirements, the accuracy is already good, but if you need high requirements, you need a new calibration.
I am trying to record the data from the iPhone's accelerometer (my own iPhone 5s) and set a label on the screen to that data using String(format: "%.2f", data) where data is the value for the specific axis I want to record. To do this I set up a CMMotionManager and began recording accelerometer data, and I have a timer that constantly updates the text in the label. However, I am getting an error from Xcode: "fatal error: unexpectedly found nil while unwrapping an Optional value". Here is the relevant code:
The error stops when I change the accelX.text assignment to a simple string, so I think the optional variable creating the error is something to do with the accelerometer. That's as far as I know, however, so if you have any suggestions, or if I'm doing it completely wrong and there's a better and easier way, I will definitely appreciate it if you help me out.
I am trying to make an application that would detect what kind of shape you made with your iPhone using accelerometer.As an example, if you draw a circle with your hand holding the iPhone, the app would be able to redraw it on the screen.This could also work with squares, or even more complicated shapes.The only example of application I've seen doing such a thing is AirPaint ( ), but it doesn't seems to be able to do it in real time.
My first try is to apply a low-pass filter on the X and Y parameters from the accelerometer, and to make a pointer move toward these values, proportionally to the size of the screen.But this is clearly not enought, I have a very low accuracy, and if I shake the device it also makes the pointer move...
1 - I have my default x, y, and z values.
2 - I extract the gravity vector from this data using a low pass filter.
3 - I substract the normalized gravity vector from each x, y, and z, and get the movement acceleration.
4 - Then, I integrate this acceleration value with respect to time, so I get the velocity.
5 - I integrate this velocity again with respect to time, and find a position.
If I execute this, I get quite good values, I mean I can see the acceleration going into positive or negative values according to the movements I make.But when I try to apply that position to my ball view, I can see it is moving, but with a propencity to go more in one direction than the other. This means, for example, if I draw circles with my device, i will see the ball describing curves towards the top-left corner of the screen.Something like that :
The problem is that you can't integrate acceleration twice to get position. Not without knowing initial position and velocity. Remember the +C term that you added in school when learning about integration? Well by the time you get to position it is a ct+k term. And it is is significant. That's before you consider that the acceleration data you're getting back is quantised and averaged, so you're not actually integrating the actual acceleration of the device. Those errors will end up being large when integrated twice.
Even devices that have some position and velocity sensing (a Wiimote, for example) have trouble doing gesture recognition. It is a tricky problem that folks pay good money (to companies like AILive, for example) to solve for them.
Having said that, you can probably quite easily distinguish between certain types of gesture, if their large scale characteristics are different. A circle can be detected if the device has received accelerations in each of six angle ranges (for example). You could detect between swiping the iphone through the air and shaking it.
You need to look up how acceleration relates to velocity and velocity to position. My mind is having a wee fart at the moment, but I am sure it the integral... you want to intergrate acceleration with respect to time. Wikipedia should help you with the maths and I am sure there is a good library somewhere that can help you out.
Seems like you are normalizing your gravity vector before subtraction with the instantaneous acceleration. This would keep the relative orientation but remove any relative scale. The latest device I tested (admittedly not an Idevice) returned gravity at roughly -9.8 which is probably calibrated to m/s. Assuming no other acceleration, if you were to normalize this then subtract it from the filtered pass, you would end up with a current accel of -8.8 instead of 0.0f;
2 options:-You can just subtract out the gravity vector after the filter pass-Capture the initial accel vector length, normalize the accel and the gravity vectors, scale the accel vector by the dot of the accel and gravity normals.
Basically, When you use Accelerometer only, there is earth's gravity which influences z value of accelerometer. But DeviceMotion tries to compensate for this influence of gravity (i.e.tries to give more accurate value of acceleration.z) by performing some algorithm on raw data received from sensor.
But this algorithm is not 100% accurate and that is why even if you put your device on flat surface like table, you get some non-zero value. This inaccuracy is very low in percentage but still you will get result which cannot be simply ignored.
You may want to perform enough trials and get average values of them to compensate for it. Again, this average value will not solve the problem completely. For example, when device is moving(and not stable such when on table) you may get more inaccurate values.
It appears the iPhone accelerometer data is in units of 'acceleration due to gravity', i.e. a value 1.0 would indicate an acceleration of approximately 9.8 m/s. So if the iPhone is laying flat on the table (face up) the data should nominally be x: 0.0, y: 0.0, z: -1.0 plus some noise due to the above sources.
The iPhone accelerometer is a small sensor embedded in the device that measures changes in acceleration and movement. It works by using tiny micro-electromechanical systems (MEMS) to detect changes in the device's position and movement, and then translates that data into usable information.
The iPhone accelerometer can collect data on the device's orientation, acceleration, and movement in three-dimensional space. This includes data on the device's tilt, rotation, and overall movement, as well as specific measurements such as velocity and impact force.
bcf7231420