feat: expanded and added more tasks
This commit is contained in:
@@ -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?
|
||||
@@ -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?
|
||||
@@ -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?
|
||||
@@ -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?
|
||||
@@ -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?
|
||||
@@ -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?
|
||||
@@ -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?
|
||||
@@ -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?
|
||||
@@ -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.
|
||||
Reference in New Issue
Block a user