Why is Artificial Intelligence teached at universities?

From the self-understanding, Artificial Intelligence is a technology which helps to automate a workflow with robots. It is equal to systems engineering and every student should learn the topic. The reality is quite different. Artificial Intelligence is not researched at universities because it solves real world problems, but it will escape from the reality. What does that mean? Real world automation has nothing do with cybernetics nor robotics. Any automation problem in a factory can be handled well with meccano like machines. It is possible to construct conveyor for any sort of tasks. Packaging food, sorting products, creating clothings and creating smartphones. Right, Smartphone production is an highly automated task not done by humans or robots but by meccano like machines.

So what exactly is the purpose of teaching Artificial Intelligence in the university? The beginning of AI was called cybernetics. Cybernetics is about the so called control problem. That is a game played ontop of an existing system. In reality no such thing like a control problem is there, it has to invented first. What AI researchers are doing is to invent artificial control problems which can be solved by AI systems. A typical example what AI courses at the university are about is first to create a game, for example Pacman, and then the students have to invent an AI controller which plays the game automatically. The reason why Game AI is used as an example is because games have a lot of control problems. Each game forms a control problem, and the control theory better known as Artificial Intelligence tries to solve this problems.

The surprising fact is, that in real factory no control problems are available. What a food company is doing is not to play games, but they are minimizing any decisions. A process is called fully automated if any sort of decision making process is missing. A packaging machine doesn’t make decision based on input signals, but the machine is putting apples into a box. It is important to understand that both things are different things. Either we can talk about automation in a factory or we can discuss control problems.

Control theory has to do with software, robotics, state-space planning and Artificial Intelligence. Mechanical automation has to do motors, machine design and productivity. Artificial Intelligence is great for motivate students to think, but it is poor in automate anything. In contrast, meccano like machines are great for factory automation and reducing costs but they doesn’t inspire the students.

The sad truth about robotics and artificial Intelligence teached at university level is, that this kind of knowledge is useless in real life. it is not possible to use the robotics from the lab for a concrete task. AI and computers were invented for brainwashing the people. The subject is about pure thinking and solving problems not available in nature. AI is the answer to the entertainment problem. This is a problem for a bored world in which the work is done, and the people are playing games. If we are observing the upraising of Artificial Intelligence since the 1950’s the development was going in parallel to the invention of games. Games are an invention which are useless by default. A game like chess formulates a problem not there outside of chess. It is a world by it’s own. And this is what AI researchers are doing in so called robotics challenges. They are not trying to solving problems like how to rescue people or how to automate a factory, instead the robocup rescue challenge is programming task which is 100% for educational purposes. It is sure, that not a single line of software code written for that competition will ever be used in reality. That means, the problem in Robocup rescue are not highly realistic but they are synthetic. The teams are solving problem not available in real life. They are doing so because they students are programmers, artists, scientists or computer hackers.

What most students are not aware of it, or what they are ignoring is, that no connection is there between a robocup rescue team and a firefighter team in the real world. That means, the robocup students have not attended in real firefigther projects, and real firefigthers are not motivated to visit the robocup challenge. This missing information exchange is not the mistake of individuals or wrong priorities, it is the goal of robocup to create a separate world which has nothing to do with real world. That means, the robocup scenario is highly unrealistic, everybody knows it, and that is the reason why the students are motivated to write sourcecode for their robots.

The joke is, that more advanced robots not invented yet, will not be able to be used in reality. Even the robots in 30 years which are much better in the robocup challenge are not able to rescue real victims in reality. That means, Artificial Intelligence research can make progress without effecting the reality. That means, the firefighters in reality will become the same in 30 years from now, but the AI researched has made large progress. The reason is, that a real rescue mission is not a game and doesn’t contains of control problems which can be solved with software, but a real scenario is about firefighting.


The difference between robots and automation

AI researchers have struggled in the past to define a robot. A robot can be used at the assembly line, but a normal machine too. Is a robot simply a computerized machine? The answer is a bit more complicated. A non-robotics system is called classical mechanical automation. The best example is a packaging machine is able to put food in a box. Such a machine doesn’t need a robot gripper or a vision system instead the food is feed with an assembly line and mechanical parts are bringing the product into the right position. The reason why classical automation machines are used in industry is because they are providing a benefit for the company. A modern packaging machine can reach a throughput of 120 boxes per minute. Before a company will buy such technology they will calculate the exact benefit with numbers and decide to buy or not.

