Microtype simulator in python

 

import pygame
import sys
import math

# Initialize Pygame
pygame.init()
pygame.font.init()

# Constants
WIDTH, HEIGHT = 1100, 780
SCREEN = pygame.display.set_mode((WIDTH, HEIGHT))
pygame.display.set_caption("Professional Microtype Engine & Layout Simulator")
CLOCK = pygame.time.Clock()

# Palettes
COLOR_BG = (249, 248, 245)       # Premium archival paper
COLOR_TEXT = (35, 35, 35)        # Soft black
COLOR_MARGIN = (230, 90, 90)     # Margin guideline
COLOR_UI_BG = (225, 227, 230)
COLOR_UI_TEXT = (50, 55, 60)
COLOR_SLIDER = (70, 130, 180)
COLOR_ACTIVE = (46, 139, 87)     # SeaGreen for scores/active selections

# Load fonts
try:
    FONT_SIZE = 18
    FONT = pygame.font.SysFont("georgia", FONT_SIZE)
    FONT_BOLD = pygame.font.SysFont("georgia", FONT_SIZE, bold=True)
except:
    FONT = pygame.font.Font(None, FONT_SIZE)
    FONT_BOLD = pygame.font.Font(None, FONT_SIZE)

SAMPLE_TEXT = (
    "Typography is the art and technique of arranging type to make written language "
    "legible, readable, and appealing when displayed. The Knuth-Plass dynamic programming "
    "algorithm revolutionizes this by looking ahead at the entire paragraph. Instead of "
    "making hasty choices on a line-by-line basis, it distributes layout 'badness' evenly, "
    "preventing unexpected blocks of loose text. Combined with microtype tracking expansions, "
    "subtle margin protrusions yield pristine geometric columns resembling classic elite print."
)

# --- UI Widgets ---
class Slider:
    def __init__(self, x, y, w, h, min_val, max_val, start_val, label):
        self.rect = pygame.Rect(x, y, w, h)
        self.min_val = min_val
        self.max_val = max_val
        self.val = start_val
        self.label = label
        self.grabbed = False
        self.update_handle()

    def update_handle(self):
        ratio = (self.val - self.min_val) / (self.max_val - self.min_val)
        hx = self.rect.x + int(ratio * self.rect.w)
        self.handle_rect = pygame.Rect(hx - 5, self.rect.y - 4, 10, self.rect.h + 8)

    def draw(self, screen):
        lbl = FONT.render(f"{self.label}: {self.val:.2f}", True, COLOR_UI_TEXT)
        screen.blit(lbl, (self.rect.x, self.rect.y - 22))
        pygame.draw.rect(screen, (190, 195, 200), self.rect, border_radius=3)
        pygame.draw.rect(screen, COLOR_SLIDER, self.handle_rect, border_radius=3)

    def handle_event(self, event):
        if event.type == pygame.MOUSEBUTTONDOWN:
            if self.handle_rect.collidepoint(event.pos) or self.rect.collidepoint(event.pos):
                self.grabbed = True
        elif event.type == pygame.MOUSEBUTTONUP:
            self.grabbed = False
        elif event.type == pygame.MOUSEMOTION and self.grabbed:
            mx = max(self.rect.x, min(event.pos[0], self.rect.x + self.rect.w))
            rel = (mx - self.rect.x) / self.rect.w
            self.val = self.min_val + rel * (self.max_val - self.min_val)
            self.update_handle()

class RadioSelector:
    def __init__(self, x, y, options):
        self.x = x
        self.y = y
        self.options = options
        self.selected_index = 1 # Default to Knuth-Plass
        self.buttons = []
        
        for idx, opt in enumerate(options):
            bx = x + (idx * 280)
            self.buttons.append(pygame.Rect(bx, y, 20, 20))

    def draw(self, screen):
        lbl_title = FONT_BOLD.render("Line Breaking Algorithm:", True, COLOR_UI_TEXT)
        screen.blit(lbl_title, (self.x, self.y - 25))
        
        for idx, opt in enumerate(self.options):
            rect = self.buttons[idx]
            # Draw outer circle
            pygame.draw.circle(screen, COLOR_UI_TEXT, rect.center, 10, 2)
            # Draw internal selection
            if idx == self.selected_index:
                pygame.draw.circle(screen, COLOR_ACTIVE, rect.center, 6)
            
            lbl = FONT.render(opt, True, COLOR_UI_TEXT)
            screen.blit(lbl, (rect.x + 25, rect.y + 1))

    def handle_event(self, event):
        if event.type == pygame.MOUSEBUTTONDOWN:
            for idx, rect in enumerate(self.buttons):
                # Expanded click zone for user convenience
                click_zone = rect.inflate(150, 10)
                if click_zone.collidepoint(event.pos):
                    self.selected_index = idx
                    return True
        return False

# --- Helper Text Calculation Tools ---
def compute_word_widths(words, font, tracking):
    return [sum(font.size(char)[0] + tracking for char in word) for word in words]

def calc_line_badness(width, test_width, num_gaps, base_space_width, min_space, max_space, ideal_space, is_last=False):
    if num_gaps == 0:
        remaining = width - test_width
        return (remaining ** 2) if remaining >= 0 else 500000
    
    actual_space = (width - test_width) / num_gaps
    
    if actual_space < min_space:
        # Heavily penalize over-compressed lines
        return 100000 + (min_space - actual_space) * 50000
    elif actual_space > max_space:
        # Loose lines
        return int(((actual_space - max_space) ** 2) * 500)
    else:
        # Standard deviation penalty
        badness = int(((actual_space - ideal_space) ** 2) * 100)
        if is_last and actual_space > ideal_space:
            return 0 # Last line of a paragraph shouldn't stretch to fill the margin
        return badness

def apply_protrusion(word, font, protrusion):
    protruding_chars = [".", ",", "-", "!", "?"]
    if protrusion > 0 and word[-1:] in protruding_chars:
        return font.size(word[-1:])[0] * protrusion * 0.5
    return 0

# --- Line-Breaking Core Algorithms ---

def layout_greedy(words, word_widths, font, width, min_space, max_space, ideal_space, protrusion):
    """ a) Traditional First-Fit Greedy Algorithm """
    lines = []
    current_line, current_widths = [], []
    current_width = 0
    
    for idx, word in enumerate(words):
        w_width = word_widths[idx]
        p_adjust = apply_protrusion(word, font, protrusion)
        
        # Test if it fits with standard spaces
        test_w = current_width + w_width + (ideal_space if current_line else 0) - p_adjust
        if test_w <= width or not current_line:
            current_line.append(word)
            current_widths.append(w_width)
            current_width += w_width + (ideal_space if len(current_line) > 1 else 0)
        else:
            # Seal line
            num_gaps = len(current_line) - 1
            last_word_pad = apply_protrusion(current_line[-1], font, protrusion)
            pure_width = sum(current_widths)
            
            space_used = (width - (pure_width - last_word_pad)) / num_gaps if num_gaps > 0 else ideal_space
            badness = calc_line_badness(width, pure_width - last_word_pad, num_gaps, ideal_space, min_space, max_space, ideal_space)
            
            lines.append((current_line, current_widths, space_used, False, badness))
            current_line, current_widths = [word], [w_width]
            current_width = w_width
            
    if current_line:
        num_gaps = len(current_line) - 1
        last_word_pad = apply_protrusion(current_line[-1], font, protrusion)
        pure_width = sum(current_widths)
        space_used = ideal_space
        badness = calc_line_badness(width, pure_width - last_word_pad, num_gaps, ideal_space, min_space, max_space, ideal_space, is_last=True)
        lines.append((current_line, current_widths, space_used, True, badness))
        
    return lines

def layout_knuth_plass(words, word_widths, font, width, min_space, max_space, ideal_space, protrusion):
    """ b) Look-Ahead Optimization (Global Minimum Variance) """
    n = len(words)
    dp = [(float('inf'), -1, ideal_space, 0)] * (n + 1)
    dp[0] = (0, -1, ideal_space, 0)
    
    for i in range(n):
        if dp[i][0] == float('inf'): continue
        current_width = 0
        for j in range(i, n):
            current_width += word_widths[j]
            num_gaps = j - i
            is_last = (j == n - 1)
            
            p_adjust = apply_protrusion(words[j], font, protrusion)
            line_txt_w = current_width - p_adjust
            
            badness = calc_line_badness(width, line_txt_w, num_gaps, ideal_space, min_space, max_space, ideal_space, is_last)
            
            actual_space = ideal_space
            if num_gaps > 0 and not is_last:
                actual_space = (width - line_txt_w) / num_gaps

            p_cost = dp[i][0] + badness
            if p_cost < dp[j + 1][0]:
                dp[j + 1] = (p_cost, i, actual_space, badness)

    lines, curr = [], n
    while curr > 0:
        parent = dp[curr][1]
        if parent == -1: break
        is_last = (curr == n)
        lines.append((words[parent:curr], word_widths[parent:curr], dp[curr][2], is_last, dp[curr][3]))
        curr = parent
    lines.reverse()
    return lines

def layout_first_fit_tight(words, word_widths, font, width, min_space, max_space, ideal_space, protrusion):
    """ c) Alternating Minimum Space Greedy Algorithm """
    # This variant forces as many words onto the line as physically allowed by compressing down to min_space limits.
    lines = []
    current_line, current_widths = [], []
    
    for idx, word in enumerate(words):
        w_width = word_widths[idx]
        current_line.append(word)
        current_widths.append(w_width)
        
        p_adjust = apply_protrusion(word, font, protrusion)
        num_gaps = len(current_line) - 1
        min_needed = sum(current_widths) + (num_gaps * min_space) - p_adjust
        
        if min_needed > width and num_gaps > 0:
            # Overfilled line, dump the last token to the next row
            popped_word = current_line.pop()
            popped_width = current_widths.pop()
            
            num_gaps = len(current_line) - 1
            last_word_pad = apply_protrusion(current_line[-1], font, protrusion)
            pure_width = sum(current_widths)
            
            space_used = (width - (pure_width - last_word_pad)) / num_gaps if num_gaps > 0 else ideal_space
            badness = calc_line_badness(width, pure_width - last_word_pad, num_gaps, ideal_space, min_space, max_space, ideal_space)
            
            lines.append((current_line, current_widths, space_used, False, badness))
            current_line, current_widths = [popped_word], [popped_width]
            
    if current_line:
        num_gaps = len(current_line) - 1
        last_word_pad = apply_protrusion(current_line[-1], font, protrusion)
        pure_width = sum(current_widths)
        badness = calc_line_badness(width, pure_width - last_word_pad, num_gaps, ideal_space, min_space, max_space, ideal_space, is_last=True)
        lines.append((current_line, current_widths, ideal_space, True, badness))
        
    return lines

