Realizing Artificial Intelligence the easy way

Sometimes it was assumed, that Artificial Inteligence is something which is hard to realize or it's even impossible to build robots. In reality the concept of an AI controller is remarkable easy. It contains of a forward model and a solver which brings the model into the goal state. This concept can be used for all sorts cf control problems for example robot movement or computer games as well.

A forward model is the same as a physics engine. It predicts future states of a system. In contrast a solver is a software program which takes a model and is testing out random actions with the monte carlo tree search. The resulting action sequence is called a path or a trajectory in the state space. If the sequence is execute on the robot it looks, that the robot is doing something useful.

For programming a model predictive control system in reality many detail problems have to be solved. The first one is, that for most robotics problems the forward model is not known. It is unclear what will happen, if the robot moves a joint by a certain degree. And without a forward model the solver can't find the optimal action sequence. A second problem is that complicated domains have a large state space. Before a solver can find the desired trajectory a hierarchical decomposition is needed to reduce the computational effort. Both problems combined prevents, that the robot control system will work.

A competition which goes into the direction to tackle the difficulties is the The GVG-AI Competition, http://www.gvgai.net/ It's a relative new programming challenge in which the forward model and the solver has to be created both.

Programming

From a computer science perspective the perspective of a MCTS solver plus a forward model is not very complicated to grasp. It's a classical planning pipeline in which what-if cases are determined. What makes the situation complicated are certain domains. That means, a forward model for a robot is hard to realize because the robot has a lot of possible movements. And creating the MCTS solver for a given forward model is also a complicated task, because there is a need to search in the game tree very fast.

An easy to explain example is the sokoban game. Creating the forward model for such a game isn't very complicated. The player can move in four directions and sometimes he will push the box. Testing out many thousands of different sequences is possible and as a result, the box can be moved in any direction. That means, the human operator can provide the target location and the solver will find the needed actions to push the box into the goal state.

The same solving technique can be used to play more complicated games autonomously. For example for controlling a robotarm. Describing the forward model and realizing the solver will take more space and the amount of real projects is small. The most complicated project which is documented was about the Mini cheetah robot at the M.I.T. [1] It is working with model predictive control to produce the trajectories of the legs.

[1] Kim, Donghyun, et al. "Highly Dynamic Quadruped Locomotion via Whole-Body Impulse Control and Model Predictive Control." arXiv preprint arXiv:1909.06586 (2019).

Identify the weakest point in current robotics

Robotics competitions are trying to solve the control problem. It is defined in the rules, that the robot has to push the ball into the goal, and the participants are trying to program the algorithms for doing so. The problem is, that the resulting robot control systems are useless for practical applications because in the factory there is no soccer challenge.

That means, the teams in robotics competitions are investing their time without getting something back in return. The competition is useless and the shown prototypes are not a sign of excellence. The problem is located in the competition itself. There is a need for a more elaborated robotics challenge which produces software with a practical application. A competition which goes into that direction is the CATS benchmark. It's a time series prediction challenge. This challenge is sometimes called system identification and it's a prestep before a robot controller can be programmed.

Instead of starting yet-another-robot challenge which will produce useless software, the better idea is to start a system identification challenge. That means, the quest is not bring the robot into the goal defined by the rules, but the task is to recognize the rules on the fly. Let us provide some detail.

Each game is producing a time series as default. That means, there are raw data which are the result of the system. The raw data generated by a robot soccer team are different from the raw data of a micromouse robot. The shared similarity is, that in the data is a certain form of sense. The sense making device is called a “forward model”, which can be summarized as a rule book how to play the game. For example, if a ball in the soccer challenge hits a certain point in the map, than the team gets a +1 reward, because it's the rule described in the rule book. Or if the robotmouse in the micromouse challenge hits the wall, than the reward will become -1.

The challenge is to determine these rules for any sort of game. A software which is able to do so can be utilized for any sort of game. It's able to play soccer, micromouse of a pick&place challenge. The amount of literature about the topic of automated generatiion of a physics engine and producing other forward models is limited. Also there are no other challenges apart from the CATS benchmark which are going int that direction. The first step towards future robotics is to give a higher priority for this kind of problems. In contrast, there is need to lower the priority for classical robot challenges. They are working with the assumption that the game engine was written in advance. This assumption is unrealistic. The task of system identification is the bottleneck in robotics applications. If the game engine is available it's trivial to create the robot controller which is able to win the game.

