Sensorrohdaten zum Download

Die DEBS 2013 Grand Challenge der Association for Computing Machinery (ACM) ist die dritte einer Reihe von Challenges mit dem Ziel, gemeinsame Grundlagen und Bewertungskriterien für ereignisbasierte Systeme in Forschung und Industrie zu entwickeln. Aufgabe der Teilnehmer dieser Grand Challenge ist es, eine Lösung für das von den Organisatoren gestellte Problem zu implementieren.
Die im Rahmen der DEBS Grand Challenges gestellten Probleme sind für die Branche insgesamt insofern hochrelevant,  als sie eine Bewertung ereignisbasierter Systeme anhand authentischer Daten und realitätsnaher Abfragen ermöglichen.

Die Teilnehmer der DEBS 2013 Grand Challenge müssen  erstens (1) ein sechsseitiges schriftliches Dokument im Format der SIG-Tagungsberichte von ACM einreichen, in der die Lösung kurz dargestellt und ihr innovativer Charakter sowie die Bewertungsmethode erläutert werden. Darüber hinaus (2) müssen sie zur Vorführung ihrer Lösung ein Video oder Screencast vorlegen. Alle Einsendungen werden einem Peer-Review unterzogen. Bei Annahme ihrer Beiträge dürfen die Teilnehmer ihr System auf der DEBS 2013 Conference präsentieren. Sofern sich die Teilnehmer ausdrücklich damit einverstanden erklären, werden die eingereichten Lösungen in die Gesamtwertung einbezogen.

Die Bekanntgabe des Gewinners der Grand Challenge und die Übergabe des Preises erfolgen feierlich im Rahmen eines Banketts. Die Gesamtwertung beruht auf den von den Reviewern erteilten Punktzahlen und der Leistungsbilanz der Lösung. Als Kriterien für das Leistungsvermögen gelten, unter der Annahme, dass die ausgegebenen Ergebnisse korrekt sind, der Datendurchsatz und die Latenz des Systems.

Problembeschreibung

Im Mittelpunkt der Challenge steht der Nachweis der Eignung ereignisbasierter Systeme zur komplexen Analyse von Daten hochschneller Sensoren in Echtzeit. Ein typisches Anwendungsbeispiel ist die Analyse eines Fußballspiels. Die Daten für die DEBS 2013 Grand Challenge stammen von einem Satz drahtloser Sensoren im Ball und den Schuhen der Teilnehmer eines Fußballspiels. Erfasst wurde der gesamte Spielverlauf. Die Echtzeitanalyse besteht in der kontinuierlichen Erstellung relevanter Statistiken für die Zuschauer (Ballbesitz, Torschüsse) sowie die Trainer und Team Manager (Laufanalysen der einzelnen Spieler).

Daten 

Die Daten der diesjährigen DEBS Grand Challenge lieferte ein Echtzeit-Lokalisierungssystem auf dem Feld des Nürnberger Fußballstadiums. Und zwar stammen die Daten von Sensoren, die nahe den Schuhen der Spieler (1 Sensor pro Bein) sowie im Ball (1 Sensor) angebracht waren. Der Torwart wurde darüber hinaus auch mit einem Sensor an jeder Hand ausgestattet. Die Fühler nahe den Schuhen der Spieler sowie an den Händen des Torwarts übertragen mit einer Frequenz von 200 Hertz. Der Sensor im Ball überträgt mit 2000 Hertz. Damit umfasst der Datenfluss insgesamt ca. 15.000 Bewegungsereignisse pro Sekunde. Jedes Ereignis beschreibt die Position eines Sensors in einem dreidimensionalen Koordinatensystem. Dabei entspricht die Koordinate (0, 0, 0) der Mitte des Spielfeldes (vgl. Abb. 1 für die Abmessungen des Fußballfeldes und die Koordinaten zum Zeitpunkt des Anpfiffs). Das Ereignisschema ist wie folgt gegliedert:

