Escape Game: Rätselbox: Unterschied zwischen den Versionen

← Zum vorherigen Versionsunterschied Zum nächsten Versionsunterschied →

Version vom 12. Januar 2026, 23:18 Uhr

→ zurück zur Übersicht: WS 25/26: Escape Game

Autoren:	xiangyao Liu , yunkai Lin
Betreuer:	Marc Ebmeyer

Einleitung

Dieses Projekt basiert auf der Handlung der Kapitel 4 bis 7 des vierten Bandes des Mangas „Detektiv Conan“. In der Geschichte platziert der Täter eine Bombe in einem Shinkansen-Hochgeschwindigkeitszug. Fällt die Geschwindigkeit des Zuges unter 80 km/h, explodiert die Bombe. Conan muss den Fall noch im Zug lösen, um den Täter zu identifizieren und die Krise abzuwenden. Sein Kombinationsprozess stützt sich dabei maßgeblich auf die Schlüsselzahl 80, aus der er weitere Informationen ableitet.

In unserem Projekt erhalten die Spieler durch das erfolgreiche Absolvieren des Labyrinths im ersten Level ebenfalls eine Schlüsselzahl. Anhand verschiedener Hinweise müssen die Spieler von dieser Zahl ausgehend auf die entsprechenden Lösungen schließen. Jede dieser Lösungen stellt ein notwendiges Passwort für das finale Level des Spiels dar. Die Spieler müssen die Passwörter mit den Hinweisen kombinieren, um das letzte Rätsel zu lösen und das Spiel erfolgreich abzuschließen.

Der Schwierigkeitsgrad ist mittel. Das Spiel erfordert grundlegendes logisches Denken und eine gewisse Geschicklichkeit beim Bedienen der Sensoren, ist aber dank visueller Rückmeldungen (LEDs und Display) sowohl für Kinder als auch Erwachsene geeignet. Die Aufgaben sind so gestaltet, dass sie ohne Fachwissen, aber mit Konzentration und Beobachtung lösbar sind.

Der Lerneffekt besteht in der Verbindung von logischem Denken und physikalischer Wahrnehmung. Die Spieler verstehen im Spiel, wie Sensoren funktionieren, wie Zahlenwerte in reale Handlungen umgesetzt werden können und trainieren dabei ihre Problemlösungsfähigkeit sowie ihre Feinmotorik.

Zur Realisierung des Projekts wird die Entwicklungsumgebung MATLAB/Simulink in Verbindung mit dem Arduino Mega 2560 verwendet. Dabei werden alle Systemkomponenten – Sensoren, Aktoren, Steuerlogik und Anzeigeelemente – in Simulink als funktionale Blöcke modelliert. Das Verhalten des Systems kann zunächst im Simulink-Modell simuliert und anschließend über die automatische Codegenerierung direkt auf die Arduino-Hardware übertragen werden . Dadurch wird ein durchgängiger Model-Based Design-Ansatz umgesetzt, wie er im Systems Engineering zentral ist.

Anforderungen

Tabelle 1: Anforderungen an das Escape Game
ID	Inhalt	Prio	Ersteller	Datum	Geprüft von	Datum	Umsetzung der Anforderung in %; Prüfer
1	Das Spiel muss in 5 Minuten lösbar sein.	Mittel	xiangyao Liu，yunkai Lin	02.10.2025	Xiangyao Liu, Yunkai Lin	12.12.2025	100%
2	Das Labyrinth-Spiel startet beim Drücken von Taste 1.	Hoch	xiangyao Liu	02.10.2025	Xiangyao Liu, Yunkai Lin	30.10.2025	100%
3	Hinweise und Rückmeldungen für die Spieler*innen werden über das OLED-Display angezeigt.	Mittel	xiangyao Liu	02.10.2025	Xiangyao Liu, Yunkai Lin	30.10.2025	100%
4	Der Wägezellen-Sensor kann das aufgelegte Gewicht zuverlässig messen.	Hoch	xiangyao Liu，yunkai Lin	02.10.2025	Xiangyao Liu	12.11.2025	80%
5	Der Ultraschallsensor kann den Abstand der Hand zum Sensor zuverlässig messen.	Mittel	xiangyao Liu	02.10.2025	Xiangyao Liu, Yunkai Lin	12.11.2025	100%
6	Der Drehwinkelsensor kann die horizontale Rotation des Kastens zuverlässig erfassen.	Hoch	xiangyao Liu	02.10.2025	Xiangyao Liu, Yunkai Lin	15.11.2025	100%
7	Die Überprüfung der Bedingungen (Abstand, Winkel, Gewicht) beginnt beim Drücken von Taste 2.	Hoch	xiangyao Liu	01.12.2025	Xiangyao Liu, Yunkai Lin	12.12.2025	100%
8	Wenn eine Aufgabe (Gewicht, Abstand, Winkel) korrekt ist, leuchtet die entsprechende LED grün, andernfalls rot.	Hoch	xiangyao Liu, Yunkai Lin	02.10.2025	Xiangyao Liu, Yunkai Lin	30.11.2025	100%
9	Beim Bestehen des Labyrinths leuchtet die entsprechende LED grün und das OLED zeigt „Erfolg“ an, andernfalls wird die LED rot und das OLED zeigt „Fehlgeschlagen“ an.	Mittel	xiangyao Liu	02.10.2025	Xiangyao Liu, Yunkai Lin	30.10.2025	100%
10	Wenn alle drei Aufgaben korrekt sind erfüllt bleiben, leuchten alle LEDs grün.	Mittel	xiangyao Liu	02.10.2025	Xiangyao Liu, Yunkai Lin	30.11.2025	100%
11	Das Endergebnis (Zahlencode) wird auf dem OLED-Display angezeigt.	Mittel	xiangyao Liu	02.10.2025	Xiangyao Liu, Yunkai Lin	12.12.2025	100%
12	Der Drehencoder kann die Spielfigur im Labyrinth korrekt steuern.	Niedrig	xiangyao Liu	02.10.2025	Xiangyao Liu, Yunkai Lin	30.10.2025	100%
13	Das System muss auch ohne Internet funktionieren.	Niedrig	xiangyao Liu，yunkai Lin	02.10.2025	Xiangyao Liu, Yunkai Lin	12.12.2025	100%
14	Das System muss in eine tragbare Box integriert werden.	Mittel	yunkai Lin	02.10.2025	Xiangyao Liu, Yunkai Lin	11.01.2026	100%
15	Das Spiel muss benutzerfreundlich und sowohl für Kinder als auch Erwachsene geeignet sein.	Hoch	xiangyao Liu，yunkai Lin	02.10.2025	Xiangyao Liu, Yunkai Lin	12.12.2025	100%
16	Während des Spiels dürfen keine externen Hilfsmittel (z. B. Waage, Lineal) verwendet werden.	Hoch	xiangyao Liu，yunkai Lin	02.10.2025	Xiangyao Liu, Yunkai Lin	12.12.2025	100%
17	Das PCB-Design und dessen Funktionalität wurden erfolgreich verifiziert.	Hoch	yunkai Lin	02.10.2025	Xiangyao Liu, Yunkai Lin	12.12.2025	100%
18	Die 3D-Modellierungseinheit erfüllt alle Spezifikationen der elektronischen Komponenten sowie die funktionalen Anforderungen.	Hoch	yunkai Lin	02.10.2025	Xiangyao Liu, Yunkai Lin	20.12.2025	100%

Funktionaler Systementwurf

Das Spiel gliedert sich in zwei Abschnitte.
Im ersten Abschnitt muss der Spieler den OLED-Bildschirm auf der Box finden und das darauf dargestellte Labyrinthspiel mithilfe eines Drehgebers lösen. Nach erfolgreichem Abschluss des Labyrinths erhält der Spieler die erste Schlüsselzahl.
Anschließend beginnt der zweite Abschnitt. Hier muss der Spieler anhand von Hinweisen verschiedene Berechnungen mit der ersten Schlüsselzahl durchführen, um drei neue Schlüsselzahlen zu ermitteln. Diese drei Zahlen sind jeweils einem der drei folgenden Rätsel zugeordnet. Das erste Rätsel besteht darin, entsprechend der neuen Zahl passende Gewichtsstücke auszuwählen, die von einem Schwerkraftsensor gemessen werden. Beim zweiten Rätsel muss die Box um einen Winkel gedreht werden, der durch die neue Schlüsselzahl vorgegeben ist. Das dritte Rätsel erfordert das Platzieren eines Hindernisses (hierfür kann auch die Hand dienen), dessen Abstand zum Ultraschallsensor der neuen Schlüsselzahl entsprechen muss.

Jede dieser Aufgaben wird automatisch überprüft. Wenn die Messwerte innerhalb des erlaubten Toleranzbereichs liegen, leuchtet die entsprechende LED grün. Nach dem erfolgreichen Bestehen aller Aufgaben wird auf dem OLED-Display „Erfolg“ angezeigt und ein Zahlencode freigegeben.

