After reading many researches and papers beside to many forums about how to measure the distance based on the acceleration data
I found the double integration method, but the error related to this method is big and increases by time.
In addition I found some people who suggested Kalman filter I read some references about it but it was not clear to me how to use it.
also some were talking about the fusion sensors ... but after reading them I did not get any new ideas.
so I am still confused and I did not find the right answer to follow ....
sorry for this long introduction.
Question
Let us consider that I hold 9-axis sensor in my hand and I move my hand in some direction, how I can find the new position of my hand in the space? how to obtain motion vector from the initial point to the new point I mean how to know the passed distances on three axes?
If there is no direct answer ... some advises or references would be great or some algorithms that give an accurate answers and I can study and use it by myself.
thank you very much
The short answer to your question is you can't do it.
The double integration method is really the only way to get the information you are looking for using only an accelerometer. You found the problem with this method. The error increases over time and generally doesn't give the accuracy many are looking for.
Kalman filtering usually requires 2 devices and basically takes the best of both devices and filters out the bad. See example below.
Kalman filtering is a really tough subject that I tried to dive into for senior design, but never found any meaningful results with my limited testing. A great place to start understanding this subject is with this youtube video series .
This is the guy that won the DARPA challenge with Stanford and explains the topic in an easy to understand way. The whole course is a 6 unit video series about programming robots to move and understand their location in an unknown environment. Worth a watch if you have the time and interest.
It sounds like you're trying to do something similar to what I did for senior design in give really specific relative location information.
Another great Kalman filtering read this (if this link doesn't work google Kalman filter balance bot and click the TKJ blog link). Basically this guy uses an accelerometer and gyroscope to track orientation in the real world.
Something else to look into wiki Real Time Kinematic. This goes on tractors and combines to provide really accurate location information. John Deere sells a system, but it's like $20,000. Here is the poor man's version using GPS and beagleboard
By a 9-Axis sensor I am assuming that means:
3-axis gyro (measures rotational rate)
3-axis accelerometer (measures acceleration)
3-axis magnetometer (measures heading)
Getting a practical position estimate from this type of 9-axis sensor is not possible without the use of another sensor that uses an external reference such as GPS.
Theoretically, if you know the accelerations of an object in space and its initial position and velocity you will be able to calculate the objects new position by propagating the information about its acceleration and velocity back on to the initial position (i.e. integrating the acceleration twice). The reason that it is not possible in practice is that the accelerometer has noise. This noise will have a non-zero mean, so when integrating the acceleration signal the non-zero mean noise is continuously added and accumulates in the resulting velocity signal. This is seen as sensor drift. The velocity estimate starts out fairly correct but quickly drifts off due to this accumulated noise. Integrating a second time to get the position only worsens the situation by repeating the process.
By using an external reference such as a GPS, the Kalman filter can be used to combine the slow-updating GPS signal, and the fast-updating acceleration signal together to produce a reliable estimate of the position. The GPS has the effect of zeroing the drift that would be accumulated by performing the integration on the acceleration signal.
I would suggest taking a look at the Udacity Youtube videos that Khamey suggested. When learning the Kalman filter it helps to get a clear general overview of what the objective is and what the kalman filter is doing. Then the math and the actual steps of the algorithm will be much easier to understand. Another thing that is helpful when learning the Kalman filter is doing it for one state variable at a time instead of a whole state vector. This just helps focus your attention on what the Kalman filter is actually doing so that you don't get bogged down by the matrix algebra.
Without considering the rotation:
Let's consider that at time t=t0 you are at position [ x0 , y0 , z0 ] and a velocity vector of [ vx0 , vy0 , vz0 ].
At t=t1 you read an acceleration vector of [ ax1 , ay1 , az1 ] (The average acceleration from t0 and t1).
Then, the velocity vector at t=t1 will be:
[ vx1 , vy1 , vz1 ] = [ vx0 + ax1 * (t1 - t0) , vy0 + ay1 * (t1 - t0) , vz0 + az1 * (t1 - t0) ]
The average speed between t0 and t1 will be
[ vx01 , vy01 , vz01 ] = [ (vx0 + vx1) / 2 , (vy0 + vy1) / 2 , (vz0 + vz1) / 2 ]
And the position at t=t1 will be:
[ x1 , y1 , z1 ] = [x0 + vx01 * (t1 - t0), y0 + vy01 * (t1 - t0), y0 + vy01 * (t1 - t0) ]
As you can see, the error propagates with t^2, so that's why the inertial systems need to be compensated by an external reference like a GPS.
If there is a base map and you are assured that the sensor is traveling along a known path (such as a road), you can use the base map to correct noisy readings. See Jun Han, Emmanuel Owusu, Thanh-Le Nguyen, Adrian Perrig, and Joy Zhang "ACComplice: Location Inference using Accelerometers on Smartphones" In Proceedings of the 4th International Conference on Communication Systems and Networks (COMSNETS 2012), Bangalore, India, January 3-7, 2012.
http://www.netsec.ethz.ch/publications/papers/han_ACComplice_comsnets12.pdf
Related
I am currently working on a mission to fuse GNSS and IMU for a more accurate navigation system for autonomous vehicles. I am very familiar with using GNSS to get the accurate position, however I'm a newbie in using IMU sensor. I've read several kinds of literature but am still confused about which better way should I do to remove bias from the accelerometer and gyroscope measurement.
I have 2 kinds of raw measurement data using MPU-9250, they are acceleration data (m/s2) in the x,y, z-axis and angular velocity data (deg/s) also in the x,y, z-axis. I have tried to input these data into my sensor fusion program. Unfortunately, I got unsatisfied with accuracy.. Hence I think firstly I should correcting (removing bias) of raw data IMU, and then the corrected IMU data can be input to my fusion program.
I couldn't find an answer that my brain could understand or fit my situation. Can someone please share some information about this? Can I use a high-pass filter or a low-pass filter in this situation?
I would really appreciate if there is someone could explain in detail to me without using complex math formulas/symbols, I'm not a mathematician and this is one of my problems when looking for information.
Thank you in advance
Accelerometer and Gyroscope have substantial bias usually. You could break the bias down to factors like,
Constant bias
Bias induced by temperature variation.
Bias instability
The static part of bias is easy to subtract out. If the unit starts from level orientation and without any movement, you could take samples for ~1s, average it and subtract it from your readings. Although, this step removes a big chuck of bias, it cannot still fully remove it (due to level not being perfect).
In case you observe that the temperature of IMU die varies during operation (even 5-10 deg matters), note down the bias and temperature (MPU9250 has an inbuilt temperature sensor). Fit a linear or quadratic curve that captures bias against temperature. Later on, use the temperature reading to estimate bias and subtract it out.
Even after implementing 1 and 2, there will still be some stubborn bias left. If the same is used in a fusion algorithm like Kalman filter (that is not formulated to estimate bias, the resulting position and orientation estimates will be biased too).
Bias can be estimated along with important states (like position) using some external reference/sensor like GNSS, Camera.
Complementary filter (low pass + high pass) or a Kalman filter can be formulated for this purpose.
Kalman filter approach:
Good amount of intuition along with some mathematics is needed to use this approach. Basically the work involves formulating prediction & measurement model and then provide rough noise variances for your measurements and prediction. An important thing to understand is that, Kalman filter assumes that the errors follow normal distribution without any bias. So the formulation should deliberately put bias terms as unknown states that should be estimated too (Do not assume that the sensor is bias free in the formulation)..
You could checkout my other answer to gain a detailed understanding of this approach.
Complementary filter approach
Complementary filter is simpler for simpler problems :P
The idea is that we use low pass filter on noisy measurement and high pass filter on biased measurement. Then add them up and call it a day.
Make sure that both the LPF and HPF are complements of each other (Transfer function of HPF should be 1-LPF). Typically first order filters with same time constants are used. Additionally the filter equations have to be converted from continuous laplace domain to discrete form (Read about ZOH, Tustins approximation...).
The final form is scattered around the internet too.
Personally I would use a Kalman filter for this purpose, but complementary filter can be used with same amount of effort. You could do this,
Assume that the body is not accelerating on average in long term (1-10 s or so). Then you could say that the accelerometer measures the direction of gravity in long term relative to the IMU. Then arctan(accy, accz) can be used to obtain an estimate of pitch and roll. But this pitch and roll readings will suffer from substantial noise. Implement a low pass filter on it with time constant ~5 seconds or so. Additionally add the latest pitch/roll with dt*transformationMatrix*gyroscope to get another pitch and roll. But these suffer from bias. Implement a HPF over gyro based Pitch and Roll. Add them together to get Pitch and Roll. Lets call these IMU_PR.
Now forget our original acceleration assumption. accelerometer gives specific force (which is net acceleration - gravity). Since we have Pitch and Roll angles (IMU_PR), we know gravities direction. Add gravity to accel readings to get an estimate of acceleration. Apply proper frame conversion to bring this acceleration to same coordinate frame as GPS (you will need an estimate of Yaw to do so. Fuse a magnetometer with gyroscope for this purpose). Then do vel = vel + acc*dt. Integrate it again to get an estimate of position from IMU. But this will drift due to the bias in accelerometer (and pitch, roll). Implement a high pass filter over this position and low pass filter over GPS position to get a final estimate.
I have accelerometer readings of three axis X, Y and z, will be getting data in a frequency of (62 records per second). Could you please suggest me how can I calculate the displacement.
Data in hand:
Accelerometer readings with respect to time.
Do I need to calculate the displacement using time domain data or need to convert into frequency domain. Which one will give a accurate results?
You can double integrate the acceleration vector over time to obtain the displacement. In theory this is a perfectly sensible solution.
But in practice, there will always be a component of g (acceleration due to gravity) acting on at least one of the axes all the time. Let's say you subtract the g component from your xyz vectors. The problem is that any slight error in readings (even off by a small order of magnitude) when double integration will lead to the error adding up over time rendering the displacement wildly inaccurate.
According to the integrated values, you will most likely see even an idle object fly off into space. You'll need an additional sensor to tell you the orientation - like a gyroscope, and have some point of reference (the Wiimote does this with an IR sensor).
This is primarily a time domain problem, but you could have a frequency domain stage where some amount of filtering is done to remove measurement error or process error.
tl;dr Positional tracking with acceleration sensors alone is a hard problem.
Can any one guide me to do an app like this link
i.e How to calculate G-Force,Speed and Distance.
g-force can be calculated as a length of the vector given by accelerometer (Core Motion framework, see CMAccelerometerData for details).
As for distance & speed you can get them from GPS/GLONASS (Core Location framework, see CLLocation class)
Don't try to calculate distance and speed from acceleration - it's impossible to do this reliably.
For example to calculate speed you have to know acceleration of the car. Given Aa is a measurements from accelerometer, car's own acceleration would be Ac = Aa - Ga where Ga is a gravity acceleration vector in car's coordinates. To know this value one can use CoreMotion services (if gyro is present) or apply low-pass filter to extract gravity vector from accelerometer measurements.
Accelerometers used in iDevices are not very precise. Following integration will accumulate measurement errors steadily. Filters and such are second source of errors.
Now we can calculate our speed:
V(T[n]) = Ac[n] * dt[n] + V(T[n-1])
where V(T[n-1]) is the previous speed of the car. To determine first value (V(T[0])) we have to either force user to stop her car (to ensure zero speed, bad) or force her to input this value (unbelievably bad).
Distance is calculated by the same process
S(T[n]) = V(T[n]) * dt[n] + S(T[n-1])
which means already extremely imprecise speed value is now integrated over time. Happy, happy, joy, joy. BTW you can enjoy the results without coding all this - just read user comments for the app mentioned by OP.
I have to find the best approach for tackling a problem for trying to recognize physical movements - with an iPhone in a pocket - like waling, stopping, turning left/right, sitting.
I was thinking on just heuristically find the data corresponding to each action, then to check the incoming values against this data (with a threshold) and see what's happening.
That's a very rough approach, of course, so maybe using something like the Support Vector Machine
methods, but this seems too complicated for the amount of time I have to develop this.
Which approach would you suggest here?
Walking: Do an fft on the gravity direction signal. Measure its frequency response for walking at different speeds and then set a simple threshold.
Stopping: if the average power i.e. total energy in the signal over the last few seconds drops below a certain threshold then you can say the user has stopped.
Turning left,right: Use the gravity vector and the gyroscopes rotation speed vector to determine whether the user is rotating clockwise or counterclockwise
Sitting: This will be very hard to determine but if youre lucky the SVM will find the right pattern.
Each of the above can be given a weighting and then you will have to find a good way to obtain training data to train your SVM. Maybe stream the signals from the phone to a webserver and simultaneously record the users motions by hand.
Your best starting point is Apples Sample code: CoreMotionTeapot
Alternatively you could analyze the GPS signal. This will give you a very good way to determine the users larger scale motion like walking/moving or changing heading etc.
Using just the rotationRate property of Core Motion or Gyroscope is it possible to extract how much radians (or degrees if you like) the device rotated?
I have tried to do a timed sampled of Core Motion data, for example, sampling it 5 times per second so I know that there's 0.2seconds between each reading. Then if I have a rotationRate of 0.5 radians per second from one read to another, in theory I could divide this by 5 and know now much radians the device rotated since the last time.
This seems logical, but the results have nothing to do with reality. Rotating the device 90 degrees will produce results telling me that the device rotated 100 times less than that.
Is it possible to extract how much the device rotated just by looking at rotationRate?
What am I missing?
Need more space than a comment ;-) iOS retrieves all data in radians and if your other calculations are correct, I thought it might be the angle measured in radians.
In general your approach seems to be alright: Take every signal's angle velocity, multiply it with time delta and you will have the angle delta for this timeframe. Then sum all your angles and the result should be the covered distance as angle in radians. Angle phi is the integral of angle velocity omega over the elapsed time and doing numerical integration with the trapezoidal rule (i.e. like described) is OK for gyroscope's data (not for accelerometer).
In general I would recommend to use the timestamp delivered by core motion instead of the defined period (1/5) as recommended by Apple, because device motion data is often delivered in a lower frequency than expected (see What is the official iPhone 4 maximum gyroscope data update frequency and or Push method for core motion and frequency of Accelerometer/Gyroscope Data.
Furthermore you should take a higher frequency to avoid errors in your numerical integration.
[Update from comments section:]
If your are interested in integrating via extended Simpson's Rule I recommend this paper (German only, p. 173 ff.) and An Extension to Newton-Cotes Formulae. Some sample code as extracted snippet taken from an existing project can be found here: DevicePosition.m Note that it might not compile, no warranty, as is, ... you know this from other sites ;-)
A free app displaying sensor input as graphs for iPhone: Sensor Monitor