The sad news is, that no framework is available to create a forward model for any sort of game. The only tool which is available are normal programming languages like Python. With Python it's possible to build any kind of game engine. It's unclear how to do so in detail. Perhaps neural networks are the answer, but it's also possible that neural networks are a dead end. So we have to answer the question in general: what is a forward model?

In the python language, a forward model contains of three functions: init(), action(), update(timestep). The most interesting function is the update method. It will bring the model into the next state. Running the update() function in a for loop is equal to move forward in time. Let me give a simple example.

The problem is a micromouse challenge. In the init() function the map of the maze and the two wheeled robot is provided. In the action() method the forward speed of the robot is set to 50 pixel. And then the update() function is called 3x times. As the result, the new position of the robot is 3x50=150 away from the starting position. This is the basic functionality of a forward model. It will provide the future system state.

The forward model can be utilized by a solver for answering more complicated problems in the reverse mode. In most cases, the operator tries to bring the robot mouse into a goal state and avoid the obstacle. The forward model allows to check if the goal state was reached. Most current robotics challenges are providing the forward model as part of the instructions. Either it was programmed as the game environment or it was described in natural language in the rule book. In both cases, the creation of the rules is not the task for the participants, but it's located in the challenge itself. It make sense to increase the abstraction level and let the participants decide which kind of robotics challenge they like to participate. That means, there are no rules given, but each team has it's own forward model.

It is possible to mix all the possible robotics competitions into one challenge. The question is not if the robot plays well in game A or in game B but the challenge is to program the forward model for a large number of games. This leads us to the problem who a forward model determines the future state? In the example with the micromouse model it was given in the update() function. To determine the follow up state a simple mathematical calculation was done:

futurexpos=timestep*action=3x50=150

That means, in the model it was given that the robot will drive 50 pixels forward in one timestep. Additionally the game engine was asked to execute three ticks at once. Therefor the resulting xposition of the robot can be determined. This is very similar to the three body problem which has a iterative solution. Sure it would be nice, if the physics engine is able to provide the result for any given point in time without calculating all the steps in between first. But for the beginning, this is only a detail problem and can be ignored. Simple games can be solved by executing the forward model step by step.

[1] Dockhorn, Alexander, Tim Tippelt, and Rudolf Kruse. "Model Decomposition for Forward Model Approximation." 2018 IEEE Symposium Series on Computational Intelligence (SSCI). IEEE, 2018.

Linux vs. FreeBSD

Today, only the Linux operating system is relevant for computing. It's by far the most advanced workstation, server and embedded platform and provides the best performance, the highest security standards and is supported by all companies. The only disadvantage of Linux is, that from a historical point of view it is not able to tell an interesting story. Linux was invented in the mid 1990s that was a time in which computing has entered the mainstream and all the adventures were done. That means, Linux never explored something which is new, but it's only an efficient Unix clone in combination with the X window system.

If somebody is interested in the history of UNIX in the 1980s, Linux is a bad starting point because in that area Linux was not invented yet. The more elaborated starting point is to focus on the BSD operating system, which is sometimes called the true Unix system. Today, the BSD Unix operating system is nearly obsolete. On most real hardware it's no longer used and was replaced by modern Linux systems. But in the 1980s the situation was the other way around. Getting familiar with the Unix culture is equal to understand the BSD system.

In the 1980s, computing was looking different from today's approach. The Internet was something which was brandnew, and getting access to a 32bit workstation was a valuable resource. In the 1980s, programming software and creating Postscript documents was done only by the academic community. It's fascinating to take a look back and explore what the pioneers have done. All the technical improvements which results into the modern Internet was done in the 1980s. It was the time in which fast CPUs were designed the first time, huge harddrive have become cheap, and 24/7 server operating systems went online for the first time. The 1980s in combination with the UNIX was also the first time, that the end user was in the position to typeset academic documents with the TeX and the troff package. And everything was new and exciting.

