Kommunikation

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¹ 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.

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.

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
Python-Client-Parameter: transport="websockets"

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 verschicken Nachrichten findet ihr hier gelistet:

• Generische Nachrichten
• Topic explorer/
• Topic planet/

Nachrichten-Arten

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 Roboter initiiert 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 initiiert werden

• Server deckt Pfad auf
• Server setzt Target

Häufige Fehler & Hinweise

• Verschickte Nachrichten liegen im Format UTF-8 vor und müssen dementsprechend zuerst mit message.payload.decode('utf-8') dekodiert werden, damit es bei der Weiterverarbeitung der enthaltenen Strings nicht zu Fehlern kommt.
• Häufig werden keine Nachrichten empfangen, da das Skript bzw. Modul für die Kommunikation direkt nach Start des Listeners schon wieder beendet wird. Eine while-Schleife kann hier Abhilfe schaffen.
• 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, nach Installation geeigneter Werkzeuge, auch zuerst lokal auf eurem Rechner testen.
  Wir empfehlen dazu die Nutzung des Clients MQTT Explorer (Konfigurationsbeispiel siehe unten).
  Bitte beachtet, dass das Mutterschiff (also der Server) für die Roboter nur über das WLAN _RoboLab Playground_ erreichbar ist.
  • Username und Password müssen mit den Daten der Gruppe befüllt werden
  • Unter Advanced muss ggf. noch die vordefinierte Client-ID entfernt werden (Feld leeren), dann sollte die Verbindung klappen

Code-Beispiel

Zur Herstellung der zuvor beschriebenen Kommunikation wird im RoboLab die Bibliothek https://www.eclipse.org/paho/index.php?page=documentation.php verwendet. Es ist sinnvoll, sich einen Überblick über die API und das eingesetzte Protokoll MQTT zu verschaffen und nicht einfach nur das Code-Beispiel zu verwenden.

#!/usr/bin/env python3

import json
import paho.mqtt.client as mqtt
import ssl

# this is a helper method that catches errors and prints them
# it is necessary because on_message is called by paho-mqtt in a different thread and exceptions
# are not handled in that thread
#
# you don't need to change this method at all
def on_message_excepthandler(client, data, message):
    try:
        on_message(client, data, message)
    except:
        import traceback
        traceback.print_exc()
        raise

# Callback function for receiving messages
def on_message(client, data, message):
    print('Got message with topic "{}":'.format(message.topic))
    data = json.loads(message.payload.decode('utf-8'))
    print(json.dumps(data, indent=2))
    print("\n")


# Basic configuration of MQTT
client = mqtt.Client(client_id="<GROUP>", clean_session=False, protocol=mqtt.MQTTv31)

client.on_message = on_message_excepthandler # Assign pre-defined callback function to MQTT client
client.tls_set(tls_version=ssl.PROTOCOL_TLS)
client.username_pw_set('<GROUP>', password='<PASS>') # Your group credentials, see the python skill-test for your group password
client.connect('mothership.inf.tu-dresden.de', port=8883)
client.subscribe('explorer/<GROUP>', qos=2) # Subscribe to topic explorer/xxx

# Start listening to incoming messages in the background
client.loop_start()

while True:
    user_input = input('Enter disconnect to close the connection...\n')

    if user_input == 'disconnect':
        break

    # you could add some code to send a message here

client.loop_stop()
client.disconnect()
print("Connection closed, program ended!")