1 Introduction

In sports, feedback is essential for athletes of all levels in order to learn new tasks and achieve better performance [1,2,3]. On the one hand, it can originate from “internal sources”, i.e. the nervous system of an athlete [4] and be referred to as intrinsic feedback. One example for this are the movements of an athlete as perceived by themselves. Alternatively, it can be given from an external source, which is then called extrinsic feedback [2, 5]. Other sources refer to this type of feedback as “augmented feedback” [4].

Extrinsic feedback can be of different forms: visual, auditory, haptic, and multimodal [2, 6,7,8,9,10]. The presentation of feedback, irrespective of its form, is often referred to as display and not constrained to the presentation of visuals [2]. Visual feedback can range from simple displays, such as presenting athletes with numeric information, to slightly more complex displays, such as the visualisation of deviations from target values, to complex displays visualising information as e.g., heatmaps or self-organising maps (SOM) [11]. Auditory feedback, on the other hand, can be given in the form of sounds played to the athletes when measurements are below or exceed a certain threshold. Additionally, verbal instructions—which are sometimes provided by text-to-speech software—are also common. Furthermore, more elaborate displays involve the modification of rhythm, pitch or loudness and are thus often referred to as sonification [2, 9, 12]. Haptic feedback also has a broad spectrum reaching from simple tactile cues to more complex scenarios or even robots assisting motor learning [8, 13, 14]. While simple tactile cues are often given using vibration motors, more complex feedback can be given using specialised machinery providing specified resistance in order to aid movements [14].

Another important categorisation concerns the timeliness of feedback: concurrent feedback is given during an activity, while terminal feedback is provided after an action has been performed [2]. In the context of motor learning a further categorisation regards the information or knowledge provided by the feedback and provides the categorisations “knowledge of performance” and “knowledge of result” [4]. While the former provides information on how a task was performed (e.g., in soccer, how the ball was kicked), the latter concerns the outcome of a task, (e.g., whether a valid goal was scored)

Feedback is not only given by coaches to athletes but also with the help of technical devices. Sociotechnical systems providing feedback to athletes and their coaches are usually referred to as feedback systems [15]. Due to the different modalities of feedback and capabilities of current sensor and processor technology, a wide range of systems and areas of application is possible. Feedback systems can be categorised in different ways, for example, based on their primary source of information used for creating the feedback or mode of providing the feedback. However, also more general categories exist. For example, a system can be categorised as sensor-based i.e a system which provide feedback based on data collected by arbitrary sensors [16]. It has to be pointed out that often a system can be categorised with more than one type, e.g. a sensor-based system which also provides video feedback.

Owing to advances in technology, the potential of feedback systems has increased over the last years. The last two decades have seen vast improvements not only in computing power but also in miniaturisation and widespread availability of wireless communication technology. This also entails that more and more sensors are developed, which are also getting lighter and more energy-efficient. Consequently, sensor systems can often be powered by coin-cells or other small and light-weight batteries. These developments enable the creation of more and more complex feedback systems with better usability. Furthermore, they have also enabled the possibility of using mobile devices such as smartphones, tables and smartwatches as a building block for feedback systems.

However, creating a feedback system offering adequate usability from scratch is still a complex task. First, a difficulty is the amount of tasks or use-cases required to be implemented. For example, in order to provide a good user experience, the pairing of sensors to the mobile unit needs to be self-explanatory and thus requires extensive engineering and user testing. Secondly, modelling the overall system can also be a challenging task, especially for researchers and practitioners from non-technical disciplines. Third, another challenge is addressing different modalities of feedback. Research such as [2, 8] has shown the importance of multimodal feedback in sports. However, designing multimodal feedback is not trivial since,for example, haptic experiences differ between people [17]. Furthermore, the coordination of different modalities presents complexities in terms of timing [18], synchronisation [19], and context [17]. For instance, combining speech recognition with gesture recognition demands precise coordination to ensure that both inputs are accurately interpreted and aligned. In the context of multimodal-multisensor interfaces combinations such as touch and pen input [20], haptic and non-speech audio [21], speech & manual gesturing [22], and audiovisual are common [23]. Furthermore, visuohaptic feedback has shown to be effective [2].

As a solution to the three problems identified above we present PEGASOS,Footnote 1 a framework allowing researchers and practitioners to create mobile feedback systems. It allows the development of state-of-the-art applications while making use of technological enhancements such as processor speed. Furthermore, the framework is made available as an open-source project thus allowing researcher and practitioners adoption without licensing barriers.

Fig. 1
figure 1

DMC model, taken from [24]

Full size image

2 Background

2.1 Direct mobile coaching

In order to aid researchers and practitioners with the creation of feedback systems two tools have been created Direct Mobile Coaching (DMC) and PEGASOS. While DMC is a model for the creation of feedback systems, PEGASOS, presented in this paper, is a framework which allows the creation of DMC-styled feedback systems, i.e. the two complement each other.

DMC, outlined in Fig. 1 is a model which allows modelling a wide range of different feedback systems [24]. In this model data is collected using arbitrary sensors ranging from off-the-shelf sensors (e.g., heart-rate monitors), over inputs to surveys to custom hardware. The data collection is performed by a mobile client which also presents feedback to the athletes. This client also streams the data to a backend server where it is persisted for further analysis and feedback provisioning. Furthermore, the server also offers the ability for coaches to interact with an athlete by sending him/her messages.

