Roboter-Programmierung

Günter Herkommer,

Das Potential des Microsoft Robotics Developer Studio

Mit dem „Robotics Developer Studio“ adressiert Microsoft erstmals die Domäne klassischer Maschinenbauer. Serviceorientierung, grafische Programmierung und visuelle Simulation soll ihnen neue Möglichkeiten für die Erstellung von Robotik-Applikationen eröffnen.

Die Version 1.0 des Microsoft „Robotics Developer Studio" - kurz RDS - wurde im Dezember 2006 veröffentlicht. Dem voraus ging ein Artikel von Bill Gates im Magazin „Scientific American", in dem der Software-Visionär den Zustand der heutigen Roboterindustrie mit der Computerindustrie von vor 30 Jahren vergleicht und darin die Meinung vertritt, dass die große Heterogenität von Hardund Software in der Robotik die Entwicklung neuer und innovativer Produkte verhindert. Mit dem Robotics Developer Studio verfolgt Microsoft daher das Ziel, eine herstellerunabhängige Plattform zu schaffen, um die Programmierung von Robotern einfacher und effizienter zu gestalten.  Die aktuelle Version, das Microsoft Robotics Developer Studio 2008, ist seit November letzten Jahres in einer kommerziellen und einer kostenfreien Variante verfügbar.

Die windowsbasierte Entwicklungsumgebung besteht aus einer visuellen Programmiersprache (Visual Programming Language), einer physikunterstützten Simulationsumgebung (Visual Simulation Environment) und einer speziellen Laufzeit-Umgebung. Diese unterteilt sich in die „Concurrency and Coordination Runtime" (CCR) und die „Decentralized Software Services" (DSS). RDS funktioniert sowohl unter Windows XP und Windows Vista als auch unter Windows  CE (hier jedoch nur die Laufzeit-Umgebung). Anwendungen lassen sich in jeder Programmiersprache des Microsoft .NET-Framework und mit Visual Studio entwickeln.

Die beiden Bausteine CCR und DSS sind Programmbibliotheken, welche die Basisfunktionalität für die inhärent komplexe Programmierung von verteilten und nebenläufigen Roboteranwendungen bereitstellen. Nebenläufige Anwendungen zeichnen sich dadurch aus, dass mehrere Prozesse gleichzeitig und voneinander unabhängig bearbeitet werden. Ein typisches Beispiel aus der Robotik ist das parallele Steuern mehrerer Aktuatoren, oftmals inklusive gleichzeitiger Verarbeitung vom Sensor-Feedback. Die CCR vereinfacht die Programmierung solcher Anwendungen, indem sie beispielsweise asynchrone Funktionsaufrufe ermöglicht und Funktionalität zur Synchronisierung der einzelnen, nebenläufigen Prozesse bietet.

Anzeige

Service-Orchestrierung der Steuerungsprogramme

Die serviceorientierte Architektur Grundidee des RDS ist die serviceorientierte Entwicklung von Applikationen für die Robotik. Im Gegensatz zu herkömmlichen Anwendungen entsteht durch diesen Ansatz nicht ein großes, monolithisches Programm, sondern es werden feingranulare Dienste beziehungsweise „Services" entwickelt, die über einen internen Zustand verfügen und eigenständig ablauffähige Programme darstellen. Komplexe Steuerungsprogramme lassen sich auf diese Weise flexibel und unter dem Gesichtspunkt der Wiederverwendbarkeit aus einzelnen Services zusammensetzen (Service-Orchestrierung).

Dienste verfügen über einen Servicekontrakt, der die von ihnen angebotene Funktionalität definiert. Der Aufruf von Operationen erfolgt durch das Versenden von Nachrichten zwischen Diensten. Die Ergebnisse der Operationen werden asynchron ebenfalls per Nachricht übermittelt. Ein Dienst kann zum Beispiel einen Industrieroboter steuern oder einen Sensor abfragen. Mit DSS steht eine Laufzeitumgebung für die Veröffentlichung, Suche und Ausführung von Services zur Verfügung. Diese enthält unter anderem die vollständige Infrastruktur für das Senden und Empfangen von Nachrichten mittels eines vorgegebenen, standardisierten Kommunikationsprotokolls. Services können sowohl innerhalb des gleichen Systems als auch über Systemgrenzen hinweg per Netzwerk kommunizieren. Sogar eine Verteilung über das Internet ist möglich. DSS deckt sämtliche Aspekte der Verteilung und Kommunikation zwischen Services ab und verbirgt diese sowohl vor dem Entwickler als auch dem Benutzer. Mit Hilfe eines Browsers können laufende Dienste eingesehen und verwaltet werden.

