Smart Light: Unterschied zwischen den Versionen
Markierung: Manuelle Zurücksetzung |
|||
(123 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 | 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 Smart Light.png| left|]] | [[Datei:Skizze Smart Light.png| left|]] | ||
Zeile 17: | Zeile 19: | ||
''Abbildung 1: Skizze Smart Light'' | ''Abbildung 1: Skizze Smart Light'' | ||
Der Sensor | 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" | ||
Zeile 30: | Zeile 33: | ||
|- | |- | ||
| 002 | | 002 | ||
| Der Mensch muss sich in einem definierten Bereich befinden, der dem Messbereich des | | 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 | | 003 | ||
Zeile 48: | Zeile 51: | ||
|- | |- | ||
| 008 | | 008 | ||
| Das System muss einen | | Das System muss einen thermischen Präsenzsensor beinhalten. | ||
|- | |- | ||
| 009 | | 009 | ||
Zeile 58: | Zeile 61: | ||
|} | |} | ||
== | == Technischer Systementwurf == | ||
Der | Der technische Systementwurf lässt sich in der folgenden Abbildung erkennen. | ||
[[Datei:Funktionaler Systementwurf Smart Light.png]] | [[Datei:Funktionaler Systementwurf Smart Light.png|left|medi]] | ||
<br clear=all> | <br clear=all> | ||
''Abbildung 2: | ''Abbildung 2: Technischer Systementwurf'' | ||
== Komponentenspezifikation == | |||
Die Komponenten des Systems werden in Tabelle 2 aufgeführt. | |||
{| class="mw-datatable" | {| class="mw-datatable" | ||
! style="font-weight: bold;" | ID | ! style="font-weight: bold;" | ID | ||
! style="font-weight: bold;" | | ! style="font-weight: bold;" | Komponente | ||
! style="font-weight: bold;" | | ! style="font-weight: bold;" | Eingangsparameter | ||
! style="font-weight: bold;" | | ! style="font-weight: bold;" | Ausgangsparameter | ||
! style="font-weight: bold;" | Aufgabe | |||
! style="font-weight: bold;" | Struktur | |||
|+ style = "text-align: left"|''Tabelle 2: Komponentenspezifikation'' | |+ style = "text-align: left"|''Tabelle 2: Komponentenspezifikation'' | ||
|- | |- | ||
| 001 | | 001 | ||
| Sensor | | 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 | | 002 | ||
| Datenverarbeitung | | 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 | | 003 | ||
| | | Visualisierung | ||
| | | Ansteuerungssignale vom Mikrocontroller | ||
| keine | |||
| Gibt den Detektionsstatus für die aktuelle Messung wieder | |||
| Hardwarekomponente | |||
|- | |- | ||
| 004 | | 004 | ||
| Datenverarbeitung | | Datenverarbeitung | ||
| | | Byte Datenpaket mit Temperaturen | ||
| 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 | |||
|- | |||
| 002 | |||
| LED1 | | LED1 | ||
| Rote LED | | Rote LED | ||
| LED mit ungefähr 633 nm Wellenlänge | | LED mit ungefähr 633 nm Wellenlänge | ||
|- | |- | ||
| | | 003 | ||
| LED2 | | LED2 | ||
| Blaue LED | | Blaue LED | ||
| LED mit ungefähr 430 nm Wellenlänge | | LED mit ungefähr 430 nm Wellenlänge | ||
|- | |- | ||
| | | 004 | ||
| Widerstand 1 | | Widerstand 1 | ||
| R1 | | R1 | ||
| 330 <math>\Omega</math> Widerstand mit einer Toleranz von <math>\pm</math> 5 % | | 330 <math>\Omega</math> Widerstand mit einer Toleranz von <math>\pm</math> 5 % | ||
|- | |- | ||
| | | 005 | ||
| Widerstand 2 | | Widerstand 2 | ||
| R2 | | R2 | ||
| 330 <math>\Omega</math> Widerstand mit einer Toleranz von <math>\pm</math> 5 % | | 330 <math>\Omega</math> Widerstand mit einer Toleranz von <math>\pm</math> 5 % | ||
|- | |- | ||
| | | 006 | ||
| Gehäuse | | Gehäuse | ||
| Grundkörper | | Grundkörper | ||
| Abmaße(außen): 95 mm x 70 mm x 60 mm (LxBxH) | | Abmaße(außen): 95 mm x 70 mm x 60 mm (LxBxH) | ||
|- | |- | ||
| | | 007 | ||
| Gehäuse | | Gehäuse | ||
| Deckel | | Deckel | ||
| Abmaße(außen): 95 mm x 70 mm x 60 mm (LxBxH) | | Abmaße(außen): 95 mm x 70 mm x 60 mm (LxBxH) | ||
|- | |- | ||
| | | 008 | ||
| Versorgungsspannung | | Versorgungsspannung | ||
| Netzteil | | Netzteil | ||
Zeile 131: | Zeile 169: | ||
|} | |} | ||
====Verdrahtungsplan==== | ====Verdrahtungsplan==== | ||
Zeile 147: | Zeile 180: | ||
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. | 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==== | ====Schaltplan==== | ||
Zeile 158: | Zeile 192: | ||
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. | 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=== | ===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 | 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]] | [[Datei:Screenshot Simulinkmodell Smartlight.PNG| 1600px]] | ||
<br clear=all> | <br clear=all> | ||
''Abbildung | ''Abbildung 10: Simulinkmodell des Smart Light Projektes'' | ||
Um einen ersten Überblick über den Programmablauf zu erhalten, lässt sich in Abbildung | 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]] | [[Datei:Programmablaufplan SmartLight.png| 300px]] | ||
<br clear=all> | <br clear=all> | ||
''Abbildung | ''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 auszulesen. Mehr Informationen zu dieser Problematik lassen sich unter dem Abschnitt Lessons Learned wiederfinden. | 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 | 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]] | [[Datei:Code Funktion getTemperature.PNG| 800px]] | ||
<br clear=all> | <br clear=all> | ||
''Abbildung | ''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 | 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 | 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:Code Funktion DetectionAlgorithm 1 von 2.PNG| 1200px]] | [[Datei:Code Funktion DetectionAlgorithm 1 von 2.PNG| 1200px]] | ||
Zeile 192: | Zeile 276: | ||
[[Datei:Code Funktion DetectionAlgorithm 2 von 2.PNG| 1200px]] | [[Datei:Code Funktion DetectionAlgorithm 2 von 2.PNG| 1200px]] | ||
<br clear=all> | <br clear=all> | ||
''Abbildung | ''Abbildung 13: Programmcode DetectionAlgorithm Funktion'' | ||
Zeile 204: | Zeile 288: | ||
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. | 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. | ||
Die Wirkung des verwendeten Tiefpassfilters lässt sich in Abbildung | Die Wirkung des verwendeten Tiefpassfilters lässt sich in Abbildung 14 erkennen. | ||
[[Datei:Messung Raumtemperatur Tiefpassfilter.png| left| 1000 px]] | [[Datei:Messung Raumtemperatur Tiefpassfilter.png| left| 1000 px]] | ||
<br clear=all> | <br clear=all> | ||
''Abbildung | ''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 | 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. | ||
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 | 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 | 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. | |||
2. | [[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'' | |||
Die | |||
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 | 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. | ||
Probleme bei der Erkennung entstehen nur wenn sich | {| 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 | 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 === | ||
[[Datei:Projektplan Smart Light.png]] | Der Projektplan lässt sich in Abbildung 17 einsehen. | ||
[[Datei:Projektplan Smart Light.png|1400px]] | |||
<br clear=all> | <br clear=all> | ||
''Abbildung | ''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] | * [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)
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 |
---|---|
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.
Abbildung 2: Technischer Systementwurf
Komponentenspezifikation
Die Komponenten des Systems werden in Tabelle 2 aufgeführt.
ID | Komponente | Eingangsparameter | Ausgangsparameter | Aufgabe | Struktur |
---|---|---|---|---|---|
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 |
---|---|---|---|
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 |
---|---|---|---|
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
Weblinks
- Präsenzsensor D6T-44L-06 bei reichelt.de
- D6T Sensoren des Herstellers Omron
- D6T-44L-06 in der Arduino IDE mit der WireExt.h Bibilothek
Literatur
→ zurück zur Übersicht: WS 21/22: Angewandte Elektrotechnik (BSE)