Direct Mobile Coaching as a Paradigm for the Creation of Mobile Feedback Systems

Abstract

In sports feedback systems, digital systems perform tasks such as capturing, analysing and representing data. These systems not only aim to provide athletes and coaches with insights into performances but also help athletes learn new tasks and control movements, for example, to prevent injuries. However, designing mobile feedback systems requires a high level of expertise from researchers and practitioners in many areas. As a solution to this problem, we present Direct Mobile Coaching (DMC) as a design paradigm and model for mobile feedback systems. Besides components for feedback provisioning, the model consists of components for data recording, storage and management. For the evaluation of the model, its features are compared against state-of-the-art frameworks. Furthermore, the capabilities are benchmarked using a review of the literature. We conclude that DMC is capable of modelling all 39 identified systems while other identified frameworks (MobileCoach, Garmin Connect IQ SDK, RADAR) could (at best) only model parts of them. The presented design paradigm/model is applicable for a wide range of mobile feedback systems and equips researchers and practitioners with a valuable tool.

1. Introduction

In sports, feedback is essential for athletes in order to learn new tasks and achieve better performance [1,2,3]. While traditionally, feedback was only given by coaches, the modern0day has seen the rise of computerised systems taking over parts of this task. These systems are usually referred to as feedback systems [4].

While, in general, their primary target is not to replace coaches [4], they can serve as a valuable aid for both athletes and their coaches. Digital systems have the potential to provide not only a transparent but also an objective and reliable process for recording and processing data. Additionally, they can help to identify behaviour that requires correction or improvement. Another benefit is that digital systems can also reduce the manual workload of coaches and athletes required for data acquisition, thus freeing time for in-person coaching or recovery.

In sports, feedback systems—in their broadest definition—have a wide variety of application areas. For example, athletes use them on a regular basis for recording their training and receiving summary statistics about it. These types of systems capture data such as kinematic data or heart rate. More sophisticated systems apply mathematical modelling, such as adaptations of the so-called fitness fatigue model by Banister et al. [5] to provide athletes with additional information on the effectiveness of their training. Additionally, they are also used for providing feedback on technique or task execution, thus helping athletes learn motor tasks [4].

Furthermore, feedback systems are also utilised for guiding data collection, e.g., for scientific purposes in controlled studies. For example, in (sport) science, sensors need to be evaluated outside the laboratory or controlled situations. A feedback system can not only be used to collect data in such scenarios but also help to improve data quality. For example, some participants in a study might face difficulties exercising at the correct prescribed intensities. In such cases, dedicated feedback can help athletes follow prescribed intensities [6], thus improving overall data quality.

The last decades have brought vast improvements in technology relevant to this field of application. In particular, the miniaturisation of sensors and enhancements in wireless technologies have created an enormous potential for feedback systems [7]. Furthermore, the enhanced battery life of sensors is another factor contributing to the ability to conduct studies not only in laboratory settings but also in real-world scenarios. This enhancement of battery life is also due to the development of wireless data transmission standards such as “Advanced and Adaptive Network Technology” (Ant+) or “Bluetooth Low Energy” (BLE).

Another challenge is that the currently available solutions are limited in their customisability and do not allow the modelling and creation of a wide variety of feedback systems. Current tools are often tailored for one specific sport (e.g., cycling) or type of sport (e.g., endurance sport) or type of feedback (e.g., terminal feedback by means of charts). Furthermore, they often rely on proprietary technology, thus hindering the ability to replicate experiments with other technologies. Yet another problem is that details concerning data protection and privacy, such as where data is processed and stored, are often not transparent.

This paper aims to answer the question of how researchers and practitioners can be aided in the creation of mobile sensor-based feedback systems. As a solution to the challenges discussed above, this article introduces Direct Mobile Coaching (DMC), a paradigm for the creation of mobile feedback systems. It allows modelling state-of-the-art applications for collecting and processing sports and motion-related data. Furthermore, its applicability to a wide variety of use cases is shown. The model addresses the challenge that the potential of novel technologies in sport science can often not be fully exploited by domain experts due to their complexity. The novelty of the approach lies in the combination of a model-based domain-specific abstraction layer, which enables the rapid building of feedback systems for various use cases without in-depth technical knowledge, with an open and highly adaptable technology layer that allows the integration of novel sensor and processing technologies without the limitations usually imposed by vendor-specific systems.

Consequently, this article describes the architecture and details of Direct Mobile Coaching. The model is then evaluated theoretically by means of a systematic literature review and compared against other feedback systems in order to investigate if and how meaningful a model such as DMC can be for sport science research. The article contributes to the field by (a) enabling sport scientists to directly model feedback systems based on their domain expertise and make use of modern sensor technology without the need for in-depth technical knowledge. Furthermore, (b) it allows for faster and easier development of practical applications. In addition, the proposed system avoids vendor lock-in and thus enables re-usability of system components, which can also contribute to sharing expertise about specific components (e.g., special sensors or algorithms) in sport feedback systems, enabling more efficient and effective development processes.

The remainder of this article is structured as follows. In Section 2, an introduction to feedback systems is given as well as an overview of the existing models. Section 3 presents our model DMC. In order to investigate the capabilities of the model, we have conducted a literature review, which is described in Section 4. Furthermore, Section 5 outlines the successful applications of DMC. In Section 6, we interpret the results, discuss challenges and outline the limitations of our analysis. Finally, Section 7 provides a conclusion.

2. Background

2.1. Feedback Systems

Feedback systems provide computerised feedback to athletes and coaches. They “acquire, determine and present information on the motor task performed which is not directly observable” [4]. A wide variety of different types of feedback systems exists, and, consequently, there are also different systems for their categorisation. One method of categorisation is based on the type of data to be used. Consequently, categorisations of feedback systems as video-based [8], audio-based [9] or even more general as sensor-based [10] systems exist. However, the categories have no clear-cut boundaries, e.g., a sensor-based system can also provide auditory feedback. Moreover, sensor-based systems can further be categorised into systems using sensors that are attached to either athlete, equipment, or both. In addition, feedback systems can be categorised/separated according to the information presented to the users. Most often, the systems are either designed to present information about the result of an action (“knowledge of result”) or about how a result was achieved or how a movement was made (“knowledge of performance”) [11]. However, similar to the categorisations presented above, the lines between the individual categories can be blurred, and a system often cannot be put into only one category.

Mobile feedback systems offer the ability to be deployed outside a laboratory. In order to enable this, they often make use of mobile platforms such as smartphones or tablets [12]. Additionally, using mobile and wireless sensor technology not only reduces interferences with the movements of the athletes (which is vital for any feedback system) but again allows mobility and measurements outside of laboratories.

