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 Eidesstaliche Erklärung
Ich versichere, die Bachelorarbeit selbstständig und lediglich unter Benutzung der angegebe- nen ellen und Hilfsmiel 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 Plaformen für humanoide Roboter 9 2.1 Grundlegender Auau ...... 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 Sowareentwicklung 27 4.1 Sowareanforderungen ...... 27 4.1.1 Plaformunabhä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 Schrie 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 Webewerb, 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 hae, ist milerweile auch auf andere Bereiche, wie zum Beispiel Such- und Reungs- 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 Wekampf 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 Webewerb 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 Plaformen für humanoide Roboter
Ausschlaggebendes Erkennungsmerkmal von humanoiden Robotern ist der Gang auf zwei Bei- nen. Der Auau 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 Auau 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 stazufinden. 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
Plaformen humanoider Roboter definieren sich durch Soware- 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 Auau eines Roboters stellen die Gelenke die Freiheitsgrade der Plaform 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 Plaformen ü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 ausgestaet. 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-Plaform 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 Roboterplaformen 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 Plaformen ü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-Plaform 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 Schnistelle auf Basis des RS485-Protokolls verbunden. Sowareseitig wurden Aufgaben wie Objekterkennung oder das Laufen miels reads pseudoparallelisiert.
Abbildung 2.2: FUmanoid-Plaform 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 Kommunikationskee gesetzt, wie in Abbildung 2.3b dargestellt. Dieses System kann nun
11 2 Plaformen ü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 Soware 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-Plaform aus dem Jahre 2009 sowie der Erfolg anderer Teams mit mehrstufiger Kontrollarchitektur aus der Humanoid League, waren weitere Gründe ür einen Plaformwechsel. 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 Plaformen ü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 Plaformwechsel. Ihre Aufgabe be- stand darin, die ersten Schrie ü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 Sowaremigration auf die neue Plaform in Teilschrien erfolgen soll. Daher muss das neue System rückwärtskompati- bel mit der FUmanoid-Plaform 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 Schnistellen 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
Schnistellen
Die Schnistellen zur Kommunikation mit den Aktoren sowie den Sensoren ist bereits im Vor- feld festgelegt, da die Endgeräte nur über eine serielle Schnistelle auf Basis des RS485- bezie- hungsweise RS232-Protokolls verügen.
Typ System Kommunikationssnittstelle Aktoren Dynamixel RX-64 und RX-28 RS485 Gyroskop CHR-6D RS232 (TTL) Fußsensoren Eigenbau RS485
Tabelle 3.1: Kommunikationsschnistellen 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].
Geswindigkeitsverglei
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 Schnistelle 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-Plaform 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.
Tenik Übertragungsgeswindigkeit 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 Arduino-Projekt hat es sich zur Aufgabe gemacht, eine möglichst einfache und billige Mikrocontroller-Plaform 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 Schnistellen unterstützt: USB, SPI, I²C[1]. So- wohl Platinenlayout, als auch die komplee Soware sind unter freien Sowarelizenzen veröffentlicht.
MSP430 Launchpad Mit dem MSP430 Launchpad versucht die Firma Texas Instruments an den Erfolg der Arduino-Plaform anzuknüpfen. Die Launchpad-Plaform 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 Schnistelle 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 Plaform über eine große Anzahl von bereits integrierten Peripherieeinheiten. Das STM32 H107 ist mit über 256KB Flash- und 64KB RAM-Speicher ausgestaet. Es wird mit USB, UART, Ethernet, SPI und CAN eine Vielzahl von Kommunikationsschnistellen unterstützt. [21]
3.1.3 Auswahlprozess
Dhrystone-Benchmark Die Leistung der jeweiligen Plaform 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-Plaform 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 Plaformen:
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 Schnistellen des iGEPv2. Hier- durch ist eine freie Auswahl des Kommunikationsmediums ge- währleistet. Mit 1.25 DMIPS/MHz erreicht die Plaform 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-Schnistelle 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-Plaform 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 Schnistellen 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 kompleen 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-Schnistelle 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 Schnistelle 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 Plaform 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 Plaform (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 miels 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-Schnistelle 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 Schnistel- 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 miels 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 Transmier ¹⁴ 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 Schnistelle 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 Sowareentwicklung
4.1 Sowareanforderungen
Die Anforderungen an die Soware sind vielältig. Zum einen muss die Soware plaformun- 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 Plaformunabhängigkeit
Um eine hohe Portabilität zu gewährleisten, ist die Plaformunabhä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- plaform vorhanden, so muss der elltext miels Cross-Compiler ür die neue Architektur kompiliert und auf das System übertragen werden. Erst dann kann die Soware auf Korrektheit getestet werden. Um diesen Mehraufwand zu minimieren, ist es ratsam, plaformunabhängige Schnistellen in die Sowarearchitektur fest zu integrieren. Dadurch kann die Entwicklung des Systems beschleunigt werden und nebenbei das System auf einfache Art und Weise auf neue Plaformen portiert werden. Als weitere Plaform ist hier der Simulator der Fußballro- boter zu nennen. Es muss möglich sein, die Soware 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 Einzelschrie unterteilt werden. Werden keine oder nur manche Teil- schrie 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 Sowareentwicklung
Es wird je nach Kriterium ür die Zeitbedingung von unterschiedlichen Echtzeitsystemen ge- sprochen[25, S. 312]:
Harte Echtzeit Zeitbedingungen müssen mit allen Mieln 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 überschrien 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 Sowareversionen müssen ohne viel Aufwand auf das neue System aufgespielt werden können.
4.1.4 Asynchronität
Da periodische und aperiodische Ereignisse aureten, 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-Plaform schnell ändern können, ist es notwen- dig, dass das System eine hohe Modularität aufweist. Hierdurch kann flexibel auf die Wei- terentwicklung der Plaform reagiert werden, da nur einzelne Module ausgetauscht werden
28 4 Sowareentwicklung 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 schriweise 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 Kommunikationskee 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 plaformspezifische Implementierung wurde miels Schnistellen ausgelagert. Jene Schnistellen 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 Plaformen:
• 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.
¹⁵Vermiler zwischen Aktoren und Hauptsystem ¹⁶Motorwerte ür jedes Frame ¹⁷Application programming interface
29 4 Sowareentwicklung
Abbildung 4.1: Soware-Architektur
Des Weiteren ist es möglich, ein einfaches autonomes Verhalten zu aktivieren. Dieses ist vor Laufzeit der Soware 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 Plaformen 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 Sowareentwicklung
Ferner wurde eine serielle Logging-Schnistelle implementiert. Die Implementierung selbst erfolgte auf Basis freier Soware 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 auaut. Nur diese müssen letztendlich ür neue Plaformen 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 Soware und stellt eine hardwarenahe Schnistelle ür den Cortex M3 zur Verügung.
31 5 Benchmark
5.1 Zugriffszeit
Um die neue Plaform 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 schriweise die Übertragungsdauer der Pakete misst. Die FUmanoid- Roboterplaformen 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 Plaform ausällt. Wird die Steigung der Geraden durch die jeweiligen Punkte berechnet, so ist diese ür die Plaform aus dem Jahre 2009 fast dreimal höher als die Plaform aus dem Jahre 2011. Das hat zur Folge, dass die neue Plaform 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 Plaform 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 Plaform aus dem Jahre 2009.
5.2 Laufalgorithmus
Die höchste Auslastung des Systems ist beim Laufen gegeben. Um jenen Prozess auf den bei- den Plaformen 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 Schries 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-Plaform 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 ermielt 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 Plaform 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 Plaform ist.
Grund ür das gute Abschneiden der Plaform 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-Plaformen
34 6 Fazit
Im Rahmen dieser Arbeit wurde eine neue Plaform ür humanoide Roboter realisiert. Wäh- rend die alte Plaform 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 Schnistellen zur Kommunikation mit den Aktoren, den Sensoren sowie dem iGEPv2. Des Weiteren musste eine echtzeitähige Sowarelö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 Plaform 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 komplee 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 Bewegungsplaform ü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 plaformunabhängige dynamische Bewegungserzeugung ür autonome mobile humanoide Roboter”. Diplomarbeit. TU Darmstadt, 2008. [20] D. Seifert. “Portierung der FUManoid-Soware”. 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-Plaform 2011 in verschiedenen Montierphasen ...... 10 2.2 FUmanoid-Plaform 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 Plaform (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 Soware-Architektur ...... 30
5.1 Benchmarkergebnisse Lese- und Schreibzugriff ...... 32 5.2 Benchmark in Pseudo-Code ...... 33
38