XBA_SI - XBA_Selbstidentifikation

Keywords: ADOxx, CPS, CyberPhysical Systems, Experiment, Identifikation, MBot, Metamodel, Modellierung, OMiLAB, Ranger, Selbstidentifikation, Umgebung

Use Case

 

Dieses Projekt wird insgesamt von drei Studenten bearbeitet, wobei jeder einen eigenen Bereich selbstständig abarbeitet. Die Idee hinter dem gemeinsamen Projekt ist es eine bessere Übersicht über den derzeitigen Zustand der experimentellen Fläche zu erhalten, um davon effizienter Experimente ableiten zu können.

  1. Selbstidentifikation: Das Ziel dieser Arbeit ist es eine autonome Identifikation eines CPS zu ermöglichen. Sobald sich der mBot Ranger einschaltet, sollen alle vorhandenen Bauteile registriert werden. Auch wenn neue Sensoren oder Aktoren an ihn angeschlossen werden, soll er diese erkennen und die Informationen mittels XML-Datei exportieren.
  2. Identifikation der Laborumgebung: Im zweiten Teill wird mit der Metamodellierungsplattform ADOxx gearbeitet, wobei diese durch Mechanismen und Algorithmen aus den exportierten Daten des ersten Teils vollständige Modelle mit allen Sensoren und Aktoren der CPS erzeugt. Neben den Aktoren und Sensoren sollten auch ontologisch korrekte Fähigkeiten abgeleitet werden.
  3. Modellierung von Fähigkeiten für Experimente in der Laborumgebung: Es sollte möglich sein mittels ADOxx ein Modell zu erstellen, dass ein Experiment darstellt und alle Fähigkeiten der Laborumgebung einschließt. Es ist nicht das Ziel Abfragen zu programmieren, welche die logische Zusammensetzung des Modells in Frage stellt. Sondern vielmehr, die Möglichkeiten des Labors zu erkennen und zu nutzen, um kreative Ideen zu realisieren.

 

Selbstidentifikation des mBot Rangers

Da in der heutigen Zeit den Cyber-Physical Systems immer mehr an Bedeutung zukommt, ist es umso notwendiger zu wissen welche Sensoren sowie Aktoren genau in Verwendung sind. Egal ob im industriellen oder privaten Bereich, für alle Anwendungsfelder kann dies einen großen Mehrwert bringen. Sich selbst zu kennen und diese Information zu teilen ist jedoch keine einfache Aufgabe, welche ein jedes CPS ohne spezielle Voreinstellungen könnte. Zudem sollte eine manuelle Konfiguration über das Vorhandensein möglicher Sensoren und Aktoren aus Flexibilitätsgründen vermieden werden. Viel besser ist es, wenn das Gerät dynamisch dessen Eigenschaften weiß. Somit würde nämlich die Fehlerquelle ’Benutzer’ wegfallen. Dieser könnte vergessen nach einer Änderung diese Information einzutragen.

 

Identifikation der OMiRob Laborumgebung

Prinzipiell sollte eine Modellierungssprache entwickelt werden, die alle Elemente der Laborumgebung in einem Modell wiederspiegeln kann. Als zusätzliche Anforderungen sollte neben der Darstellung des Labors und seinen vorhandenen CPS auch eine ontologische Abgleichung gemacht werden. Das Bedeutet, dass neben dem Modell, indem die CPS mit ihren Aktoren und Sensoren abgebildet werden, auch ein Modell erstellt werden muss in dem die abgeleiteten Fähigkeiten der CPS dargestellt werden. Dazu kommt, dass die beiden Modelle auch Abhängigkeiten untereinander besitzen sollen. 

Die oben angeführte Skizze beschreibt das Grundkonzept der Arbeit. Durch die Selbstidentifikation ist es möglich alle CPS sowie die Hindernisse und Kameras in der Laborumgebung abzubilden. Die folgenden Arbeitsschritte werden in der dabdurchgemacht:

  • Environment Modell erzeugen und Elemente der externen Datei importieren.
  • Fähigkeiten aus den Komponten der CPS ableiten, die von der externen Datei gelesen wurden.
  • Capabilites Modell erzeugen und abgeleitete Fähigkeiten importieren
  • Manuelle Änderungen des Environment Modelles erkennen und in neuem modified Capabilites Modell modellieren
  • Abhängigkeiten zwischen dem Envrionment und modified Capabilites Modell durch stetige Updates aktuell halten. 

 