Some modern sensor-based feedback systems employ—at least in some sense—the so-called “Mobile Coaching” (MC) paradigm [13] or variations and extensions of it. One example of this is the so-called “Mobile Motion Advisor”, a feedback system with the aim of motivating high school students during their physical activity by means of exercise instructions that are customised for each student [14]. This paradigm combines data acquisition methods with feedback functionalities in one system. A mobile device equipped with a client app for athletes collects data from various sensors and sends it to a server using a mobile internet connection. On this server, the data is processed and stored in a central database. An additional interface—the Expert-Client—provides coaches and experts with the ability to give feedback to the athletes in real-time or post hoc. While the feedback during the activity is a verbal message either generated by text-to-speech software or recorded and played back to the athlete, the post-hoc feedback can be realised via emails or simple text messages. This interface accesses the central database as well. Additionally, algorithms can be used in order to analyse data on the server in real-time and thus provide immediate feedback to the athletes on their movements or performances [15].

2.2. Related Work

There are several other frameworks or models that could be used for the creation of mobile feedback systems. While they do not directly propose design principles or their publication does not feature the term “model”, they are built to allow the creation of systems with a common architecture. Consequently, each of these frameworks also has an underlying model.

A domain similar to feedback systems for sporting applications is the domain of applications for mobile health (mHealth). In the field of behavioural change interventions, an approach similar to MC is followed by the MobileCoach framework [16]. Its main target audience is creators of digital health interventions that are modelled—using automata theory—as state machines. These machines aggregate user inputs and variables to states, which are used in combination with rules (the actual intervention) to interact with athletes/participants. Data from users/patients are collected in the form of surveys or text messages. Feedback in the form of text messages or additional/other surveys is provided using these state machines.

Another framework focusing on the scalability and security of mHealth applications is RADAR [17]. Its aim is to collect data from smartphones and wearables in near-real-time. RADAR offers several apps for collecting data from accelerometers or in the form of questionnaires, as well as a web-based platform for managing study participants and viewing data of a study.

As cycling and running are popular recreational activities, various feedback systems, such as bike computers and heart rate monitors, are offered by different commercial vendors. The manufacturer Garmin offers the possibility to extend the capabilities of some of their devices by using the “Garmin Connect IQ SDK” (GCIS) [18]. These devices record data from wireless sensors using Ant+ or BLE or sensors built into the device such as a Global Positioning System (GPS) module or accelerometer. Consequently, clients are restricted to certain Garmin devices. The Software Development Kit (SDK) can be used to extend the recording capabilities of the devices by adding additional “data fields”, to the data recorded by the device. Furthermore, visual feedback can be provided by creating “views”. However, the framework has only limited capabilities for providing feedback. For example, it does not allow arbitrary computations but only a restricted set of operations and limited access to data. Furthermore, it cannot be used to model systems with multiple athletes as no communication between devices, and the central server (other than uploading recorded data) can be modelled.

In summary, all frameworks presented above pose certain challenges when used for the creation of mobile feedback systems (see

Table 1. Challenges for potential first-time users.

Challenge	MoCo	GCIS	RADAR	DMC/PEGASOS
Target field	High	Medium	High	Low
Recording arbitrary data	NA	High	High	Low
Providing concurrent feedback	Low/NA	Medium	NA	Low
Providing terminal feedback	NA	Low/NA	Low/NA	Low
Programming Language	Low	Medium	NA	Low
Complexity	Medium	Medium	High	Medium
Extending capabilities	Medium	NA	High	Low

MoCo—MobileCoach, GCIS—Garmin Connect IQ SDK, DMC—Direct Mobile Coaching, NA—Not available.

). For example, their target field is not directly related to general mobile feedback systems but rather specific types such as endurance sports or mHealth. In the case of GCIS, the target field is within the domain of feedback systems but has a focus on specific types of systems. Furthermore, recording arbitrary data is often required when developing systems based on novel sensors that often do not offer data in standardised formats. Additionally, the frameworks can be challenging with regard to offered feedback modalities: for example, not all frameworks offer the ability to provide both concurrent and terminal feedback. A small challenge is posed by GCIS due to the reliance on the non-standard programming language Monkey-C. Especially for novices, the complexity of RADAR and its technology stack can pose a challenge. Furthermore, not all frameworks offer the possibility to modify or extend the capabilities.

3. Direct Mobile Coaching

As described previously in the original Mobile Coaching paradigm [13,15], feedback for athletes can either be sent by a coach or provided automatically by computer algorithms running on a server. However, since the computational power of mobile devices has increased over the last decade, parts of the algorithm in use could also be incorporated into the software running on the mobile client. While feedback by coaches can still be given remotely, the feedback provided by algorithms can now be computed on both the smartphone and a remote server. This is made possible by modern smartphones usually featuring a CPU using a multicore architecture, which allows applications to facilitate true multi-processing. Therefore, it is possible not only to capture data on the smartphone but also to analyse it and provide feedback at the same time.

However, using a server as proposed in the original Mobile Coaching paradigm still offers benefits. One example of this is large (relational) databases. When run on a (hardware) server, a database usually offers better performance, for example, providing shorter response times for queries. Additionally, any data recorded by athletes can be made accessible to coaches, experts and athletes when stored in a central database (on the server).

Hence, we propose “Direct Mobile Coaching”. This model is built on the idea of making use of the additional computing powers. Figure 1 illustrates the architecture of the system, each of the components is described in more detail in the following sections. In this model, a mobile client collects data from sensors (wireless, wired or built into the device). Data are sent by means of wireless communication (e.g., WIFI or mobile data) to the backend component of the server, where it is stored in a database. Additionally, a web-based frontend of the server offers different groups of users (e.g., athletes, coaches or experts) different views, such as reports, on the data. Feedback can either be provisioned using the remote components (c.f. Figure 2b) or directly on the mobile client (c.f. Figure 2a) by a “Controller”, which can communicate directly with the server. Remote feedback can either be provisioned by a human or a software module (labelled “AI” in Figure 1).

A further difference between MC and DMC is the clear distinction between the timeliness of feedback. Feedback is classified to be concurrent when it is provided to an athlete while they are exercising. A further type of feedback is so-called terminal feedback, which is provided after a movement or activity has finished. While MC does not incorporate such a distinction, DMC enables it in its model (Figure 2).

The proposed architecture and terminology for these modifications are as follows: While on the client, a controller is responsible for the computation of the feedback, on the server, the live computations are performed by components referred to as AI module (artificial intelligence modules). Additionally, after an activity that uses the feedback system is completed, one or more post-processing modules are scheduled to perform post-hoc analyses for the activity. Furthermore, after an activity has finished, a mobile client can also provide feedback by requesting additional data from the server. Each of these analyses can stem from simple computations of metrics, such as covered distance, to more sophisticated ones, such as estimating the maximal oxygen consumption based on data collected during a graded exercise test. Figure 2 outlines these terms and the feedback generation.

3.1. Mobile Client

Providing functions for both data collection as well as data presentation, the mobile client is the centrepiece of Direct Mobile Coaching. In the context of this paper, this client can usually be seen as a running app on a smartphone. However, other clients are also possible, and the model has no restrictions on the technology used for clients. Data collection is focused on data from sensors (see Section 3.2), which can be either integrated into the mobile device or attached to the device using wired communication protocols, such as USB, or wirelessly. Feedback can be given to the users using graphical elements on the display, vibrations of the device or the text-to-speech function of the device which the client uses. The client communicates directly with the backend server (see Section 3.4), using a high-level API-based interface. This design principle is different to previous implementations of the MC paradigm, such as the one by Preuschl et al. [14], where the app/client communicates with the server using low-level directives. In these previous implementations, individual data packets were created from scratch at various locations in the program logic and sent directly to the server using a socket connection. The high-level API of the current implementation is object-oriented. Consequently, data packets are created as objects without the necessity of accessing the data packets individually. Moreover, the socket for the communication is wrapped inside the API.

