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.