Technischer Systementwurf

Die technische Systemarchitektur beschreibt ein mikrocontroller-gesteuertes interaktives Spielsystem mit mehrstufiger Eingabeverarbeitung. Die Stromversorgung liefert die erforderliche Energie für alle Komponenten.

Das System gliedert sich in drei funktionale Ebenen: Eingabe, Verarbeitung und Ausgabe. Auf der Eingabeebene erfassen ein Drehgeber und zwei Tasten die Benutzerbefehle zur Spielsteuerung, während Sensoren (Gewichts-, Winkel- und Abstandssensoren) kontinuierlich physikalische Messdaten sammeln.

Der Mikrocontroller fungiert als zentrale Verarbeitungseinheit, die alle Eingangssignale empfängt, die Spiellogik ausführt und die Bedingungsüberprüfung durchführt. Er verarbeitet die Messdaten der Sensoren in Echtzeit und vergleicht sie mit den vorgegebenen Zielwerten.

Die Ausgabeeinheit besteht aus einem OLED-Display zur visuellen Darstellung des Spielverlaufs und der Systemmeldungen sowie einer LED-Anzeige zur Signalisierung des Erfolgszustands. Das Display zeigt während des Spiels das Labyrinth, Statusinformationen und den generierten Code an, während die LED als binäres Signal für Erfolg oder Misserfolg dient.

Durch diese Systemarchitektur wird ein durchgängiger Datenfluss von der Eingabeerfassung über die intelligente Signalverarbeitung bis zur benutzerfreundlichen Ergebnisdarstellung gewährleistet. Die modulare Struktur ermöglicht eine flexible Anpassung und Erweiterung einzelner Komponenten.

Materialliste

Tabelle 2: Materialliste
Nr.	Anz.	Komponente	Beschreibung	Link
1	1	Arduino Mega 2560	Microcontroller	ARD MEGA2560 R3 Arduino kompatibles Mega 2560 R3 Board
2	1	SSD1306 I²C 128x64	Display	SSD1306
3	1	SEN-PRESSURE02	Drucksensor	ARD SEN PRESSURE Arduino - Drucksensor, 0 g bis 2 kg
4	1	KY-040	Drehgeber	KY-040
5	1	HC-SR04	Ultraschall-Modul	HC-SR04
6	2	Taster	Taster	Taster
7	1	MPU6050（I²C）	Beschleunigungs- und Gyroskop-Sensor	MPU6050
8	4	LED	LED	Iduino SE010 RGB LED-Modul

Komponentenspezifikation

Stückliste (BOM)

In der nachfolgenden Tabelle ist die Bill of Materials für das Projekt zu finden.

Tabelle 3: BOM
ID	Anzahl	Kosten pro Stück €	Summe	Bezeichnung / Komponente	technische Bezeichnung	Beschreibung	Datenblatt	Abbildung
1	1x	19,30€	19,30€	Arduino Mega	ARD MEGA2560 R3 Arduino kompatibles Mega 2560 R3 Board	Der Mircocontroller mit dem ATmega2560 verfügt über 54 digitale I/O - Schnittstellen. Des Weiteren sind 16 analoge Eingänge die die Verarbeitung analoger Signale vorhanden.	Datenblatt Arduino Mega	Abb. 4: Arduino Mega 2560 R3 Board
2	1x	6,99€	6,99€	SSD1306 I²C 128x64	SSD1306	Der SSD1306-Controller ermöglicht die Ansteuerung von OLED-Displays mit einer Auflösung von 128x64 Pixeln über I2C- oder SPI-Schnittstellen.	Datenblatt SSD1306	Abb. 5: OLED-Display
3	1x	4,03€	4,03€	Drucksensor	ARD SEN PRESSURE Arduino - Drucksensor, 0 g bis 2 kg	Der Sensor ist für einen Messbereich von 0 bis 2 kg ausgelegt und liefert ein analoges Signal.	Datenblatt Drucksensor	Abb. 6: Drucksensor.
4	1x	2,2€	2,2€	KY-040 Drehgeber	KY-040	Der inkrementale Drehgeber ermöglicht eine endlose 360°-Rotation und verfügt über einen integrierten Drucktaster.	Datenblatt KY-040	Abb. 7: KY-040
5	1x	3,80€	3,80€	Ultraschall-Modul	HC-SR04	Der Ultraschallsensor misst berührungslos Entfernungen von 2 cm bis 400 cm mittels Schallwellen.	Datenblatt Ultraschall	Abb. 8: HC-SR04
6	2x	0,33€	0,66€	Taster	Taster	Dieses Bauteil dient als taktiles Eingabeelement auf Leiterplatten und kehrt nach dem Loslassen automatisch in die Ausgangsposition zurück.	Datenblatt Taster	Abb. 9: taster
7	1x	5,50€	5,50€	MPU6050	MPU6050	Der MPU6050 vereint ein 3-Achsen-Gyroskop und einen 3-Achsen-Beschleunigungssensor zu einer 6-Achsen-Motion-Tracking-Einheit.	Datenblatt MPU6050	Abb. 10: MPU6050
8	4x	2,49€	9,96€	LED	Iduino SE010 RGB LED-Modul	Das RGB-LED-Modul ermöglicht durch die separate Ansteuerung der Kanäle Rot, Grün und Blau die Darstellung beliebiger Mischfarben.	Datenblatt LED	Abb. 11: LED

Umsetzung (HW/SW)

Technische Daten der Sensoren

Hardware-Modul: Ultraschallsensor HC-SR04

Der HC-SR04 ist ein weit verbreitetes Modul zur berührungslosen Entfernungsmessung. Er nutzt das Sonar-Prinzip , um den Abstand zu Objekten zu erkennen.

Funktionsprinzip：

Das Modul sendet nach Erhalt eines Triggersignals automatisch Ultraschallwellen aus und misst die Zeitspanne bis zum Eintreffen des vom Objekt reflektierten Echos, um daraus unter Berücksichtigung der Schallgeschwindigkeit die Entfernung zum Objekt zu berechnen.

Berechnungsformel

Die Distanz wird berechnet, indem die gemessene Zeitdauer des Echos mit der Schallgeschwindigkeit multipliziert und durch 2 geteilt wird .

$Distanz (cm) = \frac{Echo-Dauer (μ s) \times 0, 0343}{2}$

In diesem Projekt dient das Modul als Kernkomponente für das "Level 2: Sensor-Herausforderung" (Sensor Challenge). Der Spieler muss seine Hand in einer bestimmten Höhe (9 cm - 11 cm) über den Sensor halten, um einen Teil des Rätsels zu lösen.

Tabelle 4: Technische Daten der HC-SR04 Sensoren
	HC-SR04
Messbereich	3 - 400 cm
Versorgungsspannung	5 V
Versorgungsstrom	15 mA
Arbeitsfrequenz	40 kHz
Messwinkel	15 Grad
Genauigkeit	ca. 3mm

Die Verbindung zwischen dem Ultraschallsensor HC-SR04 und dem Arduino Mega 2560 erfolgt über vier Pins. Die genaue Belegung in diesem Projekt ist wie folgt:

Tabelle 5: Hardware-Anschluss: HC-SR04
HC-SR04 Pin	Arduino Mega Pin	Beschreibung
VCC	5V	Stromversorgung
GND	GND	Ground
Trig	D7	Trigger-Signal (Ausgang vom Arduino)
Echo	D6	Echo-Signal (Eingang zum Arduino)

Hardware-Modul: Ultraschallsensor KY-040

Der KY-040 ist ein inkrementaler Drehgeber, der Drehbewegungen in elektrische Signale umwandelt. In diesem Projekt fungiert der KY-040 als Hauptsteuergerät für das Labyrinth-Spiel (Level 1).

Drehen: Steuert die Bewegung des Spielers (hoch/runter oder links/rechts).

Drücken: Der integrierte Taster wechselt die Bewegungsachse (horizontal/vertikal).

Funktionsprinzip

Der KY-040 Inkrementalgeber wandelt mechanische Drehbewegungen in elektrische Impulse um. Das Kernprinzip beruht auf der Auswertung der Phasenverschiebung zwischen zwei Signalen, um die Drehrichtung zu bestimmen.

Interner Aufbau und Signalerzeugung

Wie in der Abbildung12 zu sehen ist, befindet sich im Inneren des Encoders eine Scheibe mit gleichmäßig verteilten Kontaktstellen, die mit dem gemeinsamen Pin C (Ground) verbunden sind.

Erzeugung der Rechtecksignale: Wenn der Knopf gedreht wird, rotiert diese Scheibe. Die Ausgänge A (CLK) und B (DT) berühren abwechselnd die Kontaktflächen der Scheibe.

