feat: expanded and added more tasks

00-course-overview/01-kursziel-und-zielsystem-beschreiben.md

@@ -0,0 +1,38 @@
+# Aufgabe 01: Kursziel und Zielsystem beschreiben
+
+## Ziel
+
+Du formulierst das konkrete Zielbild des sprechenden Roboterkopfs und grenzt bewusst aus, was noch nicht gebaut wird.
+
+## Warum ist das wichtig?
+
+Ohne klares Ziel verzettelst du dich schnell zwischen AI, Kamera, Audio, Hardware und ROS2.
+
+## Voraussetzungen
+
+- keine
+- Texteditor
+
+## Theorie
+
+Systemdenken beginnt mit Grenzen: Ein Roboterkopf ist kein kompletter humanoider Roboter, sondern ein integriertes System aus Wahrnehmen, Entscheiden und Handeln. Je genauer du Ein- und Ausgaben beschreibst, desto einfacher werden spätere Schnittstellen.
+
+## Aufgabe
+
+Erstelle eine kurze Zielsystem-Spezifikation mit Use Cases, Nicht-Zielen, ersten Qualitätszielen und einer Liste der wichtigsten Komponenten.
+
+## Akzeptanzkriterien
+
+- Eine Datei beschreibt mindestens fünf Use Cases.
+- Nicht-Ziele sind explizit notiert.
+- Die Komponenten Audio, LLM, Vision, Face Recognition und Motion kommen vor.
+
+## Erweiterungen
+
+- Skizziere zusätzlich ein Kontextdiagramm.
+
+## Reflexionsfragen
+
+- Welche Funktion ist für das erste Erfolgserlebnis am wichtigsten?
+- Welche Nicht-Ziele schützen dich vor zu großer Komplexität?
+- Welche Teile des Systems sind sicherheitskritisch?

00-course-overview/02-hardware-empfehlungen-pruefen.md

@@ -0,0 +1,39 @@
+# Aufgabe 02: Hardware-Empfehlungen prüfen
+
+## Ziel
+
+Du stellst eine realistische Einkaufsliste für Prototyping und spätere Hardware zusammen.
+
+## Warum ist das wichtig?
+
+Hardware-Fehlkäufe kosten Zeit und machen Debugging unnötig schwer.
+
+## Voraussetzungen
+
+- Aufgabe 01
+- Browser oder lokale Recherche
+- Budgetrahmen
+
+## Theorie
+
+Für frühe Lernschritte reicht oft ein Linux-PC mit USB-Kamera und Mikrofon. Servos, Stromversorgung und Kameraqualität werden erst dann wichtig, wenn Softwarepfade stabil sind.
+
+## Aufgabe
+
+Erstelle eine Hardware-Matrix mit Mindestsetup, empfohlenem Setup und optionalen Upgrades. Begründe jede Komponente kurz.
+
+## Akzeptanzkriterien
+
+- Mindestsetup funktioniert ohne Servo-Hardware.
+- Stromversorgung für Servos wird separat betrachtet.
+- Kamera, Mikrofon, Lautsprecher und Recheneinheit sind aufgeführt.
+
+## Erweiterungen
+
+- Füge Alternativen für Raspberry Pi, Mini-PC und Laptop hinzu.
+
+## Reflexionsfragen
+
+- Was kannst du komplett simulieren?
+- Welche Hardware muss vor dem Kauf elektrisch geprüft werden?
+- Welche Komponente beeinflusst Latenz am stärksten?

00-course-overview/03-software-setup-vorbereiten.md

@@ -0,0 +1,40 @@
+# Aufgabe 03: Software-Setup vorbereiten
+
+## Ziel
+
+Du definierst eine reproduzierbare Entwicklungsumgebung für Python, Rust, Docker und lokale Modelle.
+
+## Warum ist das wichtig?
+
+Ein Roboterprojekt wird schnell unwartbar, wenn jede Komponente anders gestartet wird.
+
+## Voraussetzungen
+
+- Linux oder WSL
+- Rust toolchain
+- Python 3.11+
+- Docker optional
+
+## Theorie
+
+Reproduzierbarkeit ist wichtiger als Perfektion. Eine klare Ordnerstruktur, feste Versionen und einfache Startbefehle reduzieren Reibung beim Wechsel zwischen AI-, Vision- und Hardware-Code.
+
+## Aufgabe
+
+Lege eine Setup-Notiz mit benötigten Tools, Versionen, Installationschecks und ersten Smoke Tests an.
+
+## Akzeptanzkriterien
+
+- Rust, Python und Docker werden mit Befehlen geprüft.
+- Es gibt eine Liste erwarteter Versionen.
+- Mindestens ein Smoke Test pro Tool ist beschrieben.
+
+## Erweiterungen
+
+- Erstelle später ein `justfile` oder `Makefile` für häufige Befehle.
+
+## Reflexionsfragen
+
+- Welche Tools müssen systemweit installiert sein?
+- Welche Abhängigkeiten gehören in ein Projekt-Environment?
+- Wie erkennst du Setup-Probleme früh?

00-course-overview/04-lernstrategie-und-projekttagebuch.md

@@ -0,0 +1,38 @@
+# Aufgabe 04: Lernstrategie und Projekttagebuch
+
+## Ziel
+
+Du richtest ein Projekttagebuch ein, das Entscheidungen, Messwerte und offene Fragen festhält.
+
+## Warum ist das wichtig?
+
+Bei Robotik ist Debugging oft experimentell. Gute Notizen sparen Stunden.
+
+## Voraussetzungen
+
+- Aufgabe 01
+- Markdown
+
+## Theorie
+
+Ein Projekttagebuch ist kein Roman, sondern ein technisches Gedächtnis. Es hält fest, was du geändert hast, welche Hypothese du hattest und welches Ergebnis gemessen wurde.
+
+## Aufgabe
+
+Erstelle eine Vorlage für tägliche Einträge mit Ziel, Änderung, Beobachtung, Messwerten, Fehlern und nächstem Schritt.
+
+## Akzeptanzkriterien
+
+- Die Vorlage enthält Messwerte für Latenz und FPS.
+- Fehler und Hypothesen haben eigene Abschnitte.
+- Mindestens ein Beispieltag ist ausgefüllt.
+
+## Erweiterungen
+
+- Ergänze eine Entscheidungslog-Datei für Architekturentscheidungen.
+
+## Reflexionsfragen
+
+- Welche Informationen vergisst man nach zwei Wochen zuerst?
+- Welche Messwerte willst du regelmäßig vergleichen?
+- Wann ist eine Notiz besser als ein Kommentar im Code?

00-course-overview/05-sicherheit-und-datenschutz-festlegen.md

@@ -0,0 +1,38 @@
+# Aufgabe 05: Sicherheit und Datenschutz festlegen
+
+## Ziel
+
+Du definierst Grundregeln für Kamera, Mikrofon, bekannte Personen und Servo-Bewegungen.
+
+## Warum ist das wichtig?
+
+Der Roboter verarbeitet sensible Daten und bewegt Hardware in der Nähe von Menschen.
+
+## Voraussetzungen
+
+- Aufgaben 01-04
+- Grundverständnis Datenschutz
+
+## Theorie
+
+Mikrofon- und Kameradaten sind personenbezogen. Servos können mechanisch blockieren oder Bauteile beschädigen. Deshalb braucht das Projekt von Anfang an Grenzen, Einwilligung und sichere Defaults.
+
+## Aufgabe
+
+Schreibe eine Sicherheits- und Datenschutz-Checkliste für Entwicklung, Tests und Vorführung.
+
+## Akzeptanzkriterien
+
+- Consent-Regeln für Face Recognition sind enthalten.
+- Audio- und Bildspeicherung sind geregelt.
+- Servo-Winkel und Not-Aus werden erwähnt.
+
+## Erweiterungen
+
+- Definiere eine rote Status-LED oder Konsolenausgabe für aktive Aufnahme.
+
+## Reflexionsfragen
+
+- Welche Daten darfst du nicht dauerhaft speichern?
+- Wie erklärst du Testpersonen die Gesichtserkennung?
+- Was muss passieren, wenn ein Servo blockiert?

00-course-overview/README.md

@@ -0,0 +1,15 @@
+# Kursüberblick
+
+Orientierung, Setup, Lernstrategie und die grobe Architektur des späteren Roboterkopfs.
+
+## Aufgaben
+
+- [01: Kursziel und Zielsystem beschreiben](01-kursziel-und-zielsystem-beschreiben.md)
+- [02: Hardware-Empfehlungen prüfen](02-hardware-empfehlungen-pruefen.md)
+- [03: Software-Setup vorbereiten](03-software-setup-vorbereiten.md)
+- [04: Lernstrategie und Projekttagebuch](04-lernstrategie-und-projekttagebuch.md)
+- [05: Sicherheit und Datenschutz festlegen](05-sicherheit-und-datenschutz-festlegen.md)
+
+## Arbeitsweise
+
+Bearbeite die Aufgaben nacheinander. Jede Aufgabe soll ein kleines, überprüfbares Ergebnis liefern und ist bewusst auf etwa 1 bis 4 Stunden ausgelegt.

01-ai-agent-basics/01-llm-api-per-cli-ansprechen.md

@@ -0,0 +1,39 @@
+# Aufgabe 01: LLM API per CLI ansprechen
+
+## Ziel
+
+Du baust eine CLI, die eine Chat-Anfrage an ein LLM sendet und die Antwort ausgibt.
+
+## Warum ist das wichtig?
+
+Der spätere Roboter braucht ein kontrolliertes Sprachmodell als Denk- und Dialogkomponente.
+
+## Voraussetzungen
+
+- Rust oder Python
+- API-Key oder Ollama
+- HTTP-Grundlagen
+
+## Theorie
+
+LLM APIs arbeiten meist mit Nachrichten statt mit einem einzelnen Prompt. Rollen wie system, user und assistant geben dem Modell Kontext und begrenzen Verhalten.
+
+## Aufgabe
+
+Implementiere `ask "Frage"` mit konfigurierbarer Provider-URL, Timeout und verständlicher Fehlerausgabe.
+
+## Akzeptanzkriterien
+
+- Eine Frage kann per Terminal gestellt werden.
+- Antwort und Fehler werden sauber ausgegeben.
+- Provider-Konfiguration liegt nicht hart im Code.
+
+## Erweiterungen
+
+- Speichere Request und Response als JSON-Log.
+
+## Reflexionsfragen
+
+- Welche Daten sendest du an den Provider?
+- Was gehört in Konfiguration statt Code?
+- Wie erkennst du API-Timeouts?

01-ai-agent-basics/02-ollama-und-cloud-api-vergleichen.md

@@ -0,0 +1,39 @@
+# Aufgabe 02: Ollama und Cloud API vergleichen
+
+## Ziel
+
+Du vergleichst lokale und cloudbasierte LLMs mit denselben Prompts.
+
+## Warum ist das wichtig?
+
+Der Roboter muss je nach Datenschutz, Kosten und Latenz mit verschiedenen Modellquellen umgehen können.
+
+## Voraussetzungen
+
+- Aufgabe 01
+- Ollama optional
+- Cloud API optional
+
+## Theorie
+
+Lokale Modelle geben mehr Kontrolle, brauchen aber Hardware und sind oft schwächer. Cloud APIs sind leistungsfähig, erzeugen aber Kosten und Datenschutzfragen.
+
+## Aufgabe
+
+Baue einen Provider-Schalter und teste mindestens fünf Prompts gegen beide Varianten oder dokumentiere eine simulierte zweite Variante.
+
+## Akzeptanzkriterien
+
+- Provider kann per Config gewechselt werden.
+- Latenz und Antwortqualität werden notiert.
+- Datenschutz- und Kostenunterschiede sind beschrieben.
+
+## Erweiterungen
+
+- Füge einen Fallback auf lokales Modell bei Cloud-Fehler ein.
+
+## Reflexionsfragen
+
+- Wann ist lokal besser?
+- Welche Prompts zeigen Qualitätsunterschiede?
+- Wie wirkt Modelllatenz auf Sprachdialog?

01-ai-agent-basics/03-chat-messages-modellieren.md

@@ -0,0 +1,38 @@
+# Aufgabe 03: Chat Messages modellieren
+
+## Ziel
+
+Du modellierst Chat Messages als strukturierte Daten statt als String-Konkatenation.
+
+## Warum ist das wichtig?
+
+Tool Calling und Conversation History funktionieren nur sauber mit expliziten Rollen und Feldern.
+
+## Voraussetzungen
+
+- Aufgabe 01
+- JSON/Serde oder Pydantic
+
+## Theorie
+
+Strukturierte Nachrichten verhindern Prompt-Chaos. Der Code kann validieren, kürzen, speichern und gezielt System- oder Tool-Nachrichten einfügen.
+
+## Aufgabe
+
+Definiere Typen für system, user, assistant und tool messages und serialisiere sie in das API-Format deines Providers.
+
+## Akzeptanzkriterien
+
+- Rollen sind typisiert oder validiert.
+- JSON-Ausgabe entspricht dem Provider-Format.
+- Ungültige Rollen werden abgefangen.
+
+## Erweiterungen
+
+- Schreibe Unit Tests für Serialisierung.
+
+## Reflexionsfragen
+
+- Warum sind Rollen besser als ein langer Prompt?
+- Was muss eine Tool-Nachricht enthalten?
+- Wie würdest du binäre Daten vermeiden?

01-ai-agent-basics/04-system-prompt-entwerfen.md

@@ -0,0 +1,38 @@
+# Aufgabe 04: System Prompt entwerfen
+
+## Ziel
+
+Du schreibst einen System Prompt für den Roboterassistenten mit klaren Grenzen.
+
+## Warum ist das wichtig?
+
+Der Roboter darf nicht raten, wenn Sensor-Tools echte Daten liefern sollen.
+
+## Voraussetzungen
+
+- Aufgabe 03
+- Texteditor
+
+## Theorie
+
+Ein guter System Prompt beschreibt Rolle, Grenzen und Entscheidungsregeln. Er ersetzt keine Programmlogik, aber er hilft dem Modell, Tools korrekt zu nutzen.
+
+## Aufgabe
+
+Erstelle einen System Prompt, der kurze deutsche Antworten, Tool-Nutzung bei Sensorfragen und sichere Hardwarebefehle vorgibt.
+
+## Akzeptanzkriterien
+
+- Prompt enthält Rolle, Sprache und Sicherheitsregeln.
+- Sensorfragen sollen Tools nutzen.
+- Gefährliche Aktionen werden abgelehnt oder bestätigt.
+
+## Erweiterungen
+
+- Teste den Prompt mit zehn absichtlich schwierigen User-Fragen.
+
+## Reflexionsfragen
+
+- Welche Regeln gehören in Code statt Prompt?
+- Wie erkennt der Agent eine Sensorfrage?
+- Welche Antwortlänge passt für Sprache?

01-ai-agent-basics/05-conversation-history-verwalten.md