# --- Rendering ---
def render_paragraph(lines, font, x_start, y_start, tracking, protrusion, leading_ratio):
    y = y_start
    line_height = int(font.get_linesize() * leading_ratio)
    
    for line_words, line_widths, space_width, is_last, _ in lines:
        x = x_start
        num_words = len(line_words)
        
        for w_idx, word in enumerate(line_words):
            for c_idx, char in enumerate(word):
                char_surf = font.render(char, True, COLOR_TEXT)
                render_x = x
                if w_idx == num_words - 1 and c_idx == len(word) - 1:
                    render_x += apply_protrusion(word, font, protrusion)

                SCREEN.blit(char_surf, (render_x, y))
                x += char_surf.get_width() + tracking
            
            if w_idx < num_words - 1:
                x += space_width
        y += line_height

# --- UI Layout ---
sliders = [
    Slider(50, 540, 260, 10, -1.5, 3.0, 0.0, "Font Expansion (Tracking)"),
    Slider(380, 540, 260, 10, 0.4, 1.0, 0.65, "Min Word Space Elasticity"),
    Slider(710, 540, 260, 10, 1.0, 3.0, 1.70, "Max Word Space Elasticity"),
    Slider(50, 620, 260, 10, 0.0, 1.2, 0.5, "Character Protrusion"),
    Slider(380, 620, 260, 10, 0.8, 2.5, 1.3, "Line Height (Leading)")
]

algo_radio = RadioSelector(50, 710, ["a) Greedy Algorithm", "b) Knuth-Plass Ahead", "c) Space-Tight Fit"])

MARGIN_LEFT = 200
BOX_WIDTH = 700

# Main loop
while True:
    SCREEN.fill(COLOR_BG)
    
    # Event Engine Loop
    for event in pygame.event.get():
        if event.type == pygame.QUIT:
            pygame.quit()
            sys.exit()
        for slider in sliders:
            slider.handle_event(event)
        algo_radio.handle_event(event)

    # Drawing background infrastructure boundaries
    pygame.draw.rect(SCREEN, COLOR_UI_BG, (0, 480, WIDTH, HEIGHT - 480))
    pygame.draw.line(SCREEN, (190, 195, 200), (0, 480), (WIDTH, 480), 2)
    
    pygame.draw.line(SCREEN, COLOR_MARGIN, (MARGIN_LEFT, 75), (MARGIN_LEFT, 450), 1)
    pygame.draw.line(SCREEN, COLOR_MARGIN, (MARGIN_LEFT + BOX_WIDTH, 75), (MARGIN_LEFT + BOX_WIDTH, 450), 1)

    # Gather metrics
    base_space_width = FONT.size(" ")[0]
    tracking_val = sliders[0].val
    min_space = base_space_width * sliders[1].val
    max_space = base_space_width * sliders[2].val
    protrusion_val = sliders[3].val
    leading_val = sliders[4].val

    # Re-tokenize and check widths inside runtime
    words = SAMPLE_TEXT.split(" ")
    word_widths = compute_word_widths(words, FONT, tracking_val)

    # Route processing via radio flag selections
    if algo_radio.selected_index == 0:
        computed_lines = layout_greedy(words, word_widths, FONT, BOX_WIDTH, min_space, max_space, base_space_width, protrusion_val)
    elif algo_radio.selected_index == 1:
        computed_lines = layout_knuth_plass(words, word_widths, FONT, BOX_WIDTH, min_space, max_space, base_space_width, protrusion_val)
    else:
        computed_lines = layout_first_fit_tight(words, word_widths, FONT, BOX_WIDTH, min_space, max_space, base_space_width, protrusion_val)

    # Cumulative Badness Score Calculation
    total_paragraph_badness = sum(line[4] for line in computed_lines)

    # Render Paragraph Blocks
    render_paragraph(computed_lines, FONT, MARGIN_LEFT, 95, tracking_val, protrusion_val, leading_val)

    # Render Widgets
    for slider in sliders:
        slider.draw(SCREEN)
    algo_radio.draw(SCREEN)

    # Display Badness score at the top panel
    score_lbl = FONT_BOLD.render(f"Overall Paragraph Badness Score: {total_paragraph_badness}", True, COLOR_ACTIVE)
    SCREEN.blit(score_lbl, (MARGIN_LEFT, 35))

    pygame.display.flip()
    CLOCK.tick(30)

Die goldene Zeit von LaTeX

 Die Goldene Zeit des Textsatzsystems liegt weit in der Vergangenheit. LaTeX war zumindest früher eine lebendige Community die aktuelle Technologie nutzte. Man kann diese Zeit im Jahr 1995 verorten. Damals gab es noch kein pdflatex sondern eine DVI Datei wurde mittels dvips nach postscript konvertiert. Anders als heute war dieser Workflow standardisiert, das heißt 99% der Anwender erstellten auf diese Weise ein wissenschaftliches Buch und es gab auch nur das eine LaTeX2e System mit einer kleinen Zahl von Zusatzpackages.

Eine typische tetex installation aus dieser Zeit beanspruchte 150 MB auf Festplatte. Im universitären Umfeld wurden meist SUN Sparcstation Maschinen genutzt auf denen LaTeX inkl. der benötigten Schriften verwendet wurde. Das erwähnte LaTeX2e war damals in 1995 gerade frisch veröffentlicht worden und vereinheitlichte den früheren Wildwuchs. Dadurch wurde LaTeX zum führenden Publishing Werkzeug bei Naturwissenschaftlern und wissenschaftlichen Zeitschriften.

Die schlechte Nachricht lautet, dass diese goldene Zeit viele Jahrzehnte zurückliegt. Seit damals ging die Qualität von LaTeX merklich zurück. Das System, also LaTeX2e mitsamt dvips, ist noch die selbe Software allerdings ist die Welt heute eine andere. Latex ist auf dem alten Stand von 1995 stehengeblieben, seitdem gab es keine wirkliche Innovation mehr. Rein formal wurden zwar Erweiterungen entwickelt wie context, pdflatex und lualatex, doch nicht alle Anwender nutzen diese und einen erkennbaren Vorteil gibt es auch nicht.

Kritik an LaTeX

 Die Typst software ist umfassend online dokumentiert, ist technisch ausgreift und eignet sich hervorragend zum wissenschaftlichen Satz. Da der marketshare von typst bisher kleiner ist als 0.1% dauert es wohl noch einige Jahre bevor das Thema für eine größere Personenzahl relevant wird. Diese Zeit kann man nutzen um das Gegenmodell LaTeX einer kritischen Würdigung zu unterziehen.

Anstatt auf die Anfänge von TeX einzugehen die in den späten 1970er Jahre liege wo bekanntlich Unix Gurus mit Magnetbändern auf DEC Minicomputers gearbeitet haben, macht es Sinn LaTeX in der Gegenwart zu betetrachten. Leider sieht es bei den Detail gar nicht gut aus. Zum einen fällt auf, was alles nicht geht mit LaTeX:

- dreispaltensatz ist nur mit zusatzpaketen möglich
- überhaupt benötigt man für alles mögliche ein package, sei es das einbinden von Grafiken, das Anzeigen von Sourcecode oder das Setzen von Tabellen
- ein Export nach HTML ist nicht möglich nur über weitere pakete oder gar pandoc funktioniert es 
- Die Tex engine ist eingefroren und wird nicht mehr verbessert, bisherige versuche einen LaTeX nachfolger zu entwickeln wie context oder Latex3 sind gescheitert
- großes repository mit veralteten Paketen
- Community ignoriert sachliche Kritik

Schwächen von LaTeX werden nicht behoben sondern sie werden als historisch determiniert wahrgenommen. So ist z.B. die unfähigkeit von LaTeX eine HTML Datei zu erstellen damit zu ekrlären dass es Ende der 1970er als Donald Knuth die erste Version in Turbo Pascal programmiert hat, noch kein HTML gab. Wenn jetzt ein neuling aber genau diese Funktion benötigt wird diesem User geraten lieber auf MS Word umzusteigen weil er keine Einsicht zeigt in die Philosophie von TeX.

Ein solches Ökosystem kann man getrost als statisch bezeichnen. So ähnlich wie die TeX engine im Jahr 1990 eingefroren wurde ist auch die heutige LaTeX Community wie ein Eisblock unbeweglich. Es gibt dafür keine sachlichen Gründe sondern der status quo aus früheren Zeit soll unverändert bleiben. Wie bei Sekten steigt dadurch die Entropie an. Entropie ist ein Maß für das Chaos was innerhalb der LaTeX Community nicht abgebaut werden kann. Man kann das sogar messen und zwar an der Zahl der benötigten megabyte die texlife auf der Festplatte benötigt.

1990, 10 MB
2000, 100 MB
2010, 800 MB
2020, 2 GB
2026, 2.8 GB

Selbst für aktuelle high end PC die mit SSD als Festplattenersatz arbeiten ist die installation und das update einer LaTeX Installation ein Großprojekt. Es müssen unzählige Einzeldateien heruntergeladen werden und die chance dass dabei Fehlermeldungen entstehen ist hoch. Technisch gesehen müsste jemand die Software modernisieren, also nicht benötigte Pakete entfernen, die Engine neu programmieren usw. Es gab mehrmals diese Versuche die jedoch gescheitert sind, zuletzt wurde das Luatex projekt gestartet. In der Praxis nutzen die meisten User jedoch das ältere pdflatex, weil das schneller eine PDF Datei erzeugt. Leider sind damit die Modernisierungen von Luatex hinfällig und die Entropie steigt weiter.

Es gab mehrere Versuche LaTeX zu modernisieren:
- LaTex3
- Omega
- ConTeXt
- LaTeX2HTML
- LuaTeX
- Overleaf

Jedes Projekt hat schwächen und wird von der Community kritisiert. Das hatte zur Folge dass viele Parallel projekte entstanden mit unterschiedlichen Zielsetzungen.

Kurzbericht zu typst 0.15

 Seit Juni 2026 ist das Textsatzsystem typst in der neuen Version 0.15 verfügbar. Die Installation gestaltet sich so dass man eine ausführbare Datei herunterlädt welche entpackt rund 55 MB groß ist. verglichen mit pdflatex was in Linux rund 2 GB benötigt ist das sehr wenig Speicher. Trotzdem haben die Entwickler es erneut geschafft mit dieser einzigen Datei alle wichtigen Gebiete abzudecken die man von einem LaTeX Nachfolger erwartet:

- 2 spalten satz
- blocksatz
- unterschiedliche Schriftarten
- automatische Inhaltsverzeichnisse
- Tabellen
- Bilder in unterschiedlichen Formaten wie jpg, svg, png usw.

Ehemalige LaTeX Nutzer werden bemerken, dass die typst Syntax deutlich einfacher zu verwenden ist. Es gibt wenig bis gar keine Zusatzpakete die man einbinden muss sondern alle wichtigen Funktionen sind in der ausführbaren typst Datei enthalten. Es reicht aus, einmalig sich in das Program einzuarbeiten, ein wenig mit float figures und Tabellensatz herumzuprobieren und schon kann man umfangreiche wissenschaftliche oder sonstige Dokumentationen erstellen. Die Lernkurve ist deutlich flacher als bei LaTeX, die Ausgabequalität ist vergleichbar hoch.

Typst füllt damit ein Lücke die frühere Linux Kommandozeilen tools wie asciidoc, pandoc oder HTML hinterlassen haben. Es ermöglicht die Erstellung von Dokumenten in einem Texteditor und ist damit weitaus besser für umfangreiche Texte geeignet als Libreoffice.