Das Ergebnis: Durch diesen ständigen Wechsel zwischen Kontakt (Low) und keinem Kontakt (High) entstehen auf beiden Leitungen digitale Rechtecksignale.

Richtungserkennung

Um zwischen Rechts- und Linksdrehung zu unterscheiden, sind die Abnehmer für Signal A und Signal B phasenversetzt angeordnet. Das bedeutet, die Signale ändern sich nicht gleichzeitig, sondern nacheinander (um 90° versetzt). Der Mikrocontroller erkennt die Richtung, indem er prüft, welches Signal sich zuerst ändert.

Laut dem Abbildung13 gilt folgende Logik:

Im Uhrzeigersinn

Bei einer Rechtsdrehung eilt das Signal A dem Signal B voraus.

Signalverlauf: Der Zustand von Ausgang A ändert sich zuerst. Wenn Signal A seine Flanke wechselt (z. B. von High auf Low), hat Signal B seinen Zustand noch nicht geändert.

Erkennung: Der Mikrocontroller registriert eine Änderung an A. Da B zu diesem Zeitpunkt noch unverändert (statisch) ist, wird dies als Rechtsdrehung interpretiert.

Gegen den Uhrzeigersinn

Bei einer Linksdrehung kehrt sich die Reihenfolge um. Signal B eilt nun voraus.

Signalverlauf: Hier ändert sich der Zustand von Ausgang B zuerst.

Erkennung: Wenn der Mikrocontroller nun eine Änderung an A registriert, stellt er fest, dass B seinen Zustand bereits geändert hat . Dies wird als Linksdrehung interpretiert.

Tabelle 6: Technische Daten der KY-040 Sensoren
	KY-040
Betriebsspannung	5V
Drehwinkel	360°
Ausgang	2-Bit-Grau-Code
Taster	Integrierter Push-Button

Tabelle 7: Hardware-Anschluss: KY-040
KY-040 Pin	Arduino Mega Pin	Beschreibung
VCC	5V	Stromversorgung
GND	GND	Ground
SW	D5	Taster-Signal
DT	D3	Datensignal
CLK	D2	Taktsignal

Hardware-Modul: MPU6050

Der MPU6050 ist ein sogenanntes MEMS-Modul (Micro-Electro-Mechanical System), das einen 3-Achsen-Beschleunigungssensor und ein 3-Achsen-Gyroskop auf einem einzigen Chip vereint. In diesem Projekt wird es speziell zur präzisen Neigungserkennung eingesetzt.

Tabelle 8: Technische Daten der MPU-6050 Sensoren
	MPU-6050
Betriebsspannung	3.3V - 5V
Schnittstelle	I2C (SDA/SCL)
Genutzter Sensor	3 Beschleunigungs– und 3 Lageachsen
ADC-Auflösung	16-Bit
Messbereich	± 2, ± 4, ± 8, ± 16 g ± 250, ± 500, ± 1000, ± 2000°/s

Funktionsprinzip：

Obwohl der MPU6050 auch über ein Gyroskop verfügt, nutzt dieses Projekt ausschließlich den Beschleunigungssensor zur Winkelbestimmung. Dies geschieht aus Gründen der Stabilität:

Problem mit dem Gyroskop: Das Gyroskop misst Winkelgeschwindigkeiten. Um daraus einen Winkel zu berechnen, müssen die Werte integriert werden. Dies führt über die Zeit zu einem sogenannten "Drift" (Weglaufen der Werte), wodurch der Nullpunkt instabil wird.

Lösung durch Beschleunigungssensor: Der Beschleunigungssensor misst die permanente Erdanziehungskraft (1g). Da die Schwerkraft eine konstante, vertikale Referenzgröße ist, liefert diese Methode einen absoluten und stabilen Neigungswinkel ohne Drift.

Das Prinzip basiert auf der Projektion des Schwerkraftvektors auf die drei Achsen (X, Y, Z) des Sensors. Wenn die Platine geneigt wird, "verteilt" sich die Schwerkraft auf die X- oder Y-Achsen.

Implementierungslogik：

Die Ermittlung der Neigung erfolgt im Mikrocontroller in zwei Schritten: Datenerfassung und trigonometrische Berechnung.

Schritt 1: Datenerfassung Der Arduino liest die Rohwerte des Beschleunigungssensors aus den Registern des MPU6050:

Ax: Beschleunigung entlang der X-Achse .

Ay: Beschleunigung entlang der Y-Achse .

Az: Beschleunigung entlang der Z-Achse .

Schritt 2: Winkelberechnung

Um den physikalischen Neigungswinkel in Grad zu erhalten, wird das Verhältnis der Achsenwerte zueinander mithilfe der Arkustangens-Funktion berechnet:

Roll-Winkel (Neigung Links/Rechts): $Roll = \arctan (\frac{A_{y}}{A_{z}}) \cdot \frac{180}{π}$

2. Pitch-Winkel (Neigung Vor/Zurück): $Pitch = \arctan (\frac{A_{x}}{A_{z}}) \cdot \frac{180}{π}$

Das Ergebnis sind stabile Winkelwerte in Grad, die direkt für die Logiksteuerung verwendet werden.

Tabelle 9: Hardware-Anschluss: MPU6050
MPU6050 Pin	Arduino Mega Pin	Beschreibung
VCC	5V	Stromversorgung
GND	GND	Ground
SDA	SDA	Serial Data
SCL	SCL	Serial Clock

Hardware-Modul: OLED-Display (SSD1306)

Das OLED-Display (Organic Light Emitting Diode) ist die zentrale visuelle Schnittstelle dieses Projekts. Im Gegensatz zu herkömmlichen LCDs, die eine Hintergrundbeleuchtung benötigen, leuchten die Pixel bei einem OLED-Display von selbst.

In diesem Projekt dient das Display dazu, dem Spieler Echtzeit-Feedback zu geben. Es zeigt:

Den aktuellen Spielstatus und Erfolgs- oder Fehlermeldungen (z. B. "Winner!" oder "Game Over").

Tabelle 10: Technische Daten der SSD1306 Sensoren
	SSD1306
Betriebsspannung	3.3V - 5V
Schnittstelle	I2C (SDA/SCL)
Auflösung	128 x 64 Pixel
Display-Technologie	OLED
Blickwinkel	> 160°

Funktionsprinzip：

Ein OLED-Display besteht aus organischen dünnen Schichten, die zwischen zwei Leitern platziert sind. Wenn Strom fließt, emittieren diese Schichten Licht.

Speicherabbild (GDDRAM): Der SSD1306-Controller verfügt über einen internen Grafikspeicher (Graphic Display Data RAM). Der Mikrocontroller sendet Bilddaten über den I2C-Bus in diesen Speicher. Jeder Bit im Speicher entspricht einem Pixel auf dem Bildschirm (1 = Leuchten, 0 = Aus).

Vorteil gegenüber LCD: Da schwarze Pixel einfach "ausgeschaltet" sind , erreicht das Display einen extrem hohen Kontrast und verbraucht bei dunklen Bildern weniger Strom.

Tabelle 11: Hardware-Anschluss: SSD1306
SSD1306 Pin	Arduino Mega Pin	Beschreibung
VCC	5V	Stromversorgung
GND	GND	Ground
SDA	SDA	Serial Data
SCL	SCL	Serial Clock

Hardware-Modul: Drucksensor (SEN-PRESSURE02)

Der SEN-PRESSURE02 ist ein hochsensibler Dünnschicht-Drucksensor, der speziell für Mikrocontroller-Anwendungen entwickelt wurde.

In diesem Projekt dient er als analoges Eingabeelement. Er erkennt nicht nur, ob gedrückt wird, sondern misst die Intensität des Drucks.

Tabelle 12: Technische Daten der SEN-PRESSURE02 Sensoren
	SEN-PRESSURE02
Betriebsspannung	3.3V - 5V
Messbereich	0 kg bis 2 kg
Reaktionszeit	< 1 ms
Lebensdauer	> 1.000.000 Messungen
Funktionsweise	Analoge Widerstandsänderung

Funktionsprinzip：

Der Sensor arbeitet nach dem piezoresistiven Prinzip: Ruhezustand: Ohne Druck ist der elektrische Widerstand des Sensors extrem hoch (> 10 MΩ). Es fließt kaum Strom.Belastung: Sobald Druck auf die kreisförmige Fläche ausgeübt wird, verringert sich der Widerstand drastisch.Integrierter Spannungsteiler:Im Gegensatz zu rohen FSR-Sensoren verfügt dieses Modul bereits über einen integrierten Festwiderstand (auf der Platine als R1 sichtbar). Dieser bildet zusammen mit dem Sensor die notwendige Spannungsteiler-Schaltung.

Formel: $V_{out} = V_{CC} \cdot \frac{R_{Fest}}{R_{Sensor} + R_{Fest}}$

