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
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 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 hope I'm asking this at the right part of Stack Exchange. Please bear with me if I'm wrong.
I'm developing some gps based applications. The demands I have for precision are not very high, but I need to know the possible errors.
I have learned that the fourth decimal gives you ~10 meters precision. That should be enough for me.
The real question is how fast will I get that precision realiably in different environments (indoors, outdoors free sky, forest, cloudy, city etc).
The applications I'm developing is for handheld devices so I prefer to have the gps active in as short intervals as possible.
As I do now, the intervals I use the gps are more governed by battery life than precision. Now I'm trying to balance the two.
if you have good view (no major obstructions like high buildings) to sky, with A-GPS 20s, normal GPS 30-45 seconds.
If you have bad view, it can take much longer.
However you better check that the timestamp of the location is a recent one, (time diff to current time is small) and that horicontal accuracy (Location.getAccuracy()) is not horrible:
check for < 20m, if you check for 10m you may loose many positions especially in the first minute.
You shouldn't wait for some number of seconds and assume that that's enough to get a GPS fix. Instead, when you get locations from location manager, check the result of Location.getAccuracy() and wait until that returns a number less than 10 meters.
I have been developing location tracking apps and testing them mostly on my HTC G1 running Android 1.6. I find that there are certain time intervals -- of approximately 1-2 hours -- when the recorded GPS locations become very erratic: I end up with what looks like a random distribution of points around my actual location, but instead of being clustered tightly within a 10-50 meter circle as they normally are (I use a minimum accuracy for recording these locations), they are spread out with a radius of something like 1-5 km -- even though each of these locations comes in with a reported accuracy of under 50 meters.
It's as if the actual location accuracy balloons during these periods but the reported accuracy remains the same. This is relatively infrequent and when it occurs it lasts only for a few hours, after which everything appears normal again. Because it is so infrequent, and because I am usually also in the process of tinkering with the app, I am having a hard time ruling out the possibility that this is caused by a bug in my code.
Has anyone else experienced this? Are there known hardware or firmware issues that could be causing it? If so, does anyone have a good way of detecting the problem when it is occurring and correcting the reported accuracy values? I assume one option would be to rely on the NMEA sentences, but I would like to be able to run the app on Android API level 4 and I see that GpsStatus.NmeaListener requires 5 or above.
I would really appreciate any suggestions.
1-5km deviance should never happen in GPS receivers.
If that happens then it looks like an alternate location service is active, like cell tower location, and wifi location.
If you want a precise position you should filter out all non GPS ones.
GPS positions can be detected that they have a speed and heading (bearing) assigned when the device moves. (I am not sure if the check for an altitude helps)
The line patterns comes from the situation when a new GPS sattelite comes into the view, and other(s) are going ou of view. The new situation can be worse from the geometric sattelite constellation. This new constellation can also called so called Multi-Path Effects (Reflections of the GPS Signal at the opposite building)
And I hope that you don't do you measurements indoors, (where GPS does not work reliably)
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.