In contrast a robot is working under a different condition. A robot is not able to increase the productivity. So called robotics technology was invented late. The first robot were released in the 1980s with the advent of microcomputers. Robots have no benefit for an industrial company and in most cases they have a negative effect. That means, they won’t increase the productivity but they will increase the automation level. This is known as the automation paradoxon. It says, that classical all mechanical machines have a positive impact to the company, while robots and artificial Intelligence are doing the opposite. If a company decides purely on economical reasons, it is not recommended to buy an industrial robot.

And this is the difference between robots and classical machines. Normal machines are helping the people and are able to improve the things. If a company owns a packaging machine the system will work autonomously. That means, after pressing the on button the machine will work 24/7 and produce lots of products which can be sold at the market. This makes the company rich. A robot is working with the opposite goal. It will make the owner not rich and it will consume lots of manual work. The programmings will take endless and no real result is possible. Even for simple pick&place tasks a robot is poor choice. It won’t work robust and the robot will be more expensive than human work or a mechanical machine.

At the same time, robots are fascinating piece of machines. They are given an outlook how the future will look like and most engineers are fascinated by them. On the one hand, robots are completely useless and at the same time, they are more interesting than normal mechanical machines. A robot can be programmed in any direction, and the number of ways in running a program are endless. From an objective point of view, robots shouldn’t be used in a company. They are a waste of ressource and doesn’t fit to modern automation. At the same time, many engineers are trying to program robots in a useful way. They are trying so since decades. Without much luck. In the 1960s the idea was, that the technology is not highly enough developed. Today’s robots are more advanced but they can’t be used in a production environment as well. The problem is not located in the technology, but the robot itself is the problem. That means, the first law in robotics is, that it is not possible to use them in a productive way. Instead, all robotics will fail. A robot has a demand for energy and programming skills but a robot won’t provide work in exchange.

The reason why robots don’t provide work after they are programmed in the right way was often researched. But it is until now unclear what the exact reason is. My personal opinion is, that the benefit of robots over mechanical automation is too low. That means, a robot would be useful if no classical mechanical machines are available. Or to explain it from the other point of view. A non-robotics packaging machine has already a very high productivity and it is not possible to increase it further.

If today’s all-mechanical machines have a low productivity, this issue can be fixed within the same technology level. That means, the answer is to build better mechanical machines. The answer is not to switch to robots. This kind of innovation is working different and has no longer productivity as their major goal. Robots have a different social role in a society. They were not invented to increase the productivity or to help the people but robots are useless by default.

Formalizing domain knowledge with predictive models

A great challenge in Artificial Intelligence is to store abstract domain knowledge into software. Many concepts are discusses in the literature, for example expert systems, intelligent tutoring systems, neural networks or semantic networks. But how exactly are these concepts able to store knowlege?

From a formal perspective, domain knowledge is equal to predict future states of a system. If somebody is able to say, that the ball will be rolling to the left, he has understand the system. Such a prediction is only possible if the interactiion between input variable, current state and mechanics of the system are brought together. A predictive model which is sometimes called a forward simulation is an easy but powerful tool. It is used in games but it can be used for creating an artificial intelligence.

A typical chess engine which is using brute force for realizing artificial intelligence is using also a predictive model. If the software builds a game tree of future states, this is equal to a prediction model. That means, the gametree is the result of the forward simulation. It formalizes what will happen if.

It is not very common to call a game tree, a predictive model and domain knowledge all the same. Usually this is treated as separate things. But it is all the same. If the game tree of game is made explicit in a graph, this is equal to domain knowledge about the game. The question is: how can a gametree for any game be created? The second question is how to search in the game tree for a goal state?

Let us go a step backward and see what will happen without a prediction model. Suppose, in a game like pong no forward simulation is available. How can the AI controller working? In the literature the term policy is used for a simulation-free agent. The idea is, that the agent contains of rules. The rules are mappend to the current state and the agent is done what is written in the rules. Indeed, no forward simulation is used in that technique. A simple, if A then do B relationship is the opposite of a prediction model. A prediction model would be the more elaborated form of domain knowledge, because it doesn’t provide the answer what to do in a certain situation, but it provides only possible outcomes. According to the model, it is possible to act wrong in a situation. The step of deciding between good and bad is postpone to the search in the game tree.

