I'm analyzing GPS data.
My assumption has always been, that the accuracy of the speed variable should be closely related - if not functionally dependent on - the accuracy of the horizontal position and altitude.
However, for the data I've been collecting this is not the case.
Could anyone elaborate on how the accuracies of GPS signals are related with each other?
Background information:
I used smartphones and their built-in GPS-technologies to collect the data. I used both Android (several models) and iOS phones.
I know, that GPS data will always be associated with uncertainty and that the readings are estimations of the position and the accuracy. That being said, in my opinion the estimations would still be related since I don't suppose Apple or Google would add some kind of stochastic noise to their estimation.
Related
we are developing a multiplatform (android and ios) application in react-native, which mainly deals with geolocation data, thus it higly depends on accuracy and precision of the data. For instance, the application accumulates - reads and saves - the user's geolocation data every 5 seconds for ie 10 minutes (lets call it a track). So, during the track, there are about 200 measurements saved. Later on, we perform different computations based on the data accumulated during the track and visualise results to the user.
While on iphone the altitude graph of data measured at physically (nearly) identical alltitude has rather linear/smooth characteristics, on android there tend to be +-5 meters peaks. Lets say we want to measure total meters elevated during the track, thus to compute the sum of differences between succeeding measurements. Now imagine, how much the mentioned imprecision influences the result - there might be 5 meters altitude change every 5 seconds. Although physically your total elevation is +-0 meters, the total elevation computed may differ drastically.
So, to eliminate the errors, for us, there are basically two ways:
to make the measurements more accurate and precise (this is natural)
to perform some sort of approximation and adjust the measurements accordingly (this is hacky)
The first way sounds much better, but we are aware of the specific device's hardware limitation - we simply cannot fix inaccurate hardware with our software. The problem is, even on the same device, other commercial apps (ie Runtastic) perform the measurement "better" (even offline). That makes me think about the second (approximation) way. This way is rather hacky, and although it can lead to good-looking result in many cases, we think (but cannot prove) there is not such a prefrect approximation that will never corrupt the data "too much".
So, our questions are:
What are the techniques to make every altitude measurement as accurate and precise as possible on android? Which tools can be useful to accomplish that and how should we use them to get the best experience? We can think of:
gps altitude
nmea altitude
barometer
online API to get altitude based on latitude and longitude
Is it worth to apply some sort of approximation on the accumulated data? If so, what aspects (or even better ideas) should we take into account? Is this technique common?
Is there any different solution we did not mention?
Thanks in advance!
GPS altitude is the best one. but it depend on the gps chip. There are some with high accurate(High Cost). Most Phone GPS use online to get data also(For get good Hot start)
To Smooth GPS data(Or any other) ,You can use Kalman Filter. It complex and heavy but. it can guarantee the result and avoid misleading data very well.
OR
you can omit misleading packets base on pervious ones (Mean Filter) - Simple, But should be coded preciously
NOTE : I haven't use barometer. I gave my answer without it. Good luck
If you have a barometer then it's accuracy can be a lot better for altitude than you get with a phone quality gps. It's why high end bike computers and gps tracking watches have barometers in them. This is especially true if your interested in relative altitude differences rather than the actual real altitude. To get a good actual altitude with the barometer you need some sensible calibration scheme and be aware of the effects of the weather over time.
Whatever your source of altitude data you should expect to do some form of post processing on the data to get something sensible. What the processing will need to be will depend on your situation and what what you consider important.
For getting the total climb over a track you have 3 cases to consider. The easy case is simple going up or down a single consistent hill, you want to get the correct altitude difference value which is easy to check with a good map. At the other end going along a totally flat route you want to get zero climb again nice and easy to check but not so easy to achieve with typical hardware. In the middle going over undulating terrain is far harder to check although possibly the far more interesting case for the user. Getting this accurate is some form of trade off against the totally flat situation. I have code doing this in my app and with the filtering I have I know that the totally flat will over read a bit clocking up 20-30m climb in an hour. The undulating case will under count by about 1m for each undulation. The single big hill is generally pretty accurate given the known limitation of a barometric type system. Gps only based is nothing like as good. Typically going back to an online lookup approach is more consistent for a gps based system but it depends on the quality of the lookup data and the type of terrain.
I am trying to get the user's speed from their Android device, but which is the most reliable way to do it?
There is the location.getSpeed() function that uses GPS; is this a reliable way to obtain the speed? Should I instead calculate speed manually using GPS coordinates obtained? Or is there another way that I'm missing to accomplish this?
IMO, best current approach on Android is to use Location.getSpeed() along with the Google Services Location API and the fused location provider. Then, reality-check this value against Google Play Services Activity Recognition.
The fused location provider integrates some other on-board sensors to tweak location data, which is better than GPS alone. Then, check the ActivityRecognition.getMostProbableActivity() method. If the DetectedActivity is type STILL, your true speed is probably equal to 0. If its ON_FOOT, it's probably a low speed (e.g., 1 m/s). If its ON_BICYCLE or IN_VEHICLE, you're probably fine relying on the speed output obtained directly from Location.getSpeed(). You'll also want to check the DetectedActivity.getConfidence() value too, and set your own threshold for a confidence level you feed "confident" with :) when relying on these values.
I'd also definitely suggest that you do NOT simply average sequential positions to get an average speed between two position (if you do this, it needs to be an average over a large number of positions). In my benchmarking on mobile devices (see my dissertation here, pages 105-106, and 137-138 especially), I've found instantaneous speed calculated by the GPS subsystem (which is typically based off of the Doppler shift of GPS carrier signals) to be far more accurate than the positions derived from GPS. 95th percentile of speed observed while stationary indoors (using assisted GPS only, no sensor fusion) was 1 m/s on a Sanyo Pro 200 I tested. I was able to filter out a significant number of position outliers using speed data (see page 137-138) in some intelligent energy management techniques I was evaluating. With sensor fusion, and activity recognition to help filter outliers, accuracy should be better than this on a similar device.
Finally, and I can't emphasis this enough, do you own testing on real devices, as many as you can get a hold off, and preferably the most popular models out there. Android has a variety of OEMs putting out devices, which will all have their eccentricities. Your best bet it to create a solution that targets the most popular models, acknowledging that it's unrealistic to get a solution working perfectly on all models.
It seems that the getSpeed() method is not always reliable, especially at low speed and when gps coverage is not optimal.
You can have a look at this question and this one which are both about alternatives for getSpeed().
The android developper page however says that you'll get better performance by using the Google Location API.
So it appears that the choice is depending on the usage of your app: if you target slow displacement in area with poor gps coverage (walking in the wood), use your own implementation. Fast in area with good GPS coverage, use the Google Location API.
The best way for devices that are moving faster than walking speed, is to use directly the location.getSpeed().
For pedestrian, or other slow speed situations, this is not quite easy, maybe it is simply impossible to have a valid slow speed that is valid at the moment.
Some try to evaluate the history and do an averaging, or threshold based approach, this will improve for a specific application / usage.
But the simplest is to design your App to ignore low speeds.
Some links related to speed:
GPS position correction
Smooth GPS data
I'm trying to find a solution for pinpointing indoors, specifically inside big crowded places, like malls for example.
I tried building a simple app that tried to pinpoint the phone using only the Network service or Wifi networks.
Usually when Wifi was on the accuracy got to 40-60 meters, and when the wifi was off and only the network service was used, the accuracy got to 600-1000 meters.
Unfortunately that really is too inaccurate for my needs.
I read that Google have successfully added an accurate solution for indoors navigation ( http://www.engadget.com/2012/01/08/google-maps-indoor-navigation-las-vegas-ces-2012/ ) , so I guess there might be a possible way to achieve a higher accuracy. 5-10 meters accuracy should suffice.
I'd be happy to get any kind of advice!
Thanks!
In highly trafficked public spaces, indoor location solutions tend to be based on WiFi mapping combined with known map information. That approach allows an increase in the accuracy of the location information you will get from your cellular device (over results from testing performed in locations not yet mapped). The actual error rate will depend on how dense and well mapped the WiFi hot spots are, whether they are in stable locations or tend to be moved around, the accuracy of the floor plans, and the effectiveness of the algorithms that integrate the floor plan information (e.g., defining which paths may be navigated by people, for example).
Other organizations are deploying infrastructure in public spaces (e.g., Nokia - Bluetooth-based). This solution assumes you control the infrastructure (and assumes the latest Bluetooth technology).
I work for TRX Systems and we are complementing these existing technologies with sensor and map fusion technology. In this approach, we fuse information from a multitude of sensors - including signals of opportunity (GPS, WiFi, cell triangulation, Bluetooth), embedded sensors (inertial, altimeter, ranging, compass), and known and inferred map information, to deliver an accurate location indoors.
Carol
The only way to accurately estimate your indoor position is by mapping the signal of known radio hotspots (i.e. wi-fi). That's why the indoor navigation feature has been implemented just for a few locations.
I'm creating an application that needs to be very accurate such that when an individual is walking past a certain building, it will provide them with information regarding that building. I was wondering could this be accurate enough using the Android Location API? What technical challenges should I consider?
Edit: I am using a HTC Sensation XE although i'm not sure what chip it uses for GPS
There are multiple variable factors here:
1. GPS hardware itself.
2. Even if the GPS hardware is good,you cannot assume to have very good accuracy since GPS works on "Line of sight"...so if there is lots of trees/high buildings/or anything that could possibly cover the satellite from the GPS receiver would decrease the accuracy of the location determined
3.Time and location---Not all GPS satellites are available in all places at all times...and the accuracy depends on the number of available satellites currently above the user in the sky(to say in lay man terms).
4.The speed of the user.This is more to do with the polling time rather than the GPS accuracy,If say the user is moving in a high speed train,it practically becomes impossible to exactly poll the GPS for the location at that required time thus missing the building.
You might want to understand on how GPS works and this is more of a GPS technology limtation rather than Androids.
Cheers.
Basically the answer depends on your GPS hardware. However, do not expect accuracy of a few meters.
See here for a similar question and some aspects for accuracy: https://stackoverflow.com/a/8852790/1127492
According to this question, accuracy of Android phones' GPS can vary from around 5 to 50 meters, but it mostly depends on the performance of the GPS chips, which has nothing to do with the OS per se.
According to the location API doc, you can also try to use the cell towers and wi-fi hotspot for location, but this will typically be even less precise.
I'm starting to deal with gps data on Android 2.1 (HTC Hero) and look around on topics about Kalman filter and least squares fit to location data. While receiving and logging GPS data using phone I've found small dispersion if staying on position, but coordinates are pretty accurate when moving. Here comes the question: - Do getLatitude() and getLongitude() functions provide "raw" coordinates, or data was pre-filtered by android (while position is fixed or during movement)?
I'm curious if anyone tested Kalman on android and it's possible to say that you have certain improvements with gps. In my case I read GPS data every 3 seconds(was done to send it over mobile network to server along with compass data and accelerometer). Therefore, I can make filtering on device or on the server. If to do it on device reading can be done more often, but on server I could use additional calculation power.
I work with Kalman filters in my field. A Kalman filter is a filter that improves quality of a collection of sensors based on a system model. If you're trying to implement a Kalman filter, to do it, you'd need a second sensor, like a velocity sensor or etc.
You're not going to make any progress with the sensors on the Android package itself. Modern GPS chips already do extensive filtering and the data is about as good as you're going to get it without adding hardware. The accelerometers and compass especially simply aren't good enough to compute good velocity data out of, and absolutely not if you're only sampling them at 3 seconds. A poor Kalman filter implementation is a great way to really screw up a dataset.
Sorry for the downer, but my personal opinion is that you're wasting your time trying to improve the provided GPS data.
On the upside, your raw GPS data is already very good! Use it and be happy. :)