Tabelle 13: Hardware-Anschluss: SEN-PRESSURE02
SEN-PRESSURE02 Pin	Arduino Mega Pin	Beschreibung
VCC	5V	Stromversorgung
GND	GND	Ground
Signal	A0	Analoges Ausgangssignal

PCB Entwicklung

Für mein Projekt wird ein Mikrocontroller benötigt, der Signale von den verwendeten Sensoren liest und die Aktoren steuert. Angesichts der beträchtlichen Anzahl von Sensoren, die in diesem Projekt zum Einsatz kommen, wurde der Arduino Mega2560 als Mikrocontroller ausgewählt, um einen Mangel an Pins zu vermeiden. Die Wahl fiel auf den Arduino Mega 2560, da dieser über umfangreiche Ressourcen zur Informationsverarbeitung sowie eine hohe Rechenleistung für Steuerungsaufgaben in Echtzeit verfügt. Ein entscheidender Vorteil ist zudem die große Anzahl an Header-Pins: Sie deckt den gesamten Bedarf für den Anschluss aller Sensoren und Aktoren ab und gewährleistet somit eine hohe Flexibilität für die weitere Hardware-Entwicklung.

Um den Montageprozess zu rationalisieren und elektrische Anschlussfehler zu vermeiden, wurde eine spezifische Leiterplatte (PCB) als zentrale Schnittstellenplatine entwickelt. Basierend auf dem elektrischen Anschlussschema für Aktoren, Sensoren und Steuerungen wurden die Stiftleisten präzise auf der Platine platziert und die Leiterbahnen entsprechend dem Schaltplan geroutet.

Da für dieses Projekt nicht der gesamte Funktionsumfang des Arduino Mega 2560 benötigt wird, wurde bei der Schnittstellenkonfiguration auf eine vollständige Replikation des Pin-Layouts verzichtet. Stattdessen wurden gezielt nur die benötigten Pins ausgewählt und positioniert. Dieser Ansatz schafft zusätzlichen Platz auf der Leiterplatte, was die Komplexität der Leitungsführung reduziert und das Design optimiert.

Tabelle 14: Anschlussschema der Komponenten
Komponente	Pins von Komponente	Pins von Arduino Mega
KY-040	GND	GND
	VCC	V5
	SW	D5
	DT	D3
	CLK	D2
Drucksensor	Signal	A0
	VCC	V5
	GND	GND
SSD1306	VCC	V5
	GND	GND
	SCL	D21
	SDA	D20
HC-SR04	VCC	V5
	GND	GND
	Triger	D13
	Echo	D12
MPU6500	VCC	V5
	GND	GND
	SCL	D21
	SDA	D20
	INV	D19
LED_1	GND	GND
	Green	D23
	Red	D28
LED_2	GND	GND
	Green	D25
	Red	D26
LED_3	GND	GND
	Green	D27
	Red	D24
LED_4	GND	GND
	Green	D29
	Red	D22
Taster_1	GND	GND
Taster_1	Signal_1	D4
Taster_2	GND	GND
Taster_2	Signal_1	D18

Nach der Festlegung des Anschlussschemas für die Sensoren und Aktoren wurde das Layout der Schnittstellenplatine basierend auf dem Schaltplan erstellt. Die Stromversorgung des Systems erfolgt primär über die USB-Schnittstelle des Arduino Mega, ergänzt durch zwei 3,7-V-18650-Lithium-Ionen-Akkus oder einen externen 5-V-Powerbank-Anschluss. Ein integrierter Spannungsregler stabilisiert dabei Spannungen über 5 V auf ein konstantes Niveau von 5 V.

Der unten dargestellte Schaltplan nutzt On-Page-Connectors, um die Verbindungen zwischen den Komponenten übersichtlich zu gestalten. Durch die Zuweisung identischer Bezeichner wurden logische Verknüpfungen hergestellt, ohne das Diagramm mit vermeidbare unübersichtliche kreuzende Linien. zu überladen. Zur besseren Strukturierung wurde der Gesamtplan in mehrere funktionale Blöcke unterteilt. Dieser modulare Ansatz ermöglicht eine intuitive Darstellung der Logik und vereinfacht die Fehlerdiagnose.

Auf dieser Grundlage wurde der in Multisim erstellte Schaltplan in ein Leiterplattenlayout in Ultiboard überführt. Die zunächst als Ratsnest (Fly-Wires) dargestellten Verbindungen wurden im nächsten Schritt zu Leiterbahnen geroutet, woraus das unten dargestellte Layout resultiert.

Die folgenden Bilder zeigen die Vorder- und Rückseite der entworfenen Leiterplatte in 3D-Ansicht.

Gehäuseentwicklung

Um die mechanischen Funktionen dieses Projekts zu realisieren, wurde ein Gehäuse entworfen, das alle elektronischen Komponenten aufnimmt. Dazu gehören ein Arduino Mega 2560, ein I2C-LCD, ein Ultraschallsensor, ein Drucksensor, ein Gyroskop (MPU6500), ein Drehencoder, zwei Drucktaster, vier LED-Module sowie die eigens entwickelte Leiterplatte (PCB). Das Design des Gehäuses wurde als 3D-Baugruppe in SolidWorks modelliert und anschließend mittels 3D-Druckverfahren aus schwarzem PLA-Material gefertigt. Dieses Material zeichnet sich durch sein geringes Gewicht, hohe Stabilität sowie ein hervorragendes Preis-Leistungs-Verhältnis aus.

Das Gehäuse besteht im Wesentlichen aus zwei Hauptkomponenten: dem Hauptgehäuse und der Grundplatte.

Das Hauptgehäuse umfasst die Oberseite sowie die Seitenwände des Gehäuses mit den Außenmaßen 248 mm x 118 mm x 65 mm. Die Wandstärke der Seiten beträgt 2 mm, während die Oberseite eine Stärke von 3 mm aufweist. In der Oberseite sind passgenaue Aussparungen für das I2C-LCD, den Drehencoder, die zwei Taster (für den Spielstart und die Ergebnisauswertung) sowie die vier LED-Module integriert. An der linken Seitenwand befindet sich zudem eine präzise Aussparung zur Fixierung des Ultraschallsensors, deren Innenmaße exakt auf die Sensorgröße abgestimmt sind.

Die Grundplatte hat eine Stärke von 2 mm und dient als Basis für die Leiterplatte und den Drucksensor. Zur Befestigung der PCB wurden vier erhöhte Schraubdome mit einem Außendurchmesser von 8 mm auf der Grundplatte konstruiert. Diese verfügen über eine Kernlochbohrung von 2,4 mm, um eine M3-Gewindebohrung für 10 mm lange M3-Schrauben zu ermöglichen.

Die Außenmaße der Grundplatte betragen 243 mm x 113 mm. Auf der rechten Seite der Grundplatte wurde eine Plattform zur Aufnahme des Drucksensors integriert. Eine passgenaue Vertiefung sorgt für die exakte Positionierung des Sensormoduls, welches zusätzlich durch eine M3-Schraube in einem 8 mm tiefen Schraubloch fixiert wird.

Zur Verbindung der Grundplatte mit dem Hauptgehäuse wurden an den Längsseiten der Grundplatte 20 mm hohe und 8 mm dicke Verbindungsstege mit 2,4-mm-Bohrungen angebracht. Die entsprechenden Gegenstücke im Hauptgehäuse verfügen über 3-mm-Durchgangslöcher, sodass beide Teile stabil miteinander verschraubt werden können.

Abb. 18: Hauptgehäuse	Abb. 19: Grundplatte

Das Hauptgehäuse und die Grundplatte wurden in SolidWorks als Baugruppe zusammengefügt. Mithilfe der Verknüpfungsfunktionen (Mates) wurden die beiden Komponenten entsprechend der konstruktiven Planung präzise zueinander ausgerichtet. Im Anschluss wurde das Montageergebnis einer detaillierten Prüfung unterzogen, um etwaige Konstruktionsfehler frühzeitig zu identifizieren. Ein besonderer Fokus lag dabei auf der Kontrolle der Koaxialität der Schraublöcher, um sicherzustellen, dass die Bohrungen im Hauptgehäuse exakt mit den Gewindelöchern der Grundplatte fluchten und eine reibungslose Verschraubung ermöglichen.

Um die Passgenauigkeit der Komponenten innerhalb des entworfenen Gehäuses zu gewährleisten, wurden maßstabsgetreue 3D-Modelle aus der GrabCAD-Community heruntergeladen. Diese CAD-Modelle, die in ihren Abmessungen exakt den realen Bauteilen entsprechen, wurden in die Baugruppendatei des Gehäuses importiert. Durch die Anwendung gezielter Verknüpfungen (Mates) wurden die Komponenten gemäß der Planung positioniert, um das Design und die Maßhaltigkeit des Gehäuses zu validieren. Dieser Prozess stellte sicher, dass alle Bauteile korrekt mit dem Gehäuse harmonieren. Die folgende Abbildung zeigt das vollständige Montage-Layout einschließlich aller integrierten Komponenten.

