2. BACHELORARBEITzur Erlangung des akademischen Grades Bachelor of Science in Engineering

Die Bedeutung von Wissensnetzwerken fr die Robotertechnologieausgefhrt von: Herr David OrtnerA-1100 Wien, Favoritenstrae 109/7

FH-Begutachter: !Mag. Axel Zugschwert!

Wien, Sonntag, 10. April 2011

Ausgefhrt am Technikum Wien Bachelor-Studiengang Mechatronik/Robotik an der FH Technikum Wien

Eidesstattliche ErklrungIch erklre hiermit an Eides Statt, dass ich die vorliegende Arbeit selbstndig angefertigt habe. Die aus fremden Quellen direkt oder indirekt bernommenen Gedanken sind als solche kenntlich gemacht. Die Arbeit wurde bisher weder in gleicher noch in hnlicher Form einer anderen Prfungsbehrde vorgelegt und auch noch nicht verffentlicht.

Wien 27.06.2011 _________________________Ort, Datum

_________________________ Unterschrift

KurzfassungWas sind Wissensnetzwerke, wo werden sie eingesetzt und worin liegen ihre Strken? Wissensnetzwerke mit IT Technik sind allgegenwrtig, jedoch eher bekannt unter den Begriff Cloud oder Cloud Computing. Unter dem Begriff Cloud versteht man in erster Linie abstrahierte IT Infrastruktur jedoch aus der Sicht des Benutzers wird sie beinahe ausschlielich fr Informations- oder Wissensnetzwerke verwendet. Wissensnetzwerke bringen viele Vorteile fr den Benutzer mit sich und haben eine rasante Ausbreitung, welche durch die Web 2.0 Bewegung getragen wird. In dem Bereich der Robotik entstehen gerade die ersten cloudfhigen Systeme, welche in dieser Arbeit beschrieben und deren Vor- und Nachteile aufgezeigt werden. Die Implementierung einer Cloudfunktion in der Robotik stt in der Umsetzung weniger auf technische Grenzen, jedoch viel mehr verzgern klassische Konventionen dessen Fortschritt.

Schlagwrter: Wissensnetzwerke, Roboter Kollektive, Roboter Wiki, Cloud

AbstractWhat are knowledge networks, where are they used and which are their strengths? Knowledge networks with IT technology are ubiquitous and better known under the term cloud or Cloud Computing. The term cloud primary is an abstract form of IT infrastructure yet from the user's perspective it is almost exclusively used for information and knowledge networks. Knowledge networks have many benets for their user, and have a rapid spread, which is supported by the Web 2.0 movement. In the eld of robotics the rst cloud enabled systems are being developed and are described in this work. Also their advantages and disadvantages are demonstrated. The implementation of cloud features in robotics has not yet reached its technical limitations but classical conventions are delaying progress.

Keywords: knowledge-networks, Robotic collective, Robotic Wiki, Cloud

DanksagungDie Reihenfolge meiner Danksagung soll keine besondere Wertigkeit suggerieren, sondern ist lediglich zeitlich chronologisch geordnet. Daher danke ich als allererstes meinen Eltern, welche es mir erst ermglicht haben, dass ich heute hier sitzen kann und eine Arbeit schreiben darf, die fr meine Ausbildung sowie meine Persnlichkeitsbildung einen groen Wert besitzt. Auch danke ich der Fachhochschule Technikum Wien bzw. dem Personal, welche ihre Verantwortung erkannt hat und aus der Masse Menschen ausbildet, welche die Zukunft in ihren Kpfen tragen. Und ich danke ganz herzlichst meinem Betreuer Axel Zugschwert der mir mit dem Thema dieser Arbeit die Chance gab, mich mit einer Materie zu befassen, welche mich sehr inspiriert hat. Alle diese Menschen haben mir gezeigt, das Geben mehr ist als Nehmen und nur so haben wir Menschen auch eine Zukunft.

Inhaltsverzeichnis1.Aufgabenstellung und Grundlagen! 1.1. Die Roboterheinheiten nach Typen! 2.Bestehende Wissensnetzwerke fr mechatronische Systeme! 2.1. RoboEarth! 2.2. ALIZ-E!2.2.1.Fallstudie! 2.2.2.Realisierung durch GOSTAIs Urbi!

1 2 3 4 56 6

2.3. Googles Android powerd Cellbot! 2.4. DAvinCi - Distributed Agents with Collective Intelligence! 2.5. GostaiNet! 3.Programmiersprachen! 3.1. Industrie Roboter Frameworks!3.1.1.RobotStudio! 3.1.2.Programmierbeispiel RAPID!

7 8 9 10 1112 12

3.2. Service Roboter Frameworks!3.2.1.Urbi von GOSTAI! 3.2.2.Programmierbeispiel Urbi!

1515 15

3.3. Vergleich der Beispiele! 4.Mgliche Dienste aus der Cloud! 4.1. Wahrnehmung! 4.2. Sprache sprechen und bersetzen! 4.3. Planen! 4.4. AppStore Fhigkeiten! 5.Fallbeispiel mglicher Einsatz von Wissensnetzwerken!

18 18 18 19 19 19 20

5.1. Versorgung! 5.2. Reinigung und berwachen! 5.3. Die Arbeit am Patient! 5.4. Vernetzung der Roboter! 6.Ausblick! Literaturverzeichnis! Abbildungsverzeichnis! Abkrzungsverzeichnis!

21 24 26 27 28 29 30 31

1. Aufgabenstellung und GrundlagenDie Entwicklung des Internet hat gezeigt, dass die Vernetzung von einzelnen Einheiten und dadurch das Bilden von Wissensnetzwerken wie Newsgroups, Xing, Facebook und Wikipedia einen wesentlichen Vorteil darstellen. Wissensnetzwerke (Abbildung 1) sind keine neue Entwicklung oder nur durch das Internet realisierbar, jedoch ist ihre Umsetzung durch die strukturierte online Welt erheblich erleichtert. Alleine in sterreich besitzen laut Statistik Austria ( 2010 ) 72,9% aller Haushalte einen eigenen Internet Anschluss. Jedem steht es frei mit Gratissoftware wie z.B.: MediaWiki oder Wordpress ( 2011 ) ein eigenes Wissensnetzwerk zu erstellen. Die Qualitt von Wissensnetzwerken hngt wesentlich von der Aktualitt der zur Verfgung stehenden Information ab und von der Anzahl der Editoren sowie deren unterschiedlichen Wissensschwerpunkte..

Abbildung 1: Preler, M, 2007 Aktuelle Wissensnetzwerke im Internet Quelle: http://blog.gelbzucht.de/wp-images/soziale-netzwerke-maik.svg [Abgerufen 11.06.2011] Diese Entwicklung hat auch dazu gefhrt, dass renommierte Enzyklopdien wie Brock Haus quantitativ und qualitativ obsolet geworden sind, im Vergleich zu komplexeren Wissensnetzwerken wie Wikipedia. (Horst Gntheroth und Ulf Schnert 2007 ) Die Herausforderung bei Wissensnetzwerken besteht in der Koordination von Kommunikation. Diese Arbeit befasst sich mit der Problematik bei der Sammlung von Information, um ein ntzliches Wissensnetzwerk fr mechatronische Systeme zu erstellen. Dazu gehrt die Klrung von Fragen wie: Was wird von wem wie gespeichert und wer kann damit wie was anfangen? Im weiteren spielt auch die Datensicherheit eine Rolle.1

Im Zusammenhang mit Wissensnetzwerken wird oft der Begriff Cloud oder Cloud Computing verwendet. Darunter versteht man eine abstrahierte IT Infrastruktur, welche meistens bentigt wird, um Onlinedienste wie Google Maps, Facebook, Wikipedia oder Amazon zu realisieren. Die Vorteile von einer abstrahierten IT Infrastruktur bestehen in ihrer variablen Gre sowie in ihrer Ausfallsicherheit im Vergleich zu den geringen Kosten. Firmen wie Intel, Times Warner Cable oder Google betreiben Serverfarmen die ber die ganze Welt verteilt sind teilweise mit eigener Stromversorgung und einer Uptime von 99,984% im Jahr. Die Bereitstellung eigener Dienste mit diesen Spezikationen wrde enorme Kosten verursachen. (Derrick Harris 2011) Somit ist ein ein logischer Schluss, die rechenintensiven Aufgaben, die in der Robotik anfallen in das Netz auszulagern. Diese Hardware Auslagerung nennt man auch Cloud Robotics und erffnet fr die Robotik neue Mglichkeiten von denen schon lange getrumt wird aber die ohne Cloud einfach nicht mglich sind. Einfache Beispiele sind Bilderkennung und Verarbeitung, Stimmenerkennung und Verarbeitung und komplexe Planplanung. Ein Roboter knnte so Objekte erkennen, bentzen und verstehen ohne sie je davor gesehen oder benutzt zu haben. Dazu reicht es ein Abbild an die Cloud zu senden und also Antwort kommen Informationen wie Anwendungsbeispiele, 3D Modelle, Namen, und Preise. Die Mglichkeiten scheinen mit der bestehenden Mglichkeiten schon sehr vielseitig und das an einem Punkt wo dieses Gebiet erst im Entstehen ist. James Kuffner hat die Mglichkeiten die in Cloud Robotics stecken in einem Satz gut zusammen gefasst: Cloudfhige Roboter knnten komplexe Aufgaben erledigen und dabei noch leichter,

billiger und smarter werdenJames Kuffner ein Professor an der Carnegie Mellon University der gerade bei Google an dem Cloud Roboter Projekt arbeitet.

