Auslagerung der Aktorik von humanoiden Robotern

Relocation of the control system for actuators of humanoid robots

Nico von Geyso

Bachelorarbeit an der Freien Universität Berlin, Institut ür Informatik

Betreuer: Prof. Dr. Raúl Rojas Dr. Hamid Mobalegh

Berlin 2012 Eidesstaliche Erklärung

Ich versichere, die Bachelorarbeit selbstständig und lediglich unter Benutzung der angegebe- nen ellen und Hilfsmiel verfasst zu haben. Ich erkläre weiterhin, dass die vorliegende Ar- beit noch nicht im Rahmen eines anderen Prüfungsverfahren eingereicht wurde.

, am

2 Zusammenfassung

In dieser Arbeit geht es um die Auslagerung der Aktorik humanoider Roboter. Das Ziel der Auslagerung ist es, eine zweistufige Kontrollarchitektur mit einem Hauptsystem ür die Wahr- nehmung, Modellierung sowie Verhaltensentscheidungen und einem Subsystem ür reaktives Verhalten, provisorische zeitkritische Bewertungen und die sensomotorische Kopplung zu ent- wickeln. Hierzu war der Entwurf eines neuen Mikrocontroller-Systems erforderlich, das als Subsystem im Roboter fungieren soll. Gleichzeitig musste ein Echtzeitsystem ür den Mikro- controller entwickelt werden, das diese Aufgaben übernimmt. Die neue Architektur fand ihren erfolgreichen Einsatz bei Fußball spielenden humanoiden Robotern des Teams FUmanoids beim Robocup 2011 in Istanbul.

Abstract

is paper deals with the approach of a new two-tier architecture for humanoid robots. e goal was to organise the platform into a main system for perception, modeling and behaviour and a subsystem for rudimentary behaviour, pre quantification of data and actuators. For this purpose a new microcontroller system had to be designed. At the same time a real-time system had to be developed. e new architecture was successfully used in soccer-playing humanoid robots of the FUmanoid team at the Robocup 2011 in Istanbul.

3 Inhaltsverzeichnis

1 Einleitung 6 1.1 Aktorik – ein zeitintensiver Prozess ...... 6 1.2 Robocup ...... 7

2 Plaformen für humanoide Roboter 9 2.1 Grundlegender Auau ...... 9 2.2 Monolithische Basisarchitektur ...... 10 2.3 Entwicklung zu mehrstufigen Kontrollarchitekturen ...... 11

3 Hardware 14 3.1 Anforderungsanalyse ...... 14 3.1.1 Kommunikation ...... 14 3.1.2 Leistung und Peripherie ...... 18 3.1.3 Auswahlprozess ...... 19 3.1.4 Entwicklungsboard - STM32 H107 ...... 21 3.2 Entwurf ...... 22 3.2.1 Adapterplatine ...... 23 3.2.2 SD-Karte ...... 23 3.2.3 RS485 ...... 24 3.2.4 RS232 ...... 25

4 Sowareentwicklung 27 4.1 Sowareanforderungen ...... 27 4.1.1 Plaformunabhängigkeit ...... 27 4.1.2 Echtzeitähigkeit ...... 27 4.1.3 Fehlerdiagnose und Wartbarkeit ...... 28 4.1.4 Asynchronität ...... 28 4.1.5 Modularität ...... 28 4.2 Implementierung ...... 29 4.2.1 Architektur ...... 29 4.2.2 Programmlogik ...... 29 4.2.3 Toolchain ...... 30

5 Benchmark 32 5.1 Zugriffszeit ...... 32 5.2 Laufalgorithmus ...... 33

4 Inhaltsverzeichnis

6 Fazit 35

Literaturverzeichnis 36

Abbildungsverzeichnis 38

5 1 Einleitung

Die Faszination, den menschlichen Körper in seiner Komplexität verstehen zu wollen, scheint ungebrochen. So hat sich dieser über Jahrtausende evolutionär weiterentwickelt und neuen Gegebenheiten immer wieder angepasst. Ein Teil der Forschung zur künstlichen Intelligenz und Robotik knüp an diese Entwicklung an und versucht autonome Systeme zu entwickeln, die an Fähigkeiten des Menschen heran kommen sollen. Probleme wie das Erkennen von Ob- jekten, die Lokalisierung im Raum, Verhaltensentscheidungen oder der Gang auf zwei Beinen konnten bisher, wenn überhaupt, nur rudimentär gelöst werden. Die bislang gefundenen Lö- sungen können bei weitem nicht mit den Fähigkeiten des Menschen konkurrieren. Es scheint, als stünde die Robotik hier noch am Anfang eines Prozesses, der freilich ähnlich evolutionär werden könnte wie die Entwicklung des Menschen selbst.

1.1 Aktorik – ein zeitintensiver Prozess

Der Fokus dieser Arbeit liegt auf der Aktorik von autonomen humanoiden Systemen. Akto- rik ist in der Steuer- und Regelungstechnik der Prozess der Steuerung sogenannter Aktoren. Diese Aktoren wandeln Eingangsgrößen in anderweitige Ausgangsgrößen um[19]. Im Fall von Robotern werden elektrische Signale in mechanische Bewegungen umgesetzt. Bei kleineren humanoiden Robotern sind dies derzeit o Servos, die bestimmte Positionen auf einer Dreh- achse anfahren können. Um eine Bewegung abzuspielen oder nachahmen zu können, müssen eine Vielzahl dieser Aktoren bewegt werden. Was ür Menschen als Selbstverständlichkeit gilt und quasi automatisch funktioniert, muss bei Robotern gezielt gesteuert beziehungsweise ge- regelt werden. Dies umfasst eine Menge Lese- und Schreibanfragen an die Steuereinheit des jeweiligen Aktors. Soll sta einer definierten gleichbleibenden Bewegung ein stabiler autono- mer Gang auf zwei Beinen realisiert werden, ist dies bei weitem komplexer. So müssen neben Aktoren auch Sensoren und so der Zustand des derzeitigen Gesamtsystems berechnet und be- rücksichtigt werden.

Aufgrund vieler Lese- sowie Schreibanfragen und komplexer Berechnungen stellt sich die Ak- torik als ein rechen- und zeitintensiver Prozess dar. Die Leistung eben dieser Systeme sind von hoher Bedeutung, da je nach Situation Bewegungsabläufe direkt angepasst werden müssen. Effiziente Systeme wirken sich somit positiv auf die Aktorik des Roboters aus. Der Versuch, ähnlich zum Menschen gewisse Reflexe oder Bewegungsabläufe reaktiv zu lösen, kann ganz neue Architekturansätze erfordern[17].

6 1 Einleitung

Das Ziel dieser Arbeit bestand darin, erste Schrie zur Auslagerung der Aktorik von humano- iden Robotern in ein autonomes System umzusetzen. Hierür sollte das System als Stellvertreter- Lösung, auch Proxy genannt, entworfen und entwickelt werden. Hierdurch sollen das Setzen beziehungsweise Lesen der Aktoren sowie Sensoren beschleunigt und so durch Auslagerung von Aufgaben auf das Proxy-System das Hauptsystem entlastet werden. Ferner sollte mit der Auslagerung der sensomotorischen¹ Kontrollinstanz von autonomen Robotern letztendlich ein Teil menschlicher Funktionsweise übernommen werden.

1.2 Robocup

Der Robocup ist ein Webewerb, bei dem Roboter in verschiedenen Disziplinen gegeneinander antreten. Genauer noch geht es um Fußball spielende Roboter, die inzwischen in verschiede- nen Ligen aktiv sind und eine Vielzahl von verschiedenen Robotertypen umfassen. Das selbst gesetzte Ziel des Robocup ist nicht gerade bescheiden: Im Jahre 2050 soll mit einer Roboter- Mannscha der amtierende FIFA Weltmeister geschlagen werden[14]. Was seinen Ursprung im Fußball hae, ist milerweile auch auf andere Bereiche, wie zum Beispiel Such- und Reungs- sowie Haushaltsroboter, ausgeweitet worden.

Während beim Schach der amtierende Weltmeister schon 1996 von einer Maschine geschlagen werden konnte², scheint dies beim Fußball noch in weiter Ferne zu liegen. Sind beim Schach die Informationen eindeutig und so potentielle Spielzüge definierbar, ist dies aufgrund der Kom- plexität beim Fußball nicht so einfach möglich. Es muss vielmehr aus einer Vielzahl von unter anderem auch falschen oder ungenauen Informationen die richtige Entscheidung getroffen werden. Im Gegensatz zum Schach handelt es sich somit um ein weit dynamischeres System, das schwer zu modellieren ist. An der Freien Universität versucht dies in eorie und Praxis das seit 2007 existierende FUmanoid-Team.