The model separates the provisioning of feedback in two ways: timeliness and location. First, feedback can be provided in a concurrent (i.e., during an activity) or terminal (i.e., after an activity) manner. Second, it can be provided either on the client or using a web-interface. More details about the model can be found in [24].

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 DMC-styled feedback systems while focusing on their creation rather than constantly reinventing complete applications. PEGASOS provides implementations of all aspects of Direct Mobile Coaching.

2.2 Examples of sensor-based feedback systems

A simple example of a sensor-based feedback system is a heart-rate monitor. In its traditional setting, this consists of a heart-rate strap and a visualisation device. The watch is used to display the heart rate and possibly additional information such as elapsed time. Similar to this, in cycling, small computers mounted on the handlebars of the bike can be used for displaying speed and travelled distance. Modern versions of these devices usually have additional functionality for uploading data to a server as part of the system. Examples for such a systems are Polar FlowFootnote 2 and rowsandall.Footnote 3 These servers often offer athletes the ability to view and analyse their activities. Additionally, coaches are provided with remote access to the data.

Other examples of feedback are systems providing athletes and coaches with precise time measurements. One example of this is the measurement and display of wall contact times in swimming. An implementation of such a system is described and validated in a recent paper [25]. The architecture of the system again consists of a sensor and a display unit. In this case, the display unit is a tablet computer displaying amongst other things lap time and contact times. Another example of timing systems is the measurement of intermediate times in alpine skiing, where magnetic sensors are used to measure split times along a ski track [26].

2.3 Related work

There are several frameworks which could be used for the design of mobile feedback systems. Their characteristics are highlighted in Table 2.

In the field of behavioural change interventions, an approach similar to DMC is followed by the MobileCoach framework [27]. It provides a layered architecture for creating behavioural interventions and thus is tailored for collecting data in survey-like form. The underlying concept is based on automata theory and models the system as a state machine. In these machines, user inputs and variables are aggregated to states. Based on these states and created rules (the intervention), actions are taken. In its original version, the framework relies on text messaging as a means of communicating with users. It seems likely that the framework could be extended with an ‘end-user app ’, which would make the concept similar to DMC. The lack of such a ready-to-use or configurable client is, however, also a drawback, as this makes it harder for researchers and developers to integrate data from sources other than surveys into their applications.

Due to the popularity of cycling and running as recreational activities, various feedback systems such as bike computers and heart-rate monitors exist. For instance, some devices from the manufacturer Garmin can be used for the creation of more complex feedback systems with the help of the Garmin Connect IQ SDK.Footnote 4 This SDK allows developers to create ‘data fields’, widgets and even apps. However, their complexity is limited by the missing functionalities for connecting to the internet or accessing the local file system. Moreover, the restriction to bike computers and sport watches poses limitations in hardware (display density, computing power, etc.). Additionally, the exact specifications (processor capabilities, battery, etc.) of the available devices are usually not published. Similar to MobileCoach, the Garmin Connect IQ SDK also makes it harder if not impossible to integrate external sensor measurements into a feedback system. This is due to the fact that the SDK only offers limited access to ANTFootnote 5 sensors and does not offer devices the ability to connect to other sensors via interfaces such as USB. Consequently, only a small set of sensors available on the market can be used for the development of feedback systems. Moreover, the software has only limited capabilities for storing auxiliary data such as data from novel sensors which are not yet standardised for the mass-market (e.g., part of the ANT+ specification).

The Mobile Sensor Framework (MSF) is focused on the collection of data from a specific type of sensor (SHIMMER™) and internal sensors of Android devices [28]. It has modules for persistence, processing and analysis of the recorded data. One drawback is that it is tailored for offline data processing, but components that aid developers to transfer data to a computer are available. Consequently, no real-time data access is possible and feedback can be given by coaches after data has been transferred to a computer and sent using other tools, like emails. Furthermore, the project is not open source.

The project mHealthDroid focuses on the creation of mobile health applications [29]. It allows collecting data from sensors using a so-called “Communication Manager” and it offers basic functions for data processing and visualisation on the smartphone. Furthermore, the framework offers scripts for the remote storage of recorded data. However, no components for displaying and analysing data on the web are provided, and the architecture does not offer the possibility to interact with users of the app remotely. As a consequence of this design choice, coaches or algorithms cannot provide feedback from a remote location. Furthermore, it is not possible to build multi-agent systems with this framework. Although the project is open source, it has been marked as ‘deprecated’ by the developers. In addition, since it has not been updated in the last years, applications created with the framework will not run on recent Android devices due to changes in the Android API.

In conclusion, all frameworks presented above pose certain problems when used for the creation of mobile feedback systems. For example, their field of application is not directly related to general mobile feedback systems but rather to specific types of systems. Moreover, problems arise when access to recorded data is required. The frameworks also do not offer an integration of a wide variety of sensors and/or do not allow the integration of additional (arbitrary) sensors.

3 PEGASOS framework

The PEGASOS framework itself can be separated into two parts: a) the code generator and configuration manager and b) the components of the DMC architecture as described in [24]. In order to generate a feedback system a user can use the configuration manager to create the configuration of the systems. The whole framework with all its components (outlined in Fig. 2) is contained in a GitFootnote 6 repository. The main idea of the framework is to accelerate the development process of feedback systems in order to enable researchers and practitioners to test new concepts quickly. To create a feedback system using PEGASOS, a developer has to craft a configuration as well as the code for the generation of the feedback. Instead of customising an application or the whole framework by editing code, most of the customisations can be done using XML and plain-text files. In order to minimise entry barriers, a graphical user interface (depicted in Fig. 3) for creating these files is provided to potential users. Using the provided configuration and code for the feedback generation, the framework then compiles the feedback system.

