October 02, 2026

Creating chatty robots

 

The Micromouse challenge is a well known robot competition which is mostly a hardware building plus programming challenge. The rules of the challenge can be modified so that the ability of a robot is determined to generate grounded language. In the screenshot, the robot has a text widget at the bottom for showing the text.

The human user controls the robot and at the same time the textual output of the robot gets updated. This textual output allows a rule based AI to control the robot automatically which wasn't implemented yet. The only difference to the normal micromouse challenge is, that in the example the mentioned text widget is visible.

The text gets produced with a dictionary of words. Possible words like [move, goal, blocked] are describing objects and events of the game. The program detects situations and uses the words to generate the output. Because there is a mapping between the game state and the textual output its called grounded language.

import math, sys, pygame

# 1. SETUP & CONFIGURATION
WIN_W, WIN_H, MAZE_H = 800, 700, 580
WHITE, BLACK, GREEN, BLUE, GRAY = (255, 255, 255), (0, 0, 0), (40, 180, 40), (40, 100, 220), (200, 200, 200)

# Grounded language vocabulary for rule-based AI parsing
DICT = {
    "verbs": ["detected", "reached", "turn", "move"],
    "nouns": ["wall", "path", "goal", "junction", "distance"],
    "adj": ["ahead", "left", "right", "clear", "blocked", "near"]
}

# Solvable Maze Walls [x, y, w, h] & Goal
WALLS = [
    pygame.Rect(0, 0, 800, 10), pygame.Rect(0, 0, 10, 580),
    pygame.Rect(790, 0, 10, 580), pygame.Rect(0, 570, 800, 10),
    pygame.Rect(150, 0, 10, 420), pygame.Rect(300, 160, 10, 420),
    pygame.Rect(450, 0, 10, 420), pygame.Rect(600, 160, 10, 420),
    pygame.Rect(150, 250, 80, 10), pygame.Rect(450, 350, 80, 10)
]
GOAL = pygame.Rect(680, 480, 80, 80)

# 2. ROBOT CLASS
class Micromouse:
    def __init__(self, x, y):
        self.x, self.y, self.angle, self.radius, self.sensor_len = x, y, 0, 14, 55

    def update(self, keys):
        speed = (2.5 if keys[pygame.K_UP] else 0) - (1.5 if keys[pygame.K_DOWN] else 0)
        self.angle = (self.angle + (3.5 if keys[pygame.K_RIGHT] else 0) - (3.5 if keys[pygame.K_LEFT] else 0)) % 360
        rad = math.radians(self.angle)
        nx, ny = self.x + math.cos(rad) * speed, self.y + math.sin(rad) * speed
        
        # Collision detection with walls
        nrect = pygame.Rect(nx - self.radius, ny - self.radius, self.radius * 2, self.radius * 2)
        collided = any(nrect.colliderect(w) for w in WALLS)
        if not collided:
            self.x, self.y = nx, ny
        return collided

    def sense(self):
        """Scans left (-45 deg), ahead (0 deg), right (+45 deg) for obstacles."""
        dirs, res = {"left": -45, "ahead": 0, "right": 45}, {}
        for d, off in dirs.items():
            rad = math.radians(self.angle + off)
            ex, ey = self.x + math.cos(rad) * self.sensor_len, self.y + math.sin(rad) * self.sensor_len
            res[d] = any(w.clipline((self.x, self.y), (ex, ey)) for w in WALLS)
        return res

    def draw(self, surface):
        pygame.draw.circle(surface, BLUE, (int(self.x), int(self.y)), self.radius)
        rad = math.radians(self.angle)
        pygame.draw.line(surface, WHITE, (self.x, self.y), (self.x + math.cos(rad)*self.radius, self.y + math.sin(rad)*self.radius), 3)

# 3. HELPER FOR WORD WRAPPING TEXT
def render_wrapped_text(surface, text, font, rect, color=BLACK):
    words = text.split(" ")
    lines, current_line = [], ""
    for word in words:
        test_line = f"{current_line} {word}".strip()
        if font.size(test_line)[0] <= rect.width:
            current_line = test_line
        else:
            lines.append(current_line)
            current_line = word
    lines.append(current_line)
    
    y = rect.y
    for line in lines:
        if y + font.get_height() <= rect.bottom:
            surface.blit(font.render(line, True, color), (rect.x, y))
            y += font.get_height() + 2