Die FUmanoids spielen in der sogenannten Robocup Humanoid League. In der Robocup Hu- manoid League geht es um Fußball spielende, menschenähnliche Roboter. Diese werden von den Teams meist selbst entworfen. Aufgrund dessen spielen hier eine Vielzahl unterschiedli- cher Robotertypen gegeneinander, die in ihrer Leistungsähigkeit allerdings vergleichbar sein müssen. Der Körper sollte sich in Form von Freiheitsgraden³ sowie in der Wahrnehmung des Gesamtsystems nur geringügig vom Menschen unterscheiden. Die Robocup Humanoid League ist in genau drei Ligen unterteilt. Die Hauptunterschiede dieser Ligen beziehen sich auf die Spielart und die zugelassene Größe der Roboter[15, S. 7]:

KidSize 30cm bis 60cm

TeenSize 90cm bis 120cm

¹Steuerung der Motorik aufgrund von Sensorinformationen ²Deep Blue von IBM gegen Garri Kasparow ³Gelenke

7 1 Einleitung

AdultSize ab 130cm

Während der Wekampf bei der AdultSize noch auf Elfmeterschießen beschränkt ist, werden bei den TeenSize-Teams schon Spiele im zwei-gegen-zwei-Modus und bei den KidSize sogar im drei-gegen-drei-Modus ausgetragen. Bei den KidSize Teams traten bei der Weltmeisterscha im Jahre 2011 in Istanbul 20 Teams aus 10 verschiedenen Ländern gegeneinander an.

(a) 2009 (b) 2011

Abbildung 1.1: KidSize-Roboter des Teams FUmanoids aus verschiedenen Jahren

In den letzten Jahren des Robocups hat das Team FUmanoid in der KidSize-Liga teilgenommen und konnte unter anderem im Jahre 2009 sowie 2010 Vizeweltmeister werden. Gespielt wird in dieser Liga auf einem 4x6 Meter großen Spielfeld. Es unterscheidet sich neben der Größe un- ter anderem auch bei den Toren von einem echten Fußballfeld. Diese sind farblich markiert um Probleme, wie das der Lokalisierung, einfacher lösen zu können. Solche Hilfen sollen von We- bewerb zu Webewerb reduziert werden, um am Ende auf einem echten Fußballfeld bestehen zu können.

Abbildung 1.2: Robocup-Feld aus dem Simulator von Steffen Heinrich und Sebastian Mielke

8 2 Plaformen für humanoide Roboter

Ausschlaggebendes Erkennungsmerkmal von humanoiden Robotern ist der Gang auf zwei Bei- nen. Der Auau des Gesamtsystems ist in der Regel stark dem des menschlichen Körpers nach- empfunden. So sind die Freiheitsgrade und Proportionen meist direkt vom Menschen abgelei- tet. Indem in der Informationsverarbeitung Prozesse ähnlich modelliert werden, wird versucht, die menschlichen Fähigkeiten nachzuahmen. Dies kann in unterschiedlicher Form geschehen, aber der grundlegende Auau der Roboter in der KidSize-Liga ist meist monolithischer Natur. Die Hauptrecheneinheit ist hier direkt mit Aktoren und Sensoren verbunden. Sie sammelt al- le Informationen und steuert das Gesamtsystem. Seit ungeähr sechs Jahren scheint aber ein Wechsel zu modularen Alternativen stazufinden. Hier ist vor allem erkennbar, dass Bewe- gungsaufgaben in eigene Systeme ausgelagert werden. Diese Systeme übernehmen unter an- derem bei zeitkritischen Situationen eigenständig die Kontrolle, um reflexartige Bewegungen, wie zum Beispiel das Abstützen mit einer Hand beim Sturz, auszuühren. Mit der Auslage- rung derart primitiver Aufgaben kann sich das Hauptsystem komplexeren Herausforderungen widmen.

Das Team Dribblers der TU Darmstadt ist in Zusammenarbeit mit Hajime Research erstmals beim Robocup 2006 mit einem solchen Ansatz angetreten[5]. Hierzu wurde ein Mikrocontroller- System mit einer Echtzeitsteuerung und -regelung entwickelt[19]. CIT Brains folgte, wieder in Kooperation mit Hajime Research 2008[4]. Das Team Darwin von Virginia Tech zog mit dem Darwin VI 2010 nach[22].

2.1 Grundlegender Aufbau

Plaformen humanoider Roboter definieren sich durch Soware- und Hardware-Architektur sowie durch die mechanische Konstruktion des Roboters. Die Grundkonstruktion eines sol- chen Roboters besteht in mechanischer Hinsicht meist aus Metall- oder Kunststoffverbindun- gen. Das FUmanoid-Modell aus dem Jahre 2009 wurde zum Beispiel aus PVC⁴ gefertigt[9, S. 35]. Im grundlegenden Auau eines Roboters stellen die Gelenke die Freiheitsgrade der Plaform dar. Diese bilden gleichzeitig auch die einzigen, voneinander unabhängigen Bewegungsmög- lichkeiten. Die Gelenke werden von sogenannten Aktoren gesteuert. Bei den Humanoiden im Robocup werden als Aktoren meist elektrische Servos des Typs Dynamixel der Firma Robotics eingesetzt. Diese können in einem 300°-Winkel Positionen ansteuern. Diese Servos verügen

⁴Polyvinylchlorid

9 2 Plaformen ür humanoide Roboter jeweils über eine eigene Steuereinheit und sind über ein Bus-System mit der Hauptrechenein- heit verbunden[16]. Des Weiteren besitzt ein Roboter verschiedene Arten von Sensoren. Neben Gyroskopen zur Lagebestimmung - sowie möglichen Fußsensoren - ist jeder Roboter mit einer Kamera ausgestaet. Mit Hilfe dieser Sensoren und Aktoren ist es möglich, alle Informationen über das Gesamtsystem zu sammeln und so ein Weltmodell zu berechnen. Auf Basis dieses Mo- dells können dann konkrete Verhaltensentscheidungen getroffen werden. Im Fußball könnte ein liegender Roboter anhand der Aktoren, sowie Sensoren erkennen, dass er gestürzt ist und versuchen, selbstständig wieder aufzustehen. Ähnlich könnte bei der Lokalisierung des Balles das Verhalten zur Balleroberung ausgeührt werden.

Abbildung 2.1: FUmanoid-Plaform 2011 in verschiedenen Montierphasen

Das neu entworfene FUmanoid-Modell aus dem Jahre 2011 ist 60cm groß und wiegt 4.8kg. Die 21 Freiheitsgrade des Roboters werden durch Servos der Dynamixel-Reihe RX-64 und RX- 28 aktuiert[10, S. 26]. Hiervon befinden sich jeweils sieben in den Beinen sowie drei in den Armen und einer im Kopf des Roboters. Als Sensoren kommen neben einer USB-Kamera der Firma Logitech mit einer Fischaugenlinse noch ein Gyroskop sowie zwei Fußdrucksensoren zum Einsatz[10, S. 29].

2.2 Monolithische Basisarchitektur

Bei humanoiden Roboterplaformen kann unter einem monolithischen Konzept die zentrale Art der Informationsverwaltung verstanden werden. Hierbei werden alle Informationen an ei- ner zentralen Stelle gesammelt und ausgewertet. Auf dieser Basis kann das System nun reagie- ren. Deshalb sind die Sensoren, wie Kamera oder Aktoren, direkt an die Hauptrecheneinheit angeschlossen und werden nur von dieser gesteuert. Hierdurch ist die Komplexität im Vergleich zu modularen Alternativen deutlich geringer, da asynchrone Nebeneffekte – architektonisch

10 2 Plaformen ür humanoide Roboter bedingt – deutlich eingeschränkt sind. Nachteilig wirkt sich die Zentralität auf die Geschwin- digkeit des Gesamtsystems aus. Informationen können schwer vorgefiltert, angereichert oder parallel verarbeitet werden, da nur ein übergeordnetes System alle Aufgaben übernimmt.

Die FUmanoid-Plaform aus dem Jahre 2009 verfolgte den monolithischen Ansatz. Hierbei kam ein Verdex XL6P-Mainboard mit einem PXA270-Prozessor mit 600 MHz zum Einsatz. Das Board verügt über 128MB RAM- und 32MB Flashspeicher. Jegliche Aktoren und Sensoren, mit Ausnahme der Kamera, waren über eine serielle Schnistelle auf Basis des RS485-Protokolls verbunden. Sowareseitig wurden Aufgaben wie Objekterkennung oder das Laufen miels reads pseudoparallelisiert.

Abbildung 2.2: FUmanoid-Plaform 2009 - Kommunikation

2.3 Entwicklung zu mehrstufigen Kontrollarchitekturen

Schon Ende der neunziger Jahre mehrten sich in der künstlichen Intelligenz-Forschung die Stimmen derer, die darauf hinwiesen, dass Menschen keineswegs eine monolithische, zentrale Kontrollinstanz besitzen[2, S. 54]. Menschen verügen vielmehr über unterschiedliche Steue- rungsinstanzen, die zum Teil unabhängig voneinander funktionieren. Vor diesem Hintergrund war es nur folgerichtig, dass Rojas doppel- oder gar dreistufige Kontrollarchitekturen bei kom- plexen intelligenten Systemen vorgeschlagen hat[17, S. 4]. Diese sollten aus den folgenden Stufen bestehen:

