I want to measure distance travelled in a moving car from an android app. The distance is typically between (0-60 metres). How can I calculate the distance using sensors on an android device.Thanks.
Your best bet is GPS. Get the location of the start and finish and use Location.distanceTo.
If you mean you want to try and calculate when you start and stop as well- I'd look for a siginificant acceleration event and correlate with GPS position at those times.
If you mean you want to not use GPS at all- give up now. The sensors are far too noisy to try and solve using acceleration equations.
You could (try) to integrate accelerometer values, but as Gabe Sechan said, it'll be mostly hopeless. If you spend some time analyzing your accelerometer and calibrating it manually (by this I mean compensating by your measured bias and scaling errors) you can reduce the error, but you're still stuck with a (significant) growing error that gets worse quicker over time.
As a side note, if you're constantly turning (say, in a spiral ramp), you can get the velocity directly from a combination of gyroscope and accelerometer (basically combining equations of centripetal motion "a = v^2 / r" and angular velocity "v = w * r" to get "v^2 = a^2 / w^2"). I've tried doing this with an Android device, and as long as the angular velocity "w" is high enough, the values returned are very consistent and fairly accurate (and the error doesn't grow exponentially with time as when integrating acceleration data twice).
Related
I understand that there are three approaches for it
GPS Based: Add up short distances travelled (calculated using Location.distanceTo) in small time intervals (5-10 secs), but this method is prone to GPS errors and would not work indoors or in short running area (like a small park)
Double Integration of acceleration: I can do double integral of accelerometer data to calculate distance but errors due to noise in accelerometer readings may add up.
Step counting: I can detect steps by measuring spikes in accelerometer data OR using Google Fit API and then multiply the total number of steps with the average stride length. But the problem here is figuring out average stride length.
I am inclined towards using #3 as it works indoors and is not much error prone OR battery draining. But How do I get average stride length for each step, especially when runner's stride varies in length when sprinting and jogging.
Does anyone know of any combination of these methods to get the best results? OR any other totally different but efficient method?
Well it's engineering - there is no simple answer ;)
All these methods you've mentioned has their pros and cons.
GPS tracking won't sumarize errors of each measurement - it's great but on the other hand each location will be given with noticeable error. What is more you'll have problems with using your app in buildings etc.
Double integration of acceleration works great on small distances by the time error grow to big number. It is also difficult to create program which will calculate it in appropriate way. There is a lot of important issues like e.g time of sampling or rotation and translation matrix calculation that makes these application very problematic on android.
In my app I used following algorytm:
Calculate location from GPS (from Network provider or GPS provider - best precision wins)
Start using accelerometer-based algorytm.
Stop using accelerometer-based algorytm when:
GPS and accelerometer measurements are very different
Accelerometer-based algorythm finds that calculated quaternions are different from what magnetometer says.
The velocity or acceleration from measurments is bigger than given value.
Go to point 1
Hope it helps
I am trying to implement a fitness app that can keep track of the running speed and running distance in Android.
It looks like I can either use GPS or Accelerometer to calculate these information.
Since a runner may put his phone in hand, on the shoulder or in his pocket, my first intuition is to use GPS to get locations and calculate running speed and running distance. But recently someone telled me that I can also use Accelerometer also does that.
My question is: In Android, which approach is better to calculate running speed and running distance, GPS or Accelerometer?
I suspect that pedometers are based on accelerometers because accelerometers are cheaper than GPS to use. in fact I think a lot of pedometers don't even try to measure distance. just acceleration jolts which equal steps. and then if they give you a distance measurement, it's by multiplying detected steps by a guessed or average step size.
GPS (if you are in an area where it works!) will do a very good measurement of distance. Even with a very cheap GPS receiver. All being basically OK, you should expect start and end positions to within 10m, and so for a 1km travel, you have 20m of uncertianty, which is 2% total distance uncertianty. This uncertianty goes down linearly with distance travelled (ie a 2km run will have 1% uncertianty, 4 km run will have 0.5% uncertianty, etc) the issues here will be with your realtime displays (GPS position jumps from satellite switching giving massive speed values, or immediate loss of signal giving a loss of all immediately displayable data)
I think that with a good accelerometer, starting from stopped you can continually integrate the signal to get speed, and continually integrate that result to get distance... I am just unsure what kind of accelerometer quality you get in any given phone? you may need to filter for noise or even garbage data.. And you also need to consider what accuracy it has. 20% accuracy in your sensor would make for a very bad distance tracker. So you might have to work with step counting and step size guesstimates.
perhaps a combination of both could work?
I'd be tempted to use the accelerometer data (either integrating or step counting depending on what will always work) to track speed and distance in short timeframe, then with much longer timeframe, generalised GPS data could be used to correct or scale that data from the accelerometer. Especially if you filtered/blocked GPS data based on uncertianty measurement at any given time.
Adding to what Julian said ... Normally GPS doesn't work under the roofs therefore for indoor gyms it will not work. Theoretically GPS signals are not bothered by clouds but when I was working on my GPS application, I had experience of unavailability of GPS signals in really bad weather (this might not be your case as no one will go on jogging in thunder storm :D)
Agreeing with Julian, you should use both GPS and accelerometer to build a reliable app for every condition.
The best results are obtained by using both of them, through sensor fusion. See:
Android accelerometer accuracy (Inertial navigation)
You will have accuracy problems if you just use either the GPS or a pedometer algorithm.
All pedometers I know are based on accelerometers. I guess, GPS is not precise enough for this stuff. It may say "no motion" while you did some steps, it's also dependent on the area you are trying to use it.
How can I get an accurate speed from GPS in Android?
Yes, I am aware of the location.getSpeed() method in the Location class. Problem is, the default implementation returns 0.0 as speed: apparently that is the default behavior.
What I'm currently doing, is as follows, consider location objects a and b, where a is taken first, b later:
a.distanceTo(b)/(b.getTime()-a.getTime());
(simplified for readability, original code deals with history ArrayList)
Problem is that this is somewhat inaccurate: under normal circumstances, the data points are so close to one another that the GPS inaccuracy really becomes an issue. Either I would need to reduce the update frequency or calculate the speed relative to a point further away. The former I don't want to do, as I want to get as high a frequency as possible, but perhaps I could filter the points to calculate speed against based on their distance to one another?
The optimal solution, which I assumed the getSpeed() method would do, would be to calculate the speed against the GPS satellites themselves, thus getting a more accurate result.
Am I using the getSpeed() wrong somehow?
Since your keeping a history why not...
Get the current location and time
Find the speed between current and last ~10
Take an average of your results
Use the formula you stated to determine average speed but makes sure your two points are in a straight line. You could see if the user is still traveling in the same direction by calling Location.getBearing(). If it is close enough you could assume they traveled in a straight line. If not just discard the result.
Keep in mind this speed will be affected by any stops such as stop signs or stop lights. Sample as often as possible and discard any obvious outliers.
The emulator apparently always answers 0 as speed, but the real device
should not. Do you have the same issue on the real device? – Stefan
Mar 20 at 8:21
Stefan's answer was actually correct. Apparently the emulator does not give the speed, as that's not contained in the GPX file input as the testing data. So if you want to show speed, test on a real device and go for a jog, it'll work (for most devices).
Below are some thoughts for other methods of detecting speed, but not strictly relevant, but might be interesting if you're working with GPS.
Due to the relative inaccuracy of GPS, particularly at slow speeds or curvy roads the speed is hard to calculate: either the distance between data points is so short GPS inaccuracy comes to play, or so long it becomes inaccurate when not moving straight. Also, if the minimum distance between data points to calculate speed is long, at slow speeds the update interval becomes a problem.
There are ways around this problem, such as using the getAccuracy() method to calculate minimum safe distance between data points and using it dynamically, filtering data points based on maximum acceleration and deceleration values, movement direction and so on. You can also calculate a rolling average to calm down the changes a little and get a pretty good idea of what's what.
The above methods may be useful also even if you don't calculate speed based on distance covered, as sometimes the GPS seems to return speed as 0, even when you're moving. I used acceleration/deceleration figures from F1 cars as filters :)
this is another question about indoor tracking using inertial (smartphone + aceel + gyro)
Firstly, I would like to say that I have read almost every post on stackoverflow talking about this subject.
And I know that to track a position We will have to integrate TWICE the accel and that is very useless in a real life application because of all the drift errors...
But it turned out that I don't need to build a plane or whatever And i don't need to develop an application that have to WORK to be sold or something. I just want to realize a simple Android App that use "theoretical" concept of an Indoor tracking-
What's the possibilities?
What do we need?
Basically my phone is resting on a desk screen facing UP at a known position (0,0) if a push my phone to 2 or 3 meters and then I rotate it and push it again for 2 or 3
meters I the to see after how many meters it becomes to inaccurate an so use a tag tu recalibrate the measurements <--- That's my main question
what do I need ?
- the angle ? (ok integrating the the gyro) (i don't wanna use the compass)
- the accel? (i have)
- the velocity ? (integrating the accel)
- and the position (double accel integration)
The thing that I would like to know is How can I put this number together? Is it the right way to do it? Is there another solution (to resolve my problem, not to track someone really accurately)?
I also looked at the theory of the DCM (If I understood correctly, it will give me the orientation of the phone in 6 axes right? But what's the difference about getting the angle from the Accel or the gyro (pitch, roll etc..) ?
Thank you
Your smartphone probably has a 3-axis gyro, a 3-axis magnetometer and a 3-axis accelerometer. This is enough for a good estimation of attitude. Each has its advantages and disadvantages:
The accelerometers can measure the gravity force, it gives you the attitude of your phone, but in a horizontal position, you can't know where it's pointing. And it's very sensitive to inertial noise.
The gyroscopes are fastest and the most accurate, but its problem is the drift.
The magnetometers don't have drift and they aren't sensitive to inertial forces, but are too slow.
The combination of the three give you all advantages and no disadvantages. You must read the gyro measure faster as you can (this minimizes the drift) and then use the slow and not as accurate measure of magnetometer and accelerometer to correct them.
I leave you some links that may interest you:
A Guide to using IMU: http://www.starlino.com/imu_guide.html
DCM tutorial: http://www.starlino.com/dcm_tutorial.html
I hope I've been helpful and sorry for my bad English.
With the sensors you have, not considering computational power at this point yet, I know of only one method of position / displacement estimation. This would either involve just optical flow with the onboard camera, or the above with addidional info from fused data from accels / gyros (eg. with a Kalman-Filter) to improve accuracy. I guess OpenCV has all you need (including support for Android), so I'd start there.
Start by implementing an attitude-estimator with just accels and gyros. This will drift in yaw-axis (ie. the axis perpendicular to the ground, or rather parallel to gravity vector). This can be done with a Kalman-Filter or other algorithms. This won't be any good for position estimation, as the estimated position will drift tenths of meters away in just a couple of seconds.
Then try implementing optical flow with your camera, which is computationally expensive. Actually this alone could be a solution, but with less accuracy than with additional data from an IMU.
Good luck.
EDIT: I recently found this - it may be helpful to you. If there is not a lot of noise (due to vibration), this would work (I'm on a quadrotor UAV and it unfortunately doesn't work for me).
Is it possible to use the accelerometer to detect height? For instance, if I'm holding the phone on my hand and then detect the height after raising my arm?
Thanks
Assuming you mean you want to detect the height the phone was raised from its staring point, yes. The android accelerometer measures force, more info on how to use it can be found here. Keep in mind that the accelerometer isn't a perfect device, and so your results will be approximations of how much the phone was really moved.
The inaccuracy of the accelerometer will be insignificant when compared to the error caused by an unstable accelerometer. What I mean by this is the fact that as you move your phone you will not be able to keep the accelerometer orientated perfectly i.e. you will 'naturally' rotate it about its longitudinal,lateral and azimuth axes. This means that a vertical acceleration will partly be felt in all the above axes and result in an error if you were to just integrate twice the vertical acceleration measurement.
There are ways to eliminate this error which involve gyroscopes but that requires some complicated mathematics and gyros to be fitted in your phone as well.
In theory you can integrate an accelerometer's output but in a real-world device there are practical issues you must overcome.
You get position by integrating the linear acceleration twice but the error is horrible. It is useless in practice.
Here is an explanation why (Google Tech Talk) at 23:20. I highly recommend this video.
Similar questions:
track small movements of iphone with no GPS
What is the real world accuracy of phone accelerometers when used for positioning?
how to calculate phone's movement in the vertical direction from rest?
iOS: Movement Precision in 3D Space
How to use Accelerometer to measure distance for Android Application Development
How can I find distance traveled with a gyroscope and accelerometer?
Distance moved by Accelerometer
Yes, bt you need to integrate the output twice and add in the two integration constants - initial velocity and displacement.
Rgds,
Martin
First of all you measure Linear acceleration and gravity together (also some noise)
So it means when you are using accelerometer you will get
Accelerometer Readings = Linear Acc. + Gravity + Noise
Here you just only need Linear Acc. but the Accelerometer reads all the values