1.1. Die Roboterheinheiten nach TypenDie neueste Studie des IFR statistical department von 2010 listet (Abbildung 2 auf Seite 3) die verkauften Robotersysteme in drei Kategorien wie Industrie Roboter, Service Roboter fr den professionellen Einsatz und Service Roboter fr den Privaten Einsatz. In diesem Zusammenhang wird immer von Einheiten gesprochen damit sind Roboter oder Robotersysteme gemeint. Die wichtigsten Anteile aller Roboter stellen die Industrie Roboter dar. Diese werden laut IFR auf 1,021,000 bis 1,300,000 Einheiten kalkuliert. An zweiter Stelle stehen die Service Roboter fr den professionellen Einsatz dar deren Einheiten werden auf 76,600 kalkuliert. Der grte Anteil entfllt auf die Service Roboter fr den privaten Einsatz, deren Einheiten werden mit 8,700,000 kalkuliert. In Stckzahlen gerechnet, wren die Service Roboter fr den Privaten Einsatz die grte Gruppe, aber der Wert und die Komplexitt dieser Einheiten ist wesentlicher geringer als bei Industrierobotern. Daher richtet sich der Markt immer noch stark nach industriellen Anwendungen aus. (IFR Statistica department, 2010)

2

Die Ergebnisse sind fr diese Arbeit von Bedeutung, da die Verbreitung sowie die verschiedenen Typen von Robotersystemen einen wesentlichen Einuss auf die Entstehung von Wissensnetzwerken in Bezug auf Roboter haben. (IFR Statistica department, 2010)

Abbildung 2: Studie des IFR statistical department In Anlehnung an IFR Statistica department, 2010 Um ein Wissensnetzwerk fr verschiedene Robotertypen oder fr Roboter von verschiedenen Herstellern zu verbinden, ist es notwendig, eine gemeinsame Basis zu nden. Denkbar wren 3 Modelle: Verwendung einer globalen Sprache, jeden Roboter mit einem lokalen bersetzer ausstatten oder die bersetzung online realisieren.

2. Bestehende Wissensnetzwerke fr mechatronische SystemeWissensnetzwerke oder im weiteren Sinn zentral gesteuerte mechatronische Einheiten in Fertigungsstraen gehren zum Alltag. Betrachtet werden aber nur Systeme, welche nicht direkt als Teleoperator fungieren. Also nur Systeme welche eine eigenstndige Steuerlogik besitzen und Prozessdaten ber ein Netzwerk austauschen. Ein klassisches Beispiel fr eine Teleoperator Anwendung kann sein: Ein Portalroboter welcher in keinen periodischen Arbeitszyklus eingebunden ist, auerdem ber keine eigene Sensorik verfgt um eventuelle Kollisionen lokal zu vermeiden. Eine klassische Anwendung mit diesem Roboter, welche nicht einer Teleoperator Anwendung gleichkommt knnte beispielsweise ein Portalroboter sein welcher zyklisch Anfragen abarbeitet und frachtspezische Informationen wie Gewicht oder Gre in einem Netzwerk austauscht. Auerdem verfgt der Portalroboter ber lokale Sensoren, welche Routinen auslsen knnen, um unvorhergesehene Strungen zu vermeiden, ohne den Produktionsuss zu stoppen. Diese Einteilung ermglicht keine genaue Trennung von allen eingesetzten Systemen, jedoch kann dadurch eine grobe Unterscheidung getroffen werden. Auch soll diese3

Einteilung keiner Denition gleichkommen, sondern nur im Hinblick auf den Arbeitsumfang eine sinnvolle Abgrenzung schaffen.

2.1. RoboEarthGrundlage dieser Arbeit ist das EU gefrderte Projekt RoboEarth. Die Grundidee dieses Projektes ist es, die erworbenen Erfahrungen, Fhigkeiten und Kenntnisse von verschiedenen Roboterplattformen zu verbinden. Darum bietet RoboEarth eine Plattform mit Cloud Funktion. Diese Plattform besteht aus drei Computern mit jeweils einem Intel Core i5 CPU 4GB Hauptspeicher und einer 1TB Festplattenspeicher. Das verwendete Betriebssystem ist ein Ubuntu GNU. Weitere Merkmale, die RoboEarth aufweist, sind eine gute Dokumentation, leichte Erreichbarkeit und Zuverlssigkeit. Inspiriert wurden die Projektteilnehmer fr dieses Projekt durch das World Wide Web. Darum basiert auch RoboEarth auf offenen Standards, freier Software sowie standardisierten Schnittstellen. Als weitere Aufgabe wird die Entwicklung von frei verfgbaren Algorithmen zur Manipulation der gespeicherten Daten gesehen. Dadurch soll es mglich sein, das Wissen ber Objekte Aktionen und Umwelt von Robotern aus der ganzen Welt zu verarbeiten. Im Moment ist der Zugang zu dieser Plattform nur ausgewhlten Teilnehmern mglich, da derzeit nur eine privat cloud von der Hardware garantiert werden kann. Jedoch steht es jedem frei, sich an zu melden. Nach dieser Anmeldung erhlt man einen API key. Mit diesem API key ist eine eindeutige Identizierung vom Roboter mglich, ohne dass der User sich anmelden muss. (RoboEarth, 2011)

Abbildung 3: roboearth.org, 2010 Aufbau von Roboearth Quelle: http://www.roboearth.org [Abgerufen 11.06.2011]4

(Abbildung 3) zeigt die verschieden Ebenen von RoboEarth. Wie man erkennen kann bentigt der Roboter ein High-Level-Betriebssystem, welches als ROS ausgefhrt werden soll. Diese ROS Komponenten werden von RoboEarth entwickelt. Eine Dokumentation steht noch nicht zur Verfgung, da auch die Komponenten noch nicht zur Verfgung stehen.

2.2. ALIZ-ERoboter fr den Einsatz mit kranken Kindern haben ein groes Potenzial. Allerdings gibt es im Vergleich zu anderen Bereichen wie z.B. in der Chirurgie einen groen Unterschied zwischen Theorie und Praxis. Ziel dieses Projekts, welches von der EU ber Seventh Framework Programme gefrdert wird, ist die Langzeit-Begleitung von an Diabetes erkrankten Kindern. Im Gesundheitswesen spielen Robotersysteme eine zunehmend wichtigere Rolle jedoch erwartet man in diesem Projekt Fhigkeiten wie Gesundheitserziehung, Unterhaltung und bessere Kommunikation zwischen Patient und dem Krankenhaus-Personal. Die Gefahr sowie die Schwchen bei bestehenden Systemen besteht in der fehlenden Implementierung von kognitiven Systemen. Darum knnen Langzeitkontakte mit bestehenden Robotersystemen dazu fhren, dass der Menschen mit Desinteresse reagiert. Auch kann es dazu kommen dass Menschen sich an das primitive Verhalten anpassen was in keinen Fall gewnscht ist. Tony Belpaeme (2011) traf anhand von realen Diabetes Kursen fr Kinder eine Einteilung die notwendig ist fr Robotersysteme.

Abbildung 4: Die Komponenten von kognitivem Verhalten Diese Einteilungen fhren dazu, dass ein natrlich Kognitives verhalten ber lngere Zeit wahrgenommen werden kann. Die Einteilung (Abbildung 4) setzt sich auch den Punkten adaptive Erinnerung fr lngere Zeit, adaptive Bentzer und Prozess Modellierung, adaptives nichtsprachliches Verhalten und adaptives sprachliches Verhalten und nur durch die Implementierung aller vier Komponenten kann das geplante Ziel erreicht werden. Die einzelnen Fhigkeiten wurden im Rahmen einer Gesundheitsvorsorge die bis5

zu fnf Tage dauert getestet. Diese ersten Ergebnisse bilden die Grundlage fr die Fallstudie. Tony Belpaeme (2011)

2.2.1. FallstudieZielgruppe dieser ersten Fallstudie waren Patienten im Alter von acht bis zwlf Jahren die an Stoffwechselstrung litten. Das Augenmerk lag in der Ausfhrung von vier Spielen aus dem Bereich der verbalen Interaktion und der nicht verbalen Interaktion. Der kognitive Teil bei dieser Fallstudie ist durch die Anpassungsstrategie des Roboters erkennbar. Diese Anpassungsstrategie wurde in zwei Teile aufgeteilt, die Verbale Adaption (z.B.: verwenden von gleichen Ausdrcken, Sprachgeschwindigkeit, Sprachintensitt) und Interaktion (z.B.: Krperhaltung, Atemfrequenz und Gesten). Die Ergebnisse zeigten, dass alle Kinder in der Altersgruppe den Roboter als Spielpartner akzeptiert haben. Daraus kann geschlossen werden, dass der therapeutische Einsatz ebenfalls erfolgreich sein kann. Es gibt hnliche Therapiemglichkeiten mit Tieren, welche aber nur begrenzt eingesetzt werden knnen. (Baxter, P., Belpaeme, T., et al., 2011)

2.2.2. Realisierung durch GOSTAIs UrbiVerschiedene kognitive Architekturen die menschliches Denken simulieren, sind bereits bekannt. Auf der Grundlage von SORA (State, Operator Apply Result) ist es mglich ,komplexes menschliches Verhalten zu simulieren. Diese Verhaltenssimulation ist auch ber eine lngere Zeit vergleichbar mit dem menschlichen Verhalten. Weitere kognitive Architekturen wie ATLANTIS, Theo, ICARUS wurden entwickelt, jedoch SORA erfllt die Anforderungen in jeglicher Hinsicht. Die Umsetzung auf der verwendeten Plattform NAO ist wegen der stark begrenzten Hardware nicht mglich (NAO H21, 500MHz CPU, 256 MB). (Baxter, P., Belpaeme, T., et al., 2011)

Abbildung 5: aliz-e.org, 2010 Nao mit den Patienten Quelle: http://www.aliz-e.org [Abgerufen 11.06.2011]

6