Modellierung von Fähigkeiten für Experimente in der Laborumgebung

Ziel dieser Arbeit ist es eine Modellierungssprache zu entwickeln, die es erlaubt Experimente in der OMiRob Laborumgebung zu modellieren. Diese Sprache sollte alle Fähigkeiten abbilden können, die auch die CPS der Laborumgebung repräsentieren. Diese Modellierungssprache sollte dem Benutzer freie Wahl ermöglichen die unterschiedlichen Fähigkeiten der Laborumgebung in einem Modell anzuordnen, um somit ein individuelles Experiment zu erschaffen. Des Weiteren sollte es möglich sein die Fähigkeiten der bereits vorhandenen CPS der Laborumgebung aus einem standardisiertem XML-File, das von einer anderen Arbeit zur Verfügung gestellt wird, herauszufiltern. 

In der Abbildung sieht man sehr deutlich, wie die Prozedur dieser Arbeit durchgeführt wird. Es sollte möglich sein mittels ADOxx ein Experiment zu modellieren, dass alle Fähigkeiten der Laborumgebung einschließt. Es ist nicht das Ziel Abfragen zu programmieren, welche die logische Zusammensetzung des Modells in Frage stellt. Sondern vielmehr die Möglichkeiten des Labors zu erkennen und zu nutzen, um kreative Ideen zu realisieren. 

  • Anwendungsfall modellieren.
  • Fähigkeiten der registrierten CPS aus einer XML-Datei lesen.
  • Anforderungen des modellierten Versuches analysieren.
  • Anforderungen des Experiments mit den Fähigkeiten der CPS gegenüberstellen.
  • Modelliertes Experiment in der richtigen Reihenfolge auslesen.
  • Exportieren des Modells mit den ausführbaren Instanzen.

Experiment

Selbstidentifikation

Die Selbstidentifikation des Cyber-Physical Systems funktioniert. Wie im Kapitel Entwicklung beschrieben, ist dies eine Mischung aus der Benutzerkonfiguration und Signalauswertung. Dieser Lösungsweg ist natürlich verbesserbar und für den jeweiligen Einsatz adaptierbar. Je nach Art der Anbauteile und Art des Cyber-Physical Systems könnten auch andere Lösungsarten gewählt werden. Für unseren Zweck hier in der Arbeit und als Ergebnis dieser Bachelorarbeit ist diese Lösung jedoch einsetzbar. 

Einfache Zugreifbarkeit

Durch die REST-Schnittstelle ist die Information über den CPS einfach abgreifbar. Dies hat vor allem Vorteile bei der Flexibilität und dem Einsatzbereich. Zudem ist die Benutzung des Web-Frontends sehr einfach, indem der Benutzer mittels Browserzugriff auf die Informationen des Roboters kommt. 

Standards verwendet

Auch bei den verwendeten Komponenten wurde versucht möglichst Standards vorzuziehen. Zudem wurde natürlich auch beim Programm selbst die Verwendung von Standards angestrebt. Etwa durch REST, XML, Spring Boot, JAXB, HTML,... wurde eine breite Masse an populären und häufig verwendeten Komponenten gewählt. 

Irrelevanz des Portanschlusses

Durch die Selbsterkennung in Verbindung mit der Benutzerkonfiguration ist es nun auch möglich relativ irrelevant ein Bauteil an einen Port anzuschließen, egal welche Nummer dieser hat. Dennoch ist natürlich auf die Farbzusammengehörigkeit zu achten. Denn nur Komponenten mit den geeigneten Farben können sich verstehen und somit verwendet werden. Jedoch kann das Anbauteil auf einen falschen(farblich) Port angeschlossen und vom User manuell als ’Vorhanden’ markiert werden. Dies könnte mitunter zu Problemen im weiteren Workflow führen.

Umrüstung