To understand the relationship between Linux and the BSD operating system in detail, a short look into a paper from the mid 1980s make sense in which the BSD Unix system was introduced. In the 1980s many academic paper were written about the subject because the researchers and enthusiasts were interested in the new features of a time sharing operating system. They were proud to describe features like the TCP/IP protocol, the terminal for realtime access to the minicomputer and in some cases, the X Window system was described briefly. For the 1980s the subject was remarkable advanced. And it was right to cover the topic of UNIX in academic papers.

The interesting point is, that today in the 2010s nobody would write such papers, and especially not about the Linux operating system. The reason is, that Linux is nothing which is new. It's interesting to see that the latest Ubuntu version provides also the X window system, a terminal and is provided with server capabilities but from an academic standpoint this technology is obsolete. It was innovative 30 years ago. The Linux operating system has produced some kind of paradox. On the one hand it's the most advanced piece of software which was ever invented. It runs on nearly all sort of hardware and provides a lot of powerful tools. Programs like the Lyx publishing tool, the Python programming language, and of course the Gnome environment are very powerful elements of Linux. The only problem is, that the enduser isn't surprised anymore but he assumes that such features are normal. That means, nobody gets excited if an operating system is able to run 10 applications in parallel without an error message, and nobody is impressed if the Python interpreter runs a GUI without any problems.

Without any doubt the BSD OS is obsolete. The original BSD distribution isn't available anymore and the later developed FreeBSD package can't compete a modern Linux distribution. The problem is, that if BSD Unix is obsolete the danger is high that Linux can be labeled with the same term. Sure, Linux can be used to boot a current PC into the graphical mode and new programs for the Linux OS are developed each month. The problem is, that there is nothing which is new. A powerful multiuser operating system can be invented only once, and then all the new versions will look like a clone. The only thing what can be explored today is the history of UNIX. That means, in which year the first version of the X Window system was invented, and what the Unix wars in the 1980s were about. The look back into the past is unexplored land. Some stories were published already but there are many unexplored areas available.

Some details about Model predictive control

Jacques Richalet has published in 1978 the first paper about model predictive control. In that time only trivial examples were solved with the technique. Controlling biped robots with the same approach is discussed in the literature since around 2010. It's a very powerful control technique and it make sense to explain what the idea is.

The main problem for a robot control system is to determine the next action. A robot consists of joints and the question is in which direction the joints has to be moved so that the robot is doing something useful. Answering this question with software is possible but very complicated. The reason is the absence of a model. A model is a sandbox in which an action make sense. The best example for a model is a chess engine. A chess engine accepts a move and it puts the system into the follow up state. So what is a chess engine? Somebody may argue, that it's equal to an Artificial Intelligence, but this answer is not accurate enough. A chess game can be played by two human users without any AI. The game engine provides only the sandbox in which the users can take actions. So the more elaborated answer is, that a chess engine is a model of the game of chess.

Another kind of technology goes into the similar direction which is called a physics engine. Some physics engines like bullet are available. They are the basis of modern games. The typical interaction with a physics engine api is, that the programmer is doing the following steps:

1. initialize the world with some objects: box1, box2, joint1, joint2

2. send a command to the physics engine, e.g. “joint1=-1”

3. update of the engine, e.g. “engine.step(10 milliseconds)

4. print out the values of the objects to the graphics display

A physics engine is a model. It accepts commands from the outside and is able to predict future states. The prediction gets initiated with the update-method. The programmer can decide to move the physics engine for 10 milliseconds forward in time. The principle of a physics engine can be transferred into the domain of model predictive control. The result is a new kind of problem: who should the model look like to solve a certain problem?

For example, there is a robotarm which contains of 3 joints and has a gripper. The task to is program for this robot a model which accepts some actions. The model needs to be fast and accurate at the same time. If such a model is available, it's possible to search in the game tree for a desired state. It's the same principle used for realizing chess AI and TicTacToe AI players.