@@ -0,0 +1,38 @@
+# Aufgabe 05: Conversation History verwalten
+
+## Ziel
+
+Du speicherst und kürzt Dialogverlauf für mehrere Gesprächsrunden.
+
+## Warum ist das wichtig?
+
+Ein sprechender Roboter muss Kontext behalten, ohne das Modellfenster zu überladen.
+
+## Voraussetzungen
+
+- Aufgaben 01-04
+- Grundverständnis Token/Kontext
+
+## Theorie
+
+History ist Arbeitsgedächtnis, kein Archiv. Alte Nachrichten müssen zusammengefasst oder entfernt werden, damit wichtige Fakten erhalten bleiben.
+
+## Aufgabe
+
+Implementiere eine History mit maximaler Nachrichtenanzahl und einfacher Zusammenfassung alter Runden.
+
+## Akzeptanzkriterien
+
+- Mehrere Gesprächsrunden nutzen Kontext.
+- Alte Nachrichten werden begrenzt.
+- Tool-Ergebnisse bleiben nachvollziehbar.
+
+## Erweiterungen
+
+- Speichere Sitzungen mit Session-ID.
+
+## Reflexionsfragen
+
+- Was darf aus der History gelöscht werden?
+- Welche Fakten sind langfristig wichtig?
+- Wie vermeidest du, dass Tool-Logs den Kontext füllen?

01-ai-agent-basics/06-json-tool-schema-definieren.md

@@ -0,0 +1,38 @@
+# Aufgabe 06: JSON Tool Schema definieren
+
+## Ziel
+
+Du beschreibst Robotik-Tools als JSON Schema mit Parametern und Grenzen.
+
+## Warum ist das wichtig?
+
+Das Modell braucht präzise Werkzeugbeschreibungen, damit Hardware- und Sensortools korrekt aufgerufen werden.
+
+## Voraussetzungen
+
+- Aufgaben 03-04
+- JSON Schema Grundlagen
+
+## Theorie
+
+Ein Tool Schema ist ein Vertrag zwischen LLM und Programm. Es beschreibt Name, Zweck, Parameter, erlaubte Werte und Pflichtfelder.
+
+## Aufgabe
+
+Definiere Schemas für `get_time`, `count_people`, `identify_people` und `look`.
+
+## Akzeptanzkriterien
+
+- Alle Tools haben Name, Beschreibung und Parameter.
+- `look` begrenzt Richtungen oder Winkel.
+- Ungültige Argumente werden abweisbar.
+
+## Erweiterungen
+
+- Generiere aus dem Schema eine kurze Markdown-Doku.
+
+## Reflexionsfragen
+
+- Welche Parameter sind gefährlich?
+- Wie eng sollte ein Schema sein?
+- Was passiert bei fehlenden Pflichtfeldern?

01-ai-agent-basics/07-tool-dispatcher-bauen.md

@@ -0,0 +1,38 @@
+# Aufgabe 07: Tool Dispatcher bauen
+
+## Ziel
+
+Du baust einen Dispatcher, der validierte Tool Calls auf lokale Funktionen abbildet.
+
+## Warum ist das wichtig?
+
+Das LLM soll Entscheidungen vorschlagen, aber dein Code führt kontrolliert aus.
+
+## Voraussetzungen
+
+- Aufgabe 06
+- Rust oder Python
+
+## Theorie
+
+Der Dispatcher ist die Sicherheitsgrenze. Er validiert Argumente, ruft Funktionen auf, behandelt Fehler und gibt strukturierte Ergebnisse zurück.
+
+## Aufgabe
+
+Implementiere einen Dispatcher für mindestens vier Fake-Tools und schreibe Tests für gültige und ungültige Aufrufe.
+
+## Akzeptanzkriterien
+
+- Bekannte Tools werden ausgeführt.
+- Unbekannte Tools liefern Fehler.
+- Argumente werden validiert und geloggt.
+
+## Erweiterungen
+
+- Füge Berechtigungslevel für Hardware-Tools hinzu.
+
+## Reflexionsfragen
+
+- Warum sollte das LLM keine Shell ausführen dürfen?
+- Welche Fehler soll der Dispatcher verbergen?
+- Welche Tool-Ergebnisse gehören zurück ins Modell?

01-ai-agent-basics/08-agent-loop-implementieren.md

@@ -0,0 +1,38 @@
+# Aufgabe 08: Agent Loop implementieren
+
+## Ziel
+
+Du baust den Loop User Input -> LLM -> Tool -> LLM -> Antwort.
+
+## Warum ist das wichtig?
+
+Der finale Roboter braucht genau diese Schleife, nur später mit echten Services.
+
+## Voraussetzungen
+
+- Aufgaben 05-07
+- LLM Provider
+
+## Theorie
+
+Ein Agent Loop ist eine kontrollierte Iteration. Er endet bei einer finalen Antwort oder nach einer maximalen Anzahl von Tool-Schritten.
+
+## Aufgabe
+
+Implementiere einen Loop mit maximal drei Tool Calls pro Anfrage, Tool-Ergebnis-Rückgabe und finaler Antwort.
+
+## Akzeptanzkriterien
+
+- Frage nach Uhrzeit nutzt Tool.
+- Frage nach Personen nutzt Fake-Tool.
+- Endlosschleifen werden begrenzt.
+
+## Erweiterungen
+
+- Zeige eine Debug-Ansicht aller Loop-Schritte.
+
+## Reflexionsfragen
+
+- Wann sollte der Loop abbrechen?
+- Wie erkennst du Tool-Spam?
+- Welche Daten sieht das Modell nach einem Tool Call?

01-ai-agent-basics/09-fehlerbehandlung-logging-und-memory.md

@@ -0,0 +1,38 @@
+# Aufgabe 09: Fehlerbehandlung, Logging und Memory
+
+## Ziel
+
+Du ergänzt robuste Fehlerpfade, strukturierte Logs und ein kleines Memory.
+
+## Warum ist das wichtig?
+
+Robotikfehler entstehen an API-, Sensor- und Hardwaregrenzen. Gute Beobachtbarkeit ist Pflicht.
+
+## Voraussetzungen
+
+- Aufgaben 01-08
+- Logging-Grundlagen
+
+## Theorie
+
+Logs beantworten die Frage, was wirklich passiert ist. Memory speichert ausgewählte Fakten, aber keine ungeprüften Halluzinationen.
+
+## Aufgabe
+
+Erweitere den Agenten um strukturierte Logs, Fehlercodes und ein Key-Value-Memory für explizit bestätigte Fakten.
+
+## Akzeptanzkriterien
+
+- Jeder Request hat eine Trace-ID.
+- Tool-Fehler sind sichtbar.
+- Memory kann gelesen und geschrieben werden.
+
+## Erweiterungen
+
+- Füge Log-Level und JSON-Logs hinzu.
+
+## Reflexionsfragen
+
+- Welche Fehler sind wiederholbar?
+- Welche Fakten darf der Agent speichern?
+- Wie würdest du Logs in Docker sammeln?

01-ai-agent-basics/README.md

@@ -0,0 +1,19 @@
+# AI-Agent-Grundlagen
+
+LLM-Zugriff, Nachrichtenmodell, Tool Calling, Agent Loop, Fehlerbehandlung und Memory.
+
+## Aufgaben
+
+- [01: LLM API per CLI ansprechen](01-llm-api-per-cli-ansprechen.md)
+- [02: Ollama und Cloud API vergleichen](02-ollama-und-cloud-api-vergleichen.md)
+- [03: Chat Messages modellieren](03-chat-messages-modellieren.md)
+- [04: System Prompt entwerfen](04-system-prompt-entwerfen.md)
+- [05: Conversation History verwalten](05-conversation-history-verwalten.md)
+- [06: JSON Tool Schema definieren](06-json-tool-schema-definieren.md)
+- [07: Tool Dispatcher bauen](07-tool-dispatcher-bauen.md)
+- [08: Agent Loop implementieren](08-agent-loop-implementieren.md)
+- [09: Fehlerbehandlung, Logging und Memory](09-fehlerbehandlung-logging-und-memory.md)
+
+## Arbeitsweise
+
+Bearbeite die Aufgaben nacheinander. Jede Aufgabe soll ein kleines, überprüfbares Ergebnis liefern und ist bewusst auf etwa 1 bis 4 Stunden ausgelegt.

02-voice-interface/01-mikrofon-aufnehmen-und-speichern.md

@@ -0,0 +1,39 @@
+# Aufgabe 01: Mikrofon aufnehmen und speichern
+
+## Ziel
+
+Du nimmst Audio vom Mikrofon auf und speicherst es als WAV-Datei.
+
+## Warum ist das wichtig?
+
+Speech-to-Text ist nur so gut wie die Audioquelle und deren Format.
+
+## Voraussetzungen
+
+- Mikrofon
+- Python
+- PortAudio oder sounddevice
+
+## Theorie
+
+Audio hat Samplerate, Kanäle, Bit-Tiefe und Pegel. Falsche Formate führen zu schlechter Erkennung oder unnötiger Latenz.
+
+## Aufgabe
+
+Baue ein Skript, das fünf Sekunden Audio aufnimmt, Pegel ausgibt und eine WAV-Datei speichert.
+
+## Akzeptanzkriterien
+
+- WAV-Datei ist abspielbar.
+- Samplerate und Kanalzahl werden angezeigt.
+- Leise oder übersteuerte Aufnahme wird erkannt.
+
+## Erweiterungen
+
+- Füge automatische Normalisierung als Option hinzu.
+
+## Reflexionsfragen
+
+- Welche Samplerate erwartet dein STT-Modell?
+- Woran erkennst du Übersteuerung?
+- Warum ist Mono oft sinnvoll?

02-voice-interface/02-push-to-talk-cli-bauen.md

@@ -0,0 +1,38 @@
+# Aufgabe 02: Push-to-Talk CLI bauen
+
+## Ziel
+
+Du baust eine einfache Push-to-Talk-Bedienung für Terminaltests.
+
+## Warum ist das wichtig?
+
+Daueraufnahme ist beim Entwickeln störend und datenschutzkritisch.
+
+## Voraussetzungen
+
+- Aufgabe 01
+- Terminal
+
+## Theorie
+
+Push-to-Talk reduziert falsche Aktivierungen und macht Tests reproduzierbar. Später kann ein Wake Word ergänzt werden.
+
+## Aufgabe
+
+Implementiere eine CLI, die nur während gedrückter Taste oder zwischen Start/Stopp-Kommandos aufnimmt.
+
+## Akzeptanzkriterien
+
+- Aufnahme startet kontrolliert.
+- Aufnahme endet zuverlässig.
+- Datei oder Buffer wird an die nächste Pipeline-Stufe übergeben.
+
+## Erweiterungen
+
+- Zeige während der Aufnahme einen Pegelindikator.
+
+## Reflexionsfragen
+
+- Warum ist Push-to-Talk am Anfang besser als Wake Word?
+- Welche Taste ist im Terminal praktikabel?
+- Wie verhinderst du versehentliche Daueraufnahme?

02-voice-interface/03-whisper-batch-stt-integrieren.md

@@ -0,0 +1,38 @@
+# Aufgabe 03: Whisper Batch STT integrieren
+
+## Ziel
+
+Du wandelst eine gespeicherte WAV-Datei mit Whisper oder faster-whisper in Text um.
+
+## Warum ist das wichtig?
+
+Der Roboter braucht zuverlässige Transkription, bevor er sinnvoll antworten kann.
+
+## Voraussetzungen
+
+- Aufgaben 01-02
+- Whisper/faster-whisper installiert
+
+## Theorie
+
+Batch-STT verarbeitet einen fertigen Audioclip. Das ist einfacher als Streaming und ideal für erste Pipeline-Tests.
+
+## Aufgabe
+
+Baue `transcribe file.wav`, gib Text, Sprache, Laufzeit und Modellname aus.
+
+## Akzeptanzkriterien
+
+- Eine WAV-Datei wird transkribiert.
+- Laufzeit wird gemessen.
+- Fehler bei fehlender Datei sind verständlich.
+
+## Erweiterungen
+
+- Teste verschiedene Modellgrößen und notiere Qualität/Latenz.
+
+## Reflexionsfragen
+
+- Welche Modellgröße ist lokal realistisch?
+- Wie beeinflusst Raumlärm die Ausgabe?
+- Wann reicht Batch-STT nicht mehr?

02-voice-interface/04-streaming-vs-batch-bewerten.md

@@ -0,0 +1,38 @@
+# Aufgabe 04: Streaming vs Batch bewerten
+
+## Ziel
+
+Du vergleichst eine Batch-Pipeline mit einer einfachen Chunk- oder Streaming-Strategie.
+
+## Warum ist das wichtig?
+
+Für natürliche Dialoge entscheidet Latenz oft stärker als Modellqualität.
+
+## Voraussetzungen
+
+- Aufgabe 03
+- Audio-Grundlagen
+
+## Theorie
+
+Streaming kann früher Zwischenergebnisse liefern, ist aber komplexer. Batch ist robust, wartet aber bis zum Ende der Aufnahme.
+
+## Aufgabe
+
+Miss Ende-zu-Ende-Latenz für kurze und lange Äußerungen und beschreibe, wann du Streaming einführen würdest.
+
+## Akzeptanzkriterien
+
+- Mindestens drei Messungen sind dokumentiert.
+- Batch-Latenz ist von Aufnahmezeit getrennt.
+- Eine Entscheidung für den Kursstand ist begründet.
+
+## Erweiterungen
+
+- Implementiere einen experimentellen Chunk-Transcriber.
+
+## Reflexionsfragen
+
+- Welche Latenz fühlt sich im Dialog noch gut an?
+- Welche Fehler erzeugen unvollständige Chunks?
+- Was würdest du zuerst optimieren?

02-voice-interface/05-text-to-speech-erzeugen.md

@@ -0,0 +1,38 @@
+# Aufgabe 05: Text-to-Speech erzeugen
+
+## Ziel
+
+Du wandelst Text in hörbare Sprache um.
+
+## Warum ist das wichtig?
+
+Antworten müssen gesprochen werden, nicht nur im Terminal erscheinen.
+
+## Voraussetzungen
+
+- Lautsprecher
+- Python TTS oder System-TTS
+
+## Theorie
+
+TTS hat Stimme, Geschwindigkeit, Ausgabeformat und Startlatenz. Für Roboter wirkt eine kurze, klare Antwort natürlicher als lange Absätze.
+
+## Aufgabe
+
+Baue `speak "Text"`, das Audio erzeugt und abspielt oder als Datei speichert.
+
+## Akzeptanzkriterien
+
+- Text wird hörbar ausgegeben.
+- Lange Texte werden begrenzt oder geteilt.
+- TTS-Fehler blockieren den Prozess nicht dauerhaft.
+
+## Erweiterungen
+
+- Teste zwei Stimmen oder Engines.
+
+## Reflexionsfragen
+
+- Welche Antwortlänge passt für TTS?
+- Was passiert bei Sonderzeichen?
+- Wie misst du Startlatenz?

02-voice-interface/06-audio-queue-einfuehren.md

