Prototypen für ein selbstfahrendes Auto

„Du bist tatsächlich gekommen“, sagte Dr. Lena Hoffmann und winkte ihm auf dem Parkplatz entgegen.

„Eine Einladung zu einer Probefahrt mit einem selbstfahrenden Auto lehnt man als Informatiker nicht ab“, antwortete Daniel Weber. Er blieb vor dem silbernen Wagen stehen und betrachtete die glatte Karosserie. Auf dem Dach saßen mehrere Kameras und flache Sensoren, die sich kaum sichtbar in das Design einfügten.

Lena öffnete die Beifahrertür. „Dann steig ein. Ich sitze heute hinter dem Steuer.“

Daniel hob überrascht die Augenbrauen. „Du fährst selbst?“

„Ich überwache das System. Das ist nicht dasselbe.“ Sie setzte sich auf den Fahrersitz und legte die Hände locker auf das Lenkrad. „Das Auto übernimmt die meisten Aufgaben. Ich kann aber jederzeit eingreifen.“

Daniel nahm neben ihr Platz. Im Innenraum gab es nur wenige Schalter. Ein breites Display erstreckte sich über das Armaturenbrett, doch zunächst blieb es dunkel.

„Wie viele Sensoren benutzt das Fahrzeug?“, fragte Daniel.

„Vierzehn Kameras, sechs Radar-Module und drei Lidar-Einheiten“, erklärte Lena. „Dazu kommen GPS, digitale Karten, Ultraschallsensoren und eine ständige Überwachung des Fahrzeugzustands. Die KI kombiniert alle Daten zu einem Modell der Umgebung.“

„Und wie entscheidet sie, was sie tun soll?“

„Nicht wie ein Mensch, der spontan denkt: Dort ist ein Fahrradfahrer, ich bremse. Das System verarbeitet viele Datenströme gleichzeitig. Es erkennt Objekte, berechnet deren Bewegungen und erstellt mehrere mögliche Zukunftsszenarien. Für jedes Szenario bewertet es Sicherheit, Verkehrsregeln, Komfort und die Wahrscheinlichkeit von Fehlern.“

Daniel schnallte sich an. „Das klingt nach ziemlich viel Verantwortung für ein System, das niemand direkt verstehen kann.“

Lena lächelte. „Genau deshalb habe ich die innere Stimme eingebaut.“

„Die innere Stimme?“

„Eine verständliche Darstellung der wichtigsten Wahrnehmungen und Entscheidungen. Keine geheimen Gedanken, sondern eine technische Übersetzung der Prozesse.“

Sie tippte auf das Display. Über der Windschutzscheibe leuchtete plötzlich eine transparente Anzeige auf. Auf dem Head-up-Display erschienen grüne Linien auf der Straße, kleine Markierungen um parkende Fahrzeuge und gelbe Umrisse um Fußgänger.

Darunter stand:

UMGEBUNG ERKANNT:
Fahrbahn frei.
Parkendes Fahrzeug, Entfernung 18 Meter.
Fußgänger am linken Gehweg, Bewegungsrichtung: parallel zur Fahrbahn.
Geschätzte Geschwindigkeit: 5 Kilometer pro Stunde.

Daniel beugte sich leicht nach vorn. „Das wird direkt auf die Scheibe projiziert?“

„Ja. Die Anzeige bleibt im Sichtfeld, ohne den Fahrer abzulenken. Du kannst die Informationen auch hören.“

Lena drückte eine Taste am Lenkrad. „Fahrzeug, beschreibe deine aktuelle Umgebung.“

Eine ruhige, geschlechtsneutrale Stimme antwortete aus den Lautsprechern:

„Ich erkenne eine zweispurige Zufahrt. Die zulässige Geschwindigkeit beträgt dreißig Kilometer pro Stunde. Ein Lieferwagen nähert sich von rechts. Abstand: vierundzwanzig Meter. Zwei Fußgänger befinden sich auf dem Gehweg. Keine Hindernisse auf der geplanten Fahrspur.“

Daniel sah Lena an. „Du kannst einfach mit dem Auto sprechen?“

„Ja. Das Sprachmodul ist nicht nur für Befehle gedacht. Es erlaubt mir, die Wahrnehmung des Systems abzufragen.“

„Fahrzeug, warum reduzierst du die Geschwindigkeit?“, fragte sie.

„Ein Kind steht neben einem geparkten Fahrzeug. Aufgrund der eingeschränkten Sicht besteht die Möglichkeit, dass es die Fahrbahn betritt. Ich reduziere die Geschwindigkeit auf fünfzehn Kilometer pro Stunde und verschiebe die geplante Fahrlinie nach links.“

Das Auto setzte sich langsam in Bewegung. Auf dem Head-up-Display wanderte eine blaue Linie über die Straße. Der Wagen folgte ihr mit sanften Lenkbewegungen.

Daniel verschränkte die Arme. „Du hast das alles programmiert?“

„Ich habe die Wahrnehmungs- und Erklärungsschicht entwickelt. Das Fahrverhalten selbst basiert auf mehreren neuronalen Netzen und regelbasierten Sicherheitsmodulen. Wichtig ist, dass die KI nicht nur erkennt, sondern ihre Unsicherheit mitteilt.“

„Kann sie das?“

„Frag sie.“

Daniel blickte auf die Straße. Ein Fahrradfahrer fuhr zwischen zwei parkenden Autos hervor.

„Fahrzeug, wie sicher bist du bei der Erkennung des Fahrradfahrers?“

„Erkennungssicherheit: siebenundneunzig Prozent. Bewegungsprognose: achtundsiebzig Prozent. Mögliche Abweichung nach links. Ich halte an.“

