Date: Thu, 28 Mar 2024 22:57:10 +0100 (CET) Message-ID: <2145097284.79.1711663030069@vmisdata19.uni-oldenburg.de> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_78_68846955.1711663030069" ------=_Part_78_68846955.1711663030069 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
from: http://www.= orgs.ttu.edu/debs2013/index.php?goto=3Dcfchallengedetails
With this year's challenge, we seek to demonstrate the applicability of = event-based systems to provide real-time complex analytics over high veloci= ty sensor data along the example of analyzing a soccer game. The data for t= he DEBS 2013 Grand Challenge originates from a number of wireless sensors e= mbedded in the shoes and a ball used during a soccer match and spans the wh= ole duration of the game. The real-time analytics includes the continuous c= omputation of statistics of relevance to spectators (ball possession, shots= on goal) as well as trainers and team managers (running analysis of team m= embers').
The data used in this year DEBS Grand Challenge is collected by the Real=
-Time Locating System deployed=
on a football field of the Nuremberg Stadium in Germany. Data originat=
es from sensors located near the players' shoes (1 sensor per leg) and in t=
he ball (1 sensor). The goal keeper is equipped with two additional sensors=
, one at each hand. The sensors in the players' shoes and hands produce dat=
a with 200Hz frequency, while the sensor in the ball produces data with 200=
0Hz frequency. The total data rate reaches roughly 15.000 position events p=
er second. Every position event describes position of a given sensor in a t=
hree-dimensional coordinate system. The center of the playing field is at c=
oordinate (0, 0, 0) - see Figure 1 for the dimensions of the playing field =
and the coordinates of the kick off. The event schema is following:
sid, ts, x, y, z, |v|, |a|, vx, vy, vz, ax, ay, az
where sid is a sensor id which produced the position event, ts is a timest=
amp in picoseconds, e.g.: 10753295594424116 (with the value of 107532955944=
24116 designating the start and 14879639146403495 the end of the game); x, =
y, z describe the position of the sensor in mm (the origin is the middle of=
a full size football field) ; |v| (in =CE=BCm/s), vx, vy, vz describe dire=
ction by a vector with size of 10,000. Hence, the speed of the object in x-=
direction in SI-units (m/s) is calculated by
v'x =3D |v| * =
vx * 1e-4 * 1e-6
(vx in m/s is derived by |v| * 1e-10 * vx) and |a| (in =CE=BCm/s=C2=B2), a=
x, ay, az describe the absolute acceleration and its constituents in three =
dimensions (the acceleration in m/s=C2=B2 is calculated similar to that of =
the velocity). The acceleration does not include gravity, i.e. |a| is zero =
when the ball is at a fixed position and not 9.81 m/s=C2=B2).
Figure1: Playing field and its dimensions<=
/em>
In addition to the sensor data we also provide a separate data stream fo= r referee events, which includes the time when a game was paused and the ti= me when a game was resumed. Moreover, referee events contain the time and p= layer_ids for substitutions.
The mapping between player ids and team ids as well as between sensor id= and player id is provided in the metadata file. The game, during which the= data has been collected, was played on a half-size field with teams of sev= en players each. The game duration was two halves of thirty minutes each. W= e assume that the data arrives at the system under test without any delays,= nor omissions.
Raw sensor data for the game can be downloaded from: here (2.6 GB). All data has been aggregated i= s a single file and is sorted by time stamps. The video recording of the ga= me (vertical view, static camera) can be downloaded from: here (1st half, 1.7 GB) and here (2nd half, 1.7GB). The m= etadata file that contains player's names and associated transmitter ids, d= etailed field coordinates etc. can be downloaded from: here (10 kB). Game interruptions, ball possess= ion statistics, and shots on goal statistics can be downloaded from: here (10 kB). These sta= tistics have been manually created manually and can serve as an aid in vali= dating the respective query results.
In the following section we identify a number of queries which need to r= un concurrently and process the position data. Results of all queries must = be returned as a stream of data, unless explicitly stated otherwise.
The goal of this query is to calculate the analysis of the running perfo= rmance of each of the players currently participating in the game. The inte= nsities are defined as: standing (0-1 km/h), trot (till 11 km/h), low speed= run (till 14 km/h), medium speed run (till 17 km/h), high speed run (till = 24 km/h), and sprint (faster than 24 km/h). Figure 2 shows the possible tra= nsitions between different states which need to be observed for the running= analysis.
Figure 2 - Transitions between running in=
tensities for Query 1
In order to accommodate for the noise in the raw velocity measurements, = the actual speed of the run should be computed from all the individual spee= d norms of a player's transmitters. Here you can see an example plot of the= velocity of the ball:
Figure 3 - Velocity of the b=
all over time
The running analysis query should return two classes of results: (1) cur= rent running statistics and (2) a set of aggregate running statistics. The = current running statistics should be returned at a frequency of at most 50H= z and must contain following information: ts_start, ts_stop, playe= r_id, intensity, distance, speed
Where ts_start represents the start of the measurement, ts_stop represen= ts the end of the measurement, player_id is the identifier of a player, int= ensity describes the intensity of the run, distance is the length of the ru= n (in the horizontal plane only) between ts_start and ts_stop, and speed is= the average speed of the given intensity run.
The aggregate running statistics must contain following information:
ts, player_id, standing_time, standing_distance, trot_time, tro= t_distance, low_time, low_distance, medium_time, medium_distance, high_time= , high_distance, sprint_time, sprint_distance
where the ts represent the latest time stamp which updated the statistic= s, the player_id is the player identifier, xxx_time is the time player spen= t in the xxx intensity (in milliseconds), xxx_distance is the distance cove= red with the xxx intensity. The aggregate running statistics must be calcul= ated using four different time windows: 1 minute, 5 minutes, 20 minutes and= the whole game duration. Each window must emit an event with the frequency= of 50Hz. The result will be four aggregate running statistics streams bein= g returned by the system for each of the required window lengths. Moreover,= every running intensity, which has been active for less than a second must= be counted on top of the next intensity with a duration longer than 1s. Fo= r example, if a player is in a trot state for a longer time, then in a low = speed run state for 0.8 seconds, and then in a medium speed run state for a= longer time, the time of the low speed run is to be counted on top of the = medium speed run.
Please note that the requirement to count only intensities active for at= least one second requires you to delay the output until a reliable measure= ment has been made.
The goal of this query is to calculate the ball possession for each of t= he players as well as for whole team. A player (and thereby his repective t= eam) can obtain the ball whenever the ball is in his proximity (less than o= ne meter away - calculated as the distance between the ball sensor and the = closest sensor of the player) and he hits (the ball acceleration peaks) it.= The ball will stay in his possession until another player hits it, the bal= l leaves the field, or the game is stopped. The ball possession is calculat= ed as time between the first ball contact (hit) and the last ball contact (= hit). The ball may leave the player proximity and will still stay in his po= ssession.
Figure 4 - Ball possession states
A ball is hit if its (transmitter) distance from a player's foot (transm= itter) is less than 1 meter and its acceleration reaches a value of minimal= 55 m/s=C2=B2. This value depends heavily on the fitness of the players - v= alues of up to 100 m/s=C2=B2 are more suitable for professional games. It m= ay be appropriate to apply a mean filter onto the acceleration values in or= der to get better detection performance.
The ball position query should return two classes of results: (1) per pl= ayer ball possession stream and (2) per team ball possession. The per playe= r ball possession stream should contain following information:
ts, player_id, time, hits
where the ts is the latest time stamp of the event which lead to the upd= ate of the ball possession, player_id is the player identifier, time is the= total time of the ball possession for a given player, and hits is the tota= l number of ball contacts of a given player. The per team ball possession r= esult stream must contain following statistics:
ts, team_id, time, time_percent
where the ts is the latest time stamp of the event which lead to the upd= ate of the team's ball possession, team_id is the team identifier, time is = the total time of the ball possession for a given team, time_percent is a %= of the ball possession for a given team w.r.t. the total ball possession t= ime of both teams. The per team ball possession should be calculated using = four different time windows: 1 minute, 5 minutes, 20 minutes and the whole = game duration. This results in four aggregate ball possession statistics re= sult streams being returned by the system for each of the required window l= engths.
Each statistics streams should be returned with the frequency of maximum= 50Hz
The goal of this query is to calculate statistics for how long each of t= he players spent in which region of the field. For this purpose we define a= grid with X rows along the x-axis and Y columns along the y-axis of equal = size. The parameters X and Y should be implemented with following values 8 = and 13 (a grid of 104 cells), 16 and 25, 32 and 50, 64 and 100 (a grid of 6= ,400 cells), respectively. The system should return results for all paramet= er settings in parallel but different result streams.
The system must provide for each cell and each player the percentage of = time that the player spent in the respective cell over four different time = windows: 1 minute, 5 minutes, 10 minutes and the whole game duration. This = results in 16 result streams being returned by the system for each of the r= equired window lengths and parameters for the grid resolution. Each result = stream must be updated once per second and contain the following informatio= n:
ts, player_id, cell_x1, cell_y1, cell_x2, cell_y2, percent_time= _in_time_cell
where the ts represent the time stamp of the latest statistics update, t= he cell_x1, cell_y1, cell_x2, cell_y2 are the coordinates of the lower left= and upper right corner of the cell - respectively, the player_id is the pl= ayer identifier, percent_time_in_time_cell is the percentage of time that p= layer spent in the cell during the period specific to the result stream (0.= 00%-100.00%).
The aim of this query is to detect when a player shoots the ball in an a= ttempt to score a goal. A shot on the goal is defined as any shot that woul= d hit (or closely miss) the goal of the opposing team. Note, that this incl= udes unsuccessful attempts that are e.g. blocked by a player or saved by th= e goal keeper.
Below we provide suggestions for the implementation of the shot detectio= n. However, we also allow alternative implementations that yield good resul= ts (i.e. closely resemble the result lists provided in referee-events.tar.gz).
Figure 5 gives an overview of suggested states and transitions of the sh= ot detection. A shot is detected if the player with id <player_id> hi= ts the ball with a minimal acceleration of 55 m/s=C2=B2, and the projected = movement of the ball would cross the opponents' goal area within 1.5 second= s after the hit. The goal areas are defined as rectangles with the followin= g coordinates:
Goal area team 1: x > 22578.5 and x < 29898.5, y =3D 3394=
1.0, z < 2440.0
Goal area team 2: x > 22560.0 and x < 29880.0, y =3D -33968.0, z <=
; 2440.0
Please note that the hit distorts the speed values of the ball. The data= are preprocessed by a Kalman-filter and stabilize over time. The computati= on of the projection may take this into account. To allow for corrective me= asures we only require that the shot is detected at latest when the ball mo= ved 1m away from the hit location.
We leave it open in the challenge to which degree the projection conside= rs the physics of a flying ball in the projection. A base-line solution tha= t simply extrapolates the motion vector is acceptable. However, more accura= te computations of the ball movement (e.g. considering gravity) would be ap= preciated.
For the duration of the shot (i.e. as long as the state "shot on goal" i= n Figure 5 is active) the result stream should be updated with motion value= s of the ball and the ID of the shooting player:
ts, player_id, x, y, z, |v|, vx, vy, vz, |a|, ax, ay, az
The result stream should be updated with the frequency of the sensor dat= a until an exit condition occurs. Exit conditions are (a) the ball leaves t= he field, or (c) the direction changes such that the goal area would no lon= ger be hit.
Figure 5 - Shot on goal states