# 4. MAIN LOOP
def main():
    pygame.init()
    screen = pygame.display.set_mode((WIN_W, WIN_H))
    pygame.display.set_caption("Grounded Language Micromouse")
    clock, font = pygame.time.Clock(), pygame.font.SysFont("Arial", 30, bold=False)
    mouse = Micromouse(50, 50)

    while True:
        for event in pygame.event.get():
            if event.type == pygame.QUIT:
                pygame.quit(); sys.exit()

        collided = mouse.update(pygame.key.get_pressed())
        sensors = mouse.sense()
        dist = int(math.hypot(mouse.x - GOAL.centerx, mouse.y - GOAL.centery))

        # Build rule-oriented grounded language output
        tokens = []
        if GOAL.collidepoint(mouse.x, mouse.y):
            tokens.append(f"{DICT['nouns'][2]} {DICT['verbs'][1]}")  # "goal reached"
        else:
            tokens.append(f"{DICT['nouns'][4]} to {DICT['nouns'][2]}: {dist}px")  # "distance to goal: Xpx"

        if collided:
            tokens.append(f"{DICT['nouns'][0]} collision {DICT['adj'][4]}")  # "wall collision blocked"
        
        # Tactical language for rule-based navigation AI
        blocked_dirs = [d for d, is_blocked in sensors.items() if is_blocked]
        if not blocked_dirs:
            tokens.append(f"{DICT['nouns'][1]} {DICT['adj'][3]}: {DICT['verbs'][3]} {DICT['adj'][0]}") # "path clear: move ahead"
        else:
            tokens.append(f"{DICT['nouns'][0]} {DICT['verbs'][0]} on " + " ".join(blocked_dirs))
            if sensors["ahead"]:
                suggested_turn = "right" if not sensors["right"] else ("left" if not sensors["left"] else "back")
                tokens.append(f"recommendation: {DICT['verbs'][2]} {suggested_turn}")

        # Render Scene
        screen.fill(WHITE)
        pygame.draw.rect(screen, GREEN, GOAL)
        screen.blit(font.render("GOAL", True, WHITE), (GOAL.x + 18, GOAL.y + 30))
        for w in WALLS: pygame.draw.rect(screen, BLACK, w)
        mouse.draw(screen)

        # Bottom Text Panel (White Background, Black Text, Word Wrapped)
        panel = pygame.Rect(0, MAZE_H, WIN_W, WIN_H - MAZE_H)
        pygame.draw.rect(screen, WHITE, panel)
        pygame.draw.line(screen, BLACK, (0, MAZE_H), (WIN_W, MAZE_H), 2)

        output_str = f"STATUS: [ {' | '.join(tokens)} ] | CONTROLS: Arrow Keys"
        render_wrapped_text(screen, output_str, font, pygame.Rect(10, MAZE_H + 8, WIN_W - 20, WIN_H - MAZE_H - 12))

        pygame.display.flip()
        clock.tick(60)

if __name__ == "__main__":
    main()

October 01, 2026

Understanding robotics in the past

Until around the year 2010, robotics projects were started with a certain bias which wasn't discussed but seen as mandatory. The philosophy was to see a robot as a closed system similar to a meccano windmill or a steam engine. All these systems are described by its internal working. In case of a windmill there is a mechanical mechanism and in case of a robot there is a computer program available. The assumption was that the power of a robot is located inside the machine encoded in an AI algorithm.

The only debate available was about the details of a closed system, for example which programming language is useful and which algorithm should be preferred. The AI engineers were interested in improving the robot itself because this principle was successful for mechanical machines and its also relevant for classic computer software. A certain software e.g. a graphics routine is optimized by improving the code. The code can become faster in terms of RAM consumption and CPU cycles. Also the lines of codes can be reduced so the machine is working more efficient.

Unfortunately, this paradigm failed for robotics applications. Its not possible to develop a robot with this bias. This is not a theoretical criticism but can be verified with a closer look into robotics software written before 2010. Many examples projects are available at github, some of them consists of 100k lines of code written in C++ with advanced algorithms, but the resulting robot can do nothing. It fails for simple tasks.

In a more harder language, robotics projects in the past were similar to non sense machines. It was cargo cult science. Even real software code was written in C/C++ and executed on a microcontroller, the robot wasn't able to do something. This problem was recognized by researchers in the past, but they didn't know how to improve the robots.