Fig. 2
figure 2

PEGASOS framework overview

Full size image

Currently, the framework features two different clients. The first client is based on the Android framework and thus runs only on Android-based devices. The second experimental client is based on JavaFX without any native bindings. Consequently, this client can run on devices independent of the operating system. Moreover, it can be used to create clients for iOS-based smartphones, by using tools such as JavaFXPortsFootnote 7 and RoboVM.Footnote 8 The common and platform-independent functions of the clients are maintained in a core library. This also allows the development of additional platform specific clients in the future.

In the following sections, all components of PEGASOS and the Direct Mobile Coaching architecture are described in detail.

3.1 Mobile application

The configuration of the app, which can also be crafted using the configurator (c.f. Fig. 3), consists of the following parts:

  • Version control

  • Customisations

  • Menu

  • Sports

  • Sensors

  • Controllers

Fig. 3
figure 3

Screenshot of the tool for creating configurations of feedback systems. Below the menu bar the current feedback system (“Running App”) can be seen. The configuration of each system is organised using tabs (Basic, Version Control, etc.). The opened tab (“Sensors”) shows the list of sensors used by the system

Full size image

The app can be customised by adjusting various settings using variables in the XML file. For each of these settings, a default value is provided. Consequently, it is not necessary to specify a value for all settings or to copy and paste them into the configuration. The configurable settings include, for example, whether and how often users should be notified when the app loses the connection to the server, or how the user should be able to stop activities manually. Moreover, it is possible to specify additional settings. These settings can be changed by using the configuration utility instead of having to change source code. This makes it easier for novice developers to tweak the behaviour of an app.

Creating user menus can be a tedious and error-prone task. For example, creating different paths to the same action, which makes sense in some cases, can lead to various problems. The framework offers the possibility of creating menus and sub-menus using XML. Entries in the menu can be of different kinds, such as opening sub-menus, starting activities, or requesting values such as weight or distances from the user.

In order to enable the apps to have different functionalities (e.g., required set of sensors, provided visual feedback, etc.) for different situations, it is possible to define the respective ‘sport’ for an activity. As part of this definition a list of required and optional sensors can be defined. Using this list PEGASOS allows a user to start an activity only once all required sensors are connected. An additional part of this configuration is how information is presented to athletes. The framework provides its users with a variety of ways of visualising data, starting with simple ones such as displaying information numerically as either floating point or integer values to graphical displays such as tacho needles or bars. Furthermore, it is possible to create different assemblies, termed ‘screens’ allowing fast changes between displays.

PEGASOS offers a variety of sensors and takes care of the life-cycle management of the sensor data collection. Included in the framework are implementations for sensors and actors, such as internal sensors of the phone as well as a variety of ANT+ and Bluetooth Low Energy Sensors (BLE); for example, cycling speed sensors. As an example for actors, the Fitness Equipment Control (FE-C), a protocol for controlling devices such as indoor cycling trainers, has been implemented. In Table 1, the implemented sensors and actors are listed. Additionally, the framework can be extended to include additional sensors. This can be achieved by, for example, modifying the implementation of an existing sensor to fit the specification of the new sensor. Each ‘sport’ can make use of a different set of sensors. The framework manages the task of checking whether all required sensors are connected and are able to provide data. Moreover, it takes care of disconnects and interruptions of the sensors.

Table 1 List of some implemented sensors and actors
Full size table

The implementation of the interface between the feedback system and the user is done using Controllers. They can facilitate simple deterministic models (e.g., Foot Pod calibration, see below) or even full-fledged machine learning-based models for providing the feedback. For example, Park et al. used computer vision and a machine learning-based model (COCO) to provide users with feedback on their home workouts [30]. The framework requires the start of precisely one controller for each activity. PEGASOS also provides a set of default controllers implementing standard behaviour of feedback systems such as the calibration of a Foot Pod device or controllers offering no special interaction with the user. The latter can be put into action, for example, when a feedback system is used only for recording and displaying the raw sensor data and hence no special interaction is necessary. Moreover, since a controller can take an arbitrary amount of parameters, it is possible to apply a controller for different use cases using parametrisation. Parameters can be hard coded into the launch of the activity from the menu or queried from a user of the feedback system before the start of an activity. Additionally, a controller acts as a gateway between the server and the core of the feedback system and can intercept incoming messages or send messages to the server. Furthermore, PEGASOS allows these components to create additional views and to disable the default views specified as part of the ‘sports’ definition.

3.2 Backend server and AI modules

The backend server of the framework is written in Java and thus can be executed on most standard servers. Each feedback system could be connected to an individual server instance, or multiple feedback systems could use the same server instance. This decision is usually based on various factors, such as data security. The configuration of a server instance follows a similar pattern to the one of the app, consisting of the following parts:

  • Version control and customisations

  • Sensors

  • Communication protocol

  • AI modules

  • post-processing modules

Similarly to the app, the server also needs to specify the branch of the repository used for building it. One important customisation is the access to the database.

For each server, the available sensors have to be declared. The specification of a sensor consists of the various data fields and their data types. This has to be done in order to enable the framework to generate the interfaces and parsers accordingly. The backend components of the framework are targeted to be able to service several different feedback systems concurrently. Consequently, it is necessary for the server component to be able to manage data from different sensor types. In order to avoid problems during run time, the configuration of the various apps is checked for inconsistencies and conflicting declarations at build time.

The communication protocol between server and clients is built around a set of available commands. Besides standard commands such as starting and stopping sessions, additional commands can be declared. Unused commands are removed before the compilation of the server in order to shrink the binary size and increase security.