Services einfach gegeneinander austauschen

Ein weiterer interessanter Gesichtspunkt der serviceorientierten Architektur ist die einfache Austauschbarkeit einzelner Dienste. Alle Services, die den gleichen Servicekontrakt erfüllen, sind untereinander austauschbar. Dazu ist es weder erforderlich, Programmcode zu ändern, noch das Steuerprogramm erneut zu compilieren. Was die Visual Simulation Environment für die Simulation von Robotern und Maschinen in einer virtuellen 3D-Umgebung betrifft, greift Microsoft auf Technologien aus der Computerspiele-Industrie zurück. Für die realitätsnahe Darstellung der dreidimensionalen Modelle dient das so genannte XNA-Framework, welches unter anderem die Entwicklung von 3D-Anwendungen auf der Basis von DirectX vereinfacht. Zusätzlich sorgt die Integration der PhysX-Technologie von NVidia für eine realitätsnahe Simulation der Physik in Echtzeit.

Ansteuerung von außerhalb der Simulationsumgebung

Somit vereinfacht RDS die schnelle prototypische Implementierung von Robotikanwendungen, da diese zuerst in einer realitätsnahen Simulation testbar sind, bevor die Installation auf realer Hardware erfolgt. Alle Objekte in der virtuellen 3D-Umgebung (Roboter, Sensoren etc.) haben sowohl eine grafische als auch eine physikalische Repräsentation. Die grafische Repräsentation besteht aus einem Drahtgittermodell und bildet die Grundlage für die detailgetreue, texturierte Darstellung der Objekte. Die physikalische Repräsentation ist durch eine kinematische Kette starrer Körper modelliert. Zwischen den starren Körpern lassen sich durch Federn modellierte Gelenke und Motoren definieren.

In der Regel approximiert die physikalische Repräsentation das Drahtgittermodell und dient der physikalischen Berechnung sowie der Kollisionserkennung. Durch eine Koppelung der simulierten Objekte mit Diensten wird eine Ansteuerung von außerhalb der Simulationsumgebung möglich. Auf diese Weise lassen sich sowohl simulierte Roboter steuern als auch Sensoren abfragen. Um eine einfache Austauschbarkeit von Simulation und realer Hardware zu erreichen, müssen sowohl der Dienst für das simulierte Objekt als auch der für die reale Hardware den gleichen Servicekontrakt erfüllen. Die Dienste sind dan einfach gegeneinander austauschbar.

Eine Vielzahl vorgefertigter Objekte für die virtuelle 3D-Umgebung ist bereits in RDS integriert. Neben Kleinstrobotern aus der Unterhaltungsindustrie - zum Beispiel dem Lego NXT - sind Modelle wie der LBR3 von Kuka und der Lasersensor LMS200 von Sick vorhanden. Darüber hinaus können Anwender über den Import von CAD-Daten eigene Modelle entwickeln. Sind detaillierte Informationen zu physikalischen Eigenschaften des Modells in diesen Daten enthalten, so sind diese direkt für das physikalische Modell in der Simulation des RDS verwendbar. Andernfalls muss der Entwickler das physikalische Modell selbst aus elementaren Formen und Gelenken zusammensetzen.

Die Visual Programming Language

Die Komponenten des Microsoft Robotics Developer Studios. Zusätzlich liefert Microsoft eine Vielzahl von Beispielen und Tutorials mit, um den Einstieg in die Entwicklungsumgebung zu erleichtern.

Für die „Orchestrierung" einzelner Services zu Anwendungen bietet RDS mit der Visual Programming Language (VPL) eine grafische Programmier-Umgebung. Ein einfach per Drag&Drop zu bedienender Editor hilft bei der Entwicklung von grafischen Programmen. Ein solches Programm hat die Form eines gerichteten Graphen, durch den bei der Ausführung entlang der Kantenrichtungen Daten ausgetauscht werden. Die Knoten des Graphen heißen „Aktivitäten". Eine Aktivität kann die Definition eines Datenwerts, eine Berechnung oder eine Wertzuweisung sein. Die Realisierung komplexer Aktivitäten - wie die Ausführung einer Aktion durch eine Maschine oder das Abfragen eines Sensorwerts - erfolgt durch Service- Aufrufe.