Let us go back to the chess engine. A chess engine is creating lots of possible moves who are wrong. That means, the engine is simulating a weak move and then it will analyze what the future will bring. In the literature this kind of evaluation is called the horizon. That means, in the horizon are many thousands possible future states available, which includes bad and good moves. The reason why this technique is successful is because in many games a good move will be in a later state a bad move and the other way around. That means, it is not possible to say which kind of action is right, without anaylze future states.

Domain knowlege

Computercode is equal to software. It is possible to program in software anything. The main problem for Artificial Intelligence is the question how to code knowledge into software. Suppose the following hypothesis: knowledge is equal to a predictive model. The new question is: how can we code a predictive model in software? The surprising news is, that this kind of question can be answered easily. A predictive model is usually a class in a program. The class takes the current state and the player actions and will output the future state. It is similar to a forward model. In games it is called the physics engine. A physics engine contains of all the domain specific knowledge. It is able to predict future states.

But if the domain knowledge is already stored in the software, why is realizing Artificial Intelligence so hard? The problem is, that the domain knowledge is stored in the Box2D engine, but it takes to long to predict future states. Each iteration of the game-engine takes some milliseconds and for building the complete gametree there is not enough cpu time available. That means, the domain knowldge is available in software, but it is not possible to get access to that knowledge. That is the reason why Artificial Intelligence failed.

A more useful predictive model is faster than a normal physics engine. It is able to predict longer horizons in a short amount of time. In most cases, such a model has to be created from scratch on top of the existing game engine. Even if a physics simulation like Box2d is available, there is a need to rewrite the engine from scratch. What AI has to answer is the question how to realize such forward simulation with less effort. That means, if techniques like neural networks, expert systems and semantic networks are able to realize a forward simulation, than it is a here to stay.

A possible answer why predictive models are ignored in the literature is because they are not able to generate useful steering commands. A predictive model alone is useful, it can’t answer what the robot should do next. The predictive model will only generate what-if-scenarios. It will make the decision more complicated and not easier. It is not possible to connect a robot with a predictive model in the hope, that this is equal to artificial intelligence. So in most literature the problem of prediction is ignored and instead policy generation is discussed. The idea is, that a robot needs advice which actions are needed.

But a policy is not able to control complicated games. A policy has the disadvantage that the time horizon is not there. Instead it is equal to a lookup table. That means, the robot has fixed rules how to act in each situation, and if the situation is unclear, the robot runs into trouble. Such a behavior is similar to what Lemmings are doing. They doesn’t think about the situation, instead they are walking forward.

Prediction model

The reason why prediction models are attractive for Artificial Intelligence is because they can be realized in software. A prediction model can be there or not. And they are much easier to program than a full blown AI system. A prediction model is only a subpart of a robot, and it is possible to compare different approaches against each other. Let us go into the details.

Suppose have the game of pong. A simple form of a prediction model can be realized as a script. That means, the current ball’s position and it’s speed vector are feed into a subfunction and the function will calculate the new state. Similar to what is used for creating the pong simulation itself. But there is a small difference. The normal game engine in pong is very accurate. It is called 30 times per second and it will calculate the exact location of the ball. Because this pixel information is needed by the graphics engine to draw the sprite to the screen. In case of a prediction model, the requirements are different. The main difference is, that a prediction model has to estimate larger timespans. That means, we want to know the ball’s position in 1 seconds, 2 seconds and 5 seconds from now. In contrast, the exact position in the next frame which is a fraction of second away is not relevant.

How complicated is the task to program such a model? It is not very advanced and many techniques are available. A prediction model can be realized with neural networks or manual programming. And even a low accuracy is acceptable.

Surprisingly well working model predictive control

In search for a control policy for the ball on beam problem, I’ve recognized the model predictive control paradigm. The idea is, that domain specific knowledge is always stored in a forward model and if a system can calculate future states, the system has understood the situation. What can be seen in the screenshot is a box2d game plus a prediction as an overlay. The three yellow dots making possible actions visible. The player can choose to rotate the beam to the left, stay untouched or move to the right. On base of this minigame-tree which consists of three nodes the best outcome is determined and executed. As a result the beam will control by itself, that means without human intervention.