The criticism can be summarized to a single requirement: Robots in the past were not able to communicate with the environment. Even the robot was equipped with a microphone and sensors these hardware parts were not important for the software. Even more, the goal of robotics projects in the past was to avoid any communication with the environment because such a behavior has much in common with teleoperation which was seen as dead end.

AI before the year 2010 was trapped into a philosophy based on closed system plus computionalism. The thought model was a Turing machine without any external sensors. Such a closed system was recognized as best practice method for creating Artificial intelligence because it was fully understood by the software engineers.

One possible explanation for this self created closed system trap was the inability of computer science to describe the reality. Computer science is great in creating computer hardware and software but struggles in capture the environment of a robot. The reality is a highly complex, unspecified and non mathematical system which can't be compressed in algorithm or mathematical equation which creates a gap between the internal model of a robot and the external reality. This gap was first described by Rodney Brooks in 1990 but Brooks didn't mentioned how to overcome the gap.

September 30, 2026

Pointing game with heatmap

Similar to the previous example the game generates NPC Quests for the human to point at a certain location in a maze. Typical quests are "point at room C", "point at door to room A". To make the task easier, a heat map is shown, which provides a feedback at which direction the target location is. After clicking on the desired location, the user gets +10 reward and the next quest is shown.

The prototype demonstrates grounded language for a pointing game. The task for the user is to convert a textual command "point at ..." into an action with the mouse.

The source code is very short and consists of only 150 lines of code in Python with the pygame and the random library.

Robotik als geschlossenes System

 Bis ungefähr zum Jahr 2010 dominierte in der Robotik Community das Paradigma des geschlossenen Systems ohne es als solches zu benennen. Das Ziel der Programmierer war häufig einen Algorithmus oder ein Robot control Program zu erstellen was den Roboter autonom steuert. Der Fokus lag also auf der Programierung ganz so wie auch die Informatik den Schwerpunkt auf Software und Algorithmen legt.

Die Informatik stellt für diese Aufgabe zahlreiche Werkzeuge bereit, wie z.B. vorhandene Bilbiotheken mit pLanungsalgorithmen, Compiler für Hochsprachen wie Java sowie leistungsfähige Code editoren mit denen einmal erstellter Programm code getestet und verbessert werden kann. Die Annahme vor 2010 lautete dass diese Werkzeuge ausreichen um damit Roboter zu programmieren.

Im wesentlichen ging es also darum ein Computerprogram zu entwickeln was einen Roboter autonom steuern kann. Diese selbstgesetzte Zielstellung erzeugt einen besonderen Workflow. Er erzeugt eine massive Komplexität. Je anspruchsvoller der Roboter desto umfangreicher die benötigte Software.

Das Problem war den Informatikern bewusst, sie versuchten die Komplexität zu senken indem sie die Aufgabenstellung modifizierten. Anstatt die Software für ein Selbstfahrendes Auto im Straßenverkehr zu programmieren wurde versucht ein Spielzeug auto auf einem Parkurs zu steuern. Aber selbst diese reduzierte Aufgabe führte zu einer Software die 100k lines of code und mehr umfasste.

Bis 2010 war den meisten Robotik-Pionieren nicht bewusst dass sie sich in einer Sackgasse befanden weil die Roboter als geschlossene Systeme funktionierten. Damit ist gemeint dass die Roboter sowohl von der Software als auch von der Hardware extrem hochentwickelt waren, aber dabei auschließlich nach internen Mechanismen funktionierten und die Umwelt ignorierten. Rein formal waren Roboter zwar mit Sensoren ausgestattet es gab jedoch keine Theorie wie die Sensorwerte in Aktionen übersetzt werden können.

Geschlossene Systeme sind das gegenteil von einer Fernsteuerung. Bei einer Fernsteuerung sendet die Umwelt Befehle an den Roboter. Genau diese Art von Fernkontrolle gab es bei den Roboter vor 2010 nicht. Alle bekannten Robotik Wettbewerbe aus dieser Zeit funktionieren nach dem Prinzip der autonomen Steuerung. Es gab ein Program was von einer CPU ausgeführt wurde, und das Programm allein entschied was der Roboter tat. Ferngesteuerte Robotik wurde als unzulässig verworfen. Es war zwar technisch bekannt wie man das realisiert, aber das Prinzip wurde nicht ernsthaft diskutiert.

