I am working on an Android app, which warns the user if he has not been moving for a fixed period of time.
I wanted to determine if the user moves by comparing the GPS positions every few seconds.
Since I have however heard that the GPS positions are very inaccurate and can vary greatly, I was wondering what the best way would be to determine if the user does not move?
I would think using the accelerometer would be a fairly good way of determining if they had been moving.
I would look at using activity recognition. You can get more information about it here:
http://developer.android.com/training/location/activity-recognition.html
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.
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'm new in Android and I would like to ask you is there any possible way to know if the Android phone moved about 5 meters from its current location ?
One idea is to use the accelerometer to detect when the phone is moving. Naturally, you can't estimate the distance moved very accurately, but it might work for your application. If the accelerometer says the phone is moving for more than 5 seconds or so (maybe you can detect a pattern of movement?) you might infer that the phone moved significantly from its original position.
Of course, the user can trick your app by shaking the phone...
A good resource concerning GPS can be found at the official site: http://www.gps.gov/systems/gps/performance/accuracy/
The short answer, however, is that the GPS accuracy of a specific phone at a given moment is dependent upon several variables. Those that are most pertinent to your question would be the actual hardware of the device, and the environmental conditions at present. Typically, a phone under good conditions can expect at best 10m of lateral accuracy. Taking into account poor conditions, local interference, limited satellite connectivity, etc, can push the error of a reading much higher. Unfortunately, consistently and precisely measuring a movement of 5m is unlikely.
I am writing an android program that is a speedometer. the way it works wright now is it takes 2 GPS locations over time, and divides the distance by time to get speed. the problem with this is that it only refreshes when the gps moves, so when I stop moving it would stay at the last speed that I had. is there a better way of doing this?
You could keep track of how long it is since you've had the last update, and adjust the speed after a certain amount of time has past. (You could use a Handler to schedule the check).
In general gps is only going to give you a rough estimation of the speed though.
You can also use the Location object's speed estimate directly (check that it has one by calling hasSpeed(), then get it by calling getSpeed()).
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.