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.
Related
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.
I've read through the SDK documentation for both Windows and Android and found some functions for accessing the state of the current GPS connection and Latitude/longitude information.
I am looking to develop an application that uses 3d photogrammatry to monitor a set area in real time and am worried that built-in localization might not update the model accurately enough.
So I am wondering if there is a way to get the lower-level information like connection strength and specific connected satellites. (to compare to GPS information from the ground for better accuracy.) Is this supported? (maybe in specific drones?) Or is my only option to attatch a GPS device to it that I then access seperately?
I also know that DJI offers a drone with GPS-RTK to give this accuracy but I'm looking at alternative approaches because of the big step up in cost.
Any information / suggestions would be of great help! Thanks.
I am sorry to report but there is no access to the raw data from the GPS sensors. The information you found in the SDK documentation is all that is available.
How accurate are you looking for? Generally the accuracy is pretty close, certainly within 1 foot or so and there is specifications for GPS accuracy in specific drone's manuals.
There isn't any more info you can get from the sdk.
I guess you looking for raw meassurements? There is nothing that points to that's possible, even in the dumledore messages.
You better stick with the newer drones, since they seems to use dual freq gps, starting from mini2. Very accurate.
Havn't tried the mavic3 but my guess is that they switched to the same gps-chip as in the mini2.
Ne aware that gps lat/lon you get is actually fused with the imu.
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 am developing a project that is intended to use the GPS capabilities of an Android phone and a nearby station to compute positioning to a much more precise degree (cm), using RTK DGPS technology.
So far, I haven't been able to see anyone saying they actually managed to perform a similar task (apart from #GPSmaster, who doesn't explain how), and the APK doesn't seem to offer any information from the GPS chip other than location and NMEA message updates. I need, if possible, pseudo-ranges and carrier phases.
I was wondering if:
It would be possible to look for lower level hooks on my phone using native code, or other lower level snooping;
It would be possible to send RTCM corrections to the GPS chip present on one of these devices;
Any ideas?
Generally speaking DGPS is a technique that improves real position accuracy by canceling out most of the atmospheric effects on the GPS signal. In a typical direct GPS measurement there is about a random error in the ranges computed to the satellites due to atmospheric effects. This is why a GPS receiver that is left collecting data in a fixed location will seem to wander with in an error ellipse. For two receiver stations in the same area the atmospheric effects are almost identical and they will wander in parallel within their similarly sized and oriented error ellipses. If one of the two receivers is at a know location then the differences in their apparent GPS locations can be taken and plotted from the true location of the known station to find the true location of the unknown station.
Back in the day (circa 1992) when we had to accomplish DGPS by "post processing" we used to take the raw NEMA data collected at the two stations match up the times, compute the baseline vector and apply it to the known point to find the unknown point. I think the NEMA data we were using was only recorded to the nearest 10 sec. The math isn't really that hard.
I suspect that NEMA GPS messages [http://developer.android.com/reference/android/location/GpsStatus.NmeaListener.html ] from a tablet at a known point (with a clear sky view) could probably be sent over an internet socket to a smart phone (also with a clear sky view), which could then compute the difference and achieve a sub-meter relative location over a distance of few km, even if the assumed Internet transit times were ignored. This technique would probably still work even if the tablet and smart phone were both applying broadcast DGPS adjustments.
With the andvent of Android 7.1, the raw data from GPS chips will be available to developers. (http://gpsworld.com/google-to-provide-raw-gnss-measurements/)
Others seem to have done something similar to what you wish to accomplish (http://gpsworld.com/innovation-precise-positioning-using-raw-gps-measurements-from-android-smartphones/)
No, it is not practical to get any lower level access to the GPS device by an Android application. This has several reasons:
The application has no other means of accessing the GPS device as through the Java based API. Native code is forbidden to use most devices and usually needs a Java wrapper to tunnel through the sandbox for Android sensor devices. This makes up the main security concept.
If native code would have access to the GPS device on a lower level, it would have to cope with several different manufacturers protocols now not abstracted by the API. Best chances are to get access to custom NMEA codes, which may still have device dependent caveats.
Even if lower level access would be possible, one loses the integrated merging of other location sources like WLAN and cellphone carrier, that are presumably merged in native code below the Java API but above the NMEA protocol.
You can use DGPS corrections in Europe via custom application for SISnet receiving correction signals from EGNOS augmentation satellites(http://egnos-portal.gsa.europa.eu/news/egnos-gets-invite-your-smartphone-11). It does however need a subscription (which isn't really open to public yet) to SISnet to obtain username and password for connection to their servers. There's some of SDK published which you may find useful. Just remember that you are limited to C/A signals only (pseudoranges) and you CANNOT get phase data (L1/L2) from those cheap chips inside smartphones.You'd need a precision GNSS receiver such as Trimble BD910 (http://www.trimble.com/gnss-inertial/bd910.aspx?dtID=overview) to be able to access L1 carrier phase signal for GPS & GLONASS. There are however cheaper chips that support SBAS but none are yet installed natively in phones.
Umm. Your android probably has such a crap GPS antenna that achieving cm accuracy is impossible. Maybe if you average the position for days.. usually DGPS support is not published and not many chipsets support it. Last time I saw DGPS implemented it involved hacking the actual GPS chip firmware to add support. Even getting A-GPS to work on a random chipset is iffy since they might not support a documented way of feeding the assistance data.
It should be related with the hardware implementation , rather than the software implementation.
In the reality, GPS is usually accompanied with Wi-Fi or 3G to assist in searching the current position.
RTCM correction can be sent to your android phone using NTRIP 'provider'. Then you need to apply it to your raw GPS in your android.
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.