Das Auto bremste kontrolliert und blieb stehen. Der Fahrradfahrer überquerte die Einfahrt, ohne die beiden Insassen zu bemerken.

Daniel atmete aus. „Die Erklärung ist tatsächlich hilfreich. Sie sagt nicht einfach nur, was sie tut, sondern auch, wie sicher sie sich ist.“

„Das ist entscheidend“, sagte Lena. „Menschen müssen verstehen, wann sie dem System vertrauen können und wann nicht. Eine KI darf keine falsche Sicherheit erzeugen.“

„Und wenn du nicht eingreifen würdest?“

„Dann würde das Auto nach seinen Sicherheitsregeln handeln. Aber ich bleibe verantwortlich. Deshalb muss ich jederzeit aufmerksam sein.“

Auf dem Display erschien eine neue Meldung:

FAHRRADFAHRER PASSIERT.
Fahrbahn wieder frei.
Geplante Route wird fortgesetzt.

Lena sah Daniel kurz an. „Noch eine Frage?“

„Ja“, sagte er. „Kannst du ihr auch sagen, wohin sie fahren soll?“

„Natürlich.“ Sie lächelte und wandte sich an das Fahrzeug. „Bring uns zu dem Ort, an dem du zum ersten Mal selbstständig eine Entscheidung getroffen hast.“

Für einen Moment schwieg die KI.

Dann antwortete sie: „Zielangabe ist unklar. Meinst du das Testgelände?“

Daniel lachte. „Sie kann also doch nicht alles.“

„Noch nicht“, sagte Lena und gab leicht Gas. „Aber sie lernt, bessere Fragen zu stellen.“

Chatbot interaction for autonomous driving

 

Human (H): Hey AI, are you ready?

AI Chatbot (SDC): All systems are go, Sarah. Departure to 123 Tech Drive is scheduled. Route is optimized for traffic. Please confirm your destination.

H: Tech Drive, yes. Before we pull out, can you give me a status check on what you see right now?

SDC: Acknowledged. I am currently situated on Main Street. My sensor fusion is active: LiDAR and radar are creating a precise 3D map.
I have detected four immediate objects:

    Object 1 (OB-01): Green Sedan, stationary, parked curb-side.

    Object 2 (OB-02): Moving pedestrian, walking on the sidewalk to our right, 1.2 m/s.

    Object 3 (OB-03): Blue SUV, moving toward us, left-hand lane, 35 km/h.

    Object 4 (OB-04): A bicycle is emerging from behind OB-01.

H: Wait, I don’t see a bicycle.

SDC: The cyclist is partially occluded. My radar detected the micro-Doppler signature. Object classification has confirmed a bicycle (confidence: 94%).

H: Okay. So how do you plan to handle this? What are your rules here?

SDC: My planning module has established a probabilistic corridor.
Rule application is as follows:

    Rule: Pedestrian Right-of-Way: Object OB-02 must be monitored; I will yield if their trajectory intersects my lane.

    Rule: Obstacle Avoidance: I must navigate around OB-01 (the parked sedan).

    Rule: Unsafe Overtaking: The emerging bicycle (OB-04) creates an dynamic obstacle. I cannot accelerate into the main lane until OB-04 has cleared my immediate boundary.

H: So you're going to wait.

SDC: Correct. Wait time: 3.5 seconds. My plan is to maintain Status: Stationary until OB-04 merges safely or clears.

H: Understood. New Command: When it’s clear, I want you to immediately do a lane change to the left. Skip the lane we are in.

SDC: Processing. Command conflict.
Re-evaluating planning.
My current traffic rules prohibit a double lane change within 50 meters of an intersection. The crossroad is 25 meters ahead.
A rapid double lane change (Lane 1 -> Lane 2 -> Lane 3) would also violate my Passenger Comfort & Stability parameters (lateral acceleration limit: 2.0 m/s²).

H: Okay, I get it. Compliance and comfort first.

SDC: Cyclist (OB-04) has cleared. Obstacle (OB-01) can now be navigated. I will execute a Single Lane Change Left to enter traffic. Status: Moving.

The technology of Stanley self driving car in 2005

In addition to the previous blog post which describes the Darpa challenge in 2007, the technology for the competition held in 2005 should be described next. All the information are taken from the document [1].

At first it should mentioned, that the winning car Stanley was the most advanced robot car at this time. It was designed by a team of experienced engineers with a university background and has proven in an official competition its superior over alternative concepts. What makes the situation interesting from today's perspective (the year 2026) is, that the entire technology stack can be called outdated. Stanley including all the mentioned hardware and software has only a value for a museum and is very different from the technology used today.

Even for the timeline of computer science, which is known for its rapid development, such kind of fast aging process is a surprise. The usual assumption is, that at least some of the technology is valid in a modified version for later robotics projects. But this was not the case. It seems, that Artificial intelligence since 2005 has drastically reinvented itself. But let us take a closer look into the year 2005.

The physical hardware of the robot was a Volkswagen Touareg R5 TDI, with a diesel engine.[1] page 2. The engine was powered by gas which comes from a gas station. The track was provided in a waypoint text file, in the RDDF format [1] page 3. The vehicle was equipped with multiple sensors like SICK laser, GPS camera, compass [1] 4. The CPU was located in the trunk of the car and was an Intel Pentium M CPU which was used also for laptops. It was running the Linux operating system on six different machines. [1] 5.

The software stack was divided into 30 modules for sensory perception, path planning, logging and steering. The perhaps most advanced module was the self localisation module which was a particle filter, based on a kalman filter [1] page 8. Multiple incoming sensor streams were fusioned with a probabilistic estimation. The vision module was responsible to detect the drivable area in the map [1] page 12. Handcrafted computer vision algorithm were utilized. The steering controlled was realized as a PID control mathematical equation, [1] page 24.

