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.
Related
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.
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 :)
I would like to find the position of an Android device with respect to a fixed point in space.
I need a precision close to one or two meters.
My goal is to determine the position of the android device user inside a building (a museum), to detect the floor and the room she is in, and - if possible - even a more precise position in the room (to know which painting she is close to).
I did already excluded to use GPS, since it is not so precise (expecially with respect to elevation), it only reliably works outdoors, it quickly consumes battery power, and it doesn't return the location quickly.
I did already excluded to use Network Location Provider too, since it is even less accurate.
In Android you have three possibilities to detect the location of a Android phone:
1) GPS
2) Network
3) Triangulation
But none of these three possibilities is suited for you're problem. The GPS is the most accurate one, but as you already noticed it is not working in buildings, and it won't be able to differentiate between different floors. The problem is that the accuracy of GPS is at best 3 or 4 meters. The other two possibilities are far less accurate. That's why there isn't a real solution for your problem.
One thing that might be a possibility is the motion sensor. If you know where the user starts, you maybe can use the motion sensor to calculate how many meters the user moves. But I don't think that this is accurate enough.
I have here a device which can give me GPS coordinates. The time interval I can define. I want to use it to calculate the average speed during driving or travelling by car. Actually I used a orthodrome formula to calculate the distance between two points and then divided it by the given time interval. By the implementation I followed this term. Unfortunately I could only find a German link, but I think the formula should be understandable in any language ;)
Unfortunately, using this formula and a time interval of 1 second gives very unprecise results. The speed while walking is between 1 km/h and 20 km/h.
So I wonder if there is a general reference on how to implement distance calculation between two GPS coordinates (I found something similar on SO) and particulary, which is the best time interval to update the GPS coordinates?
I assume that you're testing this by walking at a constant speed (I think ~5 kph is a normal walking speed) while measuring your GPS position once per second.
The variation that you're seeing in instantaneous speed (the distance between each measured point divided by 1 second) is either due to random variation in the measured GPS position or else you aren't taking your measurements exactly one second apart (or it could be both of these things).
I'm going to assume your measurements are being taken precisely one second apart. Hand-held GPS devices are much less accurate than advertised. While it's often claimed that the devices are accurate to within 10 ft. of the true position, this simply isn't so.
The best way to measure and report the accuracy of a GPS device is to leave it in a place where it can see the satellites and not be rained on, and record a few day's worth of data. You can then use Google Maps to plot the points - I've done this around my house and around the office, which is a good way to give you a sense of scale.
Obviously, if the devices were perfectly accurate, you would see all your measured points in one spot. Or, if the 10 ft. accuracy thing were true, you would see all the points in a little cluster inside a 20 ft. diameter circle.
What you see instead (with every GPS-enabled device I've ever tested) is a combination of relatively small positional scattering (on the order of a few tens of feet) occurring on a scale of a few seconds, and a longer-term "random walk" of the average position which might move 200 or 300 ft. in the course of a day or two. When plotted over your own house, for example, it might look like your PDA wandered over to the neighbor's house, then across the street, then down the street two houses, back towards you etc., all while jittering around 5 or 10 feet here or there like it drank too much coffee.
GPS can be more accurate than this. Surveyors use devices with much more powerful receiver sets (so they get a much more accurate read on the satellite signals), and they leave them in place for days at a time to average successive measurements. Handheld devices have cheap receiver chips and cheap antennas and have to deal with all kinds of signal interference anyway.
Your best bet is to do a running average to calculate your instantaneous speed. Instead of dividing the distance between the current point and the previous point by 1 second, take the last 5 distances between points and divide by 5 seconds (or whatever number of seconds you use). It's important not to just take the difference between the current point and the point 5 seconds ago and divide this distance by 5, as that would miss any non-linear movement.
Update: I noticed in a comment that you're using an Android device. Do you know if it has a built-in GPS receiver? Many (most?) Android devices don't, which means their GPS is not the triangulate-on-the-satellites version of GPS, but the guess-where-I-am-based-on-the-signal-from-the-cell-towers version. This is much less accurate positionally, as I'm sure you could tell from the snarkiness of my description. :)
GPS systems can yield instantaneous velocity directly, without interpolating positions. I read somewhere that the velocity reading is actually more accurate than the position reading. What device/system/OS are you using?
On Android, try the android.location.Location.getSpeed() method (along with hasSpeed()) in your LocationListener implementation.
Search on google for GPS SPEED ACCURACY, and you will find reports stating that speed calculated out of position-vs-time is ten times worse than just using the speed parameter coming right out from the GPS receiver. The speed parameter is not depending on position accuracy, but is calculated out of doppler (speed/frequency difference) from the satellite signals.
Good luck