Szene to text parser mittels feature set

 Als Semantik Gap wird die Lücke bezeichnet zwischen natürlicher Sprache einerseits und Rohdaten welche durch sensoren erhoben wird andererseits. Solange es einen semantic gap gibt, scheitert eine mensch maschine kommunikation. Ein Roboter versteht nicth einen Befehl wie "fahre zum Regal A und entnehme die rote box".

Der Gap wird mittels grounded language geschlossen, was in zwei richtungen verläuft. 

a) Natürliche Sprache -> Sensordaten
b) Sensordaten -> natürliche Sprache

Natürliche Sprache lässt sich mittels feature engineering erzeugen. Ein feature set bezeichnet im Maschinen learning eine Liste von Werten. Für das Beispiel "Überwaschung einer Straßenverkehrskreuzung" sind geeignete features:

- Quelle und Ziel des Autos
- Farbe des Autos
- Größe des Autos
- Geschwindigkeit

Aus diesem Feature set lässt sich eine Sprachausgabe erzeugen wie:

- "Ein blauer Kleinwagen aus nörderlicher Richtung fährt nach Süden. Er fährt sehr langsam".
- "Ein weißer LKW aus Westlicher Richtung fährt nach Süden. Er fährt mittelschnell".

Features im Maschinen learning sind das selbe wie statistische Merkmale in beschreibenden Statistik. Es sind eine Reihe von Werte in einem Statistikbogen die gemessen werden. der Unterschied ist dass im maschine learning diese Daten computerlesbar vorliegen und häufig automatisiert gemessen werden z.B. über Kmaeras und induktionsschleifen im Boden. Das feature set stellt eine zwischenschicht da zwischen sensordaten und natürlicher sprache.

Auf den ersten blick sieht ein feature set nicht besonders anspruchsvoll aus. Es ist eine Liste mit Werte die man als histogram darstellen kann, vergleichbar mit einem Farbhistogram für ein photo. Der entscheidene Vorteil besteht darin dass features eine Zwischenposition einnehmen zwischen sensorrohdaten einerseits und natürlicher Sprache andererseits.

Betriebssysteme für Roboter

 In der Anfangszeit der Heimcomputer in den 1980er Jahren waren Betriebssysteme weitestgehend unbekannt. Zwar hatten 8bit Rechner von Commodore und Atari eigene Betriebssysteme, welche im ROM gespeichert waren, doch diese war sehr klein, hoffnungslos veraltet und wurden meist von der Software durch eigene Routinen ersetzt. Die Software in den 1980er Jahren wurde direkt für die Hardware programmiert ohne Zwischenschicht.

Als das PC Betriebssytsem MS DOS 3.x in 1985 veröffentlicht wurde, war das System noch sehr klein. Es brachte einige tools mit um Dateien auf Festplatte und Diskette zu speichern. Was fehlte waren Soundkartentreiber oder Grafikkartentreiber. Mit Aufkommen des Windows Betriebssystem ab den 1990er wurde der Umfang größer. Betriebssysteme entwickelte sich zur zentralen Steuerzentrale des Computers. Seit damals hat ihre Bedeutung weiter zugenommen, es ist nicht länger möglich Computer ohne Betriebssystem zu betreiben.

In der Robotik ist die Situation derzeit so dass es keine Betriebssysteme gibt und auch keinen Bedarf nach einer solchen Zwischenschicht. betriebssysteme für Roboter funktionieren anders als bei einem PC. Bei der Robotik muss die semantische Lücke geschlossen werden, also die zwischen Sensordaten und textueller Representation. Folglich muss das Betriebssystem zwischen diesen Layer vermitteln.

Vielleicht dazu einige Beispiele. Angenommen ein Roboter detektiert mit seinem Sensor ein Hinderniss vor sich was rot ist. Aufgabe des Betriebssystems also des vision language action models ist es auf den Bildschirm auszugeben "Rotes Hinderniss vor dem Roboter erkannt". In einem zweiten Beispiel gibt ein menschlicher Benutzer einen Befehl: "Fahre in die Mitte des Labyrinth und warte dort auf weitere Anweisungen". Es ist Aufgabe des Betriebssystems diese Befehl in eine Trajektorie zu übersetzen und auszuführen.

Die zwei wesentlichen Aufgaben eines Robotik-OS sind: Vision Question answering (VQA) und "instruction following". Beides hat etwas über der Übersetzung von high level Text in low level sensor/actuator Daten zu tun. Es ist die selbe Mittlerrolle welche PC Betriebssystem auch innehaben. Wesentliche Aufgabe von Linux und Co ist es, high level Anfragen der Software wie "speichere eine Datei auf der festplatte" in low level Aktivitäten der Hardware zu übersetzen, also das physische Ansteuern der SSD damit die Datei geschrieben wird.

Semantic gap in a DIKW pyramid

 Before the situation for robotics is explained, the situation for computing in general should be explained. An example for a semantic gap in computer is the missing layer between hardware and software. The hardware of a computer consists of a CPU, a floppy drive, a graphics card and other elements, while the software is formujlated on a high level layer and describe the appearance of a GUI, contains of algorithms and specify the data.

Its not possible to run directly software on the hardware because a dedicated operating system is needed. For today's computer user its common sonse to decide for such an operating system. Someboy prefers MS Dos, another user likes Linux while the next one has installed Windows 11 on his machine.