Aus diesem Grund wurde abstrahierte IT Infrastruktur virtuell mit eingebunden. Somit kann der SOAR uneingeschrnkt eingesetzt werden und die Verhaltensdatenbank in eine Cloud geschrieben werden. Die Verwaltung der Datenbank, die NAO bei seinem Einsatz erstellt, wird von rechenstarken Netzcomputern durchgefhrt. So kann NAO (Abbildung 5) mit den Kindern verbal und nonverbal interagieren. Bei dieser Interaktion werden stndig Informationen gesammelt, online verarbeitet und bilden so die Erinnerung des NAO. Diese Erinnerungen werden unter den eingesetzten NAOs teilweise geteilt und dienen auch zur Verbesserung des gesamten Systems. Da es sich hier um ein laufendes Projekt handelt stehen noch nicht alle Ergebnisse zur Verfgung. (Baxter, P., Belpaeme, T., et al., 2011). Die NAO Programmierung wurde mit Urbi einer Open-Source-Software realisiert. Diese Programm ist plattformunabhngig und kann fr verschiede Roboter oder hliche komplexe Systeme verwendet werden. Die Flexibilitt dieses Programmes ermglicht die Implementierung von verschieden Komponenten wie kognitive Architekturen, Bilderkennung ber open CV, Spracherkennung, Sprachsynthese, Gesichtserkennung, Gesichtswiedererkennung, SLAM, color blob detection oder SIFT basierende Objekterkennung. Nhere Informationen zu GOSTAIs Urbi sind dem Kapitel Unabhngige Programmiersprachen und Software zu entnehmen. (Baxter, P., Belpaeme, T., et al., 2011)

2.3. Googles Android powerd CellbotCellbots sind Roboter, die um ein Telefon herum gebaut werden. blicherweise kommen Smartphones zum Einsatz. Diese Telefone besitzen ausreichend Hardware und die notwendigen Softwareteile. Die gleichnamige Software Cellbot ist in Java geschrieben und kann auf jedem Smartphone installiert werden, das mindestens ein Android 2.2 (Froyo) verwendet. Erstellt wurde Cellbot mit dem Android SDK und ist open source. Entstanden ist Cellbot aus der ersten Python Library um mit Robotern zu kommunizieren. Diese Librarys ermglichen Verbindungen ber HTTP, XMPP, oder Bluetooth zu verschiedene Plattformen wie Truckbot, Tankbot, VEX Pro iRobot and LEGO MINDSTORMS. (Cellbot 2011) Diese Untersttzung wird noch stark zunehmen da auch die Verbreitung und der geringe Preis von Smartphones und Robotern diese Entwicklung frdert. Diese Projekt wird sehr stark vom privaten Sektor getragen aber es zeigt, dass nicht viel Ressourcen notwendig sind um einfache Roboter zu bauen die komplexe Aufgaben wie Gesichtserkennung oder Spracherkennung beherrschen. Die eigentliche Strke diese Projekts liegt in der Bereitstellung von Kommunikationswegen von Menschen fr den Roboter. Dadurch stehen den Roboter ausgereifte Netzwerke zu verfgung, die an Komplexitt und Gre von einzelnen Projekte nicht bertroffen werden knnen. Zum Vergleich knnen hier ein paar Zahlen genant werden. Wikipedia betreibt eine Datenbank mit 1.230.215 Artikel die von ber 1.000.000 Benutzer erstellt wurden (Wikipedia 2011). Im Juni 2008 gab Google bekannt, dass sie 1.000.000.000.000 URLs indiziert haben und das ist die letzte ofzielle Zhlung (Google 2008). Flick verwaltet eine Bildersammlung von mindestens 5.000.000.000 Bildern. (Flickr 2010) Die Filmedatenbank Youtube gab bekannt, dass im Schnitt alle 4 Sekunden 3 Videoclips online gestellt

7

werden. Anhand dieser Zahlen ist erkennbar, dass private Projekte auch wenn sie qualitative hochwertiger sind, quantitativ nicht vergleichen lassen.

2.4. DAvinCi - Distributed Agents with Collective IntelligenceDAvinCi ist ein Projekt, das sich zum Ziel gesetzt hat ein Framework zu bauen, welches verschiedene Roboter und Funktionen aus der Cloud vereint (Abbildung 6). Verwendet wurden dafr die Instrumente wie ROS, FastSLAM, Hadoop , SaaS IaaS, PaaS und Google Application Engine. Das Ergebnis ist theoretisch vergleichbar mit dem dem Kommerziellen Projekt GostaiNet jedoch ist es praktisch nicht vergleichbar da es sich hier nicht um eine Public Cloud handelt. Das Projekt zeigt jedoch, dass es mit vorhandene n Mittel mglich ist Wissensnetzwerke fr Roboter aufzubauen. Daher ist auch damit zu rechen, dass in naher Zukunft mehrere Projekte im Bereich Forschung und im kommerziellen Bereich entstehen werden.(Arumugam R., Enti V. R. et al., 2010)

Abbildung 6: DAvinCi Aufbau In Anlehnung an Arumugam R., Enti V. R. et al., 20108

2.5. GostaiNetGostaiNet ist ein kommerzielles Projekt von der Firma Gostai und kann in Verbindung mit der Software von Gostai verwendet werden. Die Verwendung der Software ist fr den privaten Gebrauch kostenlos da sie GNU-lizensiert ist. Hersteller von Robotern haben die Mglichkeit ihren Roboter mit Gostai Studio Suite Pro zu entwickeln und so von der Urbi Programmierung zu protieren. Auerdem bietet Gostai Studio Suite Pro ein fertig entwickelte GUI um Software zu programmieren, zu testen und sie zu exekutieren. Die Cloud Funktion ist dabei schon integriert und kann im vollem Umfang genutzt werden. Dadurch knnen Ressourcen am Roboter gespart werden und komplexe Rechenaufgaben auf den Servern von GostaiNet berechnet werden. Des Weiteren ist es mglich, den Roboter ber das Internet zu steuern oder Internetdienste in die Programmierung zu integrieren. Wie man in (Abbildung 7 auf Seite 10) erkennen kann, bentig man fr die Integration von GostaiNet nur einen kompatiblen Robotern, welcher nicht von Gostai sein muss und man bentigt einen WiFi Router mit Internetanbindung. Das User Interface sollte bei der Programmierung ein Computerbildschirm sein kann aber auch mit einem Smartphone gemacht werden. Fr die Steuerung oder berwachung bietet sich ein Smartphone, welches direkt oder ber das Internet mit dem Roboter verbunden werden kann.

Abbildung 7: Aufbau GostaiNet In Anlehnung an GOSTAI, 20119

3. ProgrammiersprachenEin zentrales Thema in der Robotik ist die Programmierung und deren Entwicklungsumgebungen. Verstndlicherweise sind unterschiedliche Sprachen so wie unterschiedliche Vorstellung entstanden, wie ein Roboter programmiert werden kann und soll. Groe Industrieroboter Hersteller wie ABB, Kuka ADEPT oder Honda haben eigene Lsungen entwickelt. In der Servicerobotik gibt es teils die gleichen Hersteller wie in der Industrierobotik aber es ist hier ein Trend erkennbar, der darauf abzielt die Programmierung von verschieden Robotern mit den gleichen Werkzeugen zu realisieren. Die Grenze der Frderer und der Nichtfrderer kann zum Teil am Marktanteil oder verkauften Stckzahlen erkannt werden. Diese Entwicklung wir hauptschlich von zwei Tatsachen getragen, zum einen sind die Margen und die Stckzahlen bei den Serviceroboter el geringer und darum wird versucht mglichst geringe Entwicklungskosten zu produzieren. Fertig entwickelten Open Source Frameworks wie von Gostai, Aldebaran Robotics oder Robotikinstitut Willow Garage sind meist sehr vielfltig einsetzbar und werden stndig weiterentwickelt und sind zustzlich frei von Lizenzgebhren. Zum anderen sind die Anforderungen an Serviceroboter sehr vielseitig und komplex jedoch spielt die Ausfallsicherheit nicht so eine groe Rolle wie bei Industrierobotern. Somit bentigen Serviceroboter tendenziell mehr Software und besitzen eine komplexere Software, aber wiederum tendenziell weniger Hardware. Hier kann natrlich ein gut entwickeltes Framework sehr viel Arbeit ersparen. Es ist abzusehen, dass in der Serviceroboter Sparte vor allem im privaten und Entwickler Bereich in naher Zukunft der Groteil der User auf standardisierte Komponenten aufbaut um den komplexen Softwareanforderung noch gerecht zu werden. Ein Beweis fr die unterschiedlichen Ansichten der verschieden Hersteller zeigt eine Entscheidung, die jngst von Gostai einem Serviceroboter Hersteller getroffen hat. Sie haben ihr Framework zum Groteil als open Source zur Verfgung gestellt. IRobotGrnder Rodney Brooks, welcher hauptschlich in der professionellen Servicerobotik ttig ist reagierte im Mai 2011 auf die Entscheidung von Gostai mit dem Zitat:

Solving the hard problems of robotics and giving those solutions away is the worst thing someone can do for the robotics industry, you have to understand the economic engine behind things.Die Leader der Branche sind natrlich nicht bereit ihre Entwicklungen freiwillig weg zu geben, auch wenn eventuell die Qualitt der Software durch gemeinsame Anstrengungen gesteigert werden wrde. Auf Dauer kann diese Haltung natrlich nicht eingehalten werden, da in der Zeit der Globalisierung nicht viel Platz ist fr Fderalismus. Der Einsatz von Robotersystemen geschieht in den unterschiedlichsten Bereichen, resultierend daraus sind die Anforderungen an die eingesetzte Technik auch sehr10

unterschiedlich. Die Einsatzgebiete reichen von Medizin ber Industrie, bis Unterwasser oder ins Weltall. Diese stndig wachsenden Einsatzgebiete schaffen auch kontinuierlich neue Robotersysteme. In dieser Betrachtung werden daher nie alle verfgbaren Robotersprachen aufgelistet, im Gegenteil es werden sogar starke Einschrnkungen getroffen. Verglichen werden Sprachen aus dem Bereich Industrierobotik und Servicerobotik. Des Weiteren werden nur Sprachen verglichen, die noch gepegt werden und zuknftige Anforderungen von Robotersystemen erfllen knnen. Diese Einschrnkungen sind notwendig, da die Ergebnisse fr diese Arbeit sonst nicht zielfhrend wren.