So kann beispielsweise ein Roboter mittels seines Steuerservices in ein grafisches Programm eingebunden werden. Weiterhin ist es möglich, logisch zusammengehörende Graphen wieder als eigene Aktivitäten zu kapseln und als solche in einem grafischen Programm der VPL zu verwenden. Das erhöht einerseits die Übersichtlichkeit bei größeren Abläufen, andererseits ermöglicht es eine einfache Wiederverwendung in sich abgeschlossener Funktionalitäten.

Das Potenzial für die Automatisierungsbranche Mit der visuellen Simulationsumgebung liefert das Robotics Developer Studio bereits einen geeigneten Rahmen, um eine Visualisierung von Automatisierungsanlagen und Fertigungsprozessen zu realisieren. Durch die einfache Erweiterbarkeit und die Integration der Simulationsumgebung in eigene Applikationen sind Visualisierungen und Simulationen nicht von Grund auf neu zu programmieren. Darüber hinaus ist die Offline-Programmierung von Industrierobotern möglich. Roboterprogramme können somit bereits vor der eigentlichen Inbetriebnahme der Fertigungsstraße entwickelt und deren Taktzeiten optimiert werden. Zwar bieten auch die etablierten Roboter-Anbieter wie ABB und Kuka bereits passende Software, um ihre Robotersysteme in einer Simulationsumgebung offline zu programmieren. Jedoch sind diese Anwendungen stark auf den jeweiligen Hersteller zugeschnitten.

Wie erwähnt, erlaubt die serviceorientierte Architektur einen einfachen Austausch verschiedener Services. Dies ermöglicht es, eine Anwendung zunächst mit einem simulierten Roboter zu programmieren und zu testen. Später kann dieselbe Anwendung mit einem realen Roboter ausgeführt werden, ohne dass der Quellcode zu ändern ist. Weiterhin sind unterschiedliche Implementierungen einer Funktion, zum Beispiel von verschiedenen Herstellern, gegeneinander austauschbar. Dadurch ist ein flexibler und kostengünstiger Einsatz von Anlagen und Maschinen beliebiger Hersteller möglich.

Verwendung von Standardtechnologien

Ein großer Reiz der Microsoft-Lösung besteht darin, dass durch die Verwendung von Standardtechnologien wie Windows und dem .NET-Framework wesentlich mehr Entwickler erreichbar sind, als mit branchenspezifischen Lösungen und Technologien. Viele Standardaufgaben wie Spracherkennung oder Bildverarbeitung können durch Lösungen externer Zulieferer, die sich auf eine dieser Aufgaben spezialisiert haben, eingekauft werden. Doch auch die großen Industrieroboterhersteller haben die neuen Ideen des Robotics Developer Studios bereits aufgegriffen. ABB Robotics bietet für das hauseigene Programm zur Offline-Programmierung „RobotStudio" inzwischen eine Komponente an, mit dem die Simulationsumgebung des RDS ansteuerbar ist.

Die grafische und physikalische Repräsentation eines Industrieroboters im Vergleich: Komplexe Mechanik wird durch einfache Körper nachgebildet.

Kuka Roboter wiederum hat mit seinem „Educational Framework" eine Lehrumgebung zur Verfügung gestellt, die auf RDS aufsetzt und Grundlagenwissen zum Beispiel zu Kinematik und Bahnplanung vermittelt. Mittels der integrierten Simulationsumgebung kann jeder Robotik-Interessierte Erfahrungen sammeln, ohne in teure Hardware investieren zu müssen. Weitere Hersteller wie Hokuyo Automatic bieten sowohl Modelle und Services für die Simulation in RDS als auch Dienste für die Ansteuerung ihrer realen Produkte über das RDS an.

Die Grenzen von RDS

Trotz aller Vorteile hat die aktuell vorliegende Version des Robotics Developer Studios einige Einschränkungen. Viele Industrie-Anwendungen erfordern harte Echtzeit bei der Ausführung. Diese können - alleine schon wegen der Ausführung unter einem nicht echtzeitfähigen Betriebssystem - nicht eingehalten werden. Die aktuell mitgelieferten Beispiele und Treiber für echte Hardware zielen zudem mehr auf Servicerobotik als auf Industrierobotik ab. So sind beispielsweise Treiber für Lego-NXT und iRobot Create-Roboter verfügbar, jedoch kein Treiber, um einen realen Knickarmroboter zu steuern.

