ArduMower: Drahtlose Datenschnittstelle: Unterschied zwischen den Versionen

Aus HSHL Mechatronik
Zur Navigation springen Zur Suche springen
Keine Bearbeitungszusammenfassung
 
(78 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
[[Kategorie:ArduMower]]
[[Kategorie:ArduMower]]


Dieser Wiki-Beitrag ist Teil eines Projektes, welches im Rahmen vom [[Fachpraktikum_Elektrotechnik_(WS_16/17)|Fachpraktikum Elektrotechnik]] im 6. Semester [http://www.hshl.de/mechatronik-bachelorstudiengang/ 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.
Dieser Wiki-Beitrag ist Teil eines Projektes, welches im Rahmen vom [[Fachpraktikum_Elektrotechnik_(WS_16/17)|Fachpraktikum Elektrotechnik]] im 6. Semester und 7. Semester [http://www.hshl.de/mechatronik-bachelorstudiengang/ 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:  [[Benutzer:Tom_Niehaus| Tom Niehaus]]
Autoren:  [[Benutzer:Tom_Niehaus| Tom Niehaus]]
Zeile 9: Zeile 9:


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




Zeile 21: Zeile 21:


= Herangehensweise =
= Herangehensweise =
* Einarbeitung in Funktion des W-Lan Modules
* Einarbeitung in Funktion des W-Lan Modules [[ESP8266_W-Lan Modul]]
*  
* Recherche Pinbelegung (https://arduino-hannover.de/2014/12/11/wifi-kochbuch-mit-esp8266/)
[[Datei:Ardumower W-Lan_Platine_oben.png|200px|thumb|right|Bild1: Platine für W-Lan Mosul]]
* 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


= Schnittstellen =
 
= Platine =
[[Datei:W-Lan_Platine_oben.png|400px|thumb|right|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.
 
 
= Aufbau der Verbindung =
[[Datei:Matlab_Properties_Wifi.png|600px|thumb|Abb. 2 Matlab Einstellungen]]
Die Wifi Verbindung wird jedes Mal bei Einschalten des Ardumowers aufgebaut. Um eine Verbindung herzustellen oder die IP-Adresse oder das Netzwerk geändert werden soll muss dieses zunächst in den Einstellungen von Simulink getan werden. Danach muss der Ardumower erneut geflasht werden, damit das Wifi-Modul die neue Adresse oder das neue Netzwerk in dem es kommunizieren soll übermittelt bekommt. Wie zu jetzigem Stand des Ardumowers eine Verbindung hergestellt werden kann ist in Abbildung 2 dargestellt.
# Wifi Hardware auf "ESP8266" umschalten
# Haken bei "Use static IP address and disable DHCP" setzen
# Gewünschte IP Adresse eingeben (192.168.1.5 funktioniert und kann beibehalten werden)
# Namen des Netzwerks eingeben (Netzwerk des Ardumower Routers heißt derzeit "ArduMower" und kann beibehalten werden)
# Die Wifi Entschlüsselung auf WPA stellen
# Das Passwort "ArduMower2017" eingeben
# Den seriellen Port "Serial 0" verwenden
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
= Software =
== Grundmodell zum Senden von Sensordaten vom Ardumower auf einen Diagnoserechner ==
[[Datei:Simulink Modell auf Ardumower.PNG|600px|thumb|Abb. 3 Grundmodell zum Senden von Sensordaten]]
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 ==
[[Datei:Diagnoseoberfläche_Simulink.PNG|600px|thumb|Abb.4 Grundmodell zum Empfangen von Sensordaten auf einem Diagnoserechner]]
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.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
== Diagnoseoberfläche in Simulink ==
[[Datei:Oberfläche.PNG|600px|thumb|Abb.5 Diagnoseoberfläche auf Diagnoserechner]]
Die Diagnoseoberfläche ist ein Simulink Modell, welches alle Sensordaten die über Wifi übertragen werden ausliest und auf dem Bildschirm ausgibt. Die Oberfläche ist in Abbildung 5 dargestellt. Hier ist zu sehen, wie das überlagerte Signal auf einen "Demux" Block geführt wird und dieses in die Einzelsignale aufteilt. Die Reihenfolge der Signale stimmt mit der Reihenfolge des Sendens überein. Die empfangenen Sensorwerte werden dann in Matlabs Workspace geschrieben und über "Display" Blöcke ausgegeben.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
== Simulink Modell im Hauptprogramm ==
[[Datei:Senden.PNG|300px|thumb|Abb.6 Library auf Ardumower]]
Das Simulink Modell, welches sich als Library im Hauptprogramm des Ardumowers befindet, unterscheidet sich in der Hinsicht zum Grundmodell, dass dieses alle Sensordaten und alle anderen gewünschten internen Variablen an den Diagnoserechner sendet. Das Modell ist in Abbildung 6 dargestellt. Es ist zu sehen, dass insgesamt 22 Daten übertragen werden. Diese Daten setzen sich aus den Sensordaten und einigen gewünschten internen Variablen zusammen. Um das Modell in das Hauptprogramm zu integrieren und lauffähig zu machen war es notwendig einen "Rate Transition" Block hinter jeden Eingang der Library zu setzen.
 
 
 
= 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.
 
 
 
= Ergebnisse =
# Das Wifi Modul ist lauffähig gemacht worden durch die Ergänzung eines Spannungsteiler zwischen der seriellen Schnittstelle des Wlan Chips und der seriellen Schnittstelle des Arduino (s. Abbildung 1: Platine für Wlan Modul)
# Das Wifi Modul ist an die Hauptplatine des Ardumower angeschlossen worden
# Eine Verbindung zwischen dem Ardumower und einem Diagnoserechner ist hergestellt worden durch das Einstellen von Parametern in den Matlab Einstellungen (s. Abbildung 2: Matlab Einstellungen)
# Die Library zum Senden der Sensordaten an einen Diagnoserechner ist in Simulink erstellt und auf ihre Funktionalität getestet worden (s. Abbildung 6: Library auf Ardumower)
# Eine Diagnoseoberfläche ist in Simulink erstellt und getestet worden (s. Abbildung 5: Diagnoseoberfläche auf Diagnoserechner)
 
 
 
= Zusammenfassung 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. Die Library kann erfolgreich auf den Ardumower kompiliert werden. Die Kommunikation vom Roboter zum Rechner läuft in der Entwicklungszeit über einen vom Hochschulnetzwerk getrennten Router. Wenn der Entwicklungsstand bei 100 % liegt kann die IT informiert werden um eine eventuelle Integration in das Hochschulnetzwerk zu ermöglichen. Eine Diagnoseoberfläche ist in Matlab erstellt worden.
 
= Bewertung =
Der Fortschritt kann mit 80% der Gesamtlösung bewertet werden. Die letzten 20% liegen in der Kommunikation in entgegengesetzte Richtung. Diese soll genutzt werden um Grundfunktionen des Roboters über den Diagnoserechner zu steuern. Weiterhin ist eine professionellere Fertigung der Platine sinnvoll sowie die Einbindung in das Hochschulnetzwerk nach Abschluss der Entwicklungsphase.
== LOP ==
# Kommunikation von Diagnoserechner zum Ardumower um eine Steuerung von Grundfunktionen zu ermöglichen
# Einbindung in das Hochschulnetzwerk
# Fertigung einer professionelleren Platine (Bsp.: [https://www.reichelt.de/?ARTICLE=219900&PROVID=2788&gclid=Cj0KCQiAw9nUBRCTARIsAG11eifweiqaQkeTMj8GZhnJRhRfeeWsjGCWOLd4xZlr8M2QPPE-qgcKIrgaAh1uEALw_wcB?title=Erweiterte Platine])


= Benötige Hardware =
= Benötige Hardware =
* W-Lan Modul ESP8266
* [[ESP8266_W-Lan Modul]]
 
 
= Vertiefende Links =
*[http://wiki.ardumower.de/index.php?title=Hauptseite Ardumower Wiki]
*[https://de.mathworks.com/help/supportpkg/arduino/examples/getting-started-with-wifi-on-arduino-hardware.html?title=Hauptseite Matlab Dokumentation]
*[[Projekt_ArduMower | ArduMower Hauptseite]]
 
 
= Quellen =
https://www.elektronik-kompendium.de/sites/net/0606251.htm
https://www.reichelt.de/?ARTICLE=219900&PROVID=2788&gclid=Cj0KCQiAw9nUBRCTARIsAG11eifweiqaQkeTMj8GZhnJRhRfeeWsjGCWOLd4xZlr8M2QPPE-qgcKIrgaAh1uEALw_wcB

Aktuelle Version vom 28. Februar 2018, 22:40 Uhr


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

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


Nachteile TCP/IP

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


Aufbau der Verbindung

Abb. 2 Matlab Einstellungen

Die Wifi Verbindung wird jedes Mal bei Einschalten des Ardumowers aufgebaut. Um eine Verbindung herzustellen oder die IP-Adresse oder das Netzwerk geändert werden soll muss dieses zunächst in den Einstellungen von Simulink getan werden. Danach muss der Ardumower erneut geflasht werden, damit das Wifi-Modul die neue Adresse oder das neue Netzwerk in dem es kommunizieren soll übermittelt bekommt. Wie zu jetzigem Stand des Ardumowers eine Verbindung hergestellt werden kann ist in Abbildung 2 dargestellt.

  1. Wifi Hardware auf "ESP8266" umschalten
  2. Haken bei "Use static IP address and disable DHCP" setzen
  3. Gewünschte IP Adresse eingeben (192.168.1.5 funktioniert und kann beibehalten werden)
  4. Namen des Netzwerks eingeben (Netzwerk des Ardumower Routers heißt derzeit "ArduMower" und kann beibehalten werden)
  5. Die Wifi Entschlüsselung auf WPA stellen
  6. Das Passwort "ArduMower2017" eingeben
  7. Den seriellen Port "Serial 0" verwenden








Software

Grundmodell zum Senden von Sensordaten vom Ardumower auf einen Diagnoserechner

Abb. 3 Grundmodell zum Senden von Sensordaten

Das Grundmodell zum Senden von Sensordaten ist in Abbildung 2 dargestellt.

  1. Innerhalb des Modells werden zur Veranschaulichung 7 Sensordaten zunächst in Single-Precision Format umgewandelt.
  2. Danach werden die Signale über ein "Mux" Block zusammengeführt.
  3. 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.4 Grundmodell zum Empfangen von Sensordaten auf einem Diagnoserechner

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.

  1. 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.
  2. 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.
  3. Die einzelnen Signale werden dann als Wert über ein "Display" Block dargestellt.

Die Oberfläche ist in Abbildung 3 dargestellt.















Diagnoseoberfläche in Simulink

Abb.5 Diagnoseoberfläche auf Diagnoserechner

Die Diagnoseoberfläche ist ein Simulink Modell, welches alle Sensordaten die über Wifi übertragen werden ausliest und auf dem Bildschirm ausgibt. Die Oberfläche ist in Abbildung 5 dargestellt. Hier ist zu sehen, wie das überlagerte Signal auf einen "Demux" Block geführt wird und dieses in die Einzelsignale aufteilt. Die Reihenfolge der Signale stimmt mit der Reihenfolge des Sendens überein. Die empfangenen Sensorwerte werden dann in Matlabs Workspace geschrieben und über "Display" Blöcke ausgegeben.














Simulink Modell im Hauptprogramm

Abb.6 Library auf Ardumower

Das Simulink Modell, welches sich als Library im Hauptprogramm des Ardumowers befindet, unterscheidet sich in der Hinsicht zum Grundmodell, dass dieses alle Sensordaten und alle anderen gewünschten internen Variablen an den Diagnoserechner sendet. Das Modell ist in Abbildung 6 dargestellt. Es ist zu sehen, dass insgesamt 22 Daten übertragen werden. Diese Daten setzen sich aus den Sensordaten und einigen gewünschten internen Variablen zusammen. Um das Modell in das Hauptprogramm zu integrieren und lauffähig zu machen war es notwendig einen "Rate Transition" Block hinter jeden Eingang der Library zu setzen.


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.

  1. 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.
  2. 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.
  3. 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.


Ergebnisse

  1. Das Wifi Modul ist lauffähig gemacht worden durch die Ergänzung eines Spannungsteiler zwischen der seriellen Schnittstelle des Wlan Chips und der seriellen Schnittstelle des Arduino (s. Abbildung 1: Platine für Wlan Modul)
  2. Das Wifi Modul ist an die Hauptplatine des Ardumower angeschlossen worden
  3. Eine Verbindung zwischen dem Ardumower und einem Diagnoserechner ist hergestellt worden durch das Einstellen von Parametern in den Matlab Einstellungen (s. Abbildung 2: Matlab Einstellungen)
  4. Die Library zum Senden der Sensordaten an einen Diagnoserechner ist in Simulink erstellt und auf ihre Funktionalität getestet worden (s. Abbildung 6: Library auf Ardumower)
  5. Eine Diagnoseoberfläche ist in Simulink erstellt und getestet worden (s. Abbildung 5: Diagnoseoberfläche auf Diagnoserechner)


Zusammenfassung 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. Die Library kann erfolgreich auf den Ardumower kompiliert werden. Die Kommunikation vom Roboter zum Rechner läuft in der Entwicklungszeit über einen vom Hochschulnetzwerk getrennten Router. Wenn der Entwicklungsstand bei 100 % liegt kann die IT informiert werden um eine eventuelle Integration in das Hochschulnetzwerk zu ermöglichen. Eine Diagnoseoberfläche ist in Matlab erstellt worden.

Bewertung

Der Fortschritt kann mit 80% der Gesamtlösung bewertet werden. Die letzten 20% liegen in der Kommunikation in entgegengesetzte Richtung. Diese soll genutzt werden um Grundfunktionen des Roboters über den Diagnoserechner zu steuern. Weiterhin ist eine professionellere Fertigung der Platine sinnvoll sowie die Einbindung in das Hochschulnetzwerk nach Abschluss der Entwicklungsphase.

LOP

  1. Kommunikation von Diagnoserechner zum Ardumower um eine Steuerung von Grundfunktionen zu ermöglichen
  2. Einbindung in das Hochschulnetzwerk
  3. Fertigung einer professionelleren Platine (Bsp.: Platine)

Benötige Hardware


Vertiefende Links


Quellen

https://www.elektronik-kompendium.de/sites/net/0606251.htm https://www.reichelt.de/?ARTICLE=219900&PROVID=2788&gclid=Cj0KCQiAw9nUBRCTARIsAG11eifweiqaQkeTMj8GZhnJRhRfeeWsjGCWOLd4xZlr8M2QPPE-qgcKIrgaAh1uEALw_wcB