Die Zielgruppe von typst sind zweifelsfrei frühere LaTeX user, diese zu überzeugen auf die neue Software umzusteigen ist die größte Hürde. LaTeX ist bekanntlich ein sehr mächtiges Ökosystem was über Jahrzehnte gewachsen ist. Viele LaTeX User empfinden typst als Rückschritt, gerade weil es leichter zu benutzen ist und die Einstiegshürde senkt. Man muss weder mit dem troff System aus Unix vertraut sein, noch muss man eine rekursive Makrosprache lernen, sondern typst ist ähnlich wie Markdown für ein großes Zielpublikum entwickelt worden.

Vielleicht ein kleines Textbeispiel. Zuerst LaTeX:

\begin{enumerate}
  \item erstes 
  \item zweites 
\end{enumerate}

dann typst:

1. erstes
2. zweites

Hier noch ein Beispiel zum Einbinden einer Grafik. Zuerst LaTeX:

\usepackage{graphicx}
\begin{figure}
  \includegraphics{lion.png}
\end{figure}
  
dann typst:

#figure(
  image("lion.png", width: 6cm),
  caption: [Lion],
)

Wenn man sich zusätzlich noch die Compilergeschwindigkeit anschaut mit der typst umfangreiche Dokumente inkl. Abbildungen in eine PDF Datei ausgibt so dürfte die LaTeX Community es schwer haben mit Argumenten zu überzeugen. Was bleibt ist die Tatsache, dass LaTeX das ältere und etablierte System ist während typst in einer frühen Version daherkommt und bisher nur selten praktisch angewendet wird.

Head up display with inner voice for a kitchen robot in pixelart

Haushaltsroboter in den 1980er Jahren

 Zeitgleich zum Aufstieg der 8bit Heimcomputer in den 1980er gab es eine kurze Blütezeit für Haushaltsroboter. Die verkaufte stückzahl war sehr gering, und es wurde nie ein Massenprodukt. Dennoch wurden Mitte der 1980er einige frühe Roboter herstellt wie:

- Hero 24kb ram, intel 8088 cpu
- Arctec gemini, mit 100 kb RAM
- Androbot B.O.B.

Verbaut wurde damalige state of the art technologie, also 8bit CPU, ein sehr kleiner RAM und häufig BASIC ähnliche Programmiersprachen im ROM. Anders als die sehr erfolgreichen Heimcomputer von Atari und Commodore hatten die obigen Roboter keinen sinnvollen Verwendungszweck. Sie konnten zwar durch servomotoren auf dem Teppich herumfahren aber bereits die selbstlokalisierung funktioniert nicht und das greifen von Gegenständen war nur mittels Fernsteuerung möglich.

Man kann anhand dieser frühen Roboter gut erkennen warum Künstliche Intelligenz sich in den späten 1980er Jahren in einer Sackgasse befand. Und zwar weil die damals verfügbare Hard- und Software keinerlei praktische Anwendungsmöglichkeiten hatte.

Konträr dazu konnten dezidierte Heimcomputer wie der berühmte Commodore 64 oder der Apple II sehr variable verwendet werden. Man konnte damit Spiele spielen, man konnte Programmieren lernen, man konnte kurze Texte eintippen und man konnte Grafiken auf dem Bildschirm zeichnen.

Das eigentliche Problem mit den Robotern aus den 1980er war weniger ihre schlechte Hardwareausstattung sondern die Frage wie man die Funktionen des Roboter hochskalieren sollte. Also wie aus einem klobigen Plasteeimer eine intelligente Maschine wird, die eigenständig Entscheidungen trifft.

Diese Frage wurde gestellt, aber es hatte niemand eine Antwort darauf. Künstliche INteligenz war zwar als Begriff vorhanden aber es war unklar wie man diese technisch erreicht.

Im Jahr 2026 gibt es eine Antwort auf das KI Problem und zwar benötigt man ein Speaker hearer language game. Durch ein Sprachspiel mit verteilten Rollen lässt sich menschliches Denken auf zwei Stellen aufteilen und dadurch maschinell zugänglich machen. Zwar konnte 

Technisch hatte der Arctec gemini Roboter aus dem Jahr 1985 eine eingebaut "voice/speech recognition" war also in der Lage einen natürlichsprachlichen Dialog mit Menschen zu führen. Allerdings wurde dieses Feature zur damaligen Zeit nicht als Kernbestandteil der Künstlichen Intelligenz betrachtet. Die Annahme in den 1980er und teilweise bis in die 2000er Jahre lautete, dass Künstliche Intelligenz innerhalb eines Roboters verortet sei, also ein Algorithmus sei der von der CPU ausgeführt wird.

Die moderne KI Forschung sieht das grundsätzlich anders. Danach ist künstliche Intelligenz ein Kommunikationsmuster bei dem Nachrichten von A nach B übertragen werden. Es wird also nichts berechnet sondern es wird eine Nachricht befördert. Sobald man Künstliche Intelligenz als Nachrichtenübermittlung betrachtet kann man die Leistung hochskalieren. Man beginnt mit einem sehr einfachen Sprachspiel was man als computerprogram implementiert, z.B. "Hol das Objekt". Der speaker sagt einen Begriff wie "Ball" und der Hearer muss das objekt finden und einsammeln.

Die nächste Stufe wäre das Sprachspiel etwas komplexer zu gestalten, also die Anzahl der Worte erhöhen, und neben "hol" weitere Aktionswörter zu verwenden.

Das Nachrichten-basierte Verständnis von Künstlicher Intelligenz hat sich in der Informatik sehr spät durchgesetzt. Erst ab dem Jahr 2023 mit der Entwicklung von LLM Sprachmodellen wird Künstliche Intelligenz gleichgesetzt mit Mensch maschine interaktion. Der Mensch formuliert einen Text-Prompt, welcher von der Maschine durch ein Sprachmodell beantwortet wird. Je mehr anfragen ein Sprachmodel versteht und bearbeitet desto leistungsfähiger ist die Künstliche Intelligenz.

Das Hochskalieren von Künstlicher Intelligenz ab dem Jahr 2023 erfolgt durch immer komplexer werdende Benchmarks. Die ersten Datasets welche durch neuronale Netze bearbeitet wurden bestanden aus simplen Frage/Antwort paaren. Der speaker stellt eine Frage "Was ist die Hauptstadt von Groß Britanien?" und der Hearer muss die richtige Antwort sagen "London". Zunächst waren diese Datasets eingeschränkt auf eine einzige Domäne, also nur geographie Kenntnisse, nur Mathematik-Kenntnisse. Später begann man universal Datensätze zu nutzen wo also unterschiedliche Wissensgebiete mit einer Punktezahl abgefragt wurden.

Die nächste Stufe in der Entwicklung Künstlicher Intelligenz bestand damit weiter interaktionen ausführen, das also der Datensatz Bilder und Töne enthielt. Die interaktion bestand jetzt darin dass der Speaker eine Aufgabe stellt wie "Male ein Bild mit einem Sonnenaufgang" und der Hearer musste dazu das passende Bild erstellen. Anschließend wurde begonnen die Schwierigkeit weiter zu erhöhen. Neuere Benchmarks enthalten komplexe Aufgabenstellungen wo also komplette Texte erzeugt werden oder umfangreiche tabellen formatiert werden. Auch diese Aufgaben werden interaktion über speaker to hearer kommunikation realisiert.

Kurzgeschichte: Robotersteuerung mit genetischen Algorithmen

Überall summen leise Motoren. An den Wänden hängen Monitore mit endlosen Datenströmen. In der Mitte des Raums steht ein eleganter, humanoider Roboter, der fehlerfrei Porzellantassen von einer Spülmaschine in einen Oberschrank räumt. Li Wei, ein Austauschstudent aus Peking, beobachtet die Szene fasziniert, ein digitales Notizbuch fest in der Hand. Dr. Elena Brandt, die leitende Forscherin, tritt zu ihm.

Dr. Brandt: (lächelt) Faszinierend, nicht wahr? Er hat seit heute Morgen nicht eine einzige Tasse fallen gelassen. Willkommen in unserem Labor, Li Wei.

Li Wei: (verneigt sich leicht) Vielen Dank, Frau Dr. Brandt. Es ist mir eine große Ehre, hier zu sein. Die flüssigen Bewegungen dieses Modells... das ist die neue Generation des Domestic-Helper-2000, richtig? Ich habe Ihre Veröffentlichungen gelesen, aber die Realität übertrifft alles. Die Trajektorienplanung muss unglaublich präzise sein. Läuft das über ein klassisches neuronales Netz?

Dr. Brandt: (schüttelt den Kopf) Nein, tatsächlich nicht mehr. Das war die letzte Generation. Was Sie hier sehen, ist ein völlig neuer Ansatz für die Echtzeit-Adaption. Die Steuerung dieses humanoiden Haushaltsroboters basiert auf genetischen Algorithmen.

Li Wei: (stutzt, die Augen weiten sich) Genetische Algorithmen? Für die direkte Motorsteuerung eines Humanoiden? Das... das ist ein mathematisches Optimierungsverfahren, oder?

Dr. Brandt: Genau. Wir nutzen die Prinzipien der biologischen Evolution – Selektion, Kreuzung und Mutation –, um die optimalen Bewegungsmuster für unvorhergesehene Haushaltsbzw. Alltagssituationen zu finden.

Li Wei nickt eifrig und beginnt sofort, handschriftliche Notizen auf seinem Tablet zu machen. Seine Augen leuchten vor akademischer Neugier.

Li Wei: (schreibt schnell) Evolutionäre Strategien im Haushaltsbereich... Aber Frau Doktor, genetische Algorithmen sind doch extrem rechenintensiv! Um eine Population von potenziellen Bewegungspfaden zu generieren, ihre Fitness zu bewerten und sie über Generationen hinweg zu optimieren... das braucht doch astronomisch viel CPU-Leistung?

Dr. Brandt: (seufzt hörbar) Da haben Sie den wunden Punkt getroffen. Sie sind gut informiert. Ja, der Heißhunger auf CPU-Leistung ist gigantisch. Schauen Sie mal hier rüber.

Sie geht zu einem gläsernen Schaltschrank in der Ecke des Labors. Darin leuchten blaue LEDs, und das Rauschen von Hochleistungs-Lüftern ist permanent im Hintergrund zu hören.

Dr. Brandt: Das ist unsere Recheneinheit. Der Roboter selbst trägt nur die Sensorik und die Aktuatoren. Die eigentliche „Evolution“ der Algorithmen findet auf diesem lokalen Edge-Server statt. Für die Fitnessfunktion müssen wir in Millisekunden berechnen, wie stabil der Roboter steht, wie viel Drehmoment auf die Gelenke wirkt und ob die Tasse ganz bleibt. Das zwingt selbst modernste Multi-Core-Prozessoren in die Knie.

Li Wei: (schreibt verbissen mit) „Lokaler Edge-Server notwendig... Extreme Last auf Multi-Core-CPUs... Fitnessfunktion berechnet Stabilität, Drehmoment und Objektschutz in Echtzeit...“

Li Wei blickt von seinem Tablet auf.