The advantage of model predictive control over direct control is, the ability to figure out action sequences. Complex systems need more than a single action, but around 3-10 are needed to reach the goal state.

Building advanced robotics with model predictive control

In the late 1980s, Rodney Brooks has argued, that reactive architectures are able to control simple robots. So called scripted AI and behavior trees are used for direct control of a robot. The idea is, that the programmer defines motion primitives like moveto, grasp, ungrasp and then more complex behaviors can be built. But there is a problem with this approach because in reality it's hard to scale up the idea and most of these reactive controlled robots are only able to follow a line.

The problem is, that it's unclear which motion primitives are needed in the concrete example to solve a task. The good news is, that there is more powerful technique available which is called model predictive control (MPC). The idea is to divide the programming task into two steps: system identification and controller design. In the first step it is defined what the concrete domain is. The step of model building is ignored in direct control but for MPC it's important.

So the question is: what is a model? A model is a short term for “forward model”, and this is equal to a game engine. For example, in the TicTacToe game, the model is the part of the software which formalizes the game rules. It's equal to an API, the programmer can send the next action to the game engine and this brings the engine into a follow up state. A forward model is able to predict future states. That means, it's possible to send a sequence of actions to the engine.

In case of model predictive control, the games which are played have to do with control games in physical environments. A typical example is a two wheeled robot which can move the left wheel or the right wheel. If the robot is doing so, he changes the direction. The amount of change is encoded in the forward model of the robot.

The reason why model predictive control is misinterpreted sometimes is because such a forward model is complicated to build and it's hard to imagine why it's useful. Suppose, an elaborated model was created for the two wheel robot, what's next? Right the model itself can't control the robot, this task has to be done by the controller which is located in the second step of the MPC-framework. The motivation is high to ignore the forward model and start with the AI controller. This principle is called direct control, or reactive control, because no model is available.

The disadvantage is, that without a model it's not possible to plan over longer horizons. And this results into low complexity systems. The better idea is to focus on model building first. Let me give an example. Suppose, there is a robotarm who should do a task. Instead of figure out who to program the robot the starting point is to analyze the domain. That means, the robot arm has to be converted into a game engine. The question is not, what is the next action but it's a “what-if” problem. What happens, if the robot moves the joint0 for 10 seconds to the left? What happens if the gripper is open?

Solving computer games is usually done with Artificial Intelligence. The idea is, that there is a game and then an advanced AI Solver is used to play the game autonomously. The bottleneck is not to program the solver for the game, but the challenge is to formalize the game. The rules of some easy games like pong are known. For example, if the ball collides with the border he will move it's direction. For robotics control problems, the game rules are not known. That means, each robot is playing a game, but the inner working of this game are not available.

What human operators can do is not only to control a robot, but they know also what will happen in a certain situation. In the literature this is sometimes called “qualitative reasoning”. It means, that for the human operator it's obvious that the after the gripper was opened, the object will fall down.

From remote control to fully autonomous robots

The first step in realizing a robotics system is a remote controlled system. That means, the human operator has to press the joystick and this will move the robotarm. Such a control technique is remarkable robust, because the human operator is using his own skills to produce the next control actions. Most cranes on real construction sites are working with this principle.

The more challenging problem is to remove the human operator from the loop and control the robot only with software. Such a system is needed for reducing the costs. Realizing such goal is possible with so called model predictive control (MPC). MPC means, that the human operator only provides higher goals and the motion controller is figuring out the detailed actions. A typical example for a robot crane would be, that the human operator places doesn't operates the crane directly but he drags and drops the container to the target location. It's up to the robot to figure out how to do so.

From a computational perspective a high level goal is equal to a constraint. What the human operator provides is a goal within the game tree. The solver has to explore the game tree for finding an action sequence which brings the system into the desired state. Browsing through the game tree is only possible if the game rules are known. This step is known as system identification. System identification describes the possible action of a robot and the result. It's the same like building a physics engine or a forward model.