Die Umrüstung ist auch erfolgreich gelungen, auch wenn es bei der Umsetzung immer wieder zu kleinen Problemen gekommen ist, so wurde dennoch jedes Bauteil montiert, welche für diese Arbeit notwendig sind. Somit ist der CPS einsatzbereit in unserem speziellen Kontext. Mit der Webcam ist er sogar noch mehr erweitert worden als notwendig und kann auch dessen Output auf der eigenen Webseite streamen.

 

Identifikation der Laborumgebung

Semantik der Elemente

Mit dieser Modellierungssprache können nun alle aktuellen CPS mit ihren Bestandteilen und Fähigkeiten abgebildet werden. Dank der Entwicklungsplattform ADOxx ist die Sprache in nur wenigen Schritten erweiterbar, sodass auf Erweiterungen im Bereich der Aktoren, Sensoren oder Roboter schnell reagiert werden kann, ohne großen Aufwand zu betreiben. Grundsätzlich besteht sie aus den Elementen einer Entität, eines Attributes und einer Relation. Das sind die drei Hauptmerkmale dieser Sprache, die in keinem Modell vernachlässigt werden dürfen. Zur Anwendung der Modellierungssprache werden im Modellierungstool zwei unterschiedliche Modelltypen angeboten. 

Environment

 

In dem oben angegebenen Bild wird auf die Aktoren, Robter und die Bestandteile der Laborumgebung eingegangen. In der ersten und zweiten Reihe der Abbildung sieht man die Darstellung der unterschiedlichen Entitäten. Sie werden sie durch die Symbole unterschiedlicher CPS dargestellt. Hier werden neben den mobilen CPS auch die stationören sowie Humanoiden abgebildet. Daraus folgt, dass die Modellierungssprache derzeit die Abbildung von neun verschiedenen CPS und deren Bestandteile abbilden kann. Ebenfalls sieht man in der Abbildung in der dritten und vierten Reihe die Symbole der vorhandenen Aktoren.

  • Gripper steht für einen Greifarm der zum Beispiel beim OMiArm zum Einsatz kommt.
  • Motor repräsentiert einen vorhandenen Elektromotor.
  • MecanumWheel ,Tyre und Track dienen mobilen CPS zur Fortbewegung.
  • Raspberry Pi und Arduino stellen die Recheneinheiten dar.
  • Kamera und Hindernis dienen zur Darstellung der Laborumgebung.

Grundsätzlich kann man sagen, dass alle abgebildeten Sensoren derzeit auch tatsächlich in der Laborumgebung verwendet werden. Die meisten Sensoren sind ebenso wie die CPS von der Firma Makeblock zugekauft worden und deshalb auch flexibel einsetzbar. Bei der Erstellung der Symbole wurde jedes einzelne Bild in diversen Fotoverarbeitungstools ausgeschnitten und angefertigt. In der Abbildung sieht man eine Übersicht über alle Sensoren im Environment-Modell. Die Symbole repräsentieren das wahre Aussehen der spezifischen Sensoren, sodass sie auch direkt mit dem realen Roboter verglichen werden können.

 

Capabilites

Der zweite Modelltyp lautet Capabilities und dient zur Darstellung der Fähigkeiten. Es soll die Fähigkeiten jedes modellierten CPS im Environment wiederspiegeln. Nur statt den Aktoren und Sensoren werden die CPS in diesem Modell mit den Fähigkeiten verbunden. In diesem Modell sind als Attribute nur Fähigkeiten erlaubt, sodass Aktor und Sensoren als Elemente überhaupt nicht Angeboten werden.