sid, ts, x, y, z, |v|, |a|, vx, vy, vz, ax, ay, az

wobei sid die ID des Sensors, der das Bewegungsereignis erzeugt, und ts ein Zeitstempel in Pikosekunden, z.B. 10753295594424116 (10753295594424116 entspricht dem Spielbeginn und 14879639146403495 dem Ende der Begegnung), ist. x, y und z beschreiben die Position des Sensors in mm (der Ursprung des Koordinatensystems deckt sich mit der Mitte eines Fußballfeldes normaler Größe). |v| (in μm/s) sowie vx, vy, vz entsprechen der Ausrichtung eines Vektors der Größe 10.000. Somit lässt sich die Geschwindigkeit des Objekts in x-Richtung wie folgt berechnen und in SI-Einheiten (m/s) angeben:

v’x = |v| * vx * 1e-4 * 1e-6

(vx in m/s wird durch |v| * 1e-10 * vx abgeleitet) und |a| (in μm/s²), ax, ay, az drücken die absolute Beschleunigung und ihre Komponenten in den drei Dimensionen aus (die Beschleunigung in m/s² wird auf ähnliche Weise wie die Geschwindigkeit ermittelt). Die Schwerkraft wird nicht berücksichtigt, d.h. |a| beträgt 0 und nicht 9,81 m/s², wenn sich der Ball nicht bewegt.

Zusätzlich zu den Sensordaten wird ein separater Datenfluss für schiedsrichterbezogene Ereignisse bereitgestellt; hierzu zählen Beginn und Ende der Spielunterbrechungen,  aber auch der Zeitpunkt und die Spieler-ID player_ids bei Einwechselungen.

Die Mapping-Beziehungen zwischen player_id und team_id sowie zwischen sensor_id und player_id sind in einer Metadatei enthalten.
Das Spiel, bei dem die Daten gesammelt wurden, wurde auf einem Spielfeld von halber Normalgröße mit je sieben Spielern ausgetragen,  wobei die Halbzeiten jeweils dreißig Minuten dauerten. Weiterhin wurde angenommen, dass die Daten ohne Verzögerungen oder Ausfälle an das zu testende System übertragen werden.

Die Sensorrohdaten des Spiels können unter folgender Adresse heruntergeladen werden:
http://www2.iis.fraunhofer.de/sports-analytics/full-game.gz (2.6 GB).

Die Daten wurden nach Zeitstempeln geordnet in einer einzigen Datei zusammengefasst. Die Videoaufnahmen des Spiels (vertikal ausgerichtete, statische Kamera) lassen sich unter folgenden Adressen herunterladen:

http://www2.iis.fraunhofer.de/sports-analytics/RedFIR_2012_1.mov (1st half, 1.7 GB)

and http://www2.iis.fraunhofer.de/sports-analytics/RedFIR_2012_2.mov (2nd half, 1.7GB).

Die Metadatei enthält die Namen der Spieler und deren Sender-ID sowie die detailierten Koordinaten des Spielfeldes. Heruntergeladen werden kann sie: hier (10 kB).

Die Spielunterbrechungen, die Statistiken zum Ballbesitz und zu den Torschüssen können unter http://www2.iis.fraunhofer.de/sports-analytics/referee-events.tar.gz  (10 kB) heruntergeladen werden.

Sie wurden manuell erstellt und können zur Validierung der Abfrageergebnisse benutzt werden.

Abfrage 1: Laufleistung

Ziel dieser Abfrage ist die Berechnung der Laufleistung jedes beteiligten Spielers zu Analysezwecken. Es sind folgende Intensitätsgrade im System definiert: Stehen (0-1 km/h), Traben (bis zu 11 km/h), Laufen – langsam (bis zu 14 km/h), Laufen – mittel (bis zu 17 km/h), Laufen – schnell (bis zu 24 km/h) und Sprinten (über 24 km/h). Abbildung 2 zeigt die möglichen Übergänge zwischen den Intensitätsgraden, wie sie für die Analyse der Laufleistung erfasst werden müssen.