The reason why MPC is a powerful technique for controlling a robot system is because it divides the overall task into two subproblems. First, system identification and second, fulfill the constraints by searching for an action sequence. The part with finding out the concrete actions can be ignored, because the problem can be solved easily with brute force search, similar how a chess engine is working. The gametree is explored, and if the computer hardware is fast enough, it will produce the next action in realtime. The more interesting problem is creating the forward model. The interesting fact is, that for nearly all robotics problem, no forward model is available. The only thin which goes into that direction are physics engines used in computer games, but there is a difference between a physics engine and an MPC controller.

What robotics programmer have to implement is a dedicated forward model which works much faster than a classical physics engine. It's equal to program a simulator which can answer “what-if” questions. For example, “What will happen if the crane is moving to the left?” On the first look, it's obvious what will happen, but the problem is, that the information isn't available for the computer. Creating a software module which can answer “what-if” question very fast is the fundamental step in realizing model predictive control.

System identification and automatic game playing

Most examples of Narrow Artificial Intelligence is about game playing. The domain is given in advance, and the AI software has to bring the model into the goal state. Typical examples are the TicTacToe game, the micromouse challenge or a line following robot. All these problems have in common, that the domain was defined precisely and the AI has to solve the game.

In case of the micromouse challenge the problem is provided by the maze, the robot hardware and the rule that the robot has to travel through the maze. What the engineers are doing is to solve this challenge. They are using pathplanner, motion planner and vision algorithm which will allow the robot to drive autonomously through the maze.

The surprising fact is, that all of these robots are useless for practical applications. It's not possible to utilize the micromouse robot for a different kind of task. This is a tragedy in case of very complex robots. The paradox situation is, that on the one hand the robotic system is highly developed but from a practical point of view, the robot can do nothing.

To overcome this bottleneck there is need to introduce a prestep before the robotic software is programmed. This prestep is called system identification. System identification tries to describe the domain. That means, the rules of the micromouse challenge are not given in advance, but the engineers has to describe first what the task for the robot is.

Or let me give a more easier example. A normal AI project is about programming a software which can solve TicTacToe. The more elaborated AI project is, if it's unclear which kind of game should be played by the software. The rules are not provided in advance. This is the case for real robotic applications. Especially if the aim is to replace human work with robots. The problem is, that it's unclear what exactly a human worker is doing. He is trying to solve a problem, but the domain is not described in advance.

System identification is equal to a forward model which is equal to a simulation and this is equal to a physics engine. A physics engine is not the AI itself, but it's the environment in which an AI Controller gets activated. A physics engine is sometimes introduced in the Artificial Intelligence community as a reward structure, or inverse reinforcement learning. The idea is, that before a game can be solved there is need to figure out what the game is about. This prestep before a solver can bring the system into a goal step is more complicated to solve than normal AI tasks. In most AI domains there is no need for this step because it's trivial to do the model checking. A TicTacToe simulator provides the accurate simulation for the real tic tac toe game, all the rules are known in advance.

This kind of situation is missing for robotics application. The typical robot project works with a missing domain model. That means, it's unclear if the action of the robot produced a positive or a negative reward.

Model predictive control

The rules of TicTacToe are well known: two players have to place pieces on the board and the problem is which is the best move. But is this really the problem? No it's not because the optimal move can be determined by a game-tree-search. The more interesting question is what is the TicTacToe game about. If a player puts a piece on the board, he brings the game into a new state. The action has an effect and the amout of possible actions for the next player is smaller. The game engine formalizes the rules. It determines under which condition somebody has won and what allowed actions are.

The interesting problem in TicTacToe is not solving the game itself, but it's how to transfer the game rules into the game engine. If this topic is unanswered it's not possible to automate the game. In case of the TicTacToe game the game engine is trivial to program. In most cases it can be programmed with less than 100 lines of code. In other domains like micromouse, or robotic grasping domains the game rules are more complicated. In most projects, the AI programmer ignore the task for formalizing the game rules. They assume that programming an AI is equal to solve a domain.

An often cited example for model predictive control is steering of a vehicle. The project contains of two parts: system identification and solving the model. In the system identification task, it is defined what will happen if the car steers to the left. This allows to predict future game states. It's equal to invent a game. The game rules are about a car which is able to steer to the left and to the right. Solving this game is done in the second task called “solver”. Here is the question which action is needed to next to win the game. Solving a game makes only sense, if the game rules are available. That means, a random action can be send to the forward simulation and the model provides the What-if-feedback back to the controller.

