Smart Light: Unterschied zwischen den Versionen

Aus HSHL Mechatronik
Zur Navigation springen Zur Suche springen
Keine Bearbeitungszusammenfassung
Markierung: Manuelle Zurücksetzung
 
(181 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt)
Zeile 7: Zeile 7:


→ zurück zur Übersicht: [[:Kategorie:ProjekteET_MTR_BSE_WS2021|WS 21/22: Fachpraktikum Elektrotechnik (MTR) und Angewandte Elektrotechnik (BSE)]]
→ zurück zur Übersicht: [[:Kategorie:ProjekteET_MTR_BSE_WS2021|WS 21/22: Fachpraktikum Elektrotechnik (MTR) und Angewandte Elektrotechnik (BSE)]]
[[Datei:Titelbild SmartLight.PNG| right| mini| 700px| Prototyp des Smart Light Projektes]]




== Einleitung ==
== Einleitung ==


Das Smart Light System stellt ein Steuergerät für intelligentes Licht dar. Mithilfe eines thermischen MEMS Präsenzsensors sollen Menschen erkannt werden und dementsprechend eine Lichtquelle ein- und ausgeschaltet werden. Somit kann diese effizient und gleichzeitig vollautomatisch arbeiten. Der Unterschied zu einer reinen Abstandsmessung durch beispielsweise Ultraschallsensoren oder LiDAR Sensoren, ist der, dass die Menschen mithilfe eines MEMS Präsenzsensors auch ohne Bewegung erkannt werden können. Eine Skizze des Systems lässt sich in der folgenden Abbildung erkennen.  
Das Smart Light System stellt ein Steuergerät für intelligentes Licht dar. Mithilfe eines thermischen Präsenzsensors sollen Menschen erkannt werden und dementsprechend eine Lichtquelle ein- und ausgeschaltet werden. Somit kann diese effizient und gleichzeitig vollautomatisch arbeiten. Der Unterschied zu einer reinen Abstandsmessung durch beispielsweise Ultraschallsensoren oder LiDAR Sensoren, ist der, dass die Menschen mithilfe eines thermischen Präsenzsensors auch ohne Bewegung erkannt werden können. Eine Skizze des Systems lässt sich in der folgenden Abbildung erkennen.  


[[Datei:Skizze Radar Tracker .png| left|]]
[[Datei:Skizze Smart Light.png| left|]]
<br clear=all>
<br clear=all>
''Abbildung 1: Skizze Radar Tracker''
''Abbildung 1: Skizze Smart Light''
 
Der Sensor der verwendet werden soll ist der D6T-44L-06 vom Hersteller OMRON. Das Datenblatt des Sensors kann [[:Datei:D6T DB-EN.pdf|hier]]  eingesehen werden.


== Anforderungen ==
== Anforderungen ==
Die Systemanforderungen lassen sich Tabelle 1 einsehen.


{| class="mw-datatable"
{| class="mw-datatable"
! style="font-weight: bold;" | ID
! style="font-weight: bold;" | ID
! style="font-weight: bold;" | Typ
! style="font-weight: bold;" | Kapitel
! style="font-weight: bold;" | Inhalt
! style="font-weight: bold;" | Inhalt
|+ style = "text-align: left"|''Tabelle 1: Anforderungen''
|+ style = "text-align: left"|''Tabelle 1: Anforderungen''
|-
|-
| 001
| 001
| I
| Das System muss Lebewesen erkennen können.
| 1
| Formale Anforderungen
|-
|-
| 002
| 002
| A
| Der Mensch muss sich in einem definierten Bereich befinden, der dem Messbereich des thermischen Präsenzsensors entspricht, damit die Lichtquelle vom Steuergerät angeschaltet wird.
|
| Es dürfen nur die im Modul zugelassene Software verwendet werden.
|-
|-
| 003
| 003
| A
| Die Lichtquelle muss angeschaltet bleiben, wenn sich das Lebewesen im Messbereich nicht bewegt.
|
| Das System muss verschiedene Objekte/Körper lokalisieren können.
|-
|-
| 004
| 004
| A
| Die Lichtquelle muss ausgeschaltet werden, wenn das Lebewesen sich nicht im definierten Messbereich befindet.  
|
| Die lokalisierten Objekte müssen auf einem Display in einer Radargrafik angezeigt werden.
|-
|-
| 005
| 005
| A
| Alle elektrischen Komponenten des Messsystems müssen in einem entsprechenden Gehäuse integriert sein, mit Ausnahme der Lichtquelle.
|
| Das Radar muss einen Wirkungsbereich von 180° haben.
|-
|-
| 006
| 006
| A
| Das System muss eine LED als Lichtquelle besitzen.
|
| Falls nur ein Objekt im Sichtfeld des Radars erkannt wurde, kann dieses über eine weitere Funktion bestätigt und auf dem Display markiert werden.
|-
|-
| 007
| 007
| A
| Das System muss von einem Mikrocontroller gesteuert werden.  
|
| Wenn ein Objekt lokalisiert wird, muss ebenfalls ein akustisches Signal erfolgen.
|-
|-
| 008
| 008
| A
| Das System muss einen thermischen Präsenzsensor beinhalten.  
|
| Das Entfernen des markierten Objektes aus dem erfassbaren Bereich muss nach zwei Messzyklen einen Signalton auslösen und die Markierung auf dem Display muss gelöscht werden.
|-
|-
| 009
| 009
| A
|
| Das System basiert auf einem Mikrocontroller der die Steuerung des Systems sowie Spannungsversorgung von Sensoren und Aktoren übernimmt.
| Das System basiert auf einem Mikrocontroller der die Steuerung des Systems sowie Spannungsversorgung von Sensoren und Aktoren übernimmt.
|-
|-
| 010
| 010
| I
| Das Gehäuse des Systems muss im 3D-Druckverfahren hergestellt werden
| 2
| Software und Werkzeuge
|
|-
|-
| 011
|}
| A
 
|  
== Technischer Systementwurf ==
| Die Programmierung muss mithilfe der Software MATLAB Simulink oder der Software Arduino IDE erfolgen.
 
Der technische Systementwurf lässt sich in der folgenden Abbildung erkennen.
 
[[Datei:Funktionaler Systementwurf Smart Light.png|left|medi]]
<br clear=all>
''Abbildung 2: Technischer Systementwurf''
 
== Komponentenspezifikation ==
 
Die Komponenten des Systems werden in Tabelle 2 aufgeführt.
 
{| class="mw-datatable"
! style="font-weight: bold;" | ID
! style="font-weight: bold;" | Komponente
! style="font-weight: bold;" | Eingangsparameter
! style="font-weight: bold;" | Ausgangsparameter
! style="font-weight: bold;" | Aufgabe
! style="font-weight: bold;" | Struktur
|+ style = "text-align: left"|''Tabelle 2: Komponentenspezifikation''
|-
|-
| 012
| 001
| A
| Sensor
|  
| Startkommando für den Beginn der Messungen
| Das Objekt muss über ein YouTube Video präsentiert werden.
| Temperatur als Byte Datenpaket
| Messen der Temperaturen im erfassten Messbereich in einer Matrix mit fester Größe
| Hardwarekomponente
|-
|-
| 013
| 002
| I
| Mikrocontroller
| 3
| Byte Datenpaket mit Temperaturen
| Termine und Fristen
| Startkommando für den Sensor und Ansteuerungssignale für die Visualisierung
| Steuert das gesamte System und führt die Datenverarbeitung durch
| Hardwarekomponente
|-
|-
| 014
| 003
| A
| Visualisierung
|  
| Ansteuerungssignale vom Mikrocontroller
| Die Vorstellung des Projektes erfolgt auf der Projektmesse am 11. Januar 2022.
| keine
| Gibt den Detektionsstatus für die aktuelle Messung wieder
| Hardwarekomponente
|-
|-
| 015
| 004
| A
| Datenverarbeitung
|  
| Byte Datenpaket mit Temperaturen
| Die Abgabe des Projektes muss spätestens bis einschließlich 10. Januar 2022 im SVN und HSHL Wiki vorliegen.
| Ansteuerungssignale für die Visualisierung
| Berechnet aus dem Datenpaket die Temperaturen im Messbereich und führt den Detektionsalgorithmus durch; <br/> Entsprechend der Ergebnisse wird die Visualisierung angesteuert
| Softwarekomponente
|}
 
== Umsetzung (HW/SW) ==
 
===Hardware===
 
Im folgenden Abschnitt wird insbesondere auf den Zusammenbau und das Zusammenwirken der Komponenten eingegangen.
 
====Stückliste====
 
Alle verwendeten Hardwarekomponenten können in der Stückliste in Tabelle 3 eingesehen werden.
 
{| class="mw-datatable"
! style="font-weight: bold;" | ID
! style="font-weight: bold;" | Bezeichnung im System
! style="font-weight: bold;" | Technische Bezeichnung
! style="font-weight: bold;" | Spezifikation
|+ style = "text-align: left"|''Tabelle 3: Stückliste''
|-
| 001
| Sensor
| D6T-44L-06
| Präsenzwärmesensor der 16 Temperaturen misst und sie in einer 4x4 Pixelmatrix hinterlegt
|-
|-
| 016
| 002
| A
| LED1
|  
| Rote LED
| Der Projektvorschlag muss bis zum 05. Oktober 2021 im HSHL Wiki vorliegen.
| LED mit ungefähr 633 nm Wellenlänge
|-
|-
| 003
| LED2
| Blaue LED
| LED mit ungefähr 430 nm Wellenlänge
|-
| 004
| Widerstand 1
| R1
| 330 <math>\Omega</math> Widerstand mit einer Toleranz von <math>\pm</math> 5 %
|-
| 005
| Widerstand 2
| R2
| 330 <math>\Omega</math> Widerstand mit einer Toleranz von <math>\pm</math> 5 %
|-
| 006
| Gehäuse
| Grundkörper
| Abmaße(außen): 95 mm x 70 mm x 60 mm (LxBxH)
|-
| 007
| Gehäuse
| Deckel
| Abmaße(außen): 95 mm x 70 mm x 60 mm (LxBxH)
|-
| 008
| Versorgungsspannung
| Netzteil
| AC/DC Adapter mit 100-240 V Wechselspannung als Eingang und 9 V Gleichspannung als Ausgang
|}
|}