Abb. 21: Gehäuse mit Komponente_1	Abb. 22: Gehäuse mit Komponente_2

Komponententest

OLED-Display & Zustandslogik

Testziel

Ziel dieses Unit-Tests ist die Verifizierung der korrekten visuellen Ausgabe auf dem OLED-Display in Abhängigkeit vom internen Systemzustand. Es soll sichergestellt werden, dass die C++-Treiberfunktion die von der Stateflow-Logik gesendeten Zustandswerte korrekt interpretiert und die entsprechenden Grafiken oder Texte

Testumgebung

Tabelle 15: Testumgebung der OLED-Display(Hardware)

Mikrocontroller	Arduino Mega 2560
Ausgabe	0,96" OLED-Display (SSD1306), angeschlossen via I2C
Eingabe	Drehgeber (KY-040) zur Navigation und Simulation von Benutzeraktionen,Taster.

Tabelle 16: Testumgebung der OLED-Display(Software)

Entwicklungsumgebung	MATLAB/Simulink R2024
Modus	External Mode zur Echtzeit-Beobachtung der Signale.
Treiber-Code	(basierend auf Adafruit GFX Library).oled_wrapper.cpp

Implementierungslogik

Die Implementierung folgt einer Drei-Schichten-Architektur, die die logische Entscheidung (Simulink/Stateflow) von der physischen Darstellung (C++) trennt.

a.Zustandsmaschine (Stateflow Logic)

Das "Gehirn" des Systems ist ein Stateflow-Chart, das den Spielablauf steuert. Basierend auf den Eingaben (Taster, Timer, Kollisionen) wechselt das System zwischen folgenden Zuständen:

State 0 (Wait_Start): Startzustand. Wartet auf .

State 1 (Welcome): Zeigt Startnachricht. Wechselt automatisch zu State 2.

State 2 (Maze_Game): Das eigentliche Spiel. Hier wird die Spielerposition （player_r ，player_c） aktiv berechnet.

Transition zu 3: Wenn (Falle).

Transition zu 4: Wenn (Ziel erreicht).

State 5 (Sensor_Level): Ein separater paralleler Status im Stateflow , der aktiviert wird, wenn das Labyrinth gelöst ist oder durch einen Schalter ausgewählt wird.

b.Simulink-Signalfluss

Der Signalfluss im Modell ist so konzipiert, dass er zwei parallele Aufgaben erfüllt: die Berechnung der Spielphysik und die Priorisierung der Bildschirmanzeige. Die Architektur lässt sich in drei logische Pfade unterteilen (siehe Abb. 25).

Pfad 1: Die Physik-Berechnung

Dieser Pfad ist für die Verarbeitung der Spielerbewegungen zuständig. Das Zustandssignal（current_state_out） aus dem Stateflow-Chart „Game_System“wird direkt in den Physik-Baustein（step_game_physics） geleitet.

Funktion als Aktivierungs-Logik: Die implementierte C++ Funktion nutzt den aktuellen Systemzustand als Filter. Nur wenn sich das System im Zustand „Maze Game“（current_state == 2） befindet, werden die Eingabesignale der Drehgeber (Rotary Encoders) aktiv in Koordinatenänderungen umgerechnet.

Ruhezustand: In allen anderen Zuständen wird die Positionsberechnung pausiert oder zurückgesetzt, um Fehlberechnungen im Hintergrund zu vermeiden.

Ausgang: Der Block（step_game_physics） liefert die aktuellen Spielerkoordinaten（player_r， player_c） , die für den nächsten Render-Schritt benötigt werden.

Pfad 2: Die Anzeige-Priorisierung

Bevor der aktuelle Zustand an den Display-Treiber übermittelt wird, durchläuft er eine Priorisierungsstufe, die durch einen Simulink-Switch-Block realisiert ist. Dies ermöglicht es dem System, kritische Sensor-Meldungen visuell vorzuziehen.

Eingangslogik: Der Switch vergleicht das Signal（sensor_state_out） des „Sensor_System“mit einem Schwellenwert.

Fall A (Override): Ist das Sensor-System aktiv (Status > 3), erhält dieser Status Vorrang. Das Display zeigt somit sofort die Sensor-Meldung an, unabhängig davon, was im Spiel gerade passiert.

Fall B (Normalbetrieb): Liegt keine Sensor-Priorität vor, wird der reguläre Spielstatus an das Display durchgereicht.

Pfad 3: Die Visuelle Darstellung

Der Block（draw_frame_wrapper） führt die Informationen aus Pfad 1 und Pfad 2 zusammen

Zustands-Information: Er empfängt den finalen Status vom Switch-Block (Pfad 2), der definiert, welcher Bildschirminhalt gezeichnet werden soll.

Positions-Information: Er empfängt die aktuellen Koordinaten direkt aus dem Physik-Block (Pfad 1).

Die interne Logik kombiniert diese Daten: Wenn der Status ‚Spiel‘ aktiv ist, nutzt die interne C++-Funktion die Koordinaten, um den Spieler an der physikalisch korrekten Position innerhalb des Labyrinths zu zeichnen und basierend auf verschiedenen Statusinformationen entsprechende Ergebnisse darzustellen.

Im Folgenden finden Sie den Code für die Darstellung.

void draw_frame_wrapper(int current_state, int player_r, int player_c) {
#if defined(__AVR__)

    static int skip_counter = 0;
    skip_counter++;
    if (skip_counter < 4) {
        return;
    }
    skip_counter = 0;

    display.clearDisplay();

    switch (current_state) {
    case 0:
        display.setTextSize(2);
        printCenter(F("Hallo"), 15);
        display.setTextSize(1);
        printCenter(F("Bitte Knopf druecken"), 45);
        break;

    case 1:
        display.setTextSize(2);
        printCenter(F("Hallo "), 15);
        display.setTextSize(1);
        display.setCursor(25, 40);
        display.print(F("Spiel Start"));
        break;

    case 2:
        display.setTextSize(1);
        for (int r = 0; r < 7; r++) {
            for (int c = 0; c < 15; c++) {
                int x = c * TILE_SIZE + START_X; int y = r * TILE_SIZE + 5;
                char cell = MAZE_STR[r][c];
                if (cell == '#' || cell == 'I') display.fillRect(x, y, TILE_SIZE, TILE_SIZE, SSD1306_WHITE);
                else if (cell == 'E') { display.setCursor(x + 1, y + 2); display.print('E'); }
            }
        }
        display.fillCircle(player_c * TILE_SIZE + 4 + START_X, player_r * TILE_SIZE + 4 + 5, 2, SSD1306_WHITE);
        break;

    case 3:
        display.setTextSize(2);
        printCenter(F("GAME OVER!"), 10);
        display.setTextSize(1);
        printCenter(F("Falle ausgelost!"), 35);
        printCenter(F("Neustart: Knopf"), 50);
        break;

    case 4:
        display.setTextSize(1);
        printCenter(F("Gratulation!"), 0);
        display.setTextSize(1);
        printCenter(F("Dein Schlussel ist"), 35);
        display.setTextSize(3);
        printCenter(F("090"), 45);
        break;

    case 5:
        
        display.setTextSize(2);
        printCenter(F("SUPER!"), 10);  

        display.setTextSize(1);
        printCenter(F("System Entsperrt"), 35); 

        display.setTextSize(1);
        
        printCenter(F("Code: OK"), 55);
        break;
    }

    display.display();
#endif
}

Testfälle

Die folgenden Testfälle decken alle definierten Zustände des Systems ab.

Tabelle 17: Testfälle der OLED-Display
ID	Test-Szenario	Voraussetzung	Erwartetes Ergebnis	Status
TC-01	Systemstart	System einschalten. Keine Taste drücken	Zeile 1: "Hallo" ，Zeile 2: "Bitte Knopf druecken"	Abb. 25: Systemstart
TC-02	Willkommens-Screen	taster drücken	Zeile 1: "Hallo "，Zeile 2: "Spiel Start"	Abb. 26: Willkommens-Screen
TC-03	Spielstart	Automatisch nach 3 Sekunden Wartezeit.	Das statische Labyrinth-Raster wird angezeigt. Ein kleiner Punkt (Spieler) ist an der Startposition sichtbar.	Abb. 27: Spielstart
TC-04	Spieler-Bewegung	Im Spiel-Modus : Drehgeber drehen.	Der Punkt auf dem Bildschirm bewegt sich in Echtzeit entsprechend der Drehrichtung.	Abb. 28: Spieler-Bewegung
TC-05	Game Over (Falle)	Spieler steuert in ein Falle	Zeile 1: "GAME OVER!"，Zeile 2: "Falle ausgelost!"，Zeile 3: "Neustart: Knopf"	Abb. 29: Game Over
TC-06	Spiel gewonnen	Spieler zum 'E' (Exit)	Zeile 1: "Gratulation!"，Zeile 2: "Dein Schlussel ist"，Zeile 3: "090"	Abb. 30: Spiel gewonnen
TC-07	Sensor-Level	Aktivierung des Sensor-Modus	Zeile 1: "SUPER!"，Zeile 2: "System Entsperrt"，Zeile 3: "Code: OK"	Abb. 31: Sensor-Level