An additional function of the backend server is to provide the means for concurrent feedback (i.e., feedback during the activity) by using AI modules. Using object-oriented programming users of the framework can create AI modules using pre-build modules (e.g. round-based games). The communication between clients and the modules is managed by the API of the server. Moreover, the framework allows the creation of custom commands, which can then be sent and received by the server and client. The API allows information to be sent to single users as well as to multiple users at the same time. This makes it possible to model interactions between users. Furthermore, feedback modules can access all the data transmitted from the client to the server.

Terminal feedback (i.e., feedback after the activity) for activities is provided using post-processing modules, which can be configured individually for each activity type and are triggered by the server automatically. PEGASOS includes samples for computing summary statistics (e.g. mean or maximal heart rate), computing parameters such as the maximal oxygen consumption based on models or evaluating multiple activities at the same time to award points in a group game. Furthermore, post-processing modules can be facilitated to synchronise data between platforms. The framework also includes functionalities for exporting data to common formats such as comma-separated value files or XML-based formats, e.g. Training Center XML (TCX).Footnote 9 This functionality can then be used to upload data to other platforms such as Training Peaks,Footnote 10 Polar Flow,Footnote 11 Strava,Footnote 12 etc.

A benefit of the framework and its dedicated server is compliance with recent ethical guidelines. Frameworks such as Garmin Connect IQ store data on third party servers, and thereby do not give the researchers full control over the data. PEGASOS, however, allows researchers full control over all recorded data, i.e. securing access to restricted authorities only, deletion of data after a study, etc. Consequently, by using PEGASOS, a research project can conform to the declarations of Helsinki [31] and Taipei [32].

It is important to note that PEGASOS does not utilise a server for all existing feedback systems. This means that each team, organisation or individual can host their own instance of the server. It is even possible to run a dedicated server for each feedback system. Consequently, data of athletes and users are not available for other organisations, thus ensuring some data privacy.

However, it is the task of the designer of a feedback system to ensure research ethics and data privacy standards are upheld. For example, only data which is relevant for a certain study should be collected by the system. Furthermore, designers of a system should carefully consider which data should be visible to which user group of the system. PEGASOS provides functionalities in order to implement these aspects in a feedback system.

3.3 Web-frontend

The Web-Frontend is intended to provide—among other features—access to recorded data to all users of the feedback system. However, users often have different roles within the system and thus require different views on the data. For example in intervention studies the progress of participants is often monitored by researchers, thus requiring access to all data, while individual participants will only be allowed to view their own data. Furthermore, it is required that coaches can only access specific information about an athlete, since an athlete is often monitored by a team of coaches. PEGASOS allows to integrate such behaviour using a role management concept. The framework offers pre-built views, such as diaries and charts (c.f. Fig. 4).

Fig. 4
figure 4

Example charts generated by the framework

Full size image

Moreover, the framework allows the creation of views for live tracking of activities. Each activity can be customised to show different data to athletes and experts. Examples of such data are current positions, as well as tracks on a map, current heart rate and speed.

The framework is configured to offer privacy by design. Consequently, no data is visible to other users by default. However, since a major purpose of the framework is to serve as a monitoring tool during studies, it is possible to grant a user the permission to view other users’ data. This is realised by adding users to a group and assigning a group owner.

The framework offers a variety of charting functions which can be used to display data. These charts range from simple line charts visualising data from a single sensor, or multiline charts comparing several sensors or measurements to more complex charts such as Poincaré plots. The latter are often used when heart-rate variability data is analysed [33]. The provided functionality can be used to query any data of an activity. This can be used for providing further visualisations specific to the feedback system, e.g., showing deviations from an optimal movement pattern using a novel technique.

Another common functionality of feedback systems is to provide summary statistics about athletes’ activity. PEGASOS provides functionality for data aggregation in form of ‘reports’. They can be generated to aggregate extracted metrics based on predefined operations (e.g. maximum, minimum, sum) with different ways for visualisation available.

Each feedback system can define several charts and also display a different set of charts based on the activity type.

The Web-Frontend uses a REST architecture and is thus divided into a backend server and a frontend. All user actions are provided by the backend, which is developed using Spring Boot framework.Footnote 13 The frontend is based on the AngularFootnote 14 framework.

3.4 Code generator

A central part of PEGASOS is to aid development by generating code. For example, a large portion of the code for communication between backend server and client is generated automatically. Furthermore, similar to common GUI frameworks such as Qt, the underlying code necessary for creating menus is generated. After parsing and checking the specification, the generator outputs Java-Code. The look and feel of these generated menus can then be customised by a feedback system by replacing the default implementation.

3.5 Data model

The core data model of the framework is built around two main entities: persons and sessions. All recorded data is collated to a session. Each session in turn is collated to a person. Additionally, each session contains information about the date, time and duration.

Each type of sensor data is stored in a different table. These tables are generated by the framework using the server specification (see Sect. 3.2) or the code provided by the developer. Each entry in these tables contains a reference to the session, the time of the sensor event and the sensor-specific data. Additionally, sensor tables can have an attribute for the sensor number.

Each person can have different ‘values’, for example body weight, height, etc. or application-specific parameters, such as maximal oxygen consumption. In order to enable long-time use of the feedback system, user values are stored in a datawarehouse like fashion. This means that for each value, the time span of validity is stored. Having an extra field marking the end of the validity of a value makes it possible to have time spans in which the user has no value. This feature can, for example, be used to track illnesses of an athlete.

4 Comparative assessment of PEGASOS

