feat: expanded and added more tasks

2026-07-08 23:33:26 +02:00
parent 8fdf69e11f
commit d0b776485a
97 changed files with 3121 additions and 427 deletions
@@ -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?
@@ -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?
@@ -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?
@@ -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?
@@ -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?
@@ -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?
@@ -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?
@@ -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?
@@ -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?
@@ -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.