@@ -0,0 +1,38 @@
+# Aufgabe 06: Audio Queue einführen
+
+## Ziel
+
+Du baust eine Queue, damit TTS-Ausgaben geordnet abgespielt werden.
+
+## Warum ist das wichtig?
+
+Der Roboter soll nicht mehrere Antworten gleichzeitig sprechen.
+
+## Voraussetzungen
+
+- Aufgabe 05
+- Nebenläufigkeit Grundlagen
+
+## Theorie
+
+Eine Queue entkoppelt Erzeugung und Wiedergabe. Sie erlaubt Stop, Clear, Priorität und sauberes Shutdown-Verhalten.
+
+## Aufgabe
+
+Implementiere eine Audio-Queue mit Worker, `enqueue`, `stop_current` und `clear`.
+
+## Akzeptanzkriterien
+
+- Zwei Texte werden nacheinander gesprochen.
+- Queue kann geleert werden.
+- Worker beendet sich sauber.
+
+## Erweiterungen
+
+- Füge Priorität für Warnhinweise hinzu.
+
+## Reflexionsfragen
+
+- Wann darf eine neue Antwort alte Sprache abbrechen?
+- Wie verhinderst du Race Conditions?
+- Welche Zustände braucht ein Audio-Player?

02-voice-interface/07-voice-pipeline-verbinden.md

@@ -0,0 +1,38 @@
+# Aufgabe 07: Voice Pipeline verbinden
+
+## Ziel
+
+Du verbindest Mikrofon, STT, LLM-Agent und TTS zu einem manuellen Dialog.
+
+## Warum ist das wichtig?
+
+Das ist der erste komplette Sprachpfad des späteren Roboterkopfs.
+
+## Voraussetzungen
+
+- Aufgaben 02-06
+- Agent aus Modul 01
+
+## Theorie
+
+Pipelines bestehen aus Stufen mit klaren Datenformaten. Jede Stufe muss einzeln testbar bleiben, sonst wird Debugging schwer.
+
+## Aufgabe
+
+Baue einen Ablauf: Push-to-Talk -> STT -> Agent -> TTS. Logge Textzwischenstände und Zeiten.
+
+## Akzeptanzkriterien
+
+- Gesprochene Frage wird beantwortet.
+- Transkript und Antwort werden angezeigt.
+- Jede Stufe hat eine gemessene Dauer.
+
+## Erweiterungen
+
+- Füge einen Textmodus als Fallback hinzu.
+
+## Reflexionsfragen
+
+- Welche Stufe ist am langsamsten?
+- Wo können Datenschutzdaten entstehen?
+- Warum muss jede Stufe separat testbar bleiben?

02-voice-interface/08-wake-word-als-optionaler-prototyp.md

@@ -0,0 +1,38 @@
+# Aufgabe 08: Wake Word als optionaler Prototyp
+
+## Ziel
+
+Du testest ein Wake Word als Alternative zu Push-to-Talk.
+
+## Warum ist das wichtig?
+
+Ein Roboterkopf soll später freihändig nutzbar sein, aber Fehlaktivierungen müssen verstanden werden.
+
+## Voraussetzungen
+
+- Aufgaben 01-07
+- Wake-Word-Bibliothek optional
+
+## Theorie
+
+Wake Words sind Klassifikatoren für kurze Audiosignale. Sie erzeugen False Positives und False Negatives, besonders bei Lärm oder ähnlichen Worten.
+
+## Aufgabe
+
+Baue einen optionalen Prototyp, der nach Aktivierung eine kurze Aufnahme startet, oder dokumentiere bewusst, warum du es noch weglässt.
+
+## Akzeptanzkriterien
+
+- Aktivierung wird sichtbar geloggt.
+- Fehlaktivierungen werden notiert.
+- Push-to-Talk bleibt als Fallback erhalten.
+
+## Erweiterungen
+
+- Miss Wake-Word-CPU-Last.
+
+## Reflexionsfragen
+
+- Welche Fehlaktivierung wäre peinlich oder riskant?
+- Wie informierst du über aktive Aufnahme?
+- Wann lohnt sich Wake Word wirklich?

02-voice-interface/README.md

@@ -0,0 +1,18 @@
+# Voice Interface
+
+Audioaufnahme, Speech-to-Text, Text-to-Speech, Queues und Latenzmessung.
+
+## Aufgaben
+
+- [01: Mikrofon aufnehmen und speichern](01-mikrofon-aufnehmen-und-speichern.md)
+- [02: Push-to-Talk CLI bauen](02-push-to-talk-cli-bauen.md)
+- [03: Whisper Batch STT integrieren](03-whisper-batch-stt-integrieren.md)
+- [04: Streaming vs Batch bewerten](04-streaming-vs-batch-bewerten.md)
+- [05: Text-to-Speech erzeugen](05-text-to-speech-erzeugen.md)
+- [06: Audio Queue einführen](06-audio-queue-einfuehren.md)
+- [07: Voice Pipeline verbinden](07-voice-pipeline-verbinden.md)
+- [08: Wake Word als optionaler Prototyp](08-wake-word-als-optionaler-prototyp.md)
+
+## Arbeitsweise
+
+Bearbeite die Aufgaben nacheinander. Jede Aufgabe soll ein kleines, überprüfbares Ergebnis liefern und ist bewusst auf etwa 1 bis 4 Stunden ausgelegt.

03-computer-vision/01-kamera-oeffnen-und-frames-anzeigen.md

@@ -0,0 +1,39 @@
+# Aufgabe 01: Kamera öffnen und Frames anzeigen
+
+## Ziel
+
+Du öffnest eine Kamera und zeigst Live-Frames an.
+
+## Warum ist das wichtig?
+
+Alle späteren Vision-Funktionen hängen an einem stabilen Kamerazugriff.
+
+## Voraussetzungen
+
+- USB-Kamera oder Laptop-Kamera
+- Python
+- OpenCV
+
+## Theorie
+
+Eine Kamera liefert fortlaufend Frames mit Auflösung, Farbraum und Zeitstempel. Schon hier können Treiber, Berechtigungen und Latenz Probleme machen.
+
+## Aufgabe
+
+Baue `camera-preview`, das Kameraindex, Auflösung und Abbruch per Taste unterstützt.
+
+## Akzeptanzkriterien
+
+- Livebild wird angezeigt.
+- Kameraindex ist konfigurierbar.
+- Programm gibt Ressourcen sauber frei.
+
+## Erweiterungen
+
+- Speichere beim Start ein Diagnosebild.
+
+## Reflexionsfragen
+
+- Welche Auflösung reicht für Personenerkennung?
+- Was passiert bei falschem Kameraindex?
+- Warum muss `release` aufgerufen werden?

03-computer-vision/02-frames-lesen-und-bilder-speichern.md

@@ -0,0 +1,38 @@
+# Aufgabe 02: Frames lesen und Bilder speichern
+
+## Ziel
+
+Du speicherst Einzelbilder kontrolliert aus dem Kamerastream.
+
+## Warum ist das wichtig?
+
+Debugging von Vision-Modellen braucht reproduzierbare Testbilder.
+
+## Voraussetzungen
+
+- Aufgabe 01
+- OpenCV
+
+## Theorie
+
+Ein gespeichertes Frame friert eine Situation ein. Damit kannst du Schwellenwerte und Modelle testen, ohne jedes Mal dieselbe Szene nachzustellen.
+
+## Aufgabe
+
+Erweitere die Preview um Snapshot-Funktion und speichere Bilder mit Timestamp und Metadaten.
+
+## Akzeptanzkriterien
+
+- Ein Tastendruck speichert ein Bild.
+- Dateiname enthält Timestamp.
+- Auflösung und Kameraindex werden protokolliert.
+
+## Erweiterungen
+
+- Speichere zusätzlich ein kleines JSON neben dem Bild.
+
+## Reflexionsfragen
+
+- Welche Metadaten helfen beim Debugging?
+- Warum sind Testbilder sensibel?
+- Wie organisierst du Beispielbilder?

03-computer-vision/03-fps-und-latenz-messen.md

@@ -0,0 +1,38 @@
+# Aufgabe 03: FPS und Latenz messen
+
+## Ziel
+
+Du misst Bildrate und einfache Verarbeitungslatenz.
+
+## Warum ist das wichtig?
+
+Der Roboter muss schnell genug sehen, um den Kopf sinnvoll zu bewegen.
+
+## Voraussetzungen
+
+- Aufgaben 01-02
+- Zeitmessung
+
+## Theorie
+
+FPS beschreibt Durchsatz, Latenz beschreibt Verzögerung. Beide Werte sind verschieden und für Robotik wichtig.
+
+## Aufgabe
+
+Baue eine FPS-Anzeige und miss die Zeit für Lesen, Verarbeiten und Anzeigen pro Frame.
+
+## Akzeptanzkriterien
+
+- FPS wird im Bild oder Terminal angezeigt.
+- Einzelzeiten werden gemessen.
+- Durchschnittswerte über mehrere Sekunden sind sichtbar.
+
+## Erweiterungen
+
+- Exportiere Messungen als CSV.
+
+## Reflexionsfragen
+
+- Warum ist hohe FPS nicht automatisch niedrige Latenz?
+- Welche Verarbeitung ist teuer?
+- Welche FPS reichen für Kopftracking?

03-computer-vision/04-opencv-grundlagen-anwenden.md

@@ -0,0 +1,38 @@
+# Aufgabe 04: OpenCV-Grundlagen anwenden
+
+## Ziel
+
+Du übst Resize, Farbräume, Crops und einfache Filter.
+
+## Warum ist das wichtig?
+
+Viele Modelle erwarten bestimmte Bildformate und Größen.
+
+## Voraussetzungen
+
+- Aufgaben 01-03
+- OpenCV
+
+## Theorie
+
+Computer Vision beginnt oft mit Vorverarbeitung. Resize spart Rechenzeit, Farbräume ändern die Bedeutung von Pixelwerten, Crops reduzieren irrelevante Bereiche.
+
+## Aufgabe
+
+Baue ein Tool, das ein Kamerabild in Graustufen, RGB, HSV, Resize und Crop-Ansicht zeigt.
+
+## Akzeptanzkriterien
+
+- Mindestens drei Transformationen sind umschaltbar.
+- Originalgröße und Ausgabegröße werden angezeigt.
+- Code ist als wiederverwendbare Funktion strukturiert.
+
+## Erweiterungen
+
+- Füge Histogramm-Anzeige hinzu.
+
+## Reflexionsfragen
+
+- Wann verlierst du durch Resize relevante Details?
+- Warum nutzt OpenCV oft BGR?
+- Welche Transformation ist für YOLO unnötig?

03-computer-vision/05-bounding-boxes-zeichnen.md

@@ -0,0 +1,38 @@
+# Aufgabe 05: Bounding Boxes zeichnen
+
+## Ziel
+
+Du zeichnest erkannte Bereiche mit Label und Confidence in Frames.
+
+## Warum ist das wichtig?
+
+Der Roboter muss Vision-Ergebnisse für Menschen und Logs sichtbar machen können.
+
+## Voraussetzungen
+
+- Aufgaben 01-04
+- Koordinatenverständnis
+
+## Theorie
+
+Bounding Boxes übersetzen Modell-Ausgaben in Bildkoordinaten. Saubere Visualisierung hilft, Fehler bei Schwellenwerten und Skalierung zu sehen.
+
+## Aufgabe
+
+Schreibe eine Funktion, die Boxen, Labels und Scores auf ein Bild zeichnet und außerhalb liegende Koordinaten begrenzt.
+
+## Akzeptanzkriterien
+
+- Boxen werden korrekt gezeichnet.
+- Labels bleiben lesbar.
+- Ungültige Koordinaten crashen nicht.
+
+## Erweiterungen
+
+- Füge unterschiedliche Farben pro Klasse hinzu.
+
+## Reflexionsfragen
+
+- Welche Koordinatenformate gibt es?
+- Wie erkennst du vertauschte x/y-Werte?
+- Warum sind Labels in Debugbildern nützlich?

03-computer-vision/06-yolo-oder-detector-integrieren.md

@@ -0,0 +1,38 @@
+# Aufgabe 06: YOLO oder Detector integrieren
+
+## Ziel
+
+Du nutzt ein fertiges Objekterkennungsmodell auf Kamera-Frames.
+
+## Warum ist das wichtig?
+
+Personenzählung und Objektverständnis basieren auf Detektion statt auf reiner Klassifikation.
+
+## Voraussetzungen
+
+- Aufgaben 01-05
+- YOLO/Ultralytics oder OpenCV DNN
+
+## Theorie
+
+Detektoren liefern Klassen, Boxen und Confidence. Sie sind probabilistisch und müssen mit Schwellenwerten interpretiert werden.
+
+## Aufgabe
+
+Integriere ein Modell und zeige erkannte Objekte im Livebild an.
+
+## Akzeptanzkriterien
+
+- Mindestens eine Objektklasse wird erkannt.
+- Confidence wird angezeigt.
+- Modellpfad oder Modellname ist konfigurierbar.
+
+## Erweiterungen
+
+- Teste CPU gegen GPU, falls verfügbar.
+
+## Reflexionsfragen
+
+- Warum reicht Bildklassifikation nicht?
+- Welche Klassen sind für den Roboter nützlich?
+- Wie gehst du mit langsamer Inferenz um?

03-computer-vision/07-personen-zaehlen.md

@@ -0,0 +1,38 @@
+# Aufgabe 07: Personen zählen
+
+## Ziel
+
+Du filterst Detektionen auf Personen und gibst die Anzahl aus.
+
+## Warum ist das wichtig?
+
+Der finale Agent soll Fragen wie "Wie viele Personen sind im Raum?" beantworten.
+
+## Voraussetzungen
+
+- Aufgabe 06
+- Testbilder mit Personen
+
+## Theorie
+
+Zählen ist eine Interpretationsschicht über Detektion. Du musst Klassenfilter, Confidence und doppelte Boxen beachten.
+
+## Aufgabe
+
+Baue `count-people`, das Livebild oder Einzelbild verarbeitet und Anzahl plus Debugbild ausgibt.
+
+## Akzeptanzkriterien
+
+- Personen werden gezählt.
+- Niedrige Confidence wird gefiltert.
+- Debugbild zeigt gezählte Personen.
+
+## Erweiterungen
+
+- Biete `--image` und `--camera` Modi an.
+
+## Reflexionsfragen
+
+- Welche Personen werden übersehen?
+- Wann zählt das System doppelt?
+- Wie erklärst du Unsicherheit in der Antwort?

03-computer-vision/08-confidence-und-nms-verstehen.md

@@ -0,0 +1,37 @@
+# Aufgabe 08: Confidence und NMS verstehen
+
+## Ziel
+
+Du experimentierst mit Confidence Thresholds und Non-Maximum Suppression.
+
+## Warum ist das wichtig?
+
+Falsche oder doppelte Detektionen machen Roboterantworten unglaubwürdig.
+
+## Voraussetzungen
+
+- Aufgaben 06-07
+
+## Theorie
+
+Confidence ist kein Wahrheitswert, sondern Modellvertrauen. NMS entfernt überlappende Boxen, damit ein Objekt nicht mehrfach gezählt wird.
+
+## Aufgabe
+
+Erstelle ein Experiment, das verschiedene Thresholds und NMS-Werte auf denselben Bildern vergleicht.
+
+## Akzeptanzkriterien
+
+- Mindestens drei Thresholds werden verglichen.
+- Doppelte Boxen werden sichtbar reduziert.
+- Entscheidung für Default-Werte ist begründet.
+
+## Erweiterungen
+
+- Visualisiere Ergebnisse als Kontaktbogen.
+
+## Reflexionsfragen
+
+- Warum ist hoher Threshold nicht immer besser?
+- Was passiert bei überlappenden Personen?
+- Welche Antwort sollte der Roboter bei Unsicherheit geben?