Die Symbole der Fähigkeiten haben die Aufgabe die repräsentierenden Elemente mit einem Blick widerspruchfrei zu verstehen. Die Form und die Farbdarstellungen unterscheiden sich drastisch von den Elementen im Environment-Modell, dadurch soll eine schnelle optische Erfassung der beiden unterschiedlichen Modelle ermöglicht werden.

  • Move repräsentiert die Bewegung und wird durch die Aktoren Drive und Motor ermöglicht.
  • Direction ermöglicht sich präzise zu drehen und zu wenden, dies wird durch den Aktoren Gyro repräsentiert.
  • Mecanum beschreibt die besonderen Räder des Mecanum Wheel.
  • QR-Code und Video leiten sich aus dem Aktor Kamera ab.
  • Brightness wird von dem Aktor Light abgeleitet und beschreibt die Fähigkeiten zwischen hell und dunkel zu unterscheiden.
  • Distance verkörpert die Möglichkeit den Abstand zu Gegenständen zu messen und wird von dem Sensor Ultrasonic abgeleitet.
  • Voice wird von dem Sensor Microphone abgeleitet und stellt die Fähigkeit Stimmen zu identifizieren
  • Orientation erlaubt die Orientierung in einem Raum und wird von dem Sensor Compass abgeleitet.
  • Sound wird vom Sensor Buzzer abgeleitet und beschreibt die Fähigkeit Töne von sich zu geben.
  • Visualization erlaubt es Informationen auf einem Display zu darzustellen

Die restlichen Fähigkeiten Follower, Wifi, Gripper, Color, Infrared, Temperature und Bluetooth werde von den gleichnamigen Sensoren bzw. Aktoren abgeleitet und beschreiben Fähigkeiten, die aus der Namensgebung herleiten lassen.

 

Modellierung von Fähigkeiten für Experimente

Semantik der Elemente

Die entwickelte Modellierungssprache dient für die Modellierung von Prozessen in der OMiRob-Laborumgebung. Neben einfachen Prozessen können auch sehr große und komplexe Experimente abgebildet werden. Die Sprache wird in Bezug auf die Modellierungselemente hauptsächlich in den zwei Kategorien Flussobjekte und Sequenzflüsse voneinander unterschieden. Unter den Flussobjekten versteht man Ereignisse, wie Start und End sowie Aktivitäten und Verzweigungen. Prozesse beginnen und enden mit einem Ereignis. Jeder Prozess muss mindestens einen Anfangspunkt sowie einen Endpunkt besitzen, damit er als vollständig gilt. Ebenfalls löst ein Ereignis den Ablauf eines Prozesses aus und beeinflusst oder beendet ihn. Neutrale Elemente wie das Breake Element können direkt mit vorausgehenden und nachfolgenden Aktivitäten verbunden werden.

Die Ereignisse dienen in erster Linie dazu einen Ablauf auszulösen oder ihn zu beenden. Sie werden grafisch mit einem Kreis in unterschiedlichen Farben dargestellt. Jede Farbe beschreibt ein anderes Ereignis. Dies ist bei sehr komplexen Modellen mit mehreren Ereignissen hilfreich, damit man eine gute Übersicht gewährleisten kann. Wie in der Abbildung oben gut ersichtlich ist gibt es insgesamt vier verschiedene Ereignistypen, die jeweils unterschiedliche Aufgaben bewirken.

  • Als Startereignis dient das Element Start-point, welches durch einen grünen Kreis dargestellt wird. Es symbolisiert den Anfang eines Prozesses und hat nur eine ausgehenden und niemals eine eingehende Kante. 
  • Das Zwischenereignis kann zwischen zwei Aktivitäten platziert werden. Es wird mit einem orangen Kreis dargestellt und lautet Break-point. Es stellt eine Ruhephase dar, welche in Sekunden angegeben werden kann.
  • Das Endereignis wird mit einem blauen Kreis repräsentiert, und bezeichnet den Abschluss eines Prozesses.
  • Die Verzweigung wird mittels gelben Dreieck gekennzeichnet und stellt eine Entscheidung dar. Das besondere an der Verzweigung ist, dass sie nur eine eingehende Kante und mindestens zwei oder mehrere ausgehende Kanten erlaubt.

