MRUI - Modular Robot User Interface | Teil 1
Konzept eines Energy-Monitoring-Systems (EMS)
Einer meiner Lieblingsprojekte ist das MRES-Projekt. MRES steht für MOBILE ROBOTER ECO SYSTEM. Vorläufig handelt es sich um einen spielerischen Nachbau eines Erkundungs-Fahrzeuges auf einem fernen Planeten (z.B. der Mars). Ein Erkundungs-Fahrzeug soll Proben oder Resourcen einsammeln und zur Homebase transportieren. Das Fahrzeug kann ferngesteuert werden oder autonom agieren. Mithilfe der eingebauten Kamera soll, bei Sichtverlust zum Roboter, eine Teleoperation (Fernsteuerung) ermöglicht werden. Hierfür wird ein Computer mit Display (Tablet, Laptop) benötigt, die visuelle Darstellung der internen Prozesse und der Roboter-Steuerung übernehmen soll. Wir nennen das Teleoperations-Modul (PC) der einfach halber TEOP und den Fahrroboter XplorerBB (Explorer Black Butterfly).
Im Gegensatz zum RoverBB besitzt der XplorerBB eine Wireless-Verbindung. Ich werde aber dieses Projekt so aufbauen, dass wir ein USB-Kabel einsetzen und hierfür kein zusätzliches Gerät beschaffen müssen.
Der XPlorerBB hat mehrere Subsysteme wie das Alarmsystem, den Antrieb, die Energieversorgung, das Interface, die Resourcen-Sammler-Komponente und die Sensorik mit seinen weiteren Subsystemen Navigation und Umweltdaten.
Das Alarmsystem stellt ein systemweites Meldungs- und Schutzsystem dar, dass eine übergeordnete Hierarchiestufe bildet. In ihr werden von allen Subsystemen Informationen zentral gesammelt und verarbeitet. Es besteht wiederrum aus mehreren Subsystemen: Konkurenzwarner (CPW), Kollisionswarner (CRS), Stürzgefahrwarner (ROF), Überhitzungswarner (ROH) und dem Energy-Monitoring-System (EMS). Dieses Projekt konzentriert sich ausschließlich auf das EMS.
Die Entwicklung der visuellen Darstellungen kommt wiederum aus dem MRUI-Projekt (MODULAR ROBOT USER INTERFACE). Hierbei geht es um eine visuelle Darstellung der internen Prozesse und Steuerung von einzelnen Elektronikmodulen mithilfe der Processing-Plattform. Das MRUI-Projekt besteht aus vielen kleinen Software-Modulen, die zu einem großen Steuer- und Überwachungs-Mosaik zusammengestellt werden kann, je nachdem welche Elektronik verbaut wurde. Du siehst also, dass ich mehrere meiner Projekt kombiniere.
Kommen wir zum ursprünglichen Thema wieder zurück - dem EMS = ENERGY MONITORING SYSTEM. Was bietet sich für die Energieüberwachung besser an, als den Zustand der Akkus zu tracken? Ich gehe auf die zwei Hardware-Module Spannungssensor und Stromsensor ein. Du wirst sehen, wie ich konzeptionell an dieses Thema herangehe. Diese Projektreihe soll dir zeigen, dass so etwas Simples wie die Anzeige des Akkustands viel Komplexität beinhaltet und eine Menge Konzept- und Umsetzungsarbeit bedeutet.
Spannungssensor
Stromsensor
Der Akkuzustand bei mobilen Robotern spielt eine übergeordnete wichtige Rolle und ist entscheidend über Erfolg oder Misserfolg der Mission. Ein Energie-Assistenzsystem soll uns zur richtigen Zeit mit einer angemessenen Information Hinweise geben, damit wir eine gute Entscheidungsgrundlage haben.
Bei der Umsetzung des Meldungskonzeptes werden wir zwei Wege gehen:
1. Hardwareumsetzung
2. Softwareumsetzung
Die Hardwareumsetzung soll unabhängig vom TEOP funktionieren und direkt mithilfe von einer RGB-LED vom Fahrzeug abgelesen werden können: grüne Farbe = Akku voll, rote Farbe = leer. Jedoch kann der Akkuzustand nur in kurzer Distanz abgelesen werden. Ist der Roboter um die Ecke abgebogen oder in weiter Entfernung ist eine Zustands-Bestimmung schwierig bzw. unmöglich.
Wie bereits erwähnt benutzen wir eine RGB-LED für die verschiedenen Stufen und einen Piezo-Lautsprecher, um bestimmte Warnstufen besonders hervorzuheben. Der Vorteil dieser beiden Module sind ihr einfache und schnelle Umsetzung. Der Nachteil ist die fehlende Präzision. Wir können nur wenige Nuancen wiedergeben. Bei einfachen Projekten ist das ausreichend.
RGB LED
Piezo-Lautsprecher
Processing
Bei der Softwareumsetzung werden wir die Entwicklungsplattform Processing nutzen, um die eingelesenen Informationen über den Akku zum PC zu senden und dort über ein User Interface grafisch darzustellen. Der Vorteil eines User-Interfaces ist immens. Wir können eine Vielzahl an Daten visualisieren, die im Gegensatz zu ausdrucksarmen LEDs nur schwer zu realisieren sind. Beispielsweise können wir darstellen, wie oft ein Wert einen Warnbereich betreten und verlassen hat. Oder wir könnten uns warnen lassen, wenn die Akku-Kapazität ungewöhnlich schnell sinkt und die Möglichkeit erhalten, die Ursache herauszufinden. Ein weiterer großer Vorteil ist das Remote-Monitoring. Wenn der Roboter sich außer Sicht- oder Hörweite befindet, haben wir trotzdem den vollen Zugriff auf das System - vorausgesetzt das eine kabellose Kommunikation besteht.
Wir müssen uns entscheiden
Bevor wir weiter machen müssen wir eine Entscheidung treffen. Der XplorerBB enthält nicht nur ein sondern zwei Energiequellen: Eine für das Arduino und die andere für die Antriebsmotoren. Warum das so ist, erläutere ich dir im Detail, wenn wir das Antriebssystem behandeln. Das ist auch in der Automobilbranche eine gängige Vorgehensweise. Beispielsweise wurde in dem MAN Projekt CityE, an dem ich mitgewirkt habe, eine kleine Batterie (12V) für die Steuerelektronik und für den Antrieb eine Reihe von Hochleistungsakkus verbaut. Also zwei voneinander getrennte Stromkreise.
Da das Antriebssystem viel energiehungriger ist, konzentrieren wir unseren Fokus hierauf. Die gewonnenen Erkenntnisse können wir später fast 1:1 auf die Energieversorgung der Steuerelektronik (Arduino) übertragen. Dazu brauchen wir natürlich weitere Strom- und Spannungssensoren.
Das getrennte Monitoring der zwei Energieversorgungen bringt uns den Vorteil, dass wir eine differenzierte Einsicht in das Gesamtsystem haben. Theoretischen könnten wir in jedes Subsystem einen Stromsensor integrieren und weitaus mehr Daten für Optimierungen gewinnen. Das ist dir überlassen, welchen Detaillierungsgrad du möchtest. Es muss dir aber auch klar werden, dass mit jedem weiteren eingesetzten Sensor der Energieverbrauch steigt. Der Strom- und Spannungssensor benötigt einen Teil der Energie für den Eigenverbrauch.
Kickstart
Eins muss ich vorweg erwähnen: Das Subsystem EMS beinhaltet keine Akkulade-Funktion. Das Aufladen eines Akkus ist eine Wissenschaft für sich und würde den Rahmen hier sprengen und übersteigt meine momentanen Kenntnisse. Das heißt für uns, dass wir den Akku nach seiner Entleerung herausnehmen müssen, um es wieder aufzuladen. Wir konzentrieren uns nur um die Visualisierung des Entladeverhaltens während des aktiven Betriebs. Das EMS ist eine Teilfunktion des XplorerBB und nützt folgende Module:
1x Spannungssensor
1x Stromsensor
1x RGB LED (für Hardwareumsetzung)
1x Piezo-Lautsprecher (für Hardwareumsetzung)
1x NiMH Akkupack mit 4,8V (4x 1,2V Mignonzellen)
Anforderungen
Folgende Grenzwerte sind von mir festgelegt worden und stellen natürlich nur eine Möglichkeit dar. Sie sind den Bedürfnissen frei anpassbar. Ich will dir lediglich die unterschiedlichen konzeptionellen Eskalationsstufen näher bringen. Natürlich können Stufen hinzugefügt oder reduziert werden. Die Festlegung der Stufen sollte nicht willkürlich erfolgen und dem Szenario folgenden.
Bei 100% Kapazität (51 – 100%)
Unsere Funktionsbeschreibung richtet sich in erster Linie an den Kennwerten des Akkus und dem Verbrauch des Roboter-Systems. Wenn wir von einem vollgeladenen Akkumulator ausgehen, stellen wir zunächst seine volle Kapazität dar (100%). Eine hohe Kapazität beruhigt den Systembediener und lässt seinen Fokus auf seine Tätigkeit hin ausrichten.
Bei 50% Kapazität (21 – 50%)
Wir können ab 50% Kapazität einen dezenten Hinweis geben. Solange der Roboter nahe der Homebase agiert stellen 50% noch lange keine Gefahr dar. Eine Ausnahme bildet natürlich, wenn der Roboter eine lange Strecke hinter sich gelegt und die Hälfte der Energie verbraucht ist. Machen wir folgendes Gedankenexperiment: Der Fahrroboter fährt voll aufgeladen von der Homebase weg und fährt eine gerade Strecke entlang. Nehmen wir weiter an, dass weder Neigungen noch Schlupf (Drehen des Rades auf der Stelle) die Fahrt beeinflussen. Wenn genau die Hälfte der Akkukapazität verbraucht ist, dann hat das Fahrzeug den sogenannten POINT OF NO RETURN erreicht. Fährt der Roboter etwas weiter, hat er nicht genug Energie, um wieder die Homebase zu erreichen und bleibt auf der Strecke.
Ideal wäre es, wenn der Roboter erkennen kann, wie weit er von der Homebase entfernt ist, den eigenen Energiebedarf protokoliert, dazu die Restkapazität einbezieht und eigenständig ausrechnet, wann der Zeitpunkt gekommen ist zurückzukehren. So wird der User entlastet und kann seine Arbeit länger fortsetzen. Die Einbeziehung der Distanz würde jedoch hier den Rahmen sprengen, da das Projekt insbesondere durch zusätzliche Berechnungen der aktuellen Entfernung zur Homebase deutlich komplexer wird.
Bei 20% Kapazität (16 – 20%)
Gehen wir davon aus, dass der Roboter in der Nähe der Homebase agiert: Geht die Kapazität während des Betriebs weiter runter, können wir eine Sicherheitsgrenze festlegen, die uns auf die Gefahr hinweist. Der User hat nun die Möglichkeit zu entscheiden, ob er mit der Restenergie etwas länger seine Aufgabe ausführt oder das Vehikel sofort zurück zur Homebase oder an einen sicheren Ort navigiert, wo er später schließlich seinen Geist aufgibt. Von diesem bekannten Ort kann er später von einer anderen Einheit abgeschleppt werden. Die Sicherheitsgrenze ist stark von der Distanze zur Homebase abhängig und muss individuell bestimmt werden. Ich setze ihn bei 20% Restladung fest. Die Sicherheitsgrenze bezieht sich hier nicht auf die Entfernung, sondern um die Restkapazität.
Bei 15% Kapazität (11 – 15%)
Die nächste Warnstufe ist relativ nahe zu 20% und liegt bei 15%. Falls der User die Warnung bei 20% nicht wahrgenommen oder ignoriert hat, wird jetzt ein Warnton ausgegeben. An dieser Stelle könnten wir anderen Subsystemen (z.B. Umwelt-Sensoren) kommunizieren, dass sie in diesem kritischen Moment nicht gebraucht werden und keine Daten einlesen sollen, um mehr Energie für die Motoren zur Verfügung zu stellen.
Eine gute zusätzliche Strategie kann eine Energiedrosselung zu den Antriebsmotoren bewirken. Elektromotoren haben nämlich eine ideale Leistungskurve. Sie zeigt an bei welcher Spannung der Motor am besten Strom sparen kann und trotzdem eine gute Leistung erbringt. Die Versorgung mit viel Strom heißt nicht unbedingt, dass der Motor die zugeführte Energie optimal ausnutzt. Das ist vergleichbar mit dem Benzinverbrauch eines Autos. Bei Geschwindigkeits-Höchstleistungen wird ein Benzinmotor bei gleicher zurückgelegter Strecke nicht das gleiche Verbrauchen, als mit moderater Fahrweise. Aber das ist ein anderes Thema, das an anderer Stelle besprochen werden soll.
Bei 10% Kapazität (5 – 10%)
Die nächste Eskalationsstufe habe ich bei 10% festgelegt. Hier steigt der Roboter um auf den Kriechmodus um. Es ist eine langsame Fortbewegung, die komplett auf Leistung verzichtet und den Fokus auf maximale noch mögliche Wegstrecke legt. Ab jetzt kann das Vehikel zu jeder Zeit ausfallen. Ein zweiter Warnton, der bedrohlicher als der erste ist, unterstützt zusätzlich die Dringlichkeit. Vielleicht können ab diesem Zeitpunkt weitere Maßnahmen eingeleitet werden, um die Reichweite zu vergrößern: z.B. alle nicht benötigten Subsysteme (Sensoren, Licht usw.) abschalten oder Ballast abwerfen (Anhänger, Steinproben usw.)
Bei 0% Kapazität (in Wirklichkeit 5%)
Bei 0% Energie stoppen wir bewusst den Antrieb und alle anderen Subsysteme. Wir zwingen sogar das Arduino in den Schlafmodus überzugehen. Tatsächlich ist der Akku aber nicht komplett entleert. Es sind noch 5% Kapazität übrig. Von den Anfangs angezeigten 100% Akku-Kapazität entsprechen in Wirklichkeit 95%. Warum gaukeln wir dem User den vollen Zugriff vor und verwehren ihm die 5%? Das ist eine gängige Vorgehensweise in der Consulter-Elektronikindustrie. Die einbehaltene minimale Restladung stellt sicher, dass Daten erhalten werden, der Akku geschont wird und dass das Hochfahren des Systems erleichtert wird. Ein vor kurzem entladenes Mobiltelefon lässt sich relativ schnell wieder hochfahren, sobald es am Netzgerät hängt. Ein seit Tagen entladenes Handy braucht deutlich länger.
In unserem Fall wollen wir die gefürchtete Akku-Tiefentladung vermeiden. Wird eine Batterie regelmäßig tiefentladen, wird sie dauerhaft beschädigt. Diesem Phänomen wollen wir mit der Abschaltung bei 5% entgegentreten. Wird diese Funktion nicht implementieren, dann zieht das Arduino fortlaufend Energie, auch wenn sich die Antriebsmotoren lange nicht mehr bewegen. Eine automatische Trennung von der Energiequelle gibt es beim Arduino nicht. Aus diesem Grund empfehle ich immer, die Energieversorgung von der Gesamtschaltung mit einem Haupschalter physisch zu trennen, sobald man nicht mehr an dem Projekt weiter arbeitet.
Es wird Situationen geben (Wettkampf) in denen man diese 5% Restenergie brauchen und ausnahmsweise die Gesundheit des Akkus vernachlässigen werden. Zu diesem Grund sollte die bewusste Zuschaltung der 5% durch den User ermöglicht werden. Die Möglichkeit der Freigabe der 5% muss jedoch schon früher erfolgen, z.B. bei 10% oder 20%. Erfolgt die Freigabe kann es sein, dass auf eine frühere Eskalationsstufe zurückgesprungen wird. 10% + 5%=> wieder zurück zu Warnstufe 15%.
Fassen wir die Eskalationsstufen zusammen:
Insgesamt habe ich fünf Stufen vorgesehen, aber es könnten auch weniger sein. Denkbar sind auch nur zwei Stufen, z.B. die 1. und 2. Stufe. Wir könnten aber auch eine situationsbedingte Stufung vorsehen. Falls sich der Roboter in der Nähe der Homebase aufhält können wir auf der Basis der 1. und 2. Stufe arbeiten. Sobald aber der Roboter die Nähe der Homebase verläst können wir alle vier Stufen anwenden. Voraussetzung hierzu ist die Distanzberechnung zwischen Homebase und Roboter.
Stufe 1: 51 – 100% normaler Betrieb, keine Gefahr
Stufe 2: 20 – 50% Hinweis auf eine mögliche Gefahr
Stufe 2: 15 – 19% Warnung, Warnton 1
Stufe 3: 10% Warnung der höchsten Priorität, Warnton 2 + Animationen +5% Freigabe
Stufe 4: 0% (5%) System Shutdown, Arduino Schlafmodus
In Teil 2 gehen wir auf die konzeptionelle Visualisierung ein. Hier geht es noch nicht um Design, sondern um den grundlegenden Aufbau von Informationen.