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.