From d0b776485ad1caeb33890bfb9952907d5d33352e Mon Sep 17 00:00:00 2001 From: Matthias Schild Date: Wed, 8 Jul 2026 23:33:26 +0200 Subject: [PATCH] feat: expanded and added more tasks --- .../01-kursziel-und-zielsystem-beschreiben.md | 38 +++++++++++ .../02-hardware-empfehlungen-pruefen.md | 39 +++++++++++ .../03-software-setup-vorbereiten.md | 40 +++++++++++ .../04-lernstrategie-und-projekttagebuch.md | 38 +++++++++++ ...05-sicherheit-und-datenschutz-festlegen.md | 38 +++++++++++ 00-course-overview/README.md | 15 ++++ .../01-llm-api-per-cli-ansprechen.md | 39 +++++++++++ 01-ai-agent-basics/01-llm-api.md | 43 ------------ .../02-ollama-und-cloud-api-vergleichen.md | 39 +++++++++++ 01-ai-agent-basics/02-tool-calling.md | 55 --------------- .../03-chat-messages-modellieren.md | 38 +++++++++++ .../04-system-prompt-entwerfen.md | 38 +++++++++++ .../05-conversation-history-verwalten.md | 38 +++++++++++ .../06-json-tool-schema-definieren.md | 38 +++++++++++ .../07-tool-dispatcher-bauen.md | 38 +++++++++++ .../08-agent-loop-implementieren.md | 38 +++++++++++ .../09-fehlerbehandlung-logging-und-memory.md | 38 +++++++++++ 01-ai-agent-basics/README.md | 19 ++++++ .../01-mikrofon-aufnehmen-und-speichern.md | 39 +++++++++++ 02-voice-interface/01-speech-to-text.md | 38 ----------- .../02-push-to-talk-cli-bauen.md | 38 +++++++++++ 02-voice-interface/02-text-to-speech.md | 39 ----------- .../03-whisper-batch-stt-integrieren.md | 38 +++++++++++ .../04-streaming-vs-batch-bewerten.md | 38 +++++++++++ .../05-text-to-speech-erzeugen.md | 38 +++++++++++ .../06-audio-queue-einfuehren.md | 38 +++++++++++ .../07-voice-pipeline-verbinden.md | 38 +++++++++++ .../08-wake-word-als-optionaler-prototyp.md | 38 +++++++++++ 02-voice-interface/README.md | 18 +++++ 03-computer-vision/01-camera-feed.md | 34 ---------- .../01-kamera-oeffnen-und-frames-anzeigen.md | 39 +++++++++++ 03-computer-vision/02-count-people.md | 48 ------------- .../02-frames-lesen-und-bilder-speichern.md | 38 +++++++++++ .../03-fps-und-latenz-messen.md | 38 +++++++++++ .../04-opencv-grundlagen-anwenden.md | 38 +++++++++++ .../05-bounding-boxes-zeichnen.md | 38 +++++++++++ .../06-yolo-oder-detector-integrieren.md | 38 +++++++++++ 03-computer-vision/07-personen-zaehlen.md | 38 +++++++++++ .../08-confidence-und-nms-verstehen.md | 37 ++++++++++ .../09-http-vision-service-bauen.md | 38 +++++++++++ 03-computer-vision/README.md | 19 ++++++ .../01-face-detection-testen.md | 39 +++++++++++ 04-face-recognition/01-known-faces.md | 48 ------------- .../02-face-embeddings-berechnen.md | 38 +++++++++++ .../03-bekannte-personen-enrollen.md | 38 +++++++++++ .../04-unbekannte-personen-erkennen.md | 37 ++++++++++ ...hwellenwerte-und-false-positives-testen.md | 38 +++++++++++ .../06-face-recognition-service-bauen.md | 38 +++++++++++ ...-agent-tool-identify-people-integrieren.md | 37 ++++++++++ 04-face-recognition/README.md | 17 +++++ 05-robot-motion/01-servo-basics.md | 43 ------------ .../01-servo-grundlagen-verstehen.md | 39 +++++++++++ 05-robot-motion/02-pan-tilt-head.md | 42 ------------ .../02-pwm-und-winkel-kalibrieren.md | 38 +++++++++++ .../03-stromversorgung-und-not-aus-planen.md | 38 +++++++++++ 05-robot-motion/04-pan-tilt-kopf-montieren.md | 38 +++++++++++ .../05-sichere-winkelbereiche-erzwingen.md | 37 ++++++++++ .../06-sanfte-bewegungen-implementieren.md | 37 ++++++++++ .../07-motion-api-bereitstellen.md | 38 +++++++++++ .../08-agent-tool-look-integrieren.md | 38 +++++++++++ .../09-person-im-bild-zentrieren.md | 37 ++++++++++ 05-robot-motion/README.md | 19 ++++++ .../01-service-schnitt-entwerfen.md | 37 ++++++++++ .../02-rust-orchestrator-skizzieren.md | 38 +++++++++++ .../03-python-vision-service-isolieren.md | 37 ++++++++++ .../04-voice-service-abgrenzen.md | 37 ++++++++++ .../05-rest-grpc-und-mqtt-vergleichen.md | 38 +++++++++++ ...event-basierte-kommunikation-einfuehren.md | 37 ++++++++++ .../07-docker-compose-fuer-services.md | 38 +++++++++++ .../08-config-management-strukturieren.md | 37 ++++++++++ .../09-observability-und-health-checks.md | 37 ++++++++++ 06-system-architecture/README.md | 19 ++++++ 07-ros2-basics/01-ros2-zweck-einordnen.md | 38 +++++++++++ .../02-workspace-und-package-anlegen.md | 38 +++++++++++ 07-ros2-basics/03-erste-node-schreiben.md | 37 ++++++++++ .../04-topics-publishen-und-subscriben.md | 37 ++++++++++ 07-ros2-basics/05-services-in-ros2-nutzen.md | 37 ++++++++++ .../06-actions-fuer-laengere-bewegungen.md | 37 ++++++++++ .../07-launch-files-und-parameter.md | 37 ++++++++++ 07-ros2-basics/08-tf-grob-verstehen.md | 37 ++++++++++ .../09-bridge-zur-bestehenden-architektur.md | 38 +++++++++++ 07-ros2-basics/README.md | 19 ++++++ .../01-projekt-skeleton-anlegen.md | 37 ++++++++++ .../02-voice-pipeline-integrieren.md | 38 +++++++++++ 08-final-project/03-llm-agent-integrieren.md | 38 +++++++++++ ...4-vision-tool-count-people-anschliessen.md | 38 +++++++++++ ...-face-tool-identify-people-anschliessen.md | 38 +++++++++++ .../06-motion-tool-look-anschliessen.md | 38 +++++++++++ .../07-personensuche-per-scanbewegung.md | 37 ++++++++++ .../08-debug-ui-und-abschlussreflexion.md | 37 ++++++++++ 08-final-project/README.md | 18 +++++ .../01-fahrende-plattform-bewerten.md | 38 +++++++++++ 09-extensions/02-slam-einordnen.md | 38 +++++++++++ 09-extensions/03-navigation-planen.md | 37 ++++++++++ .../04-greifarm-als-erweiterung-bewerten.md | 38 +++++++++++ 09-extensions/README.md | 14 ++++ README.md | 68 +++++++++---------- 97 files changed, 3121 insertions(+), 427 deletions(-) create mode 100644 00-course-overview/01-kursziel-und-zielsystem-beschreiben.md create mode 100644 00-course-overview/02-hardware-empfehlungen-pruefen.md create mode 100644 00-course-overview/03-software-setup-vorbereiten.md create mode 100644 00-course-overview/04-lernstrategie-und-projekttagebuch.md create mode 100644 00-course-overview/05-sicherheit-und-datenschutz-festlegen.md create mode 100644 00-course-overview/README.md create mode 100644 01-ai-agent-basics/01-llm-api-per-cli-ansprechen.md delete mode 100644 01-ai-agent-basics/01-llm-api.md create mode 100644 01-ai-agent-basics/02-ollama-und-cloud-api-vergleichen.md delete mode 100644 01-ai-agent-basics/02-tool-calling.md create mode 100644 01-ai-agent-basics/03-chat-messages-modellieren.md create mode 100644 01-ai-agent-basics/04-system-prompt-entwerfen.md create mode 100644 01-ai-agent-basics/05-conversation-history-verwalten.md create mode 100644 01-ai-agent-basics/06-json-tool-schema-definieren.md create mode 100644 01-ai-agent-basics/07-tool-dispatcher-bauen.md create mode 100644 01-ai-agent-basics/08-agent-loop-implementieren.md create mode 100644 01-ai-agent-basics/09-fehlerbehandlung-logging-und-memory.md create mode 100644 01-ai-agent-basics/README.md create mode 100644 02-voice-interface/01-mikrofon-aufnehmen-und-speichern.md delete mode 100644 02-voice-interface/01-speech-to-text.md create mode 100644 02-voice-interface/02-push-to-talk-cli-bauen.md delete mode 100644 02-voice-interface/02-text-to-speech.md create mode 100644 02-voice-interface/03-whisper-batch-stt-integrieren.md create mode 100644 02-voice-interface/04-streaming-vs-batch-bewerten.md create mode 100644 02-voice-interface/05-text-to-speech-erzeugen.md create mode 100644 02-voice-interface/06-audio-queue-einfuehren.md create mode 100644 02-voice-interface/07-voice-pipeline-verbinden.md create mode 100644 02-voice-interface/08-wake-word-als-optionaler-prototyp.md create mode 100644 02-voice-interface/README.md delete mode 100644 03-computer-vision/01-camera-feed.md create mode 100644 03-computer-vision/01-kamera-oeffnen-und-frames-anzeigen.md delete mode 100644 03-computer-vision/02-count-people.md create mode 100644 03-computer-vision/02-frames-lesen-und-bilder-speichern.md create mode 100644 03-computer-vision/03-fps-und-latenz-messen.md create mode 100644 03-computer-vision/04-opencv-grundlagen-anwenden.md create mode 100644 03-computer-vision/05-bounding-boxes-zeichnen.md create mode 100644 03-computer-vision/06-yolo-oder-detector-integrieren.md create mode 100644 03-computer-vision/07-personen-zaehlen.md create mode 100644 03-computer-vision/08-confidence-und-nms-verstehen.md create mode 100644 03-computer-vision/09-http-vision-service-bauen.md create mode 100644 03-computer-vision/README.md create mode 100644 04-face-recognition/01-face-detection-testen.md delete mode 100644 04-face-recognition/01-known-faces.md create mode 100644 04-face-recognition/02-face-embeddings-berechnen.md create mode 100644 04-face-recognition/03-bekannte-personen-enrollen.md create mode 100644 04-face-recognition/04-unbekannte-personen-erkennen.md create mode 100644 04-face-recognition/05-schwellenwerte-und-false-positives-testen.md create mode 100644 04-face-recognition/06-face-recognition-service-bauen.md create mode 100644 04-face-recognition/07-agent-tool-identify-people-integrieren.md create mode 100644 04-face-recognition/README.md delete mode 100644 05-robot-motion/01-servo-basics.md create mode 100644 05-robot-motion/01-servo-grundlagen-verstehen.md delete mode 100644 05-robot-motion/02-pan-tilt-head.md create mode 100644 05-robot-motion/02-pwm-und-winkel-kalibrieren.md create mode 100644 05-robot-motion/03-stromversorgung-und-not-aus-planen.md create mode 100644 05-robot-motion/04-pan-tilt-kopf-montieren.md create mode 100644 05-robot-motion/05-sichere-winkelbereiche-erzwingen.md create mode 100644 05-robot-motion/06-sanfte-bewegungen-implementieren.md create mode 100644 05-robot-motion/07-motion-api-bereitstellen.md create mode 100644 05-robot-motion/08-agent-tool-look-integrieren.md create mode 100644 05-robot-motion/09-person-im-bild-zentrieren.md create mode 100644 05-robot-motion/README.md create mode 100644 06-system-architecture/01-service-schnitt-entwerfen.md create mode 100644 06-system-architecture/02-rust-orchestrator-skizzieren.md create mode 100644 06-system-architecture/03-python-vision-service-isolieren.md create mode 100644 06-system-architecture/04-voice-service-abgrenzen.md create mode 100644 06-system-architecture/05-rest-grpc-und-mqtt-vergleichen.md create mode 100644 06-system-architecture/06-event-basierte-kommunikation-einfuehren.md create mode 100644 06-system-architecture/07-docker-compose-fuer-services.md create mode 100644 06-system-architecture/08-config-management-strukturieren.md create mode 100644 06-system-architecture/09-observability-und-health-checks.md create mode 100644 06-system-architecture/README.md create mode 100644 07-ros2-basics/01-ros2-zweck-einordnen.md create mode 100644 07-ros2-basics/02-workspace-und-package-anlegen.md create mode 100644 07-ros2-basics/03-erste-node-schreiben.md create mode 100644 07-ros2-basics/04-topics-publishen-und-subscriben.md create mode 100644 07-ros2-basics/05-services-in-ros2-nutzen.md create mode 100644 07-ros2-basics/06-actions-fuer-laengere-bewegungen.md create mode 100644 07-ros2-basics/07-launch-files-und-parameter.md create mode 100644 07-ros2-basics/08-tf-grob-verstehen.md create mode 100644 07-ros2-basics/09-bridge-zur-bestehenden-architektur.md create mode 100644 07-ros2-basics/README.md create mode 100644 08-final-project/01-projekt-skeleton-anlegen.md create mode 100644 08-final-project/02-voice-pipeline-integrieren.md create mode 100644 08-final-project/03-llm-agent-integrieren.md create mode 100644 08-final-project/04-vision-tool-count-people-anschliessen.md create mode 100644 08-final-project/05-face-tool-identify-people-anschliessen.md create mode 100644 08-final-project/06-motion-tool-look-anschliessen.md create mode 100644 08-final-project/07-personensuche-per-scanbewegung.md create mode 100644 08-final-project/08-debug-ui-und-abschlussreflexion.md create mode 100644 08-final-project/README.md create mode 100644 09-extensions/01-fahrende-plattform-bewerten.md create mode 100644 09-extensions/02-slam-einordnen.md create mode 100644 09-extensions/03-navigation-planen.md create mode 100644 09-extensions/04-greifarm-als-erweiterung-bewerten.md create mode 100644 09-extensions/README.md diff --git a/00-course-overview/01-kursziel-und-zielsystem-beschreiben.md b/00-course-overview/01-kursziel-und-zielsystem-beschreiben.md new file mode 100644 index 0000000..e1dbc96 --- /dev/null +++ b/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? diff --git a/00-course-overview/02-hardware-empfehlungen-pruefen.md b/00-course-overview/02-hardware-empfehlungen-pruefen.md new file mode 100644 index 0000000..f0dbd4b --- /dev/null +++ b/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? diff --git a/00-course-overview/03-software-setup-vorbereiten.md b/00-course-overview/03-software-setup-vorbereiten.md new file mode 100644 index 0000000..cb7eb1e --- /dev/null +++ b/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? diff --git a/00-course-overview/04-lernstrategie-und-projekttagebuch.md b/00-course-overview/04-lernstrategie-und-projekttagebuch.md new file mode 100644 index 0000000..bde9b6a --- /dev/null +++ b/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? diff --git a/00-course-overview/05-sicherheit-und-datenschutz-festlegen.md b/00-course-overview/05-sicherheit-und-datenschutz-festlegen.md new file mode 100644 index 0000000..abdfc35 --- /dev/null +++ b/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? diff --git a/00-course-overview/README.md b/00-course-overview/README.md new file mode 100644 index 0000000..3a4768d --- /dev/null +++ b/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. diff --git a/01-ai-agent-basics/01-llm-api-per-cli-ansprechen.md b/01-ai-agent-basics/01-llm-api-per-cli-ansprechen.md new file mode 100644 index 0000000..67f61ee --- /dev/null +++ b/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? diff --git a/01-ai-agent-basics/01-llm-api.md b/01-ai-agent-basics/01-llm-api.md deleted file mode 100644 index 3155995..0000000 --- a/01-ai-agent-basics/01-llm-api.md +++ /dev/null @@ -1,43 +0,0 @@ -# Aufgabe 01: LLM per Code ansprechen - -## Ziel - -Du baust ein minimales Programm, das eine Chat-Anfrage an ein LLM sendet und die Antwort ausgibt. - -## Aufgabe - -Baue eine kleine CLI-Anwendung: - -```text -$ ask "Erkläre mir Servos in 3 Sätzen" -``` - -Die Anwendung soll: - -- eine User-Nachricht entgegennehmen -- sie an ein LLM schicken -- die Antwort auf stdout ausgeben - -## Varianten - -Starte mit einer Variante: - -- OpenAI API -- lokales Ollama per HTTP API - -## Lernpunkte - -- Wie sieht eine Chat-Message-Struktur aus? -- Was ist System/User/Assistant? -- Wie unterscheidet sich lokales LLM von API-LLM? -- Wie gehst du mit Fehlern, Timeouts und Rate Limits um? - -## Akzeptanzkriterien - -- Du kannst per Terminal eine Frage stellen. -- Die Antwort kommt vom Modell. -- Fehler werden sauber angezeigt, nicht per `unwrap()` beendet. - -## Erweiterung - -Speichere den kompletten Request und Response als JSON in einem `logs/`-Ordner. \ No newline at end of file diff --git a/01-ai-agent-basics/02-ollama-und-cloud-api-vergleichen.md b/01-ai-agent-basics/02-ollama-und-cloud-api-vergleichen.md new file mode 100644 index 0000000..df00dbd --- /dev/null +++ b/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? diff --git a/01-ai-agent-basics/02-tool-calling.md b/01-ai-agent-basics/02-tool-calling.md deleted file mode 100644 index f6eed7e..0000000 --- a/01-ai-agent-basics/02-tool-calling.md +++ /dev/null @@ -1,55 +0,0 @@ -# Aufgabe 02: Tool Calling simulieren - -## Ziel - -Du lernst, wie ein LLM nicht nur Text erzeugt, sondern Aktionen auslösen kann. - -## Szenario - -Der User fragt: - -```text -Wie viele Personen sind im Raum? -``` - -Das LLM soll nicht raten, sondern ein Tool anfordern: - -```json -{ - "tool": "count_people", - "arguments": {} -} -``` - -## Aufgabe - -Baue ein Programm mit mindestens 3 Tools: - -- `get_time()` -- `count_people()` - erstmal fake: gibt z. B. `2` zurück -- `look(direction)` - erstmal fake: gibt `looked left` zurück - -Das Programm soll: - -1. User-Input entgegennehmen -2. LLM entscheiden lassen, ob ein Tool nötig ist -3. Tool ausführen -4. Ergebnis zurück ans LLM geben -5. finale Antwort ausgeben - -## Lernpunkte - -- Warum Tool Calling für Robotik zentral ist -- Warum ein LLM nicht direkt Motoren steuern sollte -- Wie man Tools typisiert und validiert -- Wie man gefährliche Aktionen begrenzt - -## Akzeptanzkriterien - -- Frage nach Uhrzeit ruft `get_time()` auf. -- Frage nach Personen ruft `count_people()` auf. -- Befehl "schau nach links" ruft `look("left")` auf. - -## Erweiterung - -Logge jeden Tool-Call mit Timestamp, Argumenten und Ergebnis. \ No newline at end of file diff --git a/01-ai-agent-basics/03-chat-messages-modellieren.md b/01-ai-agent-basics/03-chat-messages-modellieren.md new file mode 100644 index 0000000..20b21e6 --- /dev/null +++ b/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? diff --git a/01-ai-agent-basics/04-system-prompt-entwerfen.md b/01-ai-agent-basics/04-system-prompt-entwerfen.md new file mode 100644 index 0000000..befd26f --- /dev/null +++ b/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? diff --git a/01-ai-agent-basics/05-conversation-history-verwalten.md b/01-ai-agent-basics/05-conversation-history-verwalten.md new file mode 100644 index 0000000..2feb6a7 --- /dev/null +++ b/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? diff --git a/01-ai-agent-basics/06-json-tool-schema-definieren.md b/01-ai-agent-basics/06-json-tool-schema-definieren.md new file mode 100644 index 0000000..f5e480d --- /dev/null +++ b/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? diff --git a/01-ai-agent-basics/07-tool-dispatcher-bauen.md b/01-ai-agent-basics/07-tool-dispatcher-bauen.md new file mode 100644 index 0000000..0c6bb3b --- /dev/null +++ b/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? diff --git a/01-ai-agent-basics/08-agent-loop-implementieren.md b/01-ai-agent-basics/08-agent-loop-implementieren.md new file mode 100644 index 0000000..09fda72 --- /dev/null +++ b/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? diff --git a/01-ai-agent-basics/09-fehlerbehandlung-logging-und-memory.md b/01-ai-agent-basics/09-fehlerbehandlung-logging-und-memory.md new file mode 100644 index 0000000..abebfa3 --- /dev/null +++ b/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? diff --git a/01-ai-agent-basics/README.md b/01-ai-agent-basics/README.md new file mode 100644 index 0000000..2370f26 --- /dev/null +++ b/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. diff --git a/02-voice-interface/01-mikrofon-aufnehmen-und-speichern.md b/02-voice-interface/01-mikrofon-aufnehmen-und-speichern.md new file mode 100644 index 0000000..5a769f8 --- /dev/null +++ b/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? diff --git a/02-voice-interface/01-speech-to-text.md b/02-voice-interface/01-speech-to-text.md deleted file mode 100644 index 715ce26..0000000 --- a/02-voice-interface/01-speech-to-text.md +++ /dev/null @@ -1,38 +0,0 @@ -# Aufgabe 01: Sprache zu Text - -## Ziel - -Du baust ein kleines Programm, das Audio vom Mikrofon aufnimmt und in Text umwandelt. - -## Aufgabe - -Baue eine CLI-Anwendung: - -```text -$ listen -Du hast gesagt: "Wie viele Personen sind im Raum?" -``` - -Nutze dafür zuerst eine einfache Lösung: - -- Whisper -- faster-whisper -- oder eine andere lokale STT-Lösung - -## Lernpunkte - -- Audio aufnehmen -- WAV/PCM-Grundlagen -- Samplingrate -- Latenz -- Push-to-talk vs. dauerhaftes Zuhören - -## Akzeptanzkriterien - -- Du kannst 3 Sekunden Audio aufnehmen. -- Das Audio wird transkribiert. -- Der erkannte Text wird ausgegeben. - -## Erweiterung - -Baue Push-to-talk: Aufnahme startet erst, wenn du Enter drückst. \ No newline at end of file diff --git a/02-voice-interface/02-push-to-talk-cli-bauen.md b/02-voice-interface/02-push-to-talk-cli-bauen.md new file mode 100644 index 0000000..48b9bcb --- /dev/null +++ b/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? diff --git a/02-voice-interface/02-text-to-speech.md b/02-voice-interface/02-text-to-speech.md deleted file mode 100644 index 29f712e..0000000 --- a/02-voice-interface/02-text-to-speech.md +++ /dev/null @@ -1,39 +0,0 @@ -# Aufgabe 02: Text zu Sprache - -## Ziel - -Dein Programm soll nicht nur Text ausgeben, sondern hörbar antworten. - -## Aufgabe - -Baue eine CLI-Anwendung: - -```text -$ say "Hallo Matthias, ich bin bereit." -``` - -Das Programm soll den Text über Lautsprecher ausgeben. - -## Mögliche Tools - -- Piper -- Kokoro -- systemeigene TTS-Tools -- Cloud-TTS - -## Lernpunkte - -- Sprachsynthese -- Latenz -- lokale vs. Cloud-TTS -- Audio-Ausgabe unter Linux - -## Akzeptanzkriterien - -- Ein Text kann als Sprache ausgegeben werden. -- Die Ausgabe funktioniert mehrfach hintereinander. -- Fehler bei fehlendem Audiogerät werden verständlich angezeigt. - -## Erweiterung - -Baue eine kleine Queue, damit mehrere Sätze nacheinander gesprochen werden. \ No newline at end of file diff --git a/02-voice-interface/03-whisper-batch-stt-integrieren.md b/02-voice-interface/03-whisper-batch-stt-integrieren.md new file mode 100644 index 0000000..c93523a --- /dev/null +++ b/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? diff --git a/02-voice-interface/04-streaming-vs-batch-bewerten.md b/02-voice-interface/04-streaming-vs-batch-bewerten.md new file mode 100644 index 0000000..1a396d1 --- /dev/null +++ b/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? diff --git a/02-voice-interface/05-text-to-speech-erzeugen.md b/02-voice-interface/05-text-to-speech-erzeugen.md new file mode 100644 index 0000000..e2f06b3 --- /dev/null +++ b/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? diff --git a/02-voice-interface/06-audio-queue-einfuehren.md b/02-voice-interface/06-audio-queue-einfuehren.md new file mode 100644 index 0000000..96ccd6e --- /dev/null +++ b/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? diff --git a/02-voice-interface/07-voice-pipeline-verbinden.md b/02-voice-interface/07-voice-pipeline-verbinden.md new file mode 100644 index 0000000..64ecb82 --- /dev/null +++ b/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? diff --git a/02-voice-interface/08-wake-word-als-optionaler-prototyp.md b/02-voice-interface/08-wake-word-als-optionaler-prototyp.md new file mode 100644 index 0000000..fb84ca4 --- /dev/null +++ b/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? diff --git a/02-voice-interface/README.md b/02-voice-interface/README.md new file mode 100644 index 0000000..5bdad6b --- /dev/null +++ b/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. diff --git a/03-computer-vision/01-camera-feed.md b/03-computer-vision/01-camera-feed.md deleted file mode 100644 index 1bdd5bd..0000000 --- a/03-computer-vision/01-camera-feed.md +++ /dev/null @@ -1,34 +0,0 @@ -# Aufgabe 01: Kamera-Feed anzeigen - -## Ziel - -Du lernst, ein Kamerabild per Code zu lesen und anzuzeigen. - -## Aufgabe - -Baue ein Programm, das eine USB-Kamera öffnet und den Live-Feed anzeigt. - -## Mögliche Tools - -- Python + OpenCV -- Rust + opencv crate - -Empfehlung: Starte mit Python, damit du schneller Ergebnisse bekommst. - -## Lernpunkte - -- Kamera-Device öffnen -- Frames lesen -- FPS verstehen -- Auflösung einstellen -- Fehler behandeln, wenn keine Kamera gefunden wird - -## Akzeptanzkriterien - -- Live-Bild wird angezeigt. -- Programm beendet sauber mit `q` oder Ctrl+C. -- Kamera wird beim Beenden freigegeben. - -## Erweiterung - -Zeige FPS und Auflösung im Bild an. \ No newline at end of file diff --git a/03-computer-vision/01-kamera-oeffnen-und-frames-anzeigen.md b/03-computer-vision/01-kamera-oeffnen-und-frames-anzeigen.md new file mode 100644 index 0000000..712320d --- /dev/null +++ b/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? diff --git a/03-computer-vision/02-count-people.md b/03-computer-vision/02-count-people.md deleted file mode 100644 index 95f4c38..0000000 --- a/03-computer-vision/02-count-people.md +++ /dev/null @@ -1,48 +0,0 @@ -# Aufgabe 02: Personen zählen - -## Ziel - -Dein System soll erkennen, wie viele Personen im Kamerabild sichtbar sind. - -## Aufgabe - -Baue ein Programm: - -```text -$ count-people -Ich sehe 2 Personen. -``` - -## Mögliche Ansätze - -- YOLO-Modell verwenden -- OpenCV DNN -- fertige Python-Bibliothek für Object Detection - -## Lernpunkte - -- Object Detection vs. Classification -- Bounding Boxes -- Confidence Scores -- Klassenfilterung auf `person` -- Performance auf CPU vs. GPU - -## Akzeptanzkriterien - -- Personen werden im Bild mit Bounding Box markiert. -- Anzahl der Personen wird angezeigt. -- Niedrige Confidence-Werte werden gefiltert. - -## Erweiterung - -Biete das Ganze als HTTP-Endpoint an: - -```text -GET /vision/people/count -``` - -Antwort: - -```json -{"count": 2} -``` \ No newline at end of file diff --git a/03-computer-vision/02-frames-lesen-und-bilder-speichern.md b/03-computer-vision/02-frames-lesen-und-bilder-speichern.md new file mode 100644 index 0000000..154d86e --- /dev/null +++ b/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? diff --git a/03-computer-vision/03-fps-und-latenz-messen.md b/03-computer-vision/03-fps-und-latenz-messen.md new file mode 100644 index 0000000..9076790 --- /dev/null +++ b/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? diff --git a/03-computer-vision/04-opencv-grundlagen-anwenden.md b/03-computer-vision/04-opencv-grundlagen-anwenden.md new file mode 100644 index 0000000..6705a5c --- /dev/null +++ b/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? diff --git a/03-computer-vision/05-bounding-boxes-zeichnen.md b/03-computer-vision/05-bounding-boxes-zeichnen.md new file mode 100644 index 0000000..af91675 --- /dev/null +++ b/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? diff --git a/03-computer-vision/06-yolo-oder-detector-integrieren.md b/03-computer-vision/06-yolo-oder-detector-integrieren.md new file mode 100644 index 0000000..b27856c --- /dev/null +++ b/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? diff --git a/03-computer-vision/07-personen-zaehlen.md b/03-computer-vision/07-personen-zaehlen.md new file mode 100644 index 0000000..be54d75 --- /dev/null +++ b/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? diff --git a/03-computer-vision/08-confidence-und-nms-verstehen.md b/03-computer-vision/08-confidence-und-nms-verstehen.md new file mode 100644 index 0000000..c69ae36 --- /dev/null +++ b/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? diff --git a/03-computer-vision/09-http-vision-service-bauen.md b/03-computer-vision/09-http-vision-service-bauen.md new file mode 100644 index 0000000..1c86829 --- /dev/null +++ b/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? diff --git a/03-computer-vision/README.md b/03-computer-vision/README.md new file mode 100644 index 0000000..b4d4b11 --- /dev/null +++ b/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. diff --git a/04-face-recognition/01-face-detection-testen.md b/04-face-recognition/01-face-detection-testen.md new file mode 100644 index 0000000..4b0ba5f --- /dev/null +++ b/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? diff --git a/04-face-recognition/01-known-faces.md b/04-face-recognition/01-known-faces.md deleted file mode 100644 index f05f7fa..0000000 --- a/04-face-recognition/01-known-faces.md +++ /dev/null @@ -1,48 +0,0 @@ -# Aufgabe 01: Bekannte Personen erkennen - -## Ziel - -Das System soll nicht nur Personen zählen, sondern bekannte Gesichter unterscheiden. - -## Aufgabe - -Baue einen kleinen `faces/`-Ordner: - -```text -faces/ - matthias/ - 01.jpg - 02.jpg - lisa/ - 01.jpg -``` - -Dann soll dein Programm im Kamerabild sagen: - -```text -Ich sehe Matthias. -``` - -## Lernpunkte - -- Face Detection -- Face Embeddings -- Ähnlichkeitsvergleich -- False Positives -- Datenschutz und Consent - -## Akzeptanzkriterien - -- Mindestens eine bekannte Person kann erkannt werden. -- Unbekannte Personen werden als `unknown` markiert. -- Das System behauptet nicht mit 100 % Sicherheit, jemanden zu erkennen. - -## Erweiterung - -Baue einen Befehl: - -```text -$ enroll-person "Matthias" -``` - -Der mehrere Bilder aufnimmt und als Referenz speichert. \ No newline at end of file diff --git a/04-face-recognition/02-face-embeddings-berechnen.md b/04-face-recognition/02-face-embeddings-berechnen.md new file mode 100644 index 0000000..dc00a9b --- /dev/null +++ b/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? diff --git a/04-face-recognition/03-bekannte-personen-enrollen.md b/04-face-recognition/03-bekannte-personen-enrollen.md new file mode 100644 index 0000000..8a63d9e --- /dev/null +++ b/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? diff --git a/04-face-recognition/04-unbekannte-personen-erkennen.md b/04-face-recognition/04-unbekannte-personen-erkennen.md new file mode 100644 index 0000000..cb9acdc --- /dev/null +++ b/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? diff --git a/04-face-recognition/05-schwellenwerte-und-false-positives-testen.md b/04-face-recognition/05-schwellenwerte-und-false-positives-testen.md new file mode 100644 index 0000000..2c50cd2 --- /dev/null +++ b/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? diff --git a/04-face-recognition/06-face-recognition-service-bauen.md b/04-face-recognition/06-face-recognition-service-bauen.md new file mode 100644 index 0000000..e0164d7 --- /dev/null +++ b/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? diff --git a/04-face-recognition/07-agent-tool-identify-people-integrieren.md b/04-face-recognition/07-agent-tool-identify-people-integrieren.md new file mode 100644 index 0000000..acf4140 --- /dev/null +++ b/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? diff --git a/04-face-recognition/README.md b/04-face-recognition/README.md new file mode 100644 index 0000000..be49bee --- /dev/null +++ b/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. diff --git a/05-robot-motion/01-servo-basics.md b/05-robot-motion/01-servo-basics.md deleted file mode 100644 index 1030797..0000000 --- a/05-robot-motion/01-servo-basics.md +++ /dev/null @@ -1,43 +0,0 @@ -# Aufgabe 01: Einen Servo bewegen - -## Ziel - -Du lernst, einen Servo-Motor gezielt auf Winkelpositionen zu bewegen. - -## Aufgabe - -Baue ein Programm: - -```text -$ servo --angle 90 -``` - -Der Servo soll auf 90 Grad fahren. - -## Hardware-Ideen - -- Raspberry Pi GPIO -- PCA9685 Servo-Controller -- Arduino/RP2040 als Servo-Controller mit serieller Schnittstelle - -## Lernpunkte - -- PWM -- Servo-Winkel -- Stromversorgung für Servos -- Warum Servos nicht direkt vom Pi versorgt werden sollten -- Jitter und Kalibrierung - -## Akzeptanzkriterien - -- Servo fährt auf 0, 90 und 180 Grad. -- Winkelgrenzen sind konfigurierbar. -- Falsche Winkel werden abgelehnt. - -## Erweiterung - -Baue eine sanfte Bewegung: - -```text -$ servo --from 20 --to 120 --duration 2s -``` \ No newline at end of file diff --git a/05-robot-motion/01-servo-grundlagen-verstehen.md b/05-robot-motion/01-servo-grundlagen-verstehen.md new file mode 100644 index 0000000..8c9b39c --- /dev/null +++ b/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? diff --git a/05-robot-motion/02-pan-tilt-head.md b/05-robot-motion/02-pan-tilt-head.md deleted file mode 100644 index 2d4dee7..0000000 --- a/05-robot-motion/02-pan-tilt-head.md +++ /dev/null @@ -1,42 +0,0 @@ -# Aufgabe 02: Pan-Tilt-Kopf bauen - -## Ziel - -Du baust einen einfachen Roboterkopf mit zwei Servos: - -- Pan: links/rechts -- Tilt: hoch/runter - -## Aufgabe - -Baue Befehle: - -```text -$ head look-left -$ head look-right -$ head look-center -$ head look-up -$ head look-down -``` - -## Lernpunkte - -- Koordinatensystem für Kopfbewegung -- sichere Winkelbereiche -- Nullposition/Kalibrierung -- sanfte Bewegungen statt ruckartiger Sprünge - -## Akzeptanzkriterien - -- Kopf kann nach links, rechts, oben, unten und zur Mitte schauen. -- Bewegungen sind begrenzt und beschädigen die Mechanik nicht. -- Es gibt eine zentrale Konfigurationsdatei für Min-/Max-Winkel. - -## Erweiterung - -Baue ein HTTP-API: - -```text -POST /motion/head/look -{"pan": 30, "tilt": -10} -``` \ No newline at end of file diff --git a/05-robot-motion/02-pwm-und-winkel-kalibrieren.md b/05-robot-motion/02-pwm-und-winkel-kalibrieren.md new file mode 100644 index 0000000..1e5e8f8 --- /dev/null +++ b/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? diff --git a/05-robot-motion/03-stromversorgung-und-not-aus-planen.md b/05-robot-motion/03-stromversorgung-und-not-aus-planen.md new file mode 100644 index 0000000..4e59053 --- /dev/null +++ b/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? diff --git a/05-robot-motion/04-pan-tilt-kopf-montieren.md b/05-robot-motion/04-pan-tilt-kopf-montieren.md new file mode 100644 index 0000000..c9f29ac --- /dev/null +++ b/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? diff --git a/05-robot-motion/05-sichere-winkelbereiche-erzwingen.md b/05-robot-motion/05-sichere-winkelbereiche-erzwingen.md new file mode 100644 index 0000000..9a0ce25 --- /dev/null +++ b/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? diff --git a/05-robot-motion/06-sanfte-bewegungen-implementieren.md b/05-robot-motion/06-sanfte-bewegungen-implementieren.md new file mode 100644 index 0000000..685ac45 --- /dev/null +++ b/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? diff --git a/05-robot-motion/07-motion-api-bereitstellen.md b/05-robot-motion/07-motion-api-bereitstellen.md new file mode 100644 index 0000000..f6ed22e --- /dev/null +++ b/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? diff --git a/05-robot-motion/08-agent-tool-look-integrieren.md b/05-robot-motion/08-agent-tool-look-integrieren.md new file mode 100644 index 0000000..f9fcdab --- /dev/null +++ b/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? diff --git a/05-robot-motion/09-person-im-bild-zentrieren.md b/05-robot-motion/09-person-im-bild-zentrieren.md new file mode 100644 index 0000000..b8df501 --- /dev/null +++ b/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? diff --git a/05-robot-motion/README.md b/05-robot-motion/README.md new file mode 100644 index 0000000..52ea219 --- /dev/null +++ b/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. diff --git a/06-system-architecture/01-service-schnitt-entwerfen.md b/06-system-architecture/01-service-schnitt-entwerfen.md new file mode 100644 index 0000000..ac9bcf9 --- /dev/null +++ b/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? diff --git a/06-system-architecture/02-rust-orchestrator-skizzieren.md b/06-system-architecture/02-rust-orchestrator-skizzieren.md new file mode 100644 index 0000000..64298d0 --- /dev/null +++ b/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? diff --git a/06-system-architecture/03-python-vision-service-isolieren.md b/06-system-architecture/03-python-vision-service-isolieren.md new file mode 100644 index 0000000..2064066 --- /dev/null +++ b/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? diff --git a/06-system-architecture/04-voice-service-abgrenzen.md b/06-system-architecture/04-voice-service-abgrenzen.md new file mode 100644 index 0000000..702e021 --- /dev/null +++ b/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? diff --git a/06-system-architecture/05-rest-grpc-und-mqtt-vergleichen.md b/06-system-architecture/05-rest-grpc-und-mqtt-vergleichen.md new file mode 100644 index 0000000..4247209 --- /dev/null +++ b/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? diff --git a/06-system-architecture/06-event-basierte-kommunikation-einfuehren.md b/06-system-architecture/06-event-basierte-kommunikation-einfuehren.md new file mode 100644 index 0000000..d794265 --- /dev/null +++ b/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? diff --git a/06-system-architecture/07-docker-compose-fuer-services.md b/06-system-architecture/07-docker-compose-fuer-services.md new file mode 100644 index 0000000..db5adb2 --- /dev/null +++ b/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? diff --git a/06-system-architecture/08-config-management-strukturieren.md b/06-system-architecture/08-config-management-strukturieren.md new file mode 100644 index 0000000..674eab5 --- /dev/null +++ b/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? diff --git a/06-system-architecture/09-observability-und-health-checks.md b/06-system-architecture/09-observability-und-health-checks.md new file mode 100644 index 0000000..a508db7 --- /dev/null +++ b/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? diff --git a/06-system-architecture/README.md b/06-system-architecture/README.md new file mode 100644 index 0000000..6462efa --- /dev/null +++ b/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. diff --git a/07-ros2-basics/01-ros2-zweck-einordnen.md b/07-ros2-basics/01-ros2-zweck-einordnen.md new file mode 100644 index 0000000..fd1367b --- /dev/null +++ b/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? diff --git a/07-ros2-basics/02-workspace-und-package-anlegen.md b/07-ros2-basics/02-workspace-und-package-anlegen.md new file mode 100644 index 0000000..e74ff7c --- /dev/null +++ b/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? diff --git a/07-ros2-basics/03-erste-node-schreiben.md b/07-ros2-basics/03-erste-node-schreiben.md new file mode 100644 index 0000000..962c2c3 --- /dev/null +++ b/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? diff --git a/07-ros2-basics/04-topics-publishen-und-subscriben.md b/07-ros2-basics/04-topics-publishen-und-subscriben.md new file mode 100644 index 0000000..bfe70a5 --- /dev/null +++ b/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? diff --git a/07-ros2-basics/05-services-in-ros2-nutzen.md b/07-ros2-basics/05-services-in-ros2-nutzen.md new file mode 100644 index 0000000..ac093cb --- /dev/null +++ b/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? diff --git a/07-ros2-basics/06-actions-fuer-laengere-bewegungen.md b/07-ros2-basics/06-actions-fuer-laengere-bewegungen.md new file mode 100644 index 0000000..9cbf6d6 --- /dev/null +++ b/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? diff --git a/07-ros2-basics/07-launch-files-und-parameter.md b/07-ros2-basics/07-launch-files-und-parameter.md new file mode 100644 index 0000000..c8dd567 --- /dev/null +++ b/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? diff --git a/07-ros2-basics/08-tf-grob-verstehen.md b/07-ros2-basics/08-tf-grob-verstehen.md new file mode 100644 index 0000000..b6034fd --- /dev/null +++ b/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? diff --git a/07-ros2-basics/09-bridge-zur-bestehenden-architektur.md b/07-ros2-basics/09-bridge-zur-bestehenden-architektur.md new file mode 100644 index 0000000..4f1807c --- /dev/null +++ b/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? diff --git a/07-ros2-basics/README.md b/07-ros2-basics/README.md new file mode 100644 index 0000000..e884fe6 --- /dev/null +++ b/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. diff --git a/08-final-project/01-projekt-skeleton-anlegen.md b/08-final-project/01-projekt-skeleton-anlegen.md new file mode 100644 index 0000000..d300d6f --- /dev/null +++ b/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? diff --git a/08-final-project/02-voice-pipeline-integrieren.md b/08-final-project/02-voice-pipeline-integrieren.md new file mode 100644 index 0000000..aa88e91 --- /dev/null +++ b/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? diff --git a/08-final-project/03-llm-agent-integrieren.md b/08-final-project/03-llm-agent-integrieren.md new file mode 100644 index 0000000..e42d146 --- /dev/null +++ b/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? diff --git a/08-final-project/04-vision-tool-count-people-anschliessen.md b/08-final-project/04-vision-tool-count-people-anschliessen.md new file mode 100644 index 0000000..f52b558 --- /dev/null +++ b/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? diff --git a/08-final-project/05-face-tool-identify-people-anschliessen.md b/08-final-project/05-face-tool-identify-people-anschliessen.md new file mode 100644 index 0000000..e87912f --- /dev/null +++ b/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? diff --git a/08-final-project/06-motion-tool-look-anschliessen.md b/08-final-project/06-motion-tool-look-anschliessen.md new file mode 100644 index 0000000..ad8c2f0 --- /dev/null +++ b/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? diff --git a/08-final-project/07-personensuche-per-scanbewegung.md b/08-final-project/07-personensuche-per-scanbewegung.md new file mode 100644 index 0000000..3095080 --- /dev/null +++ b/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? diff --git a/08-final-project/08-debug-ui-und-abschlussreflexion.md b/08-final-project/08-debug-ui-und-abschlussreflexion.md new file mode 100644 index 0000000..aef9f68 --- /dev/null +++ b/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? diff --git a/08-final-project/README.md b/08-final-project/README.md new file mode 100644 index 0000000..422a782 --- /dev/null +++ b/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. diff --git a/09-extensions/01-fahrende-plattform-bewerten.md b/09-extensions/01-fahrende-plattform-bewerten.md new file mode 100644 index 0000000..65386bd --- /dev/null +++ b/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? diff --git a/09-extensions/02-slam-einordnen.md b/09-extensions/02-slam-einordnen.md new file mode 100644 index 0000000..378dc8d --- /dev/null +++ b/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? diff --git a/09-extensions/03-navigation-planen.md b/09-extensions/03-navigation-planen.md new file mode 100644 index 0000000..11d302b --- /dev/null +++ b/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? diff --git a/09-extensions/04-greifarm-als-erweiterung-bewerten.md b/09-extensions/04-greifarm-als-erweiterung-bewerten.md new file mode 100644 index 0000000..357205f --- /dev/null +++ b/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? diff --git a/09-extensions/README.md b/09-extensions/README.md new file mode 100644 index 0000000..80dd792 --- /dev/null +++ b/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. diff --git a/README.md b/README.md index 943067d..7b42499 100644 --- a/README.md +++ b/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. \ No newline at end of file +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.