ArduMower: Drahtlose Datenschnittstelle

Dieser Wiki-Beitrag ist Teil eines Projektes, welches im Rahmen vom Fachpraktikum Elektrotechnik im 6. Semester und 7. Semester Mechatronik absolviert wurde. Ziel des Beitrags ist es, eine nachhaltige Dokumentation zu schaffen, welche die Ergebnisse festhält und das weitere Arbeiten am Projekt ermöglicht.

Autoren: Tom Niehaus

Betreuer: Prof. Dr.-Ing. Schneider, Prof. Dr.-Ing. Mirek Göbel

Aufgabe

Erstellung einer drahtlosen Datenschnittstelle zur Überprüfung von Sensordaten über Wifi

Erwartungen an die Projektlösung

• Erstellung einer Diagnose-Oberfläche
• Kommunikation zwischen Rechner und Roboter via Wifi
• Test des WLAN Moduls
• Gegebenfalls Verbindung mit Hochschulnetzwerk
• Integration der Schnittstelle in Simulation

Herangehensweise

• Einarbeitung in Funktion des W-Lan Modules ESP8266_W-Lan Modul
• Recherche Pinbelegung (https://arduino-hannover.de/2014/12/11/wifi-kochbuch-mit-esp8266/)
• Protokoll zur Datenübertragung festlegen (TCP/IP)
• Platine für W-Lan Modul auf Grundlage der Pinbelegung fertigen, um dieses an den ArduMower anzuschließen (s. Bild 1)
• Einarbeitung in Programmierung eines Datenaustauschs mittels TCP/IP zwischen Arduino und einem PC
• Umsetzen des Datenaustausches in Matlab Simulink
• Test der Implementierung

Platine

Abb. 1: Platine für W-Lan Modul

Die Platine (s. Abb. 1) besteht aus dem WLAN-Chip ESP8266, zwei Widerständen und Anschlüssen für die Stromversorgung des Chips und Kommunikation über die serielle Schnittstelle des Arduino. Der Chip sowie die anderen Bauteile sind auf einer Lochrasterplatine verlötet. Die Rückseite der Platine ist mit einer Heißklebepistole versiegelt worden um das Kurzschließen an den Kontakten an der Rückseite zu vermeiden. Der Chip wird mit 5V Versorgungsspannung vom Arduino versorgt. Da der Arduino bei der seriellen Schnittstelle mit einem Pegel von 5V arbeitet und der W-LAN Chip nur 3,3V an der seriellen Schnittstelle verträgt ist ein Spannungsteiler mit den beiden Widerständen erstellt worden.

Das Übertragungsprotokoll

Die Kommunikation zwischen dem Ardumower und dem Roboter geschieht über TCP/IP (Transmission Control Protocol/Internet Protocol). Die Hauptaufgabe dieses Protokolls ist es dafür zu sorgen, dass Datenpakete innerhalb eines dezentralen Netzwerks vom Sender beim Empfänger ankommen. Das Protokoll stellt hierfür einige Funktionen bereit:

• Logische Adressierung / Logical Addressing
• Wegfindung / Routing
• Fehlerbehandlung und Flusssteuerung / Error Control and Flow Control
• Anwendungsunterstützung / Application Support
• Namensauflösung / Name Resolution

Logische Adressierung

Es bedarf einer Möglichkeit das Netzwerk physikalisch (Topologie) und logisch (Adressierung) zu strukturieren. Innerhalb von TCP/IP übernimmt IP die logische Adressierung von Netzwerken und deren Teilnehmern. Dieses sorgt dafür, dass Datenpakete nur an die Teilnehmer gesendet werden, welche diese Daten benötigen.

Routing

Das Routing sorgt als eine Art Wegfindung dafür, dass die Datenpakete ihre Ziele erreichen. Hierfür wird für jedes Datenpaket bei jedem einzelnen Netzknoten auf dem Weg zum Empfänger der nächste Netzknoten ermittelt.

Fehlerbehandlung und Flusssteuerung

Obwohl es sich eher um eine virtuelle Verbindung handelt, werden während der Datenübertragung ständig Kontrollmeldungen ausgetauscht, weshalb man von einer verbindungsorientierten Kommunikation spricht. Wird ein Fehler festgestellt, wird das betreffende Datenpaket erneut übertragen. Zusätzlich ist eine Daten-Flusssteuerung notwendig, um die verfügbare Übertragungsgeschwindigkeit auszunutzen. Weil es im Internet für eine Ende-zu-Ende-Verbindung keinen exklusiven Kanal mit fester Übertragungsgeschwindigkeit gibt, bedarf es hier einer automatischen Anpassung.

Anwendungsunterstützung

Ähnlich wie Rechner mit IP-Adressen in Netzwerken adressiert werden, bedarf es einer Unterscheidung der Kommunikationsverbindungen zwischen spezifischen Anwendungen, die gemeinsam auf einem Rechner laufen. TCP- und UDP-Ports (Nummern) bilden eine Software-Abstraktion, um spezifische Anwendungen und deren Kommunikationsverbindungen voneinander unterscheiden zu können.

Namensauflösung

Es werden lieber Namen zur Bezeichnung und Identifizierung von Dingen verwendet, da sich ein Mensch diese besser merken kann. Dieses ist jedoch nicht hilfreich bei einem Netzwerk, welches anstatt von Namen mit IP Adressen arbeitet. Um in einem solchen Netzwerk eine Verbindung auf IP Ebene zu geährleisten ist eine Namensauflösung erforderlich, welche zu einem Computer - oder Domainnamen eine IP Adresse ermittelt.

Vorteile TCP/IP

• TCP/IP ist sowohl im LAN als auch im WAN nutzbar
• TCP/IP ist ein weltweiter Standard
• Umsetzung sowohl auf PCs als auch auf µC möglich sofern Schnittstelle vorhanden
• Fehlerbehandlung

Nachteile TCP/IP

• TCP/IP hat einen großen Kopfdatensatz, welcher als Header bezeichnet wird. Nutzung des Protokolls lohnt sich daher eher bei Anwendungen mit einem hohen Anteil an Nutzdaten.

Alternative zu TCP/IP

Eine Alternative zu TCP/IP ist UDP. Dieses Protokoll hat jedoch keine Fehlerbehandlung, wodurch es zu Paketverlust führen kann. Daher kam es für die Anwendung Sensordaten zu übertragen nicht in Frage.

Grundmodell zum Senden von Sensordaten vom Ardumower auf einen Diagnoserechner

Abb. 2 Diagnoseoberläche

Das Grundmodell zum Senden von Sensordaten ist in Abbildung 2 dargestellt. Innerhalb des Modells werden zur Veranschaulichung 7 Sensordaten zunächst in Single-Precision Format umgewandelt. Danach werden die Signale über ein "Mux" Block zusammengeführt. Der Ausgang des "Mux" Blocks, welcher das Überlagerte Signal enthält wird auf den Simulink Block "Arduino Wifi TCP/IP Send" geschickt. Innerhalb des Blocks ist definiert über welchen Port das Signal verschickt wird. In diesem Block ist weiterhin darauf zu achten, dass die Anzahl der zu Übertragenden Daten, wenn Sensorsignale hinzugefügt oder entfernt werden, auf die entsprechende Anzahl angepasst wird. Wird dieses missachtet kann es zu fehlerhafter Übertragung der Daten kommen.

Grundmodell zum Senden von Sensordaten vom Ardumower auf einen Diagnoserechner

Abb.3 Diagnoseoberläche

Die Diagnoseoberfläche ist ein Simulink Modell, welches auf einem Diagnoserechner läuft, der sich im gleichen Netzwerk befindet wie der Ardumower. Hierfür ist ein eigener Router bereitgestellt. Das Simulink Modell enthält einen "TCP/IP Receive" Block von Simulink. Innerhalb des Blocks ist eingestellt von welcher IP Adresse der Rechner Daten empfangen soll und über welchen Port diese Daten übertragen werden. Weiterhin ist innerhalb des Blocks spezifiziert wie viele unterschiedliche Signale Übertragen werden, in welchem Format diese Übertragen werden und in welcher Byteorder diese übertragen werden. Der "TCP/IP Receive" Block hat einen Data Ausgang. Da der Ardumower 7 unterschiedliche Sensordaten über die Wifischnittstelle überträgt wird dieser Ausgang zunächst auf einen "Demux" geführt, um die Signale voneinander zu trennen. Die einzelnen Signale werden dann als Wert über ein "Display" Block dargestellt. Die Oberfläche ist in Abbildung 3 dargestellt.

Test der drahtlosen Datenschnittstelle

Zum Test der Schnittstelle ist zunächst versucht worden die Library auf den Ardumower zu kompilieren. Nachdem die Library problemlos kompiliert werden konnte wurden weitere Tests durchgeführt um die Funktionalität der Schnittstelle zu gewährleisten. Dafür wurde überprüft, ob alle Sensordaten vom Ardumower ohne Verlust über Wifi übertragen werden. Hierfür wurden in der Library zuerst konstante Werte auf den Mux gelegt, welcher alle Signale zusammen auf den Wifi-Send Block überträgt. Hierdurch konnte genau überprüft werden, ob die Konstanten, welche in der Library festgelegt wurden ebenfalls auf dem Diagnoserechner zu sehen sind und die Übertragung von einzelnen Werten somit funktioniert. Nachdem dieser Test erfolgreich durchgeführt wurde konnten nun Tests mit den echten Sensordaten durchgeführt werden. Die Konstanten, die beim vorherigen Test benutzt worden sind konnten nun entfernt werden und alle Sensordaten, sowie einige interne Variablen, zum Beispiel Reglergrößen, wurden mit einem Mux zusammengeführt und auf den Wifi-Send Block geführt. Hierbei ist aufgefallen, dass immer stets darauf zu achten ist, dass im Simulink Block zum Senden und zum Empfangen die richtige Anzahl an zu Übertragenden Daten eingestellt ist, da die Werte ansonsten in unterschiedlicher Reihenfolge ausgegeben werden und nicht mehr richtig zuzuordnen sind. Nachdem die Blöcke auf die Anzahl der Sensordaten angepasst worden sind konnte überprüft werden ob auch sich ändernde Werte ohne Probleme übertragen werden können.

Bewertung und Ausblick

Der Chip des W-LAN Moduls ist erfolgreich auf seine Funktionen getestet worden. Das Senden und das Empfangen anhand des Chips funktioniert. Im Zuge des Tests ist eine Verbindung mit einem Rechner erforderlich gewesen. Diese konnte erfolgreich hergestellt werden um Daten über Simulink zum Modul zu senden. Bisher konnte nur das Senden vom Rechner zum Roboter mit Simulink implementiert werden. Ein Programm für das W-LAN Modul über Simulink auf den Arduino zu spielen führt bisher noch zu einer Fehlermeldung. Der nächste Schritt ist es diese zu beseitigen. Der Matlab Support ist diesbezüglich bereits informiert und hat einen Lösungsansatz vorgeschlagen. Die Kommunikation vom Roboter zum Rechner läuft in der Entwicklungszeit über einen vom Hochschulnetzwerk getrennten Router. Wenn die Entwicklung abgeschlossen ist wird die IT informiert um eine eventuelle Integration in das Hochschulnetzwerk herzustellen. Eine erste Version der Diagnoseoberfläche ist bereits in Matlab erstellt worden. Diese muss jedoch noch lauffähig gemacht werden, wenn das W-LAN Modul im Roboter integriert ist.

Der momentane Fortschritt kann mit 80% der Gesamtlösung bewertet werden.

Benötige Hardware

• ESP8266_W-Lan Modul

Vertiefende Links

• https://de.mathworks.com/help/supportpkg/arduino/examples/getting-started-with-wifi-on-arduino-hardware.html
• ArduMower Hauptseite

Quellen

https://www.elektronik-kompendium.de/sites/net/0606251.htm