¶ Pub/Sub-Systeme
Im Internet der Dinge (Internet of Things, IoT) tauschen viele Millionen Geräte, Sensoren und Aktoren untereinander Daten aus.
Jedoch sind diese oft nicht sehr leistungsfähig und nur vorübergehend erreichbar, weil die Netzverbindung unterbrochen ist oder sie nur zeit- und ortsabhängig benötigt wird.
Wie baut man nun eine Infrastruktur mit unzuverlässigen Teilnehmern (Clients), die nicht einmal in der Lage sind, die Liste der Empfänger für ihre Nachrichten zu verwalten?
Eine mögliche Lösung bieten sogenannte Publish/Subscribe-Systeme (Pub/Sub).
Hier übernimmt ein Vermittler (Broker) die Aufgabe, Nachrichten an die richtigen Empfänger weiterzuleiten.
Jedes Gerät kann Daten senden (publish) oder dem Vermittler gegenüber mitteilen (subscribe), an welcher Art Nachrichten (topic) es interessiert ist und diese später empfangen.
¶ MQTT
MQTT[1] ist ein standardisiertes Nachrichtenprotokoll für Pub/Subs.
Es wird seit 1999 stetig weiterentwickelt, bietet verschiedene Übertragungsgarantien (Quality of Service oder QoS) für den Nachrichtentransport und zeichnet sich durch geringe Ansprüche an Verbindungsqualität und Rechenleistung aus.
¶ QoS Level
Für die Operationen subscribe und publish können als Option verschiedene QoS-Level festgelegt werden.
Das MQTT-Protokoll sichert daraufhin über ggf. zusätzliche Nachrichten deren Einhaltung ab.
- Level 0: Die Nachricht erreicht die Empfänger höchstens einmal.
- Level 1: Die Nachricht erreicht die Empfänger mindestens einmal.
- Level 2: Die Nachricht erreicht die Empfänger genau einmal.
Mit Erhöhen des QoS-Levels steigt die Komplexität des Protokolls und die Anzahl der verschickten Nachrichten im Hintergrund.
Im RoboLab wird MQTT auf QoS Level 2 eingesetzt.
¶ Nutzung im RoboLab
Jeder Roboter nimmt während der Erkundung regelmäßig Kontakt zu seinem Mutterschiff auf.
Aufgrund der dichten Atmosphäre gelingt dies jedoch nur mit den Verstärkern der Versorgungsstationen, die an den Kreuzungspunkten der Pfade eingerichtet wurden.
Dort eröffnet der Roboter eine Übertragung und versendet seine geschätzte neue Position.
Er empfängt vom Mutterschiff eine Bestätigung und möglicherweise verschiedene andere Nachrichten.
Dabei wird zwischen Planeten-Nachrichten, zum Beispiel nützlichen Informationen wie neuen Pfaden, und den direkten Anweisungen des Mutterschiffs, also einem Erkundungsziel, unterschieden.
Nach der letzten gesendeten oder empfangenen Nachricht wird ein Timeout von 3 Sekunden abgewartet, bevor die Kommunikation an dem Knoten beendet und die Erkundung fortgesetzt wird.
Allgemein gesprochen gilt eine Übertragung an einem Knoten also als beendet, wenn der Roboter 3 Sekunden lang keine Nachricht mehr empfangen hat.
Das Timeout von 3 Sekunden bedeutet nicht, dass zwischen zwei gesendeten oder empfangenen Nachrichten jeweils 3 Sekunden Funkstille herrschen sollen.
Es ist auch nicht erforderlich, an jedem Knoten eine neue Verbindung zu erstellen und diese danach wieder zu schließen.
¶ Verbindungsmöglichkeiten
Die Kommunikation mit dem MQTT-Broker erfolgt grundsätzlich TLS-verschlüsselt.
Im RoboLab bieten wir sowohl die Standard-Verbindung als auch Websockets an.
Standard-Verbindung
URL: mothership.inf.tu-dresden.de
PORT: 8883
Websocket-Verbindung
URL: mothership.inf.tu-dresden.de
PORT: 9002
Zur Authentifizierung sind folgende Informationen nötig:
username: <GROUP>
password: <PASS>
¶ Group-Tool
Im Group-Tool werden unter dem MQTT-Reiter die Nachrichten live angezeigt.
Außerdem gibt es dort die Möglichkeit, die TestPlanet-Nachricht manuell zu senden.
¶ Nachrichten
Die Kommunikation zwischen Roboter (Client) und Mutterschiff (Server) erfolgt im JSON-Format.
Nachrichten des Roboters haben dabei immer den from-Typ "client", Antwortnachrichten darauf vom Mutterschiff den from-Typ "server".
Alle anderen Nachrichten haben den from-Typ "debug".
Weiterhin werden alle Keywords in camelCase-Notation angegebenen.
Alle auf den jeweiligen Topics verschickten Nachrichten findet ihr hier gelistet:
¶ Nachrichten-Arten
Um die Entwicklung zu erleichtern, sendet das Mutterschiff Nachrichten mit dem
from-Typ "debug".
Diese enthalten nützliche Informationen, dadurch sind Fehler schneller erkenn- und behebbar.Wichtig: Debug-Nachrichten werden zur Prüfung NICHT gesendet!
Einige Platzhalter kurz erläutert:
<GROUP>= Group name / ID (z.B. 001)
<PLANET>= Planet name
<TEXT>= Integer / String placeholder
<PASS>= Group MQTT-password, see your skill-test ticket
Xs, Ys, Ds = Start coordinates and direction
Xe, Ye, De = End coordinates and direction
Xc, Yc, Dc = End coordinates and direction, possibly corrected
Xt, Yt = Target coordinates
Beispiele:
Explorer: explorer/001
Planet: planet/Gromit/001
¶ Nachrichten, die vom Client gesendet werden
- (Testplaneten festlegen)
- Server mitteilen, dass erster Knoten erreicht wurde
- Richtungsauswahl
- Gefahrenen Pfad übermitteln
- Ende der Erkundung/Erreichen des Targets
- Kommunikationstest
¶ Nachrichten, die vom Server gesendet werden
¶ Unit-Tests
Unit-Tests dienen zur Überprüfung, ob die implementierten Funktionen auch das gewollte Ergebnis erzielen. Das Template dafür befindet sich in planet/src/test.rs.
Eine genauere Anleitung zum Schreiben und Ausführen dieser Tests ist hier erläutert.
Tests für die Communication sind nicht bewertungsrelevant, sondern dienen lediglich als Hilfestellung beim Debuggen.
¶ Häufige Fehler & Hinweise
- Koordinaten, Richtungsangaben sowie Gewichte der Pfade werden als ganze Zahlen (Integer) geschickt.
Für die Richtungsangaben werden Abkürzungen der Himmelsrichtungen in Form von Grad-Angaben
0(Nord),90(Ost),180(Süd),270(West) verwendet. - Ihr könnt die Kommunikation auch zuerst lokal auf eurem Rechner testen.
Geeignet dazu sind einfache Unit-Tests.
Bitte beachtet, dass das Mutterschiff (also der Server) für die Roboter nur über das WLANRoboLab Playgrounderreichbar ist. - Ob Nachrichten beim Mutterschiff ankommen, könnt ihr ganz einfach im
MQTT-Reiter in eurem GroupTool sehen.Dabei müsst ihr den Tab parallel schon offen haben, sonst können die Nachrichten nicht geladen werden.