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
Related
I'm developing iOS/Android app that tracks mileage user has driven in his car.
Even though the task seems pretty trivial, there are 2 problems:
1) Mileage is not accurate comparing to car's odometer. (OD-10mi, App-8.5mi)
2) When user stays still outside the car, mileage keeps accumulating (it can add up like 4mi within 30 minutes.)
Is there any "easy" fix for that without adding complicated filtering, etc?
There are two small but significant things you can do:
For each GPS sample, check its accuracy. If it's over some threshold (say 20 meters) - ignore it.
Add a method that detects if the mobile is static or not. You can do it by reading the device's accelerometer - if the delta between two readings is bigger than some threshold - the car is moving. If it's too small - ignore the GPS. You'll have to try some values until you find the right threshold/
For question 1, vehicle odometer, in the US, are only required to be within 5mph of the actual speed at 50mph. My experience shows most vehicles are more erroneous than the law requires. That 10% difference could easily become the 1.5 miles you saw.
Vehicles odometers are allowed to over estimate in europe by 7%.
My car has about 3% over estimate.
There are simple solutions, that work for cars, that have been posted here on Stackoverflow multiple times, including by myself.
There is no simple solution for pedestrians.
Answer to question 2: problem certainly comes from the accurary of the GPS location.
Android Location object comes with an estimated accuracy for the given coordinates.
Suppose you stay in absolute position (0,0) without moving. The android device GPS could produce the following Locations stream:
(1,1) with an accuracy of 2m
(-2,3) with an accuracy of 5m
(0,0) with an accuracy of 1m
etc...
If you just keep adding the distances between the successive Locations, the sum will indefinitely increase, although you don't move.
One solution could be that you take into account new Locations from the stream only if their accuracy is small enough compared to the distance to the last location.
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).
I am working on app in which I have to calculate the total distance from start point to end point. I use the Location Manager of the Android SDK, use location listener and use both provider(GPS and network provider) and in every 20 seconds I have track the location and put the tracked location into the array list. After a time period calculate the total distance by
total distance = dist at point[0,1]+ dist at point[1,2] + ... +dist at point[n-1,n]
where 0,1,2,...,n is the index of array list location value.
After several test, Not got the accurate result. Approximately 60-70% of actual odometer value. Please guide if have some other alternative to be used.
Please guide me how I got more accurate result.
GPS and network location both have a degree of uncertainty associated with them, so neither will generally give you an exact distance when compared to something like an odometer. If you're outdoors and not in urban canyons, GPS will generally give you a better distance estimate than network location.
Underestimates of distance (what you're seeing) is probably due to your sampling rate (every 20 secs) or lost GPS signals. I'd try increasing your sampling rate to once every 4 seconds or so, and make sure your GPS unit isn't losing a fix. GPS sensitivity can vary widely across devices, so try to test with a few different Android devices. You can also check out an Android app I developed to help measure GPS accuracy on Android devices:
http://www.gpsbenchmark.com/
Overestimates of distance are generally caused by GPS noise, or the position bouncing around due to small (and sometimes large) GPS position error. Kalman filters are a good way to reduce the impact of some of this noise. You can also try to filter the path and reduce some of the detail via line simplification. An implementation of the Douglas-Peucker algorithm to do this is available under Apache 2.0 in the MyTracks project:
http://code.google.com/p/mytracks/source/browse/MyTracks/src/com/google/android/apps/mytracks/util/LocationUtils.java#78
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.
I am working on an application where I would like to track the position of a mobile user inside a building where GPS is unavailable. The user starts at a well known fixed location (accurate to within 5 centimeters), at which point the accelerometer in the phone is to be activated to track any further movements with respect to that fixed location. My question is, in current generation smart phones (iphones, android phones, etc), how accurately can one expect to be able to track somebodies position based on the accelerometer these phones generally come equip with?
Specific examples would be good, such as "If I move 50 meters X from the starting point, 35 meters Y from the starting point and 5 meters Z from the starting point, I can expect my location to be approximated to within +/- 80 centimeters on most current smart phones", or whatever.
I have only a superficial understanding of techniques like Kalman filters to correct for drift, though if such techniques are relevant to my application and someone wants to describe the quality of the corrections I might get from such techniques, that would be a plus.
If you integrate the accelerometer values twice you get position but the error is horrible. It is useless in practice.
Here is an explanation why (Google Tech Talk) at 23:20.
I answered a similar question.
I don't know if this thread is still open or even if you are still attempting this approach, but I could at least give an input into this, considering I tried the same thing.
As Ali said.... it's horrible! the smallest measurement error in accelerometers turn out to be rediculess after double integration. And due to constant increase and decrease in acceleration while walking (with each foot step in fact), this error quickly accumulates over time.
Sorry for the bad news. I also didn't want to believe it, till trying it self... filtering out unwanted measurements also doesn't work.
I have another approach possibly plausible, if you're interested in proceeding with your project. (approach which I followed for my thesis for my computer engineering degree)... through image processing!
You basically follow the theory for optical mice. Optical flow, or as called by a view, Ego-Motion. The image processing algorithms implemented in Androids NDK. Even implemented OpenCV through the NDK to simplify algorithms. You convert images to grayscale (compensating for different light entensities), then implement thresholding, image enhancement, on the images (to compensate for images getting blurred while walking), then corner detection (increase accuracy for total result estimations), then template matching which does the actual comparing between image frames and estimates actual displacement in amount of pixels.
You then go through trial and error to estimate which amount of pixels represents which distance, and multiply with that value to convert pixel displacement into actual displacement. This works up till a certain movement speed though, the real problem being camera images still getting too blurred for accurate comparisons due to walking. This can be improved by setting camera shutterspeeds, or ISO (I'm still playing around with this).
So hope this helps... otherwise google for Egomotion for real-time applications. Eventually you'll get the right stuff and figure out the jibberish I just explained to you.
enjoy :)
The optical approach is good, but OpenCV provides a few feature transforms. You then feature match (OpenCV provides this).
Without having a second point of reference (2 cameras) you can't reconstruct where you are directly because of depth. At best you can estimate a depth per point, assume a motion, score the assumption based on a few frames and re-guess at each depth and motion till it makes sense. Which isn't that hard to code but it isn't stable, small motions of things in the scene screw it up. I tried :)
With a second camera though, it's not that hard at all. But cell phones don't have them.
Typical phone accelerometer chips resolve +/- 2g # 12 bits providing 1024 bits over full range or 0.0643 ft/sec^2 lsb. The rate of sampling depends on clock speeds and overall configuration. Typical rates enable between one and 400 samples per second, with faster rates offering lower accuracy. Unless you mount the phone on a snail, displacement measurement likely will not work for you. You might consider using optical distance measurement instead of a phone accelerometer. Check out Panasonic device EKMB1191111.