Human perception heavily relies as on seeing and hearing, as well as on possibility to view diferent angles and continuity of motion. Obviously, modern video broadcasting and displaying do ensure high-resolution content, but they nonetheless still lack that subtlety of perceiving objects live, by which one is still capable to distinguish watching screen picture from watching natural picture. In sport competitions, events are perceived much better when they are observed up close, with stronger capability of estimating dynamics and general mechanics of motion. This concerns the coaching staf and analysts, as well as fans and spectators. A special case is the use of scaled-down or miniaturized models similar to tabletop games, where on-field sports players are represented by model figures. Such models, additionally allowing tangibility, are especially precious for people with visual impairments. We suggest a conceptual model of an IoT-based embedded system, which allows visually, tangibly, and acoustically perceiving location and motion of a sports player within sports field. We consider three approaches to technical implementation of motion mechanism for providing speed and smoothness. Motion is controlled by stepper motors and specialized drivers TMC22xx/DRV88xx. Acceleration and deceleration are computed by a special pattern. An algorithm is developed for automatic calibration of the system mechanics, and also for automatic positioning. Motion control, data acquisition from player-mounted sensors, and data exchange among servers are provided by Raspberry Pi Compute Module 5. We optimize internal protocols for data exchange among processes, as well as external protocols for real-time data acquisition, based on neglecting states that have relatively low efect on the overall model response. This renders our system power consumption to almost linear with respect to stepper motors, which are the most power-consuming in the system.
Nowadays, huge variety of portable displays, tablets, electronic boards, and other devices for visual
reproduction of information allows covering nearly any household, industrial, and entertainment tasks.
However, almost all of these tools ultimately produce a 2D image on the screen plane, which a person
“reads” with one’s eyes and eventually transforms into an image or object as a factual perception of
information. Techniques of perceptual augmentation to enhance perception in vision are well-known.
Thus, the contrast between the white background and black characters is used to highlight the text,
certain color palettes are used to enhance part of the image, special dynamic video sequences are
generated, which actually allow enhancing perceptibility of 3D scenes and objects on 2D screen, etc.
Meanwhile, large manufacturers of electronic visual displays continue to develop. There are already
many concepts of flexible displays [
In sport competitions, events are perceived much better when they are observed up close, with
stronger capability of estimating dynamics and general mechanics of motion. The coaching staf
and analysts can view detailed peculiarities of tactical movements and mistakes of players [
Our purpose is to develop a conceptual model of an IoT-based embedded system, which allows visually, tangibly, and acoustically perceiving location and motion of a sports player within sports field. Positioning is to be realized by a moving marker, whose shape and size could be changed according to the type of game or sport. Player’s data must be aggregated straightforwardly from sensors via stadium network gateways, but also we ought to make it possible to download data of previous games to simulate performance of a chosen player. The system, which is presumed to be portable and energy eficient, is believed to be a more convenient tool for visual presentation of tactics and strategies in sports games by the team’s coaching and teaching staf. Besides, unlike electronic applications, it should allow visually impaired people to better perceive information about events in the game.
Sports data, and, in particular, soccer data, are continuously collected during the game. Data acquisition
is the first step in the data processing pipeline. It involves capturing raw data and converting it into a
format that can be easily analyzed. Data are acquired either from sensors usually mounted in vests
and cleats or by optical tracking systems and event data providers. When players wear enhanced-GPS
devices [
Once acquired, the raw telemetry data from tracking systems and wearables is preprocessed to
determine the player’s position on the field and other temporal characteristics at any given moment.
This positional data is recorded in the abscissa-and-ordinate-axes coordinates with respect to the field
dimensions. Besides, these are sensors inside the ball itself, which record its motion speed and the
position in 3D coordinates with respect to the field to identify in-flight characteristics of the ball [
The preprocessed data is used for generation of heatmaps [
All telemetry data is collected on wireless gateways in the stadium and transmitted to a server where the telemetry data is filtered and processed. Most of the game’s data is not available to the general public, and it is mostly not of interest to common spectators or fans. But basic information about the game process is delivered to providers of such services, which give the end user the opportunity to receive it, whether for a fee or free. Examples of such telemetry data available on the match broadcast screens and tabulated statistics on the Internet are ball possession percentage, pass accuracy, amount of kilometers covered by the player, maximum impact force, etc.
Data providers deliver data from their servers to users online, or they may provide recordings of previous games. Data formats can be diferent, but as a rule, they can be obtained in CSV, XML, or JSON and similar formats, which are easy to parse, convert, and transfer for further processing. Recorded games, as well as interesting educational game situations, can be stored on own separate “On demand” server in an optimized format that allows for faster access to data and makes data classification better.
The center of the system is the Raspberry Pi Compute Module (figure 1). This is a powerful
minicomputer based on the Linux OS operating system [
In our system, the Raspberry Pi uses the following peripherals: 1. Ethernet and Wi-Fi to access the Internet to exchange data with servers, and to be able to configure the system and collect logs. 2. GPIO, UART, I2C, I2S for controlling stepper motor drivers, receiving data from sensors, controlling the vibrator and transmitting sound to user’s headphones. 3. Bluetooth as an alternative audio channel for a wireless headset. 4. HDMI or MIPI for outputting the broadcast video signal to an optional screen.
The system runs on Raspberry Pi OS, which is a Unix-like operating system based on the Debian Linux distribution for the Raspberry Pi family of compact single-board computers. Raspberry Pi OS is very stable, allows multithreading, and also supports all popular software development tools like C/C++, Python, Bash script, Java, PHP.
The system converts the received data about the position of the player on the sports field, his speed and current acceleration into a 2D coordinate on the miniaturized field and controls the position of the carriage with the help of two motors and belts. The carriage moves under the miniaturized field with a magnet attached to it. A magnetic marker as the player’s model figure is placed on top of the miniaturized field. This marker completely repeats the movement of the carriage. The calibration of the carriage position, as well as the permanent control of its position, is performed by four optical sensors on each side of the miniaturized field, which makes mechanical malfunctions and slips impossible. The optical sensors also help position the marker more accurately, whereas positioning is quite repeatable. The carriage is moved along the conditional abscissa and ordinate axes by two 24 V stepper motors with a maximum peak current of 2 A. The accuracy, smoothness, and other dynamic parameters of the motors are controlled by driver boards TMC22xx, which are controlled from the Raspberry Pi via GPIO and UART interfaces. The system has a vibration motor that generates a vibration signal of a certain amplitude and frequency, by the type of which the user can distinguish one or another event that is currently happening on the field.
Basic (or custom) control of the system is possible using several buttons and switches. Full control of the system is carried out using a command protocol through an internal or external (Internet) connection.
The mechanical part of the system consists of motors that move the belts, which in turn move the carriage (figure 2). The carriage moves on linear bearings along linear guides in the abscissa-andordinate-axes plane in the direction specified by the logic. Gears and tension devices allow the belt to move smoothly and have a stable tension. All elements are fixed on a strong aluminum frame, which is the base.
The choice of the design is determined by the main requirements: maximum movement speed, simplicity, and maximum reliability of the system. We consider three versions of the mechanical design. Version “A” has the appearance of a classic scheme, which is used in the manufacture of computernumerical-control machines (figure 3). It has two (cheaper schemes have one) lower motors that move the main beam with two running screws and determine the position of the ordinate axis (Y axis). Another motor is placed on the beam, which moves the carriage along the abscissa axis (X axis) with another running screw. Scheme “A” has such advantages as good positioning and excellent holding power and movement of the carriage, which is relevant for computer-numerical-control machines. However, it is not fast and requires much more additional relatively expensive components than schemes on belts. Belt schemes (figure 2) are often used in the construction of 3D printers of the cheap and middle segments of the market, so there are no problems with components and auxiliary mechanisms.
Scheme “B” is a family of 2-axis mechanisms called H-Bots [
The H-Bot is simple and very reliable, but adds some torque on the mechanism under heavy loads.
For example, when the belt is pulled down from the left side of letter “H” and up from the right side,
the force will try to twist the frame if there is too much resistance of the carriage in X. Scheme “C”
called CoreXY [
Therefore, we select the classic H-Bot layout to ensure the maximum speed of movement and reliability of the system under conditions of not applying excessive loads to the carriage, which in principle is not required for this task. The rating of stepper motors is determined based on the NEMA17 standard size with a torque of 3-4 kg/cm at a current of up to 2 A. They are usually used in 3D printers, extruders and small computer-numerical-control machines. For example, the NEMA17 JK42HS40 motor is quite suitable for such tasks by owing to that the motor has acceptable characteristics (table 1).
The driver for controlling the stepper motor is selected based on popularity, ease of connection to
the Raspberry Pi Compute Module, and energy eficiency. The DRV88xx series of drivers [
The PCM5102 module serves for the sound I2S DAC [
A laser distance sensor on the VL53L0X module serves for calibrating and adjusting the position
of the carriage. This is a miniature ToF (Time-of-Flight) distance sensor module that allows quickly
and accurately measuring distances up to 2 m. The module is connected via a common I2C serial
interface for device control and data transfer. The VL53L0X sensor is equipped with an advanced matrix
based on highly sensitive single-photon avalanche diodes. The principle of its operation is based on
STMicroelectronics’ patented FlightSense technology [
After powering on, the analog part of the system is ready to work almost immediately. The Raspberry Pi digital controller loads the operating system and starts its all related services within 10 seconds. The main internal logic of the system is shown in figure 6. If the system is idle without action for 60 seconds, it automatically goes into sleep mode to save power resources, which turns of all loads and puts the controller into a reduced power saving mode. The transition to operating mode occurs when the user presses a button on the panel, or activity on the Ethernet port. There is a light-emitting diode that indicates the current mode.
System start The Python script operations:
• Basic system checking • Reading out the configuration file • Starting the main C++ App in daemon mode with configuration keys
C++ Main App starting tasks:
• Validation of all the keys • Start of logging • Start of all the functional threads Movement thread
• Configures and controls the step motors operation using the drivers • Calculates motor speed and acceleration • Checks for the initial calibration and tunes the carriage position if needed
System core thread
• Checks for system events and exceptions • Reads and handles the sensors, vibromotor, and the user buttons • Outputs audio stream to headphones and video stream to the screen
Data thread
• Handles the incoming data from the provider server • Data processing (parsing, filtering, conversion) • Updates the moving queue with a new track for carriage
Control thread
• Handles the incoming commands • Switches the system modes • Tunes the system parameters • Responds with the current system state The Python script operations:
• Storing error logs • Storing the configuration • Double‐checking that all the peripherals are in safe mode
System turn‐off
The system starts by running a Python script that checks whether all necessary services are running in the operating system and performs basic settings. The script reads the configuration file that contains the saved data of the previous system session and runs a daemon program written in C++ with the appropriate configuration keys. For the main task, C++ is chosen because it provides maximum code execution speed and, accordingly, the operation of all system processes. Less demanding processes for execution time, such as system start, shutdown, and other related tasks, are written in Python, as they are easy to adjust and add new functionality if necessary.
The C++ program starts with a basic task that checks the settings, initiates the start of logging, and launches four main processes, which are responsible for the main operation of the system. Dividing the work of this IoT-based system into four separate processes allows distributing tasks more logically and functionally. This eventually allows parallelizing the system work without noticeable delays, overhead, or issues of non-synchronization.
The first process is responsible for movement. It performs the initial initialization of the TMC2209 driver parameters for optimal and smooth operation of the motors. For this, two system UART ports are used. The movement control itself is performed via the GPIO interface. At the beginning of the work, the carriage position is calibrated: the carriage is first moved along the entire Y axis until the optical sensor is triggered, then a similar operation is performed along the X axis and the carriage is placed exactly in the center of the playing field, which starts the main functionality. To prevent emergency situations and mechanical failure, the system provides a movement timeout without triggering the edge sensors, after which the motor movement stops and the system signals an error. Over time, a small position drift is possible caused by belt slippage or accidental skips in motor steps. However, the system constantly calculates the carriage position in the field, so when the marker and, accordingly, the carriage approaches an edge, it automatically adjusts its real position to the expected one. The first process also calculates the optimal motor speed and acceleration when the direction of the marker changes. In fact, the movement parameters are calculated after receiving data from the server (a tracking data provider), but before transferring control to the motor drivers.
The second process is the core of the IoT-based embedded system. This process is responsible for processing system events such as user pressing buttons, handling system exceptions, and terminating work. The process also polls the state of edge sensors via the I2C interface, controls signals to the vibration motor, controls the output of the audio stream via I2S/BLE to headphones and the output of the video stream to the optional HDMI/MIPI screen. This process is also an integral part of edge computing, since it provides the user with actually converted 2D game data before it is transferred to a games data warehouse.
The third process is responsible for obtaining data on the player’s movement on the field. It receives and processes data from the selected provider server (network gateway), but also it may receive data from storage. It performs data preprocessing, such as parsing, filtering, and converting into binary format, which is then added to the queue of the carriage movement trajectory, which is further handled by the process that monitors the movement. In simplified terms, the data stream is received in CSV format, strip by strip, where the belonging of each “column” is determined by the header (the first strip). The numbers in the specified columns are the coordinates of a particular player on whom a conditional marker is placed and whose movement is then monitored.
The control process is responsible for selecting a data column (i. e., the player on whom the marker is placed). This is the fourth, no less important, process in the system. The control process receives external commands from the user and responds to user’s requests. The commands are used to configure the system, select a server with data, start, stop the game, command to recalibrate the system, etc. With the help of the commands, a remote operator can find out the current state of the system. The command system itself is as simple as possible, being actually the command itself in a string form and several parameters that are added to it. Before each command, a unique ID is transmitted – a key number that constantly increases by one with each new command, which allows to clearly separate one command from another. A response with the same ID is generated for each incoming command. For example, command “12345,RECALL” does not require additional parameters and will recalibrate the mechanics, and next command “12346,DATASRVADDR,192.168.0.100” will set a new IP address for the data server. The response to the first command will be “12345,0”, where the status zero means the command has been executed without errors. This method allows to flexibly add new commands for controlling the system and makes it impossible to lose understanding of which previous command the response was received for.
To read field boundaries data from VL53L0X sensors, the I2C interface is used. In total, there are four identical sensors on each of the lines. All four sensors are hardware-connected to one two-wire line, and each has its own unique address on the bus in order to be able to query a specific sensor. The VL53L0X has a default I2C address of 0x29. But there is a software option to change it to any in the range 0x29...0x7F. Accordingly, the sensors that work in the system have addresses 0x2A, 0x2B, 0x2C, and 0x2D. Below (figure 7) is a commented example of a squeezed C++ code that initializes the interface, queries the sensors, performs averaging with outlier filtering. The result of the work is a conclusion whether the carriage is within the field; if not, then the current coordinates are corrected. This happens imperceptibly for the user and the corrected system continues to function.
After receiving the command to terminate the operation, the Python script again takes control, which records the operation log, saves the current system configuration, checks whether all peripherals are in normal mode, and safely parks the operating system.
The IoT-based system normally functions in two modes: operation and sleep. The main system operation characteristics are summarized in table 2 along with commentaries and explanations. The computing module boot time depends on settings and used services just like in the case of desktop operating
up to 5 ms
Non-configurable, although depends on the tracking data provider and how data are acquired (whether it is received from optical tracking systems and/or player-mounted wearable sensors) systems. The range of carriage calibration time is estimated by uniformly covering the miniaturized ifeld of a 105-by-70 cm size with a step of 5 cm. Motor release timeout is set to a minute due to the player’s inactivity (standstill, in fact) on a real pitch through a minute usually implies an injury or pending substitution. Sleep mode timeout is intended to save power. It is intended to be during the 15-minute break after the first half. By this very reason, system turn-of timeout is set to 20 minutes: if the player is still inactive following the 15-minute break for another 5 minutes, this means that he will not participate in the current match further.
The main system power characteristics are summarized in table 3 along with commentaries and explanations. The computing module consumes no more than 10 W, but this is about 22 % of what the stepper motor may consume. Meanwhile, our real-time experiments reveal that average system consumption is 19.3 to 22.1 W (this includes both time halves, while the 15-minute break is not included for obvious reason). A peak in 103 W occurs when both motors start moving at the same time at maximum speed. The vibration motor, drivers, the ToF distance sensor, and other peripherals consume at most 2.09 W. This power part, obviously, cannot be reduced.
Owing to internal protocols for data exchange among processes, as well as external protocols for
real-time data acquisition, are optimized based on neglecting states that have relatively low efect
on the overall model response [
of power compared to level , = 1, 2, . . ., where the amount of 93 W in (1) is the result of adding a couple of stepper motors (including consumption of the vibration motor, drivers, the ToF distance sensor, and other peripherals). Hence, the grand total of power 2 ( + 1) consumed by such a hierarchical network consisting of + 1 levels can be expressed recursively:
2 ( + 1) = 2 () + (93 + ) · 2− 1, = 1, 2, . . .
It is easy to prove that the power consumed by such a hierarchical IoT network consisting of levels (to show performance of 2 − 1 players) is
2 ( ) = 10 − + (93 + ) · 2 − 1, = 1, 2, . . .
Indeed, equality (3) can be proved by induction. The base case is when = 1, i. e. we have just a single node similar to the considered above:
2 (1) = 10 − + (93 + ) · 21− 1 = 10 − + 93 + = 103, which is true (table 3). By the inductive hypothesis we assume that equality (3) holds for any = : 2 () = 10 − + (93 + ) · 2− 1.
By the inductive step, we are about to show that equality (3) holds for = + 1. Here, 2 ( + 1) = 10 − + (93 + ) · 2+1− 1 = 10 − + (93 + ) · 2 = = 10 − + (93 + ) · 2− 1 + (93 + ) · 2− 1 = 2 () + (93 + ) · 2− 1.
The last term in (6) is the right side of true recursion (2), and this proves equality (3) by induction with (4) and (5). (2) (3) (4) (5) (6)
Alternatively, the system can be expanded to an IoT network, where data from sensors are distributed among miniaturized fields without constructing a hierarchy. If is a power amount required to route data to every newly added player (in the case of a single node considered above, it is already included into those 103 W), then it will consume an additional amount 93 + of power. Hence, the grand total of power par ( + 1) consumed by such a parallelized network consisting of + 1 players can be expressed recursively: par ( + 1) = par () + 93 + , = 1, 2, . . . (7) It is easy (even trivially, to some extent) to prove that the power consumed by such a one-level-split IoT network showing performance of players is
par ( ) = 10 − + (93 + ) · , = 1, 2, . . .
Indeed, equality (8) can be proved by induction as well. The base case is when = 1, i. e. we have just a single player:
par (1) = 10 − + (93 + ) · 1 = 10 − + 93 + = 103, which is true (table 3) coinciding also with (4). By the inductive hypothesis we assume that equality (8) holds for any = :
par () = 10 − + (93 + ) · .
By the inductive step, we are about to show that equality (8) holds for = + 1: par ( + 1) = 10 − + (93 + ) · ( + 1) = 10 − + (93 + ) · + 93 + =
= par () + 93 + .
The last term in (11) is the right side of true recursion (7), and this proves equality (8) by induction with (9) and (10).
Nevertheless, it is worth noting that the proved power equalities (3) and (8) make sense for situations, when the soccer player starts abruptly accelerating along either axis X or axis Y (i. e., horizontally or vertically, respectively). So, the amount of consumed power in equalities (3) and (8) is a close-to-worstcase scenario. In other situations, power consumption is less. (8) (9) (10) (11)
Compared to the performance of electronic applications, the developed system has a unique feature in its performance – tangibility. This feature is based on miniaturized mechanization of motion. Along with possibility to watch sports events closely enough, without necessarily touching the player’s model ifgure, acoustics of the events additionally builds up an efect of presence, although being simulated. Such a mechanical, non-virtual, reality simulation further improves perception and forms positive interest in the game. Such models providing useful information and aesthetically positive impression are especially precious for people with visual impairments, who become capable to include tactility into their perception of the game, if viewing detailed peculiarities of player’s motion is burdensome.
The computing module is edged as possible close to sensors with a purpose to further intensify data exchange without any delays during real-time game. Since 2010s, amounts of sports data acquired, collected, and recorded during matches have been gradually growing, becoming factually Big Data instances. So, this is crucial to further edge and parallelize computational systems in order to respond to the known Big Data challenges. Our system complies with those challenges by providing almost linear power consumption with respect to stepper motors, which are the most power-consuming in the system, and by neglecting data of non-efective states in the system.
The developed system is not just an amusement – replays of recorded games serve as an alternative approach for coaches and analysts to review player’s consistency and vision of pitch in struggling situations. Besides, in soccer, often conceded goals from free kicks and corner kicks are results of improper individual actions of a definite player (say, defender). In this way, along with watching screen motion, miniaturized mechanical replay of the player’s mistaken behavior helps better understand how to rectify individual and team tactics during free kicks and corner kicks.
Obviously, exposing performance of only one player on the miniaturized field seems to be a demerit. Indeed, our model cannot show the entire miniaturized match. Putting two and more players on the same field would require much complicated mechanics, which at the moment looks implausible due to physical obstacles of multiple belts and likely interference from magnets. A possible solution might be in using multilayered H-Bots by placing each carriage magnet on its own layer, but then each magnet would require to have specific calibration and amperage to hold tightly to the corresponding magnetic marker of the player.
Another drawback is the carriage calibration time. The carriage position is calibrated automatically,
but it takes 3 to 10 seconds to complete calibration. Calibration during a real-time match takes about 3
to 5 seconds, which may incur significant delays, despite sensor readout time is just up to 5 milliseconds.
Calibration during a real-time match is caused mainly by inertia of stepper motors, belt slippage, and
accidental skips in motor steps [
For the purposes of perception improvement in sport analysis and entertainment, we have suggested a conceptual model of an IoT-based embedded system of mechanizing sport competition motion on a miniaturized sports field. The system operated by a Raspberry Pi Compute Module allows visually, tangibly, and acoustically perceiving location and motion of a player within sports field in accordance with his real-time motion. Recorded motion is reproducible as well. Motion data, acquired either from wearable sensors or by optical tracking systems and event data providers on wireless gateways in the stadium, are transmitted to the computing module for further filtering, truncating, and processing. The mechanical part of the system is based on the classic H-Bot layout with two stepper motors whose torques, determined by the real player’s location and motion information, impart corresponding motion to the miniature player.
Based on the system tests for soccer with Raspberry Pi Compute Module 5, our system consumes no more than 103 W at peak, while average electric power consumption does not exceed 23 W. Besides, system power consumption is almost linear with respect to the 90 W consuming stepper motors, which makes this system expandable and scalable both hierarchically and linearly. Power consumption linearization is additionally facilitated by neglecting data of non-efective states in the soccer-exemplified system. In general, such optimization of internal protocols for data exchange among processes, as well as external protocols for real-time data acquisition, speeds up and rectifies the system response to actual player’s motion on the sports field. The soccer-exemplified system has a 5 millisecond response, although the mechanical part with the two-belted carriage of the miniature player may incur a-few-seconds delays of accurately reproducing player’s motion. The inaccuracy within a 105-by-70 cm miniaturized ifeld is 3 mm at most, though, which is unlikely to be very noticeable.
Carriage calibration is still an open question yet the system boot requires special consideration. The matter is the worst boot case including initial carriage calibration is about 35 seconds, which seems to be pretty long. Another open question remaining to be studied is how the computing module must handle data frames with missed data and probable outliers. Handling the latter successfully is expected to have a strong impact on shortening the carriage calibration time.
Author Contributions: V. Romanuke and S. Dementiev conceived the system. S. Dementiev designed the system architecture and selected its components by supervision of V. Romanuke and S. Yaremko. S. Dementiev wrote most of the codes for the system functioning, while V. Romanuke measured timing and energy characteristics of the completed system. V. Romanuke wrote drafts for sections 1, 3, 8; S. Dementiev wrote drafts for Sections 2, 4, 5; sections 6 and 7 were drafted by V. Romanuke and S. Yaremko. V. Romanuke and S. Yaremko made the finalized layout of the paper. Funding: This research received no external funding.
Data Availability Statement: Data of this research are available upon request.
Declaration on Generative AI: The authors have not employed any generative AI tools.