let's say i want to build a smartphone app that tells a user when/where to get off a subway station. i can think of two ways of doing this:
1) using GPS and map of the subway routes, track the location of the user and notifies him when the destination is reached
2) have him press start when he gets on a train as the train starts (which may not be realistic because the user could simply forget to do this), use the known travel time from starting station to end station, and simply notifies him when the time is up.
can someone tell me if there are any other good approaches? thanks.
You may have to go with 'dead reckoning'. Basically, dead reckoning is a navigation technique that uses a confirmed starting location plus accurate velocity and time to calculate a new location. Keep in mind that velocity is itself a combination of heading and speed and that the heading must be a true heading. In an airplane, compass heading would have to be combined with wind speed and direction to get a true heading. I don't think you have to account for drift on a subway, but you will have to account for varying device orientation as the user moves around or uses the device itself. Also, just because heading is normally a compass bearing doesn't mean that it has to be. You may be able to get the job done using only the accelerometers and a timer.
Proper use of dead-reckoning also requires frequent 'resets' to known locations as you reach them so that errors can't add up too badly. For this application, I would argue that curve- and stop-detection can be used as resets. You may get false positives for 'service' stops that are too close to real stops, but those may be rare enough to ignore. In fact, if it wasn't the exit stop, it might not matter because you might still be accurate enough for the next-stop warning and if was the exit stop, it won't matter because the ride is over.
To summarize: you need to be sure that you have a good initial starting point; you need to compensate for device reorientation to get true heading; you need to know your average speed between heading changes and the time-on-heading to calculate distance-on-heading. You can improve overall accuracy by resetting at known landmarks.
Edit: I don't know if this gets you any closer to the answer, but Chris Stratton raised an interesting point about summing the accelerometer vectors. Is it possible to track the orientation of the device accurately enough to have a reliable orientation-independent gravity vector? Can you keep that out of your vector sum? Can that provide a useful acceleration along a useful orientation-independent vector? If so, then tracking the duration of the acceleration will get you an average speed for that duration and a final speed for the end of acceleration. Absent acceleration, the speed will remain constant. Putting that all together might pile inaccuracy on top of inaccuracy to the point of uselessness.
If the subway line has cellular service (some that were going to had it turned off on security concerns) you might be able to do something with network location.
You could use the accelerometer to try to detect and count station stops - but trains stop in between stations from time to time due to delays ahead. Also battery life would be reduced. EDIT: realized you won't be able to tell acceleration from deceleration as you have no idea of orientation (unless you find the compass sensor workable in that environment) - you could only see that the vector sum of the three accelerometers was greater than gravity for a period of seconds.
You could try to use the microphone to detect the sounds of train motors and brakes (some are extremely characteristic) but that has the same problem with battery life and unscheduled stops between stations. Not to mention scheduled stations bypassed for repair work.
Perhaps you should give the user a scrollable list of stations marking the journey and let them keep track.
Both of those sound like poor solutions. You almost certainly won't get a GPS trace in a subway. And the 2nd way sounds like it will be inaccurate enough to make the app useless.
Read carefully Falmarri's answer. He's completely right, although he didn't give you an answer. Let me try then...
If the routes have no many curves, it will be easier: you just have to hardcode the latitude and longitude of each station, and then, calculating the position of the user will be straightforward (just a little of math and that's it). If the routes have curves, then you have more work to do but it's basically the same.
You will probably want to use a way to know the distance between the current location and the station location. You could use some of the existing algorithms, for instance the Haversine formula.
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 want to know current speed of car and make a passed path. I have an Android phone with accelerometer and gyroscope which sent me data. This is the data in phone system of coordinate that probably wouldn't the same as coordiante system of car.
How I can transform this accelerations and rotations to car system of coordinate?
The generic answer for your generic question is no. The acceleration measures the changes in the speed, so the best you could get from acceleration, is the speed variation.
To get the absolute speed you would have to have the initial speed and add it to the speed change:
v(t) = v0 + a*t
So, if you would have a car moving along a straight line, and your device was fixed to the car, you could get easly the speed changes (although measurements errors will add up and quickly lead to discrepancies)
In practice you will face many issues trying to implement it, namely:
You need the initial speed to be determinate based on the same referential as the acceleration. This would require some measurements and a lot of trignometry, as you would get both values from different sensores at different rates.
The car will not move in a straight line, so your acceleration referential will be constantly moving (a lot more of trignometry and calculus).
If the device is in the user hand, the device movements in relation to the car will increase even more the calculations (and accumulated errors).
Regards.
You need some sort of external reference (e.g. GPS is such a thing): If you just integrate the acceleration, the error will go indefinitely.
Because these sensors are not accurate enough. the error will quickly get out of control. (The linked answer is about position but the same holds for the velocity.)
In case of a car, you are better off with the GPS. If want to do something fancy, you could enforce the environmental constraints deduced from a map, that is, assume that the car goes on a road and not through buildings, etc. You will find more details on this in Chapter 5 of the PhD thesis entitled Pedestrian Localisation for Indoor Environments.
It looks like it's possible to do. I don't have an Android specific example but this forum has quite a lot of chat about it: http://www.edaboard.com/thread119232.html
It would be a lot easier if you used the Android Location class though. Specifically the getSpeed() method should give you what you need: http://developer.android.com/reference/android/location/Location.html
The Location class relies on a location provider though so your app will require appropriate permissions.
Both dont deliver anything if the car travels at the same constant speed for some time. The only way would be GPS which has a calculated speed with every location it provides.
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 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.
Problem: Consider an Android device mounted in a vehicle. We want to measure various things using the accelerometer. These measurements should be relative to the vehicle's coordinate system. Thus we need to figure out how the device is oriented in relation to the vehicle. The simple solution would be to just average the "early" acceleration after startup, but I'm worried that the first thing the driver will do is leave a parking lot or a turning left onto the road, thus describing a curve. It would be feasible to ask the user to start measuring after getting on the road, but what if there is no acceleration at that point?
Question: Can someone suggest a strategy or an algorithm that would do a reasonable job of telling how the phone is oriented in relation to the vehicle? A pointer to some FOSS source that solves a similar problem would be even better.
Notes:
I do not want to use GPS for this as it would complicate things for the user.
We can interact with the user, for example by requesting that the user starts measurements before starting out.
The accelerometer alone would not provide sufficient information for your purpose, I would hazard: The vectors acting upon the device, besides vehicle acceleration, will be the vibration of the vehicle itself, road inclines, braking and centripetal force from turns.
The amount of data from sensors due to all those forces would be impractical to aggregate on a phone, hence moving averages or other cumulation approaches would not give even vaguely precise results.
Also, a lot of the acceleration data would be lost between sensor sampling times, even if you were to use the highest available sensor rate.
Recommendation: Use GPS or network positioning information, generate moving averages to account for minor aberrations, and use the result.