Bei diesen Aktivitäten handelt es sich generell um Arbeitsschritte, die von Aktoren ausgeführt werden können. Mit den in der Abbildung dargestellten Aktivitäten wurde eine Lösung gefunden, um eine Vielzahl der aktuellen vorhandenen Aktoren in der Laborumgebung wiederzugeben. Das Ziel war es mit möglichst wenig Elementen viel Fähigkeiten abzudecken. Dies wurde durch die Wiederverwendung von einzelnen Elementen möglich, sodass alles mit nur drei Oberbegriffen abgedeckt werden konnte. Sie lauten Direction, Move und Gripper und werden in der oben angeführten Abbildung dargestellt. 

  • Direction symbolisiert die Richtungsangabe in Grad und besitzt zwei vordefinierte Auswahlmöglichkeiten die nach Links und Rechts mit jeweils 45 Grad auswählbar sind. Des Weiteren kann man über die Auswahl Costumize in ein danach erscheinendes Feld eine eigens definierte Gradanzahl eingeben.
  •  Move kann durch seine verschiedenen Eigenschaften bis zu vier unterschiedliche Aktivitäten darstellen. Es beschreibt grundsätzlich die Fortbewegung eines CPS und lässt es je nach Einstellung nach vor oder zurück fahren. Dazu können auch die Eigenschaften wie Geschwindigkeit und Dauer verändert werden. Als weitere Auswahlmöglichkeiten bieten sich auch noch Follower und Mecanum an.
  • Gripper wird nicht nur den beiden Industriearmen der Laborumgebung gewidmet, sondern auch Fahrzeugen mit Hebearm wie zum Beispiel beim PoC1 oder auch dem Drawbot. Diese Aktivität lässt sich in vier verschiedene Einstellungen abwandeln. Sie dient für alle CPS, die ein ähnliches Verhalten wie ein Industriearm bereitstellen.

Da weiter oben die Aktivitäten in Bezug auf Arbeitsschritte der Aktoren festgelegt wurden, widmen wir uns hierbei den Abläufen von Sensoren. Sie besitzen viele individuelle und unterschiedliche Parameter, da jeder Sensor für eine spezifische Tätigkeit bestimmt ist und somit jeder seine eigenen Funktionen anbietet. Hier wurde es leider nicht immer möglich mehrere Sensoren in einer Aktivität zusammenzufassen, da sie so verschieden sind und dies nur zur Verwirrung führen würde.

  • Bluetooth wurde hinzugefügt, weil viele der CPS in der Laborumgebung auch durch Bluetooth angesprochen werden können und somit diesen Sensor besitzen. Durch diese Aktivität ist es möglich sich mit der Umgebung oder anderen CPS zu verbinden.
  • Kamera symbolisiert in der Regel nur die Funktion der Aufnahme durch eine Kamera, jedoch lassen sich die Menge an Fähigkeiten des Sensors in drei verschiedene Aktivitäten aufteilen. Daraus ergeben sich Fähigkeiten QR-Code, Color und Video.
  • Visualization oder auch Visualisierung beschäftigt sich mit der Darstellung von Informationen auf einem Display. Grundsätzlich symbolisiert diese Aktivität eine Art Feedback, das vom CPS aus direkt ablesbar ist und in den verschiedensten Schriftarten repräsentiert werden kann. Da die CPSs in der Laborumgebung auch über Displays verfügen, wurde diese Fähigkeit auch miteinbezogen.
  • Wifi stellt die Netzwerkverbindung dar. Grundsätzlich können sich alle CPS in der Laborumgebung mit dem WLAN verbinden und kommunizieren.
  • Sensor stellt eine Menge von Sensoren dar, die durch ähnliche Parameter in eine Aktivität zusammengefasst werden konnten. Durch die Konfiguration kann sie auf sieben unterschiedliche Sensoren eingestellt werden, welche alle durch eine eigene Farbmarkierung sowie den Namen des Sensors als Motiv tragen. Da Sensoren meistens für das Messen von Daten zuständig sind, haben sie sehr ähnliche Parameter und lassen sich gut zusammenfassen.

 

XML-Datenstrukturen

 

Export Selbstidentifikation    Export Selbstidentifikation    Export Selbstidentifikation

                Selbstidentifikation                          Indentifikation der Laborumgebung              Modellierung der Experimente

 

Die oben abgebildeten XML-Formate sind die jeweilig exportierten Dateien der einzelnen Arbeiten, die von der jeweils nächsten Arbeit verwendet werden. Diese Dateien dienen als Interface für die einzelnen Arbeiten, sodass eine saubere Schnittstelle zwischen der eingehenden und der exportierten Datei besteht. Somit sind diese drei Arbeiten nicht nur in Kombination anwendbar, sondern können auch als eigene Einheit gesehen werden, die mit verschiedenen Projekten kombiniert werden können. Dadurch sind die Arbeiten vielseitig anwendbar und flexibel zugleich, sodass sie häufiger eingesetzt werden und dadurch auch weiterhin aktuell bleiben, um der Laborumgebung einen großen Nutzen zu leisten.

 

 

 