1. Kognitive Module ür das Planen und Erkennen,

2. Heuristiken ür schnelle zeitkritische provisorische Bewertungen,

3. Module ür reaktives Verhalten und ür die sensomotorische Kopplung.

Für das reaktive Verhalten der sensomotorischen Kopplung sowie ür die Berechnung von Heu- ristiken bietet sich eine Auslagerung an. Das geschieht über die Einührung eines weiteren Systems. Dieses wird zwischen Aktoren sowie Sensoren und dem bisherigen Kontrollsystem in der Kommunikationskee gesetzt, wie in Abbildung 2.3b dargestellt. Dieses System kann nun

11 2 Plaformen ür humanoide Roboter selbstständig Sensoren auslesen und gegebenenfalls Aktoren steuern. Eine zweistufige Kon- trollarchitektur könnte folgende Aufgabenverteilung haben:

1. Hauptsystem ür Wahrnehmung, Modellierung sowie ür Verhaltensentscheidungen,

2. ausgelagertes System ür provisorische Bewertungen, reaktives Verhalten und sensomo- torische Kopplung.

Ein entscheidende Vorteil bei dieser Lösung besteht darin, dass Reflexe, also mechanisch ablau- fende Reiz-Reaktions-Beziehungen – wie zum Beispiel eine schützende Bewegung beim Fall des Roboters – eigenständig realisiert werden können. Des Weiteren ist auch einfaches Verhalten möglich. Im Gegensatz zu Reflexen muss hier das System selbstständig Informationen mitein- ander verknüpfen und so zu einer Entscheidung kommen. Mit Hilfe von Sensorinformationen kann zum Beispiel festgestellt werden, ob der Roboter am Boden liegt und so gegebenenfalls ei- ne Aufstehbewegung ausgeührt werden. Hierdurch kann das Gesamtsystem auch ohne höher- stufige Kontrolle bedingt autonom⁵ funktionieren. Dies ist nützlich wenn zum Beispiel durch Fehler in der Soware diese höherstufigen Systeme ausfallen. Ferner können Informationen vorgefiltert oder ausgewertet und gebündelt werden. Dies ist ür schnelle und zeitkritische Bewertungen hilfreich.

Nachteil hierbei ist freilich die gestiegene Komplexität des Systems. Ursachen ür Fehler kön- nen nicht mehr auf einfache Weise lokalisiert werden, da der Zustand des Systems von vielen Faktoren abhängen kann; die Kontrolle des Systems wird dementsprechend komplizierter.

(a) Monolithische Architektur (b) zweistufige Kontrollarchitektur

Abbildung 2.3: Unterschiedliche Architekturansätze ür humanoide Roboter

Zusätzliche Probleme wie Materialermüdungserscheinungen bei der FUmanoid-Plaform aus dem Jahre 2009 sowie der Erfolg anderer Teams mit mehrstufiger Kontrollarchitektur aus der Humanoid League, waren weitere Gründe ür einen Plaformwechsel. Als Basis der neuen Architektur sollten ferner ein deutlich leistungsstärkerer Hauptrechner sowie ein neues Sys-

⁵komplexe Verhaltensentscheidungen sind weiterhin Aufgabe höherstufigen Systemen

12 2 Plaformen ür humanoide Roboter tem ür die Aktorik und Sensorik zum Einsatz kommen. Für die Auslagerung sollte ein neues Mikrocontroller-System entwickelt werden.

Die vorliegende Arbeit steht in Zusammenhang mit dem Plaformwechsel. Ihre Aufgabe be- stand darin, die ersten Schrie ür eine Auslagerung der Aktorik auf Basis eines solchen Mikrocontroller- Systems zu realisieren. Zwar wurde die bisherige hierarchische Grundarchitektur hierbei nicht in Frage gestellt. Aber durch das neue Subsystem sollte sie relativiert und das Gesamtsystem optimiert werden.

13 3 Hardware

3.1 Anforderungsanalyse

Bei der Anforderungsanalyse muss berücksichtigt werden, dass die Sowaremigration auf die neue Plaform in Teilschrien erfolgen soll. Daher muss das neue System rückwärtskompati- bel mit der FUmanoid-Plaform aus dem Jahre 2009 sein. Ferner soll der Mikrocontroller in der Lage sein, die Berechnungen in Echtzeit zu leisten. Des Weiteren muss dieser über eine Viel- zahl von Schnistellen verügen, da jegliche Kommunikation mit den Aktoren sowie Sensoren über den Mikrocontroller erfolgen soll.

Zusätzlich zu dem neuen Mikrocontroller-System wird das derzeit eingesetzte Verdex-System durch den deutlich leistungsstärkeren iGEPv2 ersetzt. Dieser verügt unter anderem über einen ARM Cortex A8-Prozessor mit einer Taktfrequenz von 1GHz und über 512MB RAM[7]. Ferner soll mit dem CHR-6D ein genaueres Gyroskop zum Einsatz kommen.

3.1.1 Kommunikation

Allgemein

In der Roboterarchitektur der FUmanoids aus dem Jahre 2009 steht der Verdex im Zentrum jeder Kommunikation. Mit der Auslagerung der Aktorik soll nun zu dieser zentralen Recheneinheit eine weitere Komponente dazu kommen. Das hat zur Folge, dass die Kommunikation mit den Aktoren oder Sensoren über das zu entwickelnde, zusätzliche Board laufen kann. Die bishe- rige Sterntopologie (3.1a) in der Kommunikationsarchitektur muss dadurch einer Baumstruk- tur (3.1b) weichen. Als Wurzelknoten kommt weiterhin das Hauptsystem, jetzt der iGEPv2, zum Einsatz. Dieses kann direkt mit der Kamera und dem Mikrocontroller-System und indirekt über jenes mit den Aktoren sowie den Sensoren (Gyroskop, Fußsensoren) kommunizieren. Mit der Auslagerung bleibt dennoch eine hierachische Kommunikationsstruktur erhalten. Diese ist notwendig, da nur das Hauptsystem ür komplexe Verhaltensentscheidungen verantwort- lich ist. Entscheidende Faktoren bei der Kommunikation sind vor allem Geschwindigkeit und Latenz.

14 3 Hardware

(a) alte Sterntopologie (b) neue Baumstruktur

Abbildung 3.1: Kommunikationsarchitekturen

Schnistellen

Die Schnistellen zur Kommunikation mit den Aktoren sowie den Sensoren ist bereits im Vor- feld festgelegt, da die Endgeräte nur über eine serielle Schnistelle auf Basis des RS485- bezie- hungsweise RS232-Protokolls verügen.

Typ System Kommunikationssnittstelle Aktoren Dynamixel RX-64 und RX-28 RS485 Gyroskop CHR-6D RS232 (TTL) Fußsensoren Eigenbau RS485

Tabelle 3.1: Kommunikationsschnistellen der eingesetzten Aktoren und Sensoren

Die Verbindung zwischen dem iGEPv2 und dem neuen Mikrocontroller-System kann dagegen über USB, Ethernet oder RS232 erfolgen [7]. Im Folgenden ein Überblick über die verschiedenen Kommunikationsarten:

USB USB⁶ ist ein universelles Bussystem der Firma Intel, das ältere Industriestandards wie RS232 oder PS/2 ersetzen und vereinheitlichen soll. Bei einem USB-Bus gibt es immer nur einen Host und bis zu 127 Endgeräte. Das iGEPv2 verügt über einen USB 2.0-Host- Controller. Dieser unterstützt Datenraten von bis zu 480 MBit/s. Ein USB-System kom- muniziert auf Basis von Paketen. Es verügt über folgende, unterschiedliche Übertra- gungsmodi:

Isochroner Transfer Datenübertragung mit garantierten Datenraten[24, S. 44]

Bulk Transfer niedrig priorisierte zeitunkritische Datenübertragung[24, S. 52]

⁶Universal Bus System

15 3 Hardware

Interrupt Transfer asynchrone Datenübertragung[24, S. 48]

Hierbei eignet sich der Interrupt-Mode am ehesten ür die Datenübertragung zwischen iGEPv2 und dem Mikrocontroller-System, da nur dieser zur Übertragung von kleinen Da- tenmengen mit möglichst geringer Latenz ausgelegt ist. In diesem Übertragungsmodus können bis zu 1024 Byte bis zu dreimal je 125µs übertragen werden [24, S. 51]. Abhängig ist dies vor allem von der Belegung des Bus-Systems.

