# Fall Detection using Accelerometer

I am now developing a micro-controller based system that detects when a person falls down using Accelerometer. The accelerometer might be placed in the person's cloth pockets. The important thing is to distinguish the signal during a fall from a signal during normal movements. It will be done by a micro-controller. It means that the analog signal from accelerometer must be converted to digital before being given to the controller.

But the digital values are something like 241, 314, 102, etc. I don't know how to fix the signal value which will be generated during a fall i.e., the threshold at which the micro-controller detects the fall. How to do this?

• When person fell, it probably has acceleration=G, or higher. So if you measure acceleration and multiple records has G or higher acceleration it is probably in free fall. Sep 22, 2013 at 20:39
• @Gossamer: No, "free fall" by definition is when acceleration (as measured by an accelerometer) equals zero. Sep 23, 2013 at 4:04
• I'm pretty sure most of the MEMS accelerometers on the market has a built-in free fall detection. Meaning you'll only have to set it up out of reset and then wait for an interrupt. Sep 23, 2013 at 6:44
• This is a research subject and you can find several papers on how to do this. Regretably this is not an easy problem to solve.
– Ktc
Sep 23, 2013 at 8:35

If you're going to do this in any sort of useful way, you're going to need to do something a lot more sophisticated than a simple threshold check on the raw accelerometer data.

First of all, accelerometers drift, and you're going to have to correct for that. Then, since you don't know the orientation of a device in someone's pocket, you're going to have to continuously compute the 3-D acceleration vector, and then evaluate that for significant events, such as changes in angle and/or magnitude.

Consider the consequences of errors — both "false positives" (creating an alert when no actual fall occurred) and "false negatives" (failing to detect an actual fall). If either of these occurs at a significant rate, your product will be a failure.

You're going to have to build a significant number of devices and simply collect data from a lot of different users doing a lot of different activities (including falling) and then determine whether you can reliably recognize the fall events among all of the other activity.

• Yeah, this is not going to be easy. Various normal events could have more total accelleration than a somewhat controlled fall. Maybe the slip on ice and crash to the ground kind of fall can be reliably detected, but many "falls" won't be that abrupt. Sep 22, 2013 at 17:11

I'm not sure what sort of "fall" you are trying to detect. But lets start with the basic theory, which is fairly straightforward, and then move into the non-idealities and the implementation details. I'm assuming you have a 3-axis accelerometer.

An accelerometer measures acceleration. Gravity acts on an accelerometer at rest and appears as a force of 1G. If there is a free fall, the measured gravity vector will reduce to 0. So as a first pass, you can threshold the 3-d norm of the acceleration vector. If the 3-d norm falls below the threshold, you're in a free-fall. Because you are simply looking at the magnitude of the vector, orientation does not matter.

When will this "first order" approach fail? I can think of two situations on first glance...

• It will fail if there is some additional acceleration during a fall (maybe a jumping/diving fall??)
• Or, it might fail if the fall is not quite a free fall (perhaps someone manages to catch himself halfway, or let himself down gently)

As some additional ideas for a second order approach: You could try to look at the magnitude profile. We would expect to see a free fall region, maybe around 0.3G, then a spike above 1G when the person hits the ground, followed by approximately a 1G period of being on the ground. The other poster is correct- it will likely take some experimentation to quantify repeatable behavior during falls.

Finally, implementation details: If the accelerometer outputs analog values, your ADC converts analog to digital which you see as 241, 314, 102, etc. Look at the accelerometer datasheet for conversion values, probably something in units of Volts/G. Then, make sure you know your ADC conversion, likely in units of integers/Volts. This should be enough to convert your result into units of G.

There are certain accelerometers that include this function (It is used in notebooks with mechanical hard drives to lock the drive in case of a fall). These devices can generate an interrupt on free fall.

One such device is the MMA8452 by Freescale. Here is an application note with more details: http://www.freescale.com/files/sensors/doc/app_note/AN3151.pdf

First, I'd test to see if the "free fall interrupt" function everyone is mentioning will pick up a human fall (which may be slower than actual free fall, because you're kind of assisting yourself down, at least somewhat, on everything but a full on trip, fall flat on your face type fall).

Assuming that doesn't work 100% of the time, I'd log some data sets of various falls. You'll want to take a 3 axis accelerometer sensor and calculate the magnitude of the acceleration vector (I'm going to assume we're talking in g's, since most MEMs scale factors are given to convert to g's). Remember: there is always 1g on you if you are sitting still, so the difference of the measured vector and 1 is the body's acceleration. Look for high frequency events where the magnitude of the acceleration vector is much less than 1. Drift shouldn't be an issue, since a fall should really stand out in the data set.

Make sure to get a MEMs sensor that isn't rated for a huge number of g's: some devices output in the range of 10's or 100's of g's. Get one that is full scale 2 or 4 g's so you have good resolution. These devices don't break after 2 or 4 g's, they just have good resolution in that range.

You're lucky, because attitude (figuring which way is up) doesn't really matter in this problem: you really only care about the magnitude of the acceleration vector.