In summary, the technology used in the Stanley self driving car was a classical combination of a diesel vehicle, a computer cluster in the trunk and a large amount of software which implemented algorithms for vision and steering. In other terms, existing and well known software engineering principle were adapted to robotics development. The idea was that a self driving car is some sort of Open source software project with additional mathematical algorithms for road navigation. Typical problems during the project were:

- how to connect the computer in the trunk with the CAN bus of the car
- how to write all the software modules
- how to make the sensory loop fast enough with C/C++ code

It was the same principle used 2 years later during the 2007 darpa urban challenge and it was valid by all of the teams during this time.

Software engineering has a certain name for such projects: rapid prototyping better known as Throwaway-Software. Its a software system that was written in a short amount of time and has a limited lifespan. None of the hardware and software developed for stanley was reused in later projects. In other words, despite that Stanley has won the challenge the technology was obsolete a few weeks after the race was over.

sources:  

[1] Thrun, Sebastian, et al. "Stanley: The robot that won the DARPA Grand Challenge." Journal of field Robotics 23.9 (2006): 661-692.

Darpa urban challenge 2007 -- the last great robot project

 Before the year 2010, artificial intelligence was mostly a niche discipline within computer science without any impact to society. The reason was, that most of the projects were in an early stage and lots of technical obstacle were visible. Because of this limitation its interesting from a science history perspective to take a closer look what the self understanding was of AI in the past.

The goal of the Darpa urban challenge 2097 was to program self driving cars for an urban environment. These normal size cars were able to stop at a junction and do some parking maneuvers. According to the large amount of documentation and some of the talks from the teams its possible to extract some general principle how the cars were realized. Building safe driving cars in the past was recognized as a hardware and software challenge. One problem was to squeeze high performance server racks into the car's trunk. A second and more serious problem was to write all the software.

One team has written software with 100k lines of code, the next one has even created a software with 500k lines of code. The idea in 2007 was to treat self driving car software similar to a large scale software project similar to the linux kernel. Therfor the existing toolchain was used, namely a C/C++ compiler and modern version control systems including bug trackers. The logic of the car was encoded in endless amount of path planning algorithms, C++ classes and dedicated particle filter for self-localization.

It should be mentioned that the outcome of these large scale projects was poor. Despite the fact that a team of experienced programmers have written all the code, the resulting autonomous car was unable to navigate on the street. Simple task like waypoint following was successful demonstrated, but more complex problems like a road block and unexpected situation have overwhelmed the car's AI software.

On the one hand, the shown self driving cars were more powerful than every attempt in the past to build such vehicles. At the same time it was obvious that these cars were not ready for real world traffic. One disappointed detail was that all the written C/C++ software was only working for the original car but can*t be adapted to other cars or another sort of robotics vehicle. In technical terms, the software wasn't scaling up to slightly different problems which is a sign of bad software design.

In 2007 it was unclear how to write better software which fits to the needs of self driving cars. The reason was a certain bias about the project which was: a) the car is designed as an autonomous vehicle b) the decision making process is implemented in software and planning algorithms. So it was a autonomous computational vehicle which is from a modern AI perspective a dead end. In 2007 nobody was able to see the limitation of these constraints but it was imagined, that AI has to be realized this way.

Let us go a step backward and describe the motivation for the darpa urban challenge. The self understanding in 2007 about robotics was, that robotics is a hardware and software problem and located within computer science. The goal was to make sure that the hardware of a self driving car is working, which means that the lidar is rotating fast enough and that the powerful server build into the car gets enough electricity. The second goal was to program the software which means to utilize the C/C++ and implement powerful algorithms in a robot control system. The hope was that the combination of hardware and software would enable a robot car to take its own decision.

Selbstfahrendes Auto gesteuert mit Sprache

Setting: Innenraum eines hochmodernen Prototyps für autonomes Fahren. Die Sitze sind futuristisch, aber bequem. Draußen, auf einer mehrspurigen Stadtstraße, herrscht dichter, stockender Verkehr.

Personen:
* A: Dr. Elias Vogel, der leitende KI-Techniker (ungefähr 40).
* B: Max Huber, ein neugieriger Besucher und Journalist (ungefähr 30).

(Das Auto, Modell "Orion-Prototyp 7", steht seit einigen Minuten still. Der Motor ist lautlos. Auf dem großen Display flimmern Echtzeit-Daten und eine detaillierte Karte.)

B (Max): Tja, Herr Dr. Vogel. Selbst die modernste Technologie kapituliert vor einem Berliner Freitagnachmittag. Ich dachte, Ihr Orion-System hätte eine geheime Abkürzung für solche Fälle.

A (Dr. Vogel): (Lächelt) Wünschenswert, Herr Huber. Aber selbst wir sind an die Gesetze der Physik und der Straßenverkehrsordnung gebunden. Wir stehen hier nicht aufgrund eines Fehlers, sondern weil die Logik des Verkehrs es so will. Sehen Sie auf dem Display: Der Stau löst sich erst in etwa zwanzig Minuten auf. Eine perfekte Gelegenheit, um Ihnen das Herzstück des Systems zu erklären.

B: Ausgezeichnet. Denn genau das beschäftigt mich seit der Abfahrt vom Parkplatz: Dieses Auto fährt nicht nur, es denkt in Sprache, wie Sie sagten. Sie nennen es das "Language-to-Action"-Netz. Wie genau muss ich mir das vorstellen? Übersetzt das Auto alles, was es sieht, in einen internen Monolog?

