DAGE-MTI | XLMC | Eine interaktive Schnittstelle zur Steuerung von fuballspielenden

Bachelorarbeit am Institut f¨
ur Informatik der Freien Universit¨at Berlin,
Arbeitsgruppe K¨
unstliche Inteligenz
Eine natu¨rliche Interaktionsschnittstelle zur
Steuerung von humanoiden fußballspielenden
Robotern
Lutz Freitag
Matrikelnummer: 4226598
lutz.freitag@fu-berlin.de
Betreuer:
Prof. Ra´
ul Rojas,
Dipl. Daniel Seifert,
Dipl. Hamid Reza Mobalegh
Berlin, July 17, 2011
Lutz Freitag
Abstract
Natural interfaces are designated to easily generate inputs which
are significantly harder to realize using classic input devices such as
mice or keyboards. In this bachelor’s thesis a natural interface will be
developed based on the Microsoft Kinect sensor for the soccer playing
robots of the Freie Universit¨at Berlin. The robots will imitate as
accurate as possible the poses and movements of a user. Motions like
standing up will be implemented by tracking the gestures of the user.
The interface is designed to be intuitively understandable.
Zusammenfassung
Mit nat¨
urlichen Schnittstellen lassen sich Eingaben f¨
ur Programme
realisieren, die mit klassischen Eingabeger¨aten wie M¨ausen oder Tastaturen nicht oder nur sehr schwer umsetzbar sind. In dieser Arbeit wird eine solche Schnittstelle f¨
ur die fußballspielenden Roboter
der Freien Universit¨
at Berlin mit einem Microsoft Kinect-Sensor als
Grundlage entwickelt. Die Bewegungen und Posen eines Nutzers sollen
dabei so genau wie m¨
oglich von den Robotern nachempfunden werden,
um diese dadurch zu steuern. Teile der Robotersteuerung wie das Aufstehen sollen auch durch Gestenerkennung am Nutzer umgesetzt werden. Bei der Umsetzung wurde darauf geachtet, dass die Schnittstelle
intuitiv und leicht verst¨
andlich gehalten wird.
b
Eidesstattliche Erkl¨
arung
Ich versichere hiermit an Eides Statt, dass diese Arbeit von niemand anderem als meiner Person verfasst worden ist. Alle verwendeten Hilfsmittel wie
Berichte, B¨
ucher, Internetseiten oder ¨ahnliches sind im Literaturverzeichnis
angegeben, Zitate aus fremden Arbeiten sind als solche kenntlich gemacht.
Die Arbeit wurde bisher in gleicher oder ahnlicher Form keiner anderen Pr¨
ufungskommission vorgelegt und auch nicht ver¨offentlicht.
17. Juli 2011
Lutz Freitag
Inhaltsverzeichnis
1 Einleitung
1.1 Die FUmanoids . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Nat¨
urliche Schnittstellen . . . . . . . . . . . . . . . . . . . . .
1.3 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . .
1
1
2
3
2 Verwandte Arbeiten
4
3 Hard- und Software der Roboter
3.1 Besonderheiten . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Antrieb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
5
5
4 Grundlagen
4.1 Tiefensensor . . . . . .
4.2 Kinect . . . . . . . . .
4.2.1 Technik . . . .
4.3 OpenNI . . . . . . . .
4.3.1 Architektur und
4.3.2 NITE . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
10
10
16
17
18
5 Steuerung durch Posen
5.1 Winkel statt Positionen . . . . . . . . . . . . . . . .
5.2 Berechnung der Winkel der verschiedenen Gelenke .
5.2.1 Mathematische Grundlagen . . . . . . . . .
5.2.2 Modellierung . . . . . . . . . . . . . . . . .
5.3 Probleme durch unterschiedliche K¨orpergeometrien
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
19
19
21
22
24
32
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
Datenfluss
. . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6 Steuerung durch Gesten
32
6.1 Funktionsweise . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.2 Aufstehgeste . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.3 Schussgeste . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7 Laufsteuerung
36
8 Fazit
37
9 Ausblick
38
Abbildungsverzeichnis
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
FUmaoind von 2011 . . . . . . . . . . . . . .
Anordnung der Servomotoren in den Robotern
Stereokameraaufbau . . . . . . . . . . . . . .
Stereo Halbbilder, Wilfried Wittkowsky 2004 .
Tiefenbildgenerierung mit strukturiertem Licht
Koordinatensystem des Kinect-Sensors . . . .
Kalibrierungspose (Psi-Pose) . . . . . . . . . .
Architektur des OpenNI Frameworks . . . . .
3D Darstellung der Basispose . . . . . . . . .
3D-Darstellung eines Nutzers . . . . . . . . .
Winkel an Scharniergelenken . . . . . . . . . .
Winkel an der Schulter . . . . . . . . . . . . .
Winkel Berechnung an den Beinen . . . . . . .
Zustandsdiagramm Aufstehgeste . . . . . . . .
Zustandsdiagramm der Schussbewegung . . .
Visualisierung der Laufsteuerung . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
6
9
10
12
13
15
18
21
25
26
28
30
34
35
37
1 Einleitung
1
Lutz Freitag
Einleitung
Humanoide Roboter, die sich menschen¨ahnlich verhalten, stellen eine große
Herausforderung dar. Die Proportionen und Form der Roboter sind zwar
humanoid, jedoch sind es die Bewegungen oft nicht. Die FUmanoids, die
fußballspielenden Roboter der Freien Universit¨at Berlin, sollen sich ¨ahnlich
zu Menschen bewegen und sich dabei m¨oglichst stabil verhalten. Daf¨
ur werden Bewegungen auf den Robotern ausgef¨
uhrt, die menschlichen Bewegungen
nachempfunden sind.
In dieser Arbeit wird eine nat¨
urliche Schnittstelle zur Steuerung der Roboter entwickelt, mit der die Roboter direkt von Menschen gesteuert werden
k¨onnen. Dabei werden m¨ogliche Techniken beschrieben, die f¨
ur eine solche
Schnittstelle n¨otig sind, Probleme bei der Umsetzung erl¨autert und L¨osungen ausgearbeitet.
1.1
Die FUmanoids
Die Freie Universit¨at Berlin nimmt mit den FUmanoids seit 2007 in der KidSize Liga des RoboCups teil. Dies ist ein Wettkampf, bei dem internationale
Bildungseinrichtungen im Roboterfußball gegeneinander antreten. Die Motivation hinter dem 1995 gegr¨
undeten Wettkampf ist es, im Jahr 2050 den
amtierenden Fußballweltmeister mit einer autonomen Robotermannschaft zu
besiegen. Bis dahin ist es allerdings noch ein langer Weg. Der derzeitige Stand
der Roboterforschung l¨asst zwar großes Potential erkennen, was zuk¨
unftige
Entwicklungen angeht, jedoch sind viele Bereiche der Robotik lange noch
nicht ausgereift. [18] [10]
1
1.2 Nat¨
urliche Schnittstellen
Lutz Freitag
Abbildung 1: FUmaoind von 2011
In der KidSize Liga des RoboCups treten humanoide Roboter, das heißt
Roboter mit zwei Armen, zwei Beinen, einem Torso und einem Kopf gegeneinander an. Die Roboter m¨
ussen dabei so gebaut sein, dass die Proportionen denen
eines kleinen Kindes ¨ahneln und sie d¨
urfen nicht gr¨oßer als 60cm sein.
Die FUmanoids nehmen regelm¨aßig am RoboCup teil und haben dabei beachtliche
Erfolge erreicht. In den Jahren 2008 und 2009 wurden sie Vize-Weltmeister.
[18]
1.2
Natu
¨ rliche Schnittstellen
Im klassischen Sinn werden Computer durch spezielle Hardware bedient, die
die Eingabefunktionalit¨at u
¨bernehmen. Mit einer Tastatur k¨onnen besonders
schnell verschiedene Eingaben aus einem Alphabet erzeugt werden, wohingegen sich M¨ause eignen, um Eingaben zu erzeugen, die zu einem Ort geh¨oren.
Das Schreiben von Texten w¨are ohne Tastatur fast nicht m¨oglich und das
2
1.3 Aufgabenstellung
Lutz Freitag
Bearbeiten von Bildern nicht ohne Maus. Beide Eingabeger¨ate haben ihre
St¨arken und Schw¨achen. In einigen Bereichen der Computernutzung haben
sich Eingabeger¨ate etabliert, die f¨
ur spezielle Anwendungen optimiert sind.
F¨
ur Bildbearbeitungsprogramme eignen sich Grafiktabletts. Sie stellen einen
Mausersatz dar, der in Form eines Stiftes und einer Unterlage realisiert wird.
Die relative Position der Stiftspitze auf dem Tablett wird vom Computer
in eine Mausposition umgesetzt und wenn der Druck des Stiftes auf der
Oberfl¨ache einen gewissen Schwellwert u
¨berschreitet, so wird das als Klick
interpretiert.
Durch die Verbreitung von Touchscreens, wurden neue Eingabekonzepte m¨oglich.
Das Touchdisplay dient dabei sowohl als Tastatur als auch als Mausersatz.
Die ber¨
uhrungsempfindliche Oberfl¨ache gibt den Entwicklern und Designern
von Benutzeroberfl¨achen viele neue M¨oglichkeiten der Umsetzung von intuitiven Bedienkonzepten. [9]
Nat¨
urliche Schnittstellen stellen ein erweitertes Bedienkonzept dar. Eingaben
k¨onnen in Form von Gesten oder Bewegungen get¨atigt werden. Dabei gehen
sie so weit, dass sie fast g¨anzlich ohne klassische Computerhardware auskommen. Der Nutzer kann ohne technische Hilfsmittel mit dem Computer interagieren. Er kann auf Elemente auf dem Bildschirm zeigen, sodass diese
ausgew¨ahlt werden oder eine Greifbewegung machen, um Fenster zu ziehen.
Die Bedienm¨oglichkeiten durch nat¨
urliche Schnittstellen sind dabei ¨außerst
vielf¨altig. Grunds¨atzlich gilt aber, dass der Nutzer keine Hardware ”in die
Hand” nehmen muss, um den Computer zu bedienen. Es muss allerdings
Hardware vorhanden sein, die den Nutzer und seine Eingaben registriert.
Hierf¨
ur eignen sich Kameras oder Mikrofone.
1.3
Aufgabenstellung
Ziel dieser Arbeit ist es, eine nat¨
urliche Schnittstelle, also eine Schnittstelle,
mit der man nicht direkt mit der Harware eines Computers interagiert, zu entwickeln, mit der die fußballspielenden Roboter der FU gesteuert werden k¨onnen. Sie sollen sowohl direkt die Bewegungen des Nutzers umsetzen als auch
durch Gesten gesteuert werden k¨onnen. Dabei soll der Nutzer die gleichen
Steuerungsm¨oglichkeiten haben wie die Roboter, wenn sie im autonomen Betrieb sind. Die Erzeugung der Steuerungsdaten soll auf einem dedizierten
Computer geschehen und u
¨ber WLAN an die Roboter u
¨bertragen werden.
3
2 Verwandte Arbeiten
2
Lutz Freitag
Verwandte Arbeiten
Nach der Ver¨offentlichung der ersten offenen Treiber f¨
ur den Microsoft KinectSensor, entwickelte sich schnell eine große Gemeinschaft von Entwicklern,
durch die viele interessante Projekte im Bereich nat¨
urlicher Schnittstellen
entwickelt wurden. [7]
Einige Beispiele sollen hier genannt werden:
• Nao OpenNI
Das Nao OpenNI Projekt stellt dem Nutzer eine zu dieser Arbeit ¨ahnliche nat¨
urliche Schnittstelle zur Verf¨
ugung, um einen Roboter zu kontrollieren. Der Nutzer kann zwischen verschiedenen Modi w¨ahlen, um
einen Nao-Roboter fernzusteuern. Man kann die Arme des Roboters
direkt steuern, indem der Roboter die Armposen direkt umsetzt, das
Laufen des Roboter, indem man im Laufmodus den eigenen K¨orpermittelpunkt relativ zu einem Nullpunkt bewegt oder auf einen Punkt
zeigt, zu dem der Roboter gehen soll. F¨
ur letzteres muss der Roboter
im Koordinatensystem der Kinect lokalisiert sein, also auch von der
Kinect erfasst werden. Das Umschalten der verschiedenen Modi erfolgt
durch spezielle Gesten mit den Armen.
• FAAST
Das am kalifornischen Institute for Creative Technologies entwickelte
Framework FAAST (Flexible Action and Articulated Skeleton Toolkit) stellt eine Umgebung bereit, mit der ein Nutzer durch bestimmte
Bewegungen oder Haltungen Eingaben am Computer generieren kann.
Das Framework kann dabei zwischen 26 verschiedenen Aktionen unterscheiden, die dann als Eingaben am Computer umgesetzt werden. Man
kann beispielsweise die Cursorsteuerung dadurch realisieren, dass sich
der Nutzer nach vorne bzw. hinten, rechts bzw. links neigt. [7]
• KinEmote
KinEmote ist eine Steuerung f¨
ur die Mediencentersoftware XBMC. Mit
ihr kann ein Nutzer durch seine Medienbibliothek navigieren und Elemente Abspielen. KinEmote wird ausschließlich durch die Arme gesteuert. Bei der Eingabe wird zwischen drei Ebenen unterschieden. In der
hinteren Ebene kann der Nutzer zum Hauptmen¨
u zur¨
uckkehren und
die Abspielfunktionen steuern, in der mittleren Ebene kann durch die
Men¨
us navigiert werden und in der vorderen kann der Nutzer seine
Auswahl best¨atigen. [7]
4
3 Hard- und Software der Roboter
3
Lutz Freitag
Hard- und Software der Roboter
Humanoide Roboter brauchen zur Bewegung viele Freiheitsgrade, die sie von
den Robotern der MidSize Liga deutlich unterscheiden. In der MidSize Liga
haben die Roboter R¨ader, mit denen sie sich schnell auf dem Spielfeld bewegen k¨onnen, ohne Gefahr zu laufen, dass sie umfallen.
Das humanoide Laufen, also das Laufen auf zwei Beinen, ist dagegen eine
große Herausforderung. Anstelle von maximal vier Antriebsr¨adern werden
bei den FUmanoids allein sieben Servomotoren pro Bein genutzt, um das
Laufen zu erm¨oglichen. Insgesamt sind sowohl in den Robotern von 2009 als
auch von 2011 der FUmanoids 21 Servomotoren verbaut. Dementsprechend
sind die Bewegungsfreiheiten gr¨oßer, aber der Aufwand der Stabilisierung
wird mit der Anzahl der Freiheitsgrade komplexer.
Die aktuell genutzten Roboter der FUmanoids wurden im Rahmen der Diplomarbeiten von Jan Streckenbach und Moritz Fr¨ohlich entworfen und im Juni
2011 fertiggestellt. Beim RoboCup 2011 in Istanbul haben die neuen Roboter
den vierten Platz erreicht.
Details der Roboter von 2011: [18]
H¨ohe
Gewicht
Servos
Prozessorboard
Kamera
Netwerk
Betriebssystem
3.1
60cm
ca. 4kg
21 (3 pro Arm, 7 pro Bein, 1 im Kopf)
IGEPv2 DM3739 (1GHz Cortex-A8 ARM)
Logitech Quickcam 9000 Pro (VGA)
LAN, WLAN
Linux
Besonderheiten
Als Optik wird bei den Robotern eine 179◦ Fischoptiklinse genutzt. Damit
sind die Roboter in der Lage einen Großteil des Spielfeldes zu sehen, ohne den
Kopf bewegen zu m¨
ussen. Dies ist insbesondere dann n¨
utzlich, wenn mehrere
Teile des Spielfeldes gleichzeitig beobachtet werden m¨
ussen. Positioniert sich
der Roboter gerade zu einem Torschuss, so kann er gleichzeitig seine F¨
uße,
den Ball und das gegnerische Tor visuell erfassen.
3.2
Antrieb
Die Servomotoren, die in den FUmanoids verbaut sind, stammen von der
Firma Robotis Inc. Sie zeichnen sich durch standardisierte Aufnahmen f¨
ur
5
3.2 Antrieb
Lutz Freitag
Achsen und Befestigungen aus und k¨onnen mit einem seriellen Protokoll
einzeln oder in Gruppen angesteuert und ausgelesen werden.
Die Servos unterst¨
utzen dabei folgende Grundfunktionen:
Beschreibung
Werte
Sollposition
0 .. 1023
Sollgeschwindigkeit 0 .. 1023
Torsionslimit
0 .. 1023
[16] [17]
Im Antriebsteil der Roboter befinden sich die st¨arkeren Servos (RX-64) und
im Oberk¨orper die schw¨acheren (RX-28).
RX-28
RX-64
maximales statisches Drehmoment 3, 7 Nm 7, 5 Nm
Gewicht
72 g
125 g
Getriebe
1 : 193
1 : 200
◦
erreichbare Positionen
300
300◦
Winkelaufl¨osung
0, 35◦
0, 35◦
maximale Winkelgeschwindigkeit
0, 6◦ /s
0, 5◦ /s
[16] [17]
HEAD_TURN 2
ARM_PITCH 3/4
ARM_ROLL 5/6
ELBOW 7/8
HIP_YAW 9/10
HIP_ROLL 11/12
HIP_PITCH 13/14
KNEE_TOP 15/16
KNEE_BOTTOM 17/18
FOOT_PITCH 19/20
FOOT_ROLL 21/22
RIGHT
LEFT
Abbildung 2: Anordnung der Servomotoren in den Robotern
6
4 Grundlagen
4
Lutz Freitag
Grundlagen
Im Folgenden werden Techniken zur Generierung von Tiefeninformationen
erl¨autert.
4.1
Tiefensensor
Sensoren, mit denen die r¨aumliche Entfernung von Objekten gemessen werden k¨onnen, gibt es in vielen Ausf¨
uhrungen. Grunds¨atzlich gibt es zwei
Klassen von denen einige Vertreter hier vorgestellt werden sollen:
• Aktive Tiefensensoren:
Sensoren, die zur Messung der r¨aumlichen Entfernung aktiv Messungen
durchf¨
uhren.
– Laser-Abstandssensor
Ein Laserstrahl wird auf das Objekt gestrahlt, dessen Entfernung
gemessen werden soll. Aus der Laufzeit des Lichtes l¨asst sich die
tLauf zeit
. Solche Sensoren
Entfernung bestimmen: d = 2vLichtgeschwindigkeit
sind vergleichsweise teuer und k¨onnen nur einen Punkt gleichzeitig messen. Sind jedoch auch bei verschiedenen Oberfl¨achen sehr
genau und haben Reichweiten bis zu u
¨ber 50 m. Im Aufbau als
beweglicher F¨acher lassen sich mit ihnen detaillierte Informationen u
¨ber die Umgebung erzeugen.[19]
– Infrarot-Abstandssensor
Eine LED, die infrarotes Licht (nicht notwendigerweise infrarot,
es hat sich aber als praktikabel etabliert) abstrahlt, beleuchtet das
Objekt, dessen Entfernung gemessen werden soll. Aus der vom Objekt reflektierten Lichtintensit¨at lassen sich R¨
uckschl¨
usse ziehen,
wie weit das Objekt entfernt ist. Solche Sensoren sind nicht teuer,
daf¨
ur messen sie nicht gezielt. Befinden sich mehrere Objekte im
Erfassungsbereich des Sensores, wird die Messung grunds¨atzlich
verf¨alscht. Außerdem entstehen auch durch unterschiedliche Materialoberfl¨achen oder -formen große Fehler. Ein kleines Objekt
wird weniger wahrscheinlich gemessen als ein großes. Oberfl¨achen,
die infrarotes Licht wenig reflektieren, sind damit fast nicht zu
7
4.1 Tiefensensor
Lutz Freitag
messen. Es gibt auch Ausf¨
uhrungen solcher Sensoren, die auf andere Wellenl¨angen des Lichtes zur¨
uckgreifen.
– Akustische Abstandssensoren
Mit Laufzeitmessungen von Schallwellen lassen sich vergleichsweise
gut Entfernungen messen. Solche Sensoren werden oft in Ger¨aten
genutzt, mit denen R¨aume vermessen werden. Akustische Abstandssensoren funktionieren, indem kurzzeitig ein hochfrequentes
Schallsignal erzeugt wird, das von einer Oberfl¨ache reflektiert wird
und wieder zum Messger¨at zur¨
uckkehrt. Aus der Laufzeit und der
tLauf zeit
Schallgeschwindigkeit der Luft l¨asst sich nach d = 2vSchallgeschwindigkeit
die Entfernung messen. Akustische Entfernungsmesser werden ungenauer, je schr¨ager die Oberfl¨ache ist, deren Entfernung gemessen
werden soll, da hier weniger Schall reflektiert wird, der als Hintergrundrauschen interpretiert werden kann. Weiterhin verf¨alschen
Luftfreuchtigkeit und Luftdruck das Ergebnis. Problematisch sind
auch nicht-diffuse Echos, die jeweils als Nutzecho interpretiert werden k¨onnen. Sind mehrere Objekte schr¨ag hintereinander, sodass
es eine sichtbare Linie zwischen dem Messger¨at und den Objekten
gibt, beispielsweise eine Reihe S¨aulen, so reflektiert jede der S¨aulen
das Signal des Messger¨ates. Je nach Bauart des Messger¨ates muss
dabei im Nachhinein eine Fehlerabsch¨atzung geschehen.
– Aktive Triangulation mit einer Kamera und strukturiertem Licht
Es wird strukturiertes Licht in die Szene projiziert, die wiederum
von einer Kamera abgefilmt wird. Aus dem Verlauf des strukturierten Lichtes lassen sich R¨
uckschl¨
usse auf die Oberfl¨achenform
ziehen. Da eine solche Technik in dieser Arbeit genutzt wurde, soll
sie nachfolgend n¨aher beschrieben werden.
• Passive Tiefensensoren:
– Stereokamera
Mit einem Aufbau von zwei Kameras, die die gleiche Szene beobachten lassen sich Informationen u
¨ber die r¨aumliche Beschaffenheit
eben dieser erzeugen. Ein solcher Aufbau ist in Abbildung 3 skizziert.
Inspiriert wurde diese Technik von der Natur, da auch die meisten
8
4.1 Tiefensensor
Lutz Freitag
Lebewesen zwei Augen besitzen. Durch einen entsprechend dimensionierten bildverarbeitenden Apperat ist es dabei m¨oglich, aus
den zwei aufgenommenen Halbbildern r¨aumliche Informationen
u
¨ber die Szene zu erhalten. Die eigentliche Schwierigkeit besteht
hierbei darin, Bildteile (Features) aus dem einen Bild im anderen
¨
Bild wiederzufinden, zu matchen. Uber
den Versatz der Features
in den Halbbildern und den Orientierungen der Sensoren lassen
sich die r¨aumliche Entfernungen berechnen. [4]
Abbildung 3: Stereokameraaufbau
F¨
ur eine akkurate Absch¨atzung der Entfernung eines Features
muss nicht nur die horizontale Verschiebung ber¨
ucksichtigt werden
sondern auch die Skalierung der Features in den Bildern. Befindet sich ein Feature n¨aher an einem Sensor, so ist es in dem Bild
entsprechend gr¨oßer. Gegen¨
uber Rotationen muss das Matching
nicht robust sein, wenn die Kameras nicht gegeneinander verdreht
und ihre Bildachsen parallel sind. Man ben¨otigt demnach einen
Algorithmus, der Features in den Bildern findet, die skalierungsinvariant beschrieben werden k¨onnen. [3]
9
4.2 Kinect
Lutz Freitag
Abbildung 4: Stereo Halbbilder, Wilfried Wittkowsky 2004
4.2
Kinect
Die Microsoft Kinect ist ein Sensor, der urspr¨
unglich ausschließlich f¨
ur die
X-Box 360 entwickelt wurde. Er integriert eine Farbkamera, 4 Mikrofone
und eine Tiefenkamera als Eingabesensoren. Die Tiefenkamera stellt dabei
f¨
ur die Entwicklung von nat¨
urlichen Schnittstellen die wichtigste Eigenschaft
dar.[15]
Im Gegensatz zur Generierung von Eingaben, die auf Bildverarbeitung beruhen,
beispielsweise durch eine Farbkamera, ist es durch die Nutzung von Tiefenkameras einfacher, R¨
uckschl¨
usse u
¨ber einen Nutzer zu ziehen und diesen zu
erkennen.[5]
Bei der Nutzung des Sensors muss gew¨ahrleistet werden, dass der Sensor sich
nicht im Raum bewegt. Ist dies nicht der Fall, so kann die Software, die das
Tiefenbild auswertet, keine sinnvollen Ergebnisse erzielen.
4.2.1
Technik
Die Tiefenkamera der Kinect arbeitet mit strukturiertem infrarotem Licht,
das seitlich vom Sensor ausgestrahlt wird. Das auf der Umgebung reflektierte
Muster, wird dabei von einer monochromen Kamera aufgenommen. In der
Kinect wird mit dem Light Coding Algorithmus das reflektierte Muster in ein
Tiefenbild umgerechnet. Da das LightCoding Verfahren propriet¨ar ist, kann
keine Erkl¨arung zum genauen Verfahren gemacht werden.[15]
Features:
• Farbkamera
10
4.2 Kinect
Lutz Freitag
Aufl¨osung
640 x 480 (VGA)
Farbtiefe
8 Bit (Beyer)
¨
Offnungswinkel
58◦ horizontal
45◦ vertikal
70◦ diagonal
• Tiefenkamera
Aufl¨osung
Pixeltiefe
640 x 480 (VGA)
11 Bit (16 Bit, davon werden 5 nicht genutzt)
Der Wert eines Tiefenpixels beschreibt
die Entfernung zur x-y-Ebene des Sensors
¨
Offnungswinkel
58◦ horizontal
45◦ vertikal
70◦ diagonal
[15]
(a) Infrarotbild [1]
(b) Tiefenbild [2]
11
4.2 Kinect
Lutz Freitag
Abbildung 5: Tiefenbildgenerierung mit strukturiertem Licht
In Abbildung 5 wird beschrieben, wie Tiefeninformationen aus strukturiertem Licht gewonnen werden k¨onnen. Das Muster, das vom Projektor rechts
im Bild abgestrahlt wird, wird vom Objekt reflektiert. Durch die Verzerrung der Reflektion lassen sich R¨
uckschl¨
usse auf die Orientierung des Objektes bzw. seiner Oberfl¨ache gewinnen. Ist das strukturierte Licht außerhalb der Bildebene der Kamera geb¨
undelt, kann außerdem durch die Abst¨ande benachbarter Elemente des Musters auf die Entfernung des Objektes
geschlossen werden. Ist ein Objekt n¨aher, so werden die Abst¨ande zwischen
den Elementen im Bild gr¨oßer. [4]
12
4.2 Kinect
Lutz Freitag
Abbildung 6: Koordinatensystem des Kinect-Sensors
Bei der Nutzung der Kinect muss beachtet werden, dass es mehrere Koordinatensysteme gibt. Einerseits steht in jedem Tiefenpixel die Entfernung
des dazugeh¨origen Raumpunktes zu der Bildebene des Sensors, andererseits
lassen sich auch alle Tiefenpixel mit den Bildkoordinaten in eine Punktwolke
transformieren, in denen alle Koordinaten absolut sind. Der Ursprung des
Koordinatensystem liegt dabei im Mittelpunkt des Sensors, siehe Abbildung
6 [15].
Durch die Nutzung eines Tiefensensors lassen sich viele Probleme weniger
aufw¨andig l¨osen als bei der Nutzung von Farbkameras. Grunds¨atzlich ist es
einfacher Objekte, bewegliche und feste, im Vordergrund vom Hintergrund zu
trennen. Mit Tiefenkameras k¨onnen Objekte auch direkt vermessen werden,
ohne einen komplizierten Messaufbau herstellen zu m¨
ussen. Selbst wenn die
Entfernung eines Objektes zur Kamera bekannt ist, ist die Berechnung der
Geometrie des Objektes nur unter Annahmen machbar, die genaue Kenntnisse weiterer Objekteigenschaften voraussetzen. [3]
Im Folgenden werden exemplarische Verfahren vorgestellt, mit denen aus
Tiefenbildern Informationen gewonnen werden k¨onnen, die speziell f¨
ur die
Nutzung als nat¨
urliche Schnittstelle von Vorteil sind.
• Nutzererkennung
Nutzer sind bewegliche Elemente in Tiefenbildern. Sie k¨onnen analog
zur Detektion von beweglichen Objekten in Farbbildern durch lokale
13
4.2 Kinect
Lutz Freitag
Ver¨anderungen erkannt werden. Im Gegensatz zur Erkennung von Menschen in Bildern hat man jedoch durch den Einsatz einer Tiefenkamera
genaue M¨oglichkeiten, die sich bewegende Punktmenge zu vermessen
und deren Lokalisierung im Raum festzustellen. Eine geeignete M¨oglichkeit w¨are, dass die Tiefenbilder u
¨ber ein Zeitfenster gemittelt werden,
um rauschen zu unterdr¨
ucken (Median-Mittelung). Die Hypothesen f¨
ur
einen Nutzer erh¨alt man, indem man das aktuelle Frame mit den gemittelten Frames vergleicht. In einem Bereich, in dem der Unterschied
besonders groß ist, kann sich ein Nutzer befinden [5]. Anschließend
wird jede Hypothese vermessen und wenn sie innerhalb gewisser Dimensionen liegt, wurde wahrscheinlich ein Mensch gefunden. Weitere
zus¨atzliche Tests, wie der Position der Hypothese zu ihrer Umgebung
(Abstand zum Hintergrund, Orientierung zum Boden), erm¨oglichen die
Unterdr¨
uckung weiterer falscher Vermutungen. Durch dieses Verfahren
erh¨alt man eine Maske, die so groß ist wie das Tiefenbild, wo in jedem
Pixel die ID des zugeh¨origen Nutzers steht.
• Skelettierung
Der Begriff Skelettierung wird hier f¨
ur die Erkennung von Gliedmaßen
genutzt. Es werden nicht die einzelnen Knochen erkannt, sondern K¨orperteile, die durch Gelenke miteinander verbunden sind. Wie z.B. Unterund Oberarme.
Um einen Nutzer und sein Skelett zu erkennen und zu tracken, muss
der Nutzer kalibiert werden. Der Nutzer muss eine spezielle Pose einnehmen, bei der die Vermessung des Skelettes so eindeutig wie m¨oglich
umsetzbar ist. Dabei hat sich die sogenannte Psi-Pose (siehe Abbildung
7) etabliert.
Die Skelettierung versucht nun ein Skelett in die Maske des Nutzer
einzupassen. Hier kann von der Pose profitiert werden. Die drei h¨ochsten Teile der Nutzermaske sind der linke Unterarm, der Kopf und der
rechte Unterarm. Die Unterarme k¨onnen vermessen werden, indem man
sich an ihrem ¨außeren Rand so lange nach unten bewegt, bis der Punkt
erreicht wurde, an dem man sich nur noch ann¨ahernd horizontal bewegen kann. Von diesem Punkt, bis zum obersten Punkt des Unterarmes
verl¨auft der Unterarm im Skelett. Der Torso wird dadruch erkannt,
dass er die gr¨oßte zusammenh¨angende Punktmasse in der Maske ist.
Die linke und rechte Begrenzung kann durch den ersten bzw. letzten
Tiefenpixel ermittelt werden, der unterhalb des unteren Endes des n¨achsten Armes noch zum Nutzer geh¨ort. Auf diese Art k¨onnnen auch die
Orte der Schultern erkannt werden. Die H¨ohe des Torsos kann analog
14
4.2 Kinect
Lutz Freitag
Abbildung 7: Kalibrierungspose (Psi-Pose)
durch den ersten Pixel der Nutzermaske ermittelt werden, der rechts
oder links neben dem Kopf unterhalb desselben ist. Eine Alternative
ist, dass der Torso genau so hoch ist, wie die Oberarme. Der Kopf wird
dadurch erkannt, dass er der h¨ochste Teil der Nutzermaske zwischen
den Unterarmen ist. Die Verbindung zwischen Kopf und Torso wird
durch den h¨ochsten Punkt des Kopfes und dem Punkt zwischen den
Oberarmen realisiert. Die untere Begrenzung des Torsos ist der h¨ochste Punkt der Nutzermaske, der zwischen den Beinen ist, also der, wo
die Nutzermaske eine L¨
ucke aufweist. In der Kalibrierungspose sind die
Beine gestreckt, was die Skelettierung erschwert, da man keine genauen
Informationen u
ur eignet
¨ber die Position der Knie erlangen kann. Hierf¨
es sich, anzunehmen, dass sich das Knie auf der halben Strecke zwischen
Torsoende und F¨
ußen befindet. Bewegt der Nutzer seine Beine, kann
die relative Position der Knie nachtr¨aglich justiert werden, indem f¨
ur
die Ober- und Unterschenkel lineare Funktionen angenommen werden,
die sich in den Knien schneiden.
15
4.3 OpenNI
4.3
Lutz Freitag
OpenNI
Im Zuge der Entwicklung und stetig wachsenden Popularit¨at des KinectSensors, gr¨
undete sich im November 2010 die Non-Profit-Organisation Natural Interaction, die sich derzeit aus PrimeSense, Willow Garage, Side Kick
und Asus zusammensetzt. Die Organisation hat sich mit dem Ziel gegr¨
undet ein einheitliches Framework zu schaffen, welches die Datenverarbeitung
von diversen Sensoren und durch vielf¨altige Datenaufbereitungsmodule vereinfacht [11].
OpenNI stellt ein Framework zur Verf¨
ugung, mit der ein Entwickler Funktionen bereitgestellt bekommt, mit denen sich nat¨
urliche Schnittstellen einfach realisieren lassen. Das Framework abstrahiert von den konkreten Sensoren weg, indem es Schnittstellen anbietet, mit denen sogenannte Production Nodes bedient werden k¨onnen. Production Nodes implementieren verarbeitende Funktionalit¨aten, beispielsweise einen Menschendetektor in Tiefenbildern. Aufbauend auf einem oder mehrerer Production Nodes k¨onnen wiederum andere Production Nodes ihre Datenverarbeitung ausf¨
uhren. Die Kommunikation und der Datenfluss werden dabei vom OpenNI Framework reguliert. [11]
Die Anwendung, die sich der dabei erzeugten Daten bedient, muss zu Beginn
ihrer Ausf¨
uhrung den Verarbeitungsgraphen erzeugen und in das Framework
registrieren oder sie bedient sich einer bereits fest definierten Konfiguration.
Daf¨
ur verwaltet das Framework eine Datenbank, in der global verf¨
ugbare
Production Nodes hinterlegt sind. Feste Konfigurationen lassen sich mittels XML-Dateien festlegen, deren Pfade bei der Initialisierung des OpenNI
Frameworks diesem u
¨bergeben werden k¨onnen. In den XML-Dateien muss
definiert sein, welche Production Nodes in der Anwendung genutzt werden
und wie diese konfiguriert werden sollen. Um das oben genannte Beispiel
zu erweitern, kann ein Menschendetektor, der auf Tiefenbildern aufbaut,
seine Eingabedaten gespiegelt erhalten. Die Implementierung der Konfigurierbarkeit ist dabei Aufgabe der Production Nodes. [11]
Eine Beispielkonfiguration sieht so aus:
16
4.3 OpenNI
Lutz Freitag
1 <OpenNI>
2
<L i c e n s e s>
3
<L i c e n s e v e n d o r=”P r i m e S e n s e ” key=”0KOIk2JeIBYClPWVnMoRKn5cdY4=”/>
4
</ L i c e n s e s>
5
<Log w r i t e T o C o n s o l e=” t r u e ” w r i t e T o F i l e=” f a l s e ”>
6
<L o g L e v e l v a l u e=”3 ”/>
7
<Masks>
8
<Mask name=”ALL” on=” t r u e ”/>
9
</ Masks>
10
<Dumps>
11
</Dumps>
12
</ Log>
13
<P r o d u c t i o n N o d e s>
14
<Node t y p e=”Image ”>
15
<C o n f i g u r a t i o n>
16
<MapOutputMode xRes=”640 ” yRes=”480 ” FPS=”30 ”/>
17
<M i r r o r on=” t r u e ”/>
18
</ C o n f i g u r a t i o n>
19
</Node>
20
<Node t y p e=”Depth ”>
21
<C o n f i g u r a t i o n>
22
<MapOutputMode xRes=”640 ” yRes=”480 ” FPS=”30 ”/>
23
<M i r r o r on=” t r u e ”/>
24
</ C o n f i g u r a t i o n>
25
</Node>
26
<Node t y p e=”User ” />
27
<Node t y p e=”S c e n e ” />
28
29
</ P r o d u c t i o n N o d e s>
30 </OpenNI>
Der Wurzelknoten muss der OpenNI-Knoten sein. Darunter kommen die globalen Konfigurationen, wie das Loggen, eventuell ben¨otigte Lizenzen f¨
ur die
Sensoren, im Beispiel wird der Kinect-Sensor genutzt, f¨
ur den ein Schl¨
ussel ben¨otigt wird und die Production Nodes. In diesem Beispiel werden vier
Production Nodes angefordert: Farbbild (Image), Tiefenbild (Depth), Menschenerkennung (User) und Umgebung (Scene). In der Konfiguration muss
nicht notwendigerweise darauf geachtet werden, wo die einzelnen Production Nodes ihre Daten herbeziehen. W¨ahrend der Initialisierung der Knoten
m¨
ussen diese beim Framework geeignete Eingabedatenquellen anfordern und
entsprechend reagieren, wenn keine oder mehrere verf¨
ugbar sind. Kann kein
Datenfluss zustande kommen, da ein Knoten keine Eingabedaten erlangen
kann, so schl¨agt die Initialisierung des Frameworks fehl.
OpenNI wird unter der GPL und der LGPL ver¨offentlicht.
4.3.1
Architektur und Datenfluss
Zweck des OpenNI Frameworks ist es, von den eigentlichen Sensoren zu abstrahieren und Schnittstellen zu bieten, mit denen Erkenntnisse aus den jeweiligen Sensoren und Kombinationen gewonnen werden k¨onnen. Dabei wird
eine strikte Trennung von verarbeitenden und nutzenden Programmteilen
angestrebt. Programmteile, die Daten aufbereiten, geh¨oren in die Middleware, also in die Production Nodes. Programmteile, die nur Daten konsumieren, die von Production Nodes erzeugt wurden, sollten sich in der Endanwendung befinden, also in der obersten Schicht. In der Abbildung 8 wird dies
17
4.3 OpenNI
Lutz Freitag
erl¨autert.
Abbildung 8: Architektur des OpenNI Frameworks [11]
Vorteilhaft an einer solchen Architektur ist, dass Production Nodes hochgradig wiederverwendbar sind und Verarbeitungsketten leicht erweitert oder
angepasst weden k¨onnen. Durch die Unterteilung der Verarbeitung in einzelne
Module lassen sich diese gut organisiert parametrisieren. Die Kommunikation
der durch die Production Nodes gewonnenen Daten geschieht ausschließlich
u
¨ber das Framework. Dadurch wird gew¨ahrleistet, dass jedes Modul, das bestimmte Typen von Daten erfordert, diese auch bekommt. Sind beispielsweise
zwei Module auf eine Datenquelle registriert, bekommen beide bei Vorhandensein der Daten, also beim erfolgreichen Erzeugen dieser durch einen weiteren Production Node, diese nacheinander. Auf die Reihenfolge der Datenvermittlung hat man dabei keinen Einfluss. Daraus ergibt sich, dass Systeme
auch schwingen k¨onnen. Allerdings sollte beachtet werden, dass zwei Production Nodes, die einen gemeinsamen Eltern-Production Node haben, sich
gegenseitig keine Informationen senden d¨
urfen. Es darf also keinen Kreis in
dem gerichteten Signalverarbeitungsgraphen geben [11].
4.3.2
NITE
Im Zuge der Entwicklung des OpenNI Frameworks hat PrimeSense einen Satz
von Production Nodes bereitgestellt, der auf die Verwendung eines Tiefensensors (speziel der Kinect-Sensor) abzielt. In der NITE-Middleware sind Module enthalten, die die Nutzererkennung, die Skelettierung und die Gestenerkennung realisieren [14]. F¨
ur die meisten Programme, die die Funktionen
des Kinect-Sensors nutzen, ist die NITE-Middleware ausreichend, um darauf
basierend eigene Funktionen zu realisieren [7]. Im praktischen Teil dieser Arbeit wurde auch dieses Framework genutzt.
18
5 Steuerung durch Posen
5
Lutz Freitag
Steuerung durch Posen
Ein Ziel dieser Arbeit ist es die Bewegungen von fußballspielenden Robotern
direkt zu steuern. Die Roboter sollen also die Posen des Nutzers so akkurat
wie m¨oglich einnehmen. Auf die dabei entstehenden Schwierigkeiten, soll im
Folgenden n¨aher eingegangen werden.
5.1
Winkel statt Positionen
Die NITE-Middleware stellt Mittel zur Verf¨
ugung, mit denen die r¨aumlichen
Positionen einzelner K¨orperteile berechnet werden k¨onnen. Diese Punkte
¨
befinden sich in einem euklidischen Raum. Eine Schwierigkeit der Ubertragung der Pose eines Nutzers besteht darin, die Orientierung des Nutzers so
umzusetzen, dass die Roboter diese einnehmen k¨onnen. Es wird also eine
Funktion gesucht, die einen Vektor, der die Pose des Nutzers beschreibt, so
umsetzt, dass sich die zugeh¨orige Abbildung, so weit wie m¨oglich, mit dem
Raum der Vektoren, der Posen, die die Roboter einnehmen k¨onnen, u
¨berschneidet. Eine komplette Abdeckung beider R¨aume ist nicht m¨oglich, da
den Robotern daf¨
ur notwendige Freiheitsgrade fehlen. W¨ahrend Menschen
an vielen Gelenken drei Freiheitsgrade (nicken, rollen, gieren) haben, haben
die Roboter dort zwei oder nur einen.
Zur L¨osung dieses Problems gibt es drei Ans¨atze:
• Positionsbasiert
Die Orte der Gelenke werden durch eine Funktion, die die Ortsvektoren der einzelnen Gelenke in einen Raum umsetzt, der entsprechend
der Robotergeometrie skaliert ist, umgesetzt und auf die Roboter u
¨bertragen.
Problematisch an dieser Methode ist, dass die Roboter f¨
ur jedes Gelenk einer kinematischen Kette, beispielsweise ein Arm, die Orte jedes
Kindgelenkes in das Koordinatensystem des aktuellen Gelenkes umsetzen muss, damit Geometrieunterschiede zwischen dem Nutzer und den
Robotern kompensiert werden k¨onnen. Außerdem entsteht bei dieser
Methode ein großer Rechenaufwand, da die Funktion, die die Punkte in das Roboterkoordinatensystem umsetzt f¨
ur jeden Nutzer einzeln
berechnet werden muss und nicht robust gegen¨
uber Rauschen in der
Skelettierung ist.
• Inverse Kinematik
Es werden die Endeffektoren der Gliedmaßen, also die H¨ande und F¨
uße
19
5.1 Winkel statt Positionen
Lutz Freitag
des Nutzers, zu den Robotern u
¨bertragen und dort mit einer inversen
Kinematik in Posen umgesetzt. Die Endeffektoren m¨
ussen dabei wie
bei der positionsbasierten Methode in ein Koordinatensystem umgesetzt werden, das die Robotergeometrie ber¨
ucksichtigt. Die Roboter
setzen eine Umkehroperation der Denavit-Hartenberg-Transformation
ein, bei der der L¨osungsraum sinnvoll eingeschr¨ankt werden muss [13].
Auf den Robotern der FUmanoids passiert dies, indem die Gierachse in
der Transformation weggelassen wird und die Winkel an den einzelnen
Gelenken eingeschr¨ankt werden. Damit existiert f¨
ur jeden Endeffektor
keine oder genau eine L¨osung.
Die Probleme bei dieser Methode sind analog zur positionsbasierten
Methode, jedoch entf¨allt die Schwierigkeit der Geometrieunterschiede
f¨
ur Teile einer kinematischen Kette. Bei der Nutzung einer inversen
Kinematik kann es vorkommen, dass die Posen des Nutzers nicht wie
gew¨
unscht von den Robotern eingenommen werden, da die inverse Kinematik keine optimal nahe L¨osung ergibt, die mit der Pose des Nutzers
u
¨bereinstimmt. Winkt der Nutzer beispielsweise so, dass sein Oberarm senkrecht vom Oberk¨orper gestreckt ist und der Unterarm um
den rechten Winkel nach oben schwingt, k¨onnte eine inverse Kinematik
diese Bewegung so aufl¨osen, dass sich auch der Oberarm bewegt. Dieses
Verhalten ist jedoch nicht erw¨
unscht.
• Winkelbasiert
Jedes Gelenk, das sowohl am Nutzer als auch am Roboter vorhanden ist, wird in Einzelgelenke aufgel¨ost. Damit wird das Nutzermodell an das Robotermodell angen¨ahert. F¨
ur diese Einzelgelenke werden
Winkel zwischen der aktuellen Konfiguration und einer Basiskonfiguration berechnet. Es gibt ein Modell der Basiskonfiguration f¨
ur die Roboter, sodass diese die Winkel entsprechend umsetzen k¨onnen. Schließlich
nehmen sie eine Pose ein, die der des Nutzers ¨ahnelt.
Nachteile entstehen bei dieser Methode durch Rauschen der Skelettierung, das sich in kinematischen Ketten fortpflanzt. Kann beispielsweise die Position eines Knies nicht genau erfasst werden, so rauschen
die Winkel am dazugeh¨origen H¨
uftgelenk u
¨berm¨aßig stark, womit die
Positionen der F¨
uße der Roboter noch st¨arker rauschen. Vorteilhaft ist
dagegen, dass die Winkel auf dem Roboter sehr einfach umsetzbar sind,
da die Servomotoren u
¨ber ihre Sollwinkel angesprochen werden k¨onnen.
Allen Methoden ist gemein, dass es gewisse Posen gibt, die nicht eindeutig
bestimmbar oder nicht erreichbar sind. Streckt der Nutzer beispielsweise die
Arme waagerecht aus (Abbildung 9), so gibt es f¨
ur die Winkelberechnung
20
5.2 Berechnung der Winkel der verschiedenen Gelenke
Lutz Freitag
Abbildung 9: 3D Darstellung der Basispose mit den Normalenvektoren auf
den Gelenken (rechts gr¨
un, links rot)
unendlich viele L¨osungen im Nickgelenk des Roboters. Sind die Unterarme
und die Oberarme nicht in der Ebene des Oberk¨orpers, k¨onnen die Roboter
diese Pose nicht nachempfinden, da ihnen ein Gelenk in den Schultern fehlt.
Der Winkelbasierte Ansatz ist der effektivste, da hier die Berechnungen f¨
ur
alle Nutzer gleich funktionieren und keine Funktion genutzt werden muss,
mit der Nutzer- in Roboterkoordinaten umgerechnet werden. So eine Funktion ist zu vermeiden, da sie nicht robust bei Menschen mit unterschiedlichen
K¨orperproportionen ist. Des Weiteren ist anzumerken, dass die Funktion des
OpenNI Frameworks, mit der f¨
ur jedes Gelenk dessen Koordinatensystem
bestimmt werden kann, nicht genutzt wird. Die von der Funktion gelieferten
Koordinatensysteme sind auf Grund ihres Rauschens und ihrer Freiheitsgrade nicht geeignet, um damit die Winkel der Gelenke zu berechnen. F¨
ur
die Basiskonfiguration wurde die Pose in Abbildung 9 gew¨ahlt.
5.2
Berechnung der Winkel der verschiedenen Gelenke
Die Roboter besitzen, im Gegensatz zu Menschen, keine Kugelgelenke. Es
m¨
ussen also die meisten Gelenke des Nutzers in Repr¨asentationen umgesetzt
werden, die denen der Roboter gleichen. Dabei werden in einigen F¨allen Freiheitsgrade weggelassen, da diese an den Robotern nicht existieren.
Im Folgenden sollen die mathematischen Grundlagen erl¨autert werden, die
f¨
ur die daran anschließenden Berechnungen n¨otig sind.
21
5.2 Berechnung der Winkel der verschiedenen Gelenke
5.2.1
Lutz Freitag
Mathematische Grundlagen
• Skalarprodukt
Das Skalarprodukt p zweier Vektoren ~a, ~b ist definiert durch:
dim(a)
p=
X
ai · b i
(1)
i=1
• Kreuzprodukt
Das Kreuzprodukt ~k zweier Vektoren ~a, ~b ∈ R3 ist definiert durch:
p~ = ~a × ~b
p 1 = a2 · b 3 − b 2 · a3
p 2 = a3 · b 1 − b 3 · a1
p 3 = a1 · b 2 − b 1 · a2
(2)
• Winkel zwischen Vektoren
Ein Winkel zwischen zwei Vektoren ~a , ~b berechnet sich folgendermaßen:
α=
~a ∗ ~b
|a| ∗ |b|
(3)
Diese Berechnung wird im Folgenden mit α = ~a6 ~b abgek¨
urzt.
Ist dazu noch ein Vektor ~c gegeben, um den herum der Winkel gemessen
werden soll (Rechte-Hand-Prinzip), so gilt:

