Idee, Projektorganisation: Andreas Döpkens
Programmierung: Brian Schüler

Mit einem Prozessleitsystem (engl. process control system) ist im technischen Sinne 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 große Schaltschränke, in denen die Steuerelektronik untergebracht ist. In einer starken Vereinfachung so weit also das typische Bild eines Prozessleitsystems, wie es die meisten Menschen in sich tragen dürften. Das acaPCS hat von alledem nicht viel zu bieten und entspricht in seinem Aufbau deshalb überhaupt nicht dem gerade geschilderten Bild eines Prozessleitsystems. Da den "Prozessen" in einem klassischen Prozessleitsystem im acaPCS die gesteuerten Bewegungsabläufe unserer URGino-Roboter entsprechen, hätten wir unsere "Anlage" in einer etwas schärferen semantischen Abgrenzung auch acaRCS (robot control system) nennen können. Wahrscheinlich wäre diese Bezeichnung geschickter 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 für einfache Roboteraufgaben zur Lokalisation und Navigation bis hin zu komplexen Anwendungen wie Slam (simultaneaous localisation and mapping). 

Das acaPCS zur Steuerung der URGino-Roboter besteht aus den drei Komponenten Viewer, Controller und Steuercode. Diese drei Instanzen sollen im folgenden vorgestellt werden.

Viewer

Bei dem Viewer handelt es sich um eine Beobachtungseinrichtung und dient der Visualisierung der Roboterpositionen. Wie aus den Abbildungen (rechts) erkennbar ist, besteht der Viewer aus einem Hardware- und einem Softwareteil. 

Die Größe des Labyrinths, 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 schöne 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.

Eine berechtigte Frage lautet: Warum verfügt dieses Prozessleitsystem eigentlich über Kameras? Wäre es nicht viel einfacher, wenn die Positionsbestimmungen der Roboter über funkgesteuerte Triangulationsmechanismen erfolgten, ähnlich dem GPS? --- Leider funktioniert GPS nur draußen, also outdoors, und nicht in geschlossenen Räumen. Für die Indoor-Navigation von Robotern gibt es zwar auch schon fertige Lösungen auf dem Markt zu kaufen, wie z.B. die Beacons von Apple. Aber sämtliche Systeme derzeit sind viel zu ungenau. Die Beacons zum Beispiel haben eine Genauigkeit von höchstens 30 Zentimetern. In einem gerade einmal 150 x 150 Zentimeter großen Labyrinth ist diese Lösung natürlich nicht brauchbar, denn hier werden Genauigkeiten im halben Zentimeterbereich benötigt. Also muss die Kamera her, denn die ist wirklich präzise.

Die Viewer-Einrichtung von acaPCS 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. 

Controller

Der Controller ist ein Programm, das auf jedem der Roboter installiert ist. Er nimmt im JSON-Format Daten über eine Socketverbindung von einem Steuercode entgegen, die Fahrbefehle repräsentieren, und übergibt seine Sensor- und Odometriedaten an den Steuercode.