03-computer-vision/09-http-vision-service-bauen.md

@@ -0,0 +1,38 @@
+# Aufgabe 09: HTTP Vision Service bauen
+
+## Ziel
+
+Du stellst Personen- und Objektzählung als HTTP-Service bereit.
+
+## Warum ist das wichtig?
+
+Der Agent soll Vision als Tool nutzen, ohne direkt OpenCV-Code zu kennen.
+
+## Voraussetzungen
+
+- Aufgaben 06-08
+- FastAPI oder Axum
+
+## Theorie
+
+Ein Service trennt Vision-Laufzeit von Agent-Logik. Schnittstellen müssen klein, stabil und testbar sein.
+
+## Aufgabe
+
+Baue Endpoints für `/health`, `/vision/people/count` und optional `/vision/objects`.
+
+## Akzeptanzkriterien
+
+- Healthcheck antwortet schnell.
+- Personenanzahl kommt als JSON.
+- Fehler enthalten verständliche Codes.
+
+## Erweiterungen
+
+- Füge Request-ID und einfache Metriken hinzu.
+
+## Reflexionsfragen
+
+- Warum ist HTTP hier einfacher als direkte Imports?
+- Welche Daten sollte der Service nicht zurückgeben?
+- Wie testest du den Endpoint ohne Kamera?

03-computer-vision/README.md

@@ -0,0 +1,19 @@
+# Computer Vision
+
+Kamera, OpenCV, Detektion, Personen zählen und ein HTTP Vision Service.
+
+## Aufgaben
+
+- [01: Kamera öffnen und Frames anzeigen](01-kamera-oeffnen-und-frames-anzeigen.md)
+- [02: Frames lesen und Bilder speichern](02-frames-lesen-und-bilder-speichern.md)
+- [03: FPS und Latenz messen](03-fps-und-latenz-messen.md)
+- [04: OpenCV-Grundlagen anwenden](04-opencv-grundlagen-anwenden.md)
+- [05: Bounding Boxes zeichnen](05-bounding-boxes-zeichnen.md)
+- [06: YOLO oder Detector integrieren](06-yolo-oder-detector-integrieren.md)
+- [07: Personen zählen](07-personen-zaehlen.md)
+- [08: Confidence und NMS verstehen](08-confidence-und-nms-verstehen.md)
+- [09: HTTP Vision Service bauen](09-http-vision-service-bauen.md)
+
+## Arbeitsweise
+
+Bearbeite die Aufgaben nacheinander. Jede Aufgabe soll ein kleines, überprüfbares Ergebnis liefern und ist bewusst auf etwa 1 bis 4 Stunden ausgelegt.

04-face-recognition/01-face-detection-testen.md

@@ -0,0 +1,39 @@
+# Aufgabe 01: Face Detection testen
+
+## Ziel
+
+Du erkennst Gesichter im Kamerabild oder auf Testfotos.
+
+## Warum ist das wichtig?
+
+Face Recognition beginnt mit der Frage, wo überhaupt Gesichter sind.
+
+## Voraussetzungen
+
+- Kamera oder Testbilder
+- Python
+- Face-Detection-Bibliothek
+
+## Theorie
+
+Detection und Recognition sind verschiedene Schritte. Zuerst wird ein Gesicht lokalisiert, erst danach wird es verglichen.
+
+## Aufgabe
+
+Baue ein Skript, das Gesichter markiert und Debugbilder speichert.
+
+## Akzeptanzkriterien
+
+- Gesichter werden mit Box markiert.
+- Mehrere Gesichter sind möglich.
+- Keine-Gesicht-Fall wird sauber behandelt.
+
+## Erweiterungen
+
+- Vergleiche zwei Detector-Varianten.
+
+## Reflexionsfragen
+
+- Wann scheitert Face Detection?
+- Wie beeinflussen Licht und Winkel das Ergebnis?
+- Warum ist Detection nicht gleich Identität?

04-face-recognition/02-face-embeddings-berechnen.md

@@ -0,0 +1,38 @@
+# Aufgabe 02: Face Embeddings berechnen
+
+## Ziel
+
+Du wandelst erkannte Gesichter in numerische Embeddings um.
+
+## Warum ist das wichtig?
+
+Bekannte Personen werden über Ähnlichkeit in einem Vektorraum erkannt.
+
+## Voraussetzungen
+
+- Aufgabe 01
+- Embedding-Modell
+
+## Theorie
+
+Ein Embedding beschreibt ein Gesicht als Vektor. Ähnliche Gesichter liegen näher beieinander, aber der Abstand ist nie eine absolute Identitätsgarantie.
+
+## Aufgabe
+
+Extrahiere Embeddings aus Testbildern und speichere sie mit Metadaten.
+
+## Akzeptanzkriterien
+
+- Embedding-Vektor wird erzeugt.
+- Metadaten enthalten Person, Bild und Datum.
+- Fehlerhafte Crops werden ausgeschlossen.
+
+## Erweiterungen
+
+- Visualisiere Distanzen zwischen Beispielbildern.
+
+## Reflexionsfragen
+
+- Warum speicherst du nicht nur Namen?
+- Was bedeutet Nähe im Vektorraum?
+- Welche Metadaten helfen später?

04-face-recognition/03-bekannte-personen-enrollen.md

@@ -0,0 +1,38 @@
+# Aufgabe 03: Bekannte Personen enrollen
+
+## Ziel
+
+Du baust einen Enrollment-Prozess für bekannte Personen mit Einwilligung.
+
+## Warum ist das wichtig?
+
+Der Roboter soll bekannte Menschen begrüßen, aber nur mit bewusst angelegten Daten.
+
+## Voraussetzungen
+
+- Aufgaben 01-02
+- Consent-Regeln aus Modul 00
+
+## Theorie
+
+Enrollment ist ein kontrollierter Datenerfassungsprozess. Mehrere Bilder pro Person erhöhen Robustheit, müssen aber verantwortungsvoll gespeichert werden.
+
+## Aufgabe
+
+Implementiere `enroll-person NAME`, nimm mehrere Bilder auf, berechne Embeddings und speichere ein Profil.
+
+## Akzeptanzkriterien
+
+- Mehrere Samples pro Person werden gespeichert.
+- Consent-Hinweis ist dokumentiert.
+- Bestehende Profile werden nicht versehentlich überschrieben.
+
+## Erweiterungen
+
+- Füge `delete-person NAME` hinzu.
+
+## Reflexionsfragen
+
+- Wie viele Samples sind sinnvoll?
+- Wie erklärst du die Speicherung?
+- Was muss beim Löschen entfernt werden?

04-face-recognition/04-unbekannte-personen-erkennen.md

@@ -0,0 +1,37 @@
+# Aufgabe 04: Unbekannte Personen erkennen
+
+## Ziel
+
+Du vergleichst neue Gesichter gegen bekannte Profile und gibst bekannt oder unbekannt zurück.
+
+## Warum ist das wichtig?
+
+Der Agent braucht eine ehrliche Antwort: erkannt, unbekannt oder unsicher.
+
+## Voraussetzungen
+
+- Aufgaben 02-03
+
+## Theorie
+
+Recognition ist ein Ähnlichkeitsvergleich mit Schwelle. Zu niedrige Schwellen erzeugen False Positives, zu hohe Schwellen übersehen bekannte Personen.
+
+## Aufgabe
+
+Baue `recognize-faces`, das Namen, Distanz und Status für jedes Gesicht ausgibt.
+
+## Akzeptanzkriterien
+
+- Bekannte Person wird mit Distanz ausgegeben.
+- Unbekannte Person bleibt unbekannt.
+- Unsichere Fälle werden nicht als sicher behauptet.
+
+## Erweiterungen
+
+- Gib Top-3 Kandidaten im Debugmodus aus.
+
+## Reflexionsfragen
+
+- Warum ist "unsicher" ein wichtiger Status?
+- Welche Schwelle erzeugt False Positives?
+- Wie sollte der Roboter höflich antworten?

04-face-recognition/05-schwellenwerte-und-false-positives-testen.md

@@ -0,0 +1,38 @@
+# Aufgabe 05: Schwellenwerte und False Positives testen
+
+## Ziel
+
+Du misst, wie sich Ähnlichkeitsschwellen auf Treffer und Fehler auswirken.
+
+## Warum ist das wichtig?
+
+Falsche Identifikation ist sozial und datenschutzrechtlich heikler als keine Identifikation.
+
+## Voraussetzungen
+
+- Aufgaben 03-04
+- Testbilder verschiedener Personen
+
+## Theorie
+
+Schwellenwerte sind Produktentscheidungen, nicht nur Technik. Du musst wählen, ob das System vorsichtig oder aggressiv erkennt.
+
+## Aufgabe
+
+Erstelle ein kleines Testset und vergleiche mehrere Schwellenwerte mit einer Ergebnis-Tabelle.
+
+## Akzeptanzkriterien
+
+- False Positives und False Negatives werden gezählt.
+- Eine Default-Schwelle ist begründet.
+- Unsicherheitsbereich ist definiert.
+
+## Erweiterungen
+
+- Füge ROC-ähnliche Visualisierung hinzu.
+
+## Reflexionsfragen
+
+- Welcher Fehler ist schlimmer?
+- Wie wirkt schlechtes Licht auf Distanzen?
+- Wann sollte der Roboter nachfragen?

04-face-recognition/06-face-recognition-service-bauen.md

@@ -0,0 +1,38 @@
+# Aufgabe 06: Face Recognition Service bauen
+
+## Ziel
+
+Du stellst Enrollment und Recognition als HTTP-Service bereit.
+
+## Warum ist das wichtig?
+
+Der Agent soll Personenidentifikation als klar begrenztes Tool aufrufen.
+
+## Voraussetzungen
+
+- Aufgaben 03-05
+- FastAPI oder Axum
+
+## Theorie
+
+Ein eigener Service kapselt Modellabhängigkeiten und Datenschutzregeln. Er kann später ersetzt werden, ohne den Agenten umzubauen.
+
+## Aufgabe
+
+Baue Endpoints für `/health`, `/faces/enroll`, `/faces/recognize` und `/faces/profiles`.
+
+## Akzeptanzkriterien
+
+- Healthcheck funktioniert.
+- Recognition liefert strukturierte JSON-Ergebnisse.
+- Enrollment validiert Name und Consent-Flag.
+
+## Erweiterungen
+
+- Füge Zugriffsschutz für Enrollment hinzu.
+
+## Reflexionsfragen
+
+- Welche Endpoints sind gefährlich?
+- Welche Rohdaten sollten nie im Response landen?
+- Wie testest du ohne echte Kamera?

04-face-recognition/07-agent-tool-identify-people-integrieren.md

@@ -0,0 +1,37 @@
+# Aufgabe 07: Agent Tool identify_people integrieren
+
+## Ziel
+
+Du verbindest den Face-Service mit dem Agenten als Tool `identify_people`.
+
+## Warum ist das wichtig?
+
+Der finale Roboter soll auf Fragen nach bekannten Personen datenbasiert antworten.
+
+## Voraussetzungen
+
+- Aufgaben 06 und Modul 01 Aufgabe 08
+
+## Theorie
+
+Das Tool liefert strukturierte Beobachtungen. Das LLM formuliert daraus eine natürliche Antwort, darf aber keine Identität erfinden.
+
+## Aufgabe
+
+Ergänze das Tool Schema, den Dispatcher und einen Prompt-Test für "Erkennst du jemanden?".
+
+## Akzeptanzkriterien
+
+- Tool Call ruft den Service auf.
+- Unbekannte und unsichere Personen werden korrekt formuliert.
+- Fehler des Services werden freundlich erklärt.
+
+## Erweiterungen
+
+- Lass den Agenten bekannte Personen begrüßen.
+
+## Reflexionsfragen
+
+- Welche Formulierung passt bei Unsicherheit?
+- Was darf das LLM nicht dazuerfinden?
+- Wie begrenzt du Identifikationsanfragen?

04-face-recognition/README.md

@@ -0,0 +1,17 @@
+# Face Recognition
+
+Gesichter erkennen, Embeddings, Enrollment, Schwellenwerte, Datenschutz und Agent-Integration.
+
+## Aufgaben
+
+- [01: Face Detection testen](01-face-detection-testen.md)
+- [02: Face Embeddings berechnen](02-face-embeddings-berechnen.md)
+- [03: Bekannte Personen enrollen](03-bekannte-personen-enrollen.md)
+- [04: Unbekannte Personen erkennen](04-unbekannte-personen-erkennen.md)
+- [05: Schwellenwerte und False Positives testen](05-schwellenwerte-und-false-positives-testen.md)
+- [06: Face Recognition Service bauen](06-face-recognition-service-bauen.md)
+- [07: Agent Tool identify_people integrieren](07-agent-tool-identify-people-integrieren.md)
+
+## Arbeitsweise
+
+Bearbeite die Aufgaben nacheinander. Jede Aufgabe soll ein kleines, überprüfbares Ergebnis liefern und ist bewusst auf etwa 1 bis 4 Stunden ausgelegt.

05-robot-motion/01-servo-grundlagen-verstehen.md

@@ -0,0 +1,39 @@
+# Aufgabe 01: Servo-Grundlagen verstehen
+
+## Ziel
+
+Du steuerst einen einzelnen Servo sicher in wenige Testpositionen.
+
+## Warum ist das wichtig?
+
+Der Roboterkopf bewegt reale Mechanik; Fehler können Bauteile beschädigen.
+
+## Voraussetzungen
+
+- Servo
+- geeignete Stromversorgung
+- Raspberry Pi/PCA9685 oder Simulator
+
+## Theorie
+
+Servos werden über PWM-Signale positioniert. Sie ziehen unter Last deutlich mehr Strom als ein GPIO liefern kann.
+
+## Aufgabe
+
+Baue einen minimalen Test, der Mitte, links und rechts anfährt oder im Simulator ausgibt.
+
+## Akzeptanzkriterien
+
+- Servo bewegt sich kontrolliert oder Simulation zeigt Werte.
+- Stromversorgung ist dokumentiert.
+- Winkel bleiben in sicherem Bereich.
+
+## Erweiterungen
+
+- Miss Stromaufnahme unter Last, falls möglich.
+
+## Reflexionsfragen
+
+- Warum darf ein Servo nicht direkt aus jedem Pin versorgt werden?
+- Was ist die Neutralposition?
+- Welche Bewegung wäre mechanisch riskant?

05-robot-motion/02-pwm-und-winkel-kalibrieren.md

