Twelve-tone music on a student party

 

The need for human to robot communication

Layered communication with a DIKW pyramid solves a simple problem: how human can submit commands to a robot. For example the human operator submits "bring me the red box" to the robot and the robot will fetch the box.

The unsolved question is why such a human to robot interaction is needed? In the classical understanding of AI until the 2000s, such kind of pattern was interpreted as a dead end. Artificial intelligence was described as autonomous system which doesn't need to communicate with humans. If a robot doesn't communicates with humans the robot is described as a closed system which is able to run a computer program written in C or runs a neural network algorithm but the robot isn't using human language because there is no need for doing so.

Grounded language realized in AI systems like SHRDLU (1968), Vitra (1987) and M.I.T. Ripley robot (2003) is only needed if human to machine interaction is intended. A possible explanation for this paradigm shift has to do with the weakness of closed AI systems. Existing attempts to build autonomous robots have failed because closed systems are overwhelmed by a complex environment. Even if the robot's software consists of 100k lines of code in the C/C++ language this code won't match to a warehouse robot task because ambiguity and vague goals. Classical computer programming language are working only in a predicted environment like sorting an array or showing pixels on a monitor. Computer programs are the internal language of machines but the code can't store the knowledge for robots task.

Before the advent of human to machine interaction there was another available to build more powerful software for robots based on ontologies. Instead of storing the world knowledge in computer code the goal was to capture knowledge in a Cyc like mental map. Unfortunately, this concept has failed too. Even OWL ontologies are not powerful enough to store domain knowledge. Only teleoperation matches to high complexity. A teleoperated robot arm can do any demanding task including dexterous grasping and novel trajectories never seen before.

During teleoperation the AI problem gets outsourced from the robot itself towards an external source which is the human operator. The teleoperation interface allows a man to machine interaction which translates the external knowledge into robot movements.

Introduction to the Rust Programming Language: Safety, Speed, and Sovereignty

 The landscape of systems programming is undergoing a generational shift. For decades, C and C++ were the undisputed kings of performance, but they carried a heavy burden: memory unsafety. Most Common Vulnerabilities and Exposures (CVEs) in modern software are caused by memory leaks and "use-after-free" errors in legacy C/C++ code. Enter Rust, a language designed to provide the performance of C with the safety guarantees of a managed language.
Origins and Philosophy

Rust was created by Graydon Hoare (who also contributed significantly to the development of Apple’s Swift). Because of this shared lineage, developers often notice a familiar, modern syntax between the two languages. Unlike languages that rely on a Garbage Collector (GC)—a process that periodically scans and removes unused memory—Rust introduces a revolutionary Ownership Model.

In C, developers must manually manage memory using malloc and free, often relying on external tools like Valgrind to hunt down leaks. C++ improved this with smart pointers, but Rust takes it a step further at the compiler level.
The Power of Ownership

The heart of Rust is its ownership system, governed by three strict rules:

    Each value in memory has a variable that’s called its owner.

    There can only be one owner at a time.

    When the owner goes out of scope, the value is automatically dropped (cleared from memory).

This prevents memory leaks and ensures that a "use-after-free" error is physically impossible to compile. This level of safety is why giants like Microsoft are planning to transition significantly to Rust by 2030, and why even the Linux Kernel has begun integrating Rust code (currently sitting at roughly 0.3%).
Ecosystem and Tooling