Eingabegeräte (Encoder/Taster) und LED-Feedback

Testziel

Das Ziel dieses Tests ist die Verifizierung der korrekten Funktion von Encoder, Tastern und LEDs, um sicherzustellen, dass die Hardware in Kombination mit der Softwarelogik die Spielfigur präzise steuern, Spielzustände umschalten und Testfunktionen validieren kann.

Testumgebung

Tabelle 18: Testumgebung der Eingabegeräte(Hardware)

Mikrocontroller	Arduino Mega 2560
Ausgabe	0,96" OLED-Display (SSD1306), LEDs
Eingabe	Drehgeber (KY-040) zur Navigation und Simulation von Benutzeraktionen,Taster.

Tabelle 19: Testumgebung der Eingabegeräte(Software)

Entwicklungsumgebung	MATLAB/Simulink R2024
Modus	External Mode zur Echtzeit-Beobachtung der Signale.
Treiber-Code	oled_wrapper.cpp

Implementierungslogik und Signalfluss

Die Systemarchitektur basiert auf einer hybriden Signalverarbeitung: Während die Eingaben des Drehgebers intern im C++-Code verarbeitet werden, erfolgen die Zustandssteuerung (Taster) und das Feedback (LEDs) direkt über das Simulink-Modell.

a.Interne Signalerfassung

Die primären Navigationsgeräte besitzen keine sichtbaren Eingangsblöcke, da ihre Verarbeitung direkt innerhalb des C Caller Blocks erfolgt. Der C++-Code nutzt Hardware-Interrupts an Pin 2 und 3, um die Drehbewegung des Encoders verzögerungsfrei zu erfassen, sowie eine digitale Abfrage an Pin 5 für die Umschaltung der Bewegungsachse.

b.Direkte Statuseingabe

Im Gegensatz zum Encoder werden die Steuertaster direkt über "Digital Input"-Blöcke in das Modell eingelesen:

Start-Taster (Pin 18): Das Signal wird direkt an den Eingang des Stateflow-Charts geleitet. Eine Betätigung dient als Trigger, um das System vom Startbildschirm in den Spielmodus zu versetzen.

Sensor-Taster (Pin 4): Sein Signal wird an den Stateflow übergeben, um die Sensor-Überprüfung zu aktivieren.

c.Signalübersetzung und Ereignis-Trigger

Die Schnittstelle zwischen dem C Caller und der Logik bildet das Ausgangssignal . Die interne Physik-Logik prüft bei jeder Bewegung die Position. Wird eine Falle ('T') oder das Ziel ('E') erreicht, setzt der Treiber auf 1 (Falle) oder 2 (Ziel). Relational-Operatoren vergleichen diesen Wert mit Konstantenblöcken und senden bei Übereinstimmung ein -Signal an den Stateflow.

d.Zustandsentscheidung und physisches Feedback

Das Stateflow-Chart entscheidet basierend auf diesen Signalen über den Spielstatus. Sobald ein Trigger empfangen wird, wechselt der Zustand.

Testfälle

Die folgenden Testfälle decken alle definierten Zustände des Systems ab.

Tabelle 20: Testfälle der Encoder，Taster und LED
ID	Test-Szenario	Voraussetzung	Erwartetes Ergebnis	Status
TC-01	Systemstart	taster drücken	Zeile 1: "Hallo "，Zeile 2: "Spiel Start"	Abb. 33: Willkommens-Screen
TC-02	Bewegungssteuerung	Den Drehgeber langsam drehen.	Die Spielfigur bewegt sich auf dem Display exakt ein Feld in die aktuelle Richtung.	Abb. 34: Bewegungssteuerung
TC-03	Achsenumschaltung	Den Encoder-Taster einmal drücken und anschließend den Encoder drehen.	Die Bewegungsrichtung der Spielfigur ändert sich von horizontal zu vertikal.	Abb. 35: Achsenumschaltung
TC-04	Ereignis: Falle	Die Spielfigur absichtlich auf ein Feld mit einer Falle steuern.	Die Rote LED leuchtet sofort auf. Der Spielstatus wechselt zu "Game Over".	Abb. 36: Game Over Abb. 37: rotled
TC-05	Spiel gewonnen	Die Spielfigur auf das Ziel-Feld steuern.	Die Grüne LED leuchtet sofort auf. Der Spielstatus wechselt zu "Finished".	Abb. 38: Spiel gewonnen Abb. 39: Grüne LED

Ultraschall-Sensorsystem

Testziel

Das Ziel dieses Tests ist die Verifizierung der korrekten Distanzmessung und der darauf basierenden Logikprüfung. Es soll sichergestellt werden, dass der Ultraschallsensor Objekte präzise erkennt und das System nur dann eine "erfolgreiche Messung" meldet, wenn sich das Objekt im definierten Zielbereich (9 cm bis 11 cm) befindet. Zudem wird das korrekte visuelle Feedback über die Status-LEDs geprüft.

Testumgebung

Tabelle 20: Testumgebung der Ultraschall-Sensorsystem(Hardware)

Mikrocontroller	Arduino Mega 2560
Ausgabe	Grüne LED: Signalisiert korrekten Abstand. Rote LED : Signalisiert falschen Abstand
Eingabe	HC-SR04 Ultraschall-Modul
Aktivierung	Taster

Tabelle 21: Testumgebung der UltraschallSensorsystem(Software)

Entwicklungsumgebung	MATLAB/Simulink R2024
Logik	Stateflow-Chart
Signalverarbeitung	Simulink-Treiberblock für Ultraschall + Gain-Block .

Implementierungslogik & Signalfluss

Die Verarbeitung der Sensordaten erfolgt in einer Kette von physikalischer Messung, Skalierung und logischer Bewertung.

a.Messung und Skalierung Der Simulink-Treiberblock steuert den HC-SR04 Sensor an (Trigger-Impuls) und misst die Laufzeit des Echo-Signals. Dieser Rohwert (in Metern) wird durch einen Gain-Block (Faktor 100) geleitet, um ihn in Zentimeter umzurechnen. Das resultierende Signal wird kontinuierlich an das Stateflow-Chart gesendet.dist

b.Logische Prüfung (Stateflow) Im Stateflow-Chart wird die Messung erst aktiviert, wenn der Sensor-Taster gedrückt wurde. Liegt der Messwert exakt zwischen 9 cm und 11 cm, wird die interne Variable auf 1 gesetzt. Dies markiert den Test als bestanden.

c.Visuelles Feedback Basierend auf dem Status von steuert das Stateflow-Chart die LEDs an

Erfolg: Wenn , wird der Ausgang aktiviert -> Grüne LED leuchtet.

Fehler: Solange die Bedingung nicht erfüllt ist -> Rote LED leuchtet.

Testfälle

Die folgenden Testfälle decken alle definierten Zustände des Systems ab.

Tabelle 22: Testfälle der Ultraschall
ID	Test-Szenario	Voraussetzung	Erwartetes Ergebnis	Status
TC-01	Distanz zu gering	Ein Objekt in 5 cm Entfernung vor den Sensor halten.	Die Rote LED bleibt an.	Abb. 41: Distanz zu gering
TC-02	Distanz zu groß	Ein Objekt in ＞10 cm Entfernung vor den Sensor halten.	Die Rote LED bleibt an.	Abb. 42: Distanz zu groß
TC-03	Zielbereich (Erfolg)	Ein Objekt in den Bereich von 10 cm bewegen.	Die Grüne LED leuchtet auf.	Abb. 43: Zielbereich

MPU6050 Neigungssensor

Testziel

Das Ziel dieses Tests ist die Verifizierung der korrekten Neigungserkennung durch das MPU6050-Modul. Es soll sichergestellt werden, dass die physische Neigung des Controllers präzise in einen Winkel umgerechnet wird und die Logik den Zielzustand (ca. 45 Grad Neigung) innerhalb des definierten Toleranzbereichs erkennt, um den Sensor-Check erfolgreich abzuschließen.

Testumgebung

Tabelle 23: Testumgebung der MPU6050(Hardware)

Mikrocontroller	Arduino Mega 2560
Ausgabe	Grüne LED : Signalisiert korrekte Neigung . Rote LED : Signalisiert falschen Winkel (zu flach oder zu steil).
Eingabe	MPU6050 Gyroskop/Akzelerometer
Aktivierung	Taster