The open question right know is how to realize a so called “prediction model”? My answer to the problem is a Python class which contains of 50 lines of code. The core prediction function is “getfuture()” at the end of the class. It takes some features as input which are ballposition, angle of the beam and velocity of the ball and calculates the future ballposition.

class Prediction():
  def __init__(self):
    self.gametree=[] # ("action",ballpos)
  def update(self,pos,vel,angle):
  def getaction(self):
    if bestaction=="current": result="stop"
    elif bestaction=="left": result="rotleft"
    elif bestaction=="right": result="rotright"
    return result
  def searchnode(self):
    # returns best action
    # range: 290, 410, center is 350
    for i in range(len(self.gametree)):
      diffcenter= abs(self.gametree[i][1][0]-350)
      if diffcenter<minvalue:
    return self.gametree[minid][0]
  def buildgametree(self):
  def getfuture(self,action):
    # action="current", "left", "right"
    if action=="current": newangle=self.angle
    if action=="left": newangle=self.angle-2
    if action=="right": newangle=self.angle+2
    temp=self.vel[0]*100 # velocity
    temp+=newangle*20 # angle
    return (xpos,self.pos[1])

The interesting point is, that getfuture() is working independent from the Box2d physics engine. Instead of calculating the exact ballposition the predicted outcome is only an estimation. The advantage is, that the function needs very little cpu ressources and is executed in realtime, which means 20 times per second.

Grounded decision tree gameplaying

On the first look the ID3 decision tree learning algorithm is one of at least thousands other concept for realizing Artificial Intelligence in games. Why should this technique be better? In general, Artificial Intelligence contains of two different categories. Numerical one which are solvers and symbolic one which are using grounded natural language. In general, the second category with grounded motion primitives is superior, because it is based on programming. Artificial Intelligence has to do with domain specific knowledge and natural language is the best way in storing that knowledge into a computer program. And here comes ID3 into the game.

The precondition for realizing the ID3 algorithm is a training set, and the training set consists of domain specific categories. The typical example is the weather prediction in which the sun is shining or not. The category “sun is shining” is a good example of a grounded feature. The feature is described in a computerprogram as a boolean datatype (yes/no), but the more interesting part is the variable name (“sun is shining”).

Grounding means, that the terms in the program are referencing to external systems located outside the program. In the software itself, there is no sun and no weather. .But sun and weather is something which can be found outside of the program in reality. And it make sense to use the same term for both things.

The best way in creating an Artificial Intelligence from scratch is first to identify some features. They got terms in natural languages. The features are forming categories and they can be learned with the ID3 algorithm. The resulting decision tree is described in human-readable language. That means, the heuristic contains sense.

How to program an AI engine for a game?

A simple physics game contains of one ball and two beams. The player has the task to juggle the ball between the paddles. He can move them up/down or he can rotate the beam. Playing that game manually, is not very hard. It is similar to a flipper arcade game in the 80s. A bit more difficult is to realize an Artificial Intelligence which can play the game autonomously. The step to such kind of software are described in the following post.

At first, the game has to be motivated to become more chatty. That means, it has to tell us, what can be seen on the screen and this should be done with natural language. For doing so we need a table with grounding information. That is a lookuptable which connects words with numbers:

