I am writing an app that needs to be able to measure speeds and I am using Google location services for Android to get speeds. It works fine up to around 300KPH and then the speed simply comes back as 0. I tested this by using the app on a recent flight I was on.
Does anyone have any idea if there is some kind of limit in place?
Well I ended up creating my own speedometer using a handler that calculates the speed based on distance traveled between calls to the function. It seems pretty accurate, now I just need to get on a plane to see if it works at high speed.
Related
I am biggener in android. I am trying to implement a fitness app that can keep track of the running speed and running distance in Android. How can i calculate the above mentioned things ?
In theory you could analyse windows of accelerometer data and count the number of peaks and the forces of those to determine running. Then, if the user has entered an average step distance, that could give an equation of distance.
Would be a lot easier using GPS as it provides the speed directly.
You might be interested in this library: https://github.com/mcharmas/Android-ReactiveLocation I recently added Activity Recognition, which can tell you whenever a user starts running. Might take a little while from one begins to run before the phone 'knows' that as being the activity, though.
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 use in my app TLocationSensor on Android but I have a problem with Distance property. If I set 10 meters and I don't move OnLocationChange is fired.
What should I set and how to make it work ?
Probably the XE5's location sensor component does work - it is just the device incapable of providing Delphi accurate enough data under given circumstances.
You can take some mapping software like MapSoft Navigator and record a track for few hours. If that track would show the significant deviations, then it means the device thinks it is being sporadically moved. And it reports those movements to Delphi, which triggers the events.
See the data presumably gathered under open skies, even without reinforced concrete walls making reflections and distortions: https://gis.stackexchange.com/questions/12011
I am working on an app that will leverage the geolocation to update the location of either vehicles or other "parked" items within a specific area, either large parking lot or other outdoor facility. I can build this app either as an HTML5 app and use phonegap to distribute it to both ios and android or I can build as an ios native app. My first question is in regards to which is more accurate the native ios geolocation services or the HTML5 (I am assuming browser) capabilities? My second question is, in order for me to get the most accurate reading, will I need to know the coordinates for the boundries of the area in question and then calculate position based on the users location in regards to the boundries? (is this triangulation?) Obviously I have never done anything like this so I am looking for guidance and logic not code. Also I really need to know how to get the greatest accuracy as I have mocked up this app using HTML5 and phone gap and I am not very happy with the level of accuracy. Thanks for your help.
The level of accuracy available to either a native app or HTML5 app is the same. It depends on which mechanism on the device you use to determine position as to the accuracy delivered to your app. The most accurate position that can be obtained is via GPS, as opposed to phone signal triangulation or a WiFi connection. The accuracy of the GPS position you receive isn't related to the mechanism you use to implement your app (native or HTML5) but a function of the hardware that the device is running (i.e. the GPS receiver), the geographical location, weather conditions, etc.
In answer to your second question, there's nothing you need to (or can) do in terms of implementing your app to improve the accuracy of the GPS position you receive. You can, however, choose to ignore readings which are outside of minimum level of accuracy (the data returned in the geolocation message contains an estimated level of accuracy).
I've implemented an app using Phonegap and during testing found the average accuracy of the GPS positions returned to be within 2 to 6 metres depending on the device.
If you're using Phonegap, make sure to use the "enableHighAccuracy" parameter when requesting a position to make sure a GPS fix is requested from the underlying OS. Beware though that even if you do this, inaccurate positions can still be returned so it's best to set up a filter to reject any that are too inaccurate.
Hope this helps.
After doing some asking around and reading, it sounds like you're lucky to get even within 10 meters of accuracy with a GPS on a mobile device (specifically Android).
I've seen a video that shows a home-made device reading out to several decimals. Is this only because of the data format from the chip? (aka, not really precise either?)
Is there any real working way that I can use an Android device to track real static positions within rooms in a building?
Ideally, I'd be able to mark a point in a room and come back to it later with virtually no drift.
The LocationProvider is different from each Android Device you are using. The SDK does not handle the calculation of your exact location but the phone does. But each device can have one or mare LocationProvider, thats why you need to set some Criterias when your picking a LocationProvider.
To get your exact position on the earth the GPS needs 3 points from 3 different satellites. Thats why the GPS works best in the open space. Regarding making a precise calculation on a static persion inside a building, this conflict with the whole scenario of the GPS-System. I'm not saying it's impossible to get a location inside a building but as with any other signals, obstacles that blocks the signal makes is weaker.
If you are inside a barn with thin walls this might work, but inside a 10 storage building your scenario seems quite impossible.
You can though force your phone to get the best LocationProvider and hopefully that will give you the most precise location. And yes, you can get inside 1-2m in precision outside.
I hope this helps a little. Enjoy your project.