It's important to know, that a forward model can be controlled by a human operator. A forward model means only that the game rules are formalized in a simulation and it's possible to play with this simulation. Playing means, that the human operator can try out different actions and observe the reaction of the system. Because of this reason, the system identification step is often ignored by the AI community. It has nothing to do with automatic game playing itself, but it's the prestep towards this goal.

Why robots are not available in the reality

Since decades, AI researchers have experimented with robots. Lots of papers were written, many lectures were held and since 20 years demonstrations are available in which real robots are shown to the audience. The average consumer wonders, why robots are not available in the store, next to a computer. The reason for this question should be given in the following blogpost.

What AI researcher and robotics experts are doing is to build production systems. A production system is a sandbox in which a simple version of the world is formalized. The shakey robot which was using the STRIPS language is a notable example for a production system. But recent biped robots are working with the same principle.

The self-understanding of a production system is, that there is the system itself and the environment. The system itself is working great. That means, the shakey robot will find the way along the obstacle and a biped robot is able to balance on two legs. Unfortunately, a production system has a border and everything which is outside the system is ignored.

What AI researchers are doing is to create a production system aka a sandbox first, and then they are programming software which works in this sandbox. A typical example is the cart balancing problem. The first step is to define the problem, which contains of a cart and a pendulum. This system is converted into a forward model, which means, that the software is able to predict future states of the pendulum. And then a so called controller is built on top of the production system which brings the pendulum into the desired direction. The result of the experiment are written down in software and the working prototype is presented to the audience.

Unfortunately, the concept has a big disadvantage. It is given in the first step in which the sandbox was defined. The cart balancing problem contains of certain elements and what is not represented in the system gets ignored. This is done because it helps to reduce the complexity. It ensures, that the AI researcher is able to create a forward model and it allows the same researcher to program an AI Controller which brings the system into a goal state.

The problem is, that production systems and the reality are not the same. In the reality, there is no such thing like a cart balancing problem which is encapsulated in a controlled environment. The problem is only available in the imagination. It's a synthetic challenge similar to the problem of following a line or do the peg in hole task.

Most of these synthetic problems were already solved by AI engineers. They have developed lots of algorithms for doing so. The problem is, that these algorithm are working only in combination with a production system. If no sandbox is defined first, it's not possible to create an AI system.

To understand why robotics fails in reality we have to focus what AI programmers are doing. The strategy is always the same, in the first step a production system is created and in the second step this synthetic production system gets solved. AI is focussed only on the second step. The question asked in the books is how to solve a certain problem, for example who to navigate a robot in a maze.

For real robotics application this kind of questions goes into the wrong direction. The more elaborated problem is, if the reality is about a maze navigating problem. The sad answer is, that in most cases the assumed production system doesn't match the reality. The result is, that from a technical perspective the AI engineers are able to solve the problem, and at the same time they don't.

The robotics available today are working from it's self understanding great. That means, the software is able to balance the biped robot. The problem is, that this balancing task was not requested by the reality. The AI engineers have solved a different task from what is needed. To understand this phenomena we have to go back to the first micromouse challenge. Micromouse is a robotics challenge with a long history. The motivation was, that robotics has failed to automate the workflow in a factory but instead asking why, the researchers have imageined a challenge they are able to solve.

Instead of using a robot to replace a human worker in a factory, the idea is to focus on a problem which can be solved by a robot. This sort of problem is a micromouse challenge. The task of driving through a maze has no practical application, it's useless. And the algorithm can't be transfered into the reality. This kind of workflow was repeated for other challenges. As a result, today's robot are successful in solving lots of problem, but the problems have nothing to do with practical applications.

System identification

In the classical control theory, there is a step available called “system identification”. The idea is to transfer a task from the reality into a simulation. The system identification step is the bottleneck for modern robotics. In all the robotics projects, the system identification was made the wrong way. Instead of describing a real system, the engineers have identified a simplified version of the reality. This model is used in the later steps as the problem definition and gets solved by the algorithm. The engineers believe they are able to solve the problem, but what they are doing is to solve the wrong problem.