Ethernet Ethernet ist die vorherrschende Technologie, die derzeit in Netzwerken wie dem Internet eingesetzt wird. Ethernet ist adressbasiert und ermöglicht unter Zunahme von weiteren Hardwarekomponenten einer Vielzahl von Knoten miteinander zu kommuni- zieren. Das Protokoll basiert auf sogenannten Frames, die Metainformation sowie die Da- ten selbst beinhalten. Zur Übertragung der Frames lauscht der Sender auf dem Medium und versucht mit Hilfe des CSMA/CD-Algorithmus⁷ die Daten erfolgreich zu übertragen. Das iGEPv2 verügt über einen RJ45-Anschluss, der sowohl 10Base-T als auch 100Base- TX unterstützt, und somit bis zu 10 MB/s beziehungsweise 100 MB/s übertragen kann. Ethernet stellt die unterste Schicht des TCP/IP-Schichtenmodells dar. Im Folgenden wird Ethernet daher nur in Anwendung dieses Modells verwendet.

RS232 Eine der ältesten Techniken bei der Datenübertragung ist die serielle Übertragung auf Basis des RS232-Protokolls. Hierbei kann nur zwischen zwei direkt verbundenen Knoten asynchron kommuniziert werden. Die Übertragung selbst erfolgt auf Basis von Wörtern in Form von Bits. Die Synchronisierung erfolgt über Start- und Stopbits.[6, S. 723] RS232 selbst ist bis zu gewissen Datenraten echtzeitähig. Das iGEPv2 verügt über zwei serielle RS232-Anschlüsse, die Geschwindigkeiten bis zu 2 MBaud (2 MBit/s) unterstützen.

RS485 Eine weitere Technik bei der seriellen Übertragung stellt das RS485-Protokoll dar. Hier- bei handelt es sich um ein Bus-System, das bis zu 32 Knoten miteinander kommunizieren lässt. Die Übertragung ist deutlich resistenter gegenüber Rauschen im Kommunikations- kanal, da hier die Daten, ähnlich wie bei USB, redundant in zwei Kanälen (normal und invertiert) übertragen werden. Die Kommunikation ist aber im Unterschied zu RS232 nur halbduplexähig. [6, S. 726] Der RS485-Hardware-Chip im iGEPv2 unterstützt Geschwin- digkeiten bis zu 250 Kb/s [7, S. 22].

Geswindigkeitsverglei

Um die Kommunikationsarten USB, TCP/IP, RS232 und RS485 vergleichen zu können, wird als Beispiel die Übertragung von drei Paketen mit je 5, 10 beziehungsweise 15 Byte an Nutzdaten gemessen:

1. USB Da USB 2.0 im Highspeed-Mode unterstützt wird, können per Interrupt-Verfahren je-

⁷ Carrier Sense Multiple Access/Collision Detection

16 3 Hardware

weils bis zu dreimal je 125µs bis zu 1024Byte übertragen werden. Für die Übertragung der drei Beispielpakete würde dies mindestens 42µs in Anspruch nehmen.

2. Ethernet - TCP/IP Bei der Übertragung von Daten bei TCP/IP müssen diese zuerst in TCP-Pakete verpackt werden. Diese werden selbst in ein oder mehrere IP-Pakete und diese nochmals in meh- rere Ethernet-Frames aufgeteilt. Dies hat zur Folge, dass deutlich mehr Daten übertra- gen werden müssen. Konkret sind dies ür das TCP- und IPv4-Paket jeweils zusätzlich 20 Byte. Bei Ethernet-Frames ist dies ein wenig komplizierter, da diese eine feste Länge von 64 Byte haben. Hierbei sind aber nur 46 Byte Nutzdaten. Die Übertragung von 5, 10 und 15 Byte würde bei 10 MB/s nur 32µs dauern.

a) 5-Byte-Paket

5 (Daten) + 40 (Overhead) = 45 Byte

→ 64B 64 MB = 10 µs = 6, 4µs 10 s

b) 10-Byte-Paket

10 (Daten) + 40 (Overhead) = 50 Byte > 46 Byte → 2 Frames nötig

→ 128 128 MB = 10 µs = 12, 8µs 10 s

c) 15-Byte-Paket

15 (Daten) + 40 (Overhead) = 55 Byte > 46 Byte → 2 Frames nötig

→ 128 128 MB = 10 µs = 12, 8µs 10 s

Übertragungsdauer: 6, 4µs + 12, 8µs + 12, 8µs = 32µs

3. RS232 Beim RS232-Protokoll können Daten mit variabler Länge direkt übertragen werden. Dies geschieht byteweise, jeweils markiert mit einem Start- und Stopbit. Darüber hinaus kann ein Parity⁸-Bit zur Fehlerkorrektur angehängt werden. [6, S. 722] Auf solch ein Bit wird in dieser Berechnung aber verzichtet. Die maximale Übertragungsrate beim iGEPv2 liegt bei 2MBaud.

40b+80b+120b 240µs 2Mbps = 2 = 120µs

4. RS485 Hier werden die Daten hardwareseitig über die serielle Schnistelle in das RS485-Protokoll

⁸gerade oder ungerade Anzahl der 1en im Wort

17 3 Hardware

übersetzt. Die Rechnung ist somit analog zu RS232 mit dem Unterschied, dass die Dynamixel- Aktoren sowie der iGEPv2 eine maximale Geschwindigkeit von 1 MBaud beziehungswei- se 250Kb/s unterstützen.

240b Aktoren 1Mbaud = 240µs

240b 240 iGEPv2 Kb = 250 ms = 0.96 = 960µs 250 s

5. Verdex (RS485) Für die bisher eingesetzte Verdex-Plaform mit der maximal möglichen Datenübertra- gungsrate von 181818 Baud[20, S. 14] seien zur Vollständigkeit halber die einschlägigen Informationen genannt:

240b 181818bps = 1320µs

Es ist leicht erkennbar, dass TCP/IP die schnellste Möglichkeit darstellt, Daten zu übertragen. Knapp dahinter folgt USB. Diese beiden Übertragungstechniken sind bis zu viermal schnel- ler als die seriellen Alternativen. Jedoch ist die Komplexität und damit die Vielfalt möglicher Komplikationen bei diesen Varianten weit höher.

Angemerkt sei hier, dass es sich bei den Angaben um theoretische Übertragungsgeschwindig- keiten handelt. Die echte Übertragungszeit ist unter anderem stark vom Betriebssystem von Sender und Empänger sowie von Übertragungsfehlern abhängig.

Tenik Übertragungsgeswindigkeit Zeit TCP/IP (iGEPv2) 10MB/s 32µs USB 2.0 - Interrupt Mode (iGEPv2) 1024 Byte bis zu 3x je 125µs mind. 42µs ür 3 Pakete RS232 (iGEPv2) 2MBaud 120µs RS485 (Aktoren) 1MBaud 240µs RS485 (iGEPv2) 250Kb/s 960µs RS232 (Verdex) 181818 Baud 1320µs

Tabelle 3.2: Geschwindigkeitsvergleich verschiedener Kommunikationsarten ür 3 Pakete je- weils mit 5, 10 und 15 Bytes Nutzdaten

3.1.2 Leistung und Peripherie

Ein weiterer wichtiger Faktor ist die Leistung des neuen Systems. Zuerst muss gewährleis- tet werden, dass die Kommunikationsarten überhaupt als Peripherieeinheit oder in der CPU selbst unterstützt werden. Des Weiteren muss das neue System in der Lage sein, Aktoren und Sensoren selbstständig zu steuern beziehungsweise auszulesen. Hier ist vor allem das Steuern der Aktoren ein Problem, da bei einer umfangreichen Auslagerung der Aktorensteuerung eine Vielzahl von mathematischen Operationen nötig ist. Als Beispiel sei hier nur die Berechnung

18 3 Hardware der Kinematik ür den Laufalgorithmus genannt. Die mathematischen Operationen sind vor allem bei kleineren Prozessoren sehr rechenaufwendig, da die nötige Hardwareunterstützung o fehlt. Weiterhin muss der Overhead, der durch den zusätzlichen Knoten im Kommunikati- onsweg verursacht wird, möglichst klein gehalten werden. Die Leistung des Systems ist ferner nicht nur von Takt und Hardwarebeschleunigung abhängig, sondern auch von weiteren Fak- toren, wie Adressierung oder Befehlssatz.

Im Folgenden eine Auswahl von populären Mikroprozessor-Systemen, die geeignet erscheinen, die Hardware-Anforderungen zu erüllen:

Arduino Uno Das -Projekt hat es sich zur Aufgabe gemacht, eine möglichst einfache und billige Mikrocontroller-Plaform zu realisieren. Die Basis hierür ist ein ATMega328- Mikrocontroller der Firma Atmel. Dies ist ein 8-Bit-Prozessor mit eigenem RISC⁹-Befehlssatz und einer Taktrate mit bis zu 16MHz. Beim Arduino Uno sind noch 32KB Flash sowie 2KB RAM verbaut. Es werden folgende Schnistellen unterstützt: USB, SPI, I²C[1]. So- wohl Platinenlayout, als auch die komplee Soware sind unter freien Sowarelizenzen veröffentlicht.