Bei der Abfrage der Laufleistung muss das System zwei Kategorien von Ergebnissen ausgeben: (1) die aktuelle Laufstatistik und (2) einen Satz aggregierter Laufstatistiken. Die Statistik bis zu einem bestimmten Zeitpunkt muss mit einer Frequenz von maximal 50 Hertz ausgegeben werden und folgende Informationen enthalten:

ts_start, ts_stop, player_id, intensity, distance, speed

Dabei steht ts_start für Beginn der Messung, ts_stop für das Ende der Messung, player_id für den betreffenden Spieler, intensity für den Intensitätsgrad der Laufbewegung, distance für die zwischen ts_start und ts_stop zurückgelegte Laufstrecke (nur auf waagrechter Ebene). Mit speed ist die Durchschnittsgeschwindigkeit über die gemessene Laufstrecke mit festem Intensitätsgrad gemeint.

Die aggregierten Laufstatistiken müssen folgende Informationen enthalten:

ts, player_id, standing_time, standing_distance, trot_time, trot_distance, low_time, low_distance, medium_time, medium_distance, high_time, high_distance, sprint_time, sprint_distance

wobei ts für den Zeitstempel des letzten Updates der Statistiken steht, player_id für den betreffenden Spieler, xxx_time für die Zeit (Millisekunden), für die der Spieler mit der Intensität xxx lief, und xxx_distance für die Entfernung, die der Spieler mit der Bewegungsintensität xxx zurücklegte. Die aggregierten Laufstatistiken sind für vier verschiedene Zeitfenster zu berechnen: 1 Minute, 5 Minuten, 20 Minuten und die Gesamtdauer der Begegnung. Für jedes Fenster müssen die Ereignisse mit einer Frequenz von 50 Hertz übertragen werden. Die daraus resultierenden vier Datenströme enthalten die über die Dauer der vier Zeitfenster aggregierten Statistiken. Darüber hinaus muss jeder für weniger als eine Sekunde erfasste Intensitätsgrad zu dem nächstfolgenden, mit einer Dauer von mehr als 1 Sekunde erfassten Intensitätsgrad hinzugezählt werden. Beispielsweise ist im Falle eines Spielers, der über längere Zeit trabt, dann für 0,8 Sekunden langsam läuft und anschließend für längere Zeit mit mittlerer Geschwindigkeit läuft, die Dauer der Laufphase mittlerer Geschwindigkeit um die Dauer der langsamen Laufphase zu erhöhen.

Bitte beachten Sie, dass sich bei ausschließlicher Zählung der über eine Sekunde lang erfassten Intensitätsgrade die Datenausgabe verzögert, bis entsprechend zuverlässige Messungen erfolgt sind.

Abfrage 2: Ballbesitz

Gegenstand dieser Abfrage ist die Ermittlung des Ballbesitzes für jeden Spieler und die gesamte Mannschaft. Ein Spieler (und somit seine Mannschaft) kann den Ball in seinen Besitz bringen, sobald der Ball sich in seiner Nähe befindet (weniger als 1 m Abstand zwischen dem Sensor im Ball und dem räumlich nächsten Sensor des Spielers) und er den Ball tritt (Beschleunigungsspitze). Der Ball gilt als in seinem Besitz befindlich, bis ihn der Fuß eines anderen Spieler tritt, der Ball das Feld verlässt oder das Spiel unterbrochen wird. Als Ballbesitz gilt die Zeit zwischen dem ersten Ballkontakt (Tritt) und dem letzten Ballkontakt (Tritt). Der Ball kann somit den Nahbereich des Spielers verlassen, ohne dass der Ballbesitz damit endet.