The developer experience in Rust is centered around Cargo, its highly praised build system and package manager.

    Project Initialization: Use cargo init --bin to start a new project.

    Dependency Management: Simply edit the Cargo.toml file to add a "crate" (Rust's term for a library).

    Execution: Run cargo run to compile and launch your application.

Rust is also being used to build entire operating systems, such as Redox OS. Redox is a Unix-like OS written entirely in Rust, featuring its own display server called Orbital and supporting the NetSurf browser.
Learning Through Graphics and Games

Many developers find that the best way to master Rust's strict compiler is through visual projects. The Piston engine is a long-standing choice for game development, but for those seeking simplicity, Macroquad is an excellent library for 2D/3D graphics.

Developer Note: If you encounter errors like "floating point arithmetic is not allowed in constant functions" while using Macroquad on Linux Mint, ensure your compiler is up to date by running rustup update stable.
References and Further Reading

- From C# to Rust: A 42-Day Challenge https://woodruff.dev/from-c-to-rust-a-42-day-developer-challenge/
- Microsoft: Rust to Replace C/C++ by 2030 https://www.martinsfeld.de/blog/microsoft-rust-ersetzt-c-cpp-2030/
- Game Development in Rust with Macroquad https://mq.agical.se/
- The Rust Programming Language (Official Book) https://doc.rust-lang.org/book/
    
  

Grounded language in robotics

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

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

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

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

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

Annotating a warehouse robot

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

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

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

A closer look into the Rust programming language

 Rust is a very new programming language available since 2015. The main problem with Rust is, that its harder to learn than C/C++. Let us describe the situation in detail.

Before the invention of the Rust language, the programming world was divided into beginners languages like Python and Java on the one hand and expert languages like C++, Haskel and Assembly.

A programming language like Python is called a beginner language because its interpreted but not compiled, because there are no datatypes and because the code is easy to read. The disadvantege of Python is well known but for creating prototypes Python is perhaps the best programming language ever invented.

Creating production ready code was mostly done in C++ which is a very efficient language but is hard to write. Rust can be seen as twice as complicated as C++ because it introduces many new concepts and is very different from existing languages like go, java or C#.

The main reason why Rust has become popular is because its newer than the C++ standard. It doesn't provide endless amount of outdated principles but was designed from scratch for productive tasks. So its soem sort of rewrite of the D Language which was also started as a C++ replacement.

In contrast to former C++ replacements like nim, golang and objective c, the Rust language has become more popular. It seems that the demanding learning curve results into efficient software projects which can compete and outperform C++.

The main reason why Rust hasn't replaced C++ yet is because its very new and different, Programmers have to unlearn former knowledge and start from scratch which is a huge obstacle. 

The long history of artificial intelligence

Historians are introducing Artificial intelligence with the fact that the subject was researched for over 50 years without much effort. This makes AI research to the most unsuccesful sciences. In contrast to other disciplines like mathematics, physics or psychology its completely unclear what AI is about and how to make computer smart. A closer look into the facts will show that the situation is more dramatic, because AI was researched since 70 years because the Dartmouth conference on AI was held in 1956.

Despite lots of robotics project and a huge amount of published papers there is little or no progress available. Before the advent of chatgpt in Nov 2022, the subject was nearly unknown in public awareness. What was available instead was classical computer science in the form of PCs, the internet and modern gadgets like the iphone. In contrast, the goal of building intelligent machinery was perceived as impossible to realize.

One possible explanation why AI research from the last 70 years is perceived as a dead end is because there are no logic bricks available which are building on each other. Of course many dedicated robotics software frameworks and AI programming languages were created but none of them are perceived as important. There is no such thing available like the x86 hardware standard for AI or the Unix specification which allows other programmers to build on top of the standard new application. Instead the common AI project in the past was started by a few researchers who have written some code and discussed the results in a conference paper and other researchers have read the paper and decided that the outcome makes no sense so they started their own project from scratch.

There is one exception from this rule available which is responsible to the emergence of Artificial intelligence since the year 2010. So called deep learning datasets have become the standard in AI research. A dataset is a table with annotated information, like motion capture data, picture database and more recently multimodal dataset with question answer pairs. These datasets have evolved from simple table with 2000 entries up to larger table created by different researchers in a multi year effort. A certain dataset formulates a puzzle which has to be solved by a neural network. The network has the obligation to interpolate missing data and reproduce existing question answer pairs. For example the neural network is feed with a walking sequence of a human and the neural network recognizes that the left foot is in front of the right foot.

In contrast to the mentioned endless amount of AI libraries and AI algorithm, the dataset principle is surprisingly stable. Dataset were used in the year 2000, in 2010, in 2020 and are also relevant for the future. The assumption is, that datasets are a fundamental building blocks in creating intelligent machines.

In modern understanding an AI dataset acts as a benchmark to score a machine learning algorithm. The ability to score an algorithm transforms AI research from alchemy into a scientific disciplines. Instead of arguing from a philosophical standpoint if machines can think, the question is what the numerical score in a benchmark is. Such a fact can be compared against each other and allows to determine a direction for future research. 

Rückblick auf das Vitra Projekt SFB 314

Deutschland gilt in der KI Szene als rückständig, innovationsfeindlich und dominiert von philosophischen Debatten anstatt technischer Projekte. Es gibt jedoch davon durchaus Ausnahmen wie das Vitra Projekt was im Jahr 1987 von Wolfgang Wahlster durchgeführt wurde. Vitra steht für "visual translator" und war ein Großforschungsprojekt im Umfang von 50 Mio DM was erstmalig Bilderkennung und Sprache kombinierte. Technisch wurde es auf VAX Minicomputern und Symbolics Workstations realisiert.

Aus heutiger Sicht würde man Vitra als "Vision language model (VLM)" definieren, nur das es damals nicht mit neuronalen Netzen arbeitete, sondern mit händisch erstelltem Lisp Sourcecode. Ähnlich wie die Zuse Z3 aus dem Jahr 1941 war das Vitra Projekt konkurrenzfähig oder sogar leicht überlegen der US amerikanischen Spitzenforschung.

Die Hauptkritikpunkt an Vitra war, dass es zu teuer war. Man verwendete Großrechner um in Echtzeit Videobilder zu analysieren. Auch die Lisp Programmiersprache war ein Kostenfaktor, weil man Spezialisten benötigte, die Lisp programmieren können. Dieses Konzept, bestehend aus VAX Rechnern, Lisp und Livekameras, kann man nicht hochskalieren zu noch mehr Komplexität, sondern Vitra war eine Art von Dinosaurier, der eine Sackgasse darstellte.

Aus heutiger Sicht würde man viel kleinere Forschungsprojekte durchführen. Man würde nicht Lisp sondern Python wählen und man würde keine Videobilder von Kameras parsen sondern lediglich Screenshots von Videospielen analysieren. Damit könnte der Aufwand zur Realisierung auf ein Bruchteil gesenkt werden.