Li Wei: Aber wie lösen Sie das Latenzproblem? Wenn der Roboter stolpert, kann er doch nicht erst zweihundert Generationen an Algorithmen abwarten, bis die CPU die optimale Ausgleichsbewegung berechnet hat?

Dr. Brandt: Ausgezeichnete Frage. Wir nutzen ein hybrides System. Für den absoluten Notfall – also das Stolpern – greift ein klassisches, schnelles Hardwaresystem. Aber für die Optimierung des Greifens, das Ausweichen von Haustieren oder das Umorganisieren einer chaotischen Küche nutzen wir die genetische Optimierung. Der Roboter „probt“ die Bewegung quasi tausendfach im virtuellen Raum der CPU, bevor er den Arm auch nur einen Zentimeter bewegt. Die „fitteste“ Lösung gewinnt.

Li Wei: (murmelt, während er tippt) Virtuelles Proben... Evolutionäre Selektion vor der physischen Ausführung... Das bedeutet, der Roboter lernt permanent und individuell in jeder neuen Wohnung?

Dr. Brandt: Exakt. Jeder Haushalt ist anders. Ein starrer Algorithmus scheitert an Kleinigkeiten. Unsere genetischen Algorithmen passen sich an die spezifische Umgebung an. Nach ein paar Tagen hat die CPU die perfekte „DNA“ für die Interaktion mit den Möbeln des Besitzers gezüchtet.

Li Wei: Das ist genial, aber der Energieverbrauch muss durch die CPU-Auslastung enorm sein. Für den kommerziellen Massenmarkt in China oder hier in Europa ist das Design so doch noch schwer zu skalieren, oder?

Dr. Brandt: Da haben Sie völlig recht. Das ist unsere aktuelle Forschungsfrage: Wie komprimieren wir diese mathematische Optimierung, ohne die Evolutionsqualität zu verlieren? Wenn Sie Ihre Masterarbeit bei uns schreiben, könnten Sie genau an dieser Schnittstelle forschen.

Li Wei hält inne. Er blickt auf seine Notizen, dann auf den Roboter, der gerade die letzte Tasse perfekt platziert hat, und schließlich zu Dr. Brandt. Ein breites Lächeln breitet sich auf seinem Gesicht aus.

Li Wei: Frau Dr. Brandt... das wäre mir eine absolute Ehre. Ich glaube, ich habe gerade mein Traum-Forschungsthema gefunden.

Das Grounding Problem in der Geschichte der KI

 In der Geschichte der Künstlichen Intelligenz gab es zwei wesentlichen Ansätze zur Wissensmodellierung: einmal die symbolische KI die in der Frame Theory ihren Höhepunkt fand und bei der Wissen als Objekte abgelegt werden die untereinander kommunizieren und zweitens die Programmiersprachen angefangen von C/C++ als Systemprogrammiersprachen bis hin zu modernen KI Sprachen wie LISP und Prolog welche beide das Speichern von Wissen unterstützen.

Leider gibt es mit diesen Ansätzen ein Problem: es skaliert nicht. Will man ein konkretes Problem lösen z.b. eine Robotersteuerung entwickeln wird man mit Frames, Lisp, Prolog oder semantischen Netzen keinen Erfolg haben. Woran es mangelt ist die praktische Relevanz. Selbst für Triviale Probleme wie towers of honoi ist es extrem schwer eine Implementierung in Prolog oder als Frames zu realisieren. Man kann also unterstellen, dass die Künstliche Intelligenz in einer Sackgasse ist.

Diese Sackgasse wird deutlich sobald man versucht einem Computer das denken einzuprogrammieren. Mag das Schreiben eines normalen Computerprograms in C/C++ noch halbwegs lösbar sein, ist das Einprogrammieren von Faktenwissen in eine Maschine eine unlösbare Aufgabe. Wichtig ist zu wissen dass selbst weiterentwickelte Konzepte wie agentenbasierte Programmiersprachen oder Web 2.0 Semantiken welche die Frame Theorie weiterentwickelt haben nicht zu erfolg führen.

Es ist gut nachvollziehbar warum Anfang der 1990er Jahre die Künstliche Intelligenz Forschung wiedereinmal für gescheitert erklärt wurde. Die ursache liegt darin wie in der Nicht KI Informatik Software entwickelt wird nähmlich um sie auf einer CPU auszuführen. Die Vorstellung der Programmierer lautet, dass ein Spiel oder eine Datenbank auf einer konkreten CPU ausführbar ist, entweder als direkte Assembler routine oder als imperative Programmiersprache die mittels Compiler in Assembler code konvertiert wird. Vorhandene Bibliotheken die grafikroutinen oder Hardwaretreiber enthalten sind ebenfalls mit dieser Zielstellung entwickelt worden. Man kann sagen, dass Softwareentwicklung immer prozessororientiert funktioniert.

Dieses Konzept ist ungeeignet für die Erstellung von KI Applikationen, das war jedoch den Forschern Anfang der 1990er Jahre nicht bekannt. Sie unterstellten, dass KI Anwendungen ebenfalls prozessororientiert erstellt werden könnten. So wurden mit viel Aufwand KI Programmiersprachen und sogar KI Softwarebibliotheken erstellt in der wagen HOffnung das man dieses Konzept hochskalieren könnte zu leistungsfähigeren Anwendungen.

Das Gegenmodel zu einer computational approach ist ein Kommunikationsparadigma das erstaunlicherweise sogar in der klassischen Informatik diskutiert wird. Überall dort wo Computernetzte gebildet werden liegt der Fokus auf dem Datenbus und nicht auf der Einzel-CPU. Diese Kommunikationsorientierte Perspektive kann auf die Künstliche Intelligenz und Robotik übertragen werden und hilft dabei intelligente Maschinen zu entwickeln. Anstatt zu diskutieren welcher Algorithmus und welche Programmiersprache benötigt wird, lautet die neue Fragestellung welches Protokoll sinnvoll ist und wie Daten übertragen und geparst werden müssen.

Betrachten wir beide Konzepte im direkten Verrgleich um die Unterschiede zu verdeutlichen. Die klassische CPU orientierte Sichtweise fokussiert auf einen Einzelcomputer und versucht für die dort vorhandene CPU Software zu erstellen. Die Idee ist dass die CPU die Software ausführt und daraufhin eine 2d Grafik auf den Bildschirm zeichnet oder eine Datenbank durchsucht. Umgekehrt liegt bei einer Kommunikationsorientierte Sichtweise der Fokus auf dem Bus, also dem Kabel zwischen zwei Computern. Dieses Kabel ist entweder als phyissches Koaxial Kabel, als Lichtwellenleiter oder sogar als Airgap bei Wifi realisiert und enthält weder eine CPU noch eine Datenspeicher, sondern ein Kabel ist ein Medium über das Daten überrragen werden. Man kann für einen Bus auch keine Software schreiben im traditionellen  Sinne sondern man kann lediglich Protokolle erfinden die zur Kommunikation verwendet werden.

Sämtliche Entwicklungen der Künstlichen Intelligenz ab dem Jahr 2020 wie Question/answering Pairs, motion capture annotation, Speaker Hearer interaction, Vision language modelle können als Kommunikation zwischen zwei Systemen verstanden werden. Immer wird von einerm Sender an einen Receiver ein Datenpaket übertragen. im Fall einer Question answer challenge ist das Datenpaket eine Frage auf die der receiver mit einem Datenpaket antwortet während bei einem Instruction following task der sender einen Befehl sendet welcher vom receiver ausgeführt wird. Es gibt also nicht eine CPU die ein Program ausführt, sondern es gibt immer zwei instanzen zwischen denen Daten übertragen werden.

Damit verlagert sich der Fokus weg von der internen Funktionsweise eines Computers hin zu offenen Systemen die mit ihrer Umwelt interagieren. Wie diese Systeme intern arbeiten ist zweirangig.

AI as the art of finding problems

 In classical computer engineering there are many obvious problems available for example how to compress a videogame into 64kb of RAM, how to design a CPU which is 50% faster, how to render a 3d animation on the screen. These problems are creating a creativity space in which possible answers are discussed, revised or rejected. A typical programmer never interprets a challenge as a dead end but as an opportunity to find an answer.

For Artificial Intelligence there is no such a problem available. This makes it hard to discuss what AI is about. The philosophical problem space of "AI is to build an intelligent machine" isn't a problem space in a technical space because no existing tools or algorithm can be applied to this challenge.

If classical computer engineering is about problem solving, AI is maybe the art of searching for problems. A good AI problem can be solved and is related to thinking machinery. Typical examples for these problems are computer chess, micromouse challenge and a chatbot competition in which the answers of a chatbot are scored. These problems can be solved with existing tools like hardware, software, libraries and AI algorithms.

A new and very powerful problem space is a dataset which is discussed in the literature frequently after the year 2000. A dataset is a universal problem because there are datasets for image recognition, trajectory planning, OCR, question answering, motion capture and so on. MOst real world problems can be presented as a dataset. The dataset is not the answer to a problem and it doesn't controls a robot, but a dataste formulates an AI problem in a machine readable format. A single dataset can be solved with different tools e.g. a certain neural network, a handcoded software, or with a pattern matching algorithm.

What can be observed in the literature is, that the amount of datasets has exploded since the year 2000 and the difficulty has increased. From today's perspective a dataset is a universal problem generator which is used to measure every new generation of large language models.

Let me give an example how a dataset works. Suppose there is a table with 10 motion capture poses including the textual annotation. The task for a computer is replicate the shown picture to text pairs. That means, the computer sees a picture and has to print the correct annotation on the screen. In this specific case, Artificial Intelligence is defined as the ability to find matching pairs in the dataset. In other words, the definition of AI can't be discovered in nature but it has to be constructed similar to a painting. The art of dataset creation means basically to discover new sort of problems not available before.

Vision to language dataset for a warehouse robot

 

example2:

 example3:

 

Short history of ingame AI

 Apart from automation tasks in a factory, there are major attempts available since the 1980s to build intelligent ingame characters targetted towards videogames. This subject seems to be easier to solve because in a videogame all the information are known.

Typical ingame AI in the 1980s was realized with Finite state machines. Especially the pacman game is using this single technique to control the ghosts. Another famous approach is depth first search used in board games likes chess and Nine men's morris.

Both concepts have major disadvantages. A finite state machine is difficult to program and a game state traversal in chess needs a lots of CPU ressources. Until around the year 2000 there were no improvements available. Even if finite state machine have evolved into behavior trees it was also hard to implement.

The main challenge in programming an ingame AI can be summarized as the reality gap between the videogame and the internal representation of the AI agent. A Finite state machine has a certain perspective towards the game encoded in state. For example a pacman ghost has states like attack, evade, idle, random and these states are applied to the current situation. In most cases the reality of a game is more complex than the game AI representation which causes an asynchronous situation. In other word, the game AI isn't communicating enought with the videogame and this explains its poor decision making.

To overcome the bottleneck of ingame AI created until the year 2000 the focus should be on the communication between a videogame and an ingame AI. For reason of simplication there is a virtual referee who is talking to the ingame AI in natural language. This virtual referee is the source of intelligence. He will guid the AI agent. In case of Pacman the referee might say to a ghost "move to upper left", in case of chess the referee might say "protect the center".