It was a slow development until operating systems became the standard. During the 1980s most homecomputer didn't had a dedicated operating system or it was very tiny. The situation changed in the 1990s and the situation today is, that operating systems are a standard component of every computer.

In case of robotics there is also a semantic gap available between low level and high level layer. The low level layer is in the DIKW pyramid the sensory data for example a camera picture or a lidar sensor. The high level layer in the dikw pyramid is a textual description of a scene, provided by a chatbot. Between both layers there is gap available, because a camera picture can't be directly converted into a text description. What is needed is a converter, some sort of robot operating system which closes the gap.

The common name for such a tool is "Vision language action model" be definition such a model, realized as a neural network, is able to translate back and forth between images and text. The prediction is that future robotics after the year 2030 will have such a VQA module built in as default, similar to an operating system in a computer. The VQA module ensures that robot tasks can be specified in natural language.

DIKW pyramid as blueprint for Artificial Intelligence

 A DIKW pyramid divides facts into separate layers:

- low level = sensory data, e.g. color=(20,10,178), distance=2 meter
- mid level= label space, e.g. [bluecolor], [mediumdistance], [baterryfull]
- high level = knowledge. e.g. "bring me the blue box from room A"

Its not an algorithm but a data representation format, similar to the Unicode table. After implementing the DIWK pyramid as a computer program its possible to interact with the robot in natural language. The human operator formulates a request on the high level layer, e.g. "bring me the blue box" and this request is translated into mid level and low level.

The principle is similar to the TCP/IP protocol layer which allows divides communication into layers for reducing complexity. The working thesis is, that a dikw pyramid can explain what artificial intelligence is about. If the robot has access to a DIKW pyramid, the robot is intelligent.

The main purpose of a DIKW pyramid is to act as an interface between internal world and external world. The low level layer is located inside the robot, while the high level layer is located outside of the robot. Communication means to transmit messages physical but also translate the message between the layers.

KI als Mapping problem in der DIKW pyramide

 Zumindest bis in die 2000er Jahre wurde Künstliche Intelligenz so definiert, dass menschliches Denken mit Hilfe eines Computers simuliert werden soll. Aufbauend auf dieser Definition wurden mehrere Strategien und Algorithmen diskutiert, die jedoch das selbst definierte Ziel nicht zu erreichen vermochten. Der wohl erfolgreichste Algorithmus der KI Forschung bis zum Jahr 2000 war der bekannte Minimax Algorithmus um Schach von einem Computer spielen zu können. Dieser Algorithmus war so erfolgreich, dass er sogar Großmeister schlagen konnte. Nur, Minimax lässt sich nicht auf Robotik-Probleme verallgemeinern.

Eine neuere und weniger bekannte Definition von Künstlicher Intelligenz lautet dass es ein Zuordnungsproblem ist zwischen low level daten und high leven natürlicher Sprache. Dieses Zuordnungsproblem entsteht innerhalb der DIKW pyramide (data, information, knowledge, wisdom). Vielleicht ein kleines Beispiel:

Über Motion capture wird die Bewegung eines menschlichen Aktors aufgezeichnet. Die x/y/z position der Mocap Marker sind Daten und gehören zum Data layer der DIKW pyramide. Jetzt soll über Mustererkennungsverfahren ermittelt werden, welche Pose der menschliche Aktor gerade ausführt. Diesre kann gehen, rennen, sitzen oder springen. Diese Labels werden im Information layer der DIKW pyramide gespeichert. Aufgabe für die Künstliche Intelligenz ist es jetzt zwischen beiden layern eine Zuordnung herzustellen. Es geht also um die Frage wie eine mathematische Realität auf eine linguistische Realität projiziert werden kann.

Die naheliegende Frage lautet: Warum muss der mathematische Raum der Mocap Marker auf einen linguistischen Raum der textuellen Label projiziert werden? Kann man die Steuerung von Robotern nicht auch eleganter/einfacher beschreiben?

Die Notwendigkeit der Sprachlichen Enkodierung ergibt sich aus dem Kommunikationserfordernis. Es reicht nicht, die mocap Marker als x/y/z position zu speichern, sondern zusätzlich soll einem außenstehender Beobachter in natürlicher Sprache übermittelt werden, was genau der Aktor gerade tut. Ziel ist weniger ein System intern zu beschreiben, sondern Zielstellung ist mit einem 2. System zu kommunizieren. 

KI Forschung bis ca. zum Jahr 2000 war geprägt von der closed system Hypothese. Ziel war stets das interne Funktionieren eines Computers zu optimieren durch bessere Algorithmen, schnellere Programmiersprachen oder spezielle Datenbanken wie Cyc. Im Gegensatz dazu verfolgt KI Forschung ab dem Jahr 2000 das Ziel, die Kommunikation zwischen zwei Systemen zu verbessern. Die Frage lautet stets: wie kommunizieren zwei Menschen miteinander? Wie interagiert ein Mensch mit einem Roboter? Welche Interaktionsspiele zwischen einem Speaker und einem Hearer gibt es?

Selbstverständlich ist die obige Beschreibung stark vereinfachend. Auch vor dem Jahr 2000 gab es Versuche die Mensch-Maschine Interaktion zu verbessern:

- 1968,SHRDLU natural language understanding by Terry Winograd
- 1987,Vitra visual translator
- 1998,Rocco Robocup commentator by Dirk Voelz

Man könnte z.B. SHRDLU als Vorläufer heutiger Vision Language action (VLA) Modelle beschreiben. Anzahlmäßig waren jedoch KI Projekte, die natürliche Sprache als Kommunikationsschnittstelle verwendeten eher die Ausnahme. Es war vor dem Jahr 2000 unklar, dass dies wichtig ist und es war unklar wie man eine solche Schnittstelle technisch realisieren könnte. Hinzu kommt dass ein interdisziplinärer Ansatz bestehend aus Mathematik und Lingustik vor dem Jahr 2000 unüblich war. 

DIKW pyramid for motion capture annotation

 

Dataset for grounded language

 A DIKW pyramid consists of 4 layers for describing multiple abstraction level for a game state. In the context of a warehouse robot the following dataset is available.  The task for the neural network is to translate between the layers, this allows a human to machine communication. Human are expressing in full english sentences, while machines are measuring the environment in numerical sensor values.

[
  {
    "id": 1,
    "data": {"pos": [40, 10], "rgb_color": [255, 0, 0], "dist": 2.0, "trajectory": "traj3", "battery": 0.7},
    "information": ["box", "red", "kitchen", "entrance"],
    "knowledge": "Pick up the red box in kitchen room"
  },
  {
    "id": 2,
    "data": {"pos": [15, 5], "rgb_color": [0, 0, 255], "dist": 1.5, "trajectory": "traj1", "battery": 0.65},
    "information": ["box", "blue", "corridor", "obstacle"],
    "knowledge": "Move the blue box out of the corridor to clear the obstacle"
  },
  {
    "id": 3,
    "data": {"pos": [60, 30], "rgb_color": [255, 255, 0], "dist": 5.0, "trajectory": "traj_return", "battery": 0.15},
    "information": ["charging_station", "yellow", "dining_room", "low_battery"],
    "knowledge": "Aborting task: Return to dining room for immediate charging"
  },
  {
    "id": 4,
    "data": {"pos": [45, 12], "rgb_color": [100, 70, 20], "dist": 0.5, "trajectory": "none", "battery": 0.58},
    "information": ["obstacle", "brown", "kitchen", "entrance", "blocked"],
    "knowledge": "Wait for 10 seconds: Entrance is blocked by a moving obstacle"
  },
  {
    "id": 5,
    "data": {"pos": [10, 80], "rgb_color": [200, 200, 200], "dist": 10.0, "trajectory": "traj_search", "battery": 0.9},
    "information": ["room", "corridor", "empty", "pickup_zone"],
    "knowledge": "Scanning corridor: No items found in designated pickup zone"
  },
  {
    "id": 6,
    "data": {"pos": [33, 44], "rgb_color": [0, 255, 0], "dist": 0.1, "trajectory": "traj_dock", "battery": 0.5},
    "information": ["box", "green", "dining_room", "drop"],
    "knowledge": "Drop the green box at the delivery point in the dining room"
  },
  {
    "id": 7,
    "data": {"pos": [5, 5], "rgb_color": [255, 0, 0], "dist": 2.2, "trajectory": "traj_safety", "battery": 0.45},
    "information": ["hazard", "red", "corridor", "liquid_spill"],
    "knowledge": "External command: Avoid red marked area due to a spill in the corridor"
  },
  {
    "id": 8,
    "data": {"pos": [50, 50], "rgb_color": [255, 255, 255], "dist": 0.0, "trajectory": "none", "battery": 0.4},
    "information": ["inventory_list", "mismatch", "kitchen", "room"],
    "knowledge": "Import external data: Re-scan kitchen room to update missing inventory"
  }
]

Grounded language in robotics

The symbol grounding problem and especially the detail of grounded language is a very new subject in computer science. It needs to be explained because its the key element of artificial intelligence. As an introductory example a warehouse robot has stored a json file:

{
  "knowledge": "pick up the red box in kitchen room",
  "information": [box, obstacle, entrance, room, pickup, drop, red, blue, yellow, kitchen, corridor, dining room],
  "data": [pos=(40,10), rgb_color=(100,70,20), dist=20, trajectory=traj3, direction=(40,10), battery=0.7],
}

This json file shows 3 of 4 layers from a DIKW pyramid. It is the current situation of the robot also known as the game state. According to the DIKW pyramid, this current situation is stored in different layers which have a different abstraction. The lowest data layer stores numerical information gathered from hardware sensors. While the information layer stores the vocabulary and the knowledge layer stores a concrete instruction.

The main task of the robots artificial intelligence is to translate between these layers. The human enters a command and the robot understands the command because its translated into the low level data layer. This translation process is called grounded language.

In contrast to former natural language processing (NLP) the goal is not to check the grammar of the input instruction e.g. to verify that the word "room" is a noun or that "red" is an adjective. So the question is not what language is by itself, but the problem has to do with converting from high level abstraction towards low level abstraction in the DIKW layers.

Annotating a warehouse robot

The table shows a simple warehouse game played in a 1d corridor. The robot R has to reach the target T and charge its battery at the Start S. Implementing such a mini game is usually realized with an array for storing the position of the objects.