MSP430 Launchpad Mit dem MSP430 Launchpad versucht die Firma an den Erfolg der Arduino-Plaform anzuknüpfen. Die Launchpad-Plaform zeichnet sich durch sehr preiswerte und extrem stromsparende Mikrocontroller-Systeme aus. Der MSP430 ist ein 16-Bit-RISC-Mikrocontroller, der mit einer Taktrate mit bis zu 16 MHz betrieben werden kann. Je nach Konfiguration verügt das System über 128 bis 512 Byte RAM sowie über 2KB Flashspeicher. Neben I²C und SPI, wird auch eine serielle Schnistelle unterstützt. [13]

STM32 H107 Mit dem STM32 H107 von STMicroelectronics wurde exemplarisch ein System ür die Cortex Mikroprozessorreihe von ARM ausgewählt. Hier ist als Prozessor ein Cor- tex M3 verbaut. Dies ist ein 32-Bit-RISC-Mikrocontroller der mit einer Taktrate von bis zu 72MHz betrieben werden kann. Des Weiteren verügt die Plaform über eine große Anzahl von bereits integrierten Peripherieeinheiten. Das STM32 H107 ist mit über 256KB Flash- und 64KB RAM-Speicher ausgestaet. Es wird mit USB, UART, Ethernet, SPI und CAN eine Vielzahl von Kommunikationsschnistellen unterstützt. [21]

3.1.3 Auswahlprozess

Dhrystone-Benchmark Die Leistung der jeweiligen Plaform wurde anhand des bekann- ten Dhrystone-Benchmarks in der Version 2.1 aus dem Jahre 1988 von Reinhold P. Wecker ge- messen[26]. Dieser zeichnet sich durch seine hohe Portabilität aus. Er basiert auf der Analyse von alltäglich eingesetzten elltexten aus dem Jahre 1984, um so repräsentative Benchmark-

⁹reduced instruction set

19 3 Hardware tests erstellen zu können. Das Ergebnis wird unter anderem in sogenannten DMIPS¹⁰/MHz angegeben. Hier wird der erreichte Dhrystone-Wert pro 1MHz berechnet und durch 1757 ge- teilt. Der Divisor steht hier ür die VAX 11/780, die sich als Referenzmaschine etabliert hat. Anzumerken ist, dass im Gegensatz zum Whetstone-Benchmark keine Berechnung von Gleit- kommaarithmetik in die Bewertung mit einfließt.

Arduino Uno Der ATMega328 arbeitet bei der Arduino-Plaform mit 16 MHz. Der Dhrystone- Benchmark wurde selber auf Basis des elltextes von Wecker auf den ATMega328 por- tiert. Hier erzielte der Arduino Uno 643, 8 Dhrystones per Second und somit 0, 366 DMIPS/MHz.

Abbildung 3.2: Dhrystone-Benchmark 2.1 - Arduino Uno DhrystoneBenchmark,Version2.1(Language:C) Registeroptionnotselected. Microsecondsforoneloop:38 Dhrystonespersecond: 643.8 VAXMIPSrating: 0.366

MSP430 Der MSP430 kann mit einer maximalen Taktfrequenz von 16MHz betrieben werden. Texas Instruments hat im Application Report - MSP430 Competitive Benchmarking den MSP430 unter anderem im Dhrystone-Benchmark 2.1 mit anderen Mikroprozessorar- chitekturen verglichen. Hier kommt der MSP430 bei 100 Iterationen[8, S. 29] auf 98039 cycle counts[8, S. 13] und somit auf 0, 58 DMIPS/MHz.

98039 Cycles per Iteration: 100 = 980, 39

1 MHz Dhrystone per Second: 980,39 = 1020

→ 1020 1757 = 0, 58 DMIPS/MHz

STM 32 H107 Laut Datenbla[21, S. 3] kann der Cortex M3 mit einer maximalen Taktfre- quenz von 72MHz betrieben werden. Im Dhrystone 2.1-Benchmark erreicht dieser 1.25 DMIPS/MHz.

Im Folgenden eine Zusammenfassung der Ergebnisse ür die einzelnen Plaformen:

Plattform DMIPS/MHz Takt (MHz) Wortbreite (Bit) Cortex M3 1.25 72 32 MSP430 0.58 16 16 ATMega328 0.366 16 8

Tabelle 3.3: Dhrystone-Benchmark

¹⁰Dhrystone million instructions per second

20 3 Hardware

3.1.4 Entwicklungsboard - STM32 H107

Bei den vorhergegangenen Benchmarkergebnissen sticht der Cortex M3 stark heraus. Anzumerken sind auch die vielen im Prozessor integrierten Peripherieeinheiten. Einzig allein das STM32 H107 verügt über alle Schnistellen des iGEPv2. Hier- durch ist eine freie Auswahl des Kommunikationsmediums ge- währleistet. Mit 1.25 DMIPS/MHz erreicht die Plaform mehr als doppelt so viele Punkte wie der MSP430 und sogar fast drei- mal soviel wie der Arduino Uno. Kombiniert mit der deutlich höheren, maximal möglichen Taktfrequenz scheint das STM32 Abbildung 3.3: STM32 H107 H107 die Anforderungen an das neue System zur Steuerung der Aktoren am besten zu erüllen. Mit Hilfe der SPI-Schnistelle ist es außerdem möglich, SD- Karten als Speichermedium anzuschließen. Dies ist vor allem ür das Laden und Speichern von Konfigurations- oder Logdateien hilfreich.

Zu einem ähnlichen Ergebnis scheint auch das Team Darwin gekommen zu sein, das mit der neuesten Darwin-Generation von der Arduino-Plaform auf die Cortex M3 Technologie von ARM gewechselt hat[22][23].

Kommunikation Die Kommunikation in Richtung Aktoren und Gyroskop ist mit einem RS485-Bus sowie einer RS232-Leitung bereits festgelegt (siehe Abbildung 3.1). Da das STM32 H107 über alle Schnistellen des iGEPv2 verügt, kann hier frei zwischen TCP/IP, USB und seriellen Alternativen gewählt werden.

Wie die Tabelle 3.2 zeigt, erreicht TCP/IP die besten Ergebnisse bezüglich Übertragungszeit und Latenz. Dennoch eignet sich TCP/IP als Übertragungsart nur bedingt, da es einen kompleen Protokoll-Stack voraussetzt. Dieser Stack basiert auf einem umfangreichen Schichten-Modell und müsste auf dem zu entwickelnden Mikrocontroller-System komple neu implementiert werden. Dies erhöht den Aufwand enorm. Ferner ist die Ethernet-Schnistelle nicht über eine RJ45-Buchse erreichbar, sondern nur rudimentär über einzelne IO-Pins.

USB 2.0 liegt bei den Übertragungszeiten nur knapp hinter TCP/IP und ist im Gegensatz zu diesem als Schnistelle auf dem STM32 H107 nach außen geührt und somit ohne Hardware- Modifikationen benutzbar. Bei näherer Betrachtung zeigt sich, dass sich der Interrupt-Mode bei USB fundamental von herkömmlichen Implementierungen unterscheidet. Unterbricht bei ei- nem IRQ¹¹ normalerweise der Interrupt den Programmablauf, so ist dies bei USB nicht der Fall. Hier werden durch den USB-Host periodisch alle USB-Devices abgefragt, egal ob ein Interrupt aufgetreten ist und erst dann abgearbeitet. Es handelt sich hierbei um sogenanntes Polling¹². Dies hat zur Folge, dass zum einen das Kommunikationsmedium aktiv ausgelastet wird und

¹¹Interrupt Request ¹²aktives zyklisches Abfragen ür asynchrone Ereignisse

21 3 Hardware zum anderen sich die Latenz zur Übertragung der Daten erhöht. Der USB-Bus darf durch das Polling bis zu maximal 80% der Bandbreite ausnutzen. Zieht man in Betracht, dass neben dem STM32 H107 auch die Kamera über den USB-Bus kommuniziert, ist es schwer abschätzbar, in- wiefern die Bandbreite ür ein Echtzeitsystem hier ausreicht. [12]

Um die Komplexität des neuen Systems möglichst gering zu halten und auf bewährten Lösun- gen aufzubauen, wurde daher als Kommunikationsmedium zwischen dem STM32 H107 und dem iGEPv2 die serielle Übertragung auf Basis von RS232 gewählt. Im Vergleich zur Plaform aus dem Jahre 2009 kann hier die Geschwindigkeit von 181818 Baud theoretisch auf 2 MBaud erhöht werden und somit ein deutlicher Geschwindigkeitszuwachs sowie eine geringere La- tenz erzielt werden. Sollte sich USB dennoch als die bessere Alternative herausstellen, so ist ein Wechsel ohne Probleme im Nachhinein möglich.

Abbildung 3.4: Kommunikationsüberblick ür die neue FUmanoid Plaform (2011)

3.2 Entwurf

Obwohl das STM32 H107 eine Vielzahl von Peripherien mitbringt, müssen der RS485-Bus sowie die SD-Karte nachgerüstet werden. Um den Aufwand möglichst gering zu halten, wurde hierzu eine sogenannte Adapterplatine ür das Board entwickelt.