~a·~b
~b 6 ~c ≤ 90◦

,
f¨
u
r
~
a
×
|a|·|b|
α=
(4)
~b 6 ~c > 90◦
 ~a·~b + 180◦ , f¨
u
r
~
a
×
|a|·|b|
urzt.
Dies wird im Folgenden mit α = ~a6 ~c~b abgek¨
• Matritzenmultiplikation
Eine a × b Matrix A, die mit einer b × c Matrix B multipliziert wird,
ergibt eine a × c Matrix C.
Ci,j =
b
X
k=1
22
Ai,k · Bk,j
(5)
5.2 Berechnung der Winkel der verschiedenen Gelenke
Lutz Freitag
• Rotationsmatrix
Rotationsmatritzen sind Matritzen mit der Vektoren um den Koordinatenursprung herum rotiert werden k¨onnen. Eine Matrix A ist eine
Rotationsmatrix, wenn gilt: det(A) = 1 und f¨
ur jeden Vector ~a muss
3
gelten |A · ~a| = |~a|. Eine Matrixin R , die um einen Vektor ~v mit dem
Winkel α dreht bildet sich nach:
Cosinus und Sinus werden mit c bzw. s abgek¨
urzt.

c(α) + v12 (1 − c(α))
v1 v2 (1 − c(α)) − v3 s(α) v1 v3 (1 − c(α)) + v2 s(α)
v2 v3 (1 − c(α)) + v1 s(α)
c(α) + v22 (1 − c(α))
= v1 v2 (1 − c(α)) − v3 s(α)
v1 v3 (1 − c(α)) + v2 s(α) v2 v3 (1 − c(α)) + v1 s(α)
c(α) + v32 (1 − c(α))
(6)