What makes the simulation more demanding is the introduction of grounded language in the form of [tags]. These tags are used to describe the situation on a semantic level. In a DIKW pyramid, the 1d ascii corridor might be the data level, while the tags are the information level. 

1D ASCII Corridor	Annotation with [Tags]
[S R . . . . . T]	[at_start] [near_station] [status_idle] [path_clear]
[. S . R . . . T]	[moving_east] [leaving_station] [battery_optimal]
[. S . . R . . T]	[moving_east] [mid_corridor] [calculating_distance]
[. S . . . R . T]	[near_target] [decelerating] [scanning_area]
[. S . . . . R T]	[at_target] [loading_process] [task_active]
[. S . . . . T R]	[target_passed] [reversing] [adjusting_position]
[. S . . . R . T]	[moving_west] [returning_to_base] [low_battery_warning]
[R S . . . . . T]	[docking] [at_station] [recharging] [task_complete]

Human to robot interaction with a dikw pyramid

Maniac Mansion is a well known point&click adventure. With the help of a walk through tutorial its possible to win the game. The standard tutorial consists of keypoints and full sentences written in English which can be read by humans but can't be executed by a computer. With a converter from high level to a low level layer its possible to transform the walk through tutorial into machine readable commands. The process is demonstrated with the following json code adressing the kitchen scene:

{
  "card_id": "MM_KITCHEN_01",
  "scene_title": "The Mansion Kitchen - ScummVM Navigation",
  "content": {
    "textual_description": {
      "objective": "Enter the kitchen to retrieve the Small Key from the counter while staying alert for Nurse Edna.",
      "key_points": [
        "The kitchen is located through the first door on the right in the main hallway.",
        "Crucial Item: The Small Key is sitting on the counter near the sink.",
        "Hazard: Opening the refrigerator triggers a cutscene/event that can lead to capture.",
        "Exit Strategy: Use the door to the far right to enter the Dining Room if the hallway is blocked."
      ]
    },
    "low_level_representation": {
      "engine_context": "ScummVM - 320x200 Resolution (Original Scale)",
      "mouse_interactions": [
        {
          "step": 1,
          "verb_action": "PICK UP",
          "verb_coordinates": { "x": 40, "y": 175 },
          "target_object": "Small Key",
          "target_coordinates": { "x": 165, "y": 115 },
          "result": "Key added to character inventory."
        },
        {
          "step": 2,
          "verb_action": "WALK TO",
          "verb_coordinates": { "x": 10, "y": 165 },
          "target_location": "Dining Room Door",
          "target_coordinates": { "x": 305, "y": 110 },
          "result": "Character transitions to the next room."
        }
      ],
      "safety_note": "Avoid clicking 'OPEN' (x: 10, y: 175) on the Refrigerator (x: 240, y: 90) unless you have a specific distraction planned."
    }
  }
}

Both layers (low level and high level) are describing the same scene which is to enter the kitchen and fetch the key. The difference is, that that the layers have a different abstraction level. The high level layer is prefered by humans and mirrors how humans are thinking and how they are using language. In contrast, the low level layer is prefered by machines who are programmed with a logic oriented mathematical notation.

The converter has the task to translate between these layer which is known as the symbol grounding problem. Solving the grounding problem means to improve human to machine interaction.

Abstieg in der DIKW Pyramide am Beispiel Zak mckracken

 Damit ein Large language model ein Videospiel automatisiert durchspielt braucht es mehrere Ebenen aus der DIKW Pyramide. Auf layer 3 (knowledge) wird eine Spielszene in Stichpunkten beschrieben auf einer sehr hohen Abstraktionsschicht. Dies wird dann in den layer2 übersetzt, der viel präziser ist aber weniger leicht zu lesen für einen Menschen und schlußendlich auf den Layer1 transformiert der die low level Daten Ebene darstellt. Der Layer1 kann dann an die Game engine gesendet werden, also an die ScummVM welche das point&click adventure ausführt.

Hier alle 3 layer der DIKW pyramide in einer übersichtlichen json notation.