The framework enables the adaption of a client’s behaviour to different situations or “sports” via parametrisation. One part of this parametrisation or definition is the sensors (see Section 3.2) to be used during an activity with the feedback system. This list of sensors can be divided into required and optional ones. An activity of the feedback system can only be started when all the required sensors are connected. It is, furthermore, possible to define default views to be used during an activity with the feedback system provides a consistent user experience. These views are composed of several different value displays, for example, floating-point or integer values. Moreover, these value views can be configured to show values using graphical displays, such as a tacho needle, rather than numbers.

A further task of clients is to upload arbitrary additional data to the server asynchronously, i.e., after an activity has finished. For some sports, this is a requirement as it is not always possible to stream data during the recording for various reasons (safety of equipment, rules, etc.). Furthermore, as not all sensors have wireless interfaces, it is not always possible to live-record data during an activity. Consequently, this improves the generality of the model.

3.2. Sensors

The input data of the feedback system is modelled to be originating from sensors (e.g., heart rate monitors, accelerometers, strain gauges). There is no conceptual restriction to the connection type of the sensor and the number of used sensors. Furthermore, the term sensor is used in a broad sense, and a sensor could also be used to provide data in the form of a survey presented to an athlete. Additionally, a sensor could take the form of fitness equipment not worn on the body, such as smart indoor cycling trainers. Data from the client are pushed to the server using a high-level interface.

The model itself does not impose constraints on the number of sensors or their respective sampling rates. However, hardware limits such as the number of available channels for wireless communication between the mobile client and a physical sensor have to be considered during the design of a feedback system. For example, current smartphone hardware offers eight channels for ANT+ communication. Furthermore, not included in the model per se but in its implementation (see Section 3.8) are functionalities for joining data streams of different sampling frequencies.

3.3. Controllers