Such kind of textual interaction solves the former reality gap. The game AI gets a constant flow of commands from the referee and the only obstacle is to understand and execute them.

Lets compare old school ingame AI with modern communication based AI. The typical AI for a videogame before the year 2010 was realized as a software project. The idea was to encode the knowledge in the source code and make the AI smart by itself. The goal was that the AI acts independent from its environment and has all the needed knowledge and all the needed algorithm as internal software modules for pathfinding, decision making, perception and case based reasoning. Of course it was very complicated to program such an AI but there was no alternative available.

In contrast, modern AI created after the year 2010 is working with the extend mind thesis. The source of knowledge and intelligence is located ooutside of the game bot, either in the game engine, in a virtual referee or in a human operator. There is no need to encode knowledge into the AI itself but the AI is realized as parser for external commands, similar to a receiver in a RC Car teleoperation. The receiver listens to the signals and converts into action. this principle results into a minimalistic software which is much easier to realize and is more flexible at the same time.

The surprising situation is, that technically such a concept was realized in the 1980 already but it was recognized as a here to stay technology. In case of text adventure likes Zork and early role playing games, the human user was entering text commands which were executed by the game engine. So there was no AI available as a compuational engine, but there was only a parser available which executed a two word command.

Such a parser has no reality gap because it has no internal representation. The external human operator is responsible that the avatar is reaching its goal. The parser is only a command receiver.

Vision and language dataset generator

The screenshot consists of a random scene generator plus a textual annotation for a food collecting robot. The algorithm generates a maze including food items, and the text widget shows the description of the scene.

Such a setup is useful to generate a synthetic dataset with picture/text pairs to train a neural network.

Sprachverstehen durch Computer

Zuverlässige Spracherkennung funktioniert nur in Science fiction Serien aber nicht in der Realität. Über Jahrzehnte war es ein ungelöstes Problem der Informatik ein natürlich-sprachliches Interface zu programmieren. Mit ein Grund dürfte darin liegen, dass aus Linguistischer Perspektive unklar war, was genau natürliche Sprache eigentlich ist.

Man kann Sätze als String-array in Computern speichern und sogar Subjekt / Verb und Objekt erkennen, nur folgt daraus nichts für einen Computer. Ein Computer versteht nur eine Sprache und das ist Assemblersprache oder notfalls eine Programmiersprache wie C/C++. Natürliche Sprache funktioniert nach komplett anderen Regeln. Um den Gap zu schließen gitl es das Problem Spracherkennung zunächst einmal mathematisch zu beschreiben in Form eines Datasets. In der ersten Spalte werden natürlich sprachliche Kommandos abgelegt wie "fahre zum Regal B" während in der zweiten Spalte eine Sequenz von Bildern hinterlegt ist die Zeigen was der Roboter tun soll.

Dieser Dataset definiert was das Problem ist und zwar soll der Computer so agieren wie in dem Dataset dargestellt. Erst in einem zweiten Schritt überlegt man sich dafür passende Alogirthmen oder entwirft neuronale Netze welche die Fehlerzahl möglichst minimieren. Sprachverstehen ist nach dieser Definition also die Fähigkeiten einen vorhandenen Dataset zu imitieren. Zuerst entwirft man einen Sprachtest und dann ermittelt man die punktzahl eines Computerprograms um diesen Test zu bestehen. Das ist das Grundprinzip beim Deep Learning wie es seit den 2010er Jahren erfolgreich in der Informatik erforscht wird.

Geschlossene Systeme und das Scheitern Künstlicher Intelligenz

 In Ergänzung zu früheren Blogposts über geschlossene Systeme soll ausführlicher erläutert werden wo das Problem mit solchen Systeme besteht.

Zunächst einmal ist ein geschlossenes System etwas gutes in der Technikgeschichte weil es dabei hilft Komplexität zu senken. Ein Dieselmotor basiert auf physikalischen Prinzipien realisiert in der Anordnung der Bauteile. Alles was nichts mit der Umwandlung von fossiler Kraftstoffe in Drehbewegung zu tun hatt gehört defnitionsgemäß nicht zu einem Dieselmotor und liegt außerhalb. Es kann ignoriert werden. Dadurch kann man räumlich wie sachlich eingrenzen worum es bei einer Kraftmschine geht. Man kann Bücher darüber verfassen, man kann das Prinzip verstehen und nachbauen.

Auch Softwareentwicklung funktioinert als geschlossenes System. Ein Tetric Computerspiel realisiert in der C/C++ Sprache besteht aus dem sourcecode der ca. 500 lines of code umfasst. Alles was nicht in diesem Sourcecode definiert wurde, gehört nicht zum Projekt, liegt außerhalb und kann ignoriert werden. Folglich besteht Programmieren darin, den vorhandenen Sourcecode zu verbessern. Es gibt auch hier ein sachliches Thema auf das man fokussieren kann und was in ein erfolgreiches Projekt mündet.

Geschlossene Systeme zeichnen sich dadurch aus, dass eine scharfe Systemgrenze gezogen wird, etwas ist Bestandteil des Systems oder eben nicht. Auch sehr große umfangreiche Softwareprojekte wie ein Betriebssystem können als geschlsosene Systeme betrachtet werden. Sie bestehen aus mehreren tausend Dateien mit dem Sourcecode, und alles was darin nicht definiert wurde gehört nicht zum Betriebssystem. Diese banale Feststellung ist so allgegenwertig dass man in der Realität verinfacht nur von Systeme spricht und annimmt, dass alle Systema auf diese Weise erstellt und verbessert werden.

Genau dieser Trugschluss führte bis 2010 dazu, dass Künstliche Intelligenz nach einem ähnlichen Prinzip imaginiert wurde. Die Annahme war, dass ein Roboter oder eine KI Software als geschlsosenes System funktioniert, wo also in Software bestimmte Module und Algorithmen enthalten sind. Z.B. könnte ein Roboter eine pfadplanungs routine enthalten.

Ein solches KI System wird dadurch verbessert dass man weiteren Sourcecode anfügt und vorhandene algorithmen verbessert. Die meisten Robotikprojekte bis 2010 wurden nach dieser Prämisse entwickelt. Speziell der umfangreiche Sourcecode von selbstfahrenden Autos vor dem Jahr 2010 wurde ähnlich wie ein Softwaregroßprojekt programmiert: es gab Bugtracker, es gab versionsverwaltungssysteme und es gab eine Codebasis die in eine ausführbare Exe datei kompiliert wurde.

Leider gibt es mit geschlossenen KI systemen ein Problem. Je mehr ein solcher Roboter leisten soll, desto mehr Sourcecode wird benötigt. Und damit steigt die Fehleranzahl an. Bereits sehr kleine ingame AI projekte bei denen nur eine Spielfigur von einem NPC gesteuert wird, benötigen sehr viele Codezeilen. Will man selbstfahrende Autos programmieren steigt der bedarf an Lines of Code weiter. Vorhandene Werkzeuge um große Informatik Projekte zu organisieren, wie wikis oder bugtracker mögen für die klassische Softwareentwicklung gute Dienste leisten, bei dezidierten Robotik-Projekten versagen sie jedoch. Das problem ist eben nicht wie man die Software programmiert, sondern das Problem ist dass unklar ist welche Art von Software benötigt wird.

Der Ausweg aus dem Dilemma besteht darin die Annahme von geschlossenen Systemen in frage zu zustellen. Ein solches System bedeutet aus Software-Perspektive dass der Sourcecode für einen Computertyp geschrieben wird. Der Algorithmus wird auf der CPU ausgerührt und berechnet dort etwas. Die Berechnung wird im Sourcecode des Programms definiert. Das gegenteil sind offene Systeme. Dort wird nichts berechnet sondern es werden Nachrichten versendet. Das TCP/IP Protokoll im Internet ist ein Besipiel für ein offenes System, aber auch die DIKW pyramide, der Morse code oder die Unicode Tabelle sind offene Systeme.

Offene Systeme zeichnen sich dadurch aus dass sie als Nachrichtenübermittlung konzipiert sind. Es gibt einen Sender und einem Empfänger. Meist erfolgt die Datenübertragung über Schichten um die Komplexität zu senken. Offene Systeme wurden in der KI Geschichte bis zum Jahr 2010 meist ignoriert. Die einzige Ausnahme sind Multiagentensysteme, wo also Softwareagenten untereinander Botschaften senden, vergleichbar mit objektorientierter Programmierung. Es war jedoch unklar wie man diese Technik zur Robotiksteuerung einsetzen kann.

An dieser Stelle ein kleiner Exkurs wie vor dem Jahr 2010 selbstfahrendew Autos als geschlossene Systeme programmiert wurden. Die Idee war, dass es ein computerprogram gibt, welche die Künstliche Intelligenz ist. Dieses computerprogram besteht aus rund 500 MB Sourcecode programmiert in der Sprache C/C++ und enthält alle Module die für die Steruerung des Autos benötigt werden. Also planung, Bilderkennung, Entscheidungen treffen, Fehlerroutinen, Logging, Situationsbewertung usw. Die Intelligenz des Roboters ist in dieser 500 MB großen Datei gebündelt, es gibt keine Außenwelt die weitere Module enthält.

Aus Sicht der Informatik stellt so ein Softwareprojekt die best practice Methode da. Es wird klar definiert was Teil des Roboters ist, und es gibt Tools um die 500 MB große Sourcecode datei zu erstellen und zu verbessern. Leider funktioniert in der Realität so ein Workflow nicht. Die 500 MB Datei geschrieben in C/C++ ist eben nicht im Stande den Roboter zu kontrollieren und zwar generell nicht. Je mehr man versucht den Fehler zu finden desto mehr zusätzlicher Sourcecode muss erstellt werden, der neue Fehler enthält und der niemals im Stande ist die komplexe Realität abzubilden. Der Unterschied zwischen der internen Darstellung im Roboter und der Realität außerhalb des Roboters ist gewaltig.

Innerhalb des bekannten paradigmas geschlsosener Softwaresysteme ist es unmöglich den Fehler zu finden. es ist eben nicht so, dass der 500 MB Sourcecode für das selbstfahrende Auto veraltete algorithmen enthält oder schlecht programiert wäre. Sondern das Problem ist viel grundsätzlicher Natur und betrifft die Annahme hinter solchen Projekten. Das Ziel in der Robotik bis 2010 war es, autonome Roboter zu bauen welche keine menschliche Sprache verstehen. Dieser Bias wurde nirgendwo explizit definiert, sondern ergibt sich automatisch wenn man geschlossene Systeme entwickelt.

Nochmal: Geschlossene Systeme -- KI Forschung bis zum Jahr 2010

 Über Jahrzehnte war die KI Forschung von Misserfolgen geprägt die Resultat waren einer selbstgewählten Perspektive auf Künstliche Intelligenz. Die Zielstellung der Forscher bestand darin, eine Technologie zu entwickeln welche denken kann. Also eine Maschine, oder noch besser einen Computer, der geistige Leistungen ausführen kann. Dieser Bias ist naheliegend weil es zugleich auch die Vorstellung von Robotern ist welche in Romanen von isaac Asimov transportiert wird.