Die der Simulationsumgebung zugrundeliegende PhysX-Engine verbessert die Darstellung dadurch, dass sich Objekte grundsätzlich realistisch verhalten. Allerdings handelt es sich dabei um eine Physik-Engine aus dem Spielebereich, die darauf optimiert ist, auf herkömmlichen Computersystemen eine möglichst realistische Simulation zu bieten. Dementsprechend ist das physikalische Modell an einigen Stellen eingeschränkt und daher nicht mit aufwendigen physikalischen Simulationen vergleichbar.

Spagat für Einstiegsprogrammierer und Profis

Beispiel für die Visual Programming Language: Durch das grafische Verknüpfen einzelner Aktivitäten per Drag&Drop sind komplexe, nebenläufige Abläufe einfach programmierbar.

Bei der Visual Programming Language versucht Microsoft den Spagat, wenig erfahrenen Programmierern den Einstieg in die Ablaufsteuerung und Koordination verteilter Dienste zu ermöglichen, gleichzeitig aber auch professionellen Programmierern ein interessantes Werkzeug zu bieten. Die Beschreibung von Abläufen auf grafischer Ebene ist geeignet für die Modellierung von Prozessen, ähnlich der Business Process Execution Language (BPEL) für die Modellierung von Geschäftsprozessen mit Web-Services. Jedoch ersetzt VPL nicht die Entwicklung „klassischer" Services, insbesondere wenn es sich um die komplexe Ansteuerung von Hardware-Geräten handelt.

Ungeachtet dieser Einschränkungen bietet das Microsoft Robotics Developer Studio einige interessante Aspekte für die Robotik- und Automatisierungsbranche. Besonders hervorzuheben ist die serviceorientierte Architektur. Im Bereich der IT-Systeme hat sich gezeigt, dass Serviceorientierung die Wartbarkeit, Austauschbarkeit und Wiederverwendbarkeit von Software enorm steigert. Dementsprechend ist es sinnvoll, dieses Konzept auch in anderen Bereichen zu verwenden, in denen die Software-Entwicklung eine wesentliche Rolle spielt. Ferner bietet die Simulationsumgebung ein großes Potenzial für die Entwicklung virtueller Prototypen. Ob sich das RDS in der industriellen Anwendung durchsetzen kann, hängt nicht zuletzt von der nachhaltigen Akzeptanz bei den Herstellern ab.

Autoren:
Andreas Angerer ist wissenschaftlicher Mitarbeiter am Institut für Software & Systems Engineering an der Universität Augsburg.

Alwin Hoffmann ist wissenschaftlicher Mitarbeiter am Institut für Software & Systems Engineering an der Universität Augsburg.

Dr. Frank Ortmeier ist Akademischer Rat am Institut für Software & Systems Engineering an der Universität Augsburg.

Michael Vistein ist wissenschaftlicher Mitarbeiter am Institut für Software & Systems Engineering an der Universität Augsburg.

  • Xing Icon
  • LinkedIn Icon
Anzeige
Anzeige

Das könnte Sie auch interessieren

Anzeige

Bachmann

Mehr Sicherheit für die Industrie

Die ‚atvise‘-Produktfamilie von Bachmann, die Visualisierung, Bedienung, Betriebsdatenerfassung und Leitstand-Technik (SCADA) auf Basis von OPC UA und Webtechnologie umfasst, hat mit den Versionen 3.13 und 3.14 wichtige Updates erhalten.

mehr...

Inosoft

Retrofit von Industrierechnern

Wenn bewährte IPCs in die Jahre kommen, steigt nicht nur das Ausfallrisiko, auch fehlende Sicherheitsupdates werden zum Problem. Ein durchdachter Retrofit kann helfen, bestehende Anlagen wirtschaftlich und regulatorisch konform weiter zu betreiben.

mehr...
Anzeige
Anzeige

Polyrack

Die richtige Anzeige für HMIs

Von LCD bis E-Paper – die Displaywahl beeinflusst Bedienbarkeit, Energie-verbrauch und Produktlebensdauer von HMIs. Neben technologischen Parametern spielen Integration, EMV-Design und Sourcing eine Rolle. Der Artikel gibt einen strukturierten...

mehr...
Anzeige

Pepperl+Fuchs

Sichere Authentifizierung mit HMIs

Im Reinraum wird jeder Login zur Herausforderung: Strenge GMP-Vorgaben, komplexe Passwörter und lückenlose Rückverfolgbarkeit treffen auf Handschuhe, Schutzkleidung und Zeitdruck. Was wie ein Detail wirkt, beeinflusst Effizienz, Sicherheit und...

mehr...
Anzeige
Anzeige
Anzeige
Jetzt Newsletter abonnieren