self.item =[ # ("group","number","word")

The table is a bit longer but contains only data and no sourcecode. An example query would be, that a ballposition x with 350 means, that the ball is on the right beam in the middle. The grounding table is requested in realtime during runtime of the game. It can put the following string to the screen:

Ball doesn’t move. It is in the right side and there on the middle of the beam.

This kind of semantic information alone won’t control the system. What we need else is a vocabulary of action words. That are normal python routines which are controlling the movement. The action words plus the grounding table forms a domain specific language. In this language, a controller is formulated. The controller is written in structured English. For example:

1. prevent that ball is falling off the beam. This is done with actions, if the ball is in right or left corner.

2. holds the ball speed always under below fast.

3. check if it’s possible to let the ball jump from one beam to another. And then activate the jump move.

4. Pay attention after a jump, that the ball lands on the beam. Sometimes a rotating action is needed to slow down the ball to zero.

Sure, it is not possible to write such kind of structured English directly into the Python sourcecode, in reality the code looks like if (cond1==true and cond2==true): action(“a”) but the syntax is nearly the same. That means, the ai controller is referencing to grounded motion primitives in natural languages, and he executes commands in natural language.

How does it work in reality? Can the AI controller generated automatically? The workflow of creating new AI controller is based on interactive testing. That means, in the first step the game is controlled manually without any AI control in the loop. In step #2 some grounded variables are created which are displayed only at the screen as a help for the operator. In step #3 only one of the movements is executated in parallel with the human operator. That means, the human operator has it’s finger on the keyboard and controls the beam, and suddenly the AI system makes an intervention. It activates the jumping action if according to the rules, the time is right.

The principle is known from automatic distance control in cars. It’s a shared autonomy between the AI and the human. Both subjects have access to the controls. In the step #4 more controls are programmed in software. Now the AI has to decide the jumping, the balancing on the beam, and actions for slow down the speed of the ball.

Here is the sample sourceode for the jump action:

def checkjump():
  if self.getvar("beam")=="right":
    if self.getvar("beampos")=="leftside":
      if self.getvar("velocity")=="leftslow" or self.getvar("velocity")=="leftmedium":
def main():
  if checkjump()==True:

The code is referencing to semantic information and it will activate the jump-movements if the conditions are fulfilled. Translated into structured English the procedure is doing the following:

checkjump: if if ball is leftside on the right beam and if it’s moveing to the left then the jump is possible.

main: if jump is possible then jump

The funny thing is, that during writing the code, in the first trial the system doesn’t work. But it was easy to identify the problem. The reason is, that the vocabulary in the AI controller is similar to what humans will explain, if they are observing a scene. That means, no numerical values are given in the controller but only English words. That means, the AI controller is operating on a high-level abstraction.

Natural language grounding with macro operators

Classical AI planning works with testing out motion primitives. For example, a robot has two wheels, left and right, and it’s up to the planner to determine the correct speed for the wheels to move the robot to the goal. That means, it is an optimization problem which can be handled with a brute-force search algorithm.

Macro-operators are a technique to speed up the search process in the game tree. The idea is to construct an artificial layer which is equal to predefined actions. The best example is given in the “Karel the robot” game. Here, the task is not to determine the lowlevel wheel speed, instead the aim is to program the robot. Programming means, to create subfunctions like “move 10 steps forward”, “rotate left”, and “rotate right”. In the subfunctions, lowlevel motor commands are submitted to the wheels. On the other hand, the function can be called from the main program. The macro operators are forming a communication layer between users requirements to direct the robot to a certain point on the map, and the needs of robot itself to get accurate wheel encodings.

Let us describe the conflicting needs in detail. The motor of a robot requires numbers as input. The left wheel of the robot can be moved with the speed -1, -0.5, 0, 0.5 or 1. That means the user has to put some of these values to the motor and the robot will understand the command. In contrast, the needs of the user are different. What the user is interested in is to solve certain problems. For example he wants to move the robot in a circle, or he want’s that the robot stops before an obstacle. The problem is, that the both instances (user and robot) are not compatible. The robot asks: “enter a value for the left wheel”, while the user says to the robot “move straight ahead”.

What happens, if communication between two instances fails? Right, there is a conflict. The result is, that the robot doesn’t move or he is moving in the wrong direction. What is missing is a layer between both parties which is able to translate the language back and forth. The interpreter takes a high-level command from the user “move ahead” and converts this into lowlevel wheel commands for the robot “leftwheel=.5, rightwheel=0.5”. The instance between the robot and the user is called grounding. In computer science such an instance is called a macro operator.

The interesting feature of macro-operators is that they are not equal to an artificial intelligence. The communication layer between the robot and the user doesn’t have goal and it can’t solve problems. It is working like a mouse driver used in operating systems which converts the physical sensor data from the mouse into pixel information for the GUI. That means, a mouse driver wasn’t programmed to click on a button. The same principle is used in macro operators and grounding layers in robotics. They are designed as an API which stands for application programming interface. Interface means, that something is put into the layer and something gets out of the system. In case of a grounded robot control system, the API takes highlevel commands in natural language and produces lowlevel wheel actions.