Was die KI Forscher vor dem Jahr 2010 jedoch nicht wussten bzw. verdrängt haben, war die bittere Erkenntnis dass das selbstgewählte Ziel nicht erreichbar ist. KI ist zwar grundsätzlich möglich, aber nicht als geschlossenes technologische Artefakt. Um die Leistungsgrenzen geschlossener Systeme zu veranschaulichen zunächst ein kleiner Exkurs wann dieses Konzept funktioniert.

Die meisten Erfindungen der Menschheit funktionieren als geschlossenes System: dazu zählt die mechanische uhr, die Dampfmaschine, die Schnellpresse von König&BAuer, das Automobil der Mikroprozessor, und Software wie z.b. das Windows Betriebssystem. Ein geschlossenes System ist demnach historisch gesehen die beste Methode wie man eine Technologie entwickelt. Man definiert zuerst einmal was die Maschinen können soll, z.b. soll ein Auto auf einer Straße fahren, und überlegt sich dann welche Bauteile man in die Maschine einbauen muss damit die Aufgabe erfüllt wird.

Der Vorteil von geschlossener Systeme ist, dass damit die Komplexität gesenkt wird, z.b. besitzt ein Elektromotor eine Breite und eine Höhe in Centimetern und was sich innerhalb dieser Abmessungen befindet gehört zur Maschine. Auf dieses physische Artefakt fokussiert man dann die Entwicklung und überlegt welche Materialien oder physikalischen Prinzipien wirken.

Auch bei der Softwareentwicklung wird das Prinip eines geschlossenen Systems verwendet. Eine Software besteht aus einem Source code der wiederum in Dateien unterteilt wird. In diesem Sourcecode ist die Funktionsweise der Software definiert. Alles was nicht im Sourcecode steht wird ignoriert. Es liegt außerhalb des System und ist für die Funktionsweise ohne Bedeutung. Stattdessen geht es darum, besagten Sourcecode zu optimieren, also effizientere Algorithmen zu verwe4nden, weniger Codezeilen zu verbrauchen udn vorhandene Fehler zu beseitigen.

Die unreflektierte Annahme der KI Forschung vor dem Jahr 2010 lautete, dass Robotik und KI nach demselben Prinzip funktioniert. Die Idee war, dass KI eine Art von Algorithmus sei, der innerhalb des Sourcecode definiert wird. Folgerichtig wurde versucht einen Roboter in einer Programmiersprache wie C/C++ zu programmieren. Relativ spät erkannten die Forscher dass genau dieser Ansatz problematisch ist. Damit ein Roboter intelligent in einer Umgebung agieren kann, muss der Roboter mindestens so komplex sein wie diese Umgebung. Eine KI zu programmieren die den kürzesten Weg in einem Labyrinth findet ist überschaubar, aber eine KI welche einen Roboter in der physischen Realität steuert ist eine unüberwindliche Aufgabe. Das benötigte Software programm für so einen Roboter würde sehr viele Codezeilen benötigen und selbst diese könnten nicht die komplexe Realität abbilden.

Eine Zeitlang gab es innerhalb der Robotik-Forschung eine wirkmächtige Antwort auf das Phänomen, genannt Model predictive control. Die Idee war, die Realität als vereinfachte Physiksimulation in Software nachzubauen, in dieser Simulation Prognosen auszuführen und dadurch dann die beste Entsheidung zu treffen. In den 2000er Jahren gab es mehrere Projekte wo mittels Model predictive control, Dronen gesteuert wurden und sogar grasp planning realisiert wurde. Leider ist model predictive control sehr rechenaufwendig. Eine halbwegs präzise physik Simulation benötigt sehr viele CPU Taktzyklen, gleichzeitig braucht aber der KI eine Prognose mehrmals pro Sekunde um auf Veräderungen zu reagieren. Model predictive control funktioniert nur auf dem Papier, aber nicht auf echter Hardware, speziell die Vorhersage längerer Zeiträume bis Minuten in die Zukunft sind technisch  nicht umsetzbar.

Abstrakt gesagt entstehen durch geschlossene Systeme in der KI Forschung zwei grundsätzliche Probleme: a) hohe Komplexität des Source codebode b) hoher Rechenaufwand bei der Ausführung von Algorithmen und der Model predictive Control Vorhersagen.

Anfangs dachten die Forscher, beide Problemen wären lösbar. Das war Wunschdenken. Es ist nicht durchführbar einen Roboter zu programmieren der hundertausende Codezeilen benötigt, und hohe Anforderungen an die CPU gleichzeitig hat. Ein solches Projekt wird in der REalität scheitern.

Betrachten wir geschlossene Systeme etwas genauer. Im wesentlichen Funktionieren diese Systeme nach Naturwissenschaftlichen Prinzipien. Ein Elektromotor verwendet einen Magneten um eine Drehbewegung zu erzeugen, während ein Mikroprozessor über elektrischen Strom kleine Transistoren schaltet. Es gibt also jeweils ein physikalisches Prinzip was in einer Maschine praktisch angewendet wird. Dadurch dreht sich ein Motor, der Computer beginnt zu rechnen oder ein Flugzeug fliegt durch die Luft. Man glaubte anfangs, dass Künstliche Intelligenz auf ähnliche Weise realisiert werden könnte, das es also ein wissenschaftlich-technisches Prinzip gibt was man in einem Softwareprogramm anwenden kann um darüber Roboter zu steuern. Was die Forscher vor dem Jahr 2010 nicht wussten war dass es ein solches Naturprinzip nicht gibt, das es also nicht möglich ist, auf diese Wweise Künstliche Intelligenz zu erzeugen.

Eine mögliche Erklärung warum die KI Forschung bis ca. 2010 sich auf geschlossene Systeme fokussierte ist, dass die Informatik insgesamt nach diesem Muster funktioniert. Definitionsgemäß untersucht Informatik die Funktionsweise von Computern, also speziell die Hardware und die Software. Damit ist zugleich definiert wofür die Informatik nicht zuständig ist. Alles was keine Computerhardware ist und nicht smit Software zu tun hat, liegt außerhalb der Informatik und entzieht sich einer wissenschaftlichen Analyse.

Diese Einschränkung ist für die klassische Informatik kein Problem und sogar erwünscht weil es dabei hilft echte Probleme zu lösen, also z.b. neue CPU zu entwickeln, bessere Programmiersprachen zu erfinden oder Betriebssysteme zu entwickeln. All diese Thmene sind entweder im Bereich Hardware oder im Bereich Software angesiedelt.

Typst als Ersatz für LaTeX

 LaTeX gilt seit den 1980er als defakto Standard unter Unix um wissenschaftliche Dokumente zu formatieren. Bersonders bei sehr umfangreichen Dokumenten die ein einheitliches Layout erhalten sollen, hat LaTeX seine Stärke. Trotz der gewöhnungsbedürftigen Syntax gilt es als leicht zu erlernen und lange Zeit gab es keine wirkliche Alternative zu dieser Software.

Seit einiger Zeit hat sich die unscheinbare Typst Software zu einem ernstzunehmenden Ersatz für LaTeX etabliert. Die Syntax von Typst ist ähnlich wie markdown aufgebaut und beinhaltet Kommandos um float-Abbildungen einzufügen, Tabellen zu erstellen, preformatted Text auszugeben sowie eine automatische Gliederung zu erstellen. Die wesentlichen Verbesserungen von typst gegenüber LaTeX sind:

- es benötigt nur 50 MB auf der Festplatte anstatt 5 GB
- die Syntax ist einfacher und logischer
- das Übersetzen einer Typst datei in eine PDF Datei dauert weniger als 1 Sekunde

Der einzige Grund warum Typst bisher LaTeX noch nicht verdrängt hat ist die Gewohnheit der Nutzer. Die LaTeX Community gilt als konservativ und viele nutzen die Software seit den 1980er Jahren also seit über 40 Jahren. Das macht den Wechsel auf eine andere Plattform aufwendig.

Es gibt jedoch einen simplen Trick wie der Umstieg auf typst gelingt. Und zwar mit der selben Methode wie man auf neue Technologie generell wechselt: man löscht die veraltete Software von der Software und gewinnt so Freiraum sich auf etwas neues einzulassen. In Linux lautet der Befehl:

apt remove texlive*

Der Vorteil von typst ist dass das Projekt sehr viel aufgeräumter wirkt. Es fehlen unzählige veraltete Pakete die historisch bedingt sind, stattdessen wurden die meisten features fest in die Software einprogrammiert. Ähnlich wie bei LateX auch haben Neueinsteiger mit einer gewissen Lernkurve zu kämpfen. Man muss sich erstmalig durch die Dokumentation kämpfen um so eine Minimal Datei zu erstellen, welche die gewünschten Layout einstellungen beinhaltet. Man definiert z.b. die Seitengröße A4, legt den gewünschten Systemfont fest, definiert einige Tabellenparameter wie z.b. liniendicke und definiert die Häufigkeit der Silbentrennung. Sind diese vorarbeiten einmal erledigt, kann man die selbe Rumpfdatei nutzen um damit beliebig viele PDF Dokumente zu erstellen. Ähnlich wie bei LaTeX müssen Autoren nur den Text eingeben und die Software rendert die Darstellung auf dem Bildschirm.

Und das macht typst ausgesprochen gut, im Regelfall sind die Abbildungen sinnvoll platziert und auch der Blocksatz sieht halbwegs professionell aus. Die Qualität ist nicht ganz so optimiert wie bei pdflatex, es gibt also durchaus noch Verbesserungsmöglichkeiten. Aktuell ist derzeit die typst version 0.15 vom Juni 2026.

Geschlossene KI Systeme vor dem Jahr 2010

 Auch vor dem Jahr 2010 wurde bereits an Robotik geforscht. Eine typische Robotik-Software aus dieser Epoche beinhaltete fplgenden Befehl:
  
  if (distance_to_wall < 10) { slowdown(); }

Mit dieser und weiterer Regeln wurde die Onboard Intelligenz eines Roboters fest im Programmcode definiert. Leider waren die Roboter nicht im Imstande sinnvoll zu agieren. Deshalb wurde versucht die Anzahl der Codezeilen immer weiter zu erhöhen um für jede Eventualität ein Untermodul vorzuhalten.

Das Grundproblem wurde vor dem Jahr 2010 nicht erkannt. Es besteht darin, dass die interne Komplexität eines Roboters ansteigt wenn die äußere Komplexität erhöht wird. Industrieroboter die in einer berechenbaren Umgebung eingesetzt werden, können über obige C/C++ Programmlogik noch halbwegs sinnvoll realisiert werden, aber mobile Roboter in einem Labyrinth oder gar selbstfahrende Autos sind mit dieser Technik nicht möglich. Die Umgebung ist viel zu kompleziert, um dafür eine zuverlässige Steuersoftware zu programmieren.