Ein Ball gilt als getreten, wenn die Entfernung (seines Messsenders) vom Fuß des Spielers (Messsender) weniger als 1 m beträgt und seine Beschleunigung einen Wert von mindestens 55 m/s² erreicht. Dieser Wert ist allerdings stark von der Fitness der Spieler abhängig: bei professionellen Spielern sind eher Werte bis zu 100 m/s² geeignet. Zur Verbesserung der Messleistung könnte sich daher die Aufschaltung eines Mittelwertfilters auf die Beschleunigungswerte als sinnvoll erweisen.

Bei Abfrage des Ballbesitzes muss das System zwei Ergebnisarten in Form von Datenströmen ausgeben: (1) den Ballbesitz pro Spieler und (2) den Ballbesitz pro Mannschaft. Für den Ballbesitz pro Spieler muss der Datenstrom folgende Informationen beinhalten:

ts, player_id, time, hits

Dabei steht ts für den Zeitstempel des letzten Ereignisses, das ein Update des Ballbesitzes bewirkt hat, player_id für den betreffenden Spieler, time für die Gesamtdauer des Ballbesitzes dieses Spielers und hits für die Gesamtzahl der Ballkontakte des Spielers.
Für den Ballbesitz der Mannschaft muss der Datenstrom folgende statistische Informationen beinhalten:

ts, team_id, time, time_percent

mit ts als Zeitstempel des letzten Ereignisses, das ein Update des Ballbesitzes der Mannschaft bewirkt hat, team_id als Kennung der Mannschaft, time als Gesamtdauer des Ballbesitzes der Mannschaft, time_percent für den Prozentanteil der Mannschaft am Ballbesitz beider Teams insgesamt. Der Ballbesitz pro Mannschaft ist für vier Zeitfenster zu berechnen: 1 Minute, 5 Minuten, 20 Minuten und die gesamte Spieldauer. Die vier aggregierten Ballbesitzwerte werden dann als Datenströme über die jeweilige Größe des Zeitfensters ausgegeben.

Das System darf Datenströme mit einer Frequenz von maximal 50 Hertz erzeugen.

Abfrage 3: Heatmap

Gegenstand dieser Abfrage sind statistische Angaben zur Dauer des Aufenthalts der einzelnen Spieler in verschiedenen Teilen des Spielfelds. Das Spielfeld wird in X gleich breite Reihen parallel zur x-Achse und Y gleich weite Spalten längs der y-Achse unterteilt. Für die Parameter X und Y sind jeweils die Werte 8 und 13 (104 Zellen), 16 und 25, 32 und 50 sowie 64 und 100 (6400 Zellen) zu wählen. Das System muss die Ergebnisse für alle Parametereinstellungen parallel in separaten Datenströmen ausgeben.

Für jede Zelle und jeden Spieler muss das System die Zeit, die der Spieler in einer gegebenen Zelle verbracht hat, als Prozentwert für vier verschiedene Zeitfenster, nämlich 1 Minute, 5 Minuten, 10 Minuten und die Gesamtdauer der Begegnung, ausgeben. Daraus resultieren 16 Datenströme, die das System für jedes Zeitfenster und alle Netzparameter erzeugen muss.
Jeder dieser Datenströme ist einmal pro Sekunde zu aktualisieren und enthält folgende Informationen:

ts, player_id, cell_x1, cell_y1, cell_x2, cell_y2, percent_time_in_time_cell

wobei ts der Zeitstempel des letzten Updates der Statistik, cell_x1, cell_y1, cell_x2 und cell_y2 jeweils die Koordinaten der unteren linken und der oberen rechten Ecke der Zelle, player_id der betreffende Spieler und percent_time_in_time_cell der Prozentwert für die Zeit ist, die der Spieler während des für den Datenstrom definierten Zeitfensters in der betreffenden Zelle verbracht hat (0,00% - 100,00%).

Abfrage 4: Torschüsse

