+ Protokoll Robotik

Protokoll vom 13.12.02

Simulation des Roboters existiert. Funktionalität im wesentlichen zur Zeit:

• move x y alpha (Position)
• Karte ist eine Menge von Linien
• Roboter kann Wegplanung zu neuer Position und Bewegung
• Feedback: Hindernisse werden gemeldet, Planbarkeit (ist Position überhaupt erreichbar)
• Kamerabilder können angezeigt werden

Szenario: Überwachung

• ist Schaum auf Kessel? (Schaum -> nicht gut, soll irgendwas reingetan werden)
• Kamerabild

Interaktivität?

• aus Kommandos wird in Standardszenarien ein Arbeitsablauf definiert
• Lernakt: sprachliches Teach-In? Hier ist Bottich 5

Satz: "zentrifugiere Probe b"

• wo ist Probe b? wo muss sie zentrifugiert werden?
• sollen wir die Wissensrepräsentation mitmachen? Speichern von Labels/Räumen/... -> ja, machen wir.
• wir setzen das in move-Anweisungen um

Initialisierung: Schätzung von Position, Karte als Linien, Roboter macht Lokalisation selbst, Planung macht er, Abfragen von Sensoren

Unsere Szenarien:

• Krankenhaus (Pillen)
• Bibliothek
• Küche
• Briefe/Dinge zwischen Personen transportieren (München: Roboter kommt auf e-mail, liefert auf Tablett)
• Universitätsszenario (Roboter fährt zwischen Uni-Räumen hin und her)
  • Beispiel Räume suchen: Türschilderkennung
  • "gehe zu Walter" -> fährt in falschen Raum (Zuordnung hat sich geändert) -> Person informiert Roboter (Walter sitzt nebenan)
• woher weiss Roboter dass Raum "falsch"? Gesichtserkennung? Sprache?
• Sprecheridentifikation?
• Walter erkältet?

Stichabstimmung Robotik vs. Formeln: 7 für Robotik (Mehrheit)

Jetzt benötigt:

• Simulationssoftware
• mögliche Befehle
  • move Position x y alpha
  • rotate Grad
  • translate Entfernung
  • getPosition -> x y alpha
  • Anzeige Laserscan (Information Marken, Hindernisse)
  • Wahl der Roboter (bei mehreren)
  • Teachbefehle: savePosition (aber: wir muessen Wissenrepräsentation machen)
• bisher: nur moveBefehle, weil nur diese "machbar" sind und simuliert werden
• wenn wir andere brauchen (Armbewegung,...), dann müssen wir das selbst machen
• Kamera an/aus
• Alternativ: Bielefeld: Zentrifuge
• Problem: Bewegung des Arms ist bis Sommer nicht drin
• fest einprogrammierte Bewegungen für Arm
• Idee: Armsteuerung: hoch runter rechts links (Spacemaus)
• aber: sowas wie "nimm Buch" mit noch nie zuvor gesehenem Buch absolut utopisch
  • Erkennung nicht möglich
  • Bewegungsplanung nicht möglich
• bestehende Systeme (Bibliotheken,...) sind auf feste Positionen usw. angewiesen
• garantieren dass etwas funktioniert ist schwer
  • Beispiel: Arm bricht im "aufmachen"-Schritt ab
  • ... weil: Deckel war (wie noch nie vorher) eingehakt
  • => beibringen problematisch

Vorteile von begrenzten Szenarien: Krankenhaus, Laborumgebung

• immer ordentlich, Schritte vorher bekannt
• Umgebung beschränkt
• Laborumgebung ist als Modell vorhanden
  • Karte existiert
  • Information über Arbeitsschritte bekannt
  • Datenbank (Reagenzglashalter: Position3, Probe xyz)
    • => "entnimm Probe 34"

Linienformkarten von Unifluren:

• 4. Flur (WSV) auch vorhanden
• muss so oder so für Robotik "hier" erstellt werden

Laborszenario...?

• ist nicht unbedingt langfristiges Ziel von TAMS
• nur ein Raum im Szenario

Generelles Modell aller dieser Szenarien:

• Karte, Bewegung
• Objekte, Aktionen

Mehrraumszenarien haben den Vorteil einer höheren Komplexität. Interaktivität?

• Labor: da Roboter für Routinearbeiten da ist wenig Interaktion
• Krankenhaus: bringe dies da und da hin...
• Uniflur: statt e-mails Zettel/Objekte transportieren

Abstimmung

Szenario	Stimmen
Krankenhaus	2
Labore	2
Uniflur	5

Karte: xfig-Karte für Flur 4 existiert, sollte untersucht werden

Arbeitsaufträge:

• Szenariomodellierung: Aufgaben
  • Versprachlichung von Kommandos: BeispielSaetze
  • Languagemodell
  • WOZ-Experimente (Person im Nebenraum steuert beispielsweise Simulator)
  • Lev, Alex, Maximilian
• Sprachliche Interpretation (Parsing, Semantik)
  • semantisches Lexikon
  • Grammatikentwicklung, Interpretationsregeln
  • Daniel, StephanMahnkopf, Yannick, Alex
• Anbindung des Roboters
  • Karte
  • Protokoll/Simulationsumgebung
  • Datenbasis von unserer Welt: Objekte, Personen, Räume, Aktionen
    • => sind nicht im Simulator verfügbar
  • Annette, Oliver, Lev
• Spracherkenner (Training, Design)
  • Aussprachewörterbuch
  • StefanWesterfeld, Maximilian, Sven, Solomon

Dialogmodell?

• zunächst: Kommando -> Ergebnis kommt zurück

Parsing mit fester Grammatik? Oder stochastische Sprachmodellierung?

• stochast. Sprachdaten: mit Textdaten
  • wir haben aber keine Beispieltexte zur Zeit
  • Ausweg: Grammatik -> Languagemodell

Sprachsignal => Erkennung => semantische Interpretation => Steuerung

Sprachsynthese und Interaktivität?

• zunächst einfacher Kommandointerpreter, später vielleicht noch...

Aufgaben, die direkt erledigt werden müssen:

Alle:

• wie soll das Endprodukt der jeweiligen Gruppe aussehen?

Szenario:

• BeispielSaetze
• wie soll die Welt aussehen?
• hol mir eine Flasche Bier?
  • Probleme: nicht fester Ort, Komplexe Aufgabe: Bierflasche, Öffnen, Glas, ...
• gehe zu Dirk
  • Lokalisation über Datenbasis
  • bei nicht erfüllter Aufgabe: Fallback (dann in Teeküche)
  • Rückfragen?

Interpretation:

• welche Werkzeuge sollen verwendet werden?
  • Prolog? Transformationsregeln
  • constraintbasiertes Parsen? (Laufzeitproblematik, Experimente)

Anbindung:

• welche Personen und Objekte ausser Roboter/Positionen sollen bekannt sein

Erkenner:

• Behandlung unbekannter Wörter?
• stochastisches Sprachmodell?
  • Generierung aus kontextfreier Grammatik?
• Nebengeräusche eines Roboters
  • Lüfter
  • Sonar bei 20000 Hz (knacken)
• Mikrophon
  • auf Roboter aufbauen
    • Integration von Hardware auf dem Roboter problematisch
    • freie Steckplätze, zweiter Rechner Platz/Geldproblem
  • Funkmikrophon
    • Headset
    • Erkennungsraten für Entfernung (->2m) gegen 0 bei freistehendem Mikrophon

-- StefanWesterfeld - 13 Dec 2002