I'm trying to find a good way to track location of people in a building. I would ultimately like to be able to create a graphic on demand showing where employees are in a building - which floor (elevation), and where on the floor they are located (lat/lon). I have read that elevation is relative to the WGS84 ellipsoid, not sea level necessarily, which is fine. I can define a baseline of where the first floor is, for example, and then calculate the difference of a person's current location from there. If I understand correctly, the general precision lat/lon for a GPS is as fine as 1m, which should be sufficient for me.
Part of my problem is finding a device to use for employees to carry around. The other is finding a device with a supported API (read: "free API") or other programming options. I would like this to be manufacturer-independent.
I would love to do cross-platform development - iOS, Android, PC, web, etc.
Does anyone have experience with something like this, and what recommendations can you offer on where to start? I know this is a little open ended but I'm not sure where to start.
Thanks.
This all does not work (tracking within a building).
GPS Signal is very poor or non existent within a building.
(Next time search here on Stackoverflow. It has been asked some times.)
The only robust and working solution, are BlueTooth beacons.
Such small hardware pieces are mounted within the building.
Such beacons (search for iBeacon) just send out an id.
The phone receives the id, and the approximate distance to it.
You have to administrate and know which id is at which level of the building.
Even when having good reception the GPS signal is not precise enough to determine the floor a person is location.
Some phones have a barometer, like the ipHone, this can track relative heigh changes, and may be used to determine level within a building. (Once calibrated before entering the buulding)
how can I correctly identify if the user is driving or not ? I am trying to make an app where I can find my parked car's location.
The simplest way was to ask user to press a button after parking the car so that my app can remember its location.
But I want my app to be automatic. It should correctly recognize if the user is in vehicle or not without interacting with the user.
I tried out Activity Recognition as well but it does not give me exact/correct result. Even when I am walking it says driving and vice versa. I cannot trust it.
There are several apps in the play store which achieve this. I want to learn this as well.
Would some one take some time and help me out on this. It will be of greate help. Thanks a lot in advance :)
I've never done this before, but here are some things I'd try:
location - mainly, how fast their location is changing. probably not great for slow traffic, but if they are moving 60mph, there's no way they are walking. You could also combine this with map data about known roads, or maybe even use locations of well-known airports to know that someone is more likely flying than driving
use the device's accelerometers to compute it's speed (in conjunction with location info to correct for accumulated error).
have the user connect their device to the car with bluetooth - and then when the connection drops, you know they aren't in their car. Or better yet, figure out if you can just detect they are in the car from strength of the bluetooth signal. Though I'm not sure that's possible.
(maybe) ask your users to use a simple RFID chip in their car, and then use that as an indicator of whether or not the phone is in the car. Of course this has implications on the user experience.
in a different vein, maybe some sensor on the device could pick up vibrations? Just thinking that car rides aren't perfectly smooth, so any vibration sensing + some signal processing (DFT the data, then look for certain low frequencies that correspond to driving - probably low frequency and below audible).
The best? Probably a combination of all of the above. The more signals you can gather, the better. Perhaps you could even collect a bunch of data, and try to use it to train a classifier? Then again, if any one of these signals turns out to be strong enough, you might not need the others. Be sure to test a variety of scenarios, e.g. phone in the cup holder v. in your pocket, city driving & slow traffic v. highway driving / empty streets, etc.
I'd be curious to know if any of these ideas pan out.
Also fwiw, Determining if user is driving using gps appears relevant - though it's a simple speed-based check - if you cruise around a parking lot at 8mph looking for a spot, you'll completely fail at catching where the car is parked if your threshold is 10mph.
If the speed drops from above 40km/h to under 7km/h, and stays low for more than 5 minutes.
I want to create application which will navigate user at the shopping mall. So, I'll create a mall's map and I need somehow to track changes of user's location. Because of navigation in building, GPS is not a solution (low signal). So, I assume there is a way to track location changing (1-2 meters) with another module (maybe accelerometer?). Any ideas?
Thanks
Update: I cannot use any additional devices such as iBeacons or so. I only can use device on which app is running. No access to wi-fi routers or so.
Example: I'm standing near Apple store(point A), and now I'm going to Samsung store(point B). The app should react that I started to move from point A, and know how much meters(accuracy may be not ideal) I walk from point A and in what side I'm going (east, west, south, north).
iBeacons have bean invented for your task, they are low energy blue tooth devices which emits an unique ID, and If I remeber correctly, also the distance to that beacon.
iBeacons have been invented by or for Apple. So you have to search for an alternative which works on Android.
ibeacons are mounted at the walls of the shop.
Update:
Things you can do:
Count foot steps using accelrometer, like apple does in an API.
Theoretically you could use the built in compass, but practically it has to calibrated each time it is used (this is anoying, and useres will not do it).
You can get to decimeter accuracy using magnet field analysis of the shop and the 3-d magnetic sensor of the smartphone. This works in research (indoor navigation using magnetic fields) But you have to create a magnetic map of each shop to make it work.
for WLAN:
You need at least 3 different wlan routers in the shop. Usually they will only have one.
1-2 m accuracy you will not get with wlan.
(On ios it is not possible to read the wlan device ids nearby, hopefully you can do that in android)
iBeacons or similar devices mounted in the shop at strategic placesw,
are the only feasible technology which you will get to work.
There is an open source Android app for tracking location without GPS. It uses TYPE_STEP_DETECTOR sensor available from API level 19.
You can download it from Google Play and source code is available on GitHub.
The app is not very accurate because it uses average step length. It can be improved if we allow user to specify or calculate automatically his personal step length.
I was looking into implementing an Inertial Navigation System for an Android phone, which I realise is hard given the accelerometer accuracy, and constant fluctuation of readings.
To start with, I set the phone on a flat surface and sampled 1000 accelerometer readings in the X and Y directions (parallel to the table, so no gravity acting in these directions). I then averaged these readings and used this value to calibrate the phone (subtracting this value from each subsequent reading).
I then tested the system by again placing it on the table and sampling 5000 accelerometer readings in the X and Y directions. I would expect, given the calibration, that these accelerations should add up to 0 (roughly) in each direction. However, this is not the case, and the total acceleration over 5000 iterations is nowhere near 0 (averaging around 10 on each axis).
I realise without seeing my code this might be difficult to answer but in a more general sense...
Is this simply an example of how inaccurate the accelerometer readings are on a mobile phone (HTC Desire S), or is it more likely that I've made some errors in my coding?
You get position by integrating the linear acceleration twice but the error is horrible. It is useless in practice.
Here is an explanation why (Google Tech Talk) at 23:20. I highly recommend this video.
It is not the accelerometer noise that causes the problem but the gyro white noise, see subsection 6.2.3 Propagation of Errors. (By the way, you will need the gyroscopes too.)
As for indoor positioning, I have found these useful:
RSSI-Based Indoor Localization and Tracking Using Sigma-Point Kalman Smoothers
Pedestrian Tracking with Shoe-Mounted Inertial Sensors
Enhancing the Performance of Pedometers Using a Single Accelerometer
I have no idea how these methods would perform in real-life applications or how to turn them into a nice Android app.
A similar question is this.
UPDATE:
Apparently there is a newer version than the above Oliver J. Woodman, "An introduction to inertial navigation", his PhD thesis:
Pedestrian Localisation for Indoor Environments
I am just thinking out loud, and I haven't played with an android accelerometer API yet, so bear with me.
First of all, traditionally, to get navigation from accelerometers you would need a 6-axis accelerometer. You need accelerations in X, Y, and Z, but also rotations Xr, Yr, and Zr. Without the rotation data, you don't have enough data to establish a vector unless you assume the device never changes it's attitude, which would be pretty limiting. No one reads the TOS anyway.
Oh, and you know that INS drifts with the rotation of the earth, right? So there's that too. One hour later and you're mysteriously climbing on a 15° slope into space. That's assuming you had an INS capable of maintaining location that long, which a phone can't do yet.
A better way to utilize accelerometers -even with a 3-axis accelerometer- for navigation would be to tie into GPS to calibrate the INS whenever possible. Where GPS falls short, INS compliments nicely. GPS can suddenly shoot you off 3 blocks away because you got too close to a tree. INS isn't great, but at least it knows you weren't hit by a meteor.
What you could do is log the phones accelerometer data, and a lot of it. Like weeks worth. Compare it with good (I mean really good) GPS data and use datamining to establish correlation of trends between accelerometer data and known GPS data. (Pro tip: You'll want to check the GPS almanac for days with good geometry and a lot of satellites. Some days you may only have 4 satellites and that's not enough) What you might be able to do is find that when a person is walking with their phone in their pocket, the accelerometer data logs a very specific pattern. Based on the datamining, you establish a profile for that device, with that user, and what sort of velocity that pattern represents when it had GPS data to go along with it. You should be able to detect turns, climbing stairs, sitting down (calibration to 0 velocity time!) and various other tasks. How the phone is being held would need to be treated as separate data inputs entirely. I smell a neural network being used to do the data mining. Something blind to what the inputs mean, in other words. The algorithm would only look for trends in the patterns, and not really paying attention to the actual measurements of the INS. All it would know is historically, when this pattern occurs, the device is traveling and 2.72 m/s X, 0.17m/s Y, 0.01m/s Z, so the device must be doing that now. And it would move the piece forward accordingly. It's important that it's completely blind, because just putting a phone in your pocket might be oriented in one of 4 different orientations, and 8 if you switch pockets. And there's many ways to hold your phone, as well. We're talking a lot of data here.
You'll obviously still have a lot of drift, but I think you'd have better luck this way because the device will know when you stopped walking, and the positional drift will not be a perpetuating. It knows that you're standing still based on historical data. Traditional INS systems don't have this feature. The drift perpetuates to all future measurements and compounds exponentially. Ungodly accuracy, or having a secondary navigation to check with at regular intervals, is absolutely vital with traditional INS.
Each device, and each person would have to have their own profile. It's a lot of data and a lot of calculations. Everyone walks different speeds, with different steps, and puts their phones in different pockets, etc. Surely to implement this in the real world would require number-crunching to be handled server-side.
If you did use GPS for the initial baseline, part of the problem there is GPS tends to have it's own migrations over time, but they are non-perpetuating errors. Sit a receiver in one location and log the data. If there's no WAAS corrections, you can easily get location fixes drifting in random directions 100 feet around you. With WAAS, maybe down to 6 feet. You might actually have better luck with a sub-meter RTK system on a backpack to at least get the ANN's algorithm down.
You will still have angular drift with the INS using my method. This is a problem. But, if you went so far to build an ANN to pour over weeks worth of GPS and INS data among n users, and actually got it working to this point, you obviously don't mind big data so far. Keep going down that path and use more data to help resolve the angular drift: People are creatures of habit. We pretty much do the same things like walk on sidewalks, through doors, up stairs, and don't do crazy things like walk across freeways, through walls, or off balconies.
So let's say you are taking a page from Big Brother and start storing data on where people are going. You can start mapping where people would be expected to walk. It's a pretty sure bet that if the user starts walking up stairs, she's at the same base of stairs that the person before her walked up. After 1000 iterations and some least-squares adjustments, your database pretty much knows where those stairs are with great accuracy. Now you can correct angular drift and location as the person starts walking. When she hits those stairs, or turns down that hall, or travels down a sidewalk, any drift can be corrected. Your database would contain sectors that are weighted by the likelihood that a person would walk there, or that this user has walked there in the past. Spatial databases are optimized for this using divide and conquer to only allocate sectors that are meaningful. It would be sort of like those MIT projects where the laser-equipped robot starts off with a black image, and paints the maze in memory by taking every turn, illuminating where all the walls are.
Areas of high traffic would get higher weights, and areas where no one has ever been get 0 weight. Higher traffic areas are have higher resolution. You would essentially end up with a map of everywhere anyone has been and use it as a prediction model.
I wouldn't be surprised if you could determine what seat a person took in a theater using this method. Given enough users going to the theater, and enough resolution, you would have data mapping each row of the theater, and how wide each row is. The more people visit a location, the higher fidelity with which you could predict that that person is located.
Also, I highly recommend you get a (free) subscription to GPS World magazine if you're interested in the current research into this sort of stuff. Every month I geek out with it.
I'm not sure how great your offset is, because you forgot to include units. ("Around 10 on each axis" doesn't say much. :P) That said, it's still likely due to inaccuracy in the hardware.
The accelerometer is fine for things like determining the phone's orientation relative to gravity, or detecting gestures (shaking or bumping the phone, etc.)
However, trying to do dead reckoning using the accelerometer is going to subject you to a lot of compound error. The accelerometer would need to be insanely accurate otherwise, and this isn't a common use case, so I doubt hardware manufacturers are optimizing for it.
Android accelerometer is digital, it samples acceleration using the same number of "buckets", lets say there are 256 buckets and the accelerometer is capable of sensing from -2g to +2g. This means that your output would be quantized in terms of these "buckets" and would be jumping around some set of values.
To calibrate an android accelerometer, you need to sample a lot more than 1000 points and find the "mode" around which the accelerometer is fluctuating. Then find the number of digital points by how much the output fluctuates and use that for your filtering.
I recommend Kalman filtering once you get the mode and +/- fluctuation.
I realise this is quite old, but the issue at hand is not addressed in ANY of the answers given.
What you are seeing is the linear acceleration of the device including the effect of gravity. If you lay the phone on a flat surface the sensor will report the acceleration due to gravity which is approximately 9.80665 m/s2, hence giving the 10 you are seeing. The sensors are inaccurate, but they are not THAT inaccurate! See here for some useful links and information about the sensor you may be after.
You are making the assumption that the accelerometer readings in the X and Y directions, which in this case is entirely hardware noise, would form a normal distribution around your average. Apparently that is not the case.
One thing you can try is to plot these values on a graph and see whether any pattern emerges. If not then the noise is statistically random and cannot be calibrated against--at least for your particular phone hardware.
How to get the distance of our mobile device from a wifi hotspot kept inside a building? This is basically for navigational purposes inside the building.. Any help would be appreciated.
If you want to use WiFi for indoor location (step 1 before navigation), then distance to the WiFi Access Points is not the correct approach. Instead use RSSI.
With Android you would need to take WiFi fingerprint of a building by moving around every few meters and sample the RSSI strength. You need to provide a user interface that lets the user manually specify on an image of the building (e.g. a CAD drawing). Doing this will build up a database of what the RSSI is for different locations in the building. When you come to use this data for locating a user indoors, then you need an app to take the RSSI strength measurement and compare it against the database you've prepared to find the appropriate match.
Notes:
- If anyone adds/removes access points, you'll need to resample the building
- The measurements can be affected by density of people
- Some access points are variable strength access points, so the RSSI fingerprint is not consistent.
- This won't work with iPhone because there is no API to get the RSSI strength.
So, it is a useful, but not perfect way to get indoor location. There are a lot of more detailed articles on RSSI fingerprinting available.
Of course, navigation has to be built on to of that then.
Hi Kris
I understood what you are asking, The distance between Wifi access point and the Receiver, correct ? If yes, then it seem to be not possible after watching the discussion below.
Click here to see