== Funktionaler Systementwurf/Technischer Systementwurf ==


Der funktionale Systementwurf lässt sich in der folgenden Abbildung erkennen.  
====Verdrahtungsplan====
 
Der Verdrahtungsplan welcher mit der Software Fritzing erstellt wurde lässt sich in Abbildung 3 erkennen. <br/>
 
[[Datei:Fritzing Steckplatine SmartLight.png| 700px]]
<br clear=all>
''Abbildung 3: Fritzing Steckplatinenaufbau Smart Light Projekt''
 
 
Bei Betrachtung von Abbildung 3 lässt sich erkennen, dass ein Arduino Uno dargestellt ist, welcher jedoch als Funduino Uno R3 gekennzeichnet ist. Dies liegt daran, dass es sich bei dem verwendeten Mikrocontroller um einen Arduino Uno Klon des Herstellers Funduino handelt. Beide Mikrocontroller sind von den Abmaßen, Anschlüssen und den technischen Daten identisch und somit wurde ein Arduino Uno für den Fritzing Entwurf verwendet, weil innerhalb dieser Software bisher keine Funduino Teile existieren. Des Weiteren wurden beide Status LEDs mit jeweils einem digitalen Ausgang des Funduino Uno verbunden und der Sensor über den I2C Bus an den Mikrocontroller angeschlossen. Anhand dieses Entwurfes wurde das System aufgebaut und anschließend der Schaltplan des Projektes ausgearbeitet.
 
 
====Schaltplan====
 
Der Verdrahtungsplan welcher mit der Software Multisim erstellt wurde lässt sich in Abbildung 4 erkennen. <br/>
 
[[Datei:Multisim Schaltplan SmartLight.PNG| 800px]]
<br clear=all>
''Abbildung 4: Multisim Schaltplan Smart Light Projekt''
 
 
In Abbildung 4 ist deutlich zu erkennen, dass der verwendete Funduino Uno mit einer externen Gleichspannungsquelle versorgt wird. Hierbei handelt es sich um ein Netzteil welches den Mikrocontroller mit 9 V versorgt. Die LEDs und der Sensor werden über den Mikrocontroller mit Spannung versorgt. Außerdem lässt sich erkennen, dass der Schaltplan aufgrund der Übersicht lediglich die belegten Steckverbindungsgruppen beinhaltet. Diese beiden Gruppen lassen sich in dem Steckplatinenaufbau in Abbildung 3 erkennen und somit auf dem Funduino Uno eindeutig zuordnen.
 
 
 
====Gehäuse====
 
Das Gehäuse besteht aus zwei Teilen, welche beide durch das 3D Druckverfahren gefertigt wurden. Zum Drucken wurde ein Ultimaker 2+ Connect verwendet. Das Material ist PETG in schwarz.
Der Grundkörper dient dazu den Ardunio, den Sensor und alle benötigten Kabel zu schützen. Zudem sind Ausschnitte für den Sensor, den Stromanschluss des Funduino Uno und den USB Anschluss des Mikrocontrollers vorgesehen. Zur Halterung des Sensors wurden kleine Führungen konstruiert. Durch eine Verstrebung im Grundkörper wird verhindert, dass beim Verwenden der Anschlüsse der Funduino Uno verrutschen kann. Die folgende Abbildung zeigt den CAD Entwurf des Grundkörpers.
 
