Attached is a piece of data with the iPhone in a pocket with the motorbike accelerating from 0 to 13 metres/sec (plot shown in green) and the raw accelerometer data (magnitude in g), the x-axis is in seconds. The speed is being sampled at 1 every second (using the GPS) and the accelerometer data is being sampled at 10 every second. Ideally if i were to accelerate at a constant rate (which is not the case on a motorbike or any vehicle) from 14s to 20s, i should have an acceleration of 13/6 = 2.16 m/s^2 = 0.22g above the stationary 1g (due to gravity). My assumption is that the forward acceleration will be much larger than the lateral movements (i.e. due to tilting of the bike, etc.), therefore allowing the magnitude of the x,y and z accelerometer components to be a good enough approximation of the forward acceleration of the bike. But as you can see, from 14s to 20s i get spikes in acceleration instead of a constant acceleration at 1.22g. This could be due to the bike not accelerating at a constant rate and the values that dip below 1g could be due to the jerk of the bike while accelerating. Any thoughts?
Two things:
Acceleration is a vector. I presume you're accelerating on a level track, so the accelerations will add like perpendicular vectors, so you should see an increase in magnitude of about 0.24 m/s = 0.024 g, which is barely visible on this scale (I think I see it, but I'm not sure).
The wiggle in the acceleration curve continues when you're cruising at high (but almost constant) speed. So it's not caused by jerks in the drive, it's caused by the bumpiness of the ride and maybe some 4-5 Hz resonance in the suspension. (The bumps don't seem to get faster, so I doubt it's an unbalanced wheel.)
Related
I am trying to detect a free fall scenario. I have accelerometer and gyroscope.
A simple fall I can detect by inspecting a total acceleration of 0g
However, my problem is when the IMU falls and rotates at the same time (centrifugal force). Any idea how to distinguish this scenario?
I don't have the solution, but let me state 2 points:
if the IMU is near the center of mass of your hardware, the centrifugal acceleration should be negligible
If you have a constant rotation you should read a constant rate on the gyroscope, and a constant acceleration too ( if the IMU is not in the center of mass). Morover, the constant rotation should be on an axis perpendicular to that of the constant rotation
I am writing an iPhone/iPad app. I need to compute the acceleration and deceleration in the direction of travel of a vehicle traveling in close to a straight horizontal line with erratic acceleration and deceleration. I have the sequence of 3 readings from the X,Y,Z orthogonal accelerometers. But the orientation of the iphone/ipad is arbitrary and the accelerometer readings include vehicle motion and the effect of gravity. The result should be a sequence of single acceleration values which are positive or negative depending on whether the vehicle is decelerating or accelerating. The positive and negative direction is arbitrary so long as acceleration has the opposite sign to deceleration. Gravity should be factored out of the result. Some amount of variable smoothing of the result would be useful.
The solution should be as simple as possible and must be computationally efficient. The answer should be some kind of pseudo-code algorithm, C code or a sequence of equations which could easily be converted to C code. An iPhone specific solution in Objective C would be fine too.
Thanks
You will need some trigonometry for this, for example to get the magnitude you need
magn = sqrt(x*x+y*y+z*z);
to get the angle you will need atan, then c function atan2 is better
xyangel = atan2(y,x);
xymagn = sqrt(x*x+y*y);
vertangle = atan2(z,xymagn)
no how you get negative and positive magnitude is arbitrary, you could for example interpret π/2 < xyangle < 3π/2 as negative. That would be taking the sign of x for the sign of magn, but it would be equally valid to take the sign from y
It is really tough to separate gravity and motion. It's easier if you can analyze the data together with a gyroscope and compass signal.
The gyroscope measures the rate of angular rotation. Its integral is theoretically the angular orientation (plus an unknown constant), but the integral is subject to drift, so is useless on its own. The accelerometer measures angular orientation plus gravity plus linear acceleration. With some moderately complex math, you can isolate all 3 of those quantities from the 2 sensors' values. Adding the compass fixes the XY plane (where Z is gravity) to an absolute coordinate frame.
See this great presentation.
Use userAcceleration.
You don't have to figure out how to remove gravity from the accelerometer readings and how to take into accont the orientation: It is already implemeted in the Core Motion Framework.
Track the mean value of acceleration. That will give you a reference for "down". Then subtract the mean from individual readings.
You'll need to play around with the sensitivity of the mean calculation, since, e.g., making a long slow turn on a freeway will cause the mean to slowly drift outwards.
If you wanted to compensate for this, you could use GPS tracking to compute a coarse-grained global acceleration to calibrate the accelerometer. In fact, you might find that differentiating the GPS velocity reading gives a good enough absolute acceleration all by itself (I haven't tried, so I can't say).
I am using this device (http://www.sparkfun.com/products/10724) and have successfully implemented an quite well working orientation estimation based on a fusion of magnetometer, accelerometer and gyroscope data based on this http://www.x-io.co.uk/node/8#open_source_imu_and_ahrs_algorithms implementation. Now I want to calculate the dynamic acceleration (measures acceleration without static gravity acceleration). For doing this I came to the following idea.
Calculate a running average of the raw accelerometer data. If the raw acceleration is stable for some time (small difference between running average and current measured raw data) we assume the device does not move and we are measuring the raw gravity. Now save the gravity vector and also current orientation as quaternion. This approach assumes that our device could not be accelerated constantly without gravity.
For calculating the acceleration without gravity I am now doing following quaternion calculation:
RA = Quaternion with current x,y,z raw acceleration values
GA = Quaternion with x,y,z raw acceleration values of estimated gravity
CO = Quaternion of current orientation
GO = saved gravity orientation
DQ = GO^-1 * CO // difference of orientation between last gravity estimation and current orientation
DQ = DQ^-1 // get the inverse of the difference
SQ = DQ * GA * DQ^1 // rotate gravity vector
DA = RA - SQ // get the dynamic acceleration by subtracting the rotated gravity from the raw acceleration
Could someone check if this is correct? I am not sure because on testing it I get some high acceleration on rotating my sensor board, but I am able to get some acceleration data (but is is much smaller than the accelration during rotation) if the device is moved without rotating it.
Moreover I have the question if the accelerometer is also measuring acceleration if it is rotated on place or not!
Another way is to differentiate accel to give jerk (using finite difference, j = (a2 - a1) / dt). Run the jerk through a decay/leakage function (use a half life decay calc value rather than a simple multiplier). Then integrate the jerk (trapezoidal rule, a = dt * (j1 + j2) * 0.5) and it will remove the DC offset (gravity). Again run this signal through a decay function.
The decay functions avoid the value spiraling off but will reduce the magnitude of dynamic acceleration values that you see and will introduce some shaping to the signal. So you won't get values that are 'accurate' m/s/s readings any longer. But it is useful for short-time movements.
Of course you could just use a highpass filter instead but that generally requires a fixed sampling rate and is probably more computationally expensive if you are using convolution (finite impulse response filter).
It's easier than you think. You may wanna have a look at my post here about it:
http://www.varesano.net/blog/fabio/simple-gravity-compensation-9-dom-imus
I am doing research on the tremors and Parkinson's disease.The plan is to use accelerometers and gyroscopes on the human arm. I plan on using Pulse for data collection and analysis. My questions are:
Is it true that there are some accelerometers that can separate gravitational acceleration from linear acceleration (heard it on the uncited grapevine). My suspicion is that we can't place an accelerometer on the patients arm to measure, say, the tremors caused by bicep and tricep contraction because if the patient rotates his wrist, the change in gravitational acceleration will contaminate our results. More to the point, can we measure acceleration due ONLY to the action of the muscles, and not due to changing gravitational forces with any of your accelerometers?
If a 3-axis accelerometer is rotating about an axis parallel to the ground, wouldn't the axis perpendicular to the ground pick up a sinusoidally varying (i.e. not DC) gravitational acceleration?
None of the accelerometers can separate the linear acceleration from the gravitational acceleration. This is achieved by sensor fusion, you merge the accelerometer and gyro readings in a clever way.
I developed a motion sensing applicaton to track human motion (elbow flexion). I am sure something similar would work fine for you.
My advice is to use orientation in your application (rotation matrices).
If you have to implement the sensor fusion yourself then the Direction Cosine Matrix IMU: Theory manuscript is a good place to start.
Now that iOS 4 is no longer NDA, I would like to know what Gyroscope has to offer over the Accelerometer for developers. Is there a difference in APIs? Other things?
Actually, the accelerometer measures linear acceleration; but since force is equal to mass times acceleration, people can consider it as measuring force as well as long as it has a constant mass. Linear acceleration is the rate of change of linear velocity. A gyro on the other hand provides the angular rotational velocity measurement as oppose to the linear acceleration of movement. Both sensors measures the rate of change; they just measure the rate of change for different things.
Technically, it is possible for a linear accelerometer to measure rotational velocity. This is due to the centrifugal force the device generates when it is rotating. The centrifugal force is directly related to its rotational speed. As a matter of fact, many MEMS gyro sensors actually uses linear accelerometers to determine the rotational speed by carefully placing them in certain orientations and measuring the centrifugal forces to compute the actual rotational gyro speed.
A MEMs gyroscope is a rate of change device. As the device rotates in any its axis, you can see a change in rotation. An accelerometer only provides the force along the X,Y,and Z vectors, and cannot solve for "twist". By using both sensors, you can often implement what is referred to as a 6DOF (degrees of freedom) inertial system - or dead reckoning - allowing you to find the relative physical location of the device. (Note that all inertial systems drift, so its not stable in the long term).
In short: gyroscopes measure rotation, accelerometers measure translation.
There is a new API for reading the gyroscope.