In order to evaluate PEGASOS we performed three steps: first, Sect. 4.1 compares the framework with state-of-the-art solutions. Next, Sect. 4.2 demonstrates how it can be used for the creation of a feedback system for running and outlines the differences to developing a solution from scratch. Lastly, Sect. 4.3 analyses the capabilities of PEGASOS with respect to its ability for creating systems with different modalities presented in current scientific literature.

4.1 Comparison to other frameworks

In this section we compare the characteristics, features, use cases and usability of MobileCoach, MSF, GCIS and mHealthDroid with PEGASOS. The results of this comparison have also been outlined in Table 2.

Table 2 Comparison of MobileCoach, Garmin Connect IQ SDK (GCIS), Mobile Sensor Framework (MSF) and mHealthDroid
Full size table

The first main difference between the five frameworks is their intended field of use. While MobileCoach is focused on behavioural change and intervention studies, both the Garmin Connect IQ SDK and PEGASOS are tailored for applications in the sports domain. However, the GCIS is tailored for displaying data rather than processing and analysing it. Furthermore, PEGASOS is—conceptually—not limited to the sporting domain and can also be used in intervention studies.

As a direct consequence of their intended field of use, the frameworks also differ in their target platforms to be used for client applications. GCIS is limited to specific Garmin devices only. Since MobileCoach is dialogue-based, its intended target platforms are phones with text messaging capabilities. Additionally, the feedback components can be accessed via a web browser. The current PEGASOS implementation features an Android client. In contrast to MSF and mHealthDroid, neither MobileCoach nor PEGASOS are limited to their current clients.

Another main difference is the way in which end-users (e.g. athletes or study participants) can access their data. Since MobileCoach is based on intervention studies, it seems that this is not an intended feature and is therefore missing. GCIS does not have a direct feature for this either. Data from recorded activities are accessible via the Garmin Connect web platform. However, it is not possible to customise or extend this platform. For MSF and mHealthDroid, no explicit information on data access for end-users is given. However, it can be assumed that with some work, such features can be realised. PEGASOS offers customisable views on the data in a web-based manner. Additionally, since all activities are also stored on the phone, the API has a built-in support for extending the client application with data views.

For researchers, it is important to have access to data recorded by users. This is where the frameworks diverge quite heavily. GCIS does not offer direct access to the user data. A commercial license can be obtained in order to mitigate this problem. MobileCoach stores all recorded data in a MongoDB.Footnote 15 Similarly, mHealthDroid stores data in a SQLiteFootnote 16 database. MSF stores data from sensors in separate CSV files. However, it seems that no code for post-processing and creating data exports is available as of yet for these frameworks. PEGASOS stores all data in a relational database with additional support in its API for creating post-processing and export functionality.

An easy distribution of created applications with short development cycles is important for small teams such as research groups. While commercial applications are usually distributed using the official distribution channels of the respective platform, research applications tend to have different requirements. For example, some applications cannot be made available to the public due to license agreements or other requirements. Moreover, in some cases, public access to the created application is not intended in order to keep service requests at a minimum. GCIS offers the least support to researchers in this matter, since the distribution of applications is only available through the official Garmin website. Depending on the use case, no distribution may be necessary for MobileCoach-based applications. For the Android-based client applications created with PEGASOS, several different methods can be used for their distribution: a USB-cable, the official Google App store or a third-party app store such as F-Droid.

Another factor that differentiates the frameworks especially in their applicability for use cases as well as in their required development effort is the list of available sensors and the possibility of integrating more sensors. MobileCoach does not offer any sensor integrations by default. However, it is theoretically possible to integrate arbitrary sensors. Similarly, sensors can be integrated into MSF and mHealthDroid, but no extensive documentation for this task is available. In contrast to this, the GCIS offers only a subset of all currently standardised ANT and ANT+ sensors. Additionally, access to the internal acceleration sensor is available. The integration of additional sensors is, however, limited to sensors using either ANT or ANT+, and the ability to store sensor data is limited to data formats within the FIT-file standard.Footnote 17 A list of all sensors implemented in PEGASOS is outlined in Table 1. Moreover, since the code is available, these implementations can serve as a starting point for the implementation of additional sensors.

Another major difference is the programming languages used for developing the applications with the framework. GCIS uses its own language called Monkey C,Footnote 18 while MobileCoach, MSF, mHealthDroid and PEGASOS use established languages such as Java and Java Script.

4.2 Implementation of an app using PEGASOS

In this section, the capabilities of the proposed PEGASOS framework is illustrated based on two applications of PerPot-live [34, 35]. Screenshots of both applications are shown in Fig. 6. PerPot-live is a feedback system targeted at runners aiming to improve their running performance by providing them with a pacing strategy based on their current level of fitness. The so-called Performance-Potential (PerPot) model [36] aims at modelling the relations between physical strain and performance. Its extension PerPot Run tries to predict optimal running times for a fixed distance. The feedback system presents a live version of PerPot Run, where the optimal running time is continuously updated. Due to these updates, the system can react to day-to-day variations of performance as well as to other relevant factors such as differences in ambient temperature, which has an effect on performance and pacing [37].

For an earlier study [34], a feedback system was developed using PerPot-live to investigate the acceptance of computer-based feedback during running. In a subsequent study [35], the feedback system described in the previous section was developed using the PEGASOS framework in order to test the capabilities of PerPot-live for pacing 10 km runs.

4.2.1 Implementation with PEGASOS