A~v,α
• Orthogonale Projektionen
Um einen Punkt P , beschrieben durch seine Koordinaten p~, auf eine
Ebene in normierter Normalform 0 = (~r − ~a)·~n0 (~a sei der St¨
utzvektor,
~n0 der Normalenvektor) zu projizieren, werden folgende Operationen
durchgef¨
uhrt:
p~proj = ~n0 × (~p − ~a) × ~n0 + ~a
23
(7)
5.2 Berechnung der Winkel der verschiedenen Gelenke
Lutz Freitag
• Invertieren von Rotationsmatritzen
Die Inverse einer Rotationsmatrix ist ihre transponierte. Es gilt also:
E = A · AT = A · A−1
(8)
[6] [8]
5.2.2
Modellierung
Ein Nutzer setzt sich f¨
ur die Berechnungen aus den Koordinaten seiner Gelenke zusammen. In der Torsomitte befindet sich ein festes Gelenk, das als
K¨orpermittelpunkt dient. In diesem befindet sich der Ursprung des K¨orperkoordinatensystems. Die x-Achse des K¨orperkoordinatensystems ist der Vektor
vom Genick zur linken Schulter. Die y-Achse ist der Vektor zwischen K¨orpermittelpunkt und dem Genick und die z-Achse ist das Kreuzprodukt aus
x- und y-Achse. Wie in Abbildung 10 sichtbar, garantiert die Skelettierung
der NITE-Middleware, dass die Vektoren zwischen K¨orpermittelpunkt und
Genick und zwischen Genick und den Schultern senkrecht aufeinander stehen.
24
5.2 Berechnung der Winkel der verschiedenen Gelenke
Lutz Freitag
Abbildung 10: 3D-Darstellung eines Nutzers mit Normalenvektoren (links
rot, rechts gr¨
un) auf den Gelenken und den Fußkoordinatensystemen
In Abbildung 10 ist die Skelettierung des Nutzers in einer 3D-Perspektive
erkennbar. Die gr¨
unen und roten Linien an den Ellbogen-, Schulter-, Kniebzw. H¨
uftgelenken stellen die errechneten Normalenvektoren auf den jeweiligen Gelenken dar. Grunds¨atzlich werden diese Normalenvektoren aus dem
Kreuzprodukt des Vektors des Elternknochens mit dem des Kindknochens
berechnet. In einigen F¨allen ist dabei keine eindeutige Berechnung des Normalenvektors m¨oglich. Diese F¨alle werden im Folgenden erl¨autert.
• Ellbogen und Knie (Scharniergelenk)
Der Winkel an einem Scharniergelenk am Punkt A, das Punkte B und
C verbindet (siehe Abbildung 11) l¨asst sich durch
αScharniergelenk =
~a ∗ ~b
|a| ∗ |b|
(9)
berechnen. In der Implementierung wurde dabei eine Schwelle αScharniergelenkM in
eingef¨
uhrt, unterhalb der das Ergebnis 0 ist. Die vollst¨andige Funktion
25
5.2 Berechnung der Winkel der verschiedenen Gelenke
Lutz Freitag
lautet also:
(
αScharniergelenk =
~a∗~b
|a|∗|b|
0
~a∗~b , f¨
ur |a|∗|b| > αScharniergelenkM in
, sonst
(10)
Abbildung 11: Winkel an Scharniergelenken
Die Normalenvektoren an diesen Gelenken werden mit dem Kreuzprodukt berechnet. Ist der Elternknochen fast parallel zum Kindknochen,
das Gelenk ist nahezu um 180◦ gestreckt, muss der Normalenvektor anders berechnet werden. Das Vorhandensein dieses Vektors ist notwendig,
um die Berechnung der korrekten Winkel an den H¨
uften und an den
Schultern durchzuf¨
uhren. Im Falle von ann¨ahernd parallelen Gliedmaßen werden folgende Berechnungen ausgef¨
uhrt, um dennoch Normalenvektoren zu erhalten.
– Ellbogen
Es wird eine Rotationsmatrix gebildet, von der die dritte Basis als
Normalenvektor genommen wird.
 
0
−1

nnormal
~
= MRotation · 0
(11)
1
Die Rotationsmatrix wird, wenn m¨oglich, aus dem Normalenvektor und dem Rollwinkel am Schultergelenk gebildet. Falls dies
26
5.2 Berechnung der Winkel der verschiedenen Gelenke
Lutz Freitag
nicht m¨oglich ist, kann die y-Achse des K¨orperkoordinatensystems
genutzt werden, da der Nutzer den Arm senkrecht vom K¨orper
ausgestreckt h¨alt. Hierbei w¨are jeder Vektor der y-z-Ebene eine
L¨osung. Damit das Ergebnis eindeutig und so nah wie m¨oglich
an der Nullposition ist, wird die z-Basis genutzt (siehe 9) . Der
Grundgedanke hinter der Nutzung der ersten Basis der Rotationsmatrix ist die Rotation der z-Achse um den Normalenvektor der
Schulter.
– Knie
An den Knien wird analog zu den Ellbogen im Falle der Parallelit¨at des Oberschenkels zum Unterschenkel eine Rotationsmatrix genutzt, mit der die x-Achse des K¨orperkoordinatensystems
rotiert wird. Obwohl die Roboter drei Freiheitsgrade an diesen Gelenken haben, kann ein Freiheitsgrad vernachl¨assigt werden, da die
Drehung des jeweiligen Beines um die eigene Achse nicht berechnet
werden kann. Die daf¨
ur n¨otigen Informationen k¨onnen aus den Orten der Gelenke nicht entnommen werden. F¨
ur die Erzeugung der
Rotationsmatrix wird sich daher auf das Nick- und das Rollgelenk
der H¨
ufte beschr¨ankt. Die Winkel hierf¨
ur werden also berechnet,
als h¨atte die H¨
ufte kein Giergelenk:
 
0

αHuef te−N ick = 0 6 ~vHuef te−Knie − 90◦
1
 
0
αHuef te−Roll = 1 6 ~vHuef te−Knie − 90◦
0
(12)
(13)
Aus den dadurch berechneten Winkeln lassen sich zwei Rotationsmatritzen erstellen, die multipliziert werden m¨
ussen.
MRotation = MHuef te−Roll · MHuef te−N ick
(14)
−1
· ~x
nnormal
~
= MRotation
(15)
• Schultern
Zur Berechnung der Gelenke an den Schultern muss der fehlende Freiheitsgrad ber¨
ucksichtigt werden. Es m¨
ussen somit zwei Winkel gemessen
werden. An den Robotern befinden sich zwischen Torso und Oberarm
27
5.2 Berechnung der Winkel der verschiedenen Gelenke
Lutz Freitag
die Nickgelenke und an diesen die Rollgelenke. Die Roboter k¨onnen also den Oberarm nur dann um dessen Achse drehen, wenn dieser im
rechten Winkel zum Oberk¨orper gestreckt ist. In diesem Fall ist das
Nickgelenk gleichzeitig ein Giergelenk.
F¨
ur die Berechnung der Winkel an der Schulter werden bis zu drei
Hilfsvektoren genutzt: die z-Achse des K¨orperkoordinatensystems, der
Normalenvektor auf der Schulter und der Normalenvektor auf dem
Ellbogengelenk. Der Normalenvektor an der Schulter wird mit dem
Kreuzprodukt des Vektors vom Nacken zur Schulter und dem Vektor
von der Schulter zum Ellbogen berechnet. Wenn diese Vektoren fast
parallel sind, wird die y-Achse als Normalenvektor genutzt. Weiterhin muss die Orientierung des Normalenvektors eingeschr¨ankt werden.
Zeigt der Normalenvektor nach hinten-unten, so sind die sich daraus
ergebenden Winkel nicht vom Roboter einnehmbar bzw. einzelne Kabel
w¨
urden bei dieser Haltung unter mechanischer Spannung stehen und
eventuell reißen. Um dies zu vermeiden, projiziert man den Normalen 
0
vektor orthogonal auf die y-z-Ebene und pr¨
uft, ob ~vprojiziert 6 1 ≥
1
135◦ gilt. Ist dies der Fall, wird der invertierte Normalenvektor genutzt.
In Abbildung 12 werden die Vektoren im Modell gezeigt.
Abbildung 12: Winkel an der Schulter
28
5.2 Berechnung der Winkel der verschiedenen Gelenke
Lutz Freitag
Wie oben beschrieben, m¨
ussen zwei Winkel an den Schultern berechnet
werden:
– Nickwinkel
Der Nickwinkel ist der Winkel zwischen dem Nomalenvekor auf
der Schulter und der y-Achse des K¨orperkoordinatensystems um
die x-Achse desselben herum. Befindet sich der Oberarm nahezu
parallel zum Schulterg¨
urtel, ist der Normalenvektor nur ungenau
bestimmbar bzw. w¨
urde bei leichten Bewegungen starke Bewegungen an den Robotern verursachen. Hierf¨
ur muss der Normalenvektor am Schultergelenk in die Berechnung einbezogen werden.
Der Nickwinkel ergibt sich dann aus dem Winkel zwischen dem
Normalenvektor des Ellbogenegenks und der z-Achse des des K¨orperkoordinatensystems um die x-Achse herum.
– Rollwinkel
Da die Fallunterscheidung f¨
ur die Winkel bereits in der Nickwinkelberechnung getan wurde und die Roboter nur zwei physikalische Gelenke an den Schultern haben, berechnet sich der Rollwinkel
aus dem Winkel zwischen dem Schulterg¨
urtel und dem Oberarm
um den Normalenvektor der Schulter herum. In diesem Fall muss
nicht unterschieden werden, ob der Oberarm ann¨ahernd parallel
zum Schulterg¨
urtel ist, da angenommen werden kann, dass der
◦
Winkel 0 ist. Dies ergibt sich durch die normale Winkelberechnung.
• H¨
ufte
An den Robotern setzt sich das H¨
uftgelenk aus drei Servomotoren
zusammen, die jeweils um eine Achse rotieren. In der kinematischen
Kette kommt erst das Gier-, dann das Roll- und schließlich das Nickgelenk.
Wie schon bei der Schulter m¨
ussen auch an der H¨
ufte die Winkel einzeln
berechnet werden. Siehe Abbildung 13.
– Gierwinkel
Die Rotation um die y-Achse an diesem Gelenk wird zum Drehen
der Roboter ben¨otigt. Steht nur ein Bein auf dem Boden, kann
durch Rotation an dieser Achse der Oberk¨orper gedreht werden.
Geschieht dies abwechselnd mit beiden Beinen, dreht sich der
29
5.2 Berechnung der Winkel der verschiedenen Gelenke
Lutz Freitag
Abbildung 13: Winkel Berechnung an den Beinen
Roboter. Bei der Berechnung des Gierwinkels wird lediglich unterschieden, ob sich der zum Bein zugeh¨orige Fuß auf dem Boden
befindet oder nicht. Befindet er sich nicht auf dem Boden, ergibt
sich der Gierwinkel mit dem Normalenvektor des Knies aus:
αGier = (~xBasis 6 ~nKnie ) − 90◦
(16)
Es wurden Koordinatensysteme eingef¨
uhrt, die von den F¨
ußen
gehalten werden. Sie kommen zum Einsatz, wenn der Boden nicht
von den jeweiligen Beinen ber¨
uhrt wird. Wenn der Fuß in der Luft
ist, also den Boden nicht ber¨
uhrt, so ist das Koordinatensystem
des Fußes das des K¨orpers MK . Sobald der Fuß den Boden ber¨
uhrt
und so lange er nicht wieder in der Luft ist, wird das letzte Koordinatensystem MF gehalten. Dabei wird der Winkel folgendermaßen
berechnet:
30
5.2 Berechnung der Winkel der verschiedenen Gelenke
  
   
0
1
0
~h = 1 × M −1 ∗ 0 × 1
F
0
0
0

 
1
−1  
~

6
αGier = h
MK ∗ 0
0
Lutz Freitag
(17)
Es wird somit ein Hilfsvektor erzeugt, mit dem die auf die x-zEbene projizierte x-Achse des Fußkoordinatensystems repr¨asentiert und der Winkel zwischen diesem Hilfsvektor und der x-Achse
des K¨orperkoordinatensystems gemessen wird. F¨
ur bessere Ergebnisse kann dieser Vorgang ebenso mit den z-Achsen der einzelnen Koordinatensysteme durchgef¨
uhrt werden. Dann wird u
¨berpr¨
uft, bei welcher der projizierte Hilfsvektor l¨anger ist. Auf diese
Art ist man robuster gegen den Fall, dass der Nutzer liegt. In
der konkreten Implementierung wurde bewusst auf diesen Fall
verzichtet.
– Rollwinkel
Der Rollwinkel ist der Winkel zwischen der x-z-Ebene und dem
Normalenvektor des Knies sowie nach der Rechte-Hand-Regel
  um
0
die zweite Basis einer Rotationsmatrix M~v,αgier mit ~v = 1:
0
αRoll
= ~y 6
My~−1
,α
~vnormal−Knie − 90◦
(18)
gier 3
 
0
0 angenommen
Aus praktischen Gr¨
unden kann M~y−1
=
,αgier 3
1
werden. Die Berechnung ist dann korrekt, solange
−90◦ < αGier < 90◦ gilt.
– Nickwinkel
F¨
ur die Berechnung des Nickwinkels wird wiederum eine Rotationsmatrix genutzt, mit der die z-Achse des K¨orperkoordinatensystems um die y-Achse mit dem Gierwinkel rotiert wird. Der
Nickwinkel ergibt sich dann aus dem Winkel zwischen der rotierten
z-Achse und dem Vektor des Oberschenkels um die zweite Basis
von M~y,αgier herum.
31
5.3 Probleme durch unterschiedliche K¨orpergeometrien

αN ick = M~y−1
,αgier
 
0

· 0 6
1
Lutz Freitag

My~−1
,α
gier 1
~vHuef te−Knie  − 90◦
(19)
Die 90◦ ergeben sich daraus, dass der hier berechnete Winkel um
90◦ gr¨oßer ist als der Nullwinkel in der Basispose.
• F¨
uße
Die F¨
uße der Roboter haben zwei Gelenke, mit denen dem Nick- und
Rollwinkel der H¨
ufte entgegengesteuert werden kann. Die Winkel an
diesem Gelenk sollten nicht direkt berechnet werden, es sollten stattdessen
die inversen Winkel der H¨
ufte genommen werden. Dadurch wird gew¨ahrleistet, dass die Roboter nicht umfallen.
5.3
Probleme durch unterschiedliche Ko
¨rpergeometrien
Im Gegensatz zur Steuerung der Arme durch die oben beschriebenen Methoden, ist es nicht m¨oglich die Beine der Roboter direkt zu steuern. Einerseits
ist die Skelettierung des Nutzers zu rauschanf¨allig, andererseits st¨oren die
unterschiedlichen Geometrien und Gewichtsverteilungen zwischen Roboter
und Nutzer. Die Roboter m¨
ussten sich selbstst¨andig stabilisieren, um ihr
Umfallen zu vermeiden, wenn die Beine gesteuert werden. Allerdings werden
die Posen des Nutzers dann nur noch wenig umgesetzt, sodass der gewollte
Nutzen, das direkte Fernsteuern des Roboters, nicht mehr sichtbar w¨are.
Weiterhin entstehen Schwierigkeiten in der Stabilisierung der Beine durch
die Verschiedenartigkeit der Gelenke zwischen Menschen und den Robotern.
Die Annahme, dass zum Beispiel Knie Scharniergelenke sind, ist nicht unbedingt zutreffend. Knie erlauben einen nicht zu vernachl¨asigbaren Spielraum
f¨
ur Gierbewegungen des Unterschenkels. Menschen nutzen diesen und weitere
Freiheitsgrade ihrer Gelenke, um das eigene Laufen zu stabilisieren.
6
Steuerung durch Gesten
Da die Steuerung der Beine nicht ohne Weiteres realisierbar ist, m¨
ussen
bestimmte Bewegungsabl¨aufe (statische und dynamische Motions) anders
realisiert werden. Beispielsweise ist es nicht gelungen die Roboter u
¨ber die
direkte Steuerung laufen oder aufstehen zu lassen. Wie oben beschrieben
sind die K¨orpergeometrien und Gewichtsverteilungen zu unterschiedlich. Es
32
6.1 Funktionsweise
Lutz Freitag
wurden f¨
ur die notwendigsten Bewegungsabl¨aufe der Roboter im Fußballspiel Konzepte ausgearbeitet, mit denen die Roboter dennoch von einem
Menschen ferngesteuert werden k¨onnnen, ohne das Konzept der nat¨
urlichen
Schnittstellen zu verletzen. Diese werden im Folgenden erl¨autert. Bei der
Steuerung durch Gesten werden nur Daten an die Roboter u
¨bertragen, die
die Ausf¨
uhrung der Motions auf dem Roboter veranlassen und im Falle der
Laufsteuerung noch die Parameter, die f¨
ur das Laufen notwendig sind. Die
konkrete Ausf¨
uhrung und die Berechnung, wie die Motion ausgef¨
uhrt werden
soll, findet ausschließlich auf den Robotern statt.
Als Gesten seien Bewegungsabl¨aufe des Nutzers beschrieben. Sie sind unabh¨angig von der r¨aumlichen Ausrichtung des Nutzers und sollten so gestaltet
sein, dass sie f¨
ur Nutzer intuitiv sind.
Im Folgenden muss zwischen statischen und dynamischen Motions unterschieden werden, da sie jeweils unterschiedliche Konzepte der Steuerung erfordern.
• Dynamische Motions
Dynamische Motions sind beispielsweise das Laufen und das dynamische Schießen. Die Roboter k¨onnen unterschiedlich schnell laufen und
ihren Schuss entprechend der Spielsituation anpassen [12]. Aus der
Sollgeschwindigkeit berechnet sich beispielsweise die Schrittweite. Die
Ausf¨
uhrung der Bewegung wird also dynamisch berechnet.
• Statische Motions
Bewegunsabl¨aufe wie das Aufstehen von hinten oder vorn oder Bewegungen, die der Unterhaltung dienen, wie der H¨
uhnertanz, laufen
immer gleich ab. Ihre Ausf¨
uhrung dauert immer gleich lang und veranlasst die Roboter dazu, immer zum gleichen Zeitschritt innerhalb des
Bewegungsablaufes die gleiche Konfiguration zu haben.
Da die meisten statischen Motions der Unterhaltung dienen und durch die
direkte Steuerung abgedeckt werden k¨onnen, m¨
ussen lediglich zwei statische
Motions durch Gesten des Nutzers ausl¨osbar sein k¨onnen.
6.1
Funktionsweise
Die Gestenerkennung setzt auf der Skelettierung auf. Mittels Zustandsmaschinen werden die Konfiguration des Skelettes oder Teile dessen u
¨berwacht und
der Zustand der Maschine ver¨andert, wenn das Skelett eine bestimmte Pose
eingenommen hat. F¨
ur die Steuerung von dynamischen Motions ist es sinnvoll, zus¨atzlich zu dem Zustand noch die Zeitpunkte zu speichern, an denen
33
6.2 Aufstehgeste
Lutz Freitag
die Zusands¨
uberg¨ange stattgefunden haben. Dynamische Motions k¨onnen so
mit zus¨atzlichen Informationen beliefert werden. In diesem konkreten Fall
wurde diese Anwendung nur bedingt genutzt, da außer der Laufsteuerung
keine dynamischen Motions angesteuert werden.
6.2
Aufstehgeste
Eine intuitive Art den Roboter aufstehen zu lassen ist es, selbst aufzustehen.
Der Nutzer muss also in die Hocke gehen und sich dann wieder aufrichten. Wichtig ist hierbei, dass eine gewisse vertikale Strecke von einem zentral
gelengenen K¨orperteil u
uckt wird. Hierf¨
ur eignen sich die Position des
¨berbr¨
Kopfes oder die des K¨orpermittelpunktes. Die Zustandsmaschine ist in Abbildung 14 dargestellt.
Abbildung 14: Zustandsdiagramm Aufstehgeste
Problematisch an dieser Zustandsmaschine ist, dass die K¨orperh¨ohe bekannt
sein muss. Hierf¨
ur wurde eine Variable gef¨
uhrt, die den maximalen y Wert
des K¨orperteils h¨alt, der gemessen wird, w¨ahrend sich die Zustandsmaschine
im Startzustand befindet. Ausgehend von diesem Wert und der H¨ohe des
Bodens kann die K¨orperh¨ohe gemessen werden und wie tief sich ein Nutzer
hocken muss, manit die Zustandsmaschine in den ”Kopf ist unten” Zustand
wechselt.
Die Ausf¨
uhrung der Geste wird von den Robotern bestimmt. Stehen sie und
es erreicht sie das Signal aufzustehen, so wird das Signal verworfen. Sie unterscheiden auch selbstst¨andig, welche Aufstehbewegung angewendet werden
soll, je nachdem ob sie auf dem R¨
ucken oder auf dem Bauch liegen.
34
6.3 Schussgeste
6.3
Lutz Freitag
Schussgeste
Die Schussbewegung der Roboter ist der eines Menschen stark nachempfunden. Sie verlagern das eigene Gewicht auf das St¨
utzbein und bewegen
das Schussbein nach hinten, um dieses danach nach vorn schnellen zu lassen.
Prinzipiell k¨onnen die Roboter mit beiden Beinen schießen [12]. Die Steuergeste
f¨
ur den Schuss ist daher eine Schussbewegung des Menschen. Sollen die
Roboter mit dem linken Bein schießen, so muss der Nutzer die Schussgeste mit
dem linken Bein ausf¨
uhren und andersherum vice versa. Die Zustandsmaschine muss in diesem Fall noch ber¨
ucksichtigen, dass entweder eine Schussgeste mit dem linken Bein gew¨
unscht ist oder mit dem rechten. Ist sie also in
einem Zustand in dem die Schussgeste eines Beines initialisiert ist (das Bein
wurde nach hinten geschwungen), so muss es eine M¨oglichkeit geben, wieder
in den Initialzustand gelangen, ohne den Schuss auszuf¨
uhren. Daf¨
ur wurde ein
Timer genutzt. Ab dem Zeitpunkt, an dem der Nutzer das Schussbein nach
hinten genommen hat, hat er zwei Sekunden Zeit, um die Geste auszuf¨
uhren.
Verstreichen diese, ohne dass er sein Bein nach vorn geschwungen hat, gelangt
die Zustandsmaschine automatisch wieder in den Startzustand. H¨alt er dagegen diese Position (das Bein ist also l¨anger als zwei Sekunden nach hinten
gestreckt), gelangt die Maschine automatisch wieder in den Initialisierungszustand der Schussgeste f¨
ur das entsprechende Bein. Wartet der Nutzer also auf
einen bestimmten Zeitpunkt f¨
ur den Schuss, kann er sein Schussbein hinten
lassen und erst dann nach vorn schnellen lassen, wenn der Schuss ausgef¨
uhrt
werden soll. Die Zustandsmaschine wird in Abbildung 15 dargestellt.
Abbildung 15: Zustandsdiagramm der Schussbewegung
¨
Da der Automat symmetrisch f¨
ur das linke und rechte Bein ist, die Uber¨
f¨
uhrungen aber das gleiche bedeuten, wird zwischen den Uberf¨
uhrungen un35
7 Laufsteuerung
Lutz Freitag
¨
terschieden, indem die Funktionen mit * f¨
ur das rechte Bein gelten. Die Uberf¨
uhrungsfunktionen bedeuten das Folgende:
• 1: Der Nutzer hat sein Bein nach hinten gestreckt. Damit wird in den
Initialisierungszustand f¨
ur das entsprechende Bein gewechselt.
• 2: Der Nutzer hat das Bein nach vorn geschwungen. Damit wird das
Signal an die Roboter geschickt, dass der Schuss am entsprechenden
Bein ausgef¨
uhrt werden soll.
• 3: Der Nutzer hatte sein Bein nach hinten gestreckt, jedoch nicht im
entsprechenden Zeitfenster nach vorn geschwungen. Damit wird wieder
in den Ausgangszustand gewechselt.
¨
F¨
ur die Grundlage der Uberf¨
uhrungsfunktionen hat sich herausgestellt, dass
es nicht zielf¨
uhrend ist, die Winkel zwischen den jeweiligen Gelenken zu betrachten. In der Praxis starten viele Nutzer ihre Schussphase mit dem nach
vorn Kippen des Oberk¨orpers. Dabei lassen sie ihr Schussbein gestreckt. Wird
der Nickwinkel am H¨
uftgelenk von der Zustandsmaschine beobachtet, kann
¨
keine Anderung erkannt werden, da sich die Orientierung des Schussbeines
zum Oberk¨orper nicht ge¨andet hat. Auch ist es nicht zielf¨
uhrend, wenn man
stattdessen den Nickwinkel des anderen Beines beobachtet. In diesem Fall
wird kein Schuss erkannt, wenn der Nutzer seinen Oberk¨orper aufrecht h¨alt
und nur das Schussbein schwingen l¨asst. Als praktisch hat sich die horizon¨
tale Entfernung zwischen K¨orpermittelpunkt und Knie egeben. Uberschreitet
diese einen gewissen Schwellwert und befindet sich das Schussbein nicht auf
dem Boden, wird in den Initialisierungszustand u
¨bergegangen. Das Erkennen
der weiteren Phasen der Geste erfolgt analog.
7
Laufsteuerung
Das Laufen ist eine dynamische Bewegung, deren genaue Ausf¨
uhrung auf dem
jeweiligen Roboter berechnet werden muss. Der Roboter berechnet nach seiner Geometrie die Schrittweite, die Drehungen der Gier- und Rollgelenke der
H¨
ufte bzw. F¨
uße. Das FUmanoid-Programm stellt hierf¨
ur ein Objekt zur Verf¨
ugung, das eine komfortable Laufsteuerung realisiert. Mit dem Objekt l¨asst
sich die Vorw¨arts-, Rotations- und Seitw¨artsgeschwindigkeit ¨andern, ohne
dass der genaue Laufmechanismus bekannt ist. Auf der Seite des Nutzers
m¨
ussen Werte generiert werden, die den Sollgeschwindigkeiten der Roboter
entsprechen. Zur Berechnung wird ein virtueller Kreis zur Hilfe genommen,
der im Nutzerraum horizontal fest um einen Punkt liegt. Dieser Kreis kann
36
8 Fazit
Lutz Freitag
entweder global fest sein oder f¨
ur die einzelnen Nutzer selbst berechnet werden. Befindet sich der Nutzer nah dem Mittelpunkt, bleibt der L¨aufer stehen.
Stellt sich der Nutzer nun weiter vorn in den Kreis, l¨auft der Roboter vorw¨arts
bzw. seitlich, wenn sich der Nutzer nach links oder rechts stellt. In Abbildung
16 ist dieser Kreis dargestellt. Hat sich der Nutzer um die vertikale Achse
gedreht, so dreht sich der Roboter entsprechend. Die Geschwindigkeiten, mit
denen der Roboter die Bewegungen ausf¨
uhrt richten sich bei der Laufrichtung nach der r¨aumlichen Entfernung zwischen Nutzer und Mittelpunkt des
Kreises und bei der Rotation am Winkel zwischen einer Nullrichtung und der
aktuell gemessenen Richtung. Die Nullrichtung kann wie der Mittelpunkt des
Kreises global oder f¨
ur jeden Nutzer einzeln festgelegt werden.
Abbildung 16: Visualisierung der Laufsteuerung. Der Roboter wird vorw¨arts
und leicht nach rechts gesteuert.
In Bild 16 wird die Laufsteurung visualisiert. Der rote Punkt stellt die K¨orpermitte des Nutzers dar, der sich innerhalb des virtuellen Kreises bewegt.
Der innere Kreis stellt eine Schwelle dar. Befindet er sich außerhalb des inneren Kreises, fangen die Roboter an, sich in die entsprechende Richtung
zu bewegen. Verl¨asst der Nutzer den ¨außeren Kreis, so bleibt der Roboter
stehen. Er l¨asst sich dann erst wieder steuern, wenn der Nutzer wieder den
inneren Kreis betreten hat.
8
Fazit
Wie bereits erl¨autert funktioniert die Laufsteuerung nicht mit der direkten
Steuerung. W¨
unschenswert w¨are es, wenn die Roboter die Beinposen so genau
wie m¨oglich einnehmen k¨onnten, die der Nutzer vorgibt. Derzeit ist dies aber
37
9 Ausblick
Lutz Freitag
nicht m¨oglich, da die Skelettierung die Beine nicht genau genug aufl¨osen
kann. Eine L¨osung an dieser Stelle w¨aren Markierungen an den Beinen, mit
denen diese besser erkannt werden k¨onnen. Dann best¨
unde dennoch das Problem der unterschiedlichen Geometrien. Die Roboter fallen bei bestimmten
Posen um, bei denen Menschen stabil stehen und andersherum. Es muss also
eine Schnittmenge dieser Posen gefunden werden und nur Posen aus dieser
Schnittmenge u
¨bertragen werden. Allerdings ist die Schnittmenge nicht trivial zu berechnen, da einerseits die genauen Gewichtsverteilungen der Roboter
nicht bekannt und die der Nutzer nur kompliziert zu messen sind. F¨
ur weitere
bessere Ergebnisse m¨
ussen einige Freiheitsgrade der Menschen wegabstrahiert
werden. Die Gierbewegungen der Unterschenkel beispielsweise sind nicht von
den Robotern reproduzierbar.
Der praktische Teil dieser Arbeit wurde im Rahmen der langen Nacht der
Wisschenschaften an der Freien Universit¨at pr¨asentiert und fand speziell bei
dem j¨
ungeren Publikum großen Anklang. Die Kinder konnten dabei aus der
Roboterperspektive die Arme steuern, zum Ball navigieren und Tore schießen.
Die Steuerung durch Gesten schien den Kindern besonders leicht gefallen zu
sein. Auch ohne vorherige Erkl¨arung der Steuerung waren die Kinder in der
Lage die richtige Schuss- und Aufstehgeste auszuf¨
uhren.
9
Ausblick
Nat¨
urliche Schnittstellen werden sich in den kommenden Jahren weiter im
Alltag etablieren. Derzeit gibt es bereits einige vielversprechende Ans¨atze, um
Eingaben f¨
ur Computer zu generieren. Diese sind allerdings nur auf spezielle
Anwendungen zugeschnitten. Langfristig werden sich daher wahrscheinlich
Kombinationen aus Bedienkonzepten durchsetzen, sodass Nutzer auf die Art
mit ihren Computern interagieren k¨onnen, wie sie es bevorzugen.
Im Bereich Robotik kann mit nat¨
urlichen Schnittstellen besser auf Menschen
reagiert werden. Sie bieten speziell f¨
ur ¨altere Menschen eine gute M¨oglichkeit
der Mensch-Maschinen-Interaktion, bei denen das Einlernen in klassische
(nicht-nat¨
urliche) Bedienkonzepte schwer ist. Haushaltsroboter k¨onnen zum
Beispiel durch Gesten darauf aufmerksam gemacht weden, bestimmte Dinge
zu erledigen.
Steuerungen wie sie im Rahmen dieser Arbeit realisiert wurden, k¨onnen in
Bereichen genutzt werden, wo Menschen nicht arbeiten k¨onnen, weil die
Umgebung der Gesundheit schaden w¨
urde. Roboter, k¨onnen darin Arbeit
verrichten, f¨
ur die menschliche Geschicklichkeit und schnelle Anpassungsf¨ahigkeit notwendig ist. So k¨onnen komplizierte Reperaturaufgaben von Experten durchgef¨
uhrt werden, ohne dass diese anwesend sein m¨
ussen.
38
Literatur
Lutz Freitag
Literatur
[1] Wikipedia: Deep map from Kinect, verf¨
ugbar online
http://upload.wikimedia.org/wikipedia/commons/9/90/
Kinect2-deepmap.png.
unter:
[2] Wikipedia: Von der Kinect empfangenes Infrarotbild mit dem
vom Laserprojektor ausgestrahltem Punktmuster, verf¨
ugbar online unter: http://upload.wikimedia.org/wikipedia/commons/7/
76/Kinect2-ir-image.png.
[3] Boguslaw Cyganek and J. Paul Siebert. An Introduction to 3D Computer
Vision Techniques and Algorithms. Wiley & Sins, Ltd, 2009.
[4] Oliver Faugeras. Three-Dimensional Computer Vision - A Geometric
Viewpoint. The MIT Press, 1993.
[5] Adrian Kaehler Gary Bradski. Learning OpenCV: Computer Vision with
the OpenCV Library. O’Reilly, 2008.
[6] John H. Hubbard and Barbara Burke Hubbard. Vector Calculus, Linear
Alegebra, and Differential Forms. Martrix Editions, 2009.
[7] jkj. Minority Report im Fernsehsessel. C’T, 11:168 – 171, Mai 2011.
[8] Marvin Marcus and Henryk Minc. Integrated Analytic Geometry and
Algebra with Circular Functions. General Learning Press, 1973.
[9] Dave Mark and Jeff LaMarche. Beginning Iphone 3 Development: Exploring the Iphone SDK. Apress, 2009.
¨
[10] Hans-Arthur Marsiske. RoboCup German Open: ”Roboter werden Ubersch¨atzt”. Heise Online, 2011.
[11] Natural Interaction. OpenNI User Guide.
[12] Stefan Otte. Entwicklung eines dynamischen Schusses f¨
ur humanoide
Fußballroboter, 2010.
[13] Richard P. Paul. Robot Manipulators: Mathematics, Programming, and
Controll - The Computer Control of Robot Manipulators. The MIT
Press, 1981.
[14] PrimeSense. Prime SensorTM NITE 1.3 Algorithms notes, 2010.
[15] PrimeSense. PrimeSense Reference Design 1.08PS, 2010.
39
Literatur
Lutz Freitag
[16] Robotis Inc. User’s Manual Dynamixel RX-28.
[17] Robotis Inc. User’s Manual Dynamixel RX-64.
[18] Daniel Seifert, Hamid Reza Moballegh, Prof. Ra´
ul Rojas, and et al.
FUmanoids Humanoid League - KidSize Team Description Paper 2011.
[19] Emanuele Trucco and Alessandro Verri. Indroductory Techniques for
3-D Computer Vision. Prentice Hall, 1998.
40
Download PDF