Ferngesteuerte Roboter sind offene Systeme. Auch die vielzietierte These von Rodney Brooks emboeddied AI zu realisieren ist nur eine andere Formulierung für Teleoperation. Sobald man Daten von Außen an den Roboter sendet entsteht ein offenes System. nicht der Roboter entscheidet was zu tun ist, sondern die umwelt übernimmt die Aufgabe. So kann ein abstandssensor ebenfalls als Fernsteuerung betrachtet werden. Sobald der abstandssensor ein Hinderniss erkennt stoppt der Roboter. Das heißt der Sensor sendet an den Roboter ein Kommando.

Bei offenen Systemen ist die Unterscheidung zwischen Roboter und Umwelt zentral. Als Roboter wird die Hardware und Software des Roboters bezeichnet, also der Arduino Microcontroller, das Linux Betriebssystem, das C program was auf dem Board läuft. Also jene Elemente für die sich die Informatik zuständig fühlt. Umgekehrt besteht die Umgebung eines Roboter aus der Aufgabe die es zu lösen, also ein Labyrinth, Hindernisse in diesem Labyrinth, ein Zielpunkt den der Roboter erreichen muss. Diese Umwelt wird von der Informatik vor dem Jahr 2010 ignroiert. Die Umwelt lässt sich nicht als Hardware und Software beschreiben sondern die Umwelt funktioniert nach anderen Prinzipien.

Sobald man Roboter baut die ferngesteuert werden, nimmt die Umwelt einen höheren Stellenwert wert. Der Roboter selbst wird zu einer Trivalen Maschine die lediglich Befehle über ein funksignal empfängt und einen Motor hat der sich bewegen kann. Der Roboter besitzt jedoch keine Software um Entscheidungen zu treffen sondern die Umwelt übernimmt das Timing und die Zieldefinition. Offene Systeme lassen sich über das Interface beschreiben, also jenes Bautteil oder jenes Softwaremodul was Befehle der Umwelt empfängt und was Informationen an die Umwelt sendet. Dieses Interface beinhaltet die eigentliche Künstliche Intelligenz, zumindest nach einer modernen Betrachtung ab dem Jahr 2010.

September 29, 2026

Text based pointing game for car driving

One problem with grounded language that its hard to give a sense making example which can be implemented in a short amount of code lines. A possible answer is a NPC quest generator which is generating tasks as textual output. The following python program has only 33 lines of code and generates random quests for a car driving game.

All the quests are pointing challenges, the human is asked to point at a certain object in the scene. The software can't verified if the human has pointed at the correct object, but only the quest itself is shown on the screen.

The implementation in python is as simple as possible. There is a python dict with possible target location which are selected randomly by the software. So its some sort dictionary with a random element. To solve the tasks, that human needs to know what a certain word means. For example "Focus on the pedestrian on sidewalk." is asking for a certain object at a certain position. 

screenshot:

==================================================
  3D DRIVING GAME: NPC POINTING QUEST GENERATOR
==================================================
Press [ENTER] for a new quest | Type 'q' + [ENTER] to quit