{
  "game": "Zak McKracken and the Alien Mindbenders",
  "card_id": 1,
  "title": "Morgenroutine in San Francisco",

  "representation_1_natural_language": {
    "format": "Karteikarte (Menschlich)",
    "content": [
      "Wache in Zaks Schlafzimmer auf.",
      "Nimm das Aquarium-Netz unter dem Bett.",
      "Gehe ins Wohnzimmer und nimm die Fernbedienung vom Fernseher.",
      "Gehe in die Küche.",
      "Nimm das stumpfe Brotmesser aus der Spüle.",
      "Öffne den Kühlschrank und nimm das Ei."
    ]
  },

  "representation_2_intermediate_logic": {
    "format": "Text-to-Action Reasoning (Zwischenschritt)",
    "note": "Hier werden implizite Aktionen und Raumwechsel für die KI logisch explizit gemacht.",
    "logic_chain": [
      {"state": "Room: Bedroom", "goal": "Inventory: Fishnet", "sub_action": "PickUp(Fishnet, under_bed)"},
      {"state": "Room: Bedroom", "goal": "Change Room", "sub_action": "WalkTo(Door_West)"},
      {"state": "Room: Living Room", "goal": "Inventory: Remote", "sub_action": "PickUp(Remote_Control, on_TV)"},
      {"state": "Room: Living Room", "goal": "Change Room", "sub_action": "WalkTo(Door_North)"},
      {"state": "Room: Kitchen", "goal": "Inventory: Knife", "sub_action": "PickUp(Bread_Knife, in_Sink)"},
      {"state": "Room: Kitchen", "goal": "Access Fridge", "sub_action": "Open(Refrigerator)"},
      {"state": "Room: Kitchen", "goal": "Inventory: Egg", "sub_action": "PickUp(Egg, inside_Fridge)"}
    ]
  },

  "representation_3_low_level_scumm": {
    "format": "SCUMM Engine Executable (Low Level)",
    "note": "Direkte Opcode-artige Anweisungen, die Objekten IDs und Verben zuordnen (fiktive IDs).",
    "commands": [
      {"op": "CUTSCENE_START"},
      {"op": "PICK_UP", "obj_id": 142, "comment": "Fishnet"},
      {"op": "WALK_TO_OBJECT", "obj_id": 201, "comment": "Door to Living Room"},
      {"op": "PICK_UP", "obj_id": 155, "comment": "Remote Control"},
      {"op": "WALK_TO_OBJECT", "obj_id": 202, "comment": "Door to Kitchen"},
      {"op": "PICK_UP", "obj_id": 160, "comment": "Bread Knife"},
      {"op": "OPEN", "obj_id": 175, "comment": "Refrigerator"},
      {"op": "PICK_UP", "obj_id": 176, "comment": "Egg"},
      {"op": "CUTSCENE_END"}
    ]
  }
}

 

Das interessante an dem Ansatz ist die Abwesenheit einer künstlichen Intelligenz im klassischen Sinne. Es gibt also kein neuronales Netz oder einen Reinforcement Learning algorithmus welches das Spiel durchspielt sondern die KI wurde so implementiert, dass sie zwischen den layern der DIWK pyramide eine Übersetzung ausführt. Wenn man möchte dass im Videospiel eine andere Aktion ausgeführt wird, schreibt man in den obersten Layer andere Stichworte hinein, die werden dann in echtzeit in die unteren Layer transformiert und ausgeführt. Das prinzip ist vergleichbar mit Unix pipes, also einer Filterkaskade die input in output übersetzt. 

LLMs als ingame AI

Large language modelle genießen eine große Popularität doch bisher wird dessen Potential nur teilweise ausgeschöpft. So finden LLM ihren Einsatz als Suchmaschine, zum Programmieren oder um Fragen zu beantworten. Hingegen werden sie kaum bis gar nicht eingesetzt um Computerspiele automatisiert durchzuspielen. Zwar gibt es neuere Entwicklungen wie Deepmind Sima 2, was durchaus in der Lage ist innerhalb von virtuellen Welten zu agieren, doch ist der Tokenverbrauch hoch und es gibt nur wenige Dokumentationen dazu.

Heutige LLM sind durchaus imstande in virtuellen Welten zu agieren. Als Beispiel sei hier eine stichpunktartige Komplettlösung für das Maniac Mansion Point&click adventure gegeben welche durch ein LLM from scratch erzeugt wurde:

Karte 1: Start
    Team-Wahl: Empfohlen: Syd oder Razor (Musik-Talent) + Bernard (Technik).
    Eingang: Gehe zum Haus. Unter der Fußmatte liegt der Türschlüssel.
    Eingangshalle: Benutze Schlüssel mit Haustür. Drinnen: Vorsicht vor Edna oder Weird Ed! Wenn sie kommen, schnell in einen Nebenraum flüchten.
    Küche: Gehe nach rechts durch die Tür. Nimm das Fleisch aus dem Kühlschrank und die Getränkedose (für später).

Karte 2: Das Gefängnis & Der Fluchtplan
    Trigger: Wenn ein Charakter geschnappt wird, landet er im Kerker.
    Ausbruch: Drücke den losen Stein an der Wand (links neben der Tür), um die Tür kurz zu öffnen.
    Taktik: Nutze einen Charakter als „Köder“, um die Edisons abzulenken, während die anderen zwei das Haus erkunden.
    Wichtig: Speichere oft! Ein falscher Schritt führt zum Game Over.

Karte 3: Die Vorräte im Erdgeschoss
    Esszimmer: Nimm die Früchte von der Schüssel.
    Speisekammer: Nimm den Glasschneider (hinter der Glasvitrine) und den Saft.
    Wohnzimmer: Benutze die Kassette mit dem Kassettenrekorder (wichtig für später, um das Glas zu zerschmettern).
    Bibliothek: Öffne die Lampe, um das Zimmer zu erhellen. Nimm den Loseblatt-Katalog.

Karte 4: Weird Eds Zimmer (1. Stock)
    Vorsicht: Wenn Ed dich sieht, fliegst du raus.
    Ablenkung: Warte, bis Ed sein Zimmer verlässt (um das Paket zu holen) oder nutze die Türklingel an der Haustür, um ihn runterzulocken.
    Gegenstand: Nimm den Hamster (nur als Razor/Syd relevant für böse Enden) und das Sparschwein. Brich das Schwein auf, um Geld zu erhalten.
    Schlüssel: Nimm den Schlüssel vom Nachttisch.