@@ -0,0 +1,38 @@
+# Aufgabe 02: PWM und Winkel kalibrieren
+
+## Ziel
+
+Du ermittelst die Pulsbreiten oder Controllerwerte für reale Winkel.
+
+## Warum ist das wichtig?
+
+Jeder Servo und jede Mechanik hat eigene Grenzen.
+
+## Voraussetzungen
+
+- Aufgabe 01
+- Lineal oder Winkelmarkierung
+
+## Theorie
+
+PWM-Werte sind nicht automatisch Gradwerte. Kalibrierung verbindet Softwarekoordinaten mit realer Mechanik.
+
+## Aufgabe
+
+Erstelle eine Kalibrierdatei mit min, max, center und optional invert pro Achse.
+
+## Akzeptanzkriterien
+
+- Grenzwerte sind sicher getestet.
+- Center-Position ist reproduzierbar.
+- Config wird vom Testprogramm geladen.
+
+## Erweiterungen
+
+- Baue einen interaktiven Kalibriermodus.
+
+## Reflexionsfragen
+
+- Warum sind Herstellerwerte nur Startpunkte?
+- Wie erkennst du mechanischen Anschlag?
+- Warum ist Invert pro Achse nützlich?

05-robot-motion/03-stromversorgung-und-not-aus-planen.md

@@ -0,0 +1,38 @@
+# Aufgabe 03: Stromversorgung und Not-Aus planen
+
+## Ziel
+
+Du baust Sicherheitsregeln für Servo-Strom und Abschaltung.
+
+## Warum ist das wichtig?
+
+Instabile Stromversorgung verursacht Resets, Zittern und gefährliche Bewegungen.
+
+## Voraussetzungen
+
+- Aufgaben 01-02
+- Grundwissen Elektrik
+
+## Theorie
+
+Motoren sind elektrische Lasten mit Spitzenströmen. Gemeinsame Masse, externe Versorgung und Sicherungen sind praktische Grundregeln.
+
+## Aufgabe
+
+Dokumentiere Verdrahtung, Strombudget, gemeinsame Masse und eine Not-Aus-Strategie.
+
+## Akzeptanzkriterien
+
+- Strombedarf pro Servo ist geschätzt.
+- Gemeinsame Masse ist erklärt.
+- Not-Aus oder Software-Disable ist definiert.
+
+## Erweiterungen
+
+- Füge eine Sicherung oder Schalter in den Plan ein.
+
+## Reflexionsfragen
+
+- Was passiert bei zu schwachem Netzteil?
+- Warum braucht Signal eine gemeinsame Masse?
+- Wie hältst du die Mechanik bei Softwarecrash sicher?

05-robot-motion/04-pan-tilt-kopf-montieren.md

@@ -0,0 +1,38 @@
+# Aufgabe 04: Pan-Tilt-Kopf montieren
+
+## Ziel
+
+Du montierst zwei Achsen und definierst ein Koordinatensystem.
+
+## Warum ist das wichtig?
+
+Pan und Tilt sind die sichtbare Körperlichkeit des Roboterkopfs.
+
+## Voraussetzungen
+
+- Aufgaben 01-03
+- Pan-Tilt-Halterung
+
+## Theorie
+
+Ein Koordinatensystem verhindert Verwirrung: Pan links/rechts, Tilt hoch/runter, Center als ruhige Ausgangslage.
+
+## Aufgabe
+
+Montiere oder simuliere den Kopf und schreibe Kommandos für center, left, right, up und down.
+
+## Akzeptanzkriterien
+
+- Alle Grundrichtungen funktionieren.
+- Koordinaten sind dokumentiert.
+- Center ist sicher und wiederholbar.
+
+## Erweiterungen
+
+- Füge ein kleines CLI-Menü hinzu.
+
+## Reflexionsfragen
+
+- Welche Richtung ist positiv?
+- Wie groß darf Tilt werden?
+- Welche Kabelbewegung begrenzt Pan?

05-robot-motion/05-sichere-winkelbereiche-erzwingen.md

@@ -0,0 +1,37 @@
+# Aufgabe 05: Sichere Winkelbereiche erzwingen
+
+## Ziel
+
+Du kapselst Winkelbegrenzung zentral in Code und Config.
+
+## Warum ist das wichtig?
+
+Das LLM oder ein Bug darf keine gefährlichen Servopositionen direkt auslösen.
+
+## Voraussetzungen
+
+- Aufgabe 04
+
+## Theorie
+
+Sicherheitsgrenzen gehören in die unterste Motion-Schicht. Höhere Schichten dürfen nur innerhalb dieser Grenzen arbeiten.
+
+## Aufgabe
+
+Implementiere `clamp_angle` oder einen Motion-Controller, der alle Zielwinkel validiert und begrenzt.
+
+## Akzeptanzkriterien
+
+- Zu große Winkel werden begrenzt oder abgelehnt.
+- Grenzen kommen aus Config.
+- Tests decken Grenzfälle ab.
+
+## Erweiterungen
+
+- Unterscheide harte Fehler und sanftes Clamping.
+
+## Reflexionsfragen
+
+- Wo sollte die Sicherheitsgrenze liegen?
+- Wann ist Ablehnen besser als Clamping?
+- Wie loggst du gefährliche Befehle?

05-robot-motion/06-sanfte-bewegungen-implementieren.md

@@ -0,0 +1,37 @@
+# Aufgabe 06: Sanfte Bewegungen implementieren
+
+## Ziel
+
+Du bewegst den Kopf in kleinen Schritten statt mit abrupten Sprüngen.
+
+## Warum ist das wichtig?
+
+Ruckartige Bewegungen wirken schlecht und belasten Mechanik und Stromversorgung.
+
+## Voraussetzungen
+
+- Aufgaben 04-05
+
+## Theorie
+
+Motion Profiles beschreiben Geschwindigkeit und Beschleunigung. Schon lineare Schritte sind besser als direkte Sprünge.
+
+## Aufgabe
+
+Baue eine Funktion `move_to(pan, tilt, duration_ms)`, die Zwischenpositionen erzeugt.
+
+## Akzeptanzkriterien
+
+- Bewegung ist sichtbar sanfter.
+- Dauer ist konfigurierbar.
+- Neue Ziele können kontrolliert behandelt werden.
+
+## Erweiterungen
+
+- Teste Ease-in/ease-out.
+
+## Reflexionsfragen
+
+- Warum sind Sprünge problematisch?
+- Wie reagierst du auf neue Befehle während Bewegung?
+- Welche Geschwindigkeit wirkt angenehm?

05-robot-motion/07-motion-api-bereitstellen.md

@@ -0,0 +1,38 @@
+# Aufgabe 07: Motion API bereitstellen
+
+## Ziel
+
+Du stellst Kopfbewegungen als lokalen Service bereit.
+
+## Warum ist das wichtig?
+
+Der Agent soll Motion als Tool nutzen, ohne Servo-Code zu importieren.
+
+## Voraussetzungen
+
+- Aufgaben 05-06
+- HTTP-Grundlagen
+
+## Theorie
+
+Eine Motion API ist eine Hardwaregrenze. Sie validiert, begrenzt und kann im Simulationsmodus laufen.
+
+## Aufgabe
+
+Baue `/health`, `/motion/head/look`, `/motion/head/center` und `/motion/head/state`.
+
+## Akzeptanzkriterien
+
+- Look akzeptiert nur sichere Ziele.
+- State liefert aktuelle Position.
+- Simulationsmodus funktioniert ohne Hardware.
+
+## Erweiterungen
+
+- Füge Auth oder Localhost-Beschränkung hinzu.
+
+## Reflexionsfragen
+
+- Welche Befehle dürfen remote erreichbar sein?
+- Warum ist Simulationsmodus wichtig?
+- Welche Zustände braucht die API?

05-robot-motion/08-agent-tool-look-integrieren.md

@@ -0,0 +1,38 @@
+# Aufgabe 08: Agent Tool look integrieren
+
+## Ziel
+
+Du verbindest die Motion API mit dem Agenten-Tool `look`.
+
+## Warum ist das wichtig?
+
+Sprachbefehle wie "Schau nach links" sollen kontrolliert Hardware bewegen.
+
+## Voraussetzungen
+
+- Aufgabe 07
+- Modul 01 Aufgabe 08
+
+## Theorie
+
+Das LLM interpretiert Sprache, aber die Motion-Schicht entscheidet über erlaubte Zielwerte. Natürliche Richtungen werden auf sichere Winkel übersetzt.
+
+## Aufgabe
+
+Ergänze Tool Schema und Dispatcher für `look(direction)` mit left, right, up, down, center.
+
+## Akzeptanzkriterien
+
+- Sprachbefehl löst Motion API aus.
+- Ungültige Richtung wird abgelehnt.
+- Agent bestätigt kurz die Bewegung.
+
+## Erweiterungen
+
+- Erlaube relative Winkel im Debugmodus.
+
+## Reflexionsfragen
+
+- Welche Wörter mapst du auf Richtungen?
+- Was passiert bei widersprüchlichen Befehlen?
+- Wie bestätigst du Bewegung knapp per Sprache?

05-robot-motion/09-person-im-bild-zentrieren.md

@@ -0,0 +1,37 @@
+# Aufgabe 09: Person im Bild zentrieren
+
+## Ziel
+
+Du nutzt Vision-Boxen, um den Kopf langsam auf eine Person auszurichten.
+
+## Warum ist das wichtig?
+
+Der Roboter wirkt präsenter, wenn er Personen im Bild verfolgen kann.
+
+## Voraussetzungen
+
+- Aufgaben Modul 03 Aufgabe 07 und Modul 05 Aufgabe 06
+
+## Theorie
+
+Zentrierung ist eine einfache Regelung: Fehler zwischen Bildmitte und Boxmitte wird in Pan/Tilt-Korrektur übersetzt.
+
+## Aufgabe
+
+Implementiere einen Prototyp, der eine erkannte Person auswählt und kleine Pan/Tilt-Korrekturen ausgibt oder ausführt.
+
+## Akzeptanzkriterien
+
+- Boxmitte wird berechnet.
+- Korrektur bleibt begrenzt.
+- Bei keiner Person fährt der Kopf nicht hektisch.
+
+## Erweiterungen
+
+- Füge Totzone gegen Zittern hinzu.
+
+## Reflexionsfragen
+
+- Warum braucht Tracking eine Totzone?
+- Welche Person wählst du bei mehreren?
+- Wie verhinderst du Oszillation?

05-robot-motion/README.md

@@ -0,0 +1,19 @@
+# Robot Motion
+
+Servo-Grundlagen, PWM, Pan-Tilt-Mechanik, Motion API und visuelles Zentrieren.
+
+## Aufgaben
+
+- [01: Servo-Grundlagen verstehen](01-servo-grundlagen-verstehen.md)
+- [02: PWM und Winkel kalibrieren](02-pwm-und-winkel-kalibrieren.md)
+- [03: Stromversorgung und Not-Aus planen](03-stromversorgung-und-not-aus-planen.md)
+- [04: Pan-Tilt-Kopf montieren](04-pan-tilt-kopf-montieren.md)
+- [05: Sichere Winkelbereiche erzwingen](05-sichere-winkelbereiche-erzwingen.md)
+- [06: Sanfte Bewegungen implementieren](06-sanfte-bewegungen-implementieren.md)
+- [07: Motion API bereitstellen](07-motion-api-bereitstellen.md)
+- [08: Agent Tool look integrieren](08-agent-tool-look-integrieren.md)
+- [09: Person im Bild zentrieren](09-person-im-bild-zentrieren.md)
+
+## Arbeitsweise
+
+Bearbeite die Aufgaben nacheinander. Jede Aufgabe soll ein kleines, überprüfbares Ergebnis liefern und ist bewusst auf etwa 1 bis 4 Stunden ausgelegt.

06-system-architecture/01-service-schnitt-entwerfen.md

@@ -0,0 +1,37 @@
+# Aufgabe 01: Service-Schnitt entwerfen
+
+## Ziel
+
+Du entscheidest, welche Komponenten eigene Services werden.
+
+## Warum ist das wichtig?
+
+AI, Voice, Vision und Motion haben unterschiedliche Laufzeiten, Risiken und Abhängigkeiten.
+
+## Voraussetzungen
+
+- Module 01-05 überblicken
+
+## Theorie
+
+Mehrere Services erhöhen Komplexität, begrenzen aber Fehler. Vision kann abstürzen, ohne den Agenten komplett mitzunehmen.
+
+## Aufgabe
+
+Zeichne eine Service-Architektur mit Agent/Orchestrator, Voice, Vision, Face und Motion.
+
+## Akzeptanzkriterien
+
+- Alle Services haben klare Verantwortungen.
+- Datenflüsse sind beschriftet.
+- Fehlergrenzen sind markiert.
+
+## Erweiterungen
+
+- Ergänze Ports und Protokolle.
+
+## Reflexionsfragen
+
+- Welche Komponente darf Hardware berühren?
+- Wo entstehen personenbezogene Daten?
+- Welcher Service ist kritisch für Sicherheit?

06-system-architecture/02-rust-orchestrator-skizzieren.md

@@ -0,0 +1,38 @@
+# Aufgabe 02: Rust Orchestrator skizzieren
+
+## Ziel
+
+Du entwirfst den zentralen Orchestrator für Dialog, Tools und State.
+
+## Warum ist das wichtig?
+
+Rust eignet sich gut für robuste Service-Logik, Konfiguration und kontrollierte Nebenläufigkeit.
+
+## Voraussetzungen
+
+- Modul 01 abgeschlossen
+- Rust Grundlagen
+
+## Theorie
+
+Der Orchestrator ist nicht das Modell, sondern der Koordinator. Er ruft Services auf, validiert Ergebnisse und hält Session-State.
+
+## Aufgabe
+
+Lege ein Rust-Projekt oder eine Architektur-Skizze mit Modulen für config, tools, agent, state und clients an.
+
+## Akzeptanzkriterien
+
+- Module sind klar benannt.
+- Externe Services werden über Clients gekapselt.
+- Config ist getrennt vom Code.
+
+## Erweiterungen
+
+- Baue einen `/health` Endpoint.
+
+## Reflexionsfragen
+
+- Welche Logik gehört nicht in Python-Skripte?
+- Was muss synchron und was asynchron sein?
+- Wie testest du Service-Clients?

06-system-architecture/03-python-vision-service-isolieren.md

@@ -0,0 +1,37 @@
+# Aufgabe 03: Python Vision Service isolieren
+
+## Ziel
+
+Du kapselst OpenCV/Modelle in einem eigenen Servicevertrag.
+
+## Warum ist das wichtig?
+
+AI- und CV-Bibliotheken ändern sich schnell und sollten den Orchestrator nicht belasten.
+
+## Voraussetzungen
+
+- Modul 03 Aufgabe 09
+
+## Theorie
+
+Python ist hier praktisch, weil Modelle und Bibliotheken gut verfügbar sind. Der Vertrag nach außen sollte trotzdem stabil und klein bleiben.
+
+## Aufgabe
+
+Definiere Request/Response-Modelle für Vision und schreibe einen Client-Stub im Orchestrator.
+
+## Akzeptanzkriterien
+
+- Schema enthält Count und optional Detections.
+- Orchestrator kennt keine OpenCV-Typen.
+- Fehler werden in Codes übersetzt.
+
+## Erweiterungen
+
+- Generiere OpenAPI-Doku.
+
+## Reflexionsfragen
+
+- Warum ist ein kleines JSON besser als Rohframes?
+- Welche Modellinfos sind im Response nützlich?
+- Was passiert bei kaltem Modellstart?

