Closed M66B closed 8 years ago
I'd like something similar.
I would like to have it log "course" under normal circumstances (24/7), and then switch to a more accurate version if/when I'm doing certain activities.
To make this general, I'd suggest that there will be several profiles, (log every XX, send log every YYY, use celltowers only / use GPS) where different triggers toggle transitions between profiles. Enter circle of X km around Y, started bicycling, started running... etc.
This would be amazing. I was thinking I'd like it if it increased resolution if it saw me move, but this is much better.
that page seems to be mia, but the APIs haven't changed. http://web.archive.org/web/20141210033149/https://developer.android.com/training/location/activity-recognition.html
So I've been testing out how activity recognition responds, and this is what I've found:
I think I'm probably going to implement this (eventually, it may even take me months, I have a lot going on right now), and if so, this is what I'll do:
unknown
as "poll no more than one minute after last poll", or if that's too difficult to implement, I will ignore the unknown state entirely (in which case still -> unknown -> still would not count as a state change.)Anyone have thoughts on this? sound good?
"constants" like "minute" and 1000ft, 300ft, 5mph etc should be avoided. I'd like to be able to configure them. I would say that "scaling up" (i.e. more trackpoints) should be quick, scaling down can have a bit of a lag.
My sport is paragliding. I go to a field for a day, and 90% of the time I'm just walking around on the field. Exact position not very relevant. Then all of a sudden, the accellerometer becomes "quiet", speed goes to about 10m/s (about 20mph) and I'm in the air. That's when I want a position reported every 5 or even 2 seconds. There are competitions for paragliders, and if you want to participate, you just submit your GPS log. As I always forget to turn the other logger on, I want to have an automatic backup... (The speed trigger is not reliable: With a nice headwind the airspeed wil still be about 10m/s, but the ground speed can be as low as 2m/s...) Similarly: Velocity is unreliable. When it is thermic, I'll be doing circles, going around every 20 seconds. With a 7m/s windspeed (thats a lot, most people don't consider it safe to be flying, but some years ago the world record was flown in even more extreme conditions....), I'll be doing say 15m/s (30mph) with the wind, and 1m/s (2mph) against the wind 10 seconds later!
Wifi connections could also be "cheap hints" used to influence the logging frequency. I'm not far from home when my phone still has a wifi connection to my home router.... Saving the battery is then more important than logging many datapoints.....
seems like the auto scaling should work fine in terms of catching your acceleration as long as you're moving a little before you accelerate. doesn't drain the battery that quickly. however, one thing I considered proposing is treating the unknown state as panic mode and turning the GPS speed up as high as the user has set it. the GPS speed needs to be higher the slower you're going because the movements you make at lower speeds typically are a lot less consistent (as you mention for paragliding, for instance). so as soon as the phone lose track of what you're doing via the accelerometer, you might still be stationary but you're probably about to move, so turn the GPS speed up until you settle on a motion.
that said, the recognition is never going to be perfect, and if there's something riding on it, it'd probably be better to leave it on a constant polling the whole time, and turn scaling off for everything except triggering/stopping GPS recording. and it'd be paranoid about letting it stop anyway, only letting it stop after a minute of phone detecting only still - which by my testing just doesn't happen when it's on your person and you're standing up - and after the GPS hasn't detected movement above a half a mile an hour or so.
and, yes, this should definitely all be configurable. except maybe a few things that almost never make sense to change, for which you'd have to rebuild the app. like activity recognition message frequency, for instance, which only varies based on what actually works. one second should be fine for that one, since it seems to take about 10 seconds to decide anything.
oh, reading your comment, it sounds like you want geofencing-triggered sample rate increases.
I found some spare time and played around with Activity Recognition a bit. The quickest wins that I can see is:
still
since the last point recorded. This helps clean up those star like numerous points that tend to accumulate when you're not moving.Some of the things you've mentioned regarding dynamic scaling would effectively replace a large part of the existing logging service or duplicate it, it's not desirable from a maintenance point of view. But maybe there are ways to get them to work together in one place without complicating things.
Notes:
I have a concern regarding Google Play Service's data requirements; it's not explicitly mentioned but it requires a connected GoogleApiClient
object, which calls Google's servers. While it may work without it, I don't know if it's guaranteed to work without it. Basing the core logic of the app on this is tenuous, especially given that a lot of GPSLogger's users are not in connectivity-rich parts of the world.
I would also look to use the ReactiveLocation library which wraps a lot of this functionality.
If it's an optional setting it shouldn't be too bad.
I've been thinking about this. The way I phrased things in my previous comment might have sounded like it would be necessary to make things specifically for me. Not desirable.
To make things general a user should be able to configure "triggers" for different sample frequencies (or modes). So, I would configure mode: "do not log": no posisitons recorded mode: "log a little": log every minute mode: "log a lot": log every 2 seconds
intended for: "when I'm stationary", "when I'm on the road" and "when I'm paragliding".
I'd then configure triggers:
connected_to_wifi "
I've been playing around with this in a separate branch.
So far the only thing I have implemented is quite basic: If the user is still since the last logged point, logging pauses until some activity movement is detected. If any other activity is detected, even tilt, then logging will resume.
You can play around with the APK here: https://www.dropbox.com/s/y1xxw0oq7e44zs0/gpslogger-61-activityrecognition.apk?dl=0
There is only one new preference, under the Performance menu item.
But I could use some help here.
I feel that sometimes, when sitting in a train, or moving at a smooth speed => activity recognition thinks that you are still. Maybe your experience is different. Have you noticed the same, or is it always reliable for you? I've been using this app as well as my own debugging messages to look at my activity. Sometimes it's unknown, but sometimes it says I am still!
I have also noticed that if you are still for a more than 10 minutes, then you pick up the phone and start moving, your movement isn't registered immediately, it can take a minute or so. But I suppose that's a minor issue.
You're totally right, I noticed it sometimes detects still incorrectly as well. My recommendation for how to deal with that, as I mentioned in my previous message, is to respond "When the user is in the 'still' state and the most recent gps update indicated no motion" (quote from what I said before) rather than simply "when the user is in the still state". For our purposes, "no motion" would be "less than a tenth of a mile an hour".
Also, your approach sounds more or less good enough for what I wanted, except for one thing: I was hoping to improve the resolution of when the user starts/stops moving, by doing these things:
I'll add a bounty of $50 if you implement it with those features.
Actually what I need is time :D
Your bulletpointed ideas make sense - if the user transitions, that's a good point to start polling. I've now added that. When moving and you go still, it will log. When still and you start moving, it will log. Then back to its regularly scheduled logging.
The APK has been updated here: https://www.dropbox.com/s/y1xxw0oq7e44zs0/gpslogger-61-activityrecognition.apk?dl=0
My concern is - and it'll be a while before I can test this - in a vehicle, I don't want it to mistake lack of acceleration as stillness, although there is an IN_VEHICLE activity.
awesome! I'll install that and use it. does it have any sort of debug logging enabled? how do I tell if it's behaving how you're concerned about?
You can go to General and enable a debug log there (and note the warning, the file grows large over time). In there the debug messages related to this thread are as follows:
Activity detection:
I/GpsLoggingService﹕ onEvent:1022 - DetectedActivity [type=2, confidence=56]
The type values are here and 3 means still.
Own logic, I have messages like:
Just exited still state, attempt to log
If you do test it, the only thing to make sure is it logs even if you are in a vehicle. I think I will be able to test the vehicle thing next weekend, so I can get to it eventually.
cool. did you set it up so the only state where it pauses logging is (activity == still && last_gps_speed < stationary_speed)
? that should deal with the biggest potential error case.
Added a speed check Added an 'Activity' text on the Detailed View screen, so you can see most recent known activity (Still - Confidence 90%)
https://www.dropbox.com/s/y1xxw0oq7e44zs0/gpslogger-61-activityrecognition.apk?dl=0
Spent today testing this. That didn't work very well. Unfortunately GPS will sometimes incorrectly report you as moving even if you are still; even if you have been still for an hour.
Removed speed check
https://www.dropbox.com/s/j300rh187b08f80/gpslogger-61-activityrecognition-nospeed.apk?dl=0
I assume the activity filter was added quite recently? After the last upgrade to 62 all my tracks contain just one point - the start, and debug log is filled with
11:55:29 INFO Utilities.PopulateAppSettings:149 - Getting preferences 11:55:29 INFO Utilities.PopulateAppSettings:149 - Getting preferences 11:55:29 INFO GpsLoggingService.StartGpsManager:526 - No movement in the past interval, resetting alarm 11:55:29 DEBUG GpsLoggingService.SetAlarmForNextPoint:893 - Set alarm for 5 seconds
and the culprit is the activity recognition: even though I was moving and even tried shaking the phone vigorously it was still refusing to log any points until I turned the accelerometer filter off. Samsung galaxy S5 duos, lollipop.
Also call me dumb, but I cannot figure out a way to delete old tracks and debug log from the card on the unrooted device. Is there a way? (apart from removing the card that is :)
The activity recognition only kicks in if it exists as a service (apparently 95% of phones have it and a modern one like yours will), so I can only imagine it's very strict about making you move? Also remember that if you had been idle for a while, the activity service itself goes to sleep (!!!) and won't wake up for a minute or two after you start vigorously shaking.
You can install ES File Explorer, then browse to /sdcard/Android/data/com.mendhak.gpslogger/files and you can delete anything from there. Or just connect to your PC, then browse in the phone to internal files, then same path and delete the files there. This works if you've got MTP support.
Apparently activity service is not active on my phone and even an hour of driving won't wake it up. I've got something called 'health service' (my health, not phone's - pedometer, etc), it was annoying me so I disabled it - could it be it?
The problem with old track deletion is not the tool, but access rights: haven't got them, access denied. All files in /storage/extSdCard/Android/data/com.mendhak.gpslogger/files and the directory itself are owned by u0_a220:sdcard_r and have 770 access mode.
Any further activity on this? I'm interested in using this kind of feature so that I can leave the logger running 24/7 and get traces when I go for a drive or walk.
Ah I've put this in since v61 last year, totally forgot to mention in this thread, sorry. Check the Performance menu, towards the bottom.
:+1: This should probably be closed, @mendhak.
Although I just went for a walk and it doesn't seem to stop logging now that I'm back and the phone is still. Is it designed so that when the activity is "STILL" it will stop GPS logging?
Yes, if you're still longer than the logging interval (60s by default).
Note that sometimes the phone just won't report activity to the app, so in those cases the code just falls back to assuming walking.
I see this great feature has been removed because F-Droid doesn't allow it.
Is there any chance it could be added back in, and a separate build with it offered via Github? I'd sacrifice automatic updates for that feature, it was extremely handy.
Alternatively, if I added the feature back in as a compile time option, disabled by default, would the patch be accepted?
It's such a shame that F-Droid has adopted this policy, where it can't even be offered as an option.
http://developer.android.com/training/location/activity-recognition.html