Karte 5: Das Musikzimmer & Die Glasplatte
    Vorbereitung: Geh ins Musikzimmer (1. Stock).
    Aktion: Benutze den Glasschneider mit der Vitrine, um die Kassette zu stehlen.
    Klavier: Wenn du Razor oder Syd bist, kannst du hier spielen, aber das Ziel ist die Schallplatte im Zimmer daneben.
    Tipp: Du musst die Schallplatte auf den Rekorder im Wohnzimmer legen und aufnehmen, um später das Fenster im Labor zu sprengen.

Karte 6: Das Schwimmbad (Außenbereich)
    Gefahr: Das Wasser ist radioaktiv! Nicht hineingehen.
    Aktion: Leere das Becken, indem du das Ventil im Keller (unter der Küche) benutzt.
    Fundstück: Am Boden des leeren Beckens liegt der leuchtende Schlüssel.
    Wichtig: Fülle das Becken sofort wieder auf, da sonst der Reaktor überhitzt (Game Over Timer startet!).

Karte 7: Der Grüne Tentakel
    Ort: 2. Stock, Weg zum Dachboden.
    Problem: Der Grüne Tentakel hat Hunger und lässt dich nicht vorbei.
    Lösung: Gib ihm den Obstteller aus dem Esszimmer und den Saft (oder die Cola).
    Ergebnis: Er wird dein Freund und lässt dich passieren. Du hast nun Zugang zu den oberen Räumen und dem Funkgerät.

Karte 8: Das Paket & Das Telefon
    Paket: Wenn die Türklingel läutet, renne mit einem Charakter zur Haustür und schnapp dir das Paket, bevor Ed es bekommt.
    Inhalt: Briefmarken.
    Telefon: Benutze das Telefon im Arbeitszimmer. Wähle die Nummer vom „Metzger“ (findest du im Loseblatt-Katalog), um Edna abzulenken.
    Nächster Schritt: Während Edna telefoniert, schleiche in ihr Zimmer, um den Schlüssel zum Labor zu finden.
    
Diese Anleitung gibt in natürlicher Sprache einen Ablauf vor um das Spiel erfolgreich zu spielen. Einziges Problem bei dieser Anleitung ist, dass es kein ausführbarer Computer code ist sondern an menschliche Leser adressiert wurde. In der DIKW pyramide ist die Komplettlösung also auf dem Layer 3 (knowledge) angesiedelt. Damit eine KI Maniac Mansion automatisiert durchspöielen kann, muss man die Anleitung auf eine niedrige DIKW Stufe übersetzen also auf Stufe 2 und Stufe 1 (Daten).

Sowas wird über ein Text to action model realisiert. DAs erhält eine Karteikarte als Input und erzeugt dafür die Mausbewegung als Ausgabe.

Hier die simulierten Mausbewegungen für Karteikarte #1 innerhalb der SCUMM-Engine bei einer Auflösung von 320x200 Pixeln. Das json file enthält dieselben Anweisungen wie die textuelle Komplettlösung auch nur mit dem Unterschied dass es nicht auf dem DIKW layer 3 sondern auf dem untersten Layer 1 angesiedelt ist. Als Folge gibt es numerische Koordinaten die definieren wo genau der Mauscursor hinbewegt wird.

{
  "card_id": 1,
  "title": "Start",
  "steps": [
    {
      "action_order": 1,
      "description": "Walk to the front door area",
      "command": "WALK_TO",
      "target_coords": {"x": 160, "y": 140},
      "wait_ms": 2000
    },
    {
      "action_order": 2,
      "description": "Pick up the door mat",
      "verb_click": {"x": 40, "y": 170, "label": "PICK_UP"},
      "object_click": {"x": 155, "y": 155, "label": "DOOR_MAT"},
      "wait_ms": 1500
    },
    {
      "action_order": 3,
      "description": "Pick up the key under the mat",
      "verb_click": {"x": 40, "y": 170, "label": "PICK_UP"},
      "object_click": {"x": 155, "y": 155, "label": "KEY"},
      "wait_ms": 1000
    },
    {
      "action_order": 4,
      "description": "Use key with front door",
      "verb_click": {"x": 80, "y": 180, "label": "USE"},
      "inventory_click": {"x": 300, "y": 170, "label": "KEY"},
      "object_click": {"x": 160, "y": 100, "label": "FRONT_DOOR"},
      "wait_ms": 3000
    },
    {
      "action_order": 5,
      "description": "Enter the house",
      "command": "WALK_TO",
      "target_coords": {"x": 160, "y": 90},
      "wait_ms": 2000
    },
    {
      "action_order": 6,
      "description": "Go to the kitchen (right door)",
      "command": "WALK_TO",
      "target_coords": {"x": 280, "y": 120},
      "wait_ms": 2500
    },
    {
      "action_order": 7,
      "description": "Open refrigerator",
      "verb_click": {"x": 40, "y": 180, "label": "OPEN"},
      "object_click": {"x": 100, "y": 100, "label": "REFRIGERATOR"},
      "wait_ms": 1000
    },
    {
      "action_order": 8,
      "description": "Pick up the meat",
      "verb_click": {"x": 40, "y": 170, "label": "PICK_UP"},
      "object_click": {"x": 105, "y": 110, "label": "MEAT"},
      "wait_ms": 1000
    }
  ]
}