A robotic problem contains of two steps: 1. system identification 2. solver. The solver step is equal to what is discussed as core AI. The question is how to play a game with Artificial Intelligence. Not a human operator takes the decision but an algorithm. Creating solver algorithm is surprisingly easy. For most problems it's available to program the software. The common techniques of object-oriented programming, neural networks and expert systems are well suited to play games autonomously.

The first step (system identification) is much harder to tackle. The amount of literature about the subject is low, and most AI engineers are not aware why this step is needed. They assume, that a model is already there. And if not, a simplified model can be used. If the system identification step is ignored or handled with a low priority the robot project will fail. That means, the working robot is useless for practical application. The problem solved by the robot is different from the needs in the reality. Nearly all existing robots can be categorized in such a way.

Solving Tictactoe

The tictactoe game has already a system identification. The game rules are known and the AI can be programmed. The AI works with a gametree search in which the possible actions are evaluated and the solver decides what to do next. Creating an AI for the TicTacToe game is easy.

A slightly more difficult problem is to solve the game of chess. Similar to TicTacToe, the rules are known. The chess board in the computer program is the same like a real chess board. This moves generated by the AI are making sense in a real game of chess.

The problem in the robotics domain is, that in contrast to TicTacToe and chess the system identification step is missing. The rules are not known. The AI engineeres are starting with a wrong model and then they are programming a solver for this wrong model. The generated moves for the wrong model are nonsense for the real model, therefore the robotics project fails.

The limits of Artificial Intelligence

In the history of AI the famous xor problem is referenced as an early pessimistic challenge to show what computers can't do. In the 1970s, the Lighthill report also claimed, that robotics has limits. Since the advent of Deeplearning the former concers have been overcome and the modern description towards AI and robotics is, that any technical challenge can be overcome.

The xor problem and the lighthill report both mentioned a technical challenge. In the xor case, the problem was to train a perceptron neural network to detect a certain pattern, and the lighthill report was about computational complexity of so called np-hard problems. Both issues can be solved with modern technology. For current AI discipline it's very easy to tackle the xor and the np-hard problem as well. So called np-hard problems can be solved easily with heuristics and faster computers while the xor problem can be tackled with a simple backpropagation learning algorithm.

It's naive to assume that modern AI doesn't have any kind of limits. They are available but they are hidden deep in the existing literature. The problem has to do with man-machine interaction. A robot will work great in the laboratory but it fails in the reality. This kind of gap is the modern limit of AI. Let me give an example.

Today's engineers are able to build soccer playing robots, self-driving cars, grasping robots and drones. In synthetic AI challenges like micromouse challenge, Mario AI and the robocup soccer challenge, the software shows it full potential. On the first look, it's an example how to use modern technology in a sense making way. The problem is, that non of the algorithm will work in the reality. It's not the fault of enginees, but it's a general problem.

To reproduce the failure we can create a robot challenge from scratch. At first, we need a robot problem. For example, the robot arm should pick&place an object. The next step is to build the hardware and program the software. Then the system is demonstrated in a public robot challenge. Writing the software and building the robot is not very complicated. All what the developer has to do is to implement a modern trajectory planning algorithm, use some neural networks for image recognition and the system will work great.

And now comes the issue. If this newly created robot should be used not in the synthetic challenge but in a real kitchen, the overall system will fail. The exact reason why is unclear. But all experiments in the past have shown the same result. It seems, that programming a robot is easy, but let the robot do a meaningful task is an unsolvable problem. To focus on the concrete issue we have to define what current AI is able to deliver.

What is in the reach of state of the art robotics is to fulfill synthetic robotics challenges- This is done by building the hardware and program the software. The resulting robots will walk, fly and grasp without any problem. They are even able to master games like soccer, hockey, tennis or whatever. Lots of demonstration videos are available in the internet, but it's also possible to build such robots from scratch without using existing software.