Tabelle 24: Testumgebung der MPU6050(Software)

Entwicklungsumgebung	MATLAB/Simulink R2024
Logik	Stateflow-Chart
Signalverarbeitung	C++ Wrapper (step_game_physics)

Implementierungslogik & Signalfluss

Die Winkelberechnung erfolgt vollständig im C++-Code, während die Auswertung des Ergebnisses im Stateflow stattfindet.

a. Physikalische Berechnung Der C Caller Block liest über den I2C-Bus die rohen Beschleunigungswerte des MPU6050 aus. Basierend auf diesen Rohdaten berechnet die Funktion mittels trigonometrischer Funktionen den aktuellen Neigungswinkel. Der berechnete Gleitkommawert wird als Signal an das Simulink-Modell ausgegeben.

b. Logische Prüfung Im Stateflow-Chart wird dieser Winkel überwacht, sobald der Testmodus aktiviert ist. Die Logik prüft, ob der Winkel dem Zielwert von 45 Grad entspricht. Im Code ist ein Toleranzbereich von ±5 Grad definiert, was bedeutet, dass der Test als bestanden gilt, wenn der Controller um 40° bis 50° (in positiver oder negativer Richtung) geneigt wird.

c. Visuelles Feedback Das Stateflow-Chart steuert basierend auf dem Ergebnis die LED-Leuchten:

Erfolg: Wenn der Winkel im Zielbereich liegt, wird der Ausgang aktiviert -> Die Grüne LED leuchtet auf.

Fehler: Liegt der Winkel außerhalb des Bereichs -> Die Rote LED leuchtet.

Der folgende Code-Ausschnitt implementiert die Kernlogik für die Bewegungssteuerung und die Kollisionserkennung im Spielmodus. Zudem wird hier die Signalauswertung für den MPU6050-Sensor und den Drehgeber durchgeführt.

void step_game_physics(int current_state, int* player_r, int* player_c, int* game_event, double* angle_z) {
#if defined(__AVR__)

    
    Wire.beginTransmission(MPU_ADDR);
    Wire.write(0x3B);
    Wire.endTransmission(false);
    Wire.requestFrom(MPU_ADDR, 6, true); 

    
    int16_t rawAccX = Wire.read() << 8 | Wire.read();
    int16_t rawAccY = Wire.read() << 8 | Wire.read();
    int16_t rawAccZ = Wire.read() << 8 | Wire.read();

   
    float accX = rawAccX;
    float accY = rawAccY;
    float accZ = rawAccZ;


    float angle_x_gravity = atan2(accY, accZ) * 180.0 / PI;

    
    float angle_y_gravity = atan2(-accX, accZ) * 180.0 / PI;

  
    Serial.print("Roll(X): "); Serial.print(angle_x_gravity);
    Serial.print(" | Pitch(Y): "); Serial.println(angle_y_gravity);

 
    *angle_z = angle_x_gravity;

    *game_event = 0;

  
    if (current_state == 2) {
        if (digitalRead(ENC_SW_PIN) == LOW) {
            if (millis() - last_sw_time > 300) {
                is_horizontal = !is_horizontal;
                last_sw_time = millis();
            }
        }

        noInterrupts();
        int raw = encoder_raw_count;
        interrupts();

        if (abs(raw) >= 4) {
            int steps = raw / 4;
            noInterrupts();
            encoder_raw_count -= (steps * 4);
            interrupts();

            int dir = (steps > 0) ? 1 : -1;
            steps = abs(steps);

            for (int i = 0; i < steps; i++) {
                int nr = my_r;
                int nc = my_c;
                char cmd = ' ';

                if (dir == 1) cmd = is_horizontal ? 'd' : 'w';
                else          cmd = is_horizontal ? 'a' : 's';

                if (cmd == 'w') nr--; else if (cmd == 's') nr++;
                else if (cmd == 'a') nc--; else if (cmd == 'd') nc++;

                if (nr >= 0 && nr < 7 && nc >= 0 && nc < 15) {
                    char target = MAZE_STR[nr][nc];
                    if (target != '#' && target != 'I') {
                        my_r = nr;
                        my_c = nc;
                        if (target == 'T') {
                            *game_event = 1;
                            break;
                        }
                        if (target == 'E') {
                            *game_event = 2;
                            break;
                        }
                    }
                }
            }
        }
    }
    else {
        my_r = 3;
        my_c = 1;
        encoder_raw_count = 0;
    }

    *player_r = my_r;
    *player_c = my_c;
#else
    * player_r = 3; *player_c = 1; *game_event = 0; *angle_z = 0.0;
#endif
}

Testfälle

Die folgenden Testfälle decken alle definierten Zustände des Systems ab.

Tabelle 25: Testfälle der MPU6050
ID	Test-Szenario	Voraussetzung	Erwartetes Ergebnis	Status
TC-01	(0 Grad)	Den Controller flach auf den Tisch legen (0° Neigung).	Die Rote LED leuchtet.	Abb. 45: 0 Grad
TC-02	(90 Grad)	Den Controller komplett senkrecht aufstellen (90°).	Die Rote LED leuchtet.	Abb. 46: 90 Grad
TC-03	Zielwinkel (45 Grad)	Den Controller langsam anheben und auf ca. 45° neigen.	Die Grüne LED leuchtet.	Abb. 47: 45 Grad

Drucksensor

Testziel

Das Ziel dieses Tests ist die Verifizierung der analogen Signalerfassung und der Schwellenwert-Logik. Es soll sichergestellt werden, dass der Drucksensor (FSR) physikalischen Druck korrekt als analogen Wert erfasst und das System diesen nur validiert, wenn er sich im definierten Bereich befindet.

Testumgebung

Tabelle 26: Testumgebung der Drucksensor(Hardware)

Mikrocontroller	Arduino Mega 2560
Ausgabe	Grüne LED : Signalisiert korrekten Druck . Rote LED : falschen Druck.
Eingabe	Drucksenso
Aktivierung	Taster

Tabelle 27: Testumgebung der Drucksensor(Software)

Entwicklungsumgebung	MATLAB/Simulink R2024
Logik	Stateflow-Chart
Signalverarbeitung	"Arduino Analog Input"-Block zur Erfassung des Rohwertes (0–1023).

Implementierungslogik

Dieser Test basiert auf der Auswertung eines kontinuierlichen analogen Signals.

a. Analoge Signalerfassung Der Arduino Analog Input Block liest die Spannung am Pin A0 aus. Der interne ADC des Arduino wandelt diese Spannung in einen ganzzahligen Rohwert zwischen 0 (0V) und 1023 (5V) um. Dieses Signal wird direkt, ohne C++-Wrapper, in das Stateflow-Chart weitergeleitet.

b. Logische Prüfung Sobald der Taster den Testmodus aktiviert, wird das Signal im Stateflow überwacht. Die Logik prüft, ob der ausgeübte Druck stark genug, aber nicht zu stark ist (Bereichsprüfung).

c. Visuelles Feedback:Das Stateflow-Chart steuert die LED-Signale basierend auf dem Ergebnis:

Erfolg: Liegt der Druck im Zielbereich, wird der Ausgang aktiviert und die Grüne LED leuchtet auf.

Fehler/Warten: Liegt der Druck außerhalb des Bereichs (z. B. 0), leuchtet die Rote LED.

Testfälle

Die folgenden Testfälle decken alle definierten Zustände des Systems ab.

Tabelle 28: Testfälle der Drucksensor
ID	Test-Szenario	Voraussetzung	Erwartetes Ergebnis	Status
TC-01	Leichte Berührung	Den Sensor nur sehr sanft berühren .	Die Rote LED bleibt an.	Abb. 48: Leichte Berührung
TC-02	Normaler Druck(90g)	Den Sensor mit normaler Kraft drücken	Die Rote LED bleibt an.	Abb. 49: Normaler Druck
TC-03	Maximaler Druck	Den Sensor extrem fest drücken	Die Grüne LED leuchtet auf.	Abb. 50: Maximaler Druck

Es ist erwähnenswert, dass die sehr kleine aktive Fläche des Drucksensors dazu führte, dass sich die Gewichtskraft leicht verteilte, was die Kalibrierung der Analogwerte (Ausgangsspannung) im Verhältnis zum Gewicht extrem erschwerte.Nach zahlreichen Versuchen wurde schließlich eine Kombination aus Schaumstoff und einem runden Distanzstück (Kegelstumpf) verwendet, um den Druck bestmöglich auf den Sensor zu konzentrieren. Da eine präzise Kalibrierung dennoch kaum realisierbar war, musste der Zielbereich letztlich als ein breiteres Toleranzintervall definiert werden.

Ergebnis & Diskussion

Testauswertung