DIKW database for a warehouse robot

 The following DIKW pyramid was simplified to only 2 bottom layers. Its stored in a json database with 2 different tables. The data layer stores the numerical sensor data like lidar_distance and battery voltage of the robot, while the information layer stored semantic tags. The task for the robot is to translate between both layers back and forth which is called symbol grounding. 

{
  "dikw_model": {
    "data_layer": {
      "lidar_distance_cm": 12.5,
      "ultrasonic_proximity": 0.15,
      "camera_rgb_average": [120, 120, 120],
      "encoder_ticks": 4502,
      "battery_voltage": 11.2
    },
    "information_layer": {
      "spatial_context": ["obstacle", "near_field"],
      "navigation_tag": "left_quadrant_blocked",
      "surface_type": "concrete",
      "status": "low_battery_warning",
      "motion_state": "decelerating"
    }
  }
}

Language parsing with a DIKW pyramid

In a role playing game there is an npc quest available which asks the human player to collect an item in the wood. To verify if the human player has fulfilled the quest, the game engine needs to understand the words which is equal to downwards in the DIKW pyramid. A sentence consists of single words, these words are associated with sprites in the game engine and also with location in the map. The association between an abstract word and the information in the game engine is stored in a DIKW pyramid which is a database.

A single sentence can be submitted to the dikw database and the database resolves the request so that it will become machine readable. Going upwards and downwards in the DIKW pyramid is equal to symbol grounding.

A DIKW pyramid consists of layers which are storing different sort of information. The lowest layer is accessible for a computer program and consists of location in a map, trajectories, sprites, tile maps and numerical color information. A possible entry might be [100,30] for a position in a map or (100,120,90) for a RGB color information.

On the next layer "information" a different sort of information are stored which are words. A word is a string which can be understand by a human but doesn't provide sense for a computer. For a human the word "wood" makes sense, but for a computer the same string is only an array of characters without any meaning. Its the task of the DIKW pyramid to link the word "wood" with a location in the map. The link allows the computer to resolve the meaning.

DIKW pyramid for trash sorting robot arm

The knowledge base is formatted as a TOML config file and contains all the layers from the DIKW pyramid. What matters is the translation from one layer to another layer. On the lowest level, the data section there are only numerical sensor values available from the camera and from the weight sensor. Its important that multiple sensors with high accuracy are available to determine the situation on the trash conveyor.

The next layer (information) describes the same reality but with a different syntax. There are no numerical sensor data available but the reality is presented with semantic tags. The name of the object is recognized also the status of the gripper. On the next layer these information are used to determine what to do with the object. The bottle is thrown into bin #03 and knowledge about the behavior of the object is shown (item_integrity = "CRUSHABLE")

The task for the AI software is to update the information in the TOML file in the game loop. This makes it easier to control the robot arm itself.


# Trash Sorting Robot Arm - DIKW Frame Mapping
# Unit: SortBot-9000 (Delta Arm Config)

[data]
# Raw hardware feedback and vision tensors (Numerical)
pixel_centroid_x = 412.0
pixel_centroid_y = 890.0
rgb_mean_r = 0.82
spectro_reflectance = 0.14    # Near-Infrared sensor value
gripper_pressure_kpa = 12.5   # Feedback from tactile sensors
item_weight_grams = 45.0
belt_speed_mps = 0.5

[info]
# Object classification and sensory context (Semantic Tags)
visual_class = "PLASTIC_BOTTLE"
material_guess = "PET"
contamination_level = "LOW"
object_orientation = "TRANSVERSE"
grip_status = "SECURE"
surface_texture = "SMOOTH"

[knowledge]
# Relational logic and sorting rules (Situational Logic)
sort_destination = "BIN_03_PLASTICS"
grasp_feasibility = "HIGH_CONFIDENCE"
item_integrity = "CRUSHABLE"
market_value_index = "RECYCLABLE_GRADE_A"
collision_risk = "CLEAR_PATH"

[wisdom]
# Strategic throughput and error handling (Executive Decision)
primary_directive = "SORT_TO_PRIMARY_BIN"
throughput_strategy = "MAXIMIZE_PURITY"
anomaly_protocol = "NONE"
energy_mode = "HIGH_PERFORMANCE"
failure_contingency = "RETRY_ON_SLIP"

 

Storing a DIKW pyramid in a TOML file

; Warehouse Robot Simulator - DIKW Symbolic Frame Mapping
; Model: Autonomous Mobile Robot (AMR) - Logistics Unit 04

[data]
; Raw sensor streams and physics engine outputs (Numerical/Float)
pos_x = 142.55
pos_y = 12.80
battery_level = 0.42
lidar_range_front = 0.85
motor_torque_nm = 4.2
payload_weight_kg = 25.0
shelf_id_detected = 1024.0
wheel_slip_ratio = 0.02

[info]
; Contextualized data and threshold-based states (Semantic Tags)
movement_state = "TRANSLATING"
battery_status = "WARNING_LOW"
path_clearance = "OBSTRUCTED"
load_status = "HEAVY_LOAD"
location_zone = "PICKING_AISLE_B"
traction_quality = "STABLE"
nearest_object = "HUMAN_OPERATOR"

[knowledge]
; Relational patterns and rule-based assessments (Situational Logic)
operational_constraint = "REDUCED_SPEED_REQUIRED"
efficiency_rating = "SUBOPTIMAL_PATHING"
safety_risk_level = "MODERATE_COLLISION_PROXIMITY"
energy_prognosis = "RETURN_TO_BASE_IN_120_SECONDS"
task_feasibility = "PICKUP_POSSIBLE_BUT_RISKY"
spatial_relation = "BLOCKED_BY_PEDESTRIAN"