Controllers represent the interface between a feedback system and user. Thus, they form the computational component on the mobile client and can range from simple deterministic computations to full machine learning-based models. An example of a controller is the calibration of a so-called Foot Pod (A sensor, usually attached to the shoe of a runner, e.g., https://buy.garmin.com/en-MZ/ssa/p/15516 (accessed on 31 March 2022)) used for measuring distance during running. In order to obtain correct measurements, the values provided by the sensor are scaled using a factor dependent on the individual wearing the equipment. The determination of this factor is usually performed by running a fixed distance, e.g., 400 m, and then dividing this distance by the distance reported by the sensor. The controller for the calibration process can then work as follows: First, it asks the user for the distance used as a basis for calibration. Before starting the recording, it resets the stored calibration factor to a default value. After the user has stopped the recording, i.e., he or she has reported having completed the distance, it calculates the new calibration factor and stores it on the device. For every activity of the feedback system, exactly one controller is started. However, it is also possible to rely on default controllers, which offer no special interaction with the user. These controllers can be used, for example, when a feedback system is used only for recording and only displaying the raw sensor data. Moreover, it is not necessary to write a new controller for each scenario, as controllers can be parametrised and thus reused for different use cases. This parametrisation can also be part of the configuration of the menus of the mobile client. Additionally, a controller can intercept the communication from the server to the feedback system and thus react to incoming messages. It can set up additional views for the user or disable the default views as specified in the “sports” definition.

3.4. Backend Server

The backend server is responsible for data persistence and feedback generation. This means that all the sensor data sent by mobile clients are parsed and stored in a database. While conceptually, no limit on the type of used database is imposed, a relational database offers the benefit of being a well-established principle, which can thus be used by many practitioners. Having such a data persistence makes recorded activities reproducible. Additionally, collecting all the data on the server provides the opportunity to model and implement inter-client communication during or after activities without the need of an ad-hoc network between the individual client devices.

An additional function of the backend server is to provide the means for concurrent feedback by using AI modules and terminal feedback using post-processing modules. Each of these modules can be configurable for certain types of activities.

3.5. AI Modules

An AI module is started once the user begins a session on the client. In order to avoid race conditions, Direct Mobile Coaching restricts feedback systems to having only one module per activity. Race conditions could occur when two modules are trying to update the same value, e.g., points in a game, for an athlete. While such conditions can be avoided, the logic of the module will be more complex, and, furthermore, the required knowledge of the developer is also higher. This type of module can then communicate with the client using the API of the server. For example, the server can send text messages to the client, where they will be communicated to the user using text-to-speech software, for example. The communication between client and server or AI module is not fixed to a set of commands but can be extended to fit the needs of the feedback system. Consequently, no restrictions are enforced on transmitted data. However, bandwidth restrictions of mobile networks should be kept in mind by practitioners. An AI module is also able to send messages either to a single or multiple clients at the same time, which makes it possible to model interactions between users. Furthermore, feedback modules can access all the data transmitted from the client to the server.

Similar to the definition of controllers, AI modules are not restricted to the type of performed computations and thus can take the form of simple mapping operations, deterministic computations or performing machine learning operations. Hence, the term artificial intelligence here is used in a broad sense and does not only refer to the deployment of machine learning algorithms per se.

While, at first glance, an AI module might not seem necessary, their integration can provide benefits in many real-world scenarios. For example, some feedback systems might require extensive computation powers exceeding those of the client (e.g., a smartphone). In such scenarios, computations can be modelled to be performed on the server, as it is modelled in Mobile Coaching.

3.6. Post-Processing Modules

For every activity, several post-processing modules can be configured to be triggered. These modules will be invoked by the backend server once the user stops the activity or once it is closed due to a timeout. Example actions for such modules include computing statistics of the completed activity, such as determining the maximal and average heart rate. Moreover, post-processing modules can be used to upload data to other platforms automatically. This can be a vital ability when working with athletes such as cyclists who usually want their activity data stored on platforms such as Training Peaks (https://www.trainingpeaks.com/ (accessed on 31 March 2022)), Garmin Connect (https://connect.garmin.com/ (accessed on 31 March 2022)), Polar Flow (https://flow.polar.com/ (accessed on 31 March 2022)), Strava (https://www.strava.com (accessed on 31 March 2022)), etc.

3.7. (Web) Frontend Server

The frontend server provides access to the information stored in the database. This access includes providing means for having different views (e.g., reports, charts) of the data. Such a feature can be necessary for coaching situations where an athlete is under the supervision of several coaches, but not all coaches are allowed to see all the data. Another scenario where different views on the data are essential is intervention studies. Throughout such studies, researchers usually need to be able to track the progress of all participants, while each individual participant should only be allowed access to their own data. Moreover, being able to configure different views of the data can provide a better user experience. One example of such a scenario is that of novice users of the system (coaches, athletes, etc.) using the same system as experienced users. In these cases, views with different levels of detail can improve usability since users can gradually move from simple and less detailed views to more complex ones.

As part of the frontend, charting functionality can be offered to the users of the system. For example, Poincaré plots [19] can be used for the investigation of heart-rate variability data (Figure 3a depicts such a plot). Another example of these visualisations is line charts for viewing individual sensor data or comparing data of two sensors, as depicted in Figure 3b. Each feedback system can define several charts and display a different set of charts based on the activity type. Furthermore, more complex charts based on custom code can be added as well.

One common task in sport science is aggregating athlete data for monitoring and reporting purposes. The framework includes functionality for creating such reports. It allows visualising data based on extracted metrics and predefined aggregation operations (e.g., maximum, minimum, sum). Figure 3c depicts an example of such a report.

3.8. Implementation

In order to avoid having to reimplement large aspects of Direct Mobile Coaching for each feedback system, we created a framework called PEGASOS.

This framework allows researchers to create prototypes of Direct Mobile Coaching-styled feedback systems while focusing on the creation of prototypes rather than constantly reinventing complete applications. PEGASOS provides implementations of all aspects of Direct Mobile Coaching. It is made publicly available as an open-source project. The source code and information are freely available at a repository for the permanent and secure storage of digital assets (https://phaidra.univie.ac.at/view/o:912121 (accessed on 31 March 2022)).

The PEGASOS framework essentially consists of two parts: a code generator and implementations of the aforementioned DMC components. Most of the components can be customised using a graphical user interface also provided by the framework. This tool also aids users with the creation of the XML-based configuration used for the code generation of the feedback system. Furthermore, PEGASOS compiles generated as well as user-provided code together with provided components in order to create a feedback system. In order to provide continuous deployment and integration, PEGASOS is also made available as a docker image. Communication between client and server is realised using a binary TCP-based protocol allowing high throughputs. Sensitive information, such as passwords, is transmitted using asymmetric encryption. The backend stores data in a relational database and offers a role-based API, which can then be used for offering granular access to the data.

3.9. Data and Control Flow

Within DMC, responsibilities for managing data are divided as follows: On the mobile client, a central unit (in our implementation PEGASOS, the so-called Sensor-Controller-Service) is responsible for managing the sensors required for capturing the data of an activity. The collected data are then pushed into the controller running on the client, utilising a central interface, and also to the server. Additionally, when offline, data are stored locally on the client. On the server, data from the client persist in a database. Furthermore, when a client requests the start of an activity, the server starts the corresponding AI module. The AI module can then request data for this activity as well as user-related data from the server. Similarly, post-processing modules can also request data of an activity and request the server to persist the computed results. Furthermore, the client can request arbitrary data from the server anytime. For example, it can request user-related data from the server after athletes have authenticated themselves. This data is stored securely, not exposing sensitive data to third party applications but providing offline access to it, when no connection to the server is possible. The client can then use this cached data in order to provide parametrised feedback for athletes.

3.10. Example

In order to perform training at correct intensities, athletes and their coaches often employ performance tests. A recent study [6] evaluating the effects of different concurrent feedback variants on the ability of athletes to adhere to prescribed paces during a graded exercise test indicated that feedback systems have the potential to increase data quality in field tests as well as aiding data collection and processing. DMC can be used for modelling a feature-rich system for the purpose of performing performance tests.

The components of the system are outlined in

Table 2. Example of a DMC-styled feedback system.

DMC Component	Functionality
Sensors	Heart rate monitor, Foot Pod, GPS
Client	Smartphone
Controllers	Foot Pod calibration run
	feedback familiarisation
	trial run
AI module	trial run
post-processing module	data analysis
Database	relational database
Reports

. In the potential system, the mobile client is realised as a smartphone app and a commercially available heart-rate sensor (e.g., Polar H10 (Polar H10 sensor https://www.polar.com/uk-en/products/accessories/polar_h10_heart_rate_sensor (accessed on 31 March 2022)), Garmin HRM Dual (Garmin HRM Dual https://www.garmin.com/en-US/p/649059 (accessed on 31 March 2022)), Wahoo Tickr X (Wahoo Ticker X https://eu.wahoofitness.com/devices/heart-rate-monitors/tickr-x-buy (accessed on 31 March 2022)), etc.) and a Foot Pod sensor (e.g., Polar Stride Sensor (Polar Stride Sensor https://www.polar.com/uk-en/products/accessories/stride_sensor_bluetooth_smart) (accessed on 31 March 2022), Garmin Foot Pod (Garmin Foot Pod https://buy.garmin.com/en-MZ/ssa/p/15516 (accessed on 31 March 2022)), etc.) are used together with built-in GPS for collecting data. As part of the feedback system, three controllers were implemented: one for performing the Foot Pod calibration, one for familiarising participants with the feedback and one for performing the test. To further aid the data collection, an AI module would select an adequate initial speed for the test based on training history, previous tests or data entered by a person through the web-frontend. After a test, a post-processing module would analyse the test and, for example, determine thresholds or turning points. Athletes and their coaches could then assess the test using pre-configured views on the data, such as graphs of speed in relation to heart-rate. When using PEGASOS, the initial configuration and skeleton code for this system can be created within a couple of minutes using the provided tools.

3.11. Experiment

Muscle–Oxygen kinetics provide a different insight into the physical abilities of an athlete. Fortiori Design proposed the so-called “5-1-5” assessment in the manual of their so-called “Moxy sensor”, a sensor targeted at measuring muscle oxygen saturation as well as haemoglobin concentration [20]. The authors claim that this assessment can be used to derive training intensities based on the oxygenation dynamics during the assessment. The protocol is completed once “continuous and sharp decline” [20] in the oxygenation values is observable. Although visual inspection as posthoc analysis could easily determine the moment where this decline starts, it can be expected that this is a hard task during the assessment, especially since most displays will show the measured values only as numbers rather than a chart. The recovery of the oxygenation values between the stages makes this live analysis even harder. Moreover, if the initial load for the assessment is set too high, no meaningful analysis can be performed.

Therefore, in order to provide athletes and coaches with an easy-to-use tool, a feedback system employing the principles of DMC was built using PEGASOS. The created app was configured to record data from power and heart-rate sensors in addition to the Moxy sensor. Furthermore, it was programmed to perform checks on whether the initial load was too high automatically. Additionally, whenever this “continuous and sharp decline” is detected, the system will end the test for the athlete. During the execution of the test protocol, the controller on the smartphone app guides the cyclist through the assessment, displaying targeted as well as actual power and remaining time in the individual stages of the assessment. The AI module on the server checks whether the end-point has been detected, the assessment is being performed wrongly, or another stage has to be completed. After the assessment is finished, a post-processing module generates a report that can be downloaded by the cyclist or coach. Furthermore, all recorded data can be viewed using the web-frontend as well.

An implementation of a similar system was also performed using GCIS (See https://apps.garmin.com/en-US/apps/f9efbc01-b8b2-4d8c-8073-1167a3aefb4b (accessed on 31 March 2022)). While having similar functionalities during the activity, two differences can be observed: (1) settings for the test and (2) post-hoc analysis are limited within GCIS. While using PEGASOS, it is possible to create custom views for displaying the data; users of the GCIS app need to convert the recorded data into a spreadsheet and perform their analysis manually (See https://www.youtube.com/watch?v=xIxvONa4vLc (accessed on 31 March 2022)). The automated detection of thresholds that can then be used for the creation of workouts cannot be realised.

Due to the nature of the models, such a system could not be created with either MobileCoach or RADAR. Consequently, no comparison was made for these cases.

4. Literature Review

Section 2.2 has identified three models that pursue similar aims as DMC, but differ in their abstraction approaches, the degree of their generic applicability and their target groups. In order to show the applicability of the proposed model to a wide range of possible applications, a systematic review of the current literature was performed. It is described in the following subsections and follows the guidelines of “Preferred Reporting Items for Systematic Reviews and Meta-Analysis (PRISMA)”. This review aims to answer the question of whether state-of-the-art research applications can be modelled using DMC. A flow diagram outlining the process of the review is presented in Figure 4. To the best of the authors’ knowledge, no comparable review of current feedback systems or a database of systems which could have been used for benchmarking exists.

4.1. Information Sources

The sources used for the review were divided into primary (databases) and secondary (conference proceedings and specialised journals). In order to feature state-of-the-art technology, the search was limited to 2018 to 2021.

The primary databases searched were the ACM library, MDPI and Web of Science. Search strings and filters used, as well as dates of the search, are listed in

Table 3. Primary sources used for the review.

Source	Search	Date
ACM	[[All: “feedback system”] OR [All: “remote coaching”]]	8 September 2021
	AND [All: sport] AND [All: sensor*] AND [Publication
	Date: (1 January 2018 TO 31 August 2021)]
MDPI	“feedback system” AND sport	8 September 2021
	“remote coaching” AND sport
	Publication Year Filter 2018 to 2021
Scopus	(ALL(feedback system*) OR ALL(remote coaching)) AND ALL(sport) AND	8 September 2021
	ALL(sensor*) AND PUBYEAR > 2021
Web of Science	(((ALL = (“feedback system”)) OR ALL = (“remote coaching”) OR	8 September 2021
	ALL = (“sensor validation”)) AND ALL = (sport)) AND ALL = (sensor*)
	Index Date Filter 1 January 2018–31 August 2021

.

Since, in technology, novel research results are often only presented at conferences, the grey literature from conferences and specialised journals were used as a secondary source. For this purpose, articles from the journals “International Journal of Computer Science in Sports” (IJCSS) and “Sports Engineering” for the years 2018–2020 and issues available in August 2021 were included in the search. Furthermore, records from the proceedings of conferences of the “International Sports Engineering Association” (ISEA) and “icSports” for the years 2018–2021 were included as well. The selection of sources was based on their impact on the research community, as well as the domain and target audience of the journal or conference. Consequently, the sources should provide a representation of recent research efforts being made in the field of sports and technology. What is more, the inclusion of secondary sources acts as a measure to counterbalance potentially missing relevant articles due to differences in nomenclature. All records from secondary sources have been extracted and then investigated without any key word search. For example, while this article uses the term feedback system, other publications might refrain from using this term and, consequently, would not be included in search results. This would, however, potentially bias the results in favour of Direct Mobile Coaching as it was designed based on the literature and existing systems using exactly this nomenclature and principles.

4.2. Inclusion and Exclusion Criteria

Studies were included when they reported using sensors for either (1) providing athletes with concurrent feedback, (2) producing terminal feedback in various forms (e.g., parameters of a model) or (3) showing their validity.

A study was excluded if it (1) represents a so-called sport information system, e.g., systems tailored for game analysis. While metrics generated by such systems can—when based on individual performances—be seen as feedback, such systems have been excluded to have a clear focus and scope of the review. (2) It uses pre-recorded data or is based purely on simulation for modelling purposes. For example, studies using historic race data (collected by sensors) to predict future racing outcomes were excluded from this analysis. This type of system can be modelled using DMC by modelling the data import as an agent and the prediction model as a post-processing module. However, such systems cannot be modelled with MobileCoach, RADAR or GCIS. (3) The study does not have sporting applications as its primary target, thus excluding articles focusing on aspects such as activity recognition during the whole day (where sport is not the main focus of the investigation). (4) The primary subjects were not human (e.g., studies investigating systems for horse racing). (5) The publication date was outside the timespan from 2018 to 2021. (6) It was not written in English. (7) The full-text was not available.

Furthermore, during the analysis, full-text articles were excluded when they were (1) out of scope, i.e., did not meet inclusion criteria, or (2) did not present sufficient information on either the feedback provided or how the data was recorded and processed (Lack of Details).

4.3. Categorisation

In order to allow for a more in-depth analysis, the results were categorised into one of the three following categories of applications of sensor-based feedback systems.

4.3.1. Feedback Systems Providing Concurrent Feedback

This type of system provides athletes with feedback during their exercise. For simplicity reasons, we will refer to these systems as “feedback systems” in the results section. In studies presenting such systems, a clear representation of the model for collecting and processing data is not only helpful to potential readers in understanding the design but also ensures that all relevant information is presented. For example, it is desirable to have detailed information on the type of sensors used, their mode of data transmission and how the data are stored. Furthermore, a clear description of how, when and where (in the architecture of the system) the feedback is computed is required in order to ensure transparency for users (athletes, coaches and researchers) of the systems and, in the case of publications, the scientific community.

4.3.2. Sensor Validation Studies

As part of the scientific publication of newly developed sensors, their reliability and validity are usually presented as part of a validation study. In such studies, a sensor is compared with another sensor or method of measuring representing the gold standard or with an upfront determined ground truth. Usually, these studies present technological advances that can be used in the future to provide athletes with insights about their performances. These insights can range from “simple” metrics or visuals, such as descriptive statistics (min, max, mean) of heart-rate, speed, power, steps, jumps [21,22,23], to more complex visuals, such as Poincaré plots [19]; analyses of cycling power over fixed time periods [24,25,26]; or even mathematically derived measures, such as TRIMP scores, “training load” or stress scores (e.g., [22,23,27,28]). When classified as a pure sensor validation study, the paper usually does not give insights in how the information can or should be presented to athletes.

4.3.3. Feedback Systems Providing Terminal Feedback

Feedback cannot only be given during an exercise but also after an activity or task has finished. In this case, it is referred to as being “terminal”. For the analysis in this paper, we will again use a broad definition of terminal feedback and include various aspects of motor tasks for which feedback can be provided. Further, we will not restrict studies to whether computed values/feedback are intended to serve athletes, their coaches or whether they are derived for scientific investigations. Consequently, for this type, a broad definition of feedback is used, which also contains abstract values, e.g., metrics about muscle fatigue (in contrast to definitions restricting feedback to categories such as “visual” or “auditory”).

4.4. Results

4.4.1. Search Results

As outlined in Figure 4, a total of 724 articles were identified: 165 articles were identified in the search using primary sources (ACM: 76, MDPI: 74, Scopus: 1, Web of Science: 14) and 599 through secondary sources (IJCSS: 49, Sports Engineering: 114, ISEA: 295, icSports: 101). Next, duplicates were removed, which left 713 records for screening. After reviewing titles and abstracts, full-texts of 114 studies were assessed for eligibility. A total of 67 studies were excluded as they were out of the scope of the review as defined in the inclusion and exclusion criteria, and a further 8 studies were removed due to a lack of information on feedback provisioning or system architecture. Consequently, a total number of 39 studies were included in the review. Their characteristics are listed in

Table 4. Summary of studies. Study types: Concurrent Feedback (CF), Sensor Validation (SV) or Terminal Feedback (TF).

Study	Source	Sport	Sensors	Type	DMC	MoCo	RADAR	GCIS
Aranki et al. [29]	MDPI	Running	Heartrate, Accelerometer, GPS, Video	TF	✓	✗	Partial	Partial
Janssen et al. [30]	MDPI	Running	Heartrate, GPS	CF, TF	✓	✗	✗	✗
Kobayashi et al. [31]	MDPI, ISEA	Baseball	IMU	SV, CF	✓	✗	✗	✗
Przednowek et al. [32]	MDPI	Basketball	Video	SV, TF	✓	✗	✗	✗
Reh et al. [33]	MDPI	Walking	IMU	CF	✓	✗	✗	✗
Örücü et al. [34]	MDPI	Weightlifting	Kinect	TF	✓	✗	Partial	✗
Bonaiuto et al. [35]	MDPI	Kayaking	IMU, GPS, straingauge	TF	✓	✗	Partial	✗
Biesmans & Markopoulos [36]	MDPI	Walking	Touch/Pressure	CF	✓	✗	✗	✗
Mat Sanusi et al. [37]	MDPI	Table Tennis	IMU, Kinect	TF	✓	✗	Partial	✗
Smyth et al. [38]	MDPI	Cycling	optoelectronic plethysmography	CF	✓	✗	✗	✗
Dong et al. [39]	MDPI	Rope skipping	Gyroscope	CF, TF	✓	✗	Partial	✗
Umek & Kos [40]	WoS	Swimming, Kayak	IMU	TF	✓	✗	Partial	✗
Kos & Umek [41]	WoS	Skiing	IMU, force, bend	TF	✓	✗	Partial	✗
Yokota et al. [42]	WoS	Cycling	IMU	CF	✓	✗	✗	✗
Kos & Umek [43]	WoS	Swimming	IMU	TF	✓	✗	✗	✗
De Brouwer [44]	ACM	Cycling	Heartrate	CF	✓	✗	✗	✗
Lorenzoni et al. [45]	ACM	Running	Accelerometer	CF	✓	✗	✗	✗
Elvitigala et al. [46]	ACM	Weightlifting	Pressure Sensitive Insole	CF	✓	✗	✗	✗
Ohnishi et al. [47]	ACM	Running	Pressure sensor	CF	✓	✗	✗	✗
Ehab & Mohamed [48]	ACM	Swimming	IMU	CF, TF	✓	✗	✗	✗
van Delden et al. [49]	ACM	Rowing	Ergometer, Video	CF	✓	✗	✗	✗
Hoffard et al. [50]	ACM	Skiing	IMU	CF	✓	✗	✗	✗
Fang et al. [51]	ISEA	Skijumping	IMU	SV, TF	✓	✗	✗	✗
Jeong et al. [52]	ISEA	Kendo	pressure sensor	SV, TF	✓	✗	✗	✗
Anderson [53]	ISEA	Climbing	Straingauge	CF, TF	✓	✗	✗	✗
Litzenberger et al. [54]	ISEA	Cycling	Accelerometer	SV, TF	✓	✗	Partial	Partial
Lanotte et al. [55]	ISEA	Swimming	Pressure sensor, IMU	SV, TF	✓	✗	✗	✗
Chew et al. [56]	Sports Eng	Running	IMU	CF, TF	✓	✗	Partial	Partial
Yoshikoka et al. [57]	Sports Eng	Alpine Skiing	IMU	TF	✓	✗	✗	✗
Moon et al. [58]	Sports Eng	Skiing	GPS, IMU, pressure	SV, TF	✓	✗	✗	✗
van Houwelingen et al. [59]	Sports Eng	Swimming	Camera	SV, TF	✓	✗	✗	✗
Wolf et al. [60]	Sports Eng	Cycling	GPS, bike sensors (power, speed)	CF	✓	✗	✗	Partial
Rymut et al. [61]	icSports	Running	Camera	SV, TF	✓	✗	✗	✗
Matsumura et al. [62]	icSports	Alpine Skiing	IMU, plantar pressure	SV, TF	✓	✗	✗	✗
Ranaweera and Silva [63]	icSports	Bowling	IMU	SV, TF	✓	✗	✗	✗
Eizentals et al. [64]	icSports	Running	Pressure Sensitive Insole	SV, TF	✓	✗	✗	✗
Stamm and Shlyonsky [65]	icSports	Swimming	IMU	SV, TF	✓	✗	Partial	✗
Lin et al. [66]	IJCSS	Table Tennis	Surface EMG	TF	✓	✗	✗	✗
Nagy et al. [67]	IJCSS	Kayaking	EMG, Force	SV, TF	✓	✗	✗	✗

.

4.4.2. Description of Studies

The identified studies focused on various sports and fields of application: running or walking [29,30,33,36,45,56,61,64], (alpine) skiing [41,50,55,57,58], ski jumping [51], baseball [31], table tennis [37,66], swimming [40,43,48,55,59,65], basketball [32], kendo [52], bodybuilding or weightlifting [34,46], cycling [38,42,44,54,60], kayaking [35,40,67], rope skipping [39], bowling [63], rowing [49] and climbing [53]. The majority of analysed studies (27) provided terminal feedback, 17 provided concurrent feedback and 14 involved sensor validation. A total of 20 were labelled with a single category, while 19 were assigned to two. For each study, we examined whether it could be implemented with either of the discussed frameworks. The results are summarised in the rightmost four columns in Table 4 and are discussed in more detail in the following sections.

4.4.3. Results for DMC

We found that all 39 identified studies could be modelled using DMC. Furthermore, we found that one study [60] employed DMC directly by implementing their system using PEGASOS, as will be discussed below (see Section 5).

Due to the fact that DMC imposes no restriction on which sports can be modelled, it is applicable to all identified studies. Furthermore, since there are also no restrictions on the type of sensors—i.e., arbitrary sensors and connections can be used—the studies are well within the specifications of the model. Additionally, studies, such as [58], where the data collected during a training session are stored on a mobile device and analysed for feedback provisioning after the session has ended, can also be modelled. However, a further automatisation of the data collection and processing process featuring an automated upload after a session has ended or whenever a connection to the server is possible would not only exploit the power of DMC but also be more user-friendly. Furthermore, since the model allows providing concurrent as well as terminal feedback or both, it is applicable for this aspect of all identified studies.

However, one study [39] would potentially require some relaxation on the model as it seems to feature multiple clients with different functionalities. In this study, one client is used for collecting the data (jumps/skips performed by a child), while a second client is used by a parent or study supervisor to investigate and visualise the progress. By altering the design of the system such that the monitoring is performed using the web interface, the study is again well within the limits of DMC. Alternatively, by modelling a feature-rich client offering users access to both functionalities (data recording and monitoring), the model is also applicable. However, doing so might potentially decrease the usability of the feedback system.

4.4.4. Results for GCIS

We found that for most investigations, GCIS was not applicable. Only for four studies [29,54,56,60] did we find that at least part of the system could have been modelled using GCIS. The main reasons for the inapplicability of GCIS to the investigated studies were (1) the lack of arbitrary sensors or (2) the lack of abilities for data analysis or terminal feedback. The majority of studies relied on sensors that used either wired communication (as opposed to wireless in the form of, e.g., ANT+) or recorded data offline. As a consequence of this, these studies cannot be modelled using GCIS.

In the three mentioned cases, it should be—at least partially—possible to model the respective study with GCIS. As most of these studies [54,56,60] all featured standard sensors for either running or cycling, the data recording part of the studies can be implemented with the model. However, not all of the data analysis required in all cases could have been performed inside the ecosystem of GCIS. For example, in [54], data from an accelerometer were used for classifying the road surface. While using a trained classifier is possible inside GCIS, its training using machine learning algorithms would require exporting data out of GCIS into a different system. Moreover, some elements of RunningCoach [29], such as providing athletes with customised cadence trajectories, can only be partially realised within GCIS.

4.4.5. Results for MobileCoach

We found that none of the investigations could be realised with MobileCoach. One reason for this is the missing feature or component in the model for sourcing data other than chats or questionnaires. Consequently, most investigations cannot be realised due to the fact that they require collecting data from sensors such as Accelerometers or IMUs.

The second reason for the negative results concerns data handling. While DMC allows storing arbitrary data, MobileCoach seems not to have this ability. This means that in order to store data from sensors, for example, the model of MobileCoach needs to be changed. Furthermore, it seems that the model does not incorporate the ability to perform arbitrary computations based on recorded data.

4.4.6. Results for RADAR

We found that some investigations [29,34,35,39,40,41,54,56,65] could be at least partially realised with RADAR. However, none can be implemented with all features. The root cause for this might be the intended field of application of the framework: systems for mHealth. One particular drawback of RADAR over DMC is that a component for the provisioning of concurrent feedback is missing.

5. Applications of DMC

In this section, we present successful applications of Direct Mobile Coaching in different scenarios. While two applications were aimed at investigating the effects of feedback on the ability of athletes to adhere to performance tasks, two further systems were developed to help athletes with their pacing. Furthermore, we present a system for increasing the motivation of students to exercise more.

In two recent studies [6,25], DMC/PEGASOS has been used as part of the investigations into the effects of different types of feedback on the ability of athletes to adhere to heart-rate, power or speed targets during cycling or running activities. Due to the fact that both studies investigated the effect of visual, tactile or auditory concurrent feedback, they could not have been modelled with MobileCoach or RADAR. A further factor for the selection of DMC as the underlying model was that both MobileCoach and RADAR do not have a concept of a session or trial that was necessary for the studies and the data analysis. Parts of the studies could have been implemented with GCIS. However, modelling the data analysis would not have been possible.

Furthermore, a feedback system providing athletes with a pacing strategy during uphill cycling time trials has been developed using DMC/PEGASOS, and its usefulness has been investigated as part of several studies [60,68]. As shown above, for [60] and also for [68], the feedback system used in the evaluation study cannot be fully modelled directly using the frameworks from related work. Another feedback system with the aim of helping runners to improve their running performance by providing them with a pacing strategy based on their current level of fitness was also developed using DMC/PEGASOS [69]. For these studies, DMC proved useful as the complexity of the model was reduced. Furthermore, the usage of PEGASOS allowed for rapid prototyping of the system and reduced overall lines of code.

As part of the “Te(a)chIn Sport” project, a system allowing young people and students to compete against each other in running games was created [70]. In order to make these games more appealing, points were awarded based on relative performances, i.e., performances were scaled based on estimated fitness levels. These estimations were based on a graded exercise test performed by the athletes. Tests and games were modelled using DMC and implemented using PEGASOS. An implementation with GCIS, MobileCoach or RADAR would not have been possible due to—among other reasons—the fact that modelling multi agent systems with interactions is not feasible with these systems.

6. Discussion

6.1. Broad Range of Application Areas

The results of the literature study show that DMC is able to model a wide variety of different studies. This means that its users are not restricted by the model and are not required to learn it for a “one-off project”. Due to the wide range of application areas, DMC users should be able to transfer knowledge gained in one project to similar future projects, as the model could be used there as well. As a consequence of this, it can be expected that development times are decreased due to enhanced knowledge about the model. It can be expected that more proficiency in the applicability of the model can decrease development times.

6.2. Data Collection

As a direct consequence of the first result, a second result from the literature review is that DMC can be used to model almost all analysed data collection/sensor validation studies. Having a clear view of how to model the data collection process can help its users to focus on the essential parts of the development with regard to data collection. This can potentially also increase the reproducibility of studies as it increases the transparency about underlying models. Therefore, DMC can also help researchers report essential information.

A further benefit of the model is that it allows the collection of arbitrary data and the creation of complex interfaces for users/athletes. This can be useful, for example, when the annotation or contextualisation of data is necessary. For example, when using DMC, the data collection in the study by Litzenberger et al. [54] could have been changed to feature different roads with varying road surfaces. Instead of manually annotating the data with the road surface, an athlete could perform this while riding using a specially created interface on the client. Such a feature would only be partially possible with GCIS as the integration of arbitrary data is not possible, and, furthermore, the capabilities of extending the user interface are limited.

6.3. Privacy and Data Protection

In the domain of medical and sport sciences, the declarations of Helsinki [71] and Taipei [72] include regulations on how studies should be conducted. While the former concerns general principles for conducting research involving humans, the latter lays down principles for “health databases” (“systems collecting, organizing and storing health information” [72]) and thus also includes studies where information about movement is collected. Both declarations include the principle that any participant at any time can request the complete removal of their data to be withdrawn from the study. Consequently, the use of proprietary technology can be a potential problem, as control over data replication is not always possible. GCIS is a commercial product with a proprietary server and cannot serve as a database for all types of studies as it is not clear how the data are stored and backups are created. The models of DMC, as well as MobileCoach and RADAR, allow running a database with restricted access to data, thus being compliant with data privacy and ethical standards. DMC further incorporates the concept of roles, which can be associated with access privileges to data, thus providing further possibilities when used in large scale studies.

6.4. Models for the Reduction of Complexity by Abstraction

DMC aims to provide practitioners with a tool for modelling complex systems. It does so by equipping its users with the ability to describe a complex system in simple terms and focus on the interaction of its individual components. Such reductions in complexity can potentially help novice users, as designing a system of this complexity can be a hard task, not only for programming novices but also experienced ones, as abstraction is not trivial to teach [73]. As DMC’s target audience is in the domain of sport science, it can be assumed that not all prospective users have a high proficiency in modelling and system design and thus can benefit from such a model. This behaviour is to a lesser degree (due to their conceptual restrictions) also present in MC and MobileCoach. Due to the required architecture of systems created with GCIS, abstraction cannot be applied rigorously.

6.5. Making Use of Technological Enhancements

A further benefit of abstraction and decomposition is that changes to individual components can be made in order to reflect changes in technology without impacting the overall system. The architecture of DMC makes it possible to change the underlying components or their implementations in software or hardware in order to reflect changes or enhancements in technology. While such changes might not be necessary for a“short-duration” research project, such changes are often required for (commercial) applications with life cycles over several years. Due to the required proprietary hardware, this is hardly possible for GCIS and is also hindered due to “breaking changes” introduced with new versions of the hardware or software stack. For MC and MobileCoach, the restrictions on the systems should allow the making use of some advances in hardware and software.

6.6. Limitations of the DMC Model

While the results of the systematic review show excellent applicability of the model, it is evident it cannot be applied to all types of systems in the sports domain. For example, two systems [74,75], collecting and aggregating data for several athletes at the same time, were identified that cannot be modelled using DMC. The study by Figueira et al. cannot be modelled directly, as in this system, a single sensor collects data for all athletes at the same time [74]. For a similar reason, the study by Perez-Diaz-de-Cerio et al. also cannot be realised within DMC since, in this investigation, sensor nodes collect data about several athletes at the same time [75].

The model could be generalised further to allow clients to record data for several athletes at the same time. This would allow the modelling of studies such as [74] using DMC. Furthermore, this would also allow the modelling of [75] when no restrictions on the number of clients acting on behalf of/for an athlete exist. However, such relaxations of the model would potentially increase the software components used for (a) provisioning concurrent feedback and (b) user interfaces on the mobile client. Furthermore, this would reduce the ability of the client to provide feedback to individual athletes.

Further relaxation of the model could allow clients with different behaviours (although not strictly forbidden in the present version). This would allow the modelling of more complex feedback systems in which specialised clients exist. This is in opposition to feature-rich clients, which potentially do not offer the desired usability. One example where this relaxation would allow better usability is [39], where different clients for parents and children could exist.

Certain types of studies require importing or including data from other recording platforms, such as Training Peaks, Garmin Connect, Polar Flow or Strava, directly. For example, for some investigations, it is not feasible to require athletes to record data with a feedback system in addition to their respective device of choice for data recording (e.g., a cycling computer or sport watch). However, these devices are usually set up to upload data to a third-party platform, which often provides interfaces/an API for data access. DMC can still be applied in such scenarios by modelling the tool for importing the data from other platforms as a sensor or even directly as the client. Although modelling might be easier in the latter case, the terminology of the model would be confusing and possibly multiple types of clients would have to exist within the same system. As a consequence of this (non-DMC clients), this type of system would not be able to use the full potential for feedback provisioning of DMC. For example, in most cases, no concurrent feedback can be given as most commercial third-party platforms do not allow data to be streamed in real-time.

6.7. Lack of Feedback System Studies

One limitation of the study is that the results obtained in the literature review were biased toward sensor-validation studies. Since the purpose of Direct Mobile Coaching is to model feedback systems; this possibly limits the generality of the result that DMC can be used to model a broad variety of feedback systems. However, this bias stems from the publications available in the sources analysed, which could be seen as representative for current trends in research. Nevertheless, all investigated studies that were classified as feedback systems could be modelled using DMC. One reason for the low number of studies evaluating feedback systems might be the lack of a model with the capabilities of DMC. Researchers, especially those with lower technical background, might be put off by the task of devising a system with no or little tool support. However, in most cases, it is currently necessary to build systems from scratch as frameworks having the necessary features are not broadly available.

Some investigations, such as the investigation by Lin et al. [66], presented their research only theoretically and not in the form of an evaluation study of the feedback, for example, whether the feedback leads to improvements in the performances of the athletes. Again, the reason for this might be the lack of a suitable model, such as DMC, and an accompanying framework guiding the creation of the feedback system for the evaluation of the underlying model (by Lin et al. [66]).

6.8. Lack of Comparable Models

The results of the literature review show a favourable picture for DMC as MobileCoach, RADAR and GCIS fail to cover the use cases described in the studies. Consequently, it could be argued that the systems are not well suited for comparison. However, the availability of comparable artefacts (such as the reviewed systems) is impacted by the maturity of the application domain [76]. In our specific case, one can identify technically mature solutions (such as MobileCoach, RADAR and GCIS), which, however, do not (yet) fully address the requirements of a quickly evolving and still immature application domain. In that sense, while we can build upon mature solution components and concepts (as presented in the existing systems), we go beyond them in terms of system features to satisfy the requirements of the novel application domains [76].

6.9. Mobile Health

Another area where feedback systems are used is mobile health (mHealth). Similar to feedback systems for sporting applications, these applications can address a wide variety of challenges, such as behaviour change or assisted living combined with remote measurement technologies. Behaviour change applications can involve becoming more conscientious [77], reducing chronic pain [78], reducing alcohol intake [79] or promoting weight loss [12]. In assisted living, mHealth technology has been shown effective of monitoring patients with cardiac [80] or neurological [81] conditions or stroke patients [82]. Due to their ubiquity, smartphones are often used as mobile recording devices in mHealth. While it is most likely that most mHealth applications can be modelled using DMC, it has to be pointed out that models specialised for this area, such as MobileCoach [16] and RADAR [17], are likely better suited.

7. Conclusions

In this paper, we presented the model Direct Mobile Coaching as an extension of Mobile Coaching. We discussed the concepts and elements of DMC and presented several example feedback systems and their characteristics. The model provides researchers and practitioners in the sport science domain with a tool that allows them to model most of the types of modern feedback systems. A system modelled using DMC will consist of a mobile unit (e.g., a smartphone), sensors connected to this unit and server components (backend and frontend). Concurrent feedback can be provided using one or both of the respective components: a “controller”, which runs directly on the device, or an “AI module” running on the server. It is also possible to model communications between controllers and an AI module, which allows multi-agent systems (e.g., athletes competing in real-time against each other) to be created with DMC. Furthermore, terminal feedback can be provided through one or more “post-processing modules”. Data recorded during an activity are sent to the backend server, where it is stored in a (relational) database. This also enables the provisioning of various charts and reports via a web-interface/frontend.

Furthermore, we showed that various types of systems in the field of sport science can be modelled using Direct Mobile Coaching and provided examples where DMC and PEGASOS have been used as part of scientific studies. From this, we conclude that DMC is a valuable concept for researchers and practitioners in the domain of feedback systems in sports.

One limitation of DMC is its emphasis on sensor-based systems. This concerns, for example, feedback systems where data originates from a (proprietary) third-party platform, i.e., where data are not collected via the mobile client but, for example, originates from a third-party platform that does not offer access to live data. Due to these technical restrictions of such platforms, DMC cannot be used without modifications to model such systems when concurrent feedback is desired.

Future work will include applications of DMC as part of scientific investigations of feedback in sports. Furthermore, the training of sport scientists in modelling feedback systems using DMC could be conducted. Investigations into the effectiveness and outcomes of teaching model-based abstraction using DMC to sport science students could provide insights into gaps in existing sport science curricula (c.f. [83]). Additionally, an investigation of PEGASOS, the framework implementing DMC should be conducted.