3.1. Industrie Roboter FrameworksIndustrie Roboter werden bis auf ein paar Ausnahmen in Fabriken und Montagehallen eingesetzt. Dort verrichten sie meist einfache Aufgaben wie Schweien, Lackieren, Sortieren und pick and place aufgaben in zyklischer Abfolge. Das hat auch dazu gefhrt ,das die Programmierung von Industrierobotern und Servicerobotern unterschiedliche Schwerpunkte aufweisen. Ein wesentlicher Unterschied besteht darin, dass immer noch viel Roboter online programmiert werden. Unter dieser Methode versteht man das Erstellen einen Programms direkt in der Steuerung des Roboters. Diese Methode hat zur Folge, dass der Roboter blicherweise in dieser Zeit nicht verwendet werden kann bis das Programm fertig erstellt wurde. Eine weitere Einschrnkung bei der online Programmierung stellt die Steuerung da. Diese wird fast ausschlielich dahingehend designed, sodass sie von dem User in einer Hand getragen werden kann. Das hat den Vorteil, dass sie sehr einfach bentzt werden, kann jedoch ist die Programmierung auf dem kleinen Bildschirm je nach Programmierbeispiel nicht immer so einfach zu lsen wie auf einem Computermonitor. hnlich verhlt es sich mit Simulationen auf dem Teachpanel jedoch knnen die Programmzeilen gleich von dem Roboter vorgefhrt werden. Eine online Programmierung muss auf die Vorteile eine Simulation verzichten und man ist somit eher der Gefahr ausgesetzt, den Roboter durch eine Kollision zu beschdigen. Vorteile die eine Ofineprogrammierung mit sich bringt sind unter anderem die einfache Simulation von Situationen wie die Verarbeitung von Sensorsignalen oder die Eingabe exakter Punkte wie bei einem CAD Modell. Die berprfung der ganzen Simulation oder nderung ist blicherweise wesentlich schneller als bei der online Programmierung wenn man die Komponenten der Simulation schon zur Verfgung hat. Die Standardisierung von Industrierobotern Sprachen wie RAPID, VAL, V+ oder KRL wurden nie vollstndig umgesetzt, dennoch bestehen sehr viele hnlichkeiten bei der Programmierung von Industrierobotern. Der Programmablauf eines Industrieroboters kann meist als eine lineare Routine verstanden werden. Online werden Programme ausschlielich zeilenweise erstellt, ausgenommen bei der Folgeprogrammierung. Hug verwendete Befehle sind Unterprogrammaufrufe wie (CALL, CALLPROGC oder PROCCALL) diese meist mit (RETURN) beendet werden. Einfach Sprnge wie (GOTO...)11

werden fast von jeder Sprache ermglicht. Wie in der Sprache C ndet man auch bei Robotern Verzweigungen wie (IF...), Zhlschleifen(FOR..) oder Bedingungsschleifen wie (WHILE..). Robotertypische Befehle beschreiben Bewegungsarten wie PTP, Spline, CP oder berschleifen. Notwendig sind auch Befehle mit Werkzeugdaten und Werkstckdaten und Befehle betreffende des Zusammenspiels der eigenen Achsen.

3.1.1. RobotStudioDas Framework von ABB trgt den Namen RobotStudio und wird beworben als OfineProgrammierung Umgebung mit der Sprache RAPID die auch von ABB entwickelt wurde. Das Programm steht auf der Webseite von ABB zum Download bereit und enthlt schon die APIs, welche bei ABB Templates genannt werden, um bestimmte Robotermodelle von ABB zu programmieren. Die GUI des Programms erinnert sehr an ein CAD Programm. Hier liegen auch die Strke des Programms, da es mglich ist, einfache Krper in dem Programm zu erstellen oder komplexe aus einer Library zu laden. ABB stellt viele Komponenten in dieser Library bereit andere knnen auch Online von der ABB Seite geladen werden. Diese Komponenten werden von einer Breiten Community bereitgestellt. Somit kann die relevante Umgebung des Roboters modelliert werden und Einstze simuliert werden. Die Steuerung ist auch in der Lage ofine wie online analoge wie digitale Ausgnge zu verwalten. In der Version RobotStudio 5 ist eine Implementierung von einer Untersttzung fr Roboter, die nicht von ABB sind, nicht vorgesehen. Der Hersteller verspricht Vorteile bei der Anwendung der Software im Bereich der Schulung, Programmierung und Prozessoptimierung. Weiter soll die Software helfen das Risiko zu minimieren, krzere Anlaufzeiten zu realisieren, schnellere Produktwechsel zu ermglichen und das soll zu einer erhhten Produktivitt fhren.

3.1.2. Programmierbeispiel RAPIDEin typisches Beispiel, welches einen kleinen Einblick in die Programmierung von RAPID gestattet, wird hier beschrieben. Die Programmierung von RAPID kann am Teachpanel erfolgen oder mit einem Texteditor. Auch besteht die Mglichkeit mit dem Framework von ABB oder von anderen Herstellern, wie Eclipse zu programmieren. Das Feature highlighting wird jedoch nur von ABB untersttzt. Auch die Kompilierung ist ausschlielich mit der ABB Software mglich. Zwecks der bersichtlichkeit wird nicht das vollstndige Programm beschrieben, sondern nur die eigentliche Funktion. Jedoch ist anzumerken, dass ein RAPID Programm Deklarationen von Variablen bentigt wie beispielhaft in folgendem Codebeispiel gezeigt wird:

CONST robtarget p_home:=[[506.29,0,679.5],[0.5,0,0.866026,0],[0,0,0,0],[9E+09,9E +09,9E+09,9E+09,9E+09,9E+09]];Hier wird eine Konstante von Typ robtarget mit dem Namen p_home deklariert und anschlieend werden ihr Werte zugeordnet Hier spricht man von der home Position und Orientierung in Bezug auf das Basiskoordinatensystem des Roboters, sofern kein Weltkoordinatensystem festgelegt wurde.12

var robtarget p_startp;Bei diesem Befehl wird eine speichernde Variable deklariert vom Typ robtarget und dem Namen p_startp. Weitere Variabel-Zustnde knnen PERS und CONST sein. Wird eine Variable mit PERS deklariert, so ist diese speichernd, auch wenn ein Neustart durchgefhrt. Wird eine Variable als VAR festgelegt, wird sie bei einem Neustart gelscht. Die Deklaration CONST wird zu Beginn festgelegt und bleibt whrend des kompletten Programmablaufs unverndert. Weitere Variabletypen sind: num, string, clock, pos, orient, pose, ...etc.

PROC main() ! ! ! TPErase; TPReadNum ausw,"Module Eck: 1 Module Kreis: 2"; TPReadNum oft,"Wie oft?:";

Laut Konvention bentigt der Compiler Den Befehl PROC main(), um das Programm als solches zu erkennen. Daher ist es notwendig, dass dieser Befehl in jedem Programm vorhanden ist. TPErase; lscht den Text der Ausgabe am Display des TeachPanels und schafft somit Platz fr die weitere Ausgabe. Der Befehl TPReadNum fordert den Benutzer in Textform ber das TeachPanel auf, einen Wert fr eine bestimmte Variable, (ausw bzw. oft) einzugeben, mit welcher er den weiteren Programmablauf fortsetzt. FOR i FROM 0 TO (oft-1) DO

TEST ausw ! ! ! ! ! ! CASE 1: ! ! ! ! p_startp:=p_home; eck; p_startp:=p_home; kreis;

CASE 2:

Mit dem Schleifenbefehl FOR wird eine Kontrollstruktur TEST mit verschiedenen CASE beliebig oft wiederholt. Je nach Auswahl die in ausw gespeichert wurde, kann ein Unterprogramm kreis oder eckeaufgerufen werden. Ausserdem wird p_home in P_startp geschrieben.

! !

ENDTEST ENDFOR

ENDPROCDer Befehl ENDTEST beendet die Kontrollstruktur TEST und die Zhlschleife ENDFOR. Mit ENDPROC wird das Hauptprogramm beendet. Die Abarbeitung von Programmen geschieht blicherweise chronologisch, von oben nach unten, jedoch kann es13

vorkommen, dass durch jump-Befehle wie GOTO oder durch Unterprogrammaufrufe diese Abfolge nicht eingehalten wird. Dadurch knnen nach dem Befehl ENDPROC immer noch Codezeilen stehen, die exekutiert werden.

PROC kreis() ! ! ! MoveJ p_startp,v1000,z50,tool0; MoveC Offs(p_startp,50,50,0),Offs(p_startp,100,0,0),v1000,z0,tool0; MoveC Offs(p_startp,50,-50,0),Offs(p_startp,0,0,0),v1000,z0,tool0;