A: Im Prinzip ja, aber es ist präziser als ein einfacher Monolog. Wir haben das System auf Basis eines Large Language Model (LLM) entwickelt, das fundamental für autonomes Fahren optimiert wurde. Der menschliche Verstand verarbeitet visuelle und sensorische Informationen, indem er sie in Konzepte und Beschreibungen umwandelt: „Die rote Ampel ist an, der Fußgänger läuft auf die Straße, der Wagen links bremst.“ Das ist das Konzept der Kontextualisierung durch Sprache.

Unser System, wir nennen es intern "Codex", tut dasselbe. Die Sensordaten z.B. Lidar, Radar, Kameras, werden nicht direkt in Steuerbefehle umgesetzt. Stattdessen übersetzt Codex die aktuelle Verkehrssituation, die Umgebung und die Vorhersage in eine präzise, strukturierte interne Sprache. Erst aus diesem Sprachmodell leitet das Netzwerk die nächsten Fahrbefehle ab.

B: Das ist faszinierend. Es ist also ein LLM, das auf die Domäne Autofahren zugeschnitten ist. Das führt mich sofort zu meiner ersten Frage: Wie groß ist der Wortschatz, den Codex wirklich versteht? Ein normales großes Sprachmodell kennt Millionen von Wörtern, aber das braucht Ihr Auto doch gar nicht.

A: Das ist der entscheidende Punkt. Wir haben den Wortschatz extrem reduziert und spezialisiert. Codex versteht nicht "Philosophie" oder "Quantenmechanik". Der aktive Vokabularbereich, mit dem es arbeitet, liegt bei etwa 25000 bis 30000 Begriffen.

B: Nur so wenig? Das ist überraschend.

A: Es sind hochspezifische Begriffe, Herr Huber. Sie stammen aus drei primären Domänen:

1.  Fahrzeugdynamik und Manöver: Wörter wie „Spurwechsel vorbereiten“, „sanfte Bremsung“, „Beschleunigung“, „Übersteuern korrigiert“.
2.  Verkehrsumgebung und Objekte: Das sind die Nomen „Fußgänger“, „Fahrradfahrer“, „Lichtsignal“, „Baustelle“, „Straßenschaden Typ A“. Diese sind mit extrem präzisen geometrischen und prädiktiven Attributen verknüpft.
3.  Gesetzgebung und Entscheidungsfindung (High-Level): Hier sprechen wir über die Regeln: „§ 1 StVO konform“, „Priorität rechts vor links“, „Notfall-Halt eingeleitet“.

Jedes Wort ist im Grunde ein Symbol für eine komplexe Datenstruktur, die Ort, Geschwindigkeit, Wahrscheinlichkeit und Sicherheitsmarge beinhaltet. Es ist ein hochkomprimiertes, optimiertes Verkehrs-Idiom.

B: Und wie sieht es mit der Spracherkennung aus? Ist Codex rein auf Englisch trainiert, wie die meisten großen KI-Systeme, oder kann es auch auf Deutsch reagieren? Wir sind ja gerade in Deutschland.

A: Unser Prototyp hier ist von Grund auf multilingual konzipiert, was unsere Trainingsdaten betrifft. Der Kern des Codex-Modells operiert zwar intern in einer Art neutraler, logischer Repräsentationssprache, die wir für die Recheneffizienz entwickelt haben. Aber es wurde auf Datensätzen in Englisch und Deutsch trainiert.

B: Warum diese zwei?

A: Englisch als globaler Standard, und Deutsch wegen der Spezifität unserer Straßenverkehrsordnung und unserer primären Testregion. Das bedeutet, wenn ein Straßen- oder Baustellenschild das Wort "Umleitung" enthält, wird es direkt als das Konzept erkannt, das im deutschen Kontext gilt. Ein rein englisch trainiertes Modell müsste es erst übersetzen und dann die deutsche Regel anwenden, was eine kritische Verzögerung darstellen könnte. Codex verarbeitet die visuelle Information und labelt sie direkt in der richtigen Sprache für die Aktionsentscheidung.

B: Das ist ein sehr durchdachter Ansatz zur Fehlervermeidung. Das bringt mich zur Königsfrage: Mit welchem Datensatz haben Sie dieses spezialisierte LLM trainiert? Es muss ja gigantisch sein, aber gleichzeitig so fokussiert.

A: Es ist gigantisch, ja, aber mit einem Unterschied zu herkömmlichen LLMs. Wir haben uns auf zwei Hauptkomponenten konzentriert:

1.  Visuelle/Sensorische Annotationen (~90% des Datensatzes): Wir verwenden Milliarden von Kilometern an simulierten Fahrten und Millionen von Kilometern an realen Fahrten, die wir selbst erfasst haben. Der Schlüssel ist die sprachliche Annotation. Jede kritische Situation – eine fast-Kollision, ein schwieriger Spurwechsel, eine überraschende Bremsung – wurde nicht nur mit visuellen Bounding Boxen annotiert, sondern auch mit einer detaillierten Ground-Truth-Sprachbeschreibung. Zum Beispiel: "Der rote SUV (ID 47) hat den toten Winkel verlassen und beschleunigt. Reduziere die Geschwindigkeit um 5 km/h, um einen sicheren Abstand wiederherzustellen.“ Das ist die Sprache, die das Netzwerk lernen muss.
2.  Regelwerk und Logik (~10% des Datensatzes): Dies ist ein handkuratierter Datensatz, der alle relevanten Gesetzesparagraphen der StVO, der EU-Vorschriften und komplexer Fahrmanöver in eine formalisierte logische Sprache übersetzt. Das ist die grammatikalische und juristische Grundlage, die dafür sorgt, dass Codex nicht nur fährt, sondern verantwortungsvoll handelt.