22 3 Hardware

3.2.1 Adapterplatine

Die Adapterplatine selbst wird miels Stecker über die zwei 40er-Pinreihen des STM32 H107 befestigt. Hierdurch kann die Adapterplatine alle nach außen geührten Pins des Entwickler- boards nutzen. Das finale Board-Layout ist in der Abbildung 3.5 zu sehen.

Abbildung 3.5: Überblick Adapter-Platine

3.2.2 SD-Karte

Um Daten auf einfache Art und Weise speichern und lesen zu können, wird eine SD-Karte verwendet. SD-Karten verügen über einen eigenen Logikbaustein und können über die Serial Periphal Interface-Schnistelle angesprochen werden. SPI ist ein Bus-System der Firma Moto- rola, welches das STM32 H107 von Haus aus unterstützt. Ähnlich wie USB basiert das Protokoll auf einem Master-Slave-Verfahren, wobei das STM32 H107 hier den Master übernimmt und die SD-Karte als Slave fungiert. Wann ein Device kommunizieren darf, wird über die sogenannte Chip-Select-Leitung geregelt. Jedes Device hat eine separate CS-Leitung, die vom Master kon- trolliert wird. Die Synchronisierung der Kommunikation erfolgt über die Source-Clock-Leitung. Diese ist theoretisch nicht festgelegt, und so sind deutlich höhere Übertragungsgeschwindig- keiten möglich als im Standard definiert. Die Datenübertragung ist vollduplexähig und erfolgt über die Master-In-Slave-Out- (MISO) sowie Master-Out-Slave-In-Leitungen (MOSI).

23 3 Hardware

Abbildung 3.6: SPI-Bus zwischen STM32 H107 und SD-Karte

3.2.3 RS485

Da es sich bei dem RS485-Protokoll um ein klassisches serielles Protokoll handelt, kann hier- ür die UART¹³ des Mikrocontrollers verwendet werden. Diese stellt eine serielle Schnistel- le in Form einer Peripherieeinheit dar. Die eigentliche Konvertierung erfolgt auf der Hard- wareebene. Weit verbreitet in der Industrie sind hier die Bausteine der Firma Maxim. Auf der Adapterplatine selbst kommt ein MAX481 zum Einsatz. Dieser verügt über zwei Eingän- ge jeweils ür das Senden beziehungsweise Empfangen sowie ür das RS485 typische A,B¹⁴- Ausgangssignal. Die Ausgangssignale werden mit dem eigentlichen RS485-Bus verbunden. Der Chip kann mit Geschwindigkeiten bis zu 2,5Mbps arbeiten. Laut Datenbla des STM32 H107 verügen die seriellen Ausgänge (UARTS) über einen möglichen Spannungspegel von 0 bis 3, 3V . Der MAX481 dagegen erwartet Transistor-Transistor-Logikspannungen (TTL): 0 bis 5V [11]. Deswegen müssen miels Spannungswandler die Spannungswerte angepasst werden. Hierzu wurde ein MAX3378-Spannungswandler[18] zwischen dem UART-Ausgang und dem MAX485 verwendet. Die Schaltung ist in Abbildung 3.7 abgebildet.

Abbildung 3.7: RS485-Anschluss

¹³Universal Asynchronous Receiver Transmier ¹⁴ invertiert und nichtinvertiert

24 3 Hardware

3.2.4 RS232

Die serielle RS232-Kommunikation des iGEPv2 arbeitet, ähnlich wie das MAX-Bauteil, mit an- deren Spannungswerten als das STM32 H107. Während der Mikrocontroller TTL-Spannungswerte erwartet, operiert der iGEPv2 auf den klassischen RS232-Spannungswerten. Aufgrund dessen ist eine Wandlung von den klassischen −12 bis +12V zu 0 bis 5V (TTL) von Nöten. Hierür kommt ein MAX3225 zum Einsatz. Da der STM32 H107 nur über eine Spannungsversorgung von 5V verügt, muss über sogenannte Spannungspumpen ein bis an 12V annähernder Span- nungswert generiert werden. Für die Spannungspumpen selbst sind vier zusätzliche Konden- satoren erforderlich. Der MAX3225 kann mit Geschwindigkeiten von bis zu 1Mbps arbeiten. Damit reduziert sich die maximal mögliche Übertragungsrate zwischen iGEPv2 und STM32 H107 auf 1Mbps.

Abbildung 3.8: RS232-Logik zwischen iGEPv2 und STM32 H107

25 3 Hardware

Die zweite serielle Schnistelle des STM32 H107 wird vom Gyroskop verwendet. Als Gyroskop kommt das CHR-6D von CH Robotics zum Einsatz. Hier sind keine weiteren Bauteile nötig, da die serielle Kommunikation auf Basis der Transistor-Transistor-Logik funktioniert und somit direkt mit einer UART des STM32 H107 verbunden werden kann[3].

26 4 Sowareentwicklung

4.1 Sowareanforderungen

Die Anforderungen an die Soware sind vielältig. Zum einen muss die Soware plaformun- abhängig sein, da sie auch zu Simulationszwecken außerhalb des Mikrocontroller-Systems ein- gesetzt werden soll. Zum anderen sind Aspekte wie Echtzeitähigkeit, Modularität sowie Wart- barkeit von hoher Bedeutung.

4.1.1 Plaformunabhängigkeit

Um eine hohe Portabilität zu gewährleisten, ist die Plaformunabhängigkeit unabdingbar. Die Entwicklung ür eine andere Architektur als die des Hostsystems kann einen deutlichen Mehr- aufwand bedeuten. Ist zum Beispiel keine Emulations- oder Virtualisierungslösung ür die Ziel- plaform vorhanden, so muss der elltext miels Cross-Compiler ür die neue Architektur kompiliert und auf das System übertragen werden. Erst dann kann die Soware auf Korrektheit getestet werden. Um diesen Mehraufwand zu minimieren, ist es ratsam, plaformunabhängige Schnistellen in die Sowarearchitektur fest zu integrieren. Dadurch kann die Entwicklung des Systems beschleunigt werden und nebenbei das System auf einfache Art und Weise auf neue Plaformen portiert werden. Als weitere Plaform ist hier der Simulator der Fußballro- boter zu nennen. Es muss möglich sein, die Soware in diesen Simulator, beispielsweise als Bibliothek, einbinden zu können.

4.1.2 Echtzeitfähigkeit

Als Echtzeitsystem wird innerhalb des Systems das Einhalten von gewissen Zeitintervallen zur Bearbeitung von Aufgaben gesehen. Auch bei der Aktorik ist dies ein entscheidender Fak- tor, da Bewegungen in Einzelschrie unterteilt werden. Werden keine oder nur manche Teil- schrie ausgeührt, kann es zu unvorhersehbaren Bewegungsabläufen und so zum Beispiel zum Umfallen des Roboters kommen. In Echtzeitsystemen muss neben der logischen Korrekt- heit somit auch zeitliche Korrektheit gewährleistet werden[25, S. 317]. Zeitlich korrekt ist ein System, wenn es ein Ergebnis oder eine Aufgabe immer rechtzeitig liefern beziehungsweise er- üllen kann. Jene Rechtzeitigkeit definiert sich durch eine diktierte Zeitbedingung[25, S. 318].

27 4 Sowareentwicklung

Es wird je nach Kriterium ür die Zeitbedingung von unterschiedlichen Echtzeitsystemen ge- sprochen[25, S. 312]:

Harte Echtzeit Zeitbedingungen müssen mit allen Mieln eingehalten werden. Sollte dies nicht passieren, können Schäden die Folge sein.

Feste Echtzeit Können gewisse Zeitbedingungen nicht eingehalten werden, so sind nicht mögliche Schäden die Folge, sondern die Aktion selbst ist wertlos und kann abgebro- chen werden.

Weiche Echtzeit Die Zeitspanne darf in einem vorher fest definierten Intervall überschrien werden ohne dass dies Folgen ür das System häe.

Die Anforderung an die Aktorik ist, dass Aufgaben innerhalb eines Zeitintervalls zwischen Empfang und einer Deadline garantiert ausgeührt werden müssen. Es reicht also aus, weiche Echtzeit zu garantieren.

4.1.3 Fehlerdiagnose und Wartbarkeit

Mit der Einührung eines weiteren Subsystems ist die Komplexität des Gesamtsystems stark gestiegen. Aufgrund dessen sind Probleme nicht mehr so einfach zu lokalisieren, da diese ver- schiedenen Ursprungs sein können. Es ist somit wichtig, dass im neuen System Fehler leicht gefunden und behoben werden können. Des Weiteren ist die Wartbarkeit von hoher Bedeutung. Neue Sowareversionen müssen ohne viel Aufwand auf das neue System aufgespielt werden können.

4.1.4 Asynchronität