Die Testergebnisse verdeutlichen, dass das Gesamtsystem alle gestellten Anforderungen erfüllt und die beabsichtigten Funktionen einwandfrei ausführt. Das Zusammenspiel zwischen den Sensoren und dem geprüften System verlief reibungslos. Da die Messabweichungen innerhalb des tolerierbaren Bereichs liegen, attestiert dies dem System eine hohe Robustheit und Präzision.

Der Gesamttest des Projekts war somit erfolgreich. Alle Spezifikationen wurden erfüllt, was die Zuverlässigkeit des Systems bestätigt:

Stateflow-Integration: Die Ergebnisse der Funktionstests zeigen, dass das System dank der Integration von Stateflow unmittelbar auf Benutzereingaben reagiert. Dies erfüllt die Anforderungen an eine effiziente Mensch-Maschine-Interaktion (HMI).

Messfunktionen und Feedback: Das Projekt realisiert präzise Messungen von Distanz, Neigungswinkel und Gewichtsschätzungen. Alle Ergebnisse liegen innerhalb der akzeptablen Fehlertoleranz. Zudem erfolgt die Rückmeldung an den Benutzer erwartungsgemäß über LED-Signale. Das System zeichnet sich durch eine intuitive Bedienung und hohe Interaktivität aus, ohne dabei an Komplexität zu überfordern, wodurch es für alle Altersgruppen zugänglich ist.

Highlight – Maze-Spiel: Das herausragende Merkmal des Projekts ist das über das SSD1306-OLED-Display und den Drehencoder realisierte Labyrinth-Spiel. Mithilfe von Stateflow wurde das System in sechs logische Zustände unterteilt, zwischen denen je nach Eingabe gewechselt wird. Die physikalischen Eigenschaften, die Anzeige-Prioritäten und die visuelle Darstellung wurden mittels Simulink-Signalfluss berechnet. Der Drehencoder dient dabei als primäre Schnittstelle zur Steuerung der Spielfigur. Dank der klar strukturierten Zustandsmaschine bietet das Spiel ein exzellentes Feedback sowie einen hohen Unterhaltungswert bei angemessenem Schwierigkeitsgrad.

Defizite

Während der Designphase stellte sich heraus, dass der verwendete Drucksensor (ARD SENPRESSURE) für die präzise Gewichtsmessung nur bedingt geeignet ist. Da die Auflage der Testobjekte auf der Sensorfläche keine ausreichende Stabilität aufwies, zeigten die Ausgangssignale starke Schwankungen. Diese Instabilität verhinderte eine exakte Ermittlung des Gewichts, da die Werte unkontrolliert fluktuierten. Für zukünftige Optimierungen wäre der Einsatz eines alternativen Sensortyps, wie beispielsweise einer Wägezelle (Load Cell) mit entsprechendem Messverstärker, eine deutlich effizientere Lösung.

Zusammenfassung

Lessons Learned

Fetter Text== Projektunterlagen ==

Abb. 51: Gantt Projekt für das Projekt "Escape Game:Rätselbox“

Projektplan

Abbildung 40 zeigt den Projektzeitplan von Oktober 2025 bis Januar 2026. Die Balken im Gantt-Diagramm stehen für einzelne Aufgaben und zeigen deren Start- und Enddatum an. Zu den aufgeführten Aufgaben gehören Sensortests, Systementwicklung, Leiterplattenentwurf, Gehäusedesign sowie Endmontage und Tests. Das Projekt wird am 12. Januar 2026 abgeschlossen sein, zu diesem Zeitpunkt wird auch der Wikipedia-Artikel fertiggestellt sein.

Aufgabestellung

Level 1:

Das Labyrinth-Spiel: In diesem ersten Abschnitt wird auf dem Display ein Labyrinth dargestellt. Der Spieler steuert seine Figur mithilfe des Drehencoders durch die Gänge. Bei erfolgreichem Erreichen des Ziels erhält der Spieler einen entscheidenden Hinweis, der als Grundlage für die Lösung des zweiten Levels dient.

Level 2:

Schätzherausforderungen: Die Schätzherausforderungen Basierend auf dem in Level 1 gewonnenen Hinweis muss der Spieler drei spezifische Kennzahlen ermitteln, um die folgenden technischen Herausforderungen innerhalb der Rätselbox zu bewältigen:

Distanzschätzung: Der Spieler muss eine Distanz von exakt 10 cm abschätzen. Das System misst den tatsächlichen Wert und gibt die Abweichung als Feedback aus.
Gewichtsschätzung: Es müssen Münzen so ausgewählt werden, dass deren Gesamtgewicht möglichst genau 90 Gramm entspricht.
Winkelschätzung: Der Spieler muss das Hauptgehäuse entlang der Längsseite der Grundplatte um exakt 45 Grad neigen.

Der Spieler kann seine Ergebnisse jederzeit durch Betätigen eines Tasters überprüfen lassen. Jede erfolgreich absolvierte Herausforderung wird durch das Aufleuchten einer grünen LED signalisiert; bei einer Fehlentscheidung leuchtet die entsprechende LED rot. Das Spiel gilt als gewonnen, wenn alle vier LEDs grün leuchten.

Projekt Durchführung

Die Projektdurchführung begann mit einer gemeinsamen Ideenfindung zu Beginn des Semesters. Dieses Projekt basiert auf der Handlung der Kapitel 4 bis 7 des vierten Bandes des Mangas „Detektiv Conan“. In der Geschichte platziert der Täter eine Bombe in einem Shinkansen-Hochgeschwindigkeitszug. Fällt die Geschwindigkeit des Zuges unter 80 km/h, explodiert die Bombe. Conan muss den Fall noch im Zug lösen, um den Täter zu identifizieren und die Krise abzuwenden. Sein Kombinationsprozess stützt sich dabei maßgeblich auf die Schlüsselzahl 80, aus der er weitere Informationen ableitet.

SVN-Projektdaten

Projektordner

YouTube Video

Escapegame-Rätselbox

Weblinks

Literatur

→ zurück zur Übersicht: WS 25/26: Escape Game

@@ Zeile 1.454: / Zeile 1.454: @@
 '''Fetter Text'''== Projektunterlagen ==
-[[Datei:Gantt-Raetselbox.png|mini|left|600px|Abb. : Gantt Projekt für das Projekt "Escape Game:Rätselbox“]]
+[[Datei:Gantt-Raetselbox.png|mini|left|600px|Abb. 51: Gantt Projekt für das Projekt "Escape Game:Rätselbox“]]
 <br clear=all>

Escape Game: Rätselbox: Unterschied zwischen den Versionen

Version vom 12. Januar 2026, 23:18 Uhr

Inhaltsverzeichnis

Einleitung

Anforderungen

Funktionaler Systementwurf

Technischer Systementwurf

Materialliste

Komponentenspezifikation

Stückliste (BOM)

Umsetzung (HW/SW)

Technische Daten der Sensoren

Hardware-Modul: Ultraschallsensor HC-SR04

Hardware-Modul: Ultraschallsensor KY-040

Hardware-Modul: MPU6050

Hardware-Modul: OLED-Display (SSD1306)

Hardware-Modul: Drucksensor (SEN-PRESSURE02)

PCB Entwicklung

Gehäuseentwicklung

Komponententest

OLED-Display & Zustandslogik

Eingabegeräte (Encoder/Taster) und LED-Feedback

Ultraschall-Sensorsystem

MPU6050 Neigungssensor

Drucksensor

Ergebnis & Diskussion

Zusammenfassung

Lessons Learned

Projektplan

Aufgabestellung

Level 1:

Level 2:

Projekt Durchführung

SVN-Projektdaten

YouTube Video

Weblinks

Literatur

Navigationsmenü

Escape Game: Rätselbox: Unterschied zwischen den Versionen

Version vom 12. Januar 2026, 23:18 Uhr

Einleitung

Anforderungen

Funktionaler Systementwurf

Technischer Systementwurf

Materialliste

Komponentenspezifikation

Stückliste (BOM)

Umsetzung (HW/SW)

Technische Daten der Sensoren

Hardware-Modul: Ultraschallsensor HC-SR04

Hardware-Modul: Ultraschallsensor KY-040

Hardware-Modul: MPU6050

Hardware-Modul: OLED-Display (SSD1306)

Hardware-Modul: Drucksensor (SEN-PRESSURE02)

PCB Entwicklung

Gehäuseentwicklung

Komponententest

OLED-Display & Zustandslogik

Eingabegeräte (Encoder/Taster) und LED-Feedback

Ultraschall-Sensorsystem

MPU6050 Neigungssensor

Drucksensor

Ergebnis & Diskussion

Zusammenfassung

Lessons Learned

Projektplan

Aufgabestellung

Level 1:

Level 2:

Projekt Durchführung

SVN-Projektdaten

YouTube Video

Weblinks

Literatur

Navigationsmenü

Suche