B: Also lernt das Auto nicht nur zu fahren, es lernt auch, warum es fährt. Und es lernt, seine eigenen Entscheidungen intern mit Sprache zu begründen.

A: Exakt. Das bietet uns einen unschätzbaren Vorteil: Interpretierbarkeit und Debugging. Wenn das Auto später eine Fehlentscheidung trifft, können wir seinen internen Monolog – die Kette der Sprachbefehle und logischen Schlussfolgerungen – exakt zurückverfolgen. Wir lesen nicht nur „Aktion: Gebremst“, sondern „Grund: Fußgänger (ID 3) hat die Fahrbahn betreten (Wahrscheinlichkeit 99%), Notbremsung (Threshold 8 von 10) eingeleitet.“ Das ist für die Zertifizierung und die Fehlersuche revolutionär.

(Der Verkehr vor ihnen beginnt sich langsam zu bewegen.)

B: Herr Dr. Vogel, das ist wirklich erstaunlich. Ihr Ansatz, die rohen Sensordaten erst in ein hochspezialisiertes Sprachmodell zu übersetzen und daraus die Aktion abzuleiten, scheint mir ein echter Paradigmenwechsel im autonomen Fahren zu sein. Vielen Dank für diese tiefen Einblicke während unserer Pause.

A: Gern geschehen, Herr Huber. Und sehen Sie, die menschliche Logik hatte Recht: Die zwanzig Minuten sind um. Codex hat soeben den Befehl „Fahre mit reduzierter Geschwindigkeit dem Fluss des Verkehrs folgend an“ generiert. Wir sind wieder unterwegs.

(Das Auto gleitet sanft an.)

Isometric traffic junction with map key

 

Carolo cup as the last great adventure in AI

 Since 2008 there is a programming challange available with autonomous model cars. Its a smaller version of the DARPA urban challenge which took place in 2007. So both competitions were started before the year 2010 and they are providing interesting insigth into the self-understanding of robotics projects in this area.

The overall idea behind the Carolo cup was, that its some sort of C/C++ microncontroller programming challenge. The team has to built the assemble the hardware, program the software and make sure that the car gets the maximum score in the competition. Typical problems available are the SLAM problem which is self-localisation on a map, prediction of the future with the model predictive control module and creating a sensor model. All these subtasks are realized with the C/C++ programming language because its the standard for microcontroller programming and a great choice for algorithm implementation.

What makes the Darpa urban challenge in 2007 and the carolo cup since 2008 remarkable is, that all the possible problems are solved by increasing the amount of code lines. The idea is, that a robot car is some sort of Linux kernel which has to growth in size to fit to demanding problems. The consequence is, that creating the AI for the robot means basically to write more source code in C++, bugfix the code and iterate this cycle all the time.

For the Darpa urban challenge, the average team was using 150k lines of code written in C. The source code for Carolo cup participants is available at github and contains also of endless amount of code. There are self written 3d simulators, path planners and sensor perception API available. The amount of effort to create all these C++ code is huge.

From a historic perspective, the software development cycle used for maintaining the Carolo cup source code can be seen as the last classical approach in AI. until 2010 the dominant paradigm in robotics was, to treat the project as a computer science project which consists of hardware and software frameworks. it was based on microcontrollers, path planners, and endless amount of highly efficient computer code. At the same time, the result of this effort was low. Even for simple tasks like moving in a circle, the written C++ code isn't working. Its not possible to reuse the program for real cars and it will take decades until the problems are fixed.

Until 2010 the focos on hard computer science topics like a certain programming challenge and a certain microcontroller was a common bias in artificial intelligence. Possible alternatives like machine learning were rejected as too complicated.

Can the railroad struggle in the future?

A look into the numbers shows, that the US owns a small amount of locomotives, which is 26546. In comparison around 250 million cars are on the road in the United states. Suppose, the future for the railroad looks bad, to which amount can the number of locomotives shrink? Right, there is not much room to the bottom. The minimum amount of locomotives can't become negative, but 0 is the lowest amount of rail guided vehicles.

How could it be, that the railroad has a low priority, while all the money is spend for buying new cars? Has the car a higher productivity, can it be operated without human drivers, is the car using electric energy? It's exactly the opposite. The car is preferred in the US because it produces to much problems. The car industry is some kind of pyramid building game. The idea is to produce extra work which is not needed. Instead of using a single freight train hundred of trucks are used. Each of them needs an operator, the trucks have to be built first and they need a lot of repair. Additionally, all the trucks need more energy than a single locomotive. It's a very luxury game in which all the money and all the manpower is thrown away for nothing.

Inefficiency is a common feature in state controlled economy. If a society prefers the car over the railway it's a sign for missing incentives. That means, the stakeholders in the game have no motivation to reduce the fuel consumption or doing the same task with less man power. This prevents technology advancement. The car has become a symbol for missing progress. Producing more cars means basically that nothing will change and that efficiency has a low priority.

According to the latest statistics, the US car industries has around 8 million employees. In contrast, the railway industry employees only 1/30 of that number. That means, 97% of the money and the manpower goes into the car industry. The funny thing is, that no matter which kind of technology gets invented in the next 30 years, it's not possible to increase this value over 100%.

It's interesting who the car industry has become so powerful, that the value was constant over decades. Nobdoy has asked, if all the invested money into cars make sense, it has become common sense, that new cars are needed.

Let us listen to the car advocates, how they would like to solve future demands in transportation. The idea is, that the car industry is not big enough. The number of 8 millions employees is too low. So there is need to put more money into the sector. The ratio from 1:30 (railway vs. car) can be adjusted into 1:100, which means, that 99% of the overall ressources are use to buy new cars and building new roads. This won't solve the logistics demand, but it will make the car industry stronger.