Da periodische und aperiodische Ereignisse aureten, muss das System Asynchronität aufwei- sen[25, S. 338]. Zu periodischen Ereignissen gehört zum Beispiel das Lesen von Gyroskopwer- ten, während zu aperiodischen Ereignissen zum Beispiel das Setzen und Lesen von Motorwer- ten gehört. Das System soll Ereignisse reaktiv abarbeiten. Mithilfe der Asynchronität soll ein flexibler, dem aktuellen Bedarf angepasster Programmablauf möglich sein.

4.1.5 Modularität

Da sich Komponenten innerhalb der Roboter-Plaform schnell ändern können, ist es notwen- dig, dass das System eine hohe Modularität aufweist. Hierdurch kann flexibel auf die Wei- terentwicklung der Plaform reagiert werden, da nur einzelne Module ausgetauscht werden

28 4 Sowareentwicklung müssen. Wichtig wäre dies vor allem im Bezug auf die einzelnen Sensoren, wie zum Beispiel dem Gyroskop.

4.2 Implementierung

Die Implementierung ist schriweise realisiert worden. Das Ziel bestand darin, eine funktio- nierende Proxy-Lösung¹⁵ zu implementieren. Das STM32 H107 wird hierzu zusammen mit der Adapterplatine zwischen die bisherige Kommunikationskee gesetzt. Des Weiteren wurde ein Modul entwickelt, das statische Key-Frame¹⁶-Motions abspielen kann. Mit Hilfe dieses Moduls ist das neue System in der Lage, selbstständig statische Bewegungen auszuühren und so zum Beispiel nach einem Sturz den Roboter wieder aufstehen zu lassen.

4.2.1 Architektur

Die Architektur ist stark generisch konzipiert. Jegliche plaformspezifische Implementierung wurde miels Schnistellen ausgelagert. Jene Schnistellen bestimmen somit eine System- API¹⁷, die ür jede Zielarchitektur neu implementiert werden muss. Während in den POSIX- kompatiblen Betriebssystemen alle Datentypen und Bibliotheken vorhanden sind, mussten ür die ARM Cortex M3-Architektur Datenstrukturen und Standard-Bibliotheken angepasst wer- den.

Derzeit unterstützt das System folgende Plaformen:

• POSIX (Linux, Win32)

• ARM Cortex M3

Der Datenaustausch zwischen Modulen erfolgt in fest definierten Datenstrukturen.

4.2.2 Programmlogik

Die Programmlogik entspricht einer zyklischen Ablaufsteuerung[25, S. 339]. Hierbei werden Aufgaben sequentiell in einer Schleife ausgeührt. Um schnelle Datenverarbeitung zu gewähr- leisten, sind jegliche Transportaufgaben im ARM Cortex M3 mit Hilfe sogenannter Interrupt- routinen realisiert. Hier wird die Abarbeitung der Schleife unterbrochen, und empfangene Da- ten werden zwischengespeichert.

¹⁵Vermiler zwischen Aktoren und Hauptsystem ¹⁶Motorwerte ür jedes Frame ¹⁷Application programming interface

29 4 Sowareentwicklung

Abbildung 4.1: Soware-Architektur

Des Weiteren ist es möglich, ein einfaches autonomes Verhalten zu aktivieren. Dieses ist vor Laufzeit der Soware anpassbar und ührt entsprechende Aktionen beim Erreichen vordefi- nierter Sensorwerte aus. Eingesetzt wird dies vor allem ür das selbstständige Aufstehen des Roboters, wenn dieser am Boden liegt. Abspielbare Bewegungsabläufe müssen in einem spe- ziellen Key-Frame-Motion-Format vorliegen. Hierbei werden Werte ür die Aktoren statisch festgehalten und als Zeilen gespeichert. Das Motion-Modul setzt bei Ausührung die jeweili- gen Werte je Aktor Zeile ür Zeile in vorherdefinierten Zeitabständen.

4.2.3 Toolchain

Für alle Plaformen wurde die GNU Compiler Collection sowie der GNU Project Debugger ver- wendet. Hierdurch stehen Werkzeuge zum einfachen Kompilieren und Debuggen zur Verü- gung. Für das STM32 H107 muss neben dem GDB auch noch auf OpenOCD¹⁸ sowie JTAG¹⁹ als Anschluss zurückgegriffen werden. JTAG stellt einen Standard zum Debuggen von elektroni- scher Hardware da. Damit über GDB der Cortex M3-Prozessor diagnostiziert werden kann, müssen mit Hilfe von OpenOCD die Protokolle der jeweiligen Programme übersetzt werden.

¹⁸Open On-Chip Debugger ¹⁹Joint Test Action Group

30 4 Sowareentwicklung

Ferner wurde eine serielle Logging-Schnistelle implementiert. Die Implementierung selbst erfolgte auf Basis freier Soware und größtenteils in der hardwarenahen Programmiersprache C.

Als Standard-C-Bibliothek kommt bei der ARM-Architektur die portable newlib-Implementierung zum Einsatz. Vorteil von newlib ist, dass die gesamte Bibliothek nur auf einer Handvoll von System-Calls auaut. Nur diese müssen letztendlich ür neue Plaformen selbst implemen- tiert werden um eine vollständige Standard-C-Bibliothek zu bekommen. Als Firmware wurde libopencm3 verwendet. Dies ist eine Neuimplementierung der proprietären STM32 Firmware auf Basis freier Soware und stellt eine hardwarenahe Schnistelle ür den Cortex M3 zur Verügung.

31 5 Benchmark

5.1 Zugriffszeit

Um die neue Plaform anhand der Leistungsähigkeit mit der alten vergleichen zu können, wurde die Übertragungszeit bei Lese- und Schreibzugriffen gemessen. Hierzu wurde ein Bench- marktest erstellt, der schriweise die Übertragungsdauer der Pakete misst. Die FUmanoid- Roboterplaformen haben jeweils 21 Aktoren sowie 3 Sensoren verbaut; somit wurde schri- weise die Zeit ür bis zu 25 Aktoren gemessen. Um die Auswirkung bei Übertragungsfehlern möglichst gering zu halten, wurde jede Zeitmessung sechsmal durchgeührt und der Durch- schni dieser Werte als Ergebnis genommen.

·104 ·104 5 5 . 2009. . 2009. . . . . 4 2011 2011 4

3 3 µs µs

2 2 Zeit in Zeit in

1 1

0 . . 0 . . 0 5 10 15 20 25 0 5 10 15 20 25 Aktoren Aktoren (a) Lesezugriff (b) Lese- und Schreibzugriff

Abbildung 5.1: Benchmarkergebnisse Lese- und Schreibzugriff

Es ist leicht zu erkennen, dass der Anstieg bei Anhebung der Aktorenzahl unterschiedlich stark ür die jeweilige Plaform ausällt. Wird die Steigung der Geraden durch die jeweiligen Punkte berechnet, so ist diese ür die Plaform aus dem Jahre 2009 fast dreimal höher als die Plaform aus dem Jahre 2011. Das hat zur Folge, dass die neue Plaform anfangs nur mehr als doppelt so schnell als die Version aus dem Jahre 2009 ist. Bei 25 Aktoren bei Lese- und Schreibzugriffen beträgt der Unterschied mit 43ms ür die 2009er Plaform im Vergleich zu 2011 mit 15ms aber

32 5 Benchmark

schon fast dreimal soviel. Die zweistufige Lösung im Proxy-Betrieb ist somit deutlich im Vorteil gegenüber der Plaform aus dem Jahre 2009.

5.2 Laufalgorithmus

Die höchste Auslastung des Systems ist beim Laufen gegeben. Um jenen Prozess auf den bei- den Plaformen vergleichen zu können, wurde der Algorithmus des zweibeinigen Laufens von Kulick analysiert und auf dieser Basis ein weiterer Benchmark entwickelt. Der Algorithmus ist in sogenannte Ticks [10, S. 41] unterteilt. Diese haben einen Wertebereich von 0 bis 360 und stellen den aktuellen Zustand des Systems beim Ablauf eines Schries dar. In jedem Tick müs- sen Aktoren und Sensoren gelesen werden. Für das Lesen der aktuellen Position eines Aktors müssen 18 Byte übertragen werden. Das Setzen umfasst dagegen nur 9 Byte²⁰. Der Unterkörper der FUmanoid-Plaform hat 14 Aktoren sowie 3 Sensoren. Es müssen also mindestens 17 Le- sevorgänge sowie 14 Schreibvorgänge pro Tick ausgeührt werden. Der Benchmark ermielt die Anzahl der Ticks, die pro Sekunde maximal ausgeührt werden können. § ¤ 1 start = getCurrentTimeInMicroSeconds() 2 FOR x in 14: // Lese alle Aktoren 3 motor.read(x) 4 5 FOR x in 3: // Lese Sensoren 6 sensor.read(x) // (Gyroskop und zwei Fußsensoren) 7 8 FOR y in 14: // Setze neue Werte für die Aktoren 9 motor.write(y) 10 11 end = getCurrentTimeInUs(); 12 duration = end - start 13 iterations = 1000000 / duration 14 15 print ”Iterations / s: ” + iterations ¦ ¥

