Idee, System-Architektur: Andreas Döpkens
Programmierung: Brian Schüler
Mit einem Prozessleitsystem (engl. process control system) ist im technischen Sinne und in einer starken Vereinfachung, wie sie die meisten Menschen in sich tragen dürften, eigentlich eine große Industrieanlage zur Steuerung von komplexen Prozessen assoziiert, die aus vielen Sensoren und Aktuatoren wie Pumpen, Ventilen udgl. besteht. Abgesehen von den vielen Monitoren, auf denen die unzähligen Zustände der jeweiligen Prozesse dargestellt sind, existieren riesige Schaltschränke, in denen die Steuerelektronik untergebracht ist.
Zwei Prozessleitsysteme: das acaPCS-Maze und das acaPCS-Football
Das acaPCS (derer gab es bis November 2018 noch zwei semantisch und syntaktisch verschiedene, die nichts miteinander zu tun hatten; jedoch sind beide über die acaBridge Software-verwaltungstechnisch zu einem einzigen Prozessleitsystem geworden, s.u., haben ihre individuellen Namen acaPCS-Maze und acaPCS-Football jedoch behalten) hat von alledem nicht viel zu bieten und entspricht in seinem Aufbau deshalb überhaupt nicht dem oben geschilderten Bild eines klassischen Prozessleitsystems. Da den "Prozessen" in einem klassischen Prozessleitsystem im acaPCS die gesteuerten Bewegungsabläufe sowohl unserer realen Roboter im Maze/Labyrinth und unserer realen Roboter auf dem Fußballplatz sowie unsere virtuellen Roboter in den zwei Simulatoren "maze" und "foothall" entsprechen, hätten wir (bis November 2018) unsere beiden "Prozess-Anlagen" (das acaPCS-Maze und acaPCS-Football) in einer etwas schärferen semantischen Abgrenzung auch acaRCS (robot control system) nennen können. Wahrscheinlich wäre diese Bezeichnung passender gewesen, aber wir haben uns vor Jahren auf PCS eingeschossen, und nicht RCS, und bleiben deshalb aus historischen Gründen bei dieser Bezeichnung.
Zum Einsatz kommt das acaPCS-Maze für einfache Roboter-Steueraufgaben zur Lokalisation und Navigation bis hin zu komplexen Anwendungen wie Slam (simultaneaous localisation and mapping). Das acaPCS-Football dient der Steuerung unserer beiden Fußball-Roboter, für die intelligente Verhaltensalgorithmen für den Kicker und Goal-Keeper entwickelt wurden und werden.
Beide acaPCS-Einrichtungen zur Steuerung unserer "realen" Roboter bestehen aus den drei Komponenten Viewer, Controller und Steuercode. Diese drei Instanzen sollen im folgenden vorgestellt werden.
Zwei Viewer im acaPCS: acaView-Maze und acaView-Football
Bei einem Viewer handelt es sich um eine Beobachtungseinrichtung zur Visualisierung der (realen) Roboterpositionen in einem vorgegebenen Gelände. Für unsere beiden Prozessleitsysteme haben wir zwei Viewer, einmal für unser Maze/Labyrinth (s. Abb. rechts) den acaView-Maze und einmal für unseren Fußballplatz den acaView-Football. Wie aus den Abbildungen (rechts) erkennbar ist, besteht der Viewer aus einem Hardware- und einem Softwareteil. Der Hardwareteil umfasst in beiden Fällen ein an einem Raspberry Pi angeschlossenes Kamerasystem (s.u.), das über dem jeweiligen Gelände, auf dem sich die Roboter bewegen, installiert ist. Der Softwareteil ist eine App, Webanwendung oder ein PC-Programm, in dem die Roboter-Positionen und ihre Bewegungen grafisch dargestellt werden.
der acaView-Maze
Viewer der ersten Generation, Java Processing (Bachelorarbeit Eric D.)
Raspberry Pi gesteuertes 6-Kamera-System (Bachelorarbeit Angelo G.)
verbesserter Viewer als Android-App (Bachelorarbeit Yannic D.)
Die Größe des Labyrinths (engl. Maze), das ist die sogenannte "Welt", in der die Roboter sich bewegen, beträgt 1,50 x 1,50 Meter. Je nach Aufgabenstellung kann diese Welt in einer Modellauffassung als ein Fabrikgelände, ein Museum, eine Krankenstation oder einfach eine Wohnung verstanden werden, in der "Service-Roboter" ihre Dienste (alleine oder im Verbund) verrichten. Eine "beliebte" Aufgabe besteht z.B. darin, einen Roboter möglichst effizient die ganze Wohnung staubsaugen zu lassen.
Über dem Labyrinth an einem Dachgestänge angebracht befinden sich sechs Kameras (Pixie-Cams), um die gesamte Fläche abzudecken. Die Kameras sind über einen USB-Hub mit einem Raspberry Pi verbunden. Auf ihm fügt ein Programm mit openCV-Funktionen die Einzelbilder der sechs Kameras zu einem Gesamtbild zusammen. Ausgestattet mit einer eigenen Steuerlogik für die doch sehr rechenintensive Bildbearbeitung können die Kameras bis zu acht Farben unterscheiden und mehrere hundert Objekte registrieren, und das bei 50 Bildern pro Sekunde! Damit lassen sich in dem Prozessverbund einer zu realisierenden Aufgabenstellung bis zu acht Roboter unterscheiden (theoretisch, denn ab vier Robotern wird es recht eng und ungemütlich in dem Labyrinth), die auf ihrer Oberseite eine zweifache Farbmarkierung angebracht haben, um Position und Orientierung zu bestimmen. Die zentimetergenauen, kartesischen Positions- und Orientierungsdaten können über WLan abgefragt werden. Sie werden im JSON-Format übertragen.
Die unmittelbare Hinderniserkennung in dem Labyrinth geschieht über die jeweiligen Sensoren in den Robotern. Je nach Roboter sind das Infrarot-, Ultraschall- oder Laser-Einrichtungen. Die hierbei anfallenden Daten können ebenfalls abgefragt werden, damit das Prozessleitsystem diese bei den fortwährenden Prozessaktualisierungsberechnungen berücksichtigen kann. Z.B. könnte sich durch das plötzliche Auftauchen eines dynamischen Objektes (z.B. ein Arbeiter auf einem Fabrikgelände, ein Besucher in einem Museum, ein Einbrecher in einer Wohnung), das eben gerade noch nicht da war, eine kürzeste Wegberechnung von A nach B für einen der Roboter verändern, wenn das Objekt umfahren werden soll. Das Prozessleitsystem könnte aber auch entscheiden, dass dieser Roboter, falls seine derzeitige Aufgabe nicht zeitkritisch ist, für eine bestimmte Zeit anhält und einfach nur wartet, bis das Objekt wieder verschwunden ist.
Die Viewer-Einrichtung von acaPCS-Maze verfügt ferner über einen Softwareteil. Auf dem Monitor werden sämtliche in dem Labyrinth sich aufhaltenden Roboter sowie weitere Hindernisse, so sie eine Farbmarkierung aufweisen, angezeigt. Die Bewegungen der Roboter können für Diagnosezwecke aufgezeichnet werden.
der acaView-Football (als Bachelorarbeit verfügbar)
Dieser Viewer existiert noch nicht. Das Prinzip ist jedoch identisch mit dem des acaView-Maze. Falls du Lust hast, ihn als Bachelorarbeit zu programmieren, melde dich bei uns.
the acaBridge - der Universal-Controller im "gebridgeten" acaPCS Prozessleitsystem
Idee, System-Architektur - Andreas Döpkens
(mit besonderem Dank an Martin von Löwis und Christian Forler)
Programmierung - Brian Schüler
Mit steigender Anzahl an realen und virtuellen Robotern sowie steigender Komplexität im organisierten Prozesshandling und der Programmierung der Roboter bezüglich verschiedener Tasks für ebendiese Roboter, haben wir es uns schließlich zur acaLab-Aufgabe gemacht, sämtliche von uns entwickelten Roboter, seien sie real oder virtuell, über einen gemeinsamen Controller zu steuern. Hierbei ist im November 2018 die sogenannte acaBridge entstanden, eine sehr mächtige und flexible Server-Schnittstelle mit einheitlichen Kommando- und Datenprotokollen für alle an der acaBridge angeschlossenen Ressourcen (Roboter, Kameras, Server-Algorithmen). In vereinfachter Darstellung kann man die Verwendung der acaBridge folgendermaßen beschreiben:
Jede Ressource ist zunächst einmal als ein Server zu verstehen, der sich bei der acaBridge über einen Web-Socket mit der acaBridge verbinden (connect) und vor allem auch registrieren muss. Daraufhin können Clients (Anwenderprogramme) sich ebenfalls über einen Web-Socket mit der acaBridge verbinden, sich von dieser eine Liste der aktuell verfügbaren Server (resources list) zusenden lassen, und aus dieser Liste den oder auch die benötigten Server für die Dauer der Socket-Verbindung reservieren (reserve). Wurden zwei Server (z.B. "robotXY" und "drive clothoide") von einem Client erfolgreich reserviert, sind diese für alle anderen Clients gesperrt. Der Client kann nun Kommandos an die von ihm reservierten Server schicken (z.B. an den oben genannten Roboter einen velocity-Befehl). Möchte der Client selbst aber - ganz abstrakt - einfach nur den Roboter eine Clothoide fahren lassen und dafür dem Server "drive Clothoide" die Roboter-Steuerung überlassen, muss er diesem Server dafür die Vollmacht erteilen (permission granted).
Die acaBridge ist ...
Eine große Herausforderung war und ist die semantische Klärung, was die acaBridge eigentlich im terminologischen Kontext der sogenannten Design-Pattern im Bereich der Verteilten Systeme und Rechnernetzwerke ist. Für uns "Roboter-Bauer" ist die acaBridge im Rahmen der Realisierung eines versatilen Prozessleitsystems zunächst einmal ein Controller, der es ermöglicht, dass verschiedene Clients/Anwenderprogramme die Roboter bewegen. Sie ist, metaphorisch, eine "Bridge" zwischen Anwenderprogrammen und Robotern. Jenseits dieser metaphorischen Verwendung der Bezeichnung Bridge vermittelt die acaBridge in Server-Client-Terminologie als Dienstprogramm aber auch den Datenverkehr zwischen Clients/Anwenderprogrammen und Roboter-Servern. Hierbei gilt jedoch: die acaBridge selbst als aktiver Datenvermittler verhält sich dem anfragenden Client/Anwenderprogramm gegenüber wie ein Server, der anderen Seite hingegen, dem Zielsystem bzw. Roboter-Server, gegenüber wie ein Client. Dies ist die typische Arbeitsweise eines Proxy(-Servers). Die acaBridge könnte aber auch ein Broker genannt werden (die Mehrheit der Gelehrten ist diesbezüglich einer Meinung), denn der Broker muss einen Client mit spezifischen Objekten/Servern verbinden können und Interaktionen zwischen Servern (hier z.B. zwischen einem Dijkstra- oder Clothoiden-Server-Algorithmus und einem realen oder virtuellen Roboter-Server verwalten. Was auch immer die acaBridge letztlich terminologisch passend sein mag, eine metaphorische "Bridge" (auf einem Schiff) zwischen Clients (Captain auf einem Schiff) und Servern (Mannschaft) ist sie ganz bestimmt.
Eine große Erleichterung im Handling der oben genannten, ehemaligen zwei acaPCS Varianten namens acaPCS-Maze und acaPCS-Football bringt die acaBridge mit sich: es braucht keine zwei unterschiedlichen Prozessleitsysteme für das Labyrinth/Maze und den Fußballplatz/Pitch mehr geben, da die acaBridge jeden beliebigen Roboter, real oder virtuell, mit jedem beliebigen Anwenderprogramm verbinden kann. Die acaBridge ist somit der zentrale Kern und Universal-Controller des einen und einzigen "gebridgeten" acaPCS.
hier folgt in Kürze der graphische Funktionsplan der acaBridge und die Protokoll-Spezifikation ...
Simulatoren im "gebridgeten" acaPCS-Prozessleitsystem
"Reale" Roboter zu haben - bei uns sind das, neben den speziellen aCTino-Schulungsrobotern für Schülerpraktikanten, hauptsächlich die im Maze/Labyrinth laufenden und mit einem Laserscanner ausgestatteten URGinos sowie auf dem Fußballplatz der Kicker und der Goal-Keeper - ist natürlich für Technische Informatiker mit einem Faible für hardwarenahes Equipment eine feine Sache. Auch die Kids auf der Langen Nacht der Wissenschaft erfreuen sich seit Jahren an ihnen, wenn sie sich mit ihnen im Geschicklichkeitsspiel herausfordern lassen dürfen. Aber reale Roboter haben bei allem Spaß, den man mit ihnen haben kann, einen nicht zu vernachlässigenden Nachteil: sie benötigen ständige Wartung und gehen meistens dann kaputt, wenn sie am dringendsten gebraucht werden. Wir haben uns deshalb entschlossen, unsere Aktivitäten im Erstellen von Software für die Lenkung der Roboter auf Simulatoren zu verlagern.
Bislang haben wir zwei Simulatoren geschaffen, die ein grafisches Abbild unserer realen Roboterplattformen, nämlich dem Maze/Labyrinth und dem Fußballplatz, repräsentieren. Gesteuert werden die in ihnen laufenden Avatare aus Client-Programmen über die acaBridge.
t.b.c.
Themen für Bachelor- und Master-Abschlussarbeiten: Viewer und (einfacher) Simulator
Im Rahmen verschiedener Abschlussarbeiten hätten wir neben den schon existierenden Viewern für das Labyrinth/Maze und den Fußballplatz als Bachelor-Abschlussarbeiten gerne noch:
- einen acaView-Maze als iOS-App
- einen acaView-Football als Android-/iOS-App
Da wir unsere "realen" Roboter zukünftig auch gerne als virtuelle Avatare in einer simulierten Umgebung steuern möchten, haben wir als Master-Abschlussarbeiten folgende Aufgaben anzubieten:
- einen acaSim-Maze als Android-App (dieses Thema ist jedoch schon vergeben) und einen als PC-Programm (Java/Processing)
- einen acaSim-Football als Android-/iOS-App und einen als PC-Programm (Java/Processing)
Im Gegensatz zu einem Viewer (s.o.), in dem die vom Kamerasystem des realen Labyrinths erkannten Roboter und Objekte an den entsprechenden cartesischen Positionen im visualisierten 1:1-Labyrinth abgebildet werden, funktioniert ein grafischer Simulator ein wenig anders: Durch einen beliebigen Steuercode, geschrieben in irgendeiner Hochsprache, werden die Avatare (d.h. die virtuellen Roboter) über eine Socketverbindung an bestimmte Stellen des visualisierten Labyrinths navigiert. Die wichtigste Schnittstelle hierfür ist die vOmega-Schnittstelle mit ihren beiden Parametern v für die Geradeausfahrt, und Omega für die Kurvenfahrt. Desweiteren zu implementieren ist in dieser Simulator-Arbeit eine virtuelle Objekterkennung; der Avatar darf nicht einfach durch Wände im Labyrinth fahren. (Vergleichbare Arbeiten existieren schon unter den Namen Player-Stage und Ros).
Betreuer der Arbeiten ist Prof. Dr. Christian Forler