Suppose, the hidden agenda is to waste all the manpower and all the money into an outdated transportation system. Then the car industry is a here to stay. It is not possible to make a car more efficient in term of fuel consumption or reduced human power. Every single truck needs a human driver and lots of fuel. It's the most luxuary transportation device ever. Only rich countries have enough ressources to use cars for everything.

Increasing the capacity

Suppose, a freight has to be transported from place A to place B. The dominant vehicle today is a truck. This kind of technology is so common, that nobody asks if it make sense. Before a truck can start, a truck driver is needed.

Transporting the freight with a railroad works a bit different. Because on a single locomotive many trailers can be added. No driver is needed, except the single one who is already available. The extra amount of freight won't need axtra human manpower. The funny fact is, that under the condition of autonomous driving nothing with change on this calculation. From a technical perspective it's not possible to build self-driving trucks. Automated cars will need always a human driver in the loop.

That means, especially with a perspective of the next 20 years, the train has a big advantage over trucks. It needs less manpower.

How to solve the traffic problem in India

On the first look, India has a lot of trouble with traffic accidents. The roads are crowed and many accidents take place. Because the problem is so big, it make sense to think about how to overcome the issue. A deeper look into India's traffic situation shows, that all sorts of transportation is used on daily basis: bicycles, private owned cars, trucks and of course the railroad. India has not only crowed cities, but it owns the second largest railroad network in the world. How can it be, that the basic logistics problems remains unsolved?

From complex problems it is known, that it is to simple to argue, that more investment are necessary, because the money is not available. Instead the question has to do with the right priorities. That means, a fixed amount of resources has to distributed to different places. And the question is, what is the perfect investment in logistics.

Before we can answer the issue, a short look into the statistics make sense. Unfortunately, only worldwide numbers are available. The amount of worldwide cars is 1.3 billion, while the amount of locomotives is only 65000. Most of the locomotives are located in U.S., U.K,, Germany and France. The amount of locomotives in India is very little. But why is the total number of cars so big, while the number of locomotives is so little? Sure, a locomotive costs more than a car, but if we measure the vehicles with a pricetag the current investment in private cars is 50x bigger than for locomotives. And exactly this is the problem. The relationship between cars and locomotives is wrong.

What the world in general, and India in detail has to do, is to invest more money into locomotives, and reduce the investment in cars. This will solve the transportation problem. The reason is, that a locomotive has a better cost to profit margin than any other transport vehicle. The railroad nees less energy, can transport more freight and needs less human manpower than cars. Surprisingly, most countries including India are living in the luxury situation to ignore the railroad and invest the available resources into cars.

From an abstract point of view, the logistics problem of a countries follows the same rule like a computer game. The computer has to deal with limited ressources, the amount of money he can spend is restricted and he has to decide, if he likes to buy 1 locomotive or 400 new cars. If the invests the money in the wrong ratio he will loose the game. Loosing means, that a countries is not able to transport all the freight to the destination and too many accidents take place.

In a pdf paper the exact number of locomotives in India are given.[1] According to page 3 the total number is 11461. 50% of them are Diesel engines, and 50% are electric driven. In comparison to the population this number is very small, and according to the amount of cars in India this is also small. That means, the railroad has in India (like in many countries in the world) an extraordinary low priority. In contrast, all the money is put into private owned cars. Does this make sense? No it doesn't and as a result, many problems can be observed in reality.

Now we can imagine what will happen, if some of the locomotives need repair. This situation is common for all technical machines and as result the amount of available locomotives will become much smaller. Are the reamaining locomotives able to transport passangers and freight in a large countries like India? No they don't. That means, the capacity is too low.

India is not the only country who gave the train fleet a low priority. It is bit difficult to get exact numbers but according to Google the total amount of trains in China is only 21000. The problem with the chinese railroad network is known. In the 1980s they have invested nearly nothing into the railroads, and since then the situation doesn't changed that much. Today, the railroad system in China has a low priority, while private owned car have become the top priority. According to the latest statistics, China has around 250 million cars. Perhaps it make sense to compare the priorities according to financial aspects.

- 21000 locomotives, each costs 10 million US$ = 210 billion US$

- 250 million cars, each costs 25000 US$ = 6250 billion US$

- the relationship is 1:30, which means from 100 US$ in total only 3 US$ are spend for the railroad, while the rest is invested into car-based transportation

Solving the crisis

... has to do with adjusting the priorities. There is no need to spend more money into transportation but modify the priorities into the direction of a railroad. The question which has to be answered is, how many US$ from 100 US$ in total should be spend for locomotives and how many for cars. The current situation is, that the railroad gets nothing, and all the money which is 97% goes into cars.

[1] INDIAN RAILWAYS, FACTS & FIGURES 2016-17, http://www.indianrailways.gov.in/railwayboard/uploads/directorate/stat_econ/IRSP_2016-17/Facts_Figure/Fact_Figures%20English%202016-17.pdf

Are self-driving cars make sense without a driver?

A naive understanding of self-driving cars is, that the human operator is no longer in charge and the drive can steer by it's own. Thinking this idea further results into a car which is able to drive without a human driver to the destination. That means, the owner can stay at home and sends to his a car the goal position somewhere in the world and the car will do all the actions by it's own.

This description emphasizes the economic benefit. The idea behind autonomous driving is – according to the description – to utllize existing vehicles more efficient. The idea is to replace human drivers with a software and this will reduce the costs in truck driving and taxi companies. It's important to know, that such kind of economic outlook can't be realized with the technology. Self-driving cars are working very different from it. They are not improving the car but they are motivating humans to become a better driver.