The problem with these projects is, that they can be categorized as practical joke toys. The machine is doing something which is funny, but not more. A robot which is useful in reality has to become not a joke toy but a productive robot. The average customer likes to use a robot for reducing it's own workload. That means, the robot should do work which is normally done by humans. And this minimum requirement isn't fulfilled by current robotics.

It's not fulfilled by self-created robot projects from scratch, and it's not fulfilled by commercial grade robots. This kind of disappointed insight isn't discussed in the literature. Instead the mainsteam robotics community has the hope that the results from synthetic challenges can be transferred in the reality. The idea is, that if a robot is able to walk on two legs and can kick a ball into the goal, it is very easy to use such a software for practical application and build a business around the robot. This kind of optimism can't be fulfilled.

Under the term “limits of automation” the discussion was held on a theoretical level. The most obvious reason why robots have failed in reality is because the normal automation level was high before the advent of robots, and it's hard or even impossible to increase the automation level further. A simple example is a modern kitchen. Current technology consists of automatic refrigerators and automatic washing machines. This kind of automation level requires only a small amount of humans. It's not possible to replace these humans with robots and increase the automation level to 100%. Exactly this pessimistic point of view can be seen in every robotics project. The result is, that even kitchen robots are working great in the lab, they can't be introduced in real kitchens.

The danger is high, that Artificial Intelligence in general is a waste of time. A discipline which doesn't produce new kind of practical technology, is some kind of non-sense science. Sure, the AI discipline has evolved over the years and current algorithm have become much better than it's counterparts 30 years ago, but even today's AI software can't be used for practical applications. It's fair to summarize the issue so, that AI is a purely theoretical discipline.

Macro-economic experts have formulated the thesis under the term “productivity paradox”. It compares advanced technology for example biped robots which can do the backflip faster than a human with it's inability of doing something useful. That means, on the one hand, the enginees can build a walking robot who is able to climb stairs and can perceive the environment with advanced neural networks, but the engineers struggle to use this robot for simple tasks and increase the productivity by only 1%.

The perhaps most impressive example who Artificial Intelligence and practical applications doesn't fit together is the domain of game AI. Since the 1990s, lots of advanced strategies were developed to realize all sort of non player characters. An early example are the ghosts in Pacman, but it's possible to play other games like chess, Super Mario, Go and sokoban with Artificial Inteligence. A modern game AI beats a human player easily. This was perceived by the AI Community as an example how well the discipline has evolved.

The problem is, that all these game AI characters are useless. They are working great in the simulated environment but it's not possible to use the software for controllling real robots. A naive assumption is, that it's very easy because controlling a game character needs the same amount of artificial intelligence which is needed for a pick&place robot in the kitchen. The problem is, that a practical robot should provide a value for the customer. He likes to press the on button, and then the machine is doing something for the customer. Exactly this requirement is out of reach. Current AI is not working with this principle.

Perhaps this pessimistic outlook sounds a bit uncommon. The advice is to start a simple game. You as a reader, can try to browse through online robot stores and identify a practical robot. Then this robot should proove, that it is doing something useful. The hypothesis is, that such an experiment will fail. There is not a single robot available which will reduce human workload. As a result, most robotics companies from the past went into bankruptcy. They have designed certain robots, but they were not able to sell them to the customers. Instead of providing some examples, it's up to the reader to find the concrete models.

In contrast, it is very easy to identify non-robotic machine which will improve the daily live or can make a company more productive. Typical examples are normal cars, normal washing machines, all sorts of mechanical tools and so on. These products have in common, that the customer has to pay first the price for the product, and then he gets something in return which improves the activity. Let me give an example.

A device like a electric oven is not sold as a practical joke article which is able to prank people in the next party, but the machine has a practical application. It is bought by the customer, because he likes to heat water. The prediction is, that after buying an electric oven, the customer will use the product on a daily basis and because of this reason the paid price for the product make sense. That is some sort of normal product.

Robotics are different kind of category, they do not have a practical purpose but they are sold for different reasons. Somebody may think, that a robot can be used in meaningful way, similar to an electric oven, but this kind of outlook in naive. Making this unrealistic expection visible and find reasons why is an important step towards a modern Artificial Intelligence.