ENDPROCDas Unterprogramm kreis wir durch PROC gekennzeichnet. Im Programm werden klassische Bewegungsbefehle ausgefhrt und mit ENDPROC wird das Programm wieder beendet. Der Bewegungsbefehl MoveJ steht fr achsspezisches und punktgenaues Anfahren, in diesem Fall zum Punkt p_startp, mit der Geschwindigkeit v1000, also bis zu 1000 Millimeter in der Sekunde. Das z50 steht fr Zone 50 Millimeter und beschreibt, wie genau ein Zwischenpunkt angefahren werden muss. Wrde man diese Funktion nicht verwenden, kann die Abntzung des Roboters hher sein, da seine Bewegungen von Punkt zu Punkt sehr ruckartig gefahren werden. Die letzte Deklaration von MoveJ ist tool0, welches das verwendete Werkzeug beschreibt, das zuvor durch Informationen wie Trgheitsmoment, Orientierung, Masse und Masseschwerpunkt deniert wurde. Diese Informationen haben einen groen Einuss auf die Berechnung der Bahn, da wenige Kilogramm am Ende eines Sechsachsers Momente erzeugen, die das Verhalten verndern, wenn man sie nicht bercksichtigt. Der nchste Bewegungsbefehl ist MoveC und steht fr eine Halbkreisbewegung aus zwei Punkten und dem Startpunkt. In diesem Fall wird von p_strart ber Offs(p_startp,50,50,0) nach Offs(p_startp,100,0,0) gefahren. Somit wird ein Halbkreis gefahren mit einem Radius von 50 Millimeter. Offs steht fr Offset und ist keine absolute Positionierung im Koordinatensystem, sondern eine relative zu p_startp. Diese Schreibweise erleichtert das Lesen des Codes und ermglicht ein schnelles Anpassen des Codes, da es gengt p_strart zu ndern. Weitere Bewegungsbefehle von RAPID sind: MoveL und MoveAbsJ. Wobei MoveL sich linear von Punkt zu Punkt und MoveAbsJ sich achsenweise und absolut bewegt. Die Ausfhrung aller Funktionen von RAPID wrde den Umfang dieser Arbeit berschreiten, jedoch konnte an einem einfachen Beispiel gezeigt werden, wie die Sprache aufgebaut wird. Eine wesentliche Funktion, die im Beispiel jedoch nicht beschrieben wurde, aber genannt werden sollte, ist das Arbeiten mit Signalen. Mit der Steuerung des Roboters kann man je nach Ausstattung digitale und analoge Signale verarbeiten, die den Roboter mit seinem Umfeld synchronisieren. Die gesamte Dokumentation der Sprache RAPID, sowie SDK und IDE stehen online zur Verfgung bei ABB.

14

3.2. Service Roboter FrameworksEs gibt Open Source Projekte, sowie kommerzielle Plattformen. In diesem Kapitel werden nur plattform-unabhngige Programmiersprachen, wie Urbi von GOSTAI, Microsoft Robotics Studio, Robotics Suite, Evolution Robotics, LabVIEW oder ROS beschrieben. Die meisten Frameworks knnen unterschiedliche Sprachen verarbeiten. Gngige Sprachen in der Robotik sind: C, C++, Java, Matlab, Urbi SDK, prototypenbasierte Programmierung und Ableitungen dieser Sprachen. In weiterer Folge werden die wichtigsten Frameworks beschrieben und deren Unterschiede aufgezeigt.

3.2.1. Urbi von GOSTAIDie Open-Source-Software von Gostai nennt sich Urbi und wurde ursprnglich fr die Roboter von Gostai, wie Jazz entwickelt. Seit 2010 wird das Universal Robot Body Interface unter der GNU Lizenz vertrieben. Weiterhin wird dennoch eine kommerzielle Version vertrieben. Verwendebar ist Urbi fr Robotersysteme oder hnlich komplexe Systeme. Sie enthlt eine C++ Komponenten-Bibliothek namens UObjekt, welche eine Standard API enthlt, um Motoren, Sensoren und Algorithmen zu beschreiben. Das Ziel von Urbi ist Roboter-Programmierung kompatibler und einfacher zu machen. Ab der Version 2.x wird ROS untersttzt und kann daher auch zusammen gentzt werden. Die Flexibilitt dieses Programms ermglicht die Implementierung von verschieden Komponenten, wie kognitive Architekturen, Bilderkennung ber open CV, Spracherkennung, Sprachsynthese, Gesichtserkennung, Gesichtswiedererkennung, SLAM, color blob detection oder SIFT basierende Objekterkennung. Klassische Anwendungsgebiete von Urbi, die auch schon umgesetzt wurden, sind: Webots, Segway, Aibo, IRobo, Lego Mindstorm NXT, NAO, Robotis Bioloid und Mobile Robots Pioneer.

3.2.2. Programmierbeispiel UrbiEin klassisches Programmierbeispiel fr Urbi SDK wird in der Sprache Urbi geschrieben. Urbi wurde von Gostai entwickelt und folgt dem Konzept der model-driven Software Development. Das Hauptaugenmerk bei der Entwicklung der Sprache bestand in der Einfachheit und in der Parallelitt. Ein einfaches Beispiel veranschaulicht die guten Ergebnisse der Entwicklung.

whenever (ball.Visible) ! ! ! ! ! { headPan.val! & headTilt.val! }; +=! camera.yfov!*! ball.! y +=! camera.xfov!*! ball.! x

Erklrung:15

Das verwendete whenever ist hnlich dem while aus der Sprache C. Der Unterschied besteht darin, dass whenever parallel ausgefhrt werden kann und keine Abbruchbedingung haben muss. So knnen in einem Urbi Programm mehrere whenever auf ihre Ausfhrung warten und zur gleichen Zeit abgerufen werden. Das ball.Visible ist der Name der Routine. Wie es auch in anderen Sprachen blich ist. headPan.val und headTilt.val sind zwei Motorsteuerungs-Objekte, wobei val eingenerischer Zeiger auf einen Slot mit Motorpositionen ist. Es knnen die Position oder der Winkel beschrieben werden. Weitere mgliche Unterklassen fr Motoren sind position, force, speed, angel, turn oder torque. Die Objekte camera.xfov und camera.yfov gehren zu dem VideoIn Interface und die Unterklasse x oder y fov beschriebt das x oder y Sichtfeld der Kamera im Bogenma. Auch hier gibt es wieder eine Anzahl von vor denierte Unterklassen, wie height, width, format?, exposure?, wb?, gain?, resolution? und quality?. & zwischen den beiden Befehlszeilen steht fr die parallele Ausfhrung der Befehlszeile 1 und 2. Dies ist eine Fhigkeit von Urbi, welche die Programmierung sehr vereinfacht, da so z.B: ieende Bewegungen in x und y gleichzeitig ausgefhrt werden knnen. In dem lediglich zwei Befehlszeilen notwendig sind. In diesen Zusammenhang ist es sinnvoll auch die weiteren drei Ausdrcke Pipe, Beistrich und Doppelpunkt zu beschreiben. Das Zeichen | oder auch als Pipe bezeichnete Symbol bewirkt in Urbi, dass der Scheduler zwei Prozesse direkt nacheinander abarbeitet. Wie in der (Abbildung 8) gezeigt kann kein Gap zwischen zwei Prozessen entstehen. Das ist auch dann der Fall sollte ein hher priorer Task dazwischen kommen. Geschieht dies bei dem Zeichen Doppelpunkt hat der hher priore Task Vorang.

Abbildung 8: Urbi Beispiel Parallelitt Diese Mglichkeit dem Scheduler eine bestimmte Reihung von Tasks vorzuschreiben ist sehr wichtig in der Robotik, speziell bei der Verarbeitung von Bewegungen. Generell spricht man hier von den Mglichkeiten der seriellen Verarbeitung. Bei der parallelen verarbeitung gibt es schon wie zu vor erwhnt, die Mglichkeit das & oder , zu verwenden. Das & garantiert die parallele Abarbeitung was bei , nicht der Fall ist.

16

Abbildung 9: Urbi Beispiel Serialitt Eine weitere Mglichkeit, um eine Event gesteuerte Funktion zu programmieren, besteht darin ein at zu verwenden.

at (speech.hear("hello")) ! ! ! ! ! { voice.say("How are you?") & robot.standup() };

Der Befehl at ist vergleichbar mit if aus der Sprache C. Der Unterschied zu whenever besteht darin, dass whenever nicht nur einmal ausgefhrt werden kann. In diesem Beispiel wird eine Funktion mit dem Namen speech.hear("hello") aufgezeigt, welcher zur selben Zeit auch die Bedingung darstellt. Speech stellt die Klasse dar und hear dessen Unterklasse. In diesem Fall wartet speech.hear auf den Ausdruck Hallo, um dann den Befehl voice.say und gleichzeitig den Befehl robot.standup() auszufhren. Das letzte und wahrscheinlich interessanteste Beispiel von Urbicode beschreit die Funktion tag.

mytag:! ...

(some_code);

mytag.stop (val); mytag.freeze; mytag.unfreeze; mytag.subtag.subsubtag...Diese Funktion tag ist aus der Tatsache entstanden, dass blicherweise ein Code der in Urbi geschrieben ist, hunderte Threads besitzt. Diese Threads knnen durch das benennen des Threads, mit dem Befehl tag benannt werden und so zu jeder Zeit, mit tag.stop (val) gestoppt werden. Whrend dessen kann auch der Status abgefragt werden.17

Mit mytag.freeze; ist es mglich den Thread anzuhalten und mit tag.unfreeze; kann er wieder aktiviert werden. Durch die hierarchische Benennung knnen ganze subtags mit einem Befehl verwaltet werden. Mit dieser Funktion kann sichergestellt werden, dass Urbi seine Aufgabe, das Verwalten von Threads und Skripten zu jeder Zeit bewerkstelligen kann. Die Ausfhrung aller Klassen und Funktionen von Urbi wrden den Umfang dieser Arbeit berschreiten, jedoch konnten ein paar einfache Beispiele die Strken dieser Sprache, welche in der Parallelitt und Einfachheit der Syntax liegen, aufzeigen. Die gesamte Dokumentation der Sprache Urbi, sowie SDK und IDE steht bei Gostai online zur Verfgung.

3.3. Vergleich der BeispieleDie beiden Beispiele zeigen die groen Unterschiede bei der Programmierung von Robotern. Klassisch wird in der Industrierobotik programmiert, wie es in dem ABB Beispiel gezeigt wurde. Im Bereich der Servicerobotik gibt es den klassischen Ansatz, aber eben auch die neue Art der Programmierung. Der wesentliche Unterschied liegt in der Benutzerfreundlichkeit. Je umfangreicher die Programmierung wird desto eher knnen Fehler eingearbeitet werden. Dabei wird die Formatierung immer wichtiger. Bei Servicerobotern werden blicherweise komplexere Programme verwendetet, darum gibt es auch in diesem Bereich mehr Anstrengungen die Programmierung einfacher und bersichtlicher zu gestalten. Naturgem beeinussen sich die Industrie und Servicerobotik, was dazu fhrt, dass die Programmierung auch fr Industrieroboter in Zukunft intuitiver wird.