A practical usecase in which a self-driving car can show it's full potential is, if the vehicle is attended by 4 persons at the same time. 2 on the front seat, and 2 on the backside. The task for the humans is to learn driving. And the person who has the most problems is asked to take the position behind the wheel. Basically spoken it's a situation known as a driver school. The self-driving car is a computer game which is more entertaining than a PC based driving school. It allows to check the own skills in a life situation. This is especially important in questions of the allowed speed, the distance to other vehicle and which or the vehicles on the street are allowed to drive first.

What the human in the car are able to learn is if they are familiar with the traffic rules. They can compare their own decision with the car's decisions and open problems can be discussed during the ride. The bottleneck in the game is not the car. Because the car is only a machine who cares about nothing. The only thing what is important are the humans in the car and their ability to take the right decision.

Let us take a look why every year around 1 million people are dying in traffic accidents. It's not because of external reason which are located in the technology, but the main reason for nearly all of the accidents is that the humans are driving the wrong way. They are driving too fast, they are not respect the traffic light and they are not focussed on secure driving. Basically spoken, the human drivers are not educated well in safe driving. And exactly this issue can be solved with self-driving cars.

A self-driving car is a personal driving school which provides feedback to the driving style of the human. The car rewards, if the human is driving with the right speed and do not crashes into other vehicles. It's a serious game with the goal to educate the human in driving secure.

Crash statistics

A common statistics to measure the crash probability is to ask how many miles a certain has driven before an accident happens. The problem is, that exact statistics are not known, because a crash is always an exception. According to a blog entry a normal car has 4 crashes for 1 million miles, while a self-driving car has 9 crashes. https://carsurance.net/blog/self-driving-car-statistics/

But in the internet there is also a different statistics available in which the relationship is the other way around. A valid statistics is known for sportscar. According to the facts, they have a greater crash rate. The reason is, that Sports car are driven more risky. The question is now if the cars available today have to be categorized as sports car or not.

In general it make sense to estimate, that it's not up the car how secure it is, but it depends on the driver. Even a sportscar can be driven very safe, unfortunately this is seldom done. So we have to ask under which conditions, the human is driving carefully and under which condition not. Let us make a simple thought experiment. Suppose the idea is to drive 1 million miles without a single crash. In theory, this is possible, all what the driver has to do is to drive in the normal speed and take care of the traffic lights. The open question is how to educate the humans so that they will drive in this safety first style. If all the human drivers in the world can be convinced to drive safe, the crash rate would become much lower. The interesting question for self-driving cars is, if they are motivating the human driver to drive more aggressive or more carefully.

Benefits of self-driving vehicles

Autonomous driving doesn't mean, that the car can drive by it's own, but it's a security feature which helps to reduce the accident rate. In cars from the past, only the human driver is in charge of adjusting the speed. The result is, that sometimes, the human are overestimate their ability to handling the sky and they drive in the urban area faster than it's allowed. A crash with other vehicles is the result.

Self-driving cars are monitoring the current speed, and compare the value with the allowed speed. This allows to give feedback to the human driver. That means, the car recognizes if the human driver is too fast and can ask him to reduce the speed. This won't prevent any mistake, but it helps to educate the person behind the wheel.

If somebody is an expert driver he won't need a self-driving car. But if the driver is not familiar with driving at all, it make sense to use the additional help of a computer-based tutorial system. It will tell the driver what the correct position in the lane is and what the allowed distance to other vehicles should be.

The disadvantages of self-driving cars is, that the feature is very expensive. To provide the mentioned guidance a lot of cameras and lidar sensors are needed. Additionally, a full blown onboard computer with the ability to interpret the raw data in realtime needs a lot of energy. Only expensive cars are equipped with such capabilities. The question for the engineers is how to reduce the overall costs, so that a driverless feature can be realized in any car on the market.

The surprising fact is, that an autonomous car without a human driver doesn't make much sense. Because the car knows already what the allowed speed in a city is. The bottleneck is the human who doesn't know exactly how fast he is allowed to drive. Instead of driving a self-driving car alone, the better idea is to invite 3 friends to attend the car, because they can be educated as well. A self-driving car is some kind of mobile driver school in which the humans in the car can discuss which kind of behavior is right.

Has the overall society a need for educating humans in driving? Yes there is a demand. Most of the 1 million driver accidents each year are the result of human error. That means, the driver behind the steering wheel are not familiar with the traffic rules. They were driving too fast, the distance to other vehicles was too slow and they doesn't see the red traffic light. If the human drivers are educated much better, the vision zero can be realized.

Car parking explained easily

The amount of existing videos and academic papers about automated car parking are endless. And many demonstrations have shown, that the technical side can be mastered with the right programming effort. What is missing right now, are not “self parking cars”, but a description how to reproduce the magic trick.

Let us take a look into some descriptions of the past. What all the algorithms have in common is, that they are working as waypoint followers. The software takes a list of waypoints and the algorithm is driving the car to each of them. Car parking is equal to waypoint following. Usually the waypoint are fixed. Some advanced algorithms are calcuting the waypoints at the fly, but the normal software doesn't provide this feature.

The interesting question is, where did the software get the list of points in the 2d space, for example p1=(100,100), p2=(150,100) and so on? The answer is, that the points are generated from the programmer. He has put the points as fixed constants into the program. It is important to describe the task of the algorithm itself, which is equal to execute predefined steps, and the task not provided by the algorithm. Or to explain it shorter: every car parking software has a demand for an input stream. Without a list of waypoints, the car parking system isn't able to do anything. That means, the software isn't able to park a car, but what the software can do is to navigate the car through a waypoint list.