[wisdom]
; High-level strategic intent and optimization (Executive Decision)
primary_directive = "ABORT_CURRENT_PICK_AND_RECHARGE"
safety_protocol = "ACTIVE_EMERGENCY_BRAKING"
resource_allocation = "HANDOVER_TASK_TO_AMR_05"
long_term_strategy = "PREVENTIVE_MAINTENANCE_SCHEDULED"
optimization_goal = "MINIMIZE_DOWNTIME_OVER_THROUGHPUT"

Teleoperation with natural language

 A good starting points for programming a robot is a teleoperated simulation. A possible implementation would be a python video game in which a human controls a robot gripper with the mouse. Such a system simulates a real world sceneario, in which the human also has control over a robot arm and grasps objects with a joystick.

The main disadvantage of teleoperation in the reality and in a simulation is, that the human operator is needed all the time. Even if its technically easy to implement, the missing ability to run the system autonomously are a great problem. So the question is how to increase the autonomy of the robot slightly without using very advanced AI techniques like vision language action (VLA) models.

The idea is to introduce two constraints, first the communication from the robot to the human is improved only but not the other way around and secondly the robot doesn't need to verbalize the scene in an elaborated style but its enough if the robot only annotates the scene with [tags] like [gripper_open], [collision_gripper_box] and [box_isfalling]. Each tag is a boolean value and the entire tag space is stored in a binary feature vector.

The task for the programmer is to convert the existing numerical information from the physics engine like the position and the rotation of the Box2d objects into the semantic tag space which consists of 3 or more different tags. In other words, the translation process is equal to climbing upwards in the DIKW pyramid.

The resulting system remains a teleoperated robot, but the improved software gives textual feedback to the human operator. The human operator is doing a task, e.g. stacking two boxes on top  and the robot annotates the activities with a tagging mechanism.

Symbol grounding with a DIKW pyramid

 A possible model to explain the symbol grounding problem is the DIKW pyramid. Grounding means to translate a higher layer in the pyramid into a lower layer. The layers are representating the same reality in different formats. The perhaps most important transition is from the numerical data layer into the labeled data. For a warehouse robot a GPS sensor reading like (40,10) gets translated into [roomB]. So the low level sensor data gets annotated with tag.

The next layer is the knowledge graph which encodes the tagging information into a semantic network. The realations between the tags are explained, synonyms are introduced and the information are stored in a json file. If all the layers in the DIKW pyramid are established and if an automatic parser can translate upward and downward in the pyramid, its possible to communicate with a robot in natural language. A voice command like "go to roomB and bring me the yellow box" is understood by the robot and executed in the reality.

Minsky frames as communiation tool

 

A minsky frame is a list of key/value pairs as text overlay in a GUI window. Its not intended as an internal data structure within a robot but its GUI gadget which displays information about the game on the screen.

For the example of an intersection simulator the minsky frame was realized with the pygame command:

screen.blit(txt, (35, y))

Which draws a text string to the screen, for example the information "exit_target: WEST". A minsky frame is some sort of form which determines which aspects of the reality are important. The computer determines the value for each item and shows the result on the screen. This allows to solve the symbol grounding problem because the shown text overlay translates the data layer of the DIKW pyramid into the information of the DIKW pyramid.

The information layer in the DIKW pyramid

The lowest layer in the DIKW pyramid is the data layer which can be desribed easily. There are raw sensor data like distance, temperature, gps coordinates which are stored in a numerical format. The next layer in the pyramid, the information layer, is harder to describe. A working thesis is, that the information layer consists of [tags].

For the example of a warehouse robot, the tag cloud would be: [roomA, roomB, roomC, shelfNorth, shelfsouth, shelf1, shelf2, obstacle, battery, chargingstation, barcode, path, left, right, speed, direction, batteryempty, order]

Of course the tag list is not complete, there are additional tags available but for reason of simplication this might be a starting point. These tags are providing context because after selecting one tag, possible alternative tags are not activated. For example, the goal for the robot might be [roomB] but not [roomA, roomC]. The robot might rotate to [left] but not to [right]. So the context of a tag are always the tag which might be possible but are not activated at the moment.

All the tags are creating a semantic network. In contrast to a full blown ontology or AI frames, a tag based information is more minimalist. Every tag can be activated or not similiar to the tags in a blogging post for annotating a document.

The interesting situation is, that there is an intersection available between low level sensor data and mid level tagging cloud. For example:

- gps sensor -> [roomA]
- gps sensor -> [direction]
- distance sensor -> [obstacle]

For desribing the robot's behavior both layers (data and information) are important. The robot needs to log the numerical raw sensor data and also the robot needs to annotate the current sensory perception with semantic information.

What we can say for sure is, that tagging information doesn't belong to the lowest data layer. A sensor like a gps sensor has no builtin tagging mechanism. The sensor doesn't know the position of a certain shelf, or doesn't know if the robot is in roomA or in roomB. What the gps sensor knows instead are precise x/y coordinates. The reason is, that the sensor hardware is able to generate such data. Its up to a higher instance in the DIKW pyramid to process these data.