4. Mgliche Dienste aus der CloudDie hier beschriebenen Dienste sind zum grten Teil schon im Internet abrufbar und es fallen dafr direkt keine Kosten fr den Nutzer an. Voraussetzung, aus der Sicht des Programmierers, fr ein gutes Wissensnetzwerk oder fr eine gute Cloudfunktion ist eine klar strukturierte Datenbank. Es mssen hier Programme geschrieben werden, die Information verarbeiten, welche noch gar nicht vorhanden sind. Das kann dazu fhren, dass Routinen mit den auftretenden Daten nicht arbeiten knnen. Um dies zu vermeiden sind kontinuierliche Quellen, strenge Formatvorgaben, sowie Syntax treue Attribute notwendig, welche ein gutes Wissensnetzwerk auszeichnen.

4.1. WahrnehmungTypische Produkte wie ein Auto, eine Tasse, ein Messer oder eine Schaufel knnten durch Bilderkennung online verglichen werden und Information wie Geometrie, Masseschwerpunkt, Bezeichnung oder Einsatzmglichkeiten knnten lokal verfgbar gemacht werden. Internet Dienste wie www.thingiverse.com zeigen jetzt schon wie18

Wissensnetzwerke fr 3D Modelle aussehen knnen. Im Moment ist der Dienst gedacht fr 3D Modelle, welche man ausdrucken mchte, aber es ist nur eine Frage der Zeit bis Modelle angeboten werden, die fr Roboter auch verwendbar sind. Anders verhlt es sich mit dem Dienst von Google mit dem Namen Google Goggles. Bilder knnen an den Dienst gesendet werden, es werden Texte, Landmarken, Bcher, Kontaktinformation, Kunstwerke, Wein und Marken erkannt. Mglich ist das Bilderkennungsverfahren durch das Internet. Ein reprsentatives Beispiel ist das Erkennen von Sudoku Puzzles. Dieses Beispiel zeigt nicht nur das es mglich ist Bilder zu vergleichen, sondern hier wird auch die Syntax verstanden und eine Lsung errechnet.

4.2. Sprache sprechen und bersetzenDas Internet ist global die vorherrschende Sprache ist Englisch. Viele Menschen sprechen kein oder nur schlecht Englisch. Aus diesem Grund arbeiten viele Firmen daran bersetzungssoftware fr Webangebote zu verbessern. Die meisten mehrsprachigen Webangebote werden durch Communities in verschieden Sprachen bersetzt. Diese bersetzungen und andere mehrsprachigen Texte knnen mit Software verglichen werden und helfen so die automatische bersetzung zu verbessern. Protieren kann man von dieser Entwicklung schon bei Diensten, wie http://translate.google.com, http:// dict.leo.org oder http://uebersetzung.babylon.com. Einen Schritt weiter gehen Dienste, welche Sprachsynthese oder Text-to-Speech-Systems (TTS) anbieten. Ganz bekannt ist hier http://www.linguatec.de oder http://www.naturalreaders.com.

4.3. PlanenCloudfunktionen, welche bei der Planung helfen sind sehr beliebt. Die einfachste Anwendung ist der Kartendienst, welches auch ein klassisches Beispiel fr ein Wissensnetzwerk darstellt. Nicht alle Onlinekartendienste sind als Wissensnetzwerke aufgebaut, jedoch bei dem Umfang der modernen Karteninformationen, wie von OpenStreetMap, Ovi Maps, WikiMapia, Bing Maps oder GoogleMaps wird der User als Autor bentigt. Inzwischen werden die unterschiedlichsten Sachen in die Karten eingetragen, wie Geschfte, Sehenswrdigkeiten, interessante Punkte, Bilder, 3D Bilder, Standort von Personen, Videos, Transit Informationen, Niederschlagsmengen von Regen und Schnee, Sonnenstand, Unterwasserinformationen, etc. Die sortierten Informationen bieten Roboteranwendungen eine Flle an Informationen, die fr verschiedenste Planungsaufgaben verwendet werden knnen.

4.4. AppStore FhigkeitenEin AppStore Fhigkeit fr Roboter gibt es noch nicht aber es gibt AppStores fr Handhelds und Pcs. Diese sind meist von Herstellern erffnet worden und der Inhalt wird von Programmierern erstellt. Autoren verwalten den Inhalt oder Konsumenten bewerten ihn Somit ist es sehr wahrscheinlich, dass diese Funktion auch auf Roboterplattformen bertragen wird. Ein erfundener Dialog soll den Einsatz von AppStores plausibel machen.19

Besitzer: Roboter bitte schneide die Hecke im Garten Roboter: Dieser Task ist in meiner Anwendungsdatenbank nicht vorhanden, kann aber nachgeladen werden. Wnschen Sie ein solches Update? Besitzer: Wie hoch ist die prognostizierte Integration? Roboter: Mit der Bosch Gartenschere und einer Hecke die nicht lter ist als 36 Monate ist, kann von einen zufrieden stellendem Ergebnis ausgegangen werden. In diesem Zusammenhang darf ich sie auf ein Angebot ihres bevorzugten Werkzeug Lieferanten Bauhaus aufmerksam machen; bei dem Kauf der neuen Heckenschere Bosch Robot 2000 erhalten sie das dafr notwendige Roboapp fr alle gngigen Modelle zu halbem Preis. Besitzer: Danke Roboter ich glaube wir lassen die Hecke von meinem Sohn schneiden, der hat sicher Freude, wenn er sich etwas Geld dazu verdienen kann. Das Wissen das hier bereitgestellt wurde ist direkt in dem App eingebunden und kann so benutz werden. Das Benutzerverhalten erzeugt ein Feedback welches die weitere Entwicklung der App beeinusst.

5. Fallbeispiel mglicher Einsatz von WissensnetzwerkenMomentan liegt das Interesse in der Robotik, vorwiegend in den Bereichen der Patientenund Altenpege, des Weltraum Einsatzes, der Landesverteidigung und des Consumer Bereichs. Das trifft natrlich nur bei der Servicerobotik zu. In der industriellen Robotik werden Wissensnetzwerke verstrkt linear als Datenbank ausgefhrt. Um den Einsatz von Wissensnetzwerke zu veranschaulichen wir dies an dem Beispiel Krankenhaus Betrieb gezeigt. In einem Krankenhaus gibt es viele Aufgabenbereiche, die fr mobile Roboter geeignet sind. Alle groen Krankenhuser verfgen ber mehrere Aufzge und etliche Versorgungswege, welche die Gebude untereinander verbinden. Computergesttzte Verarbeitung von Daten, wie die Patientenidentikation, Mitarbeiter- oder Besuchererkennung sind bereits weit verbreitet und blich. Auch verwaltungsbezogene Daten wie Lagerbestnde oder Zimmerbelegungen werden mit Datenbanken verwaltet. So treffen Roboter hier auf ein sehr strukturiertes Umfeld, dies fhrt des Weiteren dazu, dass sich die Roboter leichter zu Recht nden knnen und eine sinnvolle Hilfe fr den Menschen darstellen. Die Einsatzgebiete der Roboter in einem Krankenhaus knnen grob in die drei Bereiche, Versorgung, Reinigung und die Arbeit am Patient eingeteilt werden. Die Komplexitt der Aufgabenstellung ist gestaffelt. Bei der Versorgung ist der Mensch-Roboter Kontakt am geringsten. Fllt dieser Kontakt weg, wird es einfacher, den Roboter einzusetzen, denn20

menschliches Verhalten kann fr einen Roboter oft sehr schwer zu interpretieren sein. Auerdem mssen Roboter in Menschennhe sehr vorsichtig sein. Verletzungen durch den Roboter knnten schwere Schden verursachen, wodurch das Image der Serviceroboter negativ beeinusst werden knnte und des Weiteren dazu fhren knnte, dass die Verbreitung der Serviceroboter verzgert wird. Bei der Reinigung besteht Kontakt zwischen Mensch und Roboter, jedoch ist er hier hauptschlich darauf beschrnkt, dass Roboter bei der Reinigung nicht mit dem Menschen kollidieren. In der Bei der Arbeit am Patient kommen dann verschiedene Kontaktpunkte zwischen Mensch und Roboter zustande. Diese Kontaktpunkte entstehen bei kooperativem Arbeiten, dies kann beispielsweise einfache Kommunikation zwischen Mensch und Roboter sein. Diese K o m m u n i k a t i o n k a n n d e s We i t e r e n , b e i k o m p l e x e r e n S y s t e m e n m i t Erinnerungsfunktionen auf Seiten der Roboter versehen sein oder auch Features, wie Verstehen und Interpretieren von verschiedenen Tagesverfassungen der Mitarbeiter, Patienten oder Besucher, beinhalten.

5.1. VersorgungIn den Bereich Versorgung fallen Aufgaben, die zusammengefasst werden unter dem Begriff: Bereitstellung von Ressourcen fr den Krankenhausbetrieb. In diesen Bereich Fallen Aufgaben wie: Lagerhaltung, sortieren, transportieren, verpacken, auspacken, umbauen, aufbauen, reparieren und informieren. Je fter eine Aufgabe in einem bestimmen Zeitraum wiederholt wird, desto eher kann ein bestimmtes Robotermodell dafr eingesetzt werden. Fr Transportdienste knnen an verschieden Stellen Autonomous guided vehicles (AGVs) eingesetzt werden. Bei der Modellentscheidung ist zu beachten, dass in einem Krankenhaus sehr viele verschiedene Transportdienste anfallen. Dies bedeutet, dass Spezikationen wie Wiederholrate, Last, Tragkraft, Mae, Masseschwerpunkt und Transportweg variabel sind. Aus diesem Grund wrde sich der neue Roboter BallIP (Abbildung 10) von Herrn Dr. Kumagai von der Tohoku Gakuin University anbieten.

Abbildung 10: Dr. Masaaki, 2010 Einsatzmglichkeiten von BallIP Quelle: http://spectrum.ieee.org/automaton/robotics/robotics-software/042910-a-robotthat-balances-on-a-ball [Abgerufen 11.06.2011]21