Results

Selbstidentifikation

Selbstidentifizierender mBot Ranger

Manuelles Hinzufügen einzelner Komponenten

Im folgenden Video wird über das REST-Webservice dem Roboter ein Name(hier: My Robi 123) gegeben und zusätzlich wird der eigene Name(hier: John Doe) angegeben. Danach werden noch einige Komponenten als vorhanden, oder als unsicher markiert.

 

 

Rudimentäre Steuerung

Ein mBot Ranger von Makeblock wird hier anhand von einem REST Webservice bewegt. Mittels diesem kann auch von extern über die Webcam beobachtet werden, wie sich dieser bewegt. 

Hier wird gezeigt, wie dies vollzogen wird. Aufgerufen wird das Webservice, welches auf dem Ranger direkt läuft, per Browser.  Um auf die angebotenen Services zu gelangen, wird die IP-Adresse des CPS benötigt. Hier um den CPS zu bewegen: IP_des_CPS:8080/steuren

 

 

Identifikation der Laborumgebung

In diesem Video wird die Durchführung einer Abbildung der Laborumgebung vorgestellt. Somit werden alle einzelnen Schritte zu erfolgreichen Durchführung der Identifikation der Laborumgebung genauer erklärt. Im ersten Teil wird das importieren und auslesen der XML-File beschrieben. Danach werden alle Funktionen zur Erstellung und automatischen Modellierung angeführt. Anschließend wird die Abhängigkeit zwischen zwei Modellen durchgespielt und verständlich erklärt. Zum Schluss wird der Export der modellierten Informationen durchgeführt, um die grundlegenden Daten dem nächsten Teil des gesamten Projektes zur Verfügung zu stellen.

Trotz der großen Herausforderungen in der Umsetzung dieser Arbeit musste auf nichts verzichtet werden, sodass keine groben Einschränkungen in der Benutzerfreundlichkeit erforderlich waren. Dadurch, dass diese Arbeit unabhängig von den anderen Arbeiten entwickelt wurde, kann sie auch als einzelnes Modul in unterschiedliche Bereichen angewendet werden. Natürlich besitzt auch diese Arbeit optimierungspotenzial, sodass noch einige Symbolbilder der Elemente durch aussagekräftigere und qualitativ bessere Bilder ausgetauscht werden könnten. Abschließend kann man sagen, dass alle Anforderungen der praktischen Arbeit vollständig erfüllt wurden und dem Einsatz in der OMiRob-Laborumgebung nichts mehr im Weg steht.

 

Modellierung der Fähigkeiten von Experimenten

Modellierung eines Experiments

In diesem Video wird ein einfaches Experiment modelliert. Hier werden alle Schritte der Modellierungssprache auf der Entwicklungsplattform ADOxx durchgeführt. Es werden Abläufe für mobile CPS modelliert, damit unterschiedliche Fähigkeiten angewendet werden können. Danach werden die folgenenden Schritte mit dem Button Export as XML ausgeführt:

  1. Externe Datei einlesen
  2. Anforderungen des Modells analysieren
  3. Vorhandene Fähigkeiten der CPS mit den notwendigen Fähigkeiten des Modells abgleichen
  4. Elemente des Modells auslesen und in der exakten Reihenfolge anordnen
  5. Alle Informatinoen in eine XML-File schreiben und in den gewünschten Pfad exportieren

 

Durch die Kombination aller drei Arbeiten kann nun die Erfassung, Modellierung und Experimentierung mit CPS in der Laborumgebung erleichtert werden. Dadurch können nun Experimente effektiver und einfacher durchgeführt werden, auch von jenen Forschungsmitgliedern, die wenig Wissen im Bereich CPS oder Sensoren und Aktoren mitbringen. Durch die Selbstidentifikation und die automatische Modellierung der Umwelt, wird dem Benutzer eine Menge Arbeit abgenommen, sodass ein Versuch schnell durchgeführt werden kann.