In this subsection, the feedback system and its implementation with PEGASOS is described, while the next subsection discusses the earlier implementation without the framework. The feedback system features four different modes of runs. While the first type is a simple run over a fixed distance used to calibrate the Foot Pod and has no particular feedback, the second mode is a modified version of an incremental step test. This test is required for the calibration of the PerPot model. The first mode uses the controller included in the framework. During the incremental step test, a controller guides the athlete to run at the correct speeds. A third mode was implemented in the feedback system in order to validate the PerPot Run. This mode is a trial run over a fixed distance, where the only automated feedback is a verbal notification of completed distances. The feedback is computed by an AI module, which periodically checks whether the participant has reached a virtual kilometre marker. During the PerPot run—the fourth mode—the feedback system gives verbal feedback for both heart rate and running pace according to the determined values of the PerPot model. For this mode, the feedback is computed by an AI module which uses PerPot Run in the background. In addition to the verbal feedback, a controller displays the calculated finishing time as well as running speed and heart rate in comparison to their computed optimal values. A study comparing the two feedback modes (third and fourth mode) indicated that slower runners, i.e. those needing more than 50 minutes for a 10 km run, could significantly improve their performances with the activated PerPot feedback (fourth mode). Faster runners showed a non-significant improvement [35].

The implementation of the feedback system consists of three parts: the configuration, a controller for the fitness test and two AI modules for the trial runs. The configuration sets up the menus for starting the different runs and configures the framework to use the built-in heart rate, Foot Pod and GPS sensors. Furthermore, it defines the controllers for the calibrations and the trial run with the PerPot feedback. As mentioned before, the trial run without the pacing feedback relies on a default controller, which reads the feedback messagesFootnote 19 to the athlete. Consequently, no configuration or code is required for this aspect of the system.

The AI module for the PerPot run, which gives the athletes feedback based on their heart rate and speed, has a simple structure and is outlined in Fig. 5. Before any run can actually start, the module performs an initial calibration by querying the last calibration run from the data base. Using the identified values, the PerPot module is calibrated and initial values for speed and estimated finishing time are sent to the client, where this information will then be read to the user. After this, the module will check whether the athlete has started the run, i.e. whether the speed exceeds a threshold value of 8km h\(^-1\). Once the start has been detected, a task will periodically check every second whether the user is within the prescribed limits for speed and heart rate. Additionally, it will use the recorded values to recalibrate the PerPot module and update the prescribed limits every five minutes. While DMC and PEGASOS would allow an implementation where all updates to the limits, the current implementation with an AI module running on the server offers the benefit of using proprietary software such as PerPot which cannot be distributed to end users in the form of a mobile application.

Fig. 5
figure 5

Flowchart of the AI module in PerPot-live

Full size image

4.2.2 Comparison to systems without a framework

The code for the whole app of the previous version [34] was about 2100 lines. With the help of the framework a similar app can be created without a single line of code. This means that the development time for the app created with PEGASOS is negligible. The required lines of code, when counting the configuration as code, is reduced by \(\backsim 90\%\). Figure 6a shows a screenshot of the menu in the previous version, whereas Fig. 6b shows the menu of the version using PEGASOS. The additional screenshots (Fig. 6c, d) highlight the different views for the athletes while they are running. Using the ’sport’ configuration of the app, the current version has the added support of allowing the display unit to be switched from ’km/h’ to ’min/km’, which was not possible in the previous version. In order to enhance the user experience, an additional view was created. During the trial runs, this view presents the athletes with their speed and heart rate as well as their deviation from the computed target values. The view is provided by a controller which requires \(\backsim 150\) lines of code. Moreover, this controller also displays the calculated finishing time. Both of these views were absent in earlier versions of the app.

The previous version of the feedback system (without PEGASOS) performs the control of running speed during the calibration run entirely on the server as an AI module. This module periodically checks whether the athlete is at the prescribed speed and sends a message if otherwise. With Direct Mobile Coaching and PEGASOS, a controller with less than 300 lines can achieve the same behaviour for the new feedback system while increasing the responsiveness of the system as the feedback is computed directly on the client. The addition of this controller also removes some other drawbacks, such as the necessity of a constant mobile internet connection.

Fig. 6
figure 6

Screenshots of the different versions of PerPot-live. (a) and (c) depict an old version, (b) and (d) a version created with PEGASOS. (a) and (b) show the menu of the app, (c) and (d) different views for the athletes while they are running

Full size image

The AI module for the PerPot calibration run of the previous version also includes an analysis of the completed test. DMC allows these tasks to be split into two parts. Consequently, in the new version no AI module is needed as this functionality is implemented as a controller. Additionally, the analysis of the test is done by a post-processing module. While the amount of work required for developing this function might be similar for both versions, the architecture of the newer version seems preferable, since it separates feedback from analysis.

4.3 Feedback modalities

In order to evaluate the capabilities of PEGASOS for creating state-of-the-art systems presented in scientific literature we used the database of feedback systems established in [24] consisting of 39 systems covering 15 different sports. The list of systems was established by means of a systematic review of literature using the ACM library, MDPI and Web of Science as primary sources as well as articles from the journals “International Journal of Computer Science in Sports” (IJCSS) and “Sports Engineering” along with conference proceedings from “International Sports Engineering Association” (ISEA) and “icSports” as “grey literature”. Furthermore, results were limited to a date of publication for years 2018 to 2021.

We were able to provide basic configuration of the apps using the graphical user interface (Configurator, see Sect. 3).

4.3.1 Data sources/sensors

Since we were able to provide the initial configuration of all feedback systems, we can also expect that PEGASOS can be used to collect data required for all analysed studies. The majority of studies used sensors which are either included in the framework already or use types of sensors for which the existing sensors can serve as starting point for an implementation.