Der BallIP wurde nach dem Prinzip eines inversen Pendels entwickelt und konstruiert. Mit diesem Roboter knnen kooperative Arbeitsschritte mit Menschen und Roboter erledigt werden, sollte die Last zu gro oder zu sperrig sein. Das Gewicht des Roboters mit ca. 10 Kilogramm macht ihn unter Menschen zu einem sicheren Partner. Seine Traglast von 20 Kilogramm ist verhltnismig zu seinem Eigengewicht, sehr hoch. Dieser Roboter knnte aus einem Wissensnetzwerk Informationen wie optimale Transportwege aus einem Lageplan, beispielsweise den krzesten Weg oder Lasteigenschaften des zu transportierenden Objektes beziehen. Er knnte Informationen wie lokale Behinderungen, momentane Position und Zustand des Transportobjektes in das Netzwerk eintragen. Sollte eine Einheit whrend eines Einsatzes ausfallen, knnte ein zweiter eingesetzt werden oder eine Serviceeinheit den Ausfall beheben. Bei der Lagerhaltung von Medikamenten und Verbrauchsmaterialien gibt es zwei sehr sinnvolle Produkte, welche eingesetzt werden knnen. Zum einen gibt es ein Lagerhaltungssystem (Abbildung 11) welches mit mobilen Robotern arbeitet, die bei einer Bestellung nicht nur das gewnschte Produkt bringen, sondern das gesamte Regal, auf dem sich das bestellte Produkt bendet. Die Firma, welche das Lagerhaltungssystem in ihrem Sortiment hat trgt den Namen Kiva Systems und der Name des Produkts ist (Kiva MFS). Die Abkrzung MFS steht fr Kiva mobile-robotic fulllment system.

Abbildung 11: kivasystems.com, 2011 Einsatzbeispiel Kiva MFS Quelle: http://www.kivasystems.com [Abgerufen 11.06.2011] Der Vorteil bei diesem System liegt in der denierten Schnittstelle, an welcher die Waren bergeben werden knnen. Daher ist es leicht mglich, exakt an dieser Stelle die Roboter zu platzieren, welche dort die Warenbergabe durchfhren. Die Lagerung der einzelnen Verbrauchsmaterialien wird ausschlielich von System selbst bernommen. Produktnamen und Stckzahlen der transportierten Objekte werden stndig im Wissensnetzwerk festgehalten und sind somit zu jedem Zeitpunkt bekannt. Fr die22

Medikation der Patienten im Krankenhaus gibt es ebenfalls Robotersysteme. Diese Robotersysteme knnen aus einer Medikamentenbank die gewnschte Medikation, in der gewnschten Menge zusammenstellen, welche zuvor fr den jeweiligen Patienten individuell zusammengestellt wurden. Die Information ber die Auswahl und Menge der Medikation fr die einzelnen Patienten werden weiterhin vom behandelnden Arzt selbst getroffen und des Weiteren direkt an den Roboter weitergegeben oder ber ein Handheld, einem elektronischen Organisationsgert in ein Wissensnetzwerk eintragen.

Abbildung 12: UCSF, 2011 Einsatzbeispiel RIVA am UCSF Medicak Center Quelle: http://www.ucsf.edu/news/2011/03/9510/new-ucsf-robotic-pharmacy-aimsimprove-patient-safety [Abgerufen 11.06.2011] Das RIVA System (Abbildung 12) welches von UCSF Medical Center entwickelt wurde und seit Oktober 2010 fehlerfrei im Einsatz ist, kann bis zu 100.000 Medikamente am Tag abpacken. Zustzlich werden die Medikamente fr den jeweiligen Patienten individuell beschriftet und mit Hilfe eines Gummiringes zu praktischen Pckchen zusammengehngt. Durch dieses System entstehen nicht nur weniger Verwechslungen der Medikamente, welche ansonsten durch die Verwaltung hervorgerufen werden knnen, sondern auch die Patienten selbst sind besser ber ihre Medikation informiert. Da sich sehr viele unterschiedliche Menschen in einem Krankenaus aufhalten besteht ein groes Bedrfnis an Information jeglicher Art. Diese Informationen knnen das Krankenaus selbst betreffen, wie Wegbeschreibungen oder bestimmte Dienstleistungen aber auch schnell und praktisch ber Patienten und dessen Krankheiten, Diagnosen und Behandlungsmglichkeiten informieren oder ganz allgemeine Daten, wie solche ber das morgige Wetter bereitstellen. Fr diese Informationsbereitstellung eignen sich hervorragend Roboter, welche sich frei auf dem Gelnde des Krankenhauses bewegen knnen. Des Weiteren bentigen die Roboter Spracherkennung und Sprachsynthese. Um die Anfragen der Fragenden zu verstehen und sie beantworten zu knnen, muss eine starke Integration von verschieden Wissensnetzwerke vorhanden sein. Des Weiteren ist ein ansprechendes Aussehen, sowie ein sympathisches Auftreten sehr von Vorteil und von groer Bedeutung, da damit zu rechnen ist, dass nicht alle Menschen ohne Berhrungsangst gegenber Robotern sind.

23

Abbildung 13: GOSTAI, 2011 Jazz von Gostai und Grenvergeich Quelle: http://www.gostai.com [Abgerufen 11.06.2011] Hier wrde sich sehr der neue Roboter Jazz (Abbildung 13) von Gostai anbieten. Dieser verfgt ber eine sehr einfache Anbindung an Wissensnetzwerke durch Urbi. Die Verwendung von ausschlielich einem Modell am ganzen Gelnde erleichtert den Kontakt fr den Fragenden, den Mensch. Die Bereiche verpacken, auspacken, umbauen, aufbauen und reparieren knnen je nach Aufwand von Menschen oder handelsblichen Industrierobotern erledigt werden. Auch hier wre es mglich mit einer bergeordneten Intelligenz Industrieroboter in ein Wissensnetzwerk einzubinden.

5.2. Reinigung und berwachenDie einfachste Reinigungsarbeit ist das Bodenputzen - nass und trocken. Hier sollten Gerte eingesetzt werden, die eine bestimme Gre nicht unterschreiten, da dies zu ungewollten Zusammensten von Mensch und Robotern fhren kann. Gerte wie der AutoVacC 6 (Abbildung 14 Seite 26) von der Firma Robosoft sind robuste Industriemaschinen, die ausreichend gro, sicher und autonom sind, um den Anforderungen eines Krankenhauses gerecht zu werden. Die Reinigung der Bden knnte voll autonom von diesen Reinigungsrobotern durchgefhrt werden, Informationen ber Zwischenflle, wie unerwartete Verschmutzungen knnen an einer zentralen Stelle fr sie bereit gestellt werden. Wird eine Auftrag unterbrochen, da nicht mehr gengend Energie oder Wasser zur Verfgung steht, knnte der Auftrag weiter gegeben werden und der Nchste knnte den Auftrag nahtlos wieder aufnehmen.24

Abbildung 14: Robosoft, 2011 Trocken Nass Reinigungsroboter Quelle: http://www.robosoft.com/img/data/AutovacC_6.pdf [Abgerufen 11.06.2011] Reinigungsaufgaben, wie Wsche waschen oder Geschirr splen bentigen keinen Roboter. Jedoch an den Schnittstellen knnte je nach Komplexitt und Monotonie ein Humanoid das Schlichten, Sortieren und Ablegen erledigen. Anbieten wrde sich fr diese Aufgabe der PR2 von Willow Garage (Abbildung 15), da dieser fr komplexe Aufgaben konstruiert wurde.

Abbildung 15: Willow Garage, 2010-2011 Anwendungsbeispiel PR2 Quelle: http://www.willowgarage.com/pages/pr2/overview [Abgerufen 11.06.2011] Das verwendete Betriebssystem ROS ist open source und ist daher sehr stabil. Stndig neue Erweiterungen, die programmiert werden, stehen daher gratis zur Verfgung. Verschiedene Projekte haben gezeigt, dass der Roboter komplexe Aufgabe, wie Billard spielen, Kuchen backen, Wsche zusammen legen und Bier holen, erledigen kann. Die Anwendungsmglichkeiten steigen zunehmend mit der Verbreitung des Roboters, wobei der erste Roboter erst am 15.12.2010 verkauft wurde, dennoch stehen bereits unzhlige Anwendungen zur Verfgung.

25

5.3. Die Arbeit am PatientDie Arbeit am Patient kann wieder unterteilt werden in die Bereiche Pege, Therapie und Operation. Die Komplexitt der Aufgabenreiche ist gestaffelt. Im Bereich der Pege kann der Kontakt zum Patient gering gehalten werden, jedoch bei der Therapie und den Operationen nimmt der Kontakt zu. Darum ist auch damit zu rechnen, dass autonome Roboter in naher Zukunft den Operationssaal nicht betreten werden. Jedoch sind Teleoperatoren, welche die endoskopischen Eingriffe verbessern, nicht mehr weg zu denken. Ein sehr bekannter und ausgereifter Teleoperator mit einer gewissen Autonomie bei der Interpolierung der angewiesenen Bewegungen heit da Vinci Surgical Robot (Abbildung 16).

Abbildung 16: da Vinci Surgery, 2010-2011 Anwendungsbeispiel da Vinci Surgery Roboter Quelle: http://www.davincisurgery.com [Abgerufen 11.06.2011] Dieser Roboter knnte mit Hilfe von Sensoren berprfen, ob es sich um den richtigen Patienten handelt, da dieser ja ber das Wissensnetzwerk auf Patienteninformationen zugreifen kann. Somit wren Verwechslungen bei Operationen mit dem Roboter ausgeschlossen. Des Weiteren knnten die Logdaten Aufschluss ber den Hergang der Operation geben und so im Fall von Komplikationen den Arzt entlasten. Um Patienten bei ihrem Krankenhaus Alltag zu untersttzen und eventuell mit ihnen einfache bungen zu machen, knnte wieder der PR2 eingesetzt werden. Fr soziale Kontakte knnten Roboter eingesetzt werden, die den Patienten beruhigen und unterhalten. Bei der Pege gibt es schon mechatronische Systeme und auch Humanoide, die ber die notwendige Komplexitt und Sicherheit verfgen und fr bestimmte Aufgaben angelernt werden knnen. Im Bereich der Therapie knnten Gerte eingesetzt werden, die verschiedene therapeutische Aufgaben erledigen knnen. Exoskeletons knnten hier einen guten Kompromiss darstellen. Passive und aktive Bewegungsablufe knnten mit diesen Gerten durchgefhrt werden. Viele Krcken und Rollsthle wren obsolet. Ein sehr ambitioniertes Projekt, welches Exoskeletons entwickelt und auch schon vertreibt ist die26