Ab dem Jahr 2010 wurde deshalb eine neue Richtung in der Robotik eingeschlagen die kurz erläutert werden soll. Die Grundidee besteht darin, Intelligenz auszulagern, also weg vom Roboter hin zur Umgebung des Roboters. Damit kann die Steuersoftware des Roboter minimalistisch gestaltet werden. Die Hauptaufgabe des Roboters besteht nur noch darin, Befehle die von einem operator oder von sensoren kommen zu parsen. Der Roboter muss nicht länger Entscheidungen treffen oder gar die Umgebung intern simulieren, wie das bei Model predictive control der Fall ist. Abstrakt gesprochen verwandelt sich ein geschlossenes KI System in ein offenes KI system.

Der Ansatz die interne Logik des Roboters auszulagern war ein längerer Innovationsprozess in der KI Community. Angestoßen wurde er von Rodney Brooks mit seiner subsumption architektur. Im wesentlichen geht es darum, die komplexität eines Roboters zu senken. Die neuartige minimalistische Softwarearchitektur kann nur mittels Fernsteuerung funktionieren, das es also außerhalb des Roboters eine höhere Instanz gibt die stellvertretend für den Roboter Kamerabilder auswertet, Entscheidungen trifft und Pläne durchprobiert.

Technisch gesehen ist der Paradigmenwechsel sehr einfach: anstatt einen denkenden Roboter zu realisieren, funktioniert der Roboter als Parser der Befehle von außen ausführt. Es ist also kein Roboter im engeren Sinne sondern ein ferngesteuertes Auto das auf Kommandos reagiert. Philosophisch gesehen ist so ein Ansatz jedoch weitaus schwieriger zu realisieren, weil er mit der gängigen Vorstellung von Intelligenz bricht. Über Jahrezehnte wurde Intelligenz als die Fähigkeit verstanden eigenständig Probleme zu lösen. Das trifft auf ferngesteuerte Roboter jedoch nicht zu. Ein Ferngesteuertes Auto wo ein Mensch über Tasten oder Sprache Befehle eintippt ist definitionsgemäß nicht intelligent, fällt also nicht in den Bereich der KI Forschung.

Dennoch ist genau jenes Interaktionsmuster zur Leitdisziplin der Robotik ab dem Jahr 2010 aufgestiegen. Eigenltich jedes moderne Robotik Projekt basiert auf Vision language action modellen, instruction following und VQA Benchmarks. Es gibt keine Versuche mehr, Roboter als autonome Systeme zu konstruieren, sondern 100% aller Robotik-Projekte funktioniert über Intelligence offloading mittels natürlicher Sprache. DAs also außerhalb des Roboters eine Software oder ein Mensch Befehle eingibt die vom Roboter lediglich in Handlungen übersetzt werden.

Obwohl der Ansatz zunächst umstritten war hat er einen Entscheidenen Vorteil: er ist minimalistisch. Ein ferngesteuertes System zu realisieren ist weitaus leichter als ein autonomes System zu bauen. Besonders bei komplexen Aufgaben und unstrukturierten Umgebungen kommt dieser Vorteil zum Tragen.  Das einzige Detailproblem bei semi-autonomen Systemen besteht darin die Aufgabenverteilung zwischen Roboter und menschlichen Operator auszubalanzieren, also dafür zu sorgen dass die interaktion über high level kommandos erfolgt und so die workload für den Menschen möglichst gering ist. Hier eine Rangfolge:

- hoher Workload: Fernbedienung mit Tasten ohne Befehle
- mittlerer Workload: es werden Waypoints in einer Karte vorgegeben die der Roboter abfährt
- geringer Workload: es wird ein Text prompt an den Roboter gesendet wie "fahre im Kreis".

KI von 2010 bis 2020

 Bis ungefähr zum Jahr 2010 verlief die KI Entwicklung enttäuschend. Es war nicht gerade ein dezidierter AI Winter, aber insgesamt galt KI als unlösbare Aufgabe und es gab keine Technologie auf die man aufbauen konnte. Das änderte sich ab ca. 2010 schlagartig. In diesem Jahrzehnt gab es eine Vielzahl von Meilensteine, die auch heute noch relevanz haben:

2011 IBM Watson
2012 Alexnet bilderkennung
2016 Alphago
2017 GAN network
2018 BERT Sprachmodell
2019 GPT-2 text generator

Es ist nicht übertrieben die Zeit nach 2010 als den Beginn der modernen state of the Art KI Entwicklung zu beschreiben. Die neuronalen Netze, Datasets und Roboter ab diesem Zeitraum haben die Grundlagen gelegt für heutige leistungsfähigere Systeme. Zwar war in den 2010er KI noch nicht im Mainstream angekommen, aber es begann sich für Experten auf dem Gebiet abzuzeichnen dass KI grundsätzlich realisierbar ist.

Wie man Künstliche Intelligenz erneut erfindet

 Die Erforschung der KI war von 1900 bis 2010 von vielen Rückschlägen und gescheiterten Projekten geprägt. Mit der gewonnenen Erfahrung lässt sich im Nachhinein ermitteln wie man das Gebiet der denkenden Maschinen hätte effizienter und früher entwickeln können. Im Zentrum steht die Beobachtung dass künstliche Intleligenz weniger in einem Algorithmus besteht sondern in der Messung der Leistungsfähigkeit besteht. Z.B. gab es in den 1990er Jahren dezidierte Datasets um Handschriften per OCR zu erkennen und seit den 2020 gibt es weitere Datasets für das Visual question answering Problem.

Ein KI Benchmark besteht üblicherweise aus einer längeren tabelle mit Frage/Antwort paaren welche von KI beantwortet werden müssen und zu einem Punktestand führen. ziel ist es, eine Software oder ein neuronales Netz zu entwickeln was den Punktestand maximiert. Es ist dabei fast egal wie genau ein neuronales Netz intern arbeitet, sondern worum es geht ist dass man den Punktestand objektiv ermittelt. Dadurch wird Künstliche Intelligenz zu einer Wissenschaft, die mit statisischer Verfahren untersucht werden kann.

Selgst ein neuraonles Netz was in einem Test scheitert, also nicht im Stande ist für ein gezeigtes Bild das passende Wort auszugeben, ist wissenschaftlich gesehen ein wertvoller Fakt weil es dabei hilft künftige Neruonale Netze zu entwickeln, die diese Aufgabe zu lösen im Stande sind.

Bis in die 2000er Jahre war weitestgehend unklar was Künstliche Intelligenz ist oder wie man es praktisch realisiert. Es gab zwar viele Bücher und mehrere Robotik-Projekte die sich der Erforschung denkender Maschinen verschrieben haben, doch es fehlt an einer zentralen Idee, einem Algorithmus oder an einer bestimmten Hardware um konkrete Fortschritte zu realisieren.

Dies änderte sich ungefähr ab dem Jahr 2010. Die Arbeitsthese lautet, dass sich die Vielzahl der Bemühungen KI zu realisieren auf einen Punkt fokussieren lassen und zwar die Entwicklung eines Benchmarks zur Ermittlung ob eine Maschine grounded language versteht. Die zentrale Idee zur Realisierung künstlicher Intelligenz ist also eine besondere Form des Turing Tests der die sprachlichen Fähigkeiten eines Computers überprüft.

Dieser Test bzw. Benchmark war vor dem Jahr 2010 nicht verfügbar. Der Test ist kein Algorithmus, kein Source code wie das Linux Betriebssystem und auch kein Computerchip wie z.B. eine Pentium CPU sondern es handelt sich um eine Idee die man schriftlich notieren kann und wozu man einen konkreten Wettbewerb entwickeln kann. Ein einfaches Beispiel ist:

"In einem Labyrinth soll ein Roboter über Sprachliche Kommandos gesteuert werden: is_obstacle, check_battery, move forward, rotate left/right. Programmiere diesen Roboter in einer beliebigen Programmiersprache".

Es handelt sich um eine überschaubare Programmieraufgabe, die Ähnlichkeit hat mit dem Karel the robot Projekt aus den 1980er Jahren. Es handelt sich aus wissenschaftlicher Sicht um einen instruction following benchmark. Das heißt der Roboter reagiert auf eine vorgegebene Anzahl von Kommandos die von einem menschlichen Operator gesendet werden. Die KI ist demnach ein Parser-Modul was die Kommandos auswertet und in Handlungen umsetzt. Wenn der Roboter alle Befehle verarbeiten kann wurde der Benchmark erfolgreich bearbeitet.

Der Clou dabei ist, dass sich der Benchmark hochskalieren lässt. Was in einem 2d Labyrinth funktioniert, funktioniert ebenso bei einem biped roboter, einem humanoiden Roboter, oder einer UAV Drone. In jedem Fall wird eine Liste von Textkommandos vorgegeben die vom Roboter ausgeführt werden. Die Kommandos haben etwas mit der Abfrage der Sensoren zu tun, genauso wie man Planung und der Motorsteuerung. So ein Benchmark ist nach der obigen These, das zentrale Element moderner KI wie sie ab dem Jahr 2010 verfügbar ist.

Der einzige Diskurs innnerhalb der KI Community erfolgt darüber wie im Detail so ein Benchmark ausgestaltet ist, also welche Robotik-Domän verwendet wird, wieviele Befehle der Roboter verstehen soll, ob die Umsetzung über ein C/C++ Programm oder ein neuronales Netz erfolgt usw. Es geht in jedem Fall darum den Benchmark zu erfüllen. Darüber demonstratiert der Roboter Intelligenz.

Diese strikte Definition des Benchmarks ist etwas neuartiges. Hätte man vor dem Jahr 2010 die These formuliert, dass Intelligenz darin besteht textuelle Komamandos auszuführen wie in dem "Karel the robot" Projekt, hätte der Autor des Papers wohl Ablehnung durch seine fachkollegen erfahren. Vor dem Jahr 2010 wurde Künstliche Intelligenz anders defninert und zwar als dessen Gegenteil, also a) Abwesenheit von natürlicher Sprache und b) Abwesenheit von Teleoperation.

Der letzte KI Winter von 2000-2010

 Die Zeitepoche von 2000 bis 2010 eignet sich ausgezeichnet um das scheitern früherer Versuche zu beschreiben, Künstliche Intelligenz zu erforschen. Ähnlich wie die Jahrzehnte davor gab es mehrere KI Projekte sowohl in der Industrie als auch akademischer Natur, die ähnlich wie die Projekte in den 90er und 80er ohne Erfolg verliefen:

- semantic web von Tim Berners Lee
- Cyc von Douglas Lenat
- WordNet für maschinelle Übersetzung
- DARPA Grand Challenge
- kognitive Architektur wie SOAR
- Roboter ASIMO von Honda

Zwar wurden im Rahmen dieser Projekte lauffähige Software entwickelt und Datenbanken erstellt. Es gibt zu Cyc und zum Semantic Web viele praktische Beispiele. Auch das selbstfahrende Auto Stanley von Sebastian Thrun ist tatsächlich autonom gefahren und wurde über Software gesteuert. Nur waren die verwendeten Technologien nicht skalierbar und ohne praktische Bedeutung. Die normale Internettechnologie bestehend aus HTML funktioniert stabil genug ohne dass man eine Erweituerng namens Semantic web benötigte, und die Wordnet Datenbank hatte eine zu geringe Qualität um damit Texte zu übersetzen.