06-system-architecture/04-voice-service-abgrenzen.md

@@ -0,0 +1,37 @@
+# Aufgabe 04: Voice Service abgrenzen
+
+## Ziel
+
+Du trennst Audioaufnahme, STT und TTS von Agent-Logik.
+
+## Warum ist das wichtig?
+
+Audio hat eigene Geräte, Threads und Latenzprobleme.
+
+## Voraussetzungen
+
+- Modul 02 Aufgabe 07
+
+## Theorie
+
+Voice kann als Prozess, Service oder lokale Bibliothek laufen. Wichtig ist eine klare Grenze zwischen gesprochenem Text und Dialogentscheidung.
+
+## Aufgabe
+
+Definiere eine Voice-Schnittstelle mit `listen`, `speak`, Status und Fehlerfällen.
+
+## Akzeptanzkriterien
+
+- STT und TTS sind als Operationen getrennt.
+- Aktive Aufnahme ist erkennbar.
+- Orchestrator bekommt Text statt Audio.
+
+## Erweiterungen
+
+- Füge Queue-Status hinzu.
+
+## Reflexionsfragen
+
+- Welche Audio-Daten müssen den Prozess verlassen?
+- Wie gehst du mit TTS-Abbruch um?
+- Wann ist ein lokaler Prozess besser als HTTP?

06-system-architecture/05-rest-grpc-und-mqtt-vergleichen.md

@@ -0,0 +1,38 @@
+# Aufgabe 05: REST, gRPC und MQTT vergleichen
+
+## Ziel
+
+Du bewertest Kommunikationsformen für die Roboterarchitektur.
+
+## Warum ist das wichtig?
+
+Nicht jedes Protokoll passt zu jedem Datenfluss.
+
+## Voraussetzungen
+
+- Module 01-05
+- Grundwissen Netzwerk
+
+## Theorie
+
+REST ist einfach für Request/Response, gRPC typisiert stärker, MQTT passt gut zu Events und lose gekoppelten Sensoren.
+
+## Aufgabe
+
+Erstelle eine Entscheidungstabelle für Tools, Events, Telemetrie und Streaming.
+
+## Akzeptanzkriterien
+
+- REST, gRPC und MQTT werden verglichen.
+- Mindestens drei konkrete Roboterfälle sind bewertet.
+- Eine Startentscheidung ist festgelegt.
+
+## Erweiterungen
+
+- Implementiere einen kleinen REST- und MQTT-Prototyp.
+
+## Reflexionsfragen
+
+- Welche Calls brauchen Antwort?
+- Welche Daten sind Events?
+- Wo ist Streaming wirklich nötig?

06-system-architecture/06-event-basierte-kommunikation-einfuehren.md

@@ -0,0 +1,37 @@
+# Aufgabe 06: Event-basierte Kommunikation einführen
+
+## Ziel
+
+Du modellierst Ereignisse wie PersonDetected, SpeechStarted und MotionCompleted.
+
+## Warum ist das wichtig?
+
+Events helfen, Zustände zu beobachten, ohne jede Komponente direkt zu koppeln.
+
+## Voraussetzungen
+
+- Aufgabe 05
+
+## Theorie
+
+Events beschreiben, dass etwas passiert ist. Commands fordern etwas an. Diese Trennung verhindert viele Architekturfehler.
+
+## Aufgabe
+
+Definiere ein kleines Event-Schema und baue einen lokalen Event-Bus oder eine In-Memory-PubSub-Simulation.
+
+## Akzeptanzkriterien
+
+- Mindestens fünf Events sind definiert.
+- Commands und Events sind getrennt.
+- Logs zeigen Event-Reihenfolge.
+
+## Erweiterungen
+
+- Nutze MQTT oder NATS als Experiment.
+
+## Reflexionsfragen
+
+- Warum ist `LookLeft` kein Event?
+- Welche Events sind personenbezogen?
+- Wie vermeidest du Event-Flut?

06-system-architecture/07-docker-compose-fuer-services.md

@@ -0,0 +1,38 @@
+# Aufgabe 07: Docker Compose für Services
+
+## Ziel
+
+Du startest mehrere Services reproduzierbar zusammen.
+
+## Warum ist das wichtig?
+
+Der finale Roboter besteht aus mehreren Prozessen, die gemeinsam laufen müssen.
+
+## Voraussetzungen
+
+- Aufgaben 02-06
+- Docker Grundlagen
+
+## Theorie
+
+Compose ist kein Produktionsorchester, aber sehr gut für lokale Entwicklung. Es dokumentiert Ports, Umgebungsvariablen und Startreihenfolge.
+
+## Aufgabe
+
+Erstelle eine Compose-Datei für Orchestrator, Vision, Face und optional Voice im Mockmodus.
+
+## Akzeptanzkriterien
+
+- Services starten mit einem Befehl.
+- Healthchecks sind definiert.
+- Volumes für Modelle/Daten sind bewusst gewählt.
+
+## Erweiterungen
+
+- Füge Profile für hardware und mock hinzu.
+
+## Reflexionsfragen
+
+- Welche Services brauchen Gerätezugriff?
+- Was gehört nicht ins Image?
+- Wie startest du nur einen Teil des Systems?

06-system-architecture/08-config-management-strukturieren.md

@@ -0,0 +1,37 @@
+# Aufgabe 08: Config Management strukturieren
+
+## Ziel
+
+Du verwaltest Ports, Modellnamen, Grenzwerte und Secrets sauber.
+
+## Warum ist das wichtig?
+
+Hartkodierte Werte machen Robotiktests fehleranfällig.
+
+## Voraussetzungen
+
+- Aufgaben 02-07
+
+## Theorie
+
+Konfiguration hat Schichten: Defaults, Datei, Umgebungsvariablen und Secrets. Sicherheitsgrenzen sollten sichtbar und versioniert sein, Secrets nicht.
+
+## Aufgabe
+
+Definiere ein Config-Format und lade es in mindestens einem Service.
+
+## Akzeptanzkriterien
+
+- Ports und URLs kommen aus Config.
+- Servo-Grenzen sind konfigurierbar.
+- Secrets werden nicht committet.
+
+## Erweiterungen
+
+- Füge Config-Validierung beim Start hinzu.
+
+## Reflexionsfragen
+
+- Welche Werte ändern sich pro Maschine?
+- Welche Defaults sind gefährlich?
+- Wie dokumentierst du Secrets ohne sie zu speichern?

06-system-architecture/09-observability-und-health-checks.md

@@ -0,0 +1,37 @@
+# Aufgabe 09: Observability und Health Checks
+
+## Ziel
+
+Du baust Logs, Healthchecks und einfache Metriken über Services hinweg.
+
+## Warum ist das wichtig?
+
+Ohne Beobachtbarkeit wird ein integrierter Roboter kaum debuggbar.
+
+## Voraussetzungen
+
+- Aufgaben 07-08
+
+## Theorie
+
+Health sagt, ob ein Service grundsätzlich lebt. Logs erklären Abläufe. Metriken zeigen Trends wie Latenz, FPS und Fehlerhäufigkeit.
+
+## Aufgabe
+
+Ergänze strukturierte Logs, `/health` und mindestens drei Metriken im Architekturplan oder Prototyp.
+
+## Akzeptanzkriterien
+
+- Jeder Service hat Healthcheck.
+- Logs enthalten Request-ID.
+- Latenz wird pro Tool Call gemessen.
+
+## Erweiterungen
+
+- Füge Tracing über mehrere Services hinzu.
+
+## Reflexionsfragen
+
+- Welche Metrik zeigt schlechte Nutzererfahrung?
+- Welche Logs enthalten sensible Daten?
+- Wie korrelierst du einen Sprachbefehl mit Motion?

06-system-architecture/README.md

@@ -0,0 +1,19 @@
+# Systemarchitektur
+
+Service-Schnitt, Rust-Orchestrator, Python-Services, Kommunikation, Konfiguration und Betrieb.
+
+## Aufgaben
+
+- [01: Service-Schnitt entwerfen](01-service-schnitt-entwerfen.md)
+- [02: Rust Orchestrator skizzieren](02-rust-orchestrator-skizzieren.md)
+- [03: Python Vision Service isolieren](03-python-vision-service-isolieren.md)
+- [04: Voice Service abgrenzen](04-voice-service-abgrenzen.md)
+- [05: REST, gRPC und MQTT vergleichen](05-rest-grpc-und-mqtt-vergleichen.md)
+- [06: Event-basierte Kommunikation einführen](06-event-basierte-kommunikation-einfuehren.md)
+- [07: Docker Compose für Services](07-docker-compose-fuer-services.md)
+- [08: Config Management strukturieren](08-config-management-strukturieren.md)
+- [09: Observability und Health Checks](09-observability-und-health-checks.md)
+
+## Arbeitsweise
+
+Bearbeite die Aufgaben nacheinander. Jede Aufgabe soll ein kleines, überprüfbares Ergebnis liefern und ist bewusst auf etwa 1 bis 4 Stunden ausgelegt.

07-ros2-basics/01-ros2-zweck-einordnen.md

@@ -0,0 +1,38 @@
+# Aufgabe 01: ROS2 Zweck einordnen
+
+## Ziel
+
+Du verstehst, was ROS2 löst und was es nicht automatisch löst.
+
+## Warum ist das wichtig?
+
+ROS2 ist mächtig, aber für frühe AI-Prototypen nicht immer der beste Startpunkt.
+
+## Voraussetzungen
+
+- Linux
+- Grundwissen Services
+
+## Theorie
+
+ROS2 bietet Kommunikationsmuster, Tools und Robotik-Konventionen. Es ersetzt aber keine gute Architektur und macht AI-Integration nicht magisch einfacher.
+
+## Aufgabe
+
+Schreibe eine kurze Entscheidungshilfe: Wann nutzt du ROS2 in diesem Projekt, wann bleibst du bei Services?
+
+## Akzeptanzkriterien
+
+- Mindestens drei Pro- und Contra-Punkte sind genannt.
+- Bezug zum Roboterkopf ist konkret.
+- Entscheidung für den Kursstand ist begründet.
+
+## Erweiterungen
+
+- Vergleiche mit MQTT/REST aus Modul 06.
+
+## Reflexionsfragen
+
+- Welches Problem löst ROS2 sofort?
+- Was wird durch ROS2 komplexer?
+- Wann lohnt sich die Migration?

07-ros2-basics/02-workspace-und-package-anlegen.md

@@ -0,0 +1,38 @@
+# Aufgabe 02: Workspace und Package anlegen
+
+## Ziel
+
+Du richtest einen ROS2-Workspace mit einem einfachen Package ein.
+
+## Warum ist das wichtig?
+
+Alle weiteren ROS2-Übungen brauchen reproduzierbare Basisstruktur.
+
+## Voraussetzungen
+
+- ROS2 installiert
+- Terminal
+
+## Theorie
+
+Ein Workspace enthält Packages, die mit colcon gebaut werden. Source-Setup entscheidet, welche Pakete im Terminal sichtbar sind.
+
+## Aufgabe
+
+Erstelle einen Workspace, ein Python- oder C++-Package und baue es mit colcon.
+
+## Akzeptanzkriterien
+
+- Build läuft ohne Fehler.
+- Package ist nach `source install/setup...` sichtbar.
+- README notiert die Befehle.
+
+## Erweiterungen
+
+- Füge einen `just`-Befehl fürs Build hinzu.
+
+## Reflexionsfragen
+
+- Warum muss setup gesourced werden?
+- Was ist ein Package?
+- Wie trennst du ROS2-Code vom Restprojekt?

07-ros2-basics/03-erste-node-schreiben.md

@@ -0,0 +1,37 @@
+# Aufgabe 03: Erste Node schreiben
+
+## Ziel
+
+Du schreibst eine Node, die regelmäßig Status loggt.
+
+## Warum ist das wichtig?
+
+Nodes sind die kleinste laufende Einheit in ROS2.
+
+## Voraussetzungen
+
+- Aufgabe 02
+
+## Theorie
+
+Eine Node kapselt Verhalten und kommuniziert über ROS2-Mechanismen. Timer sind ein einfacher Einstieg ohne externe Nachrichten.
+
+## Aufgabe
+
+Implementiere eine Node `robot_head_status`, die jede Sekunde einen Status ausgibt.
+
+## Akzeptanzkriterien
+
+- Node startet mit `ros2 run`.
+- Timer läuft regelmäßig.
+- Shutdown beendet sauber.
+
+## Erweiterungen
+
+- Füge Parameter für Intervall hinzu.
+
+## Reflexionsfragen
+
+- Was unterscheidet Node und Prozess?
+- Wie stoppst du eine Node sauber?
+- Welche Zustände sollte der Roboterkopf melden?

07-ros2-basics/04-topics-publishen-und-subscriben.md

@@ -0,0 +1,37 @@
+# Aufgabe 04: Topics publishen und subscriben
+
+## Ziel
+
+Du sendest und empfängst einfache Nachrichten über Topics.
+
+## Warum ist das wichtig?
+
+Sensor- und Statusdaten werden in ROS2 typischerweise über Topics verteilt.
+
+## Voraussetzungen
+
+- Aufgabe 03
+
+## Theorie
+
+Topics sind asynchrone Datenströme. Publisher kennen Subscriber nicht direkt, was lose Kopplung ermöglicht.
+
+## Aufgabe
+
+Baue einen Publisher für `person_count` und einen Subscriber, der den Wert loggt.
+
+## Akzeptanzkriterien
+
+- Topic ist mit `ros2 topic list` sichtbar.
+- Nachrichten kommen regelmäßig an.
+- Datentyp ist dokumentiert.
+
+## Erweiterungen
+
+- Nutze einen eigenen Message-Typ als Experiment.
+
+## Reflexionsfragen
+
+- Warum passt PersonCount zu Topic?
+- Wann wäre ein Service besser?
+- Wie debuggt man Topic-Daten?

07-ros2-basics/05-services-in-ros2-nutzen.md

@@ -0,0 +1,37 @@
+# Aufgabe 05: Services in ROS2 nutzen
+
+## Ziel
+
+Du implementierst einen Request/Response-Service für Kopfzentrierung.
+
+## Warum ist das wichtig?
+
+Viele Roboteraktionen brauchen eine direkte Antwort, ob der Befehl angenommen wurde.
+
+## Voraussetzungen
+
+- Aufgaben 03-04
+
+## Theorie
+
+ROS2 Services sind synchrone oder request/response-artige Aufrufe. Sie passen zu kurzen Aktionen, nicht zu langen Bewegungen.
+
+## Aufgabe
+
+Baue einen Service `center_head`, der Erfolg und Nachricht zurückgibt.
+
+## Akzeptanzkriterien
+
+- Service ist per CLI aufrufbar.
+- Antwort enthält Erfolg.
+- Fehlerfall ist simuliert.
+
+## Erweiterungen
+
+- Verbinde den Service mit der Motion API im Mockmodus.
+
+## Reflexionsfragen
+
+- Warum ist ein langer Scan kein guter Service?
+- Welche Antwort braucht ein Caller?
+- Wie gehst du mit Timeout um?