This is interesting to know, because otherwise the car parking task would become very complicated. Suppose, we doesn't know, what the algorithm is trying to archive. The assumption is, that the AI is trying to solve the task itself, which is “car parking”. The problem is, that the amount of information and the possible amount of strategies is endless. A single lidar sensor produces a large amount of raw data, and it's possible to measure any distance around the car. But which of the features are important? Does the algorithm need to know the robots angle, and is it more important than the distance to the front? Trying to solve the parking problem inside this hypothetical box is way to complicated. The better idea is to provide a clear strategy, what the algorithm task is and what not. Surprisingly, it's main task is not to park the car. Because on a high level description, car parking has to do with all the literature about the subject which was written in English, and no algorithm in the world is able to parse natural language in that way. Only humans are able to talk about car parking itself which includes all the details.

What computers can do is a low level park assistant. The disadvantage is, that for the computer the task doesn't make any sense. He is trying only to bring a robot to a waypoint and that's all. That means, for the robot it's not really a car parking task, but it has to do with calculating the distance in millimeter and steer the wheel into the desired direction. Even if the machine is print to the console “parking complete”, he doesn't understand a single word. The string was predefined into the subroutine and the computer is not able to explain what he was doing.

The same situation is visible in the famous micromouse challenge. For the naive observer, the software which runs on the microcontroller is able to steer the robot through the maze. But that is only, what the humans are thinking what the robot is doing. In reality, the robot is running a program which includes waypoints, a pathplanning algorithm and an interrupt handler for the start-stop signal. If the programmer press the start button, only the humans are excited because the robot is driving very fast through the maze. For the microcontroller the task has nothing to do with micromouse. The software doesn't even know, what a collision is. All what the machine can do is executing some behaviors which are provided by the human.

The more advanced way to understand a given AI software is by analyzing the human machine interaction during the programming task. What exactly has the programmer done, before the micromouse competition? Has he used an EPROM flash device to put the C code to the robot? Did he utilize a simulator to test the pathplanner in advance? Has he run some testing routine to test the bot under different conditions? This kind of description explains much better what the competition is about. It's not enough to take a look at the microcontroller and the software which runs on the device, but the whole picture has to be analyzed to reproduce the setup.

Unfortunately, the look into the backstage of the competition is not allowed. Most programmers are prefering to not explain how they have programmed the device. This is some kind of social role play which is comparable to what magician have done in the 18 th century. The main idea was, that the enterainer is not allowed to reveal the tricks because then they can be reproduced. And indeed, this is the aim to reverse engineer existing robotics software.

Let us go back to the human machine interaction. Every robot was programmed by a human. He has implemented the algorithm, he has learned theoretical knowledge at the university and he has tested the software before the public run. If we want to understand what a robot is doing, we do not have to talk to the robot. The robot itself can't answer why he is working so great. Even if the software runs without any bug, it won't tell the audience, how the underlying algorithm is working in detail. Even if the sourcecode is available, the amount of information which is provided by the machine itself is limited. The more interesting approach is to analyze the steps before the program was created. It's important to backtrack the entire project until it's beginning. In most cases, this has nothing to do with Artificial Intelligence nor computer science but with the project itself, which includes the amount of invested time, the tools which were used, and the books which are referenced.

Let us go back to the initial example with the car parking robot. In most cases, these projects are evolved from simpler line following challenges. At first, the robot is programmed to follow a black line at the ground. The next step is to follow a list of waypoints which are marked at the ground, and then the waypoints are located in a parking spot and this drives the robot into the lot.

Practical example

In a parking situation the robot is in the left screen and should navigate into the base on the right. The task shouldn't be solved by a human operator but by the AI system autonomously. On the first look the task is very complicated to handle because the robot movements are working under the law of the Box2d physics engine and it's hard to plan a path from start to goal. But is the park situation a control problem in which input information have to be analyzed and converted into a steering command over a time? Sure, it's a rhetorical question because the average parking algorithm doesn't work in such a way.

Instead the more easier to implement technique contains of subbehaviors. In the first step, the robot is driving to a waypoint in front of the base. And in the second step he is driving backward into the base. Or to explain it more colloquial. The robot is cheating. He doesn't negotiate with the environment about the next steering angle but the robot has it's own plan. According to the plan, the robot has to reach two waypoints in a serial order. That means, the car parking problem can be reduced to a waypoint following task.

But why does the robot know, which waypoints he has to follow? The answer is surprising easy. It's not encoded in the program and it's not part of the AI. That means, the robot doesn't even have an AI subsystem. The only routine the robot has is a waypoint following routine. The AI functionality to reach the base is the result of the interaction between the human programmer who provides the two waypoints and the robot's software which executes the behaviors. That means, the car parking problem is only formalized for the human programmer but not for the robot's AI.

Let us describe the paradox situation in detail. Even if the robot is able to navigate to the base, he hasn't solved the car parking problem. The Car parking problem is part of the AI curriculum but there is no need to write an AI Software for the robot with the same purpose. It's interesting how this semantic gap is overcome in reality. One option is, that the programmer tells a story to the audience:

“My robot is able to solve the car parking problem. He has built in sensors and a brain which is able to move the robot into the lot”.

The funny thing is, that this description doesn't fit to the reality. It's the interpretation from the outside to describe what the robot is doing. Indeed, the car is navigating into the lot, but that doesn't mean, that's an AI System. It means only, that that programmer believes for himself, that his robot is intelligent.

In a real line following robot project, the Python sourcecode was given at the end. https://circuitdigest.com/microcontroller-projects/raspberry-pi-line-follower-robot Is the Python code equal to an AI which can think? No, it's not. The code is providing only the line following functionality. The interesting point is, that if the line on the ground is going in a certain direction, the result is, that the robot will move intelligently. That means, if the line follows the maze, then it seems, that the robot is able to solve the maze. But it's the same python sourcecode. And in the code the maze is unknown.