[[Datei:Smart Light Grundkörper Solid Works.jpeg]]
<br clear=all>
''Abbildung 5: Smart Light Grundkörper Solid Works''
 
 
Die vollständige Konstruktion, sowie die genaue technische Zeichnung kann im [https://svn.hshl.de/svn/Elektrotechnik_Fachpraktikum/trunk/Projekte/126-150/142_Radar_Tracker SVN] betrachtet werden.
Der Deckel wurde so konstruiert, dass dieser passgenau auf den Grundkörper gesteckt werden kann ohne Verschraubungen zu verwenden. Die LEDs werden in den Deckel integriert. Die folgende Abbildung 6 zeigt den CAD Entwurf des Deckels.
 
[[Datei:Smart Light Deckel.JPG]]
<br clear=all>
''Abbildung 6: Smart Light Deckel Solid Works''
 
 
Die beiden Komponenten werden im Anschluss zusammengesetzt. Dies wurde im CAD als Baugruppe realisiert und ist in Abbildung 7 dargestellt.
 
[[Datei:Smart Light Zusammenbau.JPG]]
<br clear=all>
''Abbildung 7: Smart Light Baugruppe Solid Works''
 
 
Im Anschluss an die Konstruktion wurden die Teile mit der Software Cura von Ultimaker für den 3D Druck vorbereitet. Das Ergebnis der Gehäusefertigung ist im Titelbild des Artikels zu sehen.
 
====Prototyp====
 
Im Anschluss an die vorhergegangenen Schritte wurde die elektrischen Bauteile in das Gehäuse eingebaut.
 
[[Datei:Gehäuse Innen ohne LEDs.png| left| 800px]]
<br clear=all>
''Abbildung 8: Gehäuse von Innen ohne LEDs''
 
 
 
In Abbildung 8 lässt sich erkennen, dass der Funduino Uno mit dem Gehäuse verschraubt ist. Hierfür wurden 4 Spaxschrauben verwendet die zusätzlich gekürzt wurden. Außerdem wurde der Sensor an das Gehäuse geklebt, da er in der konstruierten Halterung nicht optimal festsaß. Alle Verbindungen zum Mikrocontroller sind über Male Pins realisiert, sodass sie jederzeit getrennt werden können. In Abbildung 9 ist das Gehäuse von Innen mit den beiden LEDs erkennbar. Alle Lötstellen wurden sorgfältig mit Schrumpfschläuchen isoliert.
 
[[Datei:Gehäuse Innen mit LEDs.PNG| left| 800px]]
<br clear=all>
''Abbildung 9: Gehäuse von Innen mit LEDs''
 
 
Der vollständige Prototyp lässt sich im Titelbild erkennen.
 
------
 
===Software===
 
Im folgenden Ablauf wird detailliert auf die erstellte Software des Projektes eingegangen. Grundlegend wurde die Software modellbasiert mit MATLAB Simulink erstellt. Dieses Modell ist in Abbildung 10 dargestellt.
 
[[Datei:Screenshot Simulinkmodell Smartlight.PNG| 1600px]]
<br clear=all>
''Abbildung 10: Simulinkmodell des Smart Light Projektes''
 
 
Um einen ersten Überblick über den Programmablauf zu erhalten, lässt sich in Abbildung 11 der Programmablaufplan der programmierten Software erkennen.
 
[[Datei:Programmablaufplan SmartLight.png| 300px]]
<br clear=all>
''Abbildung 11: Programmablaufplan des Simulinkmodells''
 
 
Die Software beginnt damit das Startkommando an den Sensor über den I2C Bus zu senden, damit er beginnt zu messen. Dies wird einmalig ausgeführt. Anschließend beginnt die endlose Zyklusschleife die nicht mehr verlassen wird. Innerhalb dieser Schleife wird zunächst ein 32 Byte langes Datenpaket über den I2C Bus ausgelesen. In diesem Datenpaket werden vom Sensor unter anderem die gemessenen Temperaturen übermittelt. Ursprünglich ist das Paket 35 Byte lang. Jedoch ist es mit den Bausteinen des "Simulink Support Package for Arduino Hardware" nicht möglich mehr als 32 Byte in einem Zyklus über den I2C Bus auszulesen. Mehr Informationen zu dieser Problematik lassen sich unter dem Abschnitt Lessons Learned wiederfinden.
 
Nach dem Auslesen der Messdaten folgt die Berechnung der Temperaturen in der zugehörigen 4x4 Pixelmatrix des Sensor. Dieser Vorgang wurde genau wie der Detektionsalgorithmus in dem Simulinkmodell mithilfe eines "MATLAB Function" Blocks implementiert. In diesem Block befindet sich der in Abbildung 12 dargestellte Programmcode.
 
[[Datei:Code Funktion getTemperature.PNG| 800px]]
<br clear=all>
''Abbildung 12: Programmcode getTemperature Funktion''
 
 
Eingangswerte der Funktion sind die Bytes aus dem Datenpaket, die der Sensor über den I2C Bus an den Mikrocontroller sendet. Diese Bytes sind in der Variable data hinterlegt. Anschließend werden zunächst einmalig die verwendeten Variablen als persistent Datentyp deklariert und entsprechende Werte zugewiesen. Das 16. Temperaturpixel kann aufgrund der bereits beschriebenen Problematik nicht ausgesen und somit berechnet werden. Dementsprechend wird ihm dauerhaft der Wert NaN zugewiesen.
 
Als nächstes werden die anderen 15 Temperaturen aus den Bytes berechnet und an ihrer zugehörigen Stelle in der 4x4 Matrix hinterlegt. Abschließend wird die vollständige Matrix an die Variable temperature zurückgeben. Eine Rückgabevariable kann nicht als persistent Variable verwendet werden. Weitergehend folgt im Programmablauf der Detektionsalgorithmus. Der Programmcode dieser MATLAB Function ist in Abbildung 13 einsehbar.


[[Datei:Funktionaler Systementwurf BSE Gruppe 1 3.png]]
[[Datei:Code Funktion DetectionAlgorithm 1 von 2.PNG| 1200px]]
<br clear=all>
[[Datei:Code Funktion DetectionAlgorithm 2 von 2.PNG| 1200px]]
<br clear=all>
<br clear=all>
''Abbildung 2: Funktionaler Systementwurf''
''Abbildung 13: Programmcode DetectionAlgorithm Funktion''
 
 
Auch in dieser Funktion werden zu Anfang alle verwendeten Variablen als persistent Datentyp einmalig deklariert und falls vorhanden ein fester oder initialer Wert zugewiesen. Insgesamt beruht der Detektionsalgorithmus auf der Differenz zwischen den einzelnen Temperaturen der Pixelmatrix und einer berechneten Umgebungstemperatur. Für die Berechnung der Umgebungstemperatur werden zunächst alle gemessenen Temperaturen in einem Array nach Größe aufsteigend sortiert. Hiernach wird ein Tiefpassfilter 1. Ordnung verwendet.
 
 
<math>\vartheta = \alpha \cdot T + (1-\alpha) \cdot \vartheta_{old}</math>
 


<math>T</math> stellt in dieser Gleichung den Mittelwert aus den vier kleinsten Temperaturwerten der Pixelmatrix dar. Diese Berechnung ergibt sich aus der Überlegung, dass das Smart Light System für die Wahrnehmung von Wärmesignaturen in einem Abstand von <br/>
ca. 2-3 m verwendet wird. Somit spannt sich die Pixelmatrix über einen Bereich von ungefähr 2.5 m^2 bis 5.7 m^2 auf (siehe [[:Datei:D6T DB-EN.pdf| Datenblatt]]). Da dieser Bereich im Vergleich mit der projizierten Fläche eines Menschen deutlich geringer ist, kann davon ausgegangen werden, dass mehrere Pixel repräsentative Messwerte für die Umgebungstemperatur besitzen.


<!-- Füllen Sie Ihre Projektskizze bis hierher aus. Fügen Sie einen Projektplan unten ein.  -->
Die Wirkung des verwendeten Tiefpassfilters lässt sich in Abbildung 14 erkennen.  


== Komponentenspezifikation ==
[[Datei:Messung Raumtemperatur Tiefpassfilter.png| left| 1000 px]]
<br clear=all>
''Abbildung 14: Messung der Raumtemperatur''
 
 
Es lässt sich deutlich erkennen, dass die Raumtemperatur über einen Zeitraum von 10 Sekunden konstant knapp unterhalb von 21 °C liegt. Dementsprechend konnte die gewünschte Wirkung mit der getroffenen Einstellung für <math>\alpha</math> = 0.6 erzielt werden. Die zeitliche Verzögerung des Messsignals (delay) durch das Tiefpassfilter kann vernachlässigt werden, weil es sich bei der Raumtemperatur um ein Messsignal mit sehr langsamen Änderungen handelt.


== Umsetzung (HW/SW) ==
Im nächsten Schritt wird über jedes Temperaturpixel gegangen und die Differenz zur Umgebungstemperatur gebildet. Ist diese größer als die Variable dT_max, welche die maximale Abweichung <math>\Delta T</math> darstellt, so wird in der Detektionsmatrix an der zugehörigen Stelle eine 1 hinterlegt. Diese 1 steht für ein gefundenes Objekt in dem jeweiligen Temperaturpixel. Anschließend wird die Anzahl an gefundenen Objekten gezählt und die Temperaturen der gefundenen Objekte abgespeichert. Wenn mindestens ein Objekt gefunden wird, schaltet das System die rote LED an, andernfalls die blaue. Abschließend wird die aktuelle Umgebungstemperatur in der Variable Temp_old für den nächsten Durchlauf hinterlegt, damit diese im Tiefpassfilter verwendet werden kann.


== Komponententest ==
== Komponententest ==
Der Sensor wurde getestet werden indem dieser an den Funduino Uno angeschlossen und im Anschluss ein Testprogramm über die Arduino IDE hochgeladen wurde. Es wurden realistische Temperaturen im Serial Monitor ausgegeben und somit die Funktionalität des Sensor bestätigt.
Weitergehend wurden die Vorwiderstände für die LEDs (R1 und R2) mit dem Multimeter UT61E des Herstellers UNI-T gemessen und die folgenden Ergebnisse erzielt.
<math>R1 =  324,5 \Omega \pm 0,5 %</math>
<math>R2 =  320,7 \Omega \pm 0,5 %</math>
Somit liegen die gemessenen Widerstände innerhalb der vorgegebenen Toleranzen. Anschließend wurde die Funktionalität der LEDs überprüft, indem diese mitsamt ihrer Vorwiderstände an den Funduino Uno angeschlossen und mithilfe eines Testprogramms zum Blinken gebracht wurden. Beide LEDs haben im programmierten Rhythmus geblinkt und der Test war somit erfolgreich. Aufgrund der bisherigen Komponententests lässt sich ebenfalls die einwandfreie Funktionalität des Mikrocontrollers festhalten, weil in zwei Tests ein Testprogramm in den Flash-Speicher geladen wurde. Außerdem wurde der autarke Betrieb des Mikrocontrollers über das Netzteil getestet. Dieser Test war ebenfalls erfolgreich und der Uno hat einwandfrei funktioniert.
Die Komponententests zur Software wurden so durchgeführt, dass hinter den jeweiligen Funktionsblöcken im Simulinkmodell ein "To Workspace" Block geschaltet wurde. Somit wurden die Variablen mit ihrem zeitlichen Verlauf an den Workspace zurückgegeben, in welchem sie dann überprüft wurden.
Die Ergebnisse der getTemperature Funktion sind exemplarisch in Abbildung 15 dargestellt.
[[Datei:Komponententest getTemperature.PNG| left]]
<br clear=all>
''Abbildung 15: Ergebnisse getTemperature Funktion''
Für die Ergebnisse der DetectionAlgorithm Funktion wurden die Ausgabe der Variablen Detektionsmatrix und zSaved herangezogen. Beide lassen sich für dieselbe Messung wie in Abbildung 15 in der folgenden Abbildung 16 erkennen.
[[Datei:Komponententest DetectionAlgorithm 1 von 2.PNG| left]]
<br clear=all>
[[Datei:Komponententest DetectionAlgorithm 2 von 2.PNG| left]]
<br clear=all>
''Abbildung 16: Ergebnisse DetectionAlgorithm Funktion''
An dieser Stelle lässt sich die Funktionalität des unteren Teils des Simulinkmodells aus Abbildung 8 bestätigen. Weitergehend wurde der obere Teil, also das Senden des Startkommandos, mit einem "Display" Block in Simulink geprüft. An dieser Stelle wurde eine 0 ausgegeben, was ein erfolgreiches Schreiben der Daten über den I2C Bus bedeutet. Die zugehörige Ansteuerung der LEDs wurde visuell überprüft und war ebenfalls erfolgreich.
Der Grundkörper des Gehäuses konnte lediglich auf Funktionalität getestet werden indem geprüft wurde, ob die Komponenten (Funduino Uno, Kabel, Sensor) in dem Grundkörper, wie während der Konstruktion vorgesehen, verbaut werden konnten. Dies war erfolgreich und es konnten alle Bauteile entsprechend der Aussparungen und vorgesehenen Platzierung im Gehäuse positioniert werden.
Der Deckel des Gehäuses konnte durch Aufsetzen auf dem Grundkörper mit den eingebauten LEDs getestet werden. Dieser Test war ebenfalls erfolgreich.


== Ergebnis ==
== Ergebnis ==
Das Projekt konnte erfolgreich durchgeführt werden und wir konnten alle gesetzten Anforderungen erreichen. Das Endprodukt lies sich gut im Raum positionieren und hat zuverlässig Lebewesen erkannt. Zudem werden die LEDs entsprechend der Detektion ein- und ausgeschaltet. Eine Überprüfung der einzelnen Anforderungen aus Tabelle 1 lässt sich in Tabelle 4 einsehen.
{| class="mw-datatable"
! style="font-weight: bold;" | Anforderungs-ID
! style="font-weight: bold;" | Testinhalt
! style="font-weight: bold;" | Testergebnis
! style="font-weight: bold;" | Anmerkungen
|+ style = "text-align: left"|''Tabelle 4: Test der Anforderungen''
|-
| 001
| Positionierung einer Person im Messbereich
| erfolgreich
| keine
|-
| 002
| Verlassen des Messbereichs und Überprüfung des Anschaltens der blauen LED
| erfolgreich
| keine
|-
| 003
| Positionierung einer Person im Messbereich ohne Bewegung
| erfolgreich
| keine
|-
| 004
| Verlassen des Messbereichs und Überprüfung des Ausschaltens der roten LED
| erfolgreich
| keine
|-
| 005
| Sichtprüfung des Prototyps
| erfolgreich
| Die LEDs sind im Deckel des Gehäuse integriert worden
|-
| 006
| Sichtprüfung des Prototyps
| erfolgreich
| keine
|-
| 007
| Überprüfung der Verschaltung des Prototyps
| erfolgreich
| keine
|-
| 008
| Sichtprüfung des Prototyps
| erfolgreich
| keine
|-
| 009
| Überprüfung der Verschaltung des Prototyps und Überprüfung der Software auf die steuernde Funktionsweise des Funduino Uno
| erfolgreich
| keine
|-
| 010
| Sichtprüfung des Gehäuses
| erfolgreich
| keine
|-
|}
Probleme bei der Erkennung entstehen nur wenn sich weitere unbewegliche Wärmequellen, z.B. elektrische Geräte, im Messbereich befinden. Dieses Problem wird nochmal ausführlich im Abschnitt Lessons Learned erläutert.


== Zusammenfassung ==
== Zusammenfassung ==
Die Projektumsetzung war erfolgreich und alle Anforderungen aus Tabelle 1 konnten mit dem Prototyp erfüllt werden.
=== Lessons Learned ===
=== Lessons Learned ===
Durch das Verwenden von MATLAB Simulink waren uns leider klare Grenzen in der Umsetzung des Projektes gesetzt. Dies bezieht sich vor allem auf die Schwierigkeiten C++ Bibliotheken in MATLAB Simulink zu verwenden sowie die Schnittstellen des Funduino Uno vielseitig zu nutzen. Beispielsweise ist es nicht möglich analoge Schnittstellen als digitale Schnittstellen zu deklarieren, wie es in der Arduino IDE möglich ist. Somit können in Simulink die Schnittstellen nur analog verwendet werden. Dementsprechend konnten keine 16 LEDs zum Aufbau einer LED Matrix verwendet werden, da nicht genügend Kontakte zum Ansteuern vorhanden waren. Außerdem war es aufgrund der anspruchsvollen Einbindung der Bibliotheken nicht möglich eine LED Matrix aus RGB LED Stripes oder ähnlichem aufzubauen. Somit musste eine Datenreduktion bei der Ausgabe in Kauf genommen werden.
Des Weiteren hat sich wie bereits erwähnt ergeben, dass der verwendete Sensor seine Daten in einem 35 Byte langen Datenpaket über den I2C Bus sendet. Das Auslesen des I2C Bus Systems ist in MATLAB Simulink auf 32 Byte begrenzt, weshalb die zwei Bytes für das letzte Temperaturpixel der 4x4 Matrix verloren gehen. Dies ist ebenfalls in herkömmlichen C++ Bibliotheken auf 32 Bytes begrenzt, wie beispielsweise der C++ Bibliothek Wire.h. Mithilfe der WireExt.h C++ Bibliothek wäre ein vollständiges Auslesen des Sensors in der Arduino IDE möglich gewesen. Für MATLAB Simulink konnte keine Lösung gefunden werden, weshalb das 16. Temperaturpixel dauerhaft als NaN definiert wird.
Weitergehend hat sich in der Anwendung des Prototyps ergeben, dass Menschen keine so signifikante Wärmesignatur besitzen wie ursprünglich erwartet. Die Temperatur an der Oberfläche weicht nur minimal von der Umgebungstemperatur ab, wenn die Person viel Kleidung trägt. Sind jedoch viele freie Hautflächen im Messbereich des Sensors vorhanden, so lassen sich diese eindeutiger erkennen. Die Temperatur auf der Hautoberfläche beträgt ungefähr 28 °C. Dementsprechend ist das gewählte <math>\Delta T</math> mit 4 °C vergleichsweise klein.
Aufgrund dieses kleinen <math>\Delta T</math> kann es passieren, dass auch statische Wärmesignaturen von z.B. Elektrogeräten, erkannt werden. An dieser Stelle könnte ein herkömmlicher Präsenzsensor auf Basis von elektromagnetischen Wellen oder Ultraschall verwendet werden, um das System zu ergänzen. Mithilfe einer Sensordatenfusion könnten im Algorithmus statische Signaturen, die über einen längeren Messzeitraum keine Positionsänderung aufweisen, gefiltert werden.
Als letztes lässt sich noch eine Einschränkung des Detektionsalgorithmus festhalten. Da der Algorithmus auf der Bildung der Umgebungstemperatur basiert, darf sich kein Lebewesen unmittelbar vor der Linse befinden (ca. 20 - 30 cm). Andernfalls würden nahezu alle Temperaturpixel dieses Lebewesen messen und somit die Berechnung der Umgebungstemperatur nicht mehr funktionieren. Deshalb würde nach einem gewissen Zeitraum keine Signatur mehr erkannt werden.


== Projektunterlagen ==
== Projektunterlagen ==
Die essentiellen Projektunterlagen lassen sich im [https://svn.hshl.de/svn/Elektrotechnik_Fachpraktikum/trunk/Projekte/126-150/142_Radar_Tracker SVN] einsehen sowie hier als [[:Datei:Smart Light.zip| ZIP-Archiv]] downloaden.
=== Projektplan ===
=== Projektplan ===
Der Projektplan lässt sich in Abbildung 17 einsehen.
[[Datei:Projektplan Smart Light.png|1400px]]
<br clear=all>
''Abbildung 17: Projektplan Smart Light''
=== Projektdurchführung ===
=== Projektdurchführung ===
Zu Beginn haben wir den Sensor ausgewählt und diesen bestellt. Da dieser einen speziellen Anschluss besitzt mussten wir daraufhin auch noch das entsprechende Kabel bestellen. Nach Abschluss dieses Vorgangs konnten wir uns der Programmierung widmen. Nach einigen Problemen, welche im Abschnitt Lessons Learned beschrieben sind, konnten wir die Programmierung erfolgreich beenden. Parallel dazu haben wir mit der Konstruktion des Gehäuses begonnen. Ausschlaggebend für die Konstruktion war dabei der Funduino Uno aufgrund seiner Größe. Nach dem erfolgten 3D Druck konnten alle Komponenten in das Gehäuse eingesetzt und das Smart Light System in Betrieb genommen werden.


== YouTube Video ==
== YouTube Video ==
{{#ev:youtube|https://youtu.be/00XEmlVwJVk |600px |left| Video 1: Smart Light Videoclip| frame}}
<br clear=all>


== Weblinks ==
== Weblinks ==
* [https://www.reichelt.de/thermischer-mems-praesenzsensor-4x4-element-5-50-c-d6t44l06-p293439.html?&trstct=pos_1&nbc=1 Präsenzsensor D6T-44L-06 bei reichelt.de]
* [https://components.omron.com/us-en/products/sensors/D6T D6T Sensoren des Herstellers Omron]
* [https://forum.arduino.cc/t/programming-omron-d6t-mems-thermal-sensor-as-people-counter/211659/7 D6T-44L-06 in der Arduino IDE mit der WireExt.h Bibilothek]


== Literatur ==
== Literatur ==

Aktuelle Version vom 9. Januar 2023, 18:48 Uhr


Autoren: Björn Schlottke & Dennis Schleicher
Betreuer: Prof. Göbel & Prof. Schneider


→ zurück zur Übersicht: WS 21/22: Fachpraktikum Elektrotechnik (MTR) und Angewandte Elektrotechnik (BSE)

Prototyp des Smart Light Projektes


Einleitung

Das Smart Light System stellt ein Steuergerät für intelligentes Licht dar. Mithilfe eines thermischen Präsenzsensors sollen Menschen erkannt werden und dementsprechend eine Lichtquelle ein- und ausgeschaltet werden. Somit kann diese effizient und gleichzeitig vollautomatisch arbeiten. Der Unterschied zu einer reinen Abstandsmessung durch beispielsweise Ultraschallsensoren oder LiDAR Sensoren, ist der, dass die Menschen mithilfe eines thermischen Präsenzsensors auch ohne Bewegung erkannt werden können. Eine Skizze des Systems lässt sich in der folgenden Abbildung erkennen.


Abbildung 1: Skizze Smart Light

Der Sensor der verwendet werden soll ist der D6T-44L-06 vom Hersteller OMRON. Das Datenblatt des Sensors kann hier eingesehen werden.

Anforderungen

Die Systemanforderungen lassen sich Tabelle 1 einsehen.

ID Inhalt
Tabelle 1: Anforderungen
001 Das System muss Lebewesen erkennen können.
002 Der Mensch muss sich in einem definierten Bereich befinden, der dem Messbereich des thermischen Präsenzsensors entspricht, damit die Lichtquelle vom Steuergerät angeschaltet wird.
003 Die Lichtquelle muss angeschaltet bleiben, wenn sich das Lebewesen im Messbereich nicht bewegt.
004 Die Lichtquelle muss ausgeschaltet werden, wenn das Lebewesen sich nicht im definierten Messbereich befindet.
005 Alle elektrischen Komponenten des Messsystems müssen in einem entsprechenden Gehäuse integriert sein, mit Ausnahme der Lichtquelle.
006 Das System muss eine LED als Lichtquelle besitzen.
007 Das System muss von einem Mikrocontroller gesteuert werden.
008 Das System muss einen thermischen Präsenzsensor beinhalten.
009 Das System basiert auf einem Mikrocontroller der die Steuerung des Systems sowie Spannungsversorgung von Sensoren und Aktoren übernimmt.
010 Das Gehäuse des Systems muss im 3D-Druckverfahren hergestellt werden

Technischer Systementwurf

Der technische Systementwurf lässt sich in der folgenden Abbildung erkennen.

medi
medi


Abbildung 2: Technischer Systementwurf

Komponentenspezifikation

Die Komponenten des Systems werden in Tabelle 2 aufgeführt.

ID Komponente Eingangsparameter Ausgangsparameter Aufgabe Struktur
Tabelle 2: Komponentenspezifikation
001 Sensor Startkommando für den Beginn der Messungen Temperatur als Byte Datenpaket Messen der Temperaturen im erfassten Messbereich in einer Matrix mit fester Größe Hardwarekomponente
002 Mikrocontroller Byte Datenpaket mit Temperaturen Startkommando für den Sensor und Ansteuerungssignale für die Visualisierung Steuert das gesamte System und führt die Datenverarbeitung durch Hardwarekomponente
003 Visualisierung Ansteuerungssignale vom Mikrocontroller keine Gibt den Detektionsstatus für die aktuelle Messung wieder Hardwarekomponente
004 Datenverarbeitung Byte Datenpaket mit Temperaturen Ansteuerungssignale für die Visualisierung Berechnet aus dem Datenpaket die Temperaturen im Messbereich und führt den Detektionsalgorithmus durch;
Entsprechend der Ergebnisse wird die Visualisierung angesteuert
Softwarekomponente

Umsetzung (HW/SW)

Hardware

Im folgenden Abschnitt wird insbesondere auf den Zusammenbau und das Zusammenwirken der Komponenten eingegangen.

Stückliste

Alle verwendeten Hardwarekomponenten können in der Stückliste in Tabelle 3 eingesehen werden.

ID Bezeichnung im System Technische Bezeichnung Spezifikation
Tabelle 3: Stückliste
001 Sensor D6T-44L-06 Präsenzwärmesensor der 16 Temperaturen misst und sie in einer 4x4 Pixelmatrix hinterlegt
002 LED1 Rote LED LED mit ungefähr 633 nm Wellenlänge
003 LED2 Blaue LED LED mit ungefähr 430 nm Wellenlänge
004 Widerstand 1 R1 330 Widerstand mit einer Toleranz von 5 %
005 Widerstand 2 R2 330 Widerstand mit einer Toleranz von 5 %
006 Gehäuse Grundkörper Abmaße(außen): 95 mm x 70 mm x 60 mm (LxBxH)
007 Gehäuse Deckel Abmaße(außen): 95 mm x 70 mm x 60 mm (LxBxH)
008 Versorgungsspannung Netzteil AC/DC Adapter mit 100-240 V Wechselspannung als Eingang und 9 V Gleichspannung als Ausgang


Verdrahtungsplan

Der Verdrahtungsplan welcher mit der Software Fritzing erstellt wurde lässt sich in Abbildung 3 erkennen.


Abbildung 3: Fritzing Steckplatinenaufbau Smart Light Projekt


Bei Betrachtung von Abbildung 3 lässt sich erkennen, dass ein Arduino Uno dargestellt ist, welcher jedoch als Funduino Uno R3 gekennzeichnet ist. Dies liegt daran, dass es sich bei dem verwendeten Mikrocontroller um einen Arduino Uno Klon des Herstellers Funduino handelt. Beide Mikrocontroller sind von den Abmaßen, Anschlüssen und den technischen Daten identisch und somit wurde ein Arduino Uno für den Fritzing Entwurf verwendet, weil innerhalb dieser Software bisher keine Funduino Teile existieren. Des Weiteren wurden beide Status LEDs mit jeweils einem digitalen Ausgang des Funduino Uno verbunden und der Sensor über den I2C Bus an den Mikrocontroller angeschlossen. Anhand dieses Entwurfes wurde das System aufgebaut und anschließend der Schaltplan des Projektes ausgearbeitet.


Schaltplan

Der Verdrahtungsplan welcher mit der Software Multisim erstellt wurde lässt sich in Abbildung 4 erkennen.


Abbildung 4: Multisim Schaltplan Smart Light Projekt


In Abbildung 4 ist deutlich zu erkennen, dass der verwendete Funduino Uno mit einer externen Gleichspannungsquelle versorgt wird. Hierbei handelt es sich um ein Netzteil welches den Mikrocontroller mit 9 V versorgt. Die LEDs und der Sensor werden über den Mikrocontroller mit Spannung versorgt. Außerdem lässt sich erkennen, dass der Schaltplan aufgrund der Übersicht lediglich die belegten Steckverbindungsgruppen beinhaltet. Diese beiden Gruppen lassen sich in dem Steckplatinenaufbau in Abbildung 3 erkennen und somit auf dem Funduino Uno eindeutig zuordnen.


Gehäuse

Das Gehäuse besteht aus zwei Teilen, welche beide durch das 3D Druckverfahren gefertigt wurden. Zum Drucken wurde ein Ultimaker 2+ Connect verwendet. Das Material ist PETG in schwarz. Der Grundkörper dient dazu den Ardunio, den Sensor und alle benötigten Kabel zu schützen. Zudem sind Ausschnitte für den Sensor, den Stromanschluss des Funduino Uno und den USB Anschluss des Mikrocontrollers vorgesehen. Zur Halterung des Sensors wurden kleine Führungen konstruiert. Durch eine Verstrebung im Grundkörper wird verhindert, dass beim Verwenden der Anschlüsse der Funduino Uno verrutschen kann. Die folgende Abbildung zeigt den CAD Entwurf des Grundkörpers.


Abbildung 5: Smart Light Grundkörper Solid Works


Die vollständige Konstruktion, sowie die genaue technische Zeichnung kann im SVN betrachtet werden. Der Deckel wurde so konstruiert, dass dieser passgenau auf den Grundkörper gesteckt werden kann ohne Verschraubungen zu verwenden. Die LEDs werden in den Deckel integriert. Die folgende Abbildung 6 zeigt den CAD Entwurf des Deckels.


Abbildung 6: Smart Light Deckel Solid Works


Die beiden Komponenten werden im Anschluss zusammengesetzt. Dies wurde im CAD als Baugruppe realisiert und ist in Abbildung 7 dargestellt.


Abbildung 7: Smart Light Baugruppe Solid Works


Im Anschluss an die Konstruktion wurden die Teile mit der Software Cura von Ultimaker für den 3D Druck vorbereitet. Das Ergebnis der Gehäusefertigung ist im Titelbild des Artikels zu sehen.

Prototyp

Im Anschluss an die vorhergegangenen Schritte wurde die elektrischen Bauteile in das Gehäuse eingebaut.


Abbildung 8: Gehäuse von Innen ohne LEDs


In Abbildung 8 lässt sich erkennen, dass der Funduino Uno mit dem Gehäuse verschraubt ist. Hierfür wurden 4 Spaxschrauben verwendet die zusätzlich gekürzt wurden. Außerdem wurde der Sensor an das Gehäuse geklebt, da er in der konstruierten Halterung nicht optimal festsaß. Alle Verbindungen zum Mikrocontroller sind über Male Pins realisiert, sodass sie jederzeit getrennt werden können. In Abbildung 9 ist das Gehäuse von Innen mit den beiden LEDs erkennbar. Alle Lötstellen wurden sorgfältig mit Schrumpfschläuchen isoliert.


Abbildung 9: Gehäuse von Innen mit LEDs


Der vollständige Prototyp lässt sich im Titelbild erkennen.


Software

Im folgenden Ablauf wird detailliert auf die erstellte Software des Projektes eingegangen. Grundlegend wurde die Software modellbasiert mit MATLAB Simulink erstellt. Dieses Modell ist in Abbildung 10 dargestellt.


Abbildung 10: Simulinkmodell des Smart Light Projektes


Um einen ersten Überblick über den Programmablauf zu erhalten, lässt sich in Abbildung 11 der Programmablaufplan der programmierten Software erkennen.


Abbildung 11: Programmablaufplan des Simulinkmodells


Die Software beginnt damit das Startkommando an den Sensor über den I2C Bus zu senden, damit er beginnt zu messen. Dies wird einmalig ausgeführt. Anschließend beginnt die endlose Zyklusschleife die nicht mehr verlassen wird. Innerhalb dieser Schleife wird zunächst ein 32 Byte langes Datenpaket über den I2C Bus ausgelesen. In diesem Datenpaket werden vom Sensor unter anderem die gemessenen Temperaturen übermittelt. Ursprünglich ist das Paket 35 Byte lang. Jedoch ist es mit den Bausteinen des "Simulink Support Package for Arduino Hardware" nicht möglich mehr als 32 Byte in einem Zyklus über den I2C Bus auszulesen. Mehr Informationen zu dieser Problematik lassen sich unter dem Abschnitt Lessons Learned wiederfinden.

Nach dem Auslesen der Messdaten folgt die Berechnung der Temperaturen in der zugehörigen 4x4 Pixelmatrix des Sensor. Dieser Vorgang wurde genau wie der Detektionsalgorithmus in dem Simulinkmodell mithilfe eines "MATLAB Function" Blocks implementiert. In diesem Block befindet sich der in Abbildung 12 dargestellte Programmcode.


Abbildung 12: Programmcode getTemperature Funktion


Eingangswerte der Funktion sind die Bytes aus dem Datenpaket, die der Sensor über den I2C Bus an den Mikrocontroller sendet. Diese Bytes sind in der Variable data hinterlegt. Anschließend werden zunächst einmalig die verwendeten Variablen als persistent Datentyp deklariert und entsprechende Werte zugewiesen. Das 16. Temperaturpixel kann aufgrund der bereits beschriebenen Problematik nicht ausgesen und somit berechnet werden. Dementsprechend wird ihm dauerhaft der Wert NaN zugewiesen.

Als nächstes werden die anderen 15 Temperaturen aus den Bytes berechnet und an ihrer zugehörigen Stelle in der 4x4 Matrix hinterlegt. Abschließend wird die vollständige Matrix an die Variable temperature zurückgeben. Eine Rückgabevariable kann nicht als persistent Variable verwendet werden. Weitergehend folgt im Programmablauf der Detektionsalgorithmus. Der Programmcode dieser MATLAB Function ist in Abbildung 13 einsehbar.



Abbildung 13: Programmcode DetectionAlgorithm Funktion


Auch in dieser Funktion werden zu Anfang alle verwendeten Variablen als persistent Datentyp einmalig deklariert und falls vorhanden ein fester oder initialer Wert zugewiesen. Insgesamt beruht der Detektionsalgorithmus auf der Differenz zwischen den einzelnen Temperaturen der Pixelmatrix und einer berechneten Umgebungstemperatur. Für die Berechnung der Umgebungstemperatur werden zunächst alle gemessenen Temperaturen in einem Array nach Größe aufsteigend sortiert. Hiernach wird ein Tiefpassfilter 1. Ordnung verwendet.



stellt in dieser Gleichung den Mittelwert aus den vier kleinsten Temperaturwerten der Pixelmatrix dar. Diese Berechnung ergibt sich aus der Überlegung, dass das Smart Light System für die Wahrnehmung von Wärmesignaturen in einem Abstand von
ca. 2-3 m verwendet wird. Somit spannt sich die Pixelmatrix über einen Bereich von ungefähr 2.5 m^2 bis 5.7 m^2 auf (siehe Datenblatt). Da dieser Bereich im Vergleich mit der projizierten Fläche eines Menschen deutlich geringer ist, kann davon ausgegangen werden, dass mehrere Pixel repräsentative Messwerte für die Umgebungstemperatur besitzen.

Die Wirkung des verwendeten Tiefpassfilters lässt sich in Abbildung 14 erkennen.


Abbildung 14: Messung der Raumtemperatur


Es lässt sich deutlich erkennen, dass die Raumtemperatur über einen Zeitraum von 10 Sekunden konstant knapp unterhalb von 21 °C liegt. Dementsprechend konnte die gewünschte Wirkung mit der getroffenen Einstellung für = 0.6 erzielt werden. Die zeitliche Verzögerung des Messsignals (delay) durch das Tiefpassfilter kann vernachlässigt werden, weil es sich bei der Raumtemperatur um ein Messsignal mit sehr langsamen Änderungen handelt.

Im nächsten Schritt wird über jedes Temperaturpixel gegangen und die Differenz zur Umgebungstemperatur gebildet. Ist diese größer als die Variable dT_max, welche die maximale Abweichung darstellt, so wird in der Detektionsmatrix an der zugehörigen Stelle eine 1 hinterlegt. Diese 1 steht für ein gefundenes Objekt in dem jeweiligen Temperaturpixel. Anschließend wird die Anzahl an gefundenen Objekten gezählt und die Temperaturen der gefundenen Objekte abgespeichert. Wenn mindestens ein Objekt gefunden wird, schaltet das System die rote LED an, andernfalls die blaue. Abschließend wird die aktuelle Umgebungstemperatur in der Variable Temp_old für den nächsten Durchlauf hinterlegt, damit diese im Tiefpassfilter verwendet werden kann.

Komponententest

Der Sensor wurde getestet werden indem dieser an den Funduino Uno angeschlossen und im Anschluss ein Testprogramm über die Arduino IDE hochgeladen wurde. Es wurden realistische Temperaturen im Serial Monitor ausgegeben und somit die Funktionalität des Sensor bestätigt.

Weitergehend wurden die Vorwiderstände für die LEDs (R1 und R2) mit dem Multimeter UT61E des Herstellers UNI-T gemessen und die folgenden Ergebnisse erzielt.

Fehler beim Parsen (Konvertierungsfehler. Der Server („cli“) hat berichtet: „[INVALID]“): {\displaystyle R1 = 324,5 \Omega \pm 0,5 %}

Fehler beim Parsen (Konvertierungsfehler. Der Server („cli“) hat berichtet: „[INVALID]“): {\displaystyle R2 = 320,7 \Omega \pm 0,5 %}

Somit liegen die gemessenen Widerstände innerhalb der vorgegebenen Toleranzen. Anschließend wurde die Funktionalität der LEDs überprüft, indem diese mitsamt ihrer Vorwiderstände an den Funduino Uno angeschlossen und mithilfe eines Testprogramms zum Blinken gebracht wurden. Beide LEDs haben im programmierten Rhythmus geblinkt und der Test war somit erfolgreich. Aufgrund der bisherigen Komponententests lässt sich ebenfalls die einwandfreie Funktionalität des Mikrocontrollers festhalten, weil in zwei Tests ein Testprogramm in den Flash-Speicher geladen wurde. Außerdem wurde der autarke Betrieb des Mikrocontrollers über das Netzteil getestet. Dieser Test war ebenfalls erfolgreich und der Uno hat einwandfrei funktioniert.

Die Komponententests zur Software wurden so durchgeführt, dass hinter den jeweiligen Funktionsblöcken im Simulinkmodell ein "To Workspace" Block geschaltet wurde. Somit wurden die Variablen mit ihrem zeitlichen Verlauf an den Workspace zurückgegeben, in welchem sie dann überprüft wurden.

Die Ergebnisse der getTemperature Funktion sind exemplarisch in Abbildung 15 dargestellt.


Abbildung 15: Ergebnisse getTemperature Funktion


Für die Ergebnisse der DetectionAlgorithm Funktion wurden die Ausgabe der Variablen Detektionsmatrix und zSaved herangezogen. Beide lassen sich für dieselbe Messung wie in Abbildung 15 in der folgenden Abbildung 16 erkennen.



Abbildung 16: Ergebnisse DetectionAlgorithm Funktion


An dieser Stelle lässt sich die Funktionalität des unteren Teils des Simulinkmodells aus Abbildung 8 bestätigen. Weitergehend wurde der obere Teil, also das Senden des Startkommandos, mit einem "Display" Block in Simulink geprüft. An dieser Stelle wurde eine 0 ausgegeben, was ein erfolgreiches Schreiben der Daten über den I2C Bus bedeutet. Die zugehörige Ansteuerung der LEDs wurde visuell überprüft und war ebenfalls erfolgreich.

Der Grundkörper des Gehäuses konnte lediglich auf Funktionalität getestet werden indem geprüft wurde, ob die Komponenten (Funduino Uno, Kabel, Sensor) in dem Grundkörper, wie während der Konstruktion vorgesehen, verbaut werden konnten. Dies war erfolgreich und es konnten alle Bauteile entsprechend der Aussparungen und vorgesehenen Platzierung im Gehäuse positioniert werden.

Der Deckel des Gehäuses konnte durch Aufsetzen auf dem Grundkörper mit den eingebauten LEDs getestet werden. Dieser Test war ebenfalls erfolgreich.

Ergebnis

Das Projekt konnte erfolgreich durchgeführt werden und wir konnten alle gesetzten Anforderungen erreichen. Das Endprodukt lies sich gut im Raum positionieren und hat zuverlässig Lebewesen erkannt. Zudem werden die LEDs entsprechend der Detektion ein- und ausgeschaltet. Eine Überprüfung der einzelnen Anforderungen aus Tabelle 1 lässt sich in Tabelle 4 einsehen.

Anforderungs-ID Testinhalt Testergebnis Anmerkungen
Tabelle 4: Test der Anforderungen
001 Positionierung einer Person im Messbereich erfolgreich keine
002 Verlassen des Messbereichs und Überprüfung des Anschaltens der blauen LED erfolgreich keine
003 Positionierung einer Person im Messbereich ohne Bewegung erfolgreich keine
004 Verlassen des Messbereichs und Überprüfung des Ausschaltens der roten LED erfolgreich keine
005 Sichtprüfung des Prototyps erfolgreich Die LEDs sind im Deckel des Gehäuse integriert worden
006 Sichtprüfung des Prototyps erfolgreich keine
007 Überprüfung der Verschaltung des Prototyps erfolgreich keine
008 Sichtprüfung des Prototyps erfolgreich keine
009 Überprüfung der Verschaltung des Prototyps und Überprüfung der Software auf die steuernde Funktionsweise des Funduino Uno erfolgreich keine
010 Sichtprüfung des Gehäuses erfolgreich keine


Probleme bei der Erkennung entstehen nur wenn sich weitere unbewegliche Wärmequellen, z.B. elektrische Geräte, im Messbereich befinden. Dieses Problem wird nochmal ausführlich im Abschnitt Lessons Learned erläutert.

Zusammenfassung

Die Projektumsetzung war erfolgreich und alle Anforderungen aus Tabelle 1 konnten mit dem Prototyp erfüllt werden.

Lessons Learned

Durch das Verwenden von MATLAB Simulink waren uns leider klare Grenzen in der Umsetzung des Projektes gesetzt. Dies bezieht sich vor allem auf die Schwierigkeiten C++ Bibliotheken in MATLAB Simulink zu verwenden sowie die Schnittstellen des Funduino Uno vielseitig zu nutzen. Beispielsweise ist es nicht möglich analoge Schnittstellen als digitale Schnittstellen zu deklarieren, wie es in der Arduino IDE möglich ist. Somit können in Simulink die Schnittstellen nur analog verwendet werden. Dementsprechend konnten keine 16 LEDs zum Aufbau einer LED Matrix verwendet werden, da nicht genügend Kontakte zum Ansteuern vorhanden waren. Außerdem war es aufgrund der anspruchsvollen Einbindung der Bibliotheken nicht möglich eine LED Matrix aus RGB LED Stripes oder ähnlichem aufzubauen. Somit musste eine Datenreduktion bei der Ausgabe in Kauf genommen werden.

Des Weiteren hat sich wie bereits erwähnt ergeben, dass der verwendete Sensor seine Daten in einem 35 Byte langen Datenpaket über den I2C Bus sendet. Das Auslesen des I2C Bus Systems ist in MATLAB Simulink auf 32 Byte begrenzt, weshalb die zwei Bytes für das letzte Temperaturpixel der 4x4 Matrix verloren gehen. Dies ist ebenfalls in herkömmlichen C++ Bibliotheken auf 32 Bytes begrenzt, wie beispielsweise der C++ Bibliothek Wire.h. Mithilfe der WireExt.h C++ Bibliothek wäre ein vollständiges Auslesen des Sensors in der Arduino IDE möglich gewesen. Für MATLAB Simulink konnte keine Lösung gefunden werden, weshalb das 16. Temperaturpixel dauerhaft als NaN definiert wird.

Weitergehend hat sich in der Anwendung des Prototyps ergeben, dass Menschen keine so signifikante Wärmesignatur besitzen wie ursprünglich erwartet. Die Temperatur an der Oberfläche weicht nur minimal von der Umgebungstemperatur ab, wenn die Person viel Kleidung trägt. Sind jedoch viele freie Hautflächen im Messbereich des Sensors vorhanden, so lassen sich diese eindeutiger erkennen. Die Temperatur auf der Hautoberfläche beträgt ungefähr 28 °C. Dementsprechend ist das gewählte mit 4 °C vergleichsweise klein.

Aufgrund dieses kleinen kann es passieren, dass auch statische Wärmesignaturen von z.B. Elektrogeräten, erkannt werden. An dieser Stelle könnte ein herkömmlicher Präsenzsensor auf Basis von elektromagnetischen Wellen oder Ultraschall verwendet werden, um das System zu ergänzen. Mithilfe einer Sensordatenfusion könnten im Algorithmus statische Signaturen, die über einen längeren Messzeitraum keine Positionsänderung aufweisen, gefiltert werden.

Als letztes lässt sich noch eine Einschränkung des Detektionsalgorithmus festhalten. Da der Algorithmus auf der Bildung der Umgebungstemperatur basiert, darf sich kein Lebewesen unmittelbar vor der Linse befinden (ca. 20 - 30 cm). Andernfalls würden nahezu alle Temperaturpixel dieses Lebewesen messen und somit die Berechnung der Umgebungstemperatur nicht mehr funktionieren. Deshalb würde nach einem gewissen Zeitraum keine Signatur mehr erkannt werden.

Projektunterlagen

Die essentiellen Projektunterlagen lassen sich im SVN einsehen sowie hier als ZIP-Archiv downloaden.

Projektplan

Der Projektplan lässt sich in Abbildung 17 einsehen.
Abbildung 17: Projektplan Smart Light

Projektdurchführung

Zu Beginn haben wir den Sensor ausgewählt und diesen bestellt. Da dieser einen speziellen Anschluss besitzt mussten wir daraufhin auch noch das entsprechende Kabel bestellen. Nach Abschluss dieses Vorgangs konnten wir uns der Programmierung widmen. Nach einigen Problemen, welche im Abschnitt Lessons Learned beschrieben sind, konnten wir die Programmierung erfolgreich beenden. Parallel dazu haben wir mit der Konstruktion des Gehäuses begonnen. Ausschlaggebend für die Konstruktion war dabei der Funduino Uno aufgrund seiner Größe. Nach dem erfolgten 3D Druck konnten alle Komponenten in das Gehäuse eingesetzt und das Smart Light System in Betrieb genommen werden.

YouTube Video

Video 1: Smart Light Videoclip


Weblinks

Literatur


→ zurück zur Übersicht: WS 21/22: Angewandte Elektrotechnik (BSE)