07-ros2-basics/06-actions-fuer-laengere-bewegungen.md

@@ -0,0 +1,37 @@
+# Aufgabe 06: Actions für längere Bewegungen
+
+## Ziel
+
+Du modellierst eine Scanbewegung als ROS2 Action.
+
+## Warum ist das wichtig?
+
+Lange Bewegungen brauchen Feedback, Fortschritt und Abbruchmöglichkeit.
+
+## Voraussetzungen
+
+- Aufgabe 05
+
+## Theorie
+
+Actions bestehen aus Goal, Feedback und Result. Sie passen zu Aufgaben, die dauern und eventuell abgebrochen werden sollen.
+
+## Aufgabe
+
+Implementiere oder skizziere eine Action `scan_for_person` mit Fortschritt und Ergebnis.
+
+## Akzeptanzkriterien
+
+- Goal kann gestartet werden.
+- Feedback wird regelmäßig gesendet.
+- Cancel ist bedacht oder implementiert.
+
+## Erweiterungen
+
+- Verbinde später mit Vision-Erkennung.
+
+## Reflexionsfragen
+
+- Warum ist Scan eine Action?
+- Welche Feedbackdaten sind nützlich?
+- Was passiert bei Cancel?

07-ros2-basics/07-launch-files-und-parameter.md

@@ -0,0 +1,37 @@
+# Aufgabe 07: Launch Files und Parameter
+
+## Ziel
+
+Du startest mehrere Nodes mit Parametern über ein Launch File.
+
+## Warum ist das wichtig?
+
+Ein Roboter startet selten nur einen Prozess.
+
+## Voraussetzungen
+
+- Aufgaben 03-06
+
+## Theorie
+
+Launch Files beschreiben, welche Nodes mit welchen Parametern starten. Parameter machen Verhalten ohne Codeänderung anpassbar.
+
+## Aufgabe
+
+Erstelle ein Launch File für Status-, PersonCount- und Motion-Mock-Node.
+
+## Akzeptanzkriterien
+
+- Mehrere Nodes starten gemeinsam.
+- Parameter werden gesetzt.
+- Startbefehle sind dokumentiert.
+
+## Erweiterungen
+
+- Füge Namespace `robot_head` hinzu.
+
+## Reflexionsfragen
+
+- Welche Parameter ändern sich pro Umgebung?
+- Warum sind Launch Files besser als viele Terminals?
+- Wie organisierst du Namespaces?

07-ros2-basics/08-tf-grob-verstehen.md

@@ -0,0 +1,37 @@
+# Aufgabe 08: TF grob verstehen
+
+## Ziel
+
+Du modellierst grob Koordinatenrahmen für Kamera und Kopf.
+
+## Warum ist das wichtig?
+
+Bewegung und Sicht brauchen gemeinsame Bezugssysteme.
+
+## Voraussetzungen
+
+- Aufgaben 04-07
+
+## Theorie
+
+TF beschreibt Transformationen zwischen Frames. Für den Kurs reicht zunächst zu verstehen, wo Kamera, Kopfmitte und Welt relativ zueinander liegen.
+
+## Aufgabe
+
+Zeichne Frames für base, head_pan, head_tilt und camera und beschreibe Transformationen qualitativ.
+
+## Akzeptanzkriterien
+
+- Mindestens vier Frames sind beschrieben.
+- Parent/Child-Beziehungen sind klar.
+- Bezug zur Pan-Tilt-Mechanik ist hergestellt.
+
+## Erweiterungen
+
+- Publiziere statische TFs als Experiment.
+
+## Reflexionsfragen
+
+- Warum ist Kameraposition wichtig?
+- Was ändert sich bei Pan?
+- Welche Vereinfachung ist für 2D-Tracking okay?

07-ros2-basics/09-bridge-zur-bestehenden-architektur.md

@@ -0,0 +1,38 @@
+# Aufgabe 09: Bridge zur bestehenden Architektur
+
+## Ziel
+
+Du verbindest REST-Service und ROS2-Welt in einem kleinen Adapter.
+
+## Warum ist das wichtig?
+
+So kannst du bestehende Services nutzen, ohne alles sofort auf ROS2 umzuschreiben.
+
+## Voraussetzungen
+
+- Modul 06
+- Aufgaben 04-08
+
+## Theorie
+
+Eine Bridge übersetzt zwischen Protokollen. Sie sollte dünn bleiben und keine Fachlogik verstecken.
+
+## Aufgabe
+
+Baue eine Node, die einen ROS2-Service oder Topic-Aufruf an einen bestehenden HTTP-Mock weiterleitet.
+
+## Akzeptanzkriterien
+
+- ROS2-Aufruf erreicht HTTP-Mock.
+- Fehler werden übersetzt.
+- Bridge-Code bleibt klein.
+
+## Erweiterungen
+
+- Bridge PersonCount Topic aus Vision-Service.
+
+## Reflexionsfragen
+
+- Welche Logik gehört nicht in die Bridge?
+- Wie behandelst du HTTP-Timeouts?
+- Wann würdest du native ROS2-Nodes schreiben?

07-ros2-basics/README.md

@@ -0,0 +1,19 @@
+# ROS2 Basics
+
+Nodes, Topics, Services, Actions, Launch Files, Parameter, TF und Architektur-Brücken.
+
+## Aufgaben
+
+- [01: ROS2 Zweck einordnen](01-ros2-zweck-einordnen.md)
+- [02: Workspace und Package anlegen](02-workspace-und-package-anlegen.md)
+- [03: Erste Node schreiben](03-erste-node-schreiben.md)
+- [04: Topics publishen und subscriben](04-topics-publishen-und-subscriben.md)
+- [05: Services in ROS2 nutzen](05-services-in-ros2-nutzen.md)
+- [06: Actions für längere Bewegungen](06-actions-fuer-laengere-bewegungen.md)
+- [07: Launch Files und Parameter](07-launch-files-und-parameter.md)
+- [08: TF grob verstehen](08-tf-grob-verstehen.md)
+- [09: Bridge zur bestehenden Architektur](09-bridge-zur-bestehenden-architektur.md)
+
+## Arbeitsweise
+
+Bearbeite die Aufgaben nacheinander. Jede Aufgabe soll ein kleines, überprüfbares Ergebnis liefern und ist bewusst auf etwa 1 bis 4 Stunden ausgelegt.

08-final-project/01-projekt-skeleton-anlegen.md

@@ -0,0 +1,37 @@
+# Aufgabe 01: Projekt-Skeleton anlegen
+
+## Ziel
+
+Du legst die finale Projektstruktur für Orchestrator, Services, Config und Dokumentation an.
+
+## Warum ist das wichtig?
+
+Ein integriertes Projekt braucht Ordnung, bevor viele Teile zusammenkommen.
+
+## Voraussetzungen
+
+- Module 00-07 überblickt
+
+## Theorie
+
+Skeletons sind Architekturentscheidungen in Dateiform. Sie zeigen, wo Code, Config, Tests und Betriebsdateien leben.
+
+## Aufgabe
+
+Erstelle eine Struktur mit `orchestrator`, `services/vision`, `services/voice`, `services/motion`, `config`, `docs` und `scripts`.
+
+## Akzeptanzkriterien
+
+- Alle Hauptkomponenten haben Platz.
+- README erklärt Startreihenfolge.
+- Mockmodus ist vorgesehen.
+
+## Erweiterungen
+
+- Füge ein Top-Level-`justfile` hinzu.
+
+## Reflexionsfragen
+
+- Welche Struktur verhindert Kopplung?
+- Wo liegen Testdaten?
+- Was muss ohne Hardware laufen?

08-final-project/02-voice-pipeline-integrieren.md

@@ -0,0 +1,38 @@
+# Aufgabe 02: Voice Pipeline integrieren
+
+## Ziel
+
+Du bringst Push-to-Talk, STT und TTS in das finale Skeleton.
+
+## Warum ist das wichtig?
+
+Der Roboter muss zuerst zuverlässig zuhören und sprechen.
+
+## Voraussetzungen
+
+- Modul 02 Aufgabe 07
+- Aufgabe 01
+
+## Theorie
+
+Integration heißt, echte Startbefehle, Config und Fehlerpfade zu haben, nicht nur einzelne Skripte.
+
+## Aufgabe
+
+Integriere die Voice Pipeline als Service oder Prozess mit klarer Schnittstelle zum Orchestrator.
+
+## Akzeptanzkriterien
+
+- Eine gesprochene Frage wird zu Text.
+- Eine Textantwort wird gesprochen.
+- Latenz wird geloggt.
+
+## Erweiterungen
+
+- Füge Text-Fallback in der CLI hinzu.
+
+## Reflexionsfragen
+
+- Welche Fehler hörst du erst bei echter Nutzung?
+- Wie stoppst du laufende TTS?
+- Welche Logs helfen bei Audio-Problemen?

08-final-project/03-llm-agent-integrieren.md

@@ -0,0 +1,38 @@
+# Aufgabe 03: LLM Agent integrieren
+
+## Ziel
+
+Du verbindest den Orchestrator mit LLM, System Prompt, History und Tool Dispatcher.
+
+## Warum ist das wichtig?
+
+Der Agent ist die Entscheidungsschicht zwischen Sprache und Fähigkeiten.
+
+## Voraussetzungen
+
+- Modul 01 Aufgabe 09
+- Aufgabe 01
+
+## Theorie
+
+Im finalen System muss der Agent deterministische Grenzen haben: maximale Tool Calls, validierte Argumente und klare Fehlermeldungen.
+
+## Aufgabe
+
+Integriere den Agent Loop in den Orchestrator und teste mindestens fünf Dialoge.
+
+## Akzeptanzkriterien
+
+- Dialoge laufen über den Orchestrator.
+- Tool Calls werden geloggt.
+- Endlosschleifen sind begrenzt.
+
+## Erweiterungen
+
+- Füge Session-Auswahl hinzu.
+
+## Reflexionsfragen
+
+- Welche Dialoge brauchen Tools?
+- Welche Antworten sollen kurz bleiben?
+- Wie erkennst du Agent-Fehlverhalten?

08-final-project/04-vision-tool-count-people-anschliessen.md

@@ -0,0 +1,38 @@
+# Aufgabe 04: Vision Tool count_people anschließen
+
+## Ziel
+
+Du schließt den Vision Service als Tool für Personenanzahl an.
+
+## Warum ist das wichtig?
+
+Damit kann der Roboter reale Beobachtungen in Antworten einbauen.
+
+## Voraussetzungen
+
+- Modul 03 Aufgabe 09
+- Aufgabe 03
+
+## Theorie
+
+Sensor-Tools liefern Momentaufnahmen, keine absolute Wahrheit. Der Agent muss Unsicherheit und Fehler verständlich formulieren.
+
+## Aufgabe
+
+Verbinde `count_people` mit dem Vision Service und teste die Frage "Wie viele Personen sind im Raum?".
+
+## Akzeptanzkriterien
+
+- Tool ruft echten oder Mock-Service auf.
+- Antwort enthält Anzahl oder Unsicherheit.
+- Servicefehler werden nicht als Null Personen ausgegeben.
+
+## Erweiterungen
+
+- Füge Debugbild-Link im Log hinzu.
+
+## Reflexionsfragen
+
+- Warum ist Servicefehler nicht gleich keine Person?
+- Wie formulierst du Unsicherheit?
+- Welche Latenz ist akzeptabel?

08-final-project/05-face-tool-identify-people-anschliessen.md

@@ -0,0 +1,38 @@
+# Aufgabe 05: Face Tool identify_people anschließen
+
+## Ziel
+
+Du integrierst bekannte Personen als Agent-Tool.
+
+## Warum ist das wichtig?
+
+Der Roboter soll bekannte Personen erkennen, ohne Identitäten zu erfinden.
+
+## Voraussetzungen
+
+- Modul 04 Aufgabe 07
+- Aufgabe 03
+
+## Theorie
+
+Identifikation ist sensibler als Zählen. Der Agent muss strikt beim Tool-Ergebnis bleiben.
+
+## Aufgabe
+
+Verbinde `identify_people`, teste bekannt, unbekannt und unsicher mit Mock- oder Echtservice.
+
+## Akzeptanzkriterien
+
+- Bekannte Person wird korrekt genannt.
+- Unbekannte bleiben unbekannt.
+- Consent-Regeln sind dokumentiert.
+
+## Erweiterungen
+
+- Füge Begrüßung bekannter Personen hinzu.
+
+## Reflexionsfragen
+
+- Welche Antwort ist bei Unsicherheit fair?
+- Wann sollte der Roboter nicht identifizieren?
+- Wie löschst du Profile?

08-final-project/06-motion-tool-look-anschliessen.md

@@ -0,0 +1,38 @@
+# Aufgabe 06: Motion Tool look anschließen
+
+## Ziel
+
+Du steuerst den Pan-Tilt-Kopf per Sprachbefehl.
+
+## Warum ist das wichtig?
+
+Damit wird aus dem Dialog ein handelnder Roboterkopf.
+
+## Voraussetzungen
+
+- Modul 05 Aufgabe 08
+- Aufgabe 03
+
+## Theorie
+
+Motion-Tools sind gefährlicher als reine Informations-Tools. Sie brauchen enge Schemas, Limits und Simulation.
+
+## Aufgabe
+
+Verbinde `look(direction)` mit der Motion API und teste links, rechts, hoch, runter und center.
+
+## Akzeptanzkriterien
+
+- Alle Richtungen funktionieren im Mock oder an Hardware.
+- Ungültige Richtungen werden abgelehnt.
+- Bewegung wird kurz bestätigt.
+
+## Erweiterungen
+
+- Füge einen Dry-Run-Schalter hinzu.
+
+## Reflexionsfragen
+
+- Welche Befehle sind zu vage?
+- Wie begrenzt du Bewegung bei Kindern oder Publikum?
+- Was passiert bei Motion-Service-Ausfall?

08-final-project/07-personensuche-per-scanbewegung.md

@@ -0,0 +1,37 @@
+# Aufgabe 07: Personensuche per Scanbewegung
+
+## Ziel
+
+Du kombinierst Kopfscan und Vision, um nach Personen zu suchen.
+
+## Warum ist das wichtig?
+
+Der Roboter soll aktiv suchen können, statt nur passiv geradeaus zu sehen.
+
+## Voraussetzungen
+
+- Aufgaben 04 und 06
+
+## Theorie
+
+Scan ist eine kontrollierte Sequenz aus Bewegung, Warten, Bildauswertung und Abbruch. Ohne Zustandsmodell wird das schnell chaotisch.
+
+## Aufgabe
+
+Implementiere einen Scanmodus: mehrere Kopfpositionen anfahren, Vision prüfen, bei Person stoppen oder Ergebnis melden.
+
+## Akzeptanzkriterien
+
+- Scanpositionen sind begrenzt.
+- Bei Person wird gestoppt.
+- Kein Treffer wird verständlich gemeldet.
+
+## Erweiterungen
+
+- Nutze ROS2 Action oder internen Job als Variante.
+
+## Reflexionsfragen
+
+- Welche Scanreihenfolge wirkt natürlich?
+- Wie lange wartest du nach Bewegung?
+- Was passiert bei mehreren Personen?