Abbildung 5.2: Benchmark in Pseudo-Code

Die Benchmarkergebnisse sind in der Tabelle 5.1 zu finden. Mit 105 Iterationen pro Sekunde kann dieser Algorithmus mit dem neuen Mikrocontroller-System mehr als doppelt so schnell ausgeührt werden als mit der Plaform aus dem Jahre 2009 (im Vergleich nur 40 Iteratio- nen pro Sekunde). Hierdurch können deutlich bessere Ergebnisse in Form von Stabilität und Geschwindigkeit ür das Laufen auf zwei Beinen auf Basis des Algorithmus von Kulick erzielt

²⁰8 Byte ür ein Instruction- (Anfrage) und 10 Byte ür das Status-Paket (Antwort)

33 5 Benchmark werden, da aufgrund der höheren Anzahl von Iterationen pro Sekunde die Reaktionsgeschwin- digkeit des Systems deutlich schneller als bei der alten Plaform ist.

Grund ür das gute Abschneiden der Plaform aus dem Jahre 2011 ist vor allem die erhöhte Übertragungsgeschwindigkeit. Diese konnte von 181818Baud auf 1MBaud mehr als verünf- facht werden. Dennoch bringt eine zweistufige Kontrollarchitektur bei weitem mehr Vorteile als eine erhöhte Übertragungsgeschwindigkeit. Zu nennen wäre hier vor allem die einfache Realisierung von reaktivem Verhalten sowie Vorberarbeitung von Sensorinformationen.

Plattform Dauer für eine Iteration Iterationen pro Sekunde FUmanoid 2009 (Verdex) 24823, 44µs 40 FUmanoid 2011 (iGEPv2) 9503, 08µs 105

Tabelle 5.1: Benchmarkergebnisse ür die verschiedenen FUmanoid-Plaformen

34 6 Fazit

Im Rahmen dieser Arbeit wurde eine neue Plaform ür humanoide Roboter realisiert. Wäh- rend die alte Plaform aus dem Jahre 2009 einen monolithischen Ansatz verfolgte, konnte mit der Auslagerung der Aktorik eine zweistufige Kontrollarchitektur umgesetzt werden. Hierzu wurde ein neues Mikrocontrollersystem entworfen, das zwischen der Hauptrecheneinheit und den Sensoren sowie den Aktoren arbeitet. Zwar ist die Architektur noch immer hierarchisch strukturiert, aber konnte mit der Auslagerung ein weiteres autonomes Subsystem realisiert werden. Dieses kann bis zu einem gewissen Grad selbstständig agieren. So kann der Roboter mit Hilfe des Subsystems zum Beispiel selbstständig nach einem Sturz aufstehen. Durch dieses Subsystem ist der Roboter in seinen Aktionsmöglichkeiten erheblich erweitert.

Hierzu wurde auf Basis des Entwicklerboards STM32 H107 eine Adapterplatine entworfen. Die- se verügt über alle erforderlichen Schnistellen zur Kommunikation mit den Aktoren, den Sensoren sowie dem iGEPv2. Des Weiteren musste eine echtzeitähige Sowarelösung entwi- ckelt und implementiert werden. Diese beinhaltet ein aktivierbares, einfaches Verhalten und arbeitet als Proxy-Lösung zwischen den Aktoren und dem iGEPv2.

Die Benchmarkergebnisse haben gezeigt, dass die neue Plaform zu einem starken Leistungs- zuwachs geührt hat. Dies ist zum einen in der Kommunikationsgeschwindigkeit spürbar, aber auch die Latenz konnte gesenkt werden. Mit der gewonnenen Leistung können nun in Zu- kun neue Algorithmen implementiert werden, die zu besseren Ergebnissen im Gesamtsystem ühren.

Die Bewegungsabläufe in ein autonomen System auszulagern erweist sich als eine wirkungs- volle und vielversprechende Alternative ür humanoide Roboter. Eine komplee Auslagerung unter Einschluss des Laufalgorithmus häe den Rahmen einer Bachelorarbeit bei weitem ge- sprengt. Offene Punkte bleiben die Portierung von dynamischen, sich selbst stabilisierenden Bewegungen, provisorische zeitkritische Bewertungen sowie eine stärkere Informationsvor- bearbeitung.

Insgesamt lässt sich festhalten, dass die neue zweistufige Architektur dem alten monolithischen Modell deutlich überlegen ist. Weitere Arbeiten zur Klärung der offenen Fragen werden zeigen, welche Möglichkeiten in der Auslagerung von Bewegungsabläufen liegen.

35 Literaturverzeichnis

[1] ATMega328 Datasheet. Atmel, 2011. [2] R. A. Brooks, C. Breazeal, M. Marjanović, B. Scassellati und M. M. Williamson. “e Cog project: Building a humanoid robot”. In: Lecture Notes in Computer Science. Springer- Verlag, 1999, S. 52–87. [3] CHR-6d Digital IMU. CH Robotics. [4] CIT Brains. Team Description Paper. 2008. [5] Darmstadt Dribblers & Hajime Team. Team Description Paper. 2006. [6] P. Horowitz und W. Hill. e Art of Electronics. New York, NY, USA: Cambridge University Press, 1989. [7] IGEPv2 BOARD Hardware Reference Manual. ISEE, 2.02.2011. [8] W. G. und Kripasagar Venkat. MSP430 Competitive Benchmarking. Techn. Ber. 2009. [9] M. Kukulski. “Entwurf und Bau einer humanoiden Bewegungsplaform ür Fußball spie- lende Roboter”. Diplomarbeit. FU Berlin, 2009. [10] J. Kulick. “Ein stabiler Gang ür humanoide, Fußball spielende Roboter”. Masterarbeit. FU Berlin, 2011. [11] Low-Power, Slew-Rate-Limited RS-485/RS-422 Transceivers. Maxim, 9/2009. [12] MICRO/SYS. White Paper: Interrupts and USB. [13] MSP430x11x - Mixed signal Microcontrollers. Texas Instruments, September 2004. [14] Robocup Federation. Robocup Objective. URL http://www.robocup.org/about-robocup/ objective/; besucht am 30.07.2012. [15] Robocup Federation. RoboCup Soccer Humanoid League - Rules and Setup. 2012. [16] Robotics Co Ltd. User’s Manual Dynamixel RX64 - v1.10. Techn. Ber. [17] R. Rojas. Die Angst des Roboters beim Elfmeter. URL http://www.heise.de/tp/artikel/ 35/35244/1.html; besucht am 30.07.2012. [18] RS-232 Transceivers. Maxim, 2/2011. [19] D. Scholz. “Modulare und plaformunabhängige dynamische Bewegungserzeugung ür autonome mobile humanoide Roboter”. Diplomarbeit. TU Darmstadt, 2008. [20] D. Seifert. “Portierung der FUManoid-Soware”. Studienarbeit. HU Berlin, 2009. [21] STM32-H107 development board - Users Manual. Olimex Ltd., 2011.

36 Literaturverzeichnis

[22] Team VT DARwIn. Team Description for Humanoid KidSize League of RoboCup. 2010. [23] Team VT DARwIn. Team Description for Humanoid KidSize League of RoboCup. 2011. [24] Universal Serial Bus Revision 2.0 specification. 2.0. Compaq, Hewle-Packard, Intel, Lu- cent, Microso, NEC, und Philips. Apr. 2000. [25] H. W. und Uwe Brinkschulte. Echtzeitsysteme: Grundlagen, Funktionsweisen, Anwendun- gen. Springer Verlag, 2005. [26] R. P. Wecker. “Dhrystone: A synthetic systems programming benchmark”. In: Commu- nications of the ACM. Bd. 27. ACM Press, Okt. 1984.

37 Abbildungsverzeichnis

1.1 KidSize-Roboter des Teams FUmanoids aus verschiedenen Jahren ...... 8 1.2 Robocup-Feld aus dem Simulator von Steffen Heinrich und Sebastian Mielke . 8

2.1 FUmanoid-Plaform 2011 in verschiedenen Montierphasen ...... 10 2.2 FUmanoid-Plaform 2009 - Kommunikation ...... 11 2.3 Unterschiedliche Architekturansätze ür humanoide Roboter ...... 12

3.1 Kommunikationsarchitekturen ...... 15 3.2 Dhrystone-Benchmark 2.1 - Arduino Uno ...... 20 3.3 STM32 H107 ...... 21 3.4 Kommunikationsüberblick ür die neue FUmanoid Plaform (2011) ...... 22 3.5 Überblick Adapter-Platine ...... 23 3.6 SPI-Bus zwischen STM32 H107 und SD-Karte ...... 24 3.7 RS485-Anschluss ...... 24 3.8 RS232-Logik zwischen iGEPv2 und STM32 H107 ...... 25

4.1 Soware-Architektur ...... 30

5.1 Benchmarkergebnisse Lese- und Schreibzugriff ...... 32 5.2 Benchmark in Pseudo-Code ...... 33

38