Firma Cyberdyne von dem Professor Sankai. Verschiedene Modelle stehen zur Verfgung und knnen nach einer kurzen Einlernzeit sofort vom Patienten benutzt werden. Es handelt sich nicht um das einzige Exoskeleton, jedoch ist die Einsatzvielfalt von Hybrid Assistive Limb (HAL) sehr umfangreich.

Abbildung 17: Cyberdyne, 2010-2011 Anwendungsbeispiel HAL Quelle: http://www.cyberdyne.jp/english/index.html [Abgerufen 12.06.2011] Der Exoskeleton wird unter dem Produktnahmen HAL vertrieben und ist mittlerweile in der Version 5 erhltlich. ber das OS von HAL ist nichts bekannt, aber das Auslesen von System-Zustandsinformationen, um den Genesungsprozess zu protokollieren, ist mglich. Diese Informationen knnten wieder in ein Wissensnetzwerk eingepegt werden.

5.4. Vernetzung der RoboterWie gezeigt wurde, ist es mglich, viele verschiedene Robotersysteme in einem Krankenhausbetrieb einzusetzen. Wesentlich fr die Integration der Systeme ist die Vernetzung der Roboter unter einander, sowie diese zu Datenbanken. Ein komplexes Datenverwaltungsmanagement muss erstellt werden, um die von den einzelnen Systemen erhobenen Daten richtig abzusichern. Der Zugriff von Robotern muss verwaltet werden und ist fr sich ein sehr heikles Thema. Spezielle Informationen stehen so den Robotern zur Verfgung, wie Patienten Namen, Krankheitsverlufe, Medikation oder Menwnsche. Je vielfltiger die Informationen ber den Patienten und das Krankenhaus sind, um so besser knnen Robotersysteme integriert werden. Ein weiterer Aspekt eines Wissensnetzwerks, welches mit derartig vielen Informationen von Roboter erstellt wird, kann bei richtigem Einsatz von Filtern gute Ergebnisse ber den Erfolg von Behandlungsmethoden liefern. Vergleiche zwischen z.B. Abteilungen, behandelnden rzten und Medikamenten knnten neue Ergebnisse liefern, ohne den Patient zustzlich zu belasten. Frhwarnsysteme knnten autonom kritische Systemparameter berwachen und so Fehler frhzeitig sichtbar machen. Diese Vorteile stehen der Gefahr gegenber, dass Informationen eine falsche Realitt abbilden oder diese Informationen nicht fr den vorgesehen Zweck verwendet werden. In einem Krankenhaus wird mit sehr sensiblen27

Daten gearbeitet daher ist genau zu berwachen, wem welche Information zur Verfgung steht.

6. AusblickWie verschiede Projekte zeigen, ist die Verwendung von Cloudfunktionen eine gnstige Mglichkeit, komplexe Aufgaben fr Roboter zu implementieren. Zwei wesentliche Grnde konnten gefunden werden, wieso eine Implementierung von Wissensnetzwerke angestrebt werden sollte. Das gemeinsame Aufbauen von Modellen, die im Kollektiv gentzt werden sollten, wie z.B.: Landkarten oder Erfahrungen, die meist qualitativ und quantitativ besser sind, da sie aus mehr Information aufgebaut werden knnen. Wesentlich bei Wissensnetzwerken sind die richtigen Interpretationen der gesammelten Information und das Verwenden von leistungsstarken Filtern. Der zweite Grund ist, dass Wissen in solchen Netzwerken generiert und durch Verknpfen von Informationen erweitert werden kann. Dabei knnen komplexe Rechenaufgaben entstehen, die meist vom Netzwerk selbst bernommen werden, um somit den Roboter zu entlasten. Nicht in jedem Bereich ist es sinnvoll oder mglich, ein Wissensnetzwerk einzusetzen. Ein klassisches Wissensnetzwerk besteht aus mindestens zwei Clients und einem Host, wobei dieser Host die Wissensdatenbank verwalten muss. Der Zugriff auf den Host sollte zu jeder Zeit mglich sein und die Verbindung sollte sich durch eine hohe Datenrate auszeichnen. In der mobilen Robotik ist eine kabellose bertragung erforderlich. In Produktionssttten kann unter Umstnden eine kabelgebundene bertragung sinnvoll sein. Somit ergeben sich Einschrnkungen von der technischen Seite, die den Einsatz von Wissensnetzwerken erschweren oder unmglich machen knnen. Diese Arbeit soll nicht zeigen, dass Arbeitspltze von Menschen sinnlos sind. Diese Arbeit soll zeigen, dass es mglich ist, eine alternde Gesellschaft wrdevoll zu versorgen. Roboter sollen Menschen nicht ersetzen, sondern dort helfen, wo Menschen nicht helfen wollen oder knnen. Dadurch kann dem zwischenmenschlichen Kontakt mit mehr Aufmerksamkeit gewidmet werden.

28

LiteraturverzeichnisBaxter, P., Belpaeme, T., Canamero, L., Cosi, P., Demiris, Y. & Enescu, V (2011). LongTerm Human-Robot Interaction with Young Users. In IEEE/ACM Human-Robot Interaction 2011 Gntheroth Horst und Schnert Ulf, 2007. Verfgbar unter: http://www.stern.de/digital/ online/wikipedia-wissen-fuer-alle-606048.html [Zugang am 1.Mai 2011] Harris Derrick, 2011. Verfgbar unter: http://gigaom.com/cloud/infrastructure-key-togoogles-no-downtime-guarantee/ [Zugang am 7.Mai 2011] Hickman Ryan and Rheingold Mamie, Robot hackathon connects with Android, browsers and the cloud, verfgbar unter: http://googleresearch.blogspot.com/2010/12/robothackathon-connects-with-android.html [Zugang am 15.Mai 2011] IFR Statistica department, 2010. Verfgbar unter: http://www.worldrobotics.org/ modules.php?name=News&le=article&sid=12 [Zugang am 1.Mai 2011] Kaczmarczyk Paul Peter, verfgbar unter: http://www.dfki.de/~kipp/seminar_ws0607/ reports/Soar.pdf [Zugang am 10.Mai 2011] MediaWiki, 2011. Verfgbar unter: http://www.mediawiki.org/wiki/MediaWiki [Zugang am 1.Mai 2011] The Urbi Software Development Kit, Dokumentation verfgbar unter: http://gostai.com/ downloads/urbi-sdk/2.x/doc/urbi-sdk.htmldir/ [Zugang am 24.Mai 2011] Rajesh Arumugam, Vikas Reddy Enti, Liu Bingbing, Wu Xiaojun, Krishnamoorthy Baskaran Foong Foo Kong, A.Senthil Kumar, Kang Dee Meng, and Goh Wai Kit,DAvinCi: A Cloud Computing Framework for Service Robots, verfgbar unter: http:// vikasreddyenti.com/wp/wp-content/uploads/2010/06/DAvinCiCloudComputingRobots_nal.pdf [Zugang am 15.Mai 2011] Statistik Austria, 2010. Verfgbar unter: http://www.statistik.at/web_de/statistiken/ informationsgesellschaft/ikt-einsatz_in_haushalten/index.html [Zugang am 1.Mai 2011]

AbbildungsverzeichnisAbbildung" Abbildung" Abbildung" Abbildung" Abbildung" Abbildung" Abbildung" Abbildung# Abbildung# Abbildung# Abbildung" Abbildung" Abbildung# Abbildung" Abbildung" Abbildung" Abbildung" 1:" 2:" 3:" 4:" 5:" 6:" 7:" 8:# 9:# Aktuelle Wissensnetzwerke im Internet" Die Roboterheinheiten nach Typen" Aufbau von Roboearth" Kognitive Komponenten" Nao mit den Patienten" DAvinCi Struktur " GostaiNet Struktur " Urbi Beispiel Parallelitt# Urbi Beispiel Serialitt# 1 3 4 5 6 8 9 16 17 21 22 23 24 25 25 26 27

10:# Einsatzmglichkeiten von BallIP # 11:" Einsatzbeispiel Kiva MFS " 12:" Einsatzbeispiel RIVA am UCSF Medicak Center " 13:# Jazz von Gostai und Grenvergeich# 14:" Trocken Nass Reinigungsroboter" 15:" Anwendungsbeispiel PR2" 16:" Anwendungsbeispiel da Vinci Surgery Roboter" 17:" Anwendungsbeispiel HAL"

AbkrzungsverzeichnisWWW" USB" bzw." ISBN" ADMIN" USER" U/min" ROS" IFR" IT" TB" CPU" GUI" API" SOAR" CV" SLAM" SIFT" SDK" HTTP" XMPP" SaaS" IaaS" PaaS" GNU" DAvinCi" IDE" World Wide Web Universal Serial Bus beziehungsweise Internationale Standardbuchnummer Administraren = Verwalter Anwender Umdrehungen pro Minute Robot Operating System International Federation of Robotics Informationstechnik Terabyte Central processing unit Graphical user interface Application programming interface State, Operator Apply Result Computer Vision Simultaneous localization and mapping Scale-invariant feature transform Software Development Kit Hypertext Transfer Protoco Extensible Messaging and Presence Protocol Software as a Service Ifrastructure as a Service Platform as a Service General Public License Distributed Agents with Collective Intelligence integrated development environment