Currently, not implemented within PEGASOS are sensors requiring storage of videos or similar data structures such as data provided by Microsoft Kinect. However, many feedback systems only process video signals and do not store captured images. Only in cases where actual images (in the form of video) are required additional programming effort would be necessary.

4.3.2 Concurrent feedback

Out of the 39 studies identified in [24] 17 provided concurrent feedback. The studies and feedback provided are listed in Table 3.

Table 3 Summary of studies providing concurrent feedback
Full size table

Simple visuals

A total of 6 studies provided feedback by means of simple visuals such as displaying numeric information during the activity. The investigated displays could be created with PEGASOS without programming efforts. Furthermore, the study of Wolf et al. [53] already made use of the framework.

Complex visuals

Three studies utilised complex visual displays: One study [11] showed a visualisation of a SOM, while two further studies displayed mappings of pressure applied on the foot. While PEGASOS currently does not provide such visuals using a configuration only approach, it is possible to provide these types of feedback using the framework. Furthermore, due to the fact that it is provided open-source, these designs could be integrated into PEGASOS or provided to other users in the form of libraries.

Sonification

We found three studies making use of simple sonification techniques such as threshold sounds or verbal cues. All of these techniques are within the capabilities of PEGASOS.

As mentioned in the introduction, sonification also involves providing feedback by generating a tone [9, 10]. Some studies such as [41] used custom or proprietary tone generators (e.g., CsoundFootnote 20). The utilisation of such additional software into a feedback system is possible using PEGASOS. It provides functionalities for collecting data from sensors and forwarding it to other software.

Vibrotactile

Four studies used vibrotactile cues as part of their feedback. In most cases this type of feedback is provided using one or more vibration motors which can be triggered with varying length of pulses and intensities, using the built-in vibration motor of a smartphone implemented in PEGASOS. Furthermore, several tasks such as starting a vibration pattern whenever a value is above or below a threshold are implemented.

Multimodality

Out of the 17 studies only three provided feedback using more than one modality. Two studies [47, 50] combined auditory and vibrotactile feedback, while the study of Biesmans and Markopoulos combined visual and auditory feedback [42].

4.3.3 Terminal feedback

Table 4 Summary of studies providing terminal feedback
Full size table

The majority of analysed studies (27) provided terminal feedback. They are listed in Table 4 together with the feedback provided.

Simple visuals

Out of the 27 studies providing terminal feedback 24 studies used ‘simple’ visuals such as charts showing trajectories of a value over time. These visuals can be created with PEGASOS using only the configuration, i.e. no programming effort is necessary. Furthermore, it is possible to customise the provided visuals even further by either extending existing charting functionality or using existing code as starting point for custom functionalities.

Metrics

Another common type of feedback given to athletes are “simple” metrics based on their activity. Examples for this are descriptive statistics such as minimal and maximal value as well as mean of a variable, e.g., cadence. Four studies provided feedback by computing metrics based on activities recorded by the participants of the studies. PEGASOS provides an API for computing such metrics as part of post-processing modules. Values computed during this stage can then be visualised using the web-frontend.

Complex visuals

Six studies provided more complex visuals such as cadence trajectories mapped on a geographic track [38]. While such visuals currently cannot be provided by PEGASOS using the basic configuration, the framework provides the ability to create custom visuals. The aforementioned example thus can be created using existing code for creating maps as a starting point.

5 Discussion

5.1 Accelerating development and preserving knowledge

As we have shown in Sect. 4.2, using PEGASOS can reduce the lines of code required for creating an application. Some reductions are also due to the fact that the framework provides solutions for common tasks such as sensor pairing. Additionally, its existing architecture and design decisions reduce research and testing efforts with regard to development decisions for users of PEGASOS. Since not all researchers in the domain of sport science have a strong computer science or programming background, the task of developing enterprise scale systems from scratch could potentially exceed their capabilities. Also in this case, the framework helps to accelerate the development process as the required knowledge is reduced.

Additionally, PEGASOS provides a layer of abstraction on the underlying technologies such as the Android framework. Consequently, its users are not required to have a deep understanding of all the technologies. This again reduces effort and time during the conceptualisation and development of new feedback systems.

Conducting a study can be a time-consuming task in many ways. For example, any study involving technical devices should have personnel trained for the handling of these machines. A concrete example for a study evaluating a sensor-based mobile feedback system would be the pairing of sensors with the mobile device. This task requires training, but there should be at least one member of the study team who is able to perform it. Conducting this training and preparing the necessary material requires additional time. As these tasks are often assigned to student staff or contractors, the transferred knowledge is often lost or training material cannot be reused for other studies. Moreover, as sensors and mobile devices / applications have certain pitfalls, members of the study team need to be proficient in their handling to help participants. A solution that does not change between different feedback systems could help institutions not only save time but also preserve knowledge.

5.2 Applications for testing models in sport science

With the availability of more and more data, mathematical models are also becoming more popular in sport science as well as in the sport industry. Mathematical models allow, for example, to predict future performances based on training results, e.g. by applying the Fitness-Fatigue Model [76]. Furthermore, models allow the computation of so-called pacing plans, i.e. intensity / effort distributions for a sporting effort. One example for such an application is the above mentioned Powerbike project. Consequently, we conclude that PEGASOS allows sport scientists to test models without the need of creating a complete application from scratch. This ability allows researchers and practitioners to focus on the model at hand and its implementation rather than having to spend time reinventing the wheel. Moreover, using PEGASOS produces more robust solutions with regard to issues such as sensor pairing, thus making it possible to test models in real world scenarios.

