Beruflich Dokumente
Kultur Dokumente
BACHELORARBEIT
zur Erlangung des akademischen Grades Bachelor of Science in Engineering
Eidesstattliche Erklrung
Ich 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.
_________________________ Unterschrift
Kurzfassung
Was 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.
Abstract
What 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.
Danksagung
Die 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.
Inhaltsverzeichnis
1.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 5
6 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 11
12 12
15
15 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
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,
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.
Einteilung keiner Denition gleichkommen, sondern nur im Hinblick auf den Arbeitsumfang eine sinnvolle Abgrenzung schaffen.
2.1. RoboEarth
Grundlage 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-E
Roboter 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 bis
5
zu fnf Tage dauert getestet. Diese ersten Ergebnisse bilden die Grundlage fr die Fallstudie. Tony Belpaeme (2011)
2.2.1. Fallstudie
Zielgruppe 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)
Abbildung 5: aliz-e.org, 2010 Nao mit den Patienten Quelle: http://www.aliz-e.org [Abgerufen 11.06.2011]
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)
werden. Anhand dieser Zahlen ist erkennbar, dass private Projekte auch wenn sie qualitative hochwertiger sind, quantitativ nicht vergleichen lassen.
2.5. GostaiNet
GostaiNet 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.
3. Programmiersprachen
Ein 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 sehr
10
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.
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. RobotStudio
Das 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.
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
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
ENDPROC
Der 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 es
13
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.
ENDPROC
Das 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
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.
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);
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.
4.1. Wahrnehmung
Typische 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 wie
18
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.3. Planen
Cloudfunktionen, 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.
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.
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. Versorgung
In 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 die
22
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.
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
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 die
26
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.
Daten gearbeitet daher ist genau zu berwachen, wem welche Information zur Verfgung steht.
6. Ausblick
Wie 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
Literaturverzeichnis
Baxter, 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]
Abbildungsverzeichnis
Abbildung" 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"
Abkrzungsverzeichnis
WWW" 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