08-final-project/08-debug-ui-und-abschlussreflexion.md

@@ -0,0 +1,37 @@
+# Aufgabe 08: Debug UI und Abschlussreflexion
+
+## Ziel
+
+Du baust eine einfache Debug-Ansicht und bewertest das Gesamtsystem.
+
+## Warum ist das wichtig?
+
+Ein integrierter Roboter braucht sichtbare Zustände, sonst bleibt Fehlersuche langsam.
+
+## Voraussetzungen
+
+- Aufgaben 01-07
+
+## Theorie
+
+Eine Debug UI muss nicht schön sein. Wichtig sind aktueller Zustand, letzte Transkription, Tool Calls, Service-Health und Latenzen.
+
+## Aufgabe
+
+Erstelle eine kleine Web- oder Terminal-UI und schreibe eine Abschlussreflexion mit offenen Risiken.
+
+## Akzeptanzkriterien
+
+- UI zeigt Service-Status.
+- Letzte Dialogrunde und Tool Calls sind sichtbar.
+- Reflexion nennt technische und ethische Grenzen.
+
+## Erweiterungen
+
+- Füge Log-Download oder Trace-Ansicht hinzu.
+
+## Reflexionsfragen
+
+- Welche Funktion fühlt sich wirklich fertig an?
+- Wo ist die größte technische Schuld?
+- Welche Sicherheitsregel würdest du vor einer Demo verschärfen?

08-final-project/README.md

@@ -0,0 +1,18 @@
+# Final Project
+
+Der sprechende, sehende und bewegliche AI-Roboterkopf in integrierten Meilensteinen.
+
+## Aufgaben
+
+- [01: Projekt-Skeleton anlegen](01-projekt-skeleton-anlegen.md)
+- [02: Voice Pipeline integrieren](02-voice-pipeline-integrieren.md)
+- [03: LLM Agent integrieren](03-llm-agent-integrieren.md)
+- [04: Vision Tool count_people anschließen](04-vision-tool-count-people-anschliessen.md)
+- [05: Face Tool identify_people anschließen](05-face-tool-identify-people-anschliessen.md)
+- [06: Motion Tool look anschließen](06-motion-tool-look-anschliessen.md)
+- [07: Personensuche per Scanbewegung](07-personensuche-per-scanbewegung.md)
+- [08: Debug UI und Abschlussreflexion](08-debug-ui-und-abschlussreflexion.md)
+
+## Arbeitsweise
+
+Bearbeite die Aufgaben nacheinander. Jede Aufgabe soll ein kleines, überprüfbares Ergebnis liefern und ist bewusst auf etwa 1 bis 4 Stunden ausgelegt.

09-extensions/01-fahrende-plattform-bewerten.md

@@ -0,0 +1,38 @@
+# Aufgabe 01: Fahrende Plattform bewerten
+
+## Ziel
+
+Du prüfst, was nötig wäre, um den Roboterkopf auf eine mobile Basis zu setzen.
+
+## Warum ist das wichtig?
+
+Mobilität erhöht Nutzen und Risiko massiv.
+
+## Voraussetzungen
+
+- Final Project grob lauffähig
+- Sicherheitsbewusstsein
+
+## Theorie
+
+Eine fahrende Plattform braucht Motorcontroller, Odometrie, Hinderniserkennung und Not-Aus. Sie ist kein kleiner Zusatz zum Kopfprojekt.
+
+## Aufgabe
+
+Erstelle eine Architektur- und Risikoanalyse für eine mobile Erweiterung.
+
+## Akzeptanzkriterien
+
+- Motoren, Strom, Sensoren und Not-Aus sind erwähnt.
+- Bestehende Kopfarchitektur bleibt erkennbar.
+- Klare Nicht-Ziele sind definiert.
+
+## Erweiterungen
+
+- Baue nur eine Simulation der Fahrbefehle.
+
+## Reflexionsfragen
+
+- Welche neuen Gefahren entstehen?
+- Welche Sensoren fehlen dem Kopfprojekt?
+- Warum sollte Bewegung langsam starten?

09-extensions/02-slam-einordnen.md

@@ -0,0 +1,38 @@
+# Aufgabe 02: SLAM einordnen
+
+## Ziel
+
+Du verstehst, wofür SLAM gebraucht wird und welche Daten es benötigt.
+
+## Warum ist das wichtig?
+
+Navigation ohne Karte und Lokalisierung bleibt blindes Herumfahren.
+
+## Voraussetzungen
+
+- Aufgabe 01
+- ROS2-Grundwissen hilfreich
+
+## Theorie
+
+SLAM schätzt gleichzeitig Karte und Position. Dafür braucht es geeignete Sensorik wie LiDAR, Tiefenkamera oder visuelle Odometrie.
+
+## Aufgabe
+
+Vergleiche drei SLAM-Ansätze auf Eignung für eine spätere Plattform.
+
+## Akzeptanzkriterien
+
+- Sensoranforderungen sind genannt.
+- Rechenlast ist grob bewertet.
+- Bezug zu ROS2 ist hergestellt.
+
+## Erweiterungen
+
+- Teste ein ROS2-SLAM-Demo mit Beispieldaten.
+
+## Reflexionsfragen
+
+- Welche Sensoren liefern Entfernung?
+- Warum ist nur eine RGB-Kamera schwierig?
+- Wann reicht Teleoperation statt SLAM?

09-extensions/03-navigation-planen.md

@@ -0,0 +1,37 @@
+# Aufgabe 03: Navigation planen
+
+## Ziel
+
+Du skizzierst eine Navigationsarchitektur mit Zielpunkten, Hindernissen und Sicherheit.
+
+## Warum ist das wichtig?
+
+Ein mobiler Roboter braucht mehr als ein LLM mit "fahr dorthin".
+
+## Voraussetzungen
+
+- Aufgaben 01-02
+
+## Theorie
+
+Navigation besteht aus globaler Planung, lokaler Vermeidung, Lokalisierung und Motorsteuerung. Das LLM sollte Ziele formulieren, nicht direkt Motorwerte setzen.
+
+## Aufgabe
+
+Erstelle ein Diagramm für LLM-Ziel, Navigation Stack, Safety Layer und Motorcontroller.
+
+## Akzeptanzkriterien
+
+- LLM ist nicht direkt am Motor.
+- Safety Layer ist explizit.
+- Abbruchbedingungen sind beschrieben.
+
+## Erweiterungen
+
+- Füge eine simulierte `go_to` Action hinzu.
+
+## Reflexionsfragen
+
+- Welche Entscheidungen darf ein LLM treffen?
+- Wie erkennt der Roboter Blockaden?
+- Welche Sensoren brauchst du für Menschen in der Nähe?

09-extensions/04-greifarm-als-erweiterung-bewerten.md

@@ -0,0 +1,38 @@
+# Aufgabe 04: Greifarm als Erweiterung bewerten
+
+## Ziel
+
+Du analysierst, was ein kleiner Greifarm zusätzlich erfordert.
+
+## Warum ist das wichtig?
+
+Manipulation ist deutlich komplexer als Kopfbewegung.
+
+## Voraussetzungen
+
+- Final Project
+- Servo- und Sicherheitsgrundlagen
+
+## Theorie
+
+Ein Greifarm braucht Kinematik, Kraftbegrenzung, Objektwahrnehmung und sichere Bewegungsplanung. Schon einfache Greifer können Finger einklemmen oder Objekte beschädigen.
+
+## Aufgabe
+
+Schreibe eine Machbarkeitsnotiz für einen 2- oder 3-DOF-Greifarm mit klaren Lernschritten.
+
+## Akzeptanzkriterien
+
+- DOF, Reichweite und Last sind betrachtet.
+- Sicherheitsgrenzen sind definiert.
+- Integration als Tool ist skizziert.
+
+## Erweiterungen
+
+- Simuliere `point_at` statt `grab` als ersten Schritt.
+
+## Reflexionsfragen
+
+- Warum ist Greifen schwerer als Zeigen?
+- Welche Sensorik fehlt?
+- Wie würdest du gefährliche Tool Calls verhindern?

09-extensions/README.md

@@ -0,0 +1,14 @@
+# Extensions
+
+Optionale Fortgeschrittenenthemen wie mobile Plattform, SLAM, Navigation und Greifarm.
+
+## Aufgaben
+
+- [01: Fahrende Plattform bewerten](01-fahrende-plattform-bewerten.md)
+- [02: SLAM einordnen](02-slam-einordnen.md)
+- [03: Navigation planen](03-navigation-planen.md)
+- [04: Greifarm als Erweiterung bewerten](04-greifarm-als-erweiterung-bewerten.md)
+
+## Arbeitsweise
+
+Bearbeite die Aufgaben nacheinander. Jede Aufgabe soll ein kleines, überprüfbares Ergebnis liefern und ist bewusst auf etwa 1 bis 4 Stunden ausgelegt.

README.md

@@ -1,49 +1,43 @@
-# Robotics + AI Learning Roadmap
+# Robotics + AI Learning Course
 
-Dieses Repository ist als praktischer Lernpfad gedacht, um von 0 zu einem kleinen AI-Robotik-Assistenten zu kommen.
+Dieses Repository ist ein deutschsprachiger, praktischer Lernkurs für erfahrene Softwareentwickler, die Rust, Backend-Entwicklung, Linux, Docker und APIs kennen, aber Robotik, Computer Vision, ROS2 und Hardware schrittweise lernen wollen.
 
-Zielbild:
+Ziel ist ein sprechender AI-Roboterkopf, der zuhört, Sprache in Text wandelt, ein LLM mit Tool Calling nutzt, per Text-to-Speech antwortet, Personen über eine Kamera zählen und bekannte Personen erkennen kann, einen Pan-Tilt-Kopf bewegt und später über ROS2 erweiterbar ist.
 
-- Du kannst mit dem System sprechen.
-- Es versteht Sprache über Speech-to-Text.
-- Es antwortet über Text-to-Speech.
-- Es kann Tools/Aktionen ausführen.
-- Es kann über eine Kamera Personen erkennen/zählen.
-- Es kann einen kleinen Servo-Kopf bewegen.
-- Später kann es über ROS2 strukturiert erweitert werden.
+## Kursstruktur
 
-## Lernphasen
+1. [00-course-overview](00-course-overview/) - Zielbild, Setup, Lernstrategie, Architektur, Sicherheit und Datenschutz
+2. [01-ai-agent-basics](01-ai-agent-basics/) - LLM API, Chat Messages, System Prompt, Tool Calling, Agent Loop, Logging und Memory
+3. [02-voice-interface](02-voice-interface/) - Audioaufnahme, Push-to-Talk, Whisper, TTS, Audio Queue und Voice Pipeline
+4. [03-computer-vision](03-computer-vision/) - Kamera, OpenCV, Bounding Boxes, YOLO, Personen zählen und Vision Service
+5. [04-face-recognition](04-face-recognition/) - Face Detection, Embeddings, Enrollment, Schwellenwerte, Datenschutz und Agent Tool
+6. [05-robot-motion](05-robot-motion/) - Servos, PWM, Stromversorgung, Pan-Tilt-Kopf, Motion API und visuelles Zentrieren
+7. [06-system-architecture](06-system-architecture/) - Rust-Orchestrator, Python-Services, REST/gRPC/MQTT, Docker Compose und Observability
+8. [07-ros2-basics](07-ros2-basics/) - ROS2 Nodes, Topics, Services, Actions, Launch Files, Parameter, TF und Bridge-Architektur
+9. [08-final-project](08-final-project/) - Integration zum sprechenden, sehenden und beweglichen Roboterkopf
+10. [09-extensions](09-extensions/) - optionale Themen wie fahrende Plattform, SLAM, Navigation und Greifarm
 
-1. `01-ai-agent-basics` - LLMs, Tool Calling, einfache Agenten
-2. `02-voice-interface` - Mikrofon, Whisper, TTS
-3. `03-computer-vision` - Kamera, OpenCV, Personenerkennung
-4. `04-face-recognition` - bekannte Personen erkennen
-5. `05-robot-motion` - Servos, PWM, Pan-Tilt-Kopf
-6. `06-system-architecture` - Services, APIs, Events, Rust/Python-Aufteilung
-7. `07-ros2-basics` - ROS2 verstehen und einfache Nodes bauen
-8. `08-final-project` - sprechender Roboterkopf als integriertes Projekt
+## Arbeitsweise
 
-## Empfohlene Arbeitsweise
+Jede Aufgaben-Datei ist als kleine, praktische Lerneinheit aufgebaut und sollte in etwa 1 bis 4 Stunden bearbeitbar sein. Lies nicht nur passiv: Baue das Ergebnis, miss die wichtigsten Werte und notiere Entscheidungen in einem Projekttagebuch.
 
-Arbeite die Aufgaben nicht nur lesend durch. Jede Markdown-Datei enthält ein kleines Ergebnis, das du wirklich bauen solltest.
+Empfohlene Rollenverteilung:
 
-Pro Aufgabe:
+- Rust für Orchestrierung, APIs, Tool Calling, Services, State und Konfiguration
+- Python für AI, Whisper, OpenCV, YOLO, Face Recognition und schnelle Experimente
+- Docker Compose für lokale Integration mehrerer Services
+- ROS2 erst dann, wenn die Grundfähigkeiten verstanden und als Services lauffähig sind
 
-1. Ziel lesen
-2. Mini-Projekt bauen
-3. Erkenntnisse notieren
-4. Optional: Erweiterung umsetzen
+## Empfohlenes Startsetup
 
-## Tech-Empfehlung
+- Linux-PC, Laptop oder Raspberry Pi 5
+- USB-Kamera
+- USB-Mikrofon und Lautsprecher
+- Python 3.11+
+- Rust stable
+- Docker oder Podman optional
+- später: zwei Servos, Pan-Tilt-Halterung, passende externe Stromversorgung und optional PCA9685 Servo-Controller
 
-Für den Anfang:
+## Leitprinzip
 
-- Python für AI, Whisper, OpenCV, YOLO
-- Rust für Backend-/Service-Logik, APIs, Orchestrierung
-- Raspberry Pi 5 oder normaler Linux-PC für frühe Tests
-- USB-Kamera, USB-Mikrofon, Lautsprecher
-- später: PCA9685 Servo-Controller oder direkt GPIO/PWM
-
-## Wichtig
-
-Nicht direkt mit einem fahrenden Roboter anfangen. Baue zuerst einen sprechenden, sehenden und beweglichen Roboterkopf. Das reduziert die Komplexität massiv.
+Starte nicht mit einem fahrenden Roboter. Baue zuerst einen sprechenden, sehenden und beweglichen Roboterkopf. Dadurch lernst du die wichtigen AI-, Vision-, Audio-, Motion- und Architekturthemen mit deutlich weniger Risiko.