Indoor training - Githubissues

ChristophWurst commented 3 years ago

Is your feature request related to a problem? Please describe.

As far as I can tell the app is currently focused on outdoor training. That is, GPS signal is assumed to be available and the app most likely also uses it to determine activity and pause sections of a recording.

Describe the solution you'd like

For cycling, running and possibly other sports it would be neat if the app could also support training indoors. This means there should be an option to disable GPS. The active/pause is then either fully manual or based on sensors (e.g. steps for running, speed for cycling).

Describe alternatives you've considered

n/a

Additional context

Cycling power meter sensor PR: #444 My feature request for power meter readings of smart trainers: #498, specifically

while the sensor data will be shown, we only record (store it in the database) when a GPS coordinate is stored. So, no GPS signal, no diagrams, statistics, export etc.

dennisguse commented 3 years ago

That's a kind of complicated as we only store data based upon GPS and indoors there will be no GPS data. So, we need to store the data using some timer?

And are not able to provide a distance as we use the GPS for this. One option would be to use a wheel rotation sensor (BLE: Cycling Speed) to estimate the traveled distance.

ChristophWurst commented 3 years ago

So, we need to store the data using some timer?

I recently inspected some .fit files from wearables and they use timestamps for their data points. So each timestamp has a value for lat, long, speed and so on.

One option would be to use a wheel rotation sensor (BLE: Cycling Speed) to estimate the traveled distance.

Indeed, that is how other trackers do it as well. Either you have GPS or a speed sensor, otherwise distance can't be determined.

pstorch commented 3 years ago

Do we need to revise our backup (import/export) strategy? As KML and GPX are for Tracks, don't know if they are suitable for indoor activities.

dennisguse commented 3 years ago

Following the implementation of #316, we could implement this now. Assumption: there is no GPS signal For pure indoor training, we would then need to store the generated data (in the STOP trackpoint).

Following tasks:

[x] get distance from a sensor (like Cycling Cadence And Speed Sensor)
[x] store this distance in the trackpoint
[x] use the sensor derived distance (if present) to compute the TrackStatistics
[x] import/export distance via GPX/KML
[x] (nice to have) present data source in the UI (also do this for speed)
[x] (nice to have) implement distance and speed parsing for wheel-based powermeters like Wahoo Kickr

Follow-up: generate TrackPoints based upon time intervals if no GPS is present

dennisguse commented 3 years ago

@ChristophWurst I just opened https://github.com/OpenTracksApp/OpenTracks/pull/598, but it is not ready. I stumpled upon the issue that we have to compute the distance between two trackpoints; not only between two sensor measurements (sufficient for speed; not relevant for HR even).

dennisguse commented 3 years ago

We now support getting the distance from a sensor. Next step is that we need to store the data at a regular(?) interval as well. So far, data is only stored when a GPS location is received OR the user pauses/stops a track.

dennisguse commented 3 years ago

IMHO: the code base is now ready for this. After merging #922, we will have only one handler running within TrackRecordingService. It handles the data updates for UI and voice announcements. We can then extend it to create time interval-based Trackpoints (i.e., if no GPS-Trackpoint was created a certain period of time and there are sensors sending data, then create a sensor-based TrackPoint; repeat).

Proposal:

(min_recording_interval_key) GPS-Interval * 2 => sensor-based TrackPoint interval
lower limit 30s if GPS-Interval < 60s *sensor-based TrackPoint interval is reset each time a GPS-TrackPoint is created

Follow-up idea: make use of GPS optional (i.e. GPS-Interval of -1) and also skip requesting access.

@rgmf What do you think?

dennisguse commented 2 years ago

@dennisguse Note to myself - hasSensorData should not be used in TrackRecordingManager if this is implemented.

            if (trackPoint.hasSensorData() || (distanceToLastTrackLocation.greaterOrEqualThan(recordingDistanceInterval) && trackPoint.isMoving())) {

rgmf commented 2 years ago

IMHO: the code base is now ready for this. After merging #922, we will have only one handler running within TrackRecordingService. It handles the data updates for UI and voice announcements. We can then extend it to create time interval-based Trackpoints (i.e., if no GPS-Trackpoint was created a certain period of time and there are sensors sending data, then create a sensor-based TrackPoint; repeat).

Proposal:
* (min_recording_interval_key) GPS-Interval * 2 => sensor-based TrackPoint interval

* lower limit 30s if GPS-Interval  < 60s
  *sensor-based TrackPoint interval is reset each time a GPS-TrackPoint is created
Follow-up idea: make use of GPS optional (i.e. GPS-Interval of -1) and also skip requesting access.

@rgmf What do you think?

I didn't realize this.

That sounds like a great idea. With cycling sensors we could do what you say so we can turn GPS off and save battery even for outdoor activities.

On the other hand, I don't know how much effort this will imply: more code, more logic, more maintenance... will it worth? will you use this feature? I think I won't use such a thing because getting locations (trackpoints with GPS data) is important for analytics purpose.

dennisguse commented 2 years ago

@rgmf Hopefully, it won't be that bad - basically, we can consider GPS just another sensor :) Almost everything is in place for this, except the actual timer that needs to be triggered - implementing it as push would be another option, but would produce more data if multiple sensors are connected.

Another thing that would be great to do for this is #652 (so can we can at least export the stats to GPX).

dennisguse commented 2 years ago

@ChristophWurst this feature got released with v3.24.0 today :partying_face: Kudos for this feature request: it was kind of nice doing as it had a vast amount of aspects to consider. A never ending story to think about new cool stuff and figure out (crazy) solutions :sunglasses: Also the boring stuff was nice :thisisfine:

ChristophWurst commented 2 years ago

Sorry I'm late to the party. Awesome work @dennisguse! Great to see this has been picked up :)

dennisguse commented 2 years ago

@ChristophWurst actually, was a great goal to work towards to. We needed to change so many things (and understand them first)! Was a great vision for the product 😊

OpenTracksApp / OpenTracks

Indoor training #500