Gegenstand dieser Abfrage sind die Zeitpunkte, zu denen ein Spieler den Ball schießt, um ein Tor zu erzielen. Ein Torschuss ist jeder Schuss, der das Tor der gegnerischen Mannschaft trifft (oder knapp verfehlt). Dabei ist zu beachten, dass dies auch für die misslungenen Versuche, ein Tor zu erzielen, d.h. die von einem Spieler abgewehrten oder dem Tormann gehaltenen Schüsse, gilt.

Die nachstehenden Empfehlungen sollen Ihnen die Implementierung des Torschuss-Sensors erleichtern. Wir gestatten aber auch alternative Implementierungslösungen, wenn sie gute (d.h. der Ergebnisliste in der Datei referee-events.tar.gz ähnliche) Ergebnisse ermöglichen.

Abbildung 5 bietet einen Überblick über die Status und Status-Übergänge, die wir für die Erkennung von Torschüssen empfehlen. Ein Torschuss liegt vor, wenn der Spieler mit der id player_id> den Ball um mindestens 55 m/s² beschleunigt und die daraus ableitbare Bahn des Balls den Torraum der gegnerischen Mannschaft innerhalb von 1,5 Sekunden nach dem Tritt durchqueren würde. Als Torräume gelten dabei die Rechtecke mit folgenden Koordinaten:

Torraum Mannschaft 1: x > 22578,5 und x < 29898,5, y = 33941,0, z < 2440,0 
Torraum Mannschaft 2: x > 22560,0 und x < 29880,0, y = -33968,0, z < 2440,0

Bitte beachten Sie, dass der Tritt des Spielers die Geschwindigkeitswerte des Balls verfälscht. Die Daten werden daher durch einen Kalman-Filter vorverarbeitet und stabilisieren sich dann nach und nach. Bei der Berechnung der Flugbahn des Balls kann dies dann berücksichtigt werden. Zur Ermöglichung der Korrekturmessungen fordern wir lediglich, dass der Schuss spätestens dann erkannt wird, wenn sich der Ball bis auf 1 m vom Punkt der Berührung durch den Spieler entfernt hat.

Wir überlassen es den Teilnehmern der Challenge, in welchem Maße die Physik eines fliegenden Balls bei der Bahnberechnung berücksichtigt wird. Eine Basisvariante in Form einer Extrapolation des Bewegungsvektors wird als Lösung akzeptiert. Genauere Berechnungen der Ballbewegungen (z.B. unter Berücksichtigung der Schwerkraft) sind aber durchaus erwünscht.

Für die Dauer des Torschusses (d.h. solange der Zustand „Torschuss“ in Abbildung 5 aktiv ist) muss der Datenstrom mit den Bewegungswerten des Balls und der ID des schießenden Spielers aktualisiert werden:

ts, player_id, x, y, z, |v|, vx, vy, vz, |a|, ax, ay, az

Der vom System ausgegebene Datenstrom muss mit der Frequenz der Sensordaten aktualisiert werden, bis eine Abbruchbedingung erfüllt wird. Abbruchbedingungen sind: (a) der Ball verlässt das Spielfeld und (b) der Ball wechselt die Richtung, sodass er sich nicht länger auf den Torbereich zubewegt.

1.     Wird es nur eine Datei für alle Sensoren oder eine Datei pro Sensor geben? (Ich nehme letzteres an.) Ja, gibt es. Aber ich werde ein Wiedergabegerät bereitstellen, das die Dateien öffnet und die Positionsdaten in Echtzeit wiedergibt. Dazu müssen wir allerdings das Datenformat definieren. Sollten die Daten über eine Buchse oder ähnliches ausgegeben werden?

2.     In welchen Einheiten erfolgt die Angabe von Position, Geschwindigkeit und Beschleunigung? Ist das nun klar? Ich kann eingehender erklären, warum die gewählten Einheiten im Hinblick auf die eigentliche Problemstellung so seltsam anmuten.