In order to be used in any scientific study, a feedback system needs to be evaluated, which is usually done in the course of intervention studies. Apart from being evaluated as part of a study, feedback systems are also used on a regular basis to help with the conductance of such studies. However, in such scenarios, a common problem for sport scientists is the large amount of time needed for data analysis. This is sometimes due to low standardisation of recording devices and the requirement of data synchronisation between different measuring systems. Using a framework for recording data from sensors can solve these problems. PEGASOS is able to record data from various different sensors and store them in a unified format. Furthermore, it has functionalities for exporting data into common formats such as comma-separated values.

Another problem is the sheer complexity and low customisability of most systems. As a consequence, these systems often require extensive additional post-processing efforts. PEGASOS can help automatise these processes. For example, post-processing modules allow automated triggering of data analysis actions after an activity has been completed by a participant of a study.

One potential drawback of applications stemming from research is that they tend to be complex. Most feedback systems of this type employ models that require either a high amount of work from athletes—for example entering various input variables—or extensive calibration is needed before they can be used. Usually they pose a high extraneous cognitive load on the athletes during the learning phase. For these reasons, the majority of research applications never reach the broad mass of athletes and coaches. In order to make those research outputs more applicable for real-world usage, these feedback systems require a lot of additional software development work. In most cases, the application was not developed to be used by a potential end-user but rather to be handled by an expert, so the user experience often offers room for improvement. However, most of the required features for achieving an acceptable user experience share similarities or are repetitive. For example, most systems require the function to view recorded data, and/or summaries of it. This problem can be solved with PEGASOS, as it allows the configuration of functionalities on a task-by-task basis. For example, a feedback system can be configured to show a map of the route for a trail running activity or a chart displaying power output of an indoor cycling activity.

5.3 Multimodality

As we have argued before, the creation of a feedback system is a complex task and the results of our investigation indicates that a majority of the identified feedback systems present data using simple visuals such as graphs showing lines and only provide terminal feedback. This might also indicate that creating a system covering a wide variety of different modalities of feedback thus is an even more complex task. Since PEGASOS covers a wide variety of different modes, which can be used without any programming knowledge, it can be a useful tool for researchers and practitioners wanting to provide multimodal feedback. By using the provided means, systems targeting more than one modality can be created without much additional effort. We hypothesise that using a framework such as PEGASOS could enable researchers and practitioners to provide athletes with both concurrent and terminal feedback as well as using different modalities. Due to the number of feedback variants already implemented within the framework and the ability of adding them without much additional effort, they can be offered to users of the system easily.

Consequently, this would also lower the barriers for studies aiming to investigate different effects of feedback on aspects of performance such as the adherence to pacing profiles. Since efforts for developing aspects of the feedback system, such as data collection, are reduced, time saved could be invested in the creation of novel feedback variants.

Previous studies have already highlighted the capabilities of PEGASOS with respect to different feedback modalities [77,78,79]. While in [77] auditory and haptic feedback was provided, [24, 79] provided visual feedback for pacing.

Due to its effectiveness (e.g., [2, 8]) multimodal feedback as part of feedback systems is important. The design of PEGASOS allows to combine modalities in order to achieve multimodality. One possibility is to use an event driven architecture which reacts to events from sensors. For example, whenever the heart rate of an athlete exceeds a certain threshold a feedback event is triggered. The framework can then be facilitated to play a sound, use the text-to-speech engine of the mobile device and vibrate. Another possibility is to use the API of PEGASOS to also react to the absence of events in order to provide feedback. Using PEGASOS could enable researchers to bridge the gap between HCI research on multimodality and sport science.

6 Conclusions and future work

In this paper, we presented PEGASOS, a framework for the creation of DMC-styled feedback systems. We started by examining some existing solutions for mobile feedback systems and their shortcomings, as well as describing the difficulties in creating a huge range of these systems. Next, we discussed the concepts of DMC and showed implementation details of our framework. We presented several examples of feedback systems and their characteristics. Moreover, we compared a regular implementation of an MC feedback system to a revised version of it which facilitates DMC and the use of PEGASOS.

Due to its features and extensibility, PEGASOS can become a valuable tool for researchers as well as practitioners when creating mobile feedback systems. Besides a deep knowledge of mobile app development, it usually requires a high amount of work and time to create a mobile feedback system that offers a reasonable degree of usability as well as functionality from scratch. Using PEGASOS, the required workload can be reduced drastically, since features such as managing sensors and users do not have to be implemented but are already present. It also lowers the required level of knowledge about technical details such as the Android API for creating feedback systems. The framework with the added ability of customisation covers a wide variety of potential use cases. Moreover, the existing sample applications provide ‘documentation by example’ and could serve as a starting point for creating new applications.

In its current version, the implementation of PEGASOS is stable and offers a wide range of features. However, we expect this project to be continued and thus have an active code base. Besides fixing bugs that are still undiscovered, this will also involve the extension of the framework. One example of future extensions is the creation and integration of other clients such as Apple products or embedded chips. Moreover, we expect continuous updates to be necessary in order for the framework to be able to run on the newest hard- and software.

Further development efforts could offer more graphical assistants and even a visual programming language in order to lower entry barriers even further [80, 81]. Additionally, more feedback components and variants could be added to the framework. Another strand of research and development efforts should investigate options for offering feedback to additional user groups, e.g., blind or visually impaired people. Furthermore, future research could involve qualitative feasibility study investigating user acceptance and usability of systems built using PEGASOS.