Man kann sagen, dass die Zeitspanne von 2000 bis 2010 eine verlorene Dekade für die KI Forschung war. Es wurde viel ausprobiert, es gab namenhafte Forscher die sich näher mit der Thamatik beschäftigten, aber es gab keine Durchbrüche oder anwendungsbereite Demonstrationen im eigentlichen Sinne.

Auf den ersten Blick klangen die o.g. KI Projekte vielversprechend. Der Ansatz ein selbstfahrendes Auto zu bauen was gegen andere Autos in einem Wettrennen antritt hört sich nach einer spannenden Herausforderung für die Robotik an. Und die Idee common sense knowledge in einer Cyc Datenbank zu bündeln erscheint wie der durchdachte Versuch eine denkende Datenbank zu erschaffen. Dennoch stellte sich heraus, dass die Konzepte fehlerhaft waren. Sie verkörperten Sackgassen, die einmalig beschritten wurden und dann nicht weiter verfolgt wurden.

DIe Geschichte der Künstlichen Intelligenz verkörpert wie keine andere Wissenschaft eine Abfolge von gescheiterten Bemühungen. So ähnlich als wenn wenn mehrere Bergsteiger einen Berg auf sehr unterschiedliche Weise besteigen wollen, aber keinem gelingt auch nur die erste Etappe zu meistern.

Man kann das Scheitern anhand mehrerer Parameter erklären. Entweder ist die benötigte CPU Rechenleistung um einen Algorithmus auszuführen zu groß. Dies ist bei den meisten Pfadplannungsalgorithmen in der Robotik inkl. model predictive control der Fall. In der Theorie könnte man den game tree über einen Algorithmus durchprobieren so wie man Computerschach spielt, doch in der Realität sind physische Computer des Jahres 2010 dafür zu langsam. Also ist der Ansatz nicht praktikabel. Ein weiteres objektives Kennzeichen für ein scheitern ist der hohe manuelle Aufwand der beim Erstellen von Datenbanken wie wordnet oder Cyc anfällt. Es ist schlichtweg zu teuer über Jahre hinweg manuell eine Datenbank zu erstellen die dann keinerlei Nutzen erbringt. Ein weiteres Kennzeichen für gescheiterte KI projekte ist der hohe Programmieraufwand gemessen in lines of code. So wurden für die DARPA Grand Challenge mehrere 100k lines of code erstellt und zwar von jedem teilnehmenden Team einzeln. All diesen Code in C/C++ zu erstellen und zu warten ist ein hoher Aufwand insbesondere wenn man den code nicht erneut verwenden kann sondern er stark auf ein konkretes Auto und ein konkretes Team zugeschnitten wurde.

Die genannten Probleme des hohen Rechenbedarf, des manuellen Aufwandes beim Datenbank-Erstellen und das manuelle Erstellen des Source code waren wohl von 2000 bis 2010 bekannt, aber es war unklar wie man den Aufwand senken kann.

Als kleiner Ausblick auf die Zeitpsanne ab 2010 soll kurz erläutert werden, welche Ansätze nicht verfügbar waren.

- Ferngesteuerte Roboter
- Datasets um neuronale netze zu trainieren

Beide Themen wurden als unwichtig definiert. So wurden ferngesteuerte Robotik nicht als erstrebenswert angesehen, weil laut selbstgewähltem Ziel es darum ging autonome algorithmengesteurte Roboter zu entwickeln aber keine RC cars zu bauen. Auch dem Thema Datasets und preprocessing wurde keine Aufmerksamkeit gewidmet. Es wurde angenommen dass künstliche Intelligen im neuronalen netz verortet sei und die Datenqualität unwichtig wäre mit der das NEtz trainiert wird.

Es finden sich in der Literatur vor 2010 durchaus Beispiele wo remote control roboter diskutiert wurden und wo das erstellen von größeren Datasets thematisiert wurden, aber diese Ansätze galten als Randthemen ohne Relevanz für die weitere Erforschung der Künstlichen Intelligenz. Das änderte sich ab 2010 grundlegend und zwar deshalb weil man mit den bisherigen versuchen in einer Sackgasse steckte und daraufhin die Prioritäten in der Forschung neu justierte.

VLA models -- the upcoming revolution in AI

 Since the year 2023, there are Large language models (LLM) available which are soem sort of advanced chatbots. A LLM can answer question, programs a computer code and can paint an image. Even if these systems are looking powerful there is a much more advanced technology available not released yet which is a VLA model.

VLA stands for vision language action model. It can handle text in combination with robotic action which is needed to control biped robots and drones both. The user interface looks similar to a LLM because there is a text box and the user enters a prompt. The difference is, that the AI software will convert the prompt into action. An example prompt might be "walk in a circle" "bring me the red ball".

Similar to a LLM, a VLA Model works with natural language. The AI won't do anything by its own but its a text based interaction between human and machine. The innovation is, that the output of the AI isn't restricted to a text window on the monitor but the AI has access to servo motors in the reality or can control ingame characters in a videogame. Such kind of AI is available in research prototypes and was described in academic papers but its not available as commercial product for everyone.

Current LLM can simulate the behavior in parts today. Its possible to upload a JPEG image to the internet and the AI can describe the picture with words. Such kind of picture to text annotation seems a bit useless, because its obvious what is shown on the picture. So the feature is used seldom in the reality. Only in combination with actuator control of a robot it makes sense to annotate pictures. Because the robot needs to transform the camera signal into text and then take decisions in response to the information.

AI the big picture

 AI isn't new but was researched since decades by multiple researchers. They have investigated andless amount of theories and algorithms for different subjects. To get a better picture what the AI community has researched in the past, the working thesis is, that there was a transition from closed systems in the past, to open systems in the present time. This working thesis should be explained briefly.

A closed system is the natural understanding in computing. It assumes that a software runs on a computer, and the programmer has to write down the source code including the algorithm. A typical example is a model predictive control algorithm which takes a physics engine to predict future states, or a path planning algorithm like RRT which searches for the shortest path. These approaches are imitating classical computer science paradigm which are working with the same technique.

The idea of a closed AI system is to grasp the reality in mathematical terms and write a computer program which solves a mathematical optimization problem. Such kind of appraoch was common in AI history until the 1990s. The only debate was about which algorithm was prefered, for example neural network or an alpha beta pruning algorithm.

It should be mentioend, that closed systems are not powerful enought to tackle advanced probloems. Especially in the domain of robot control, the paradigm fails every time, because of the state space explosion. There is no algorithm available which can handle millions of joint configurations of a biped robot. That was the reason why some pessimistic AI researchers in the past have assumed, that its not possible to solve np hard problems in AI.

A more powerful paradigm is an open system. Early examples are motion capture systems from the 1980s which are recording the position of markers in real time. Such a system is open because it tries to capture data from the environment, here mocap data. Another example of an early open system are text adventures like Zork I which puts also a great priority on human to machine interaction. Modern open systems developed after the year 2000 are using advanced interfaces based on text and sensory data. These systems are open because the input send to the computer is the most important information. A human operator might speak "Move to north and grasp the blue box". or another human operator might demonstrate a walking pattern in a motion capture suite and the robot has to repeat the trajectory. In open systems, the man to machine interaction stands in the center of attention. Possilble technologies like certain algorithms, a certain neural network or a database is groupoed around this principle. For example, a neural network might used to deterect the mocap markers, while a SQL database is used to store the realtime data, and then a rendering algorithm might fetch the database and paint the human pose on the screen.

From a technical perspective, these algorithms are trivial and most of them were available before the 1990s. The innovation is the context in which they are used which is human to machine interaction. The existing software libraries are not used to build closed systems e.g. a genetic algorithm which tries to improve itself, but they are used to parse textual input or annotate sensor data with textual [tags].

Newspaper with AI advertisement

 

Matching game in python

The font-name needs to be adjusted according to the operating system, otherwise only a question mark is shown in the window.

import pygame
import sys
import time

# Pygame initialisieren
pygame.init()

# Fenstergröße
WIDTH, HEIGHT = 640, 480
screen = pygame.display.set_mode((WIDTH, HEIGHT))
pygame.display.set_caption("Emoji-Text-Matching")

# Farben
WHITE = (255, 255, 255)
BLACK = (0, 0, 0)
BLUE = (0, 0, 255)

# Schriftarten (mit Unicode-Unterstützung)
# font_large = pygame.font.SysFont("Segoe UI Emoji", 120)  # Für Emoji Windows
font_large = pygame.font.SysFont("Noto Color Emoji", 150)  # Für Emoji Linux
font_small = pygame.font.SysFont("Arial", 30)            # Für Text

# Emoji-Text-Paare (20 Einträge)
pairs = [
    ("🐶", "Hund"),
    ("🐱", "Katze"),
    ("🐭", "Maus"),
    ("🐹", "Hamster"),
    ("🐰", "Hase"),
    ("🦊", "Fuchs"),
    ("🐻", "Bär"),
    ("🐼", "Panda"),
    ("🐨", "Koala"),
    ("🐯", "Tiger"),
    ("🦁", "Löwe"),
    ("🐮", "Kuh"),
    ("🐷", "Schwein"),
    ("🐸", "Frosch"),
    ("🐵", "Affe"),
    ("🐒", "Affe2"),
    ("🐺", "Wolf"),
    ("🐗", "Wildschwein"),
    ("🦊", "Fuchs"),
    ("🐝", "Biene"),
    ("🐛", "Raupe"),
    ("🔪", "Messer"),
    ("🔦", "Taschenlampe"),
    
    
]

# Position für Emoji und Text (zentriert)
emoji_x, emoji_y = WIDTH // 2, HEIGHT // 3
text_x, text_y = WIDTH // 2, emoji_y + 150

# Hauptspielschleife
def main():
    clock = pygame.time.Clock()
    running = True
    current_pair_index = 0

    while running:
        for event in pygame.event.get():
            if event.type == pygame.QUIT:
                running = False

        # Hintergrund
        screen.fill(WHITE)

        # Aktuelles Paar anzeigen
        if current_pair_index < len(pairs):
            emoji, text = pairs[current_pair_index]

            # Emoji groß anzeigen
            emoji_surface = font_large.render(emoji, True, BLACK)
            emoji_rect = emoji_surface.get_rect(center=(emoji_x, emoji_y))
            screen.blit(emoji_surface, emoji_rect)

            # Text darunter
            text_surface = font_small.render(text, True, BLUE)
            text_rect = text_surface.get_rect(center=(text_x, text_y))
            screen.blit(text_surface, text_rect)

            # Nächstes Paar nach 1 Sekunde
            time.sleep(1)
            current_pair_index += 1
        else:
            # Alle Paare gezeigt: Beenden oder neu starten
            font_done = pygame.font.SysFont("Arial", 40)
            done_text = font_done.render("Alle Paare gezeigt!", True, BLACK)
            done_rect = done_text.get_rect(center=(WIDTH // 2, HEIGHT // 2))
            screen.blit(done_text, done_rect)

        # Aktualisieren des Displays
        pygame.display.flip()
        clock.tick(30)

    pygame.quit()
    sys.exit()

if __name__ == "__main__":
    main()