[Quest #1] Ready? 
 >> NEW QUEST: Focus on the pedestrian on sidewalk.
--------------------------------------------------
[Quest #2] Ready? 
 >> NEW QUEST: Focus on the parking spot.
--------------------------------------------------
[Quest #3] Ready? 
 >> NEW QUEST: Track the parking spot.
--------------------------------------------------
[Quest #4] Ready? 
 >> NEW QUEST: Locate the car on the left lane.
--------------------------------------------------
[Quest #5] Ready? 
 

source code:

import random

# Driving game targets organized by relative 3D perspective from behind the wheel
TARGETS = {
    "traffic_controls": ["traffic light", "speed limit sign", "stop sign", "yield sign"],
    "road_features": ["street ahead", "crosswalk", "lane line", "pothole", "guardrail"],
    "vehicles": ["car in front", "car on the left lane", "car on the oncoming side", "truck in side mirror", "motorcycle in rearview mirror"],
    "environment": ["pedestrian on sidewalk", "billboard", "parking spot", "street lamp"]
}

VERBS = ["point at", "focus on", "locate", "target", "track"]

def generate_quest():
    category = random.choice(list(TARGETS.keys()))
    obj = random.choice(TARGETS[category])
    verb = random.choice(VERBS)
    return f'{verb.capitalize()} the {obj}.'

def main():
    print("=" * 50 + "\n  3D DRIVING GAME: NPC POINTING QUEST GENERATOR\n" + "=" * 50)
    print("Press [ENTER] for a new quest | Type 'q' + [ENTER] to quit\n")
    
    count = 1
    while True:
        cmd = input(f"[Quest #{count}] Ready? ").strip().lower()
        if cmd == 'q':
            print("\nGenerator stopped. Keep your eyes on the road!")
            break
        print(f" >> NEW QUEST: {generate_quest()}\n" + "-" * 50)
        count += 1

if __name__ == "__main__":
    main()


September 28, 2026

Pointing game with npc quests

 The game engine generates a random quests like "click on top" or "click on obstacle". The human user has to follow the instruction to get a reward.

import sys, random, pygame

pygame.init()
pygame.font.init()

# Setup grid & display settings
GRID_SIZE, CELL_SIZE = 8, 60
OFF_X, OFF_Y = 160, 60
W, H = 800, 650

SCREEN = pygame.display.set_mode((W, H))
pygame.display.set_caption("Grounded Language: Grid Pointing Game")
CLOCK = pygame.time.Clock()

FONT_MAIN = pygame.font.SysFont("Arial", 20, bold=True)
FONT_UI = pygame.font.SysFont("Arial", 16)

# Colors: BG, Grid, Obstacle, Box BG, Box Border, Text, Success, Error
C_BG, C_GRID, C_OBS = (240, 243, 246), (180, 185, 190), (100, 110, 120)
C_BOX_BG, C_BOX_BDR, C_TXT = (220, 225, 230), (140, 150, 160), (30, 40, 50)
C_SUCC, C_ERR = (46, 204, 113), (231, 76, 60)

# 2x2 Obstacle cells in the middle
OBSTACLE_CELLS = {(3, 3), (3, 4), (4, 3), (4, 4)}

ACTIONS = ["point at", "click on", "select", "target"]

class PointingGame:
    def __init__(self):
        self.score = 0
        self.fb_msg, self.fb_col, self.fb_timer = "", C_TXT, 0
        self.new_quest()

    def new_quest(self):
        act = random.choice(ACTIONS)
        qtype = random.choice(["specific", "obstacle", "top", "bottom", "left", "right"])

        if qtype == "specific":
            x, y = random.randint(0, 7), random.randint(0, 7)
            self.quest = f'NPC Quest: "{act} ({x},{y})"'
            self.check = lambda cx, cy, x=x, y=y: (cx, cy) == (x, y)
        elif qtype == "obstacle":
            self.quest = f'NPC Quest: "{act} the obstacle"'
            self.check = lambda cx, cy: (cx, cy) in OBSTACLE_CELLS
        else: # Top, Bottom, Left, or Right edge (8 cells each)
            self.quest = f'NPC Quest: "{act} {qtype} edge cells"'
            edges = {
                "top": lambda cx, cy: cy == 0,
                "bottom": lambda cx, cy: cy == 7,
                "left": lambda cx, cy: cx == 0,
                "right": lambda cx, cy: cx == 7
            }
            self.check = edges[qtype]

    def handle_click(self, pos):
        mx, my = pos
        if OFF_X <= mx < OFF_X + 480 and OFF_Y <= my < OFF_Y + 480:
            cx, cy = (mx - OFF_X) // CELL_SIZE, (my - OFF_Y) // CELL_SIZE
            if self.check(cx, cy):
                self.score += 10
                self.fb_msg, self.fb_col = f"Correct! +10 pts for cell ({cx},{cy})", C_SUCC
                self.new_quest()
            else:
                self.score = max(0, self.score - 5)
                self.fb_msg, self.fb_col = f"Wrong! Cell ({cx},{cy}) is not the target. (-5)", C_ERR
            self.fb_timer = pygame.time.get_ticks() + 1500

    def draw(self):
        SCREEN.fill(C_BG)
        # Headers & Score
        SCREEN.blit(FONT_MAIN.render("Grounded Language Grid Game", True, C_TXT), (OFF_X, 15))
        SCREEN.blit(FONT_MAIN.render(f"Score: {self.score}", True, C_SUCC), (OFF_X + 320, 15))

        # Axis Labels & Grid
        mx, my = pygame.mouse.get_pos()
        for i in range(8):
            SCREEN.blit(FONT_UI.render(str(i), True, C_TXT), (OFF_X + i * 60 + 26, OFF_Y - 25))
            SCREEN.blit(FONT_UI.render(str(i), True, C_TXT), (OFF_X - 25, OFF_Y + i * 60 + 22))

        for cy in range(8):
            for cx in range(8):
                rect = pygame.Rect(OFF_X + cx * 60, OFF_Y + cy * 60, 60, 60)
                col = C_OBS if (cx, cy) in OBSTACLE_CELLS else (255, 255, 255)
                pygame.draw.rect(SCREEN, col, rect)
                pygame.draw.rect(SCREEN, C_GRID, rect, 1)

                if rect.collidepoint(mx, my):
                    s = pygame.Surface((60, 60), pygame.SRCALPHA)
                    s.fill((52, 152, 219, 100))
                    SCREEN.blit(s, rect.topleft)

        # Quest & Feedback Widget
        box = pygame.Rect(OFF_X - 40, OFF_Y + 505, 560, 85)
        pygame.draw.rect(SCREEN, C_BOX_BG, box, border_radius=8)
        pygame.draw.rect(SCREEN, C_BOX_BDR, box, width=2, border_radius=8)

        SCREEN.blit(FONT_MAIN.render(self.quest, True, C_TXT), (box.x + 20, box.y + 15))
        if pygame.time.get_ticks() < self.fb_timer:
            SCREEN.blit(FONT_UI.render(self.fb_msg, True, self.fb_col), (box.x + 20, box.y + 50))

game = PointingGame()
while True:
    for event in pygame.event.get():
        if event.type == pygame.QUIT:
            pygame.quit(); sys.exit()
        elif event.type == pygame.MOUSEBUTTONDOWN and event.button == 1:
            game.handle_click(event.pos)

    game.draw()
    pygame.display.flip()
    CLOCK.tick(60)
 

September 25, 2026

Programming grounded language games step by step

Suppose the goal is to use grounded language to control a model railroad. The first step is to invent a dictionary with useful words:

- locomotive_1: red, locomotive_2: blue
- switch_1: left_side, switch_2: right_side, track,
- slowdown, speedup, switch, follow, wait

These words are stored in a python dictionary as a list. The first iteration of the parser takes a command from the command line e.g. "switch_1" and searches in the dictionary if the found is available. Then the parser returns "ok".

In step 2 the vocabulary gets connected with the visual appearance of the game formalized in a pointing game. The user enters a command and the parser should highlight the object on the screen. For example the user enters "locomotive_2" and the parser draws a rectangle around the object.

In step 3 which is more advanced an instruction following game gets established. The parser has to execute actions. The user might enter a command like "speedup locomotive_1" and the parser ensures that the desired action gets executed. Programming such a behavior is the most advanced part of a language game.

In general grounded language starts always with a vocabulary which is a word list. The list contains of nouns, verbs and objects and is related to a domain. Symbol grounding in the strict sense means to play language games with the word list which are the pointing game and the instruction following game.

Wo kann man grounded Language einordnen?

 Wissenschaft ist in Gebieten organisiert wie Mathematik, Physik, Linguistik und Kunst. Leider ist es schwierig, die Thematik "grounded language" einem dieser Bereiche zuzuordnen. Gleichzeitig ist grounded language fundamental zum Verständnis von Robotik als lohnt es sich die Thematik näher zu untersuchen.

Von der selbstbeschreibung her ist Grounded language eine Mischung als Sprachwissenschaft mit Informatik. Natürliche Sprache wird verwendet um ein Informatik-Problem z.B. Robotik-Steuerung zu lösen. Technisch gesehen ist das ein vielversprechender Ansatz allerdings ist unklar wo Literatur über diese Thematik einsortiert werden muss. Weder in die Linguistik noch in die Informatik passt grounded language wirklich hinein. Ein möglichers Gebiet wäre die Nachrichtentechnik welche sich mit der Informationsübertragung vom Sender zum Empfänger beschäftigt, nur leider besteht Nachrichtentechnik eher aus der technischen Realisierbarkeit also wie Bits über einen Kanal fließen und weniger in der semantischen Analyse einer Nachricht.

Vermutlich werden die meisten Informatiker noch nie etwas von grounded language gehört haben. Der Grund ist dass Informatik seine Wurzeln in den exakten Naturwissenschaften hat also verwand ist mit der Mathematik und der Physik. Um Computer zu bauen benötigt man Elektrotechnik und dort speziell  Transistoren. Um Computer zu programmieren benötigt man Algorithmen welche in der Mathematik untersucht werden. Leider hat grounded language mit beidem nichts zu tun. Es ist keine matghematik sondern es ist verwand mit der Sprachwissenschaft von Ferdinand de Saussure der untersucht hat wie Zeichen ihre Bedeutung erhalten. Die Methoden innerhalb der Sprachwissenschaft unterscheiden sich grundsätzlich von den Methoden in der Mathematik. Sprachwissenschaft wird als Geisteswissenschaft bezeichnet und gehört wie Geschichte und Soziologie zur Kulturhistorie.

Wollte man grounded language angemessen berücksichtigen müsste man eigentlich eine neue Kategorie erstellen zusätzlich zur bekannten Dewey Klassifikation. Das ist praktisch nicht durchführbar weil ja die idee hinter der etablierten Systematik darin besteht die Literatur auf dieses Raster einzurodnen. Um das Problem der Einordnung zu lösen muss man zuerst einmal grob definieren ob grounded language im Bereich Naturwissenschaft oder im Bereich Geisteswissenschaft veroret ist. 

Am ehesten könnte man grounded language als Naturwissenschaft bezeichnen und zwar weil der technisch-mathematische Aspekt im Zentrum steht. Es geht weniger darum Sprache an sich zu beschreiben sondern Sprache wird verwendet um Roboter zu steuern. Ähnlich wie Motion capture ist es damit im Bereich Naturwissenschaft -> Informatik -> Robotik lokalisiert. Auch bei Motion capture verfahren werden bekanntlich Ideen aus der Sportwissenschaft verwendet, allerdings ist Mocap zunächst einmal ein technisches Verfahren und wird daher von der Informatik definiert.

Bei grounded language ging es technikhistorisch immer darum, Sensordaten mittels Computer in textuelle ausgabe zu übersetzen. Frühe Beispiele waren das SHRDLU Projekt (Terry Winograd, 1968) oder Commentator scene description (Bengt Sigurd, 1980). Der Computer wurde also zwingend in diesen Projekten eingesetzt. Da das SHRDLU Projekt primär ein Artefakt der Informatik war, ist auch grounded language ein Teilbereich der Informatik-Geschichte.

Die klassische Sprachwissenschaft untersucht ebenfalls Sprache allerdings geht es um Sprache wie sie von Menschen oder Tieren verwendet wird, nicht um Sprache die von Algorithmen erzeugt wird. Sobald der Computer im Zentrum steht wird ein Thema als Informatik betrachtet. Im Fall von grounded language steht der computer zweifelsfrei im Zentrum der Betrachung. Es geht darum Sprache soweit zu formalisieren dass sie von Computern zur Interaktion verwendet werden kann. Computer sind definitionsgemäß innerhalb der Informatik beheimatet und werden nach naturwissenschaftlichen Prinipien beschrieben.

Mag sein dass für die Beschreibung von grounded language auf Theorien der Sprachwissenschaft und Psychologie zurückgegriffen wird, aber das könnte man über Computerspiele auch sagen. So verwendet das Spiel "Sim City" elemente der Architekturplanung während Malprogramme einen Starken bezug haben zur Kunst. Trotzdem sind diese Beispiel innerhalb der Informatik verortet weil der Computer jedesmal im Zentrum steht.

Grounded language kann man daher als neues Aufgabengebiet für einen Computer definieren. Anstatt nur Daten über ein Leitung zu übetragen wie das durch das Internet erfolgt und anstatt einfach nur Zahlen aufzuaddieren wie das mit einer Tabellenkalulation möglich ist, wird durch grounded language der Computer in die Lage versetzt natürliche Sprache an Roboter zu senden und zu empfangen. Und weil dies über Algorithmen funktioniert ist die Informatik die richtige Anlaufstelle für eine weitere Literaturrecherche.