Plattfuß lässt grüßen: Automatische Aufzeichnung und Analyse der Qualität von Fahrradwegen
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Nachhaltige Kommunikationsnetze Universität Bremen Prof. Dr. Anna Förster Bachelorarbeit Plattfuß lässt grüßen: Automatische Aufzeichnung und Analyse der Qualität von Fahrradwegen von Ivan Reichert Matr.-Nr. 3059324 Bremen, den 30. Januar 2021 Betreut durch: Prof. Dr. Anna Förster Prof. Dr. Peter Haddaway Dipl.-Ing. Jens Dede
Ich versichere, daß die vorliegende Arbeit – bis auf die offizielle Betreuung durch den Lehrstuhl – ohne fremde Hilfe von mir durchgeführt wurde. Die verwendete Literatur ist im Literaturverzeichnis vollständig angegeben. Bremen, den 30. Januar 2021 (Ivan Reichert)
ZUSAMMENFASSUNG In einer stetig wachsenden Globalisierung werden immer mehr Grünflächen in der Stadt zugebaut und mit städtischem (urbanem) Chaos gefüllt. Deshalb achten Menschen, die von Natur mit der Welt um sie herum einig sind, darauf, dass ihr Weg zur Arbeit/Schule mög- lichst angenehm ist (ruhige Umgebung, saubere Luft). Bei der Wahl dieses Weges lassen sich die Menschen entweder von ihren eigenen Beobachtungen oder von den Beobachtungen anderer leiten und haben kein vollständiges Bild von der Stadt um sie herum. Das Ziel dieser Arbeit ist, solchen Menschen zu helfen, den besten Weg zwischen zwei Punkten zu finden, damit sie sich in den Momenten, in denen sie von zu Hause weg sind, wohl fühlen. Darüber hinaus wurde entschieden, die Sammlung von Umweltdaten in Form eines Dienstes zu organisieren, mit dessen Hilfe die gesammelten Daten ausgewertet und ein ökologisches Bild der Stadt erstellt werden konnte. Um das Dienst mit den Daten zu befüllen wurde eine mobile Messstation gebaut, die die Sammlung von den wichtigen Umweltdaten (die Feinstaubbelastung, der Geräuschpegel) ermöglicht. Die Daten werden von der Messstation zum Handy (Android-Anwendung) verschickt, wo sie mit den Metadaten ergänzt und an den Server übermittelt werden. Auf dem Server wurden die Streckenauswertung-Algorithmen entwickelt und eine Weboberflä- che gefertigt. Die Ergebnisse zeigen, dass die Daten schnell gesammelt werden können und somit das ökologisches Bild der Stadt erstellt werden kann. Aus diesen Gründen sollen mehrere Messstationen gefertigt und kostenlos an die Benutzer in verschiedenen Stadtteilen verteilt werden, um die Datenbank mit den Daten zu befühlen.
INHALTSVERZEICHNIS Zusammenfassung 1 1 Einführung 5 2 Systemanforderungen 7 2.1 Allgemeine Systemanforderungen . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2 Anforderungen an Hardware und Embedded Software . . . . . . . . . . . . . 7 2.2.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2.2 Embedded Software . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3 Anforderungen an die Android-Anwendung . . . . . . . . . . . . . . . . . . 8 2.3.1 Eigenschaften . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3.2 Benutzeroberfläche . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4 Anforderungen an den Server . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4.1 Server Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4.2 Weboberfläche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3 Anwendungsfälle 10 3.1 Die Messung der Daten mit der Messeinrichtung . . . . . . . . . . . . . . . 10 3.1.1 Der Messablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.2 Mögliche Kommunikationskanäle . . . . . . . . . . . . . . . . . . . . 10 3.1.2.1 Mobilfunknetz . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.2.2 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1.2.3 Drahtloses lokales Netzwerk (WLAN) . . . . . . . . . . . . 12 3.1.3 Kommunikation zwischen ESP32 und Android Gerät . . . . . . . . . 12 3.1.3.1 Auswahl des Datenformats . . . . . . . . . . . . . . . . . . 12 3.1.3.2 Spezifikation des Datenformats - ESP32->Andorid-Anwendung 13 3.1.3.3 Kommunikationskanal . . . . . . . . . . . . . . . . . . . . . 14 3.1.4 Die Kommunikation zwischen dem Android Gerät und dem Server . 14 3.1.4.1 Das Datenformat zwischen der Android-Anwendung und dem Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1.4.2 Der Kommunikationskanal . . . . . . . . . . . . . . . . . . 15 3.2 Die Anfrage der Streckenqualität auf der Internetseite . . . . . . . . . . . . 15 3.2.1 Die Weboberfläche . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2.2 Eingabefelder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.3 Berechnung der Ratings . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.4 Ausgabe zur Weboberfläche . . . . . . . . . . . . . . . . . . . . . . . 16 3.3 Die Anpassung des Systems für weitere Zwecke . . . . . . . . . . . . . . . . 16 4 Hardware und eingebettete Software 17 4.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.1.1 Der Mikrocontroller - ESP32 . . . . . . . . . . . . . . . . . . . . . . 17 4.1.2 Feinstaubsensor (SDS011) . . . . . . . . . . . . . . . . . . . . . . . . 18 4.1.2.1 Allgemeine Funktionsweise . . . . . . . . . . . . . . . . . . 19 4.1.2.2 Anschließen . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Inhaltsverzeichnis 3 4.1.2.3 Abfragen/Auslesen der Messdaten . . . . . . . . . . . . . . 19 4.1.3 GPS-Empfänger (EM506) . . . . . . . . . . . . . . . . . . . . . . . . 21 4.1.3.1 Allgemeine Funktionsweise . . . . . . . . . . . . . . . . . . 21 4.1.3.2 Anschließen . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.1.3.3 Abfragen/Auslesen der Messdaten . . . . . . . . . . . . . . 22 4.1.4 Lautstärke-Sensor (Grove Loudness) . . . . . . . . . . . . . . . . . . 23 4.1.4.1 Allgemeine Funktionsweise . . . . . . . . . . . . . . . . . . 25 4.1.4.2 Anschließen . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.1.4.3 Abfragen der Messdaten . . . . . . . . . . . . . . . . . . . . 25 4.1.5 Gesamtaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.1.5.1 Energieversorgung . . . . . . . . . . . . . . . . . . . . . . . 27 4.1.5.2 Funktionale Möglichkeiten der Messeinrichtung . . . . . . . 28 4.2 Eingebettete Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.2.1 Arduino Integrated Development Environment (IDE) . . . . . . . . . 29 4.2.1.1 ESP32 Grundeinrichtung in Arduino IDE . . . . . . . . . . 29 4.2.1.2 Struktur des Codes . . . . . . . . . . . . . . . . . . . . . . 29 4.2.2 Verwendung von Bibliotheken . . . . . . . . . . . . . . . . . . . . . . 30 4.2.2.1 AnalogWrite Bibliothek . . . . . . . . . . . . . . . . . . . . 30 4.2.2.2 BLE Bibliotheken . . . . . . . . . . . . . . . . . . . . . . . 30 5 Android Anwendung 31 5.1 Oberfläche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.2 Verbindung mit der Messeinrichtung . . . . . . . . . . . . . . . . . . . . . . 32 5.3 Anzeige der gemessenen Daten . . . . . . . . . . . . . . . . . . . . . . . . . 32 6 Server 34 6.1 Allgemein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 6.2 Server Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 6.3 Server Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 6.3.1 Model-View-Presenter-Schema . . . . . . . . . . . . . . . . . . . . . 34 6.3.2 Die Stuktur von Django Code . . . . . . . . . . . . . . . . . . . . . . 35 6.4 Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 6.4.1 Die Einstellungen der Datenbank im Django-Framework . . . . . . . 36 6.4.2 Die Einstellungen der Datenbank auf dem Server . . . . . . . . . . . 36 6.4.3 Die Datenbankstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . 37 6.4.3.1 Klasse DataTable . . . . . . . . . . . . . . . . . . . . . . . 37 6.4.3.2 Klasse TelemetryTable . . . . . . . . . . . . . . . . . . . . . 37 6.4.3.3 Klasse HistoryTable . . . . . . . . . . . . . . . . . . . . . . 38 6.5 Funktionsweise (Funktionale Teile) . . . . . . . . . . . . . . . . . . . . . . . 38 6.5.1 Bearbeitung von POST-Request . . . . . . . . . . . . . . . . . . . . 38 6.5.2 Umrechnung der Koordinaten . . . . . . . . . . . . . . . . . . . . . . 40 6.5.3 Streckenauswertung . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 6.5.3.1 Die Weboberfläche . . . . . . . . . . . . . . . . . . . . . . . 41 6.5.3.2 Berechnungsskripten . . . . . . . . . . . . . . . . . . . . . . 42 6.5.4 Webinterface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4 Inhaltsverzeichnis 7 Die Testergebnisse des Systems 46 7.1 Die Strecke: Neckarstr. 4, Bremen - Hermann-Köhl-Straße 7, Bremen . . . . 46 7.2 Die Strecke: Neckarstr. 4, Bremen - “AOK - Hauptgeschäftsstelle Bremen”, Bürgermeister-Smidt-Straße, Bremen . . . . . . . . . . . . . . . . . . . . . . 48 7.3 Datennutzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 7.4 Energieeffizienz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 8 Zusammenfassung und Ausblick 51 8.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 8.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 A Anhang 52 A.1 Einrichtung von Arduino IDE für ESP32 . . . . . . . . . . . . . . . . . . . 52 A.2 Django Installationsanleitung . . . . . . . . . . . . . . . . . . . . . . . . . . 54 A.3 models.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 A.4 views.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 A.5 map.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Abbildungsverzeichnis 65 Tabellenverzeichnis 66 Abkürzungsverzeichnis 67 Literaturverzeichnis 68
KAPITEL 1 Einführung Im Zeitalter von Computergeräten und Netzwerktechnologien werden immer mehr Um- weltdaten gesammelt. Auch wenn die Daten mithilfe von verschiedenen Sensoren gemessen werden können, gibt es heutzutage zu wenige mobile Stationen, womit die wichtigen und für die Menschheit relevanten Daten gesammelt werden. Die Messboxen, die in einer Stadt verteilt sind, können nur die Daten in näheren Umgebung erkennen und messen. Somit es ist fast unmöglich einen gesamten Überblick zu erschaffen und die Situation an einem bestimmten Ort zu bewerten. Dieses Problem wird heutzutage so gelöst, dass die Forscher die Messgeräte mitnehmen, zum bestimmten Ort fahren und die Messdaten auf Papier schreiben, um sie später in eine Tabellenkalkulationsanwendung zu übertragen, oder die Daten werden direkt in die Tabellen eingetragen, was aber noch spätere Bearbeitung und die Auswertung im Büro benötigt. Noch schlimmer wird es, wenn mehrere Daten von verschiedenen Sensoren gemessen oder die Position ermittelt werden sollen. Da werden die Stunden verbraucht, um solche Daten vollständig auszulesen. Für diese Bachelorarbeit wurde eine Messeinrichtung zusammengebaut, die die Messung der wichtigsten Umweltdaten durchführt. Es wird gezeigt, dass es heute schon möglich ist, eine mobile Messstation zu bauen, die die Daten automatisch aufnimmt und weiter an den Server verschickt. Auf dem Server ist es machbar, die Daten vollautomatisch mit verschie- denen Skripten auszuwerten und für die menschliche Analyse darzustellen. Außerdem sind die Originaldaten in einer Datenbank gespeichert und für die Betrachter zugänglich. Die Bachelorarbeit wurde von zwei Personen gefertigt (Ivan Reichert aus Fachbereich 1 und Dmytro Reznik aus Fachbereich 3) um das System komplett entwickeln zu können. Das System ist demzufolge in 3 Teile aufgeteilt: • Die Messeinrichtung auf Basis von einem ESP32-Mikrocontroller ist von Herrn Ivan Reichert gefertigt • Die Android Anwendung ist von Herrn Dmytro Reznik erstellt[1] • Der Server für die Lagerung und die Auswertung von den gemessenen Daten ist von Herrn Ivan Reichert aufgesetzt, konfiguriert und programmiert. Außerdem sind von Ihm die Koordinaten-Umrechnungsskripten und das Webinterface erstellt. Herr Dmy- tro Reznik hat seinerseits sich mit den Streckenauswertungs-Algorithmen beschäftigt. Die Hauptfunktionalität des Systems ist die punktweise Ermittlung der Umweltdaten (Fein- staubbelastung, Geräuschpegel, GPS Position) entlang einer Strecke, die Weiterleitung der Daten via Bluetooth zu der Android Anwendung, hinzufügen von Metadaten auf dem Handy und das Verschicken der Daten an den Server. Auf dem Server werden die Da- ten ausgewertet, gespeichert und zur weiteren Bearbeitung vorbereitet. Außerdem wurde die Möglichkeit erschaffen, auf einer Internetseite mithilfe von Google API, die Strecken zwischen zwei Punkten zu finden und Anhang von den gemessenen und im System ge- speicherten Daten die Bewertung (die Luftqualität, der Geräuschpegel) von den einzelnen
6 1. Einführung Strecken darzustellen. Somit haben die Benutzer die Möglichkeit einen am besten passen- den Weg (sowie Fahrrad als auch Fußgängerweg) zwischen zwei Punkten zu finden. Die Messeinrichtung ist auf Basis von einem ESP32-Mikrocontroller realisiert. Der ESP32 ist “Arduino Kompatibel” und es können somit alle Sensoren benutzt werden, die eine Schnittstelle zu Arduino haben. Die von Sensoren gemessenen Daten werden dann über ei- ne Bluetooth-Verbindung an die Android-Anwendung gesendet. Da die Android-Plattform meistens niedrigere Einstiegspreise bittet und sehr verbreitet ist, wurde entschieden, zuerst auf Android Geräten zu konzentrieren. Für die Hardwareteile des Systems ermöglicht die ESP32-Plattform, dass die Hardware von jedem mit grundlegenden Kenntnissen der elek- tronischen Schaltungstechnik zusammengebaut bzw. verändert werden kann, während die Verwendung der C-basierten Arduino-Programmiersprache nur geringe Vorkenntnisse der Programmierung eingebetteter Systeme erfordert, um den Code an neue Anwendungsfälle anzupassen. Die folgende Bachelorarbeit beginnt mit der Analyse der grundlegenden Systemanforderun- gen des Projektes, da das Projekt aus vielen Komponenten besteht und damit es verständ- lich wird, was mit dem System zu erreichen ist. Außerdem werden drei Anwendungsfälle betrachtet und die Hauptkomponente des Systems und deren Kommunikationskanäle vor- gestellt. Im Anschluss werden für die Teststrecken die Daten gesammelt und die Strecken- auswertungen dargestellt. Die Testergebnisse werden zusammengefasst und analysiert. Außerdem wird das System und die einzelnen Komponente des Systems bewertet.
KAPITEL 2 Systemanforderungen In diesem Kapitel werden die grundlegenden Anforderungen und Eigenschaften für die in dieser Arbeit benutzten Teile definiert. 2.1 Allgemeine Systemanforderungen Das Ziel der Bachelorarbeit ist die Entwicklung und die Tests des Systems, das die posi- tionsbasierten Messungen durchführen und die Ergebnisse nachher in einem Webinterface anzeigen kann. Das System soll aus 3 Teilen bestehen: • Auf ESP32 basierte Messeinrichtung • Android Anwendung • Server für die Datenlagerung und die Datenbearbeitung mit einer Weboberfläche Die Messeinrichtung soll mit dem Android Gerät kommunizieren. Die Kommunikation erfolgt via Bluetooth. Wenn die Bluetooth Verbindung aufgebaut ist, soll die Messein- richtung mit den Messungen anfangen. Es sollen die Global Positioning System (GPS)- Position, die Feinstaubbelastung und der Geräuschpegel gemessen werden. Nachdem alle Daten von Sensoren ausgelesen worden sind, sollen die Daten via Bluetooth zum Handy verschickt werden. Auf dem Handy (Android Anwendung) soll das Hinzufügen von Me- tadaten erfolgen. Das gesamte Datenpaket soll danach an den Server verschickt werden. Beim Verschicken soll das Representational State Transfer (REST)-Application Program- ming Interface (API) Prinzip benutzt werden, dh. es wird ein JavaScript Object Notati- on (JSON) über Hypertext Transfer Protocol (HTTP) gesendet. Auf dem Server soll die Datenspeicherung in die PostgreSQL Datenbank erfolgen. Zusätzlich sollen auf dem Server die Algorithmen für die Streckenauswertung entwickelt werden und es soll für die Benut- zer möglich sein, anhand der gemessenen und in der Datenbank gespeicherten Daten eine Streckenauswertung zu bekommen und somit einen am besten passenden Weg zwischen zwei Punkten finden zu können. 2.2 Anforderungen an Hardware und Embedded Software Die Messeinrichtung soll folgende grundlegende Eigenschaften haben: • Tragbar • Eigene Versorgungsquelle (Batterie) • Kompakt • Erweiterbar (große Auswahl von möglichen Sensoren) • Arduino-Plattform kompatibel • Leistbar (Kostengünstig) 2.2.1 Hardware Aus den Eigenschaften können die folgenden Kriterien für Hardware Auswahl abgeleitet werden. Die Sensoren sollen: • kompakt sein
8 2. Systemanforderungen • eine entsprechende Masse haben (geringes Gewicht) • möglichst geringe Energieverbrauch haben • Arduino kompatibel sein (eine Serielle Schnittstelle haben) 2.2.2 Embedded Software Die Software sollte auf möglichst vielen Gerätetypen laufen. Außerdem soll der Code gut dokumentiert und leicht anpassbar sein. Es soll auch möglich werden, das System mit den weiteren Sensoren zu erweitern. 2.3 Anforderungen an die Android-Anwendung Die Anwendung soll auf vielen unterschiedlichen Geräten laufen, die eine Bluetooth Funk- tion haben. Die Anwendung soll auch an den Low-Budget Geräten benutzbar sein. 2.3.1 Eigenschaften Die Anwendung soll die Möglichkeit haben: • in der nähe verfügbaren Geräte anzuzeigen • die gemessenen Daten zu bekommen • die Metadata hinzufügen zu können • die Daten von Sensoren anzuzeigen • den Status anzuzeigen, wenn ein Sensor ausgefallen ist. 2.3.2 Benutzeroberfläche Die Benutzeroberfläche soll Benutzerfreundlich sein. Die Knöpfe und Texte sollen gut lesbar sein. Die Funktionalität der Android Anwendung soll auch nicht stark von Standard abweichen und bei der Möglichkeit die Standardfunktionen haben. Außerdem soll die Anwendung das Fenster mit der Liste der verfügbaren Bluetooth-Geräten haben, wo die Messeinrichtung (die Messbox) für die Verbindung ausgewählt werden kann. Es soll ein weiteres Fenster vorhanden sein, wo die gemessenen Daten angezeigt werden. 2.4 Anforderungen an den Server Es soll einen Server sein, wo die Windows oder Linux Betriebssystem installiert werden kann. Der Server soll eine Internetverbindung haben, um die Daten bekommen zu können. Außerdem ist es wichtig, dass der Server auch eine statische Internet Protocol (IP)-Adresse hat, um von außen erreichbar zu sein. Es sollen die Streckenbewertungsalgorithmen er- stellt werden und es soll im Webinterface möglich sein, nach der Eingabe von Start und Endpositionen die Streckenbewertung zu bekommen. 2.4.1 Server Hardware Die Server-Hardware soll die folgenden Voraussetzungen erfüllen: • 2 CPU-Kerne • 2 GB RAM • 3 GB Speicherplatz • Netzwerk Anschluss • optimal: eine unterbrechungsfreie Stromversorgung (USV)
2.4. Anforderungen an den Server 9 Außerdem soll es möglich sein, dass der Server mit einem Raspberry Pi realisiert werden kann, was die Kosten für Server Hardware reduzieren wird. 2.4.2 Weboberfläche Die Weboberfläche soll Benutzerfreundlich sein. Es soll ein “single page” Webinterface er- stellt werden. Die Grundfunktionalitäten des Projektes sollen da erwähnt und die Strecken- auswertung in der Oberfläche angezeigt werden. Außerdem soll die Weboberfläche Mobil- optimiert sein. Das Webinterface soll für alle Benutzer zugänglich sein. Die Administrator-Seite des Djan- go Frameworkes soll die Authentifizierungsseite haben.
KAPITEL 3 Anwendungsfälle Da das entwickelte System komplex und vielfältig ist, sollen es 3 unterschiedliche Anwen- dungsfälle betrachtet werden: • Die Messung der Daten mit der Messeinrichtung • Die Anfrage der Streckenqualität auf der Internetseite • Die Anpassung des Systems für weitere Zwecke 3.1 Die Messung der Daten mit der Messeinrichtung Der erste Fall der Benutzererfahrung ist, dass der Benutzer eine vorprogrammierte Box kriegt und per Bluetooth mit der Box verbindet. Danach erfolgt die automatische Messung und Übermittlung der Daten an den Server. 3.1.1 Der Messablauf Der Benutzer soll zuerst die Spannungsversorgungsquelle anschließen. In unserem Fall es soll einen Knopf auf der Powerbank getätigt werden. Es kann auch abweichen, wenn eine andere Versorgungsquelle benutzt wird. Ab dem Moment der Einschaltung hat der Benut- zer ca. 30 Sekunden um mit der Messeinrichtung zu verbinden. Wenn es in 30 Sekunden nicht geschieht, werden die Sensoren ausgeschaltet und die Messeinrichtung wird in Schlaf- modus geschickt. Ab dem Moment der erfolgreichen Verbindung brauchen die Sensoren die Zeit um richtig zu starten. Feinstaubsensor (SDS011) braucht ca. 10 Sekunden um die erste Luftmenge einzusaugen und zu messen, GPS-Empfänger (EM506) braucht laut offizielle Dokumentation ca. 45 Sekunden (Cold start) um die Postion zu bestimmen. Die Sensoren liefern die Daten über die Serielle Schnittstelle und der ESP32 ist so pro- grammiert, dass der Mikrocontroller im Datenstrom von Sensoren nach dem benötigten “Header” sucht, um die Daten danach auszulesen. Die genaue Vorgehensweise ist im Ka- pitel Hardware beschrieben. Der Messablauf ist für die Veranschaulichung im Form von einer Diagramm auf der Abbildung 3.1 dargestellt. 3.1.2 Mögliche Kommunikationskanäle In diesem Abschnitt werden die gängige Kommunikationsstechnicken erklärt und deren Vorteile genannt. 3.1.2.1 Mobilfunknetz Mobilfunknetz ist eine der Arten der mobilen Funkkommunikation, die auf einem zellularen Netzwerk basiert. Das Hauptmerkmal ist, dass das gesamte Versorgungsgebiet in Zellen unterteilt wird, die durch die Versorgungsgebiete der einzelnen Basisstationen definiert sind. Die Zellen überlappen sich teilweise und bilden zusammen ein Netzwerk. Das Netz besteht aus räumlich getrennten Sendeempfängern, die im gleichen Frequenzbe- reich arbeiten, und Vermittlungseinrichtungen, die es ermöglichen, den aktuellen Standort
3.1. Die Messung der Daten mit der Messeinrichtung 11 Abbildung 3.1: Der Messablauf auf dem ESP32 der mobilen Teilnehmer zu bestimmen und die Kontinuität der Kommunikation zu gewähr- leisten, wenn sich ein Teilnehmer von einem Abdeckungsbereich in einen anderen bewegt. Es kann sowohl UMTS (3G) als auch LTE (4G) Mobilfunkstandard benutzt werden, da die beiden Datenübertragungsraten für die Projektzwecken ausreichend sind. 3.1.2.2 Bluetooth Bluetooth ist eine Herstellerspezifikation für drahtlose persönliche Netzwerke . Bluetooth ermöglicht es, den Geräten über eine zuverlässige und kostenlose Funkfrequenz für die Kommunikation im Nahbereich zu kommunizieren. Über Bluetooth können diese Geräte miteinander austauschen, wenn sie sich in einer Reichweite von ca. 10 m in älteren Versio- nen des Protokolls und bis zu 1500 m ab der Bluetooth-Version 5 befinden. Die Reichweite ist stark abhängig von Hindernissen und Störungen, auch im gleichen Raum.1 Bluetooth Low Energy (BLE) - ist eine Version der Kernspezifikation für die Bluetooth- Funktechnologie, deren wichtigster Vorteil der extrem niedrige Spitzen-, Durchschnitts- und Leerlaufstromverbrauch ist. Geräte, die BLE verwenden, verbrauchen weniger Strom als andere Bluetooth-Geräte frü- herer Generationen. In vielen Fällen können die Geräte mehr als ein Jahr lang mit einer einzigen Miniaturbatterie laufen, ohne dass sie wieder aufgeladen werden müssen. Auf diese Weise wird es möglich sein, z.B. kleine Sensoren im Dauerbetrieb (wie einen Tempe- ratursensor) mit anderen Geräten (z.B. das Handy) kommunizieren zu lassen. 1 Vgl. Bluetooth Tutorial | Tutorial-Reports.com: in: tutorial-reports.com, [online] http://www.tutorial- reports.com/wireless/bluetooth/tutorial.php [Abgerufen am 30.01.2021] [2].
12 3. Anwendungsfälle Diese Version der Bluetooth-Spezifikation ermöglicht die Unterstützung einer breiten Pa- lette von Anwendungen und reduziert die Größe des Endgeräts für den bequemen Einsatz in den verschiedenen Bereichen.2 3.1.2.3 Drahtloses lokales Netzwerk (WLAN) Wireless Local Area Network (WLAN) ist ein lokales Netzwerk, das auf drahtloser Tech- nologie basiert. Bei dieser Art des Netzwerkaufbaus erfolgt die Datenübertragung über die Luft. Die Geräte werden ohne Kabelverbindungen in das Netzwerk eingebunden. Die am weitesten verbreitete Methode der Konstruktion ist Wireless Fidelity (WI-FI). WI-FI ist die Technologie der kabellosen Netzwerken mit den Geräten, die IEEE 802.11 Standarten entsprechen. 3.1.3 Kommunikation zwischen ESP32 und Android Gerät In diesem Abschnitt werden das Datenformat und der Kommunikationskanal zwischen dem ESP32 und der Android-Anwendung vorgestellt. 3.1.3.1 Auswahl des Datenformats Es gibt verschiedene Datenformate, die für die Kommunikation zwischen zwei Geräten benutzt werden können. Bei der Auswahl des Formats der Datendarstellung wurden Extensible Markup Langua- ge (XML) und JSON verglichen. Das sind die zwei Datenformaten, die gut für Maschinen und Menschen lesbar sind. Außerdem haben sie auch entsprechende Vorteile, die folgend angeschaut werden. Extensible Markup Language (XML) XML ist eine Auszeichnungssprache, die eine Reihe von Regeln für die Kodierung von Dokumenten in einem Format definiert, das sowohl für Menschen als auch für Maschinen lesbar ist. Die Design-Ziele von XML betonen Einfachheit, Allgemeinheit und Verwend- barkeit im Internet. Es ist ein textuelles Datenformat mit starker Unterstützung durch Unicode für verschiedene menschliche Sprachen. Obwohl sich das Design von XML auf Dokumente konzentriert, wird die Sprache häufig für die Darstellung beliebiger Daten- strukturen verwendet, wie z.B. in Webdiensten.3 JavaScript Object Notation (JSON) JSON ist ein offenes Standard-Dateiformat und Datenaustauschformat, das menschenles- baren Text verwendet, um Datenobjekte zu speichern und zu übertragen, die aus Attribut- Wert-Paaren und Array-Datentypen bestehen. Es ist ein sehr verbreitetes Datenformat mit einer Vielzahl von Anwendungen, wie z.B. als Ersatz für XML in Asynchronous JavaScript and XML (AJAX)-Systemen. Außerdem ist JSON ein sprachunabhängiges Datenformat. Parser und Generatoren sind in allen populären Sprachen vorhanden.4 Da es an dieser Stelle wenig um die Webdatenaustausch handelt, wurde für die Kommunika- tion zwischen dem ESP32 und der Android-Anwendung ein JSON ausgewählt. Außerdem 2 Vgl. Wikipedia contributors: Bluetooth Low Energy, in: Wikipedia, 20.01.2021b, [online] htt- ps://en.wikipedia.org/wiki/Bluetooth_Low_Energy [Abgerufen am 30.01.2021] [3]. 3 Vgl. Extensible Markup Language (XML): in: w3.org, [online] https://www.w3.org/XML/ [Abgerufen am 31.01.2021] [4]. 4 Vgl. Einführung in JSON in: json.org, [online] https://www.json.org/json-de.html [Abgerufen am 30.01.2021] [5].
3.1. Die Messung der Daten mit der Messeinrichtung 13 bietet JSON auch gute Testmöglichkeiten, da es schnell umgebaut werden kann und von Menschen gut lesbar ist. 3.1.3.2 Spezifikation des Datenformats - ESP32->Andorid-Anwendung JSON Datenbeispiel: 1 { 2 " pdegree " : " 5 3 " , 3 " pminutes " : " 0 4 . 3 7 6 1 " , 4 " pole " : " N " , 5 " hdegree " : " 0 0 8 " , 6 " hminutes " : " 4 7 . 1 5 1 4 " , 7 " hemisphere " : " E " , 8 " mic " : " 8 1 3 " , 9 " pm 1 0 " : " 1 4 " , 10 " pm 2 5 " : " 6 " , 11 " bat " : " 0 . 0 0 " 12 } Grade des Breitengrads (pdegree) Der GPS-Empfänger liefert die Daten im Form von Dezimalgrades. Für die bequeme Wei- terverarbeitung werden die Daten schon auf dem ESP32 getrennt und separat im JSON eingegeben. Somit hat der Schlüssel “pdegree” den Grad-Wert. Der Grad-Wert bezieht sich auf den Pol (entweder Nord- oder Südpol) Minuten des Breitengrads (pminutes) Der Schlüssel “pminutes” liefert demzufolge den Minuten-Wert des Dezimalgrades. Pol des Breitengrads (pole) Der Schlüssel “pole” bestimmt ob es um einen geografischen Nord- oder Südpol handelt. Der Wert kann nur “N” oder “S” sein. Grade des Längengrads (hdegree) Gleich wie “pdegree” hat der Schlüssel “hdegree” den Grad-Wert der Hemisphäre. Minuten des Längengrads (hminutes) “hminutes” liefert dementsprechend den Minuten-Wert der Hemisphäre. Hemisphäre des Längengrads (hemisphere) Der Schlüssel “hemisphere” bestimmt ob es um die östliche und die westliche Hemisphäre handelt, nach dem Längengrad bezüglich des Nullmeridians und des 180. Längengrads. Der Wert kann nur “E” (östliche) oder “W” (westliche) sein. Geräuschpegel (mic) Hier wird ein Mittelwert der letzten 50 Messungen des Geräuschsensors (Grove Loudness Sensor) eingegeben. Feinstaubbelastung (pm10 und pm 25) Das Feinstaubsensor (SDS011) verwendet das Prinzip der Laserstreuung und kann die Par- tikelkonzentration zwischen 0,3 bis 10 µm in der Luft ermitteln. Der Sensor kann in zwei
14 3. Anwendungsfälle Bereichen die Teilchen in der Luft messen und liefert entsprechend zwei Werte. Der Wert µg ‘pm10‘ gibt an, wie viel Teilchen (in m 3 ) im Bereich um 10 µm in der Luft sind. Der µg Wert “pm25” gibt an, wie viel Teilchen (auch in m 3 ) im Bereich um 2.5 µm in der Luft vorhanden sind. Batterie (bat) Der Schlüssel “bat” ist für die Batteriemessung vorgesehen, wenn ein Lithium-Polymer- Akkumulator benutzt werden soll. Jetzt hat die externe Powerbank eigene Batterieanzeige und muss nicht extra gemessen werden. 3.1.3.3 Kommunikationskanal Nachdem die Daten (die Feinstaubbeslastung, die GPS-Position und die Lautstärke der Umgebung) ausgelesen wurden, werden die Daten in ein JSON zusammengebunden und für die Ausgabe vorbereitet (JSON wird bei jeder Messung aktualisiert). Da die Gerä- te (der ESP32 und das Android-Gerät) sich immer in der Nähe befinden und der ESP32 schon das Bluetooth Modul auf der Platine hat, wurde es entschieden den Bluetooth Kanal für die Kommunikation zwischen zwei Geräten zu nutzen. Für die Energieeffizienz wurde das BLE Protokoll ausgewählt. BLE bietet im Vergleich zum Bluetooth deutlich geringe- ren Stromverbrauch, was in diesem Projekt sehr relevant ist, da eine mobile Messstation möglich länger von einer Stromquelle arbeiten soll. 3.1.4 Die Kommunikation zwischen dem Android Gerät und dem Server Folgend wird der Verbindungskanal und das Datenformat zwischen der Android-Anwendung und dem Server erklärt. 3.1.4.1 Das Datenformat zwischen der Android-Anwendung und dem Server JSON Datenbeispiel: 1 { 2 " pdegree " : " 1 2 . 0 5 " , 3 " pminutes " : " 2 4 " , 4 " pole " : " N " , 5 " hdegree " : " 5 2 . 0 2 " , 6 " hminutes " : " 3 2 . 0 1 " , 7 " hemisphere " : " W " , 8 " time " : " 1 4 : 3 0 : 5 9 " , 9 " mic " : " 2 3 " , 10 " pm 2 5 " : " 1 5 " , 11 " pm 1 0 " : " 2 5 " , 12 " uuid " : " aee 0 bd 3c - 6 fa 7 -4 8 b 5 -8 9 da - 1 4 cfee 8 8 0 ff 1 " , 13 " bat " : " 7 . 5 " 14 } Wie im Beispiel zu sehen ist, wurden noch extra Felder in JSON hinzugefügt. Aktuelle Uhrzeit (time) Wird für die statistischen Zwecken benutzt, um die gemessenen Daten auf dem Server richtig zu strukturieren.
3.2. Die Anfrage der Streckenqualität auf der Internetseite 15 Universally Unique Identifier (UUID) Der Schlüssel UUID ist eine 128-Bit-Zahl, welche identifiziert, von welchen Gerät die In- formationen gekommen sind und somit kann es bestimmt werden, welcher Gerät die Daten aufgenommen hat. UUID ist eindeutig und wird bei der Bluetooth-Kommunikation zwi- schen dem ESP32 und dem Android-Gerät benutzt. 3.1.4.2 Der Kommunikationskanal Als Hauptkommunikationskanal zwischen dem Android-Gerät und dem Server wurde für dieses Projekt das Mobilfunknetz ausgewählt. Die Internetverbindung soll stabil sein, um die Daten ohne Verluste an den Server zu schicken. Für Datentransport von dem Android-Gerät an den Server wird das REST API Prinzip benutzt. REST API REST steht für Representational State Transfer, API für Application Programming Inter- face. Das ist eine Schnittstelle, die für die Kommunikation zwischen dem Client und dem Server dient. Das REST Prinzip wird in der Praxis meistens per HTTP/S umgesetzt. Die Dienste werden über URL-Anfragen angesprochen. Die HTTP-Methoden (GET, POST, PUT,...) geben an, welche Operation ein Dienst ausführen soll.5 In unserem Projekt wird die POST HTTP-Methode benutzt, um die Daten (JSON) an der Server zu übermitteln. JSON wird von dem Server empfangen, geprüft ob alle Daten vorhanden sind und JSON korrekt ist. Nachdem die Prüfung abgeschlossen ist, erfolgt das Einlesen der Daten, die Umrechnung der GPS-Koordinaten in richtiges Format und Speichern der Daten in der Datenbank. 3.2 Die Anfrage der Streckenqualität auf der Internetseite Der zweite Fall ist, dass der Benutzer auf der Internetseite die Start- und Endpositionen eingibt und die Streckenauswertungen bekommt, um am besten passende zu ihm Strecke auswählen zu können. 3.2.1 Die Weboberfläche Die Weboberfläche des Projektes ist ausgehend aus den Anforderungen konzipiert und programmiert. Es wurde entschieden eine Single-Page-Webanwendung (single page app- lication) zu erstellen, damit die Benutzer sofort die Funktionen des Projektes benutzten könnten. Das Web-Interface verfügt über eine kleine Beschreibung des Projektes (Ab- bildung 6.5 und 6.6), zeigt die im Projekt benutzten Komponenten (Abbildung 6.7) und verfügt über zwei Eingabefelder (Abbildung 6.3), wo es Start- und Endposition eingegeben werden soll. Nach der Eingabe der Daten in die Felder werden die Fahrtstrecken ermittelt und auf der Karte angezeigt. Außerdem werden die Streckenauswertungen in einer Tabelle unter der Karte (Abbildung 6.4) eingetragen und farblich markiert. 5 Vgl. Karlstetter, Florian: Was ist eine REST API?, in: CloudComputing-Insider, 20.07.2020, [online] https://www.cloudcomputing-insider.de/was-ist-eine-rest-api-a-611116/ [Abgerufen am 30.01.2021] [6].
16 3. Anwendungsfälle 3.2.2 Eingabefelder Die Felder dienen für die Eingabe der Informationen von Benutzern und verfügen über eine Autovervollständigungsfunktion von Google Maps. Nach der Eingabe der Daten werden aus der Start- und Endposition mithilfe von Google API die Fahrtstrecken bestimmt. 3.2.3 Berechnung der Ratings Aus den Fahrtstrecken werden die Polylinien (Polylines) bestimmt und daraus werden alle Punkte ermittelt, die zu dieser Polylinie gehören. Danach wird Punktweise mit den in der Datenbank gespeicherten Daten verglichen und ausgewertet. Die Funktionsweise und die Auswertung werden genauer im Kapitel 6 dem Abschnitt Streckenauswertung erklärt. 3.2.4 Ausgabe zur Weboberfläche Nachdem die Streckenauswertungen von dem Server berechnet worden sind, werden die Strecken auf der Karte angezeigt und die entsprechende Werte werden in der Tabelle ein- getragen und farblich markiert (Beispiel siehe Abbildung 6.3 und 6.4) 3.3 Die Anpassung des Systems für weitere Zwecke Der dritte Fall ist, dass es entschieden wird, die Messeinrichtung weiter anzupassen und/o- der den Service (Web-Anwendung) zu optimieren. Hier kann man davon ausgehen, dass es folgendes angepasst wird: • Anpassung von Hardware-Teilen • Anpassung der Android-Anwendung • Anpassung des Servers Um die Sachen anpassen zu können, wird es empfohlen, die Kapitel Hardware und ein- gebettete Software, Android Anwendung und Server zu lesen. Da wird erklärt wie die grundlegenden Teile funktionieren, wie die Abhängigkeiten sind und wie das System zu- sammengebaut ist. Außerdem wird im Kapitel 4 auf alle technischen Besonderheiten und Details eingegangen.
KAPITEL 4 Hardware und eingebettete Software In diesem Kapitel werden die technischen Aspekte und Zusammenhänge erläutert. Außer- dem wird auf die einzelnen Komponente des Systems eingegangen und die Funktionsweise erklärt. 4.1 Hardware 4.1.1 Der Mikrocontroller - ESP32 In dieser Bachelorarbeit wurde ein ESP32 Mikrocontroller benutzt. Der Mikrocontroller befindet sich auf der Platine ESP32 Thing der Firma SparkFun. Die SpakFun ESP32 Thing Platine (Abbildung 4.1) ist so ausgerüstet, dass es alles zum Programmieren und Entwickeln dabei ist. Außerdem hat ESP32 ein WI-FI/Bluetooth Modul in dem Chip integriert, der für die drahtlose Kommunikation benutzt wird. Zusätzlich ist ein FTDI FT231X Chip auf der Platine vorhanden, der USB in eine serielle Schnittstelle umwandelt und die Programmierung und die Kommunikation mit dem Computer ermöglicht. Es gibt noch die Status LEDs und die Tasten auf der Platine, welche für die Entwicklungszwecke benutzt werden können.1 Somit erledigt die Platine alle im Projekt vorgesehene Ziele (Energieeffizienz, Tragbarkeit, Arduino-Kompatibilität) und passt zum Systemkonzept. Abbildung 4.1: SparkFun ESP32 Thing Der ESP32 hat für die Kommunikation mit den anzuschließenden Geräten verschiedene Möglichkeiten und Schnittstellen-Ausführungen. Um die Sensoren (den Feinstaubsensor und den GPS-Empfänger) an der Platine anzuschließen, werden die Serielle Schnittstellen 1 Vgl. SparkFun ESP32 Thing: in: DEV-13907 - SparkFun Electronics, 30.06.2017, [online] htt- ps://www.sparkfun.com/products/13907 [Abgerufen am 30.01.2021] [7] .
18 4. Hardware und eingebettete Software benötigt.2 Serielle Schnittstelle ist eine Schnittstelle zur Datenübertragung zwischen zwei Geräten, wobei die einzelnen Bits zeitlich nacheinander übertragen werden. Für die Kommunikation mit dem GPS-Empfänger (EM506) und dem Feinstaubsensor (SDS011) wird die Universal Asynchronous Receiver Transmitter (UART)-Schnittstelle benutzt. Die UART-Schnittstelle dient für die Datenübertragung (Senden und Empfan- gen) über eine Datenleitung (RXD und TXD Anschlüsse) und bildet den Standard der seriellen Schnittstellen an PCs und Mikrocontrollern. Die Aufbau der UART Schnittstelle wird auf der Abbildung 4.2 dargestellt.3 Im Übrigen werden die UART-Pins der ESP32 mit 3.3V betrieben (und nicht wie in Arduino mit 5V ), was direktes Anschließen den Sensoren ermöglicht und auch ein Grund für die Verwendung des ESP32 war. Abbildung 4.2: Aufbau der UART Schnittstelle Der ESP32 in der Ausführung der Firma SparkFun hat drei Hardware UART Schnittstellen für die Kommunikation mit den externen Geräten. Eine davon wird für die Kommunika- tion mit dem Computer benutzt und zwei werden für die GPS- und Feinstaubsensoren verwendet. Außerdem wenn noch weitere Schnittstellen benötigt werden, kann die Softwa- reSerial Bibliothek 4 benutzt werden. Wie die Sensoren an ESP32 angeschlossen sind, wird im Kapitel Gesamtaufbau dargestellt. Grundsätzlich wird der ESP32 Mikrocontroller als Steuerelement in der Messeinrichtung benutzt. Auf dem ESP32 läuft einen Programmcode, der in einer Schleife ausgeführt wird. 4.1.2 Feinstaubsensor (SDS011) “Feinstaub entsteht vor allem bei Verbrennungsprozessen in Kraftfahrzeugen, Kraftwerken und Kleinfeuerungsanlagen, in der Metall- und Stahlerzeugung, durch Bodenerosion und aus Vorläufersubstanzen wie Schwefeldioxid, Stickoxi- den und Ammoniak. Es ist erwiesen, dass Feinstaub die Gesundheit schädigt” 5 . 2 Vgl. ESP32 Thing Hookup Guide - learn.sparkfun.com: in: Sparkfun, [online] https://learn.sparkfun.com/tutorials/esp32-thing-hookup-guide [Abgerufen am 30.01.2021] [8] . 3 Vgl. Weissgärber, Jirka: UART, in: Schlaufuchs, 02.03.2019, [online] Link [Abgerufen am 30.01.2021] [9] . 4 Link zu SoftwareSerial Bibliothek: https://www.arduino.cc/en/Reference/SoftwareSerial,[Abgerufen am 15.01.2021] 5 Umweltbundesamt, Luftqualität 2019, S:6 [Abgerufen am 30.01.2021] [10]
4.1. Hardware 19 4.1.2.1 Allgemeine Funktionsweise Der Feinstaubsensor misst die Menge der Feinstaubteilchen in der Luft. Der Sensor kann laut offizieller Dokumentation[11] die Teilchen im Bereich zwischen 0.3 µm und 10 µm messen. Der SDS011 basiert auf dem Prinzip der Lasermessung. Die Luftmenge wird mittels eingebauten Lüfter eingesaugt, die Teilchen fliegen durch die Laserstrahlen und es wird gemessen. Der Feinstaubsensor liefert zwei Messwerte: einen PM10 und einen PM2,5 Wert. Der Unterschied liegt daran, dass PM10 Wert angibt, wie viele Objekte, die im Durchmesser kleiner als 10 µm in der Luft vorhanden sind und der PM2,5-Wert, wie viele Objekte kleiner als 2,5 µm. Der Feinstaubsensor ist auf der Abbildung 4.3 dargestellt. 4.1.2.2 Anschließen Die Informationen, die für das Anschließen des Feinstaubsensors benötigt werden, sind seinem Datenblatt[11] entnommen. Die 5V Versorgungsspannung wird von ESP32 geliefert. Die UART-Pins (RXD und TXD) werden an die Pins 25 und 27 des ESP32 angeschlossen (Abbildung 4.11) Abbildung 4.3: Der Feinstaubsensor der Firma “Nova Fitness Co., Ltd.” 4.1.2.3 Abfragen/Auslesen der Messdaten Der Feinstaubsensor soll mit den Befehlen gesteuert werden. Um einen Messwert auf- zunehmen soll er zuerst in den Arbeitsmodus (WORKCMD) versetzt werden. Danach soll der Abfragebefehl (DATACMD) von ESP32 zum Feinstaubsensor (SDS011) verschickt werden und danach kann das Auslesen der Daten von dem Feinstaubsensor erfolgen. Als Datenquelle für die Steuerung von SDS011 wurde die SDS011 Bibliothek von R. Zschiegner benutzt.6 Um den Feinstaubsensor in den Arbeitsmodus versetzen zu können, soll folgender Befehl (WORKCMD) verschickt werden (Tabelle 4.1) 6 https://github.com/ricki-z/SDS011, [Abgerufen am 29.01.2021]
20 4. Hardware und eingebettete Software Byte Nr. Name HeX 0 Anfang des Befehls 0xAA 1 Befehls ID 0xB4 2 Daten Byte 1 0x06 3 Daten Byte 2 (1 um den Modus einzustellen) 0x01 4 Daten Byte 3 (1 für Work) 0x01 5 Daten Byte 4 0x00 6 Daten Byte 5 0x00 7 Daten Byte 6 0x00 8 Daten Byte 7 0x00 9 Daten Byte 8 0x00 10 Daten Byte 9 0x00 11 Daten Byte 10 0x00 12 Daten Byte 11 0x00 13 Daten Byte 12 0x00 14 Daten Byte 13 0x00 15 Daten Byte 14 (Device ID Byte 1, FF = Beliebig) 0xFF 16 Daten Byte 15 (Device ID Byte 2, FF = Beliebig) 0xFF 17 Checksum 0x06 18 Ende des Befehls 0xAB Tabelle 4.1: Aufbau des WORKCMD-Befehls von dem SDS011 Um eine Messung mit dem SDS011 durchzuführen, soll ein DATACMD-Befehl verschickt werden. Der Aufbau des DATACMD-Befehls ist in der Tabelle 4.2 dargestellt. Byte Nr. Name HeX 0 Anfang des Befehls 0xAA 1 Befehls ID 0xB4 2 Daten Byte 1 0x04 3 Daten Byte 2 (0 um keinen Modus einzustellen) 0x00 4 Daten Byte 3 0x00 5 Daten Byte 4 0x00 6 Daten Byte 5 0x00 7 Daten Byte 6 0x00 8 Daten Byte 7 0x00 9 Daten Byte 8 0x00 10 Daten Byte 9 0x00 11 Daten Byte 10 0x00 12 Daten Byte 11 0x00 13 Daten Byte 12 0x00 14 Daten Byte 13 0x00 15 Daten Byte 14 (Device ID Byte 1, FF = Beliebig) 0xFF 16 Daten Byte 15 (Device ID Byte 2, FF = Beliebig) 0xFF 17 Checksum 0x02 18 Ende des Befehls 0xAB Tabelle 4.2: Aufbau des DATACMD-Befehls von dem SDS011
4.1. Hardware 21 Aus dem Datenblatt[11] erfährt man, wie der SDS011 die gemessenen Daten ausgibt. Nach der Messung wird vom Feinstaubsensor das Datenpaket geliefert, das in der Tabelle 4.3 dargestellt ist. Byte Nr. Name Hex 0 Anfang des Datenpakets 0xAA 1 Commander No. 0xC0 2 Daten für den PM2.5 Wert PM2.5 Low Byte 3 Daten für den PM2.5 Wert PM2.5 High Byte 4 Daten für den PM10 Wert PM10 Low Byte 5 Daten für den PM10 Wert PM10 High Byte 6 ID Byte 1 7 ID Byte 2 8 Die Summe der Bytes 2 bis 7 Checksum 9 Ende des Datenpakets 0xAB Tabelle 4.3: Das Datenpaket des SDS011 Das Datenpaket beginnt mit Anfangs-Byte 0xAA. Damit das Datenpaket vollständig aus- gelesen wird, muss als erstes nach dem Anfangs-Byte gesucht werden. Falls dies gefunden wird, werden die restlichen 9 Bytes des Pakets gelesen und in einem Array gespeichert. Danach wird dieses Array auf die richtigen Anfangs- End-Bytes überprüft und, falls diese auch stimmen, wird das Checksumme-Byte überprüft. Dabei werden die Bytes 2 bis 7 aus Tabelle 4.3 miteinander addiert. Falls das Ergebnis dem Checksumme-Byte entspricht, dann ist das Datenpaket korrekt übertragen worden und kann ausgegeben werden. Die Bytes 2, 3 und 4, 5 aus Tabelle 4.3 werden dabei jeweils mit der Formel: µg High−Byte·256+Low−Byte W ert( m3) = 10 verrechnet um den Messwert des Sensors zu erhalten. Am Ende werden die errechneten Werte jeweils in einer Variable gespeichert. Wie auf der Abbildung 4.11 zu sehen ist, wird der Feinstaubsensor mit einem MOSFET gesteuert. MOSFET wird in diesem Fall als einen Schlüssel funktionieren und die Ver- bindung zum “GND” Anschluss herstellen oder trennen. Somit wird die Energieeffizienz erreicht, da der Sensor beim Bedarf ausgeschaltet werden kann. 4.1.3 GPS-Empfänger (EM506) 4.1.3.1 Allgemeine Funktionsweise Der GPS-Empfänger EM-506 von USGlobalSat (Abbildung 4.4) findet mithilfe von GPS- Satelliten seine Position und kann diese im Form von geografischen Koordinaten ausgeben. Um die Position zu bestimmen, braucht der GPS-Empfänger mindestens 3 Satelliten (die Anzahl von gefundenen Satelliten kann auch ausgegeben werden). Außerdem kann der EM506 die aktuelle Uhrzeit in UTC-Format ausgeben, dafür soll es zu mindestens einem Satelliten die Verbindung haben.[12] Der GPS-Empfänger hat folgende Vorteile: • benötigt keine externe Internetverbindung (hat eine eingebaute Patch-Antenne) • ist sehr kompakt • verfügt über eine integrierte Spannungsregelung • verfügt über LED-Statusanzeige (wird angezeigt, ob die Position gefunden wurde)
22 4. Hardware und eingebettete Software • bietet eine überragende Empfindlichkeit und Leistung, selbst in städtischen Umge- bung • hat einen UART Ausgang Abbildung 4.4: Der GPS-Empfänger EM-506 von USGlobalSat 4.1.3.2 Anschließen Im Datenblatt[12] des EM506 ist beschrieben, wie der Sensor an den Mikrocontroller an- zuschließen ist. Als Versorgungsspannung braucht der Sensor 5V und seine UART-Pins laufen mit 3.3V. Die UART-Pins (RXD und TXD) werden an die Pins 16 und 17 des ESP32 angeschlossen (Abbildung 4.11) 4.1.3.3 Abfragen/Auslesen der Messdaten Aus dem Datenblatt[12] wird auch erfahren, wie die Datenpakete des GPS-Empfängers aussehen und wie mit den Daten gehandelt wird. Der EM506 braucht keine Steuerbefehle und gibt die Daten über UART ständig aus. Bei dem GPS-Empfänger werden die Daten nacheinander in verschiedenen Format auszugeben. Da in dieser Arbeit nur die Position die Relevanz hat, wurde es entschieden das GGA-Datenpaket zu nutzen (Tabelle 4.4) Format Beschreibung $GPGGA Message ID hhmmss.sss Uhrzeit im UTC Format ddmm.mmmm Breitengrad N Angabe ob Nord (N) oder Süd (S) dddmm.mmmm Längengrad W Angabe ob Westen (W) oder Osten (E) 1 Angabe ob eine Position bestimmt wurde: 0 - nein, 1/2 - ja 07 Anzahl der gefundenen GPS-Satelliten ... In diesem Fall irrelevante Bytes Zeilenumbruch am Ende des Datenpakets Tabelle 4.4: Aufbau des GGA-Datenpakets Um dieses Datenpaket auszulesen, wird zuerst nach dem Anfangbyte “$” gesucht. Nach diesem Byte werden die nächsten Bytes überprüft, ob sie dem Header “GPGGA” entspre-
4.1. Hardware 23 chen. Falls der GGA-Datenpaket gefunden wird, werden die restlichen Bytes ausgelesen und in ein Array gespeichert. Danach wird überprüft ob die Position bestimmt wurde (siehe Tabelle 4.4). Wenn die Position bestimmt wurde, werden die Koordinaten aus dem Array ausgelesen und in Variablen gespeichert. 4.1.4 Lautstärke-Sensor (Grove Loudness) Für die Auswahl des Lautstärke-Sensors wurden vier verschiedene Mikrofone und deren Ausführungen ausgewählt. Da alle Mikrofon-Platinen einen eingebauten Filter haben, wurde es entschieden einmal alle Platinen im Serial Plotter des Arduino IDE anzuzeigen und die Interessanten im Labor mit dem Oszilloskop zu messen. Die zur Auswahl vorhandene Platinen waren: • Big Sound Sensor Abbildung 4.5: Big Sound Sensor der Firma “Elegoo” • Small Sound Sensor Abbildung 4.6: Small Sound Sensor der Firma “Elegoo” • Grove Loudness Sensor Abbildung 4.7: Grove Loudness Sensor
24 4. Hardware und eingebettete Software • Geräuschsensor auf dem Chip LM393 des unbekannten Herstellers Abbildung 4.8: Hersteller X - Chip LM393 Der Small Sound und der Sensor Hersteller X haben beim Plotten in der Arduino IDE kei- ne vernünftige Ergebnisse angezeigt und kaum eine Reaktion gezeigt. Die beiden anderen haben im Vergleich zu den oben genannten Sensoren auf die Umgebungsgeräusche reagiert und da es nicht bekannt war, wie gut die Sensoren die Umgebungsgeräusche messen kön- nen, wurde es entschieden, den Grove Loudness und den Big Sound Sensor noch mal mit dem Oszilloskop zu testen, um den Frequenzgang zu überprüfen. Die Überprüfung lief so, dass es mit dem Tongenerator das Geräusch mit der Frequenz 1.4 kHz generiert wurde und die Sensoren gleichzeitig gemessen wurden. Big Sound hat folgendes gemessen und angezeigt (Abbildung 4.9): Abbildung 4.9: Die Messung mit dem Big Sound Sensor auf der Frequenz 1.4kHz Auf der Abbildung 4.9 ist zu sehen, dass der Big Sound Sensor periodisch die Frequenzen anzeigt, die gar nicht generiert worden sind. Die Messung mit dem Loudness Sensor war erfolgreicher (Abbildung 4.10):
4.1. Hardware 25 Abbildung 4.10: Die Messung mit dem Grove Loudness Sensor auf der Frequenz 1.4kHz Auf der Abbildung 4.10 ist überschaubar, dass der Grove - Loudness Sensor nur die gene- rierte Frequenz anzeigt. Aus diesem Grund wurde der Grove - Loudness Sensor im Projekt benutzt. An dieser Stelle sollte auch erwähnt werden, dass wegen dem eingebauten Filter, die Frequenzen abgeschnitten werden, die höher als ca. 5-6 kHz sind. 4.1.4.1 Allgemeine Funktionsweise Der Grove - Loudness Sensor (Abbildung 4.7) nimmt die Lautstärke von Geräuschen in der Umgebung auf[13]. Mit Hilfe eines Verstärkers des Typs LM2904[14] und eines eingebauten Mikrofons verstärkt und filtert das Produkt die hohen Frequenzen, die über das Mikro her- ein kommen, und generiert eine positive Hüllkurve als Ausgang. Das ist die Signalerfassung für den ESP32. Der Ausgabewert hängt dabei vom Niveau des eingegangenen Geräuschs ab. Um unnötige Signalstörungen zu vermeiden, geht das Eingangssignal zweimal durch Filter im Modul. Außerdem gibt es auch noch ein Schraubpotentiometer zum Regeln der Ausgangsverstärkung. 7 4.1.4.2 Anschließen Der Sensor wird von ESP32 mit 5V Versorgungsspannung betrieben. Der Ausgabe Pin des Sensors wird an den 36 I/O Pin des ESP32 angeschlossen. 4.1.4.3 Abfragen der Messdaten Die Messung ist so realisiert, dass es 50 Messwerte von dem Sensor aufgenommen werden. Aus diesen 50 Werten wird einen Mittelwert ausgerechnet und der Mittelwert wird in eine 7 Vgl. Zuo, Baozhu: Grove - Loudness Sensor - Seeed Wiki, in: Seeed The IoT Hardware Enabler, [online] https://wiki.seeedstudio.com/Grove-Loudness_Sensor/ [Abgerufen am 30.01.2021].
26 4. Hardware und eingebettete Software Variable gespeichert. Die Variable wird in JSON ausgelesen und mit den anderen Daten zum Android Gerät verschickt. 4.1.5 Gesamtaufbau Auf der Abbildung 4.11 ist die Schaltskizze des Gesamtaufbaus der Messeinrichtung dar- gestellt. Abbildung 4.11: Schaltskizze des Gesamtaufbaus8 Und auf der folgenden Abbildung 4.12 ist der Gesamt-Hardware-Aufbau abgebildet. Hier ist auch die Powerbank der Firma “Spigen” zu sehen, die die gesamte Messeinrichtung mit der Energie versorgen wird. Abbildung 4.12: Der Gesamt-Hardware-Aufbau 8 Das SDS011 Fritzing Symbol - https://forum.fritzing.org/t/sds011-dust-sensor/7924/2, [Abgerufen am 15.01.2021]
4.1. Hardware 27 Abbildung 4.13: Der Gesamtaufbau in einer Kunstglasbox 4.1.5.1 Energieversorgung Damit die Messbox unabhängig von einer Stromquelle funktionieren kann, muss die Schal- tung eine eigene Versorgungsquelle haben. Nach der Recherche in allen Datenblättern wurde ausgerechnet, dass die Schaltung im Peak maximal 260 mAh verbrauchen würde. Im Sleep-Modus soll die Schaltung nur maximal 5 mAh verbrauchen. Um die Schaltung dauerhaft zu versorgen und keinen Aufwand mit den auswechselbaren Batterien zu betrei- ben, wurde es entschieden in erstem Entwurf eine Powerbank zu nutzen. Die Kapazität der Powerbank ist 20000 mAh und somit erreicht man ca. 100 Stunden konstanter Arbeitszeit. Danach kann die Powerbank durch einen Akkumulator ersetzt werden. Um die Energieeffizienz zu erreichen, sollen die Sensoren und der ESP32 Mikrocontroller möglichst geringeren Energieverbrauch haben. Somit ist es logisch, dass wenn die Mes- seinrichtung nicht benutzt wird, soll sie auch entweder ausgeschaltet oder in Sleep-Modus gesetzt werden. Der ESP32 und der Feinstaubsensor (SDS011) haben die Möglichkeit in Deep-Sleep Modus zu wechseln. Bei dem GPS-Sensor ist es technisch unmöglich. Deswegen wurde an dieser Stelle entschieden, dass die Sensoren über MOSFETs an die Versorgungs- quelle angeschaltet werden. Somit kann man von ESP32 die MOSFETs steuern und die Sensoren dann an- oder ausschalten, wenn es benötigt wird. Die MOSFET-Schaltung sieht folgenderweise aus (Abbildung 4.14): Abbildung 4.14: Die MOSFET-Schaltung
28 4. Hardware und eingebettete Software Wenn der Steuerpin des ESP32 3.3V (HIGH) liefert, wird MOSFET geöffnet und der Sensor wird angeschaltet. Wenn der Steuerpin aber 0V (LOW) liefert, bleibt der MOSFET geschlossen und somit der Sensor inaktiv. Die MOSFETs sind so ausgewählt, dass sie maximal 500 mA durchlassen können, was in unserem Fall ausreichend ist, da die Sensoren maximal 55 mA (GPS Sensor EM506) und 80 mA (Feinstaubsensor SDS011) verbrauchen. 4.1.5.2 Funktionale Möglichkeiten der Messeinrichtung Außerdem hat die Platine der Messeinrichtung noch paar Funktionale Teile, die erwähnt werden sollen. Es wurde eine Status-RGB-LED eingebaut (Abbildung 4.11, rechts unten). Somit ist es für Benutzer nachvollziehbar, in welchem Modus sich gerade die Platine befindet. Die möglichen Modi sind: • Warten auf die Bluetooth-Verbindung (Farbe: Hellblau) • Die Bluetooth-Verbindung ist hergestellt, die Messung wird ausgeführt (Farbe: Grün) • Die Bluetooth-Verbindung ist verloren, die Messung wird nicht ausgeführt (Farbe: Rot) • Die Platine ist im Sleep-Modus/Ausgeschaltet (LED ist inaktiv) Wenn die Messeinrichtung keine Verbindung zu dem Android-Gerät herstellen kann, wird sie im Sleep-Modus versetzt. Das bedeutet, dass die Messung nicht mehr ausgeführt wird, die Sensoren nach ca. 30 Sekunden ausgeschaltet werden und der ESP32 wird nach ca. 1 Minute auch in Sleep-Modus gesetzt. Um die Platine wieder funktionsfähig zu bekom- men, wurde ein externer “Wake-Up” Knopf eingebaut (Abbildung 4.11 “WAKE UP” rechts unten). Der ESP32 überwacht im Sleep-Modus einen Pin (in unserem Fall den Pin 33) und wenn auf diesen Pin die Spannung angelegt wird, wird ein Interrupt (eine kurzfristige Unterbrechung der normalen Programmausführung) ausgelöst und der ESP32 wird wieder in das Normalbetrieb wechseln. Zusätzlich hat die Messeinrichtung einen externen “Reset” Knopf (RST Knopf auf der Ab- bildung 4.11 rechts unten) bekommen, womit es möglich ist, die Platine und die Ausführung des Programmcodes neu zu starten. Das ist für denn Fall gedacht, wenn die Messbox nicht wie gewohnt funktioniert. Auf der Abbildung 4.11 kann man auch sehen, das es noch ein Kondensator (C1 10 µF) im “RESET” Zweig eingebaut ist. Ohne diesen Kondensator wird bei dem Flashen des Codes relativ oft ein Fehler (Abbildung 4.15) auftreten, da der ESP32 nicht in das Flash/Update- Modus wechseln kann. Das ist ein Fehler der Entwicklung des ESP32-Chips und es kann nur wie oben beschrieben, gelöst werden.
Sie können auch lesen