3.     Wie lässt sich erkennen, welcher Sensor zu welchem Spieler (Schuh) gehört und welcher der Ballsensor ist (wohl anhand des Dateinamens, nehme ich an)? Ich würde dafür eine XML-Datei bereitstellen, ok? Oder könnten wir das einfach in Textform festlegen? Das wäre vielleicht die einfachste Lösung.

4.     Können wir davon ausgehen, dass die Daten an das zu testende System geordnet und ohne Lücken übertragen werden? Ja.

5.     Abb.1 – Wie lautet die Definition von aktiver/inaktiver Zustand eines Spielers? Wie lässt sich ein solcher Zustand mit Hilfe der Sensordaten erkennen? Ich denke, dieses Kriterium können wir abschaffen. Ein aktiver Spieler ist ein Spieler, der an dem Match teilnimmt, d.h. der nicht auf der Auswechselbank sitzt. Natürlich kann es während des Matchs Einwechselungen geben. Der Club hat uns viele Spieler überlassen.

6.     Beschreibung von Abfrage 1: Die Laufzeitanalyse von Fraunhofer schließt Spieler mit Tracking-Status ein. Wie lässt sich dieser Status an den Sensordaten erkennen? Ich denke, diesen Status können wir abschaffen. Denn die Tracking-Funktion weist manchmal Defekte auf und es fehlen Positionen. Und wenn das Tracking wieder ansetzt, sind die Geschwindigkeitswerte dann fehlerhaft und die Laufzeitanalyse misslingt. Ich hoffe, dass dies bei uns nicht passiert.

7.     Abfrage 1 – Laufanalyse: Was ist der Zweck der Entfernungsangaben (min, max, Durchschnitt) zu dem Parameter intensity (Intensitätsgrad)? Das sind statistische Informationen zu den Distanzen, über die manche Spieler in einem bestimmten Intensitätsgrad der Fortbewegung verharren. Beispielsweise rennen sie über sehr kurze Distanzen; bei langsamem Laufen sind die Entfernungen erheblich größer.

8.     Abfrage 1 – Laufzeitanalyse. Welchen Zweck haben die Geschwindigkeitsangaben (min, max, Durchschnitt) zu dem Parameter intensity (Intensitätsgrad)? Diese Angaben haben hier in der Tat nichts zu suchen. Sie sollten nicht Bestandteil der Laufzeitanalyse sein. Interessant sind diese Angaben zu den einzelnen Spielern und Mannschaften bezogen auf die Zeitfenster.

9.     Abfrage 2 – Ballbesitz. Wie lässt sich erkennen, welcher Spieler zu welcher Mannschaft gehört? Konfigurationsdatei wie oben?

10.  Abfrage 2 – Ballbesitz. Was genau ist mit Ballnähe gemeint? Dass der Abstand zwischen Ball und Spieler 1 m oder weniger beträgt.

11.  Abfrage 2 – Ballbesitz. Woran lässt sich erkennen, dass ein Spieler den Ball tritt? An der vom Ballsensor übertragenen Beschleunigungsspitze.

12.  Wie lässt sich eine Spielunterbrechung (Foul, Abseits usw.) erkennen? Hierfür könnten wir Schiedsrichter-Ereignisse manuell in den Datenfluss einpflegen. Wäre das OK? Vielleicht ein Ereignis wie „Pfiff“.

13.  Abfrage 2 – Ballbesitz. Warum ist die Information „Ballnähe“ notwendig? Wir nutzen diese Unterabfrage zur Erkennung der Spieler, die sich in unmittelbarer Nähe zum Ball befinden. Das brauchen wir dann zum Zeitpunkt einer Beschleunigungsspitze nicht nachzuholen. Ich meine aber, wir sollten diese „Einschränkung“ aufheben. Wir praktizieren das so, aber ist es wirklich effizient? Vielleicht finden wir da noch etwas Besseres.

Der laufende Status lautet auf das Datum 7.11.2012 und die Uhrzeit 17:00 Uhr für den Beginn des Testspiels.