Abstract: Driving in dynamically changing trafﬁc is a highly challenging task for autonomous vehicles, especially in crowded urban roadways. The Artiﬁcial Intelligence (AI) system of a driverless car must be able to arbitrate between different driving strategies in order to properly plan the car’s path, based on an understandable trafﬁc scene model. In this paper, an AI behavior arbitration algorithm for Autonomous Driving (AD) is proposed. The method, coined AIBA (AI Behavior Arbitration), has been developed in two stages: (i) human driving scene description and understanding and (ii) formal modelling. The description of the scene is achieved by mimicking a human cognition model, while the modelling part is based on a formal representation which approximates the human driver understanding process. The advantage of the formal representation is that the functional safety of the system can be analytically inferred. The performance of the algorithm has been evaluated in Virtual TestDrive(VTD),a comprehensive trafﬁc simulator, and in GridSim, a vehicle kinematics engine for prototypes.ArXiv paper link
Multi-disciplinary Trends in Artificial Intelligence, p.191, DOI: 10.1007/978-3-030-33709-4
The main reason behind the human ability to drive cars is our capability to understand the driving environment, or driving context. In the followings, we will refer to the driving context as the scene and we will define it as linked patterns of objects. We introduce AIBA (AI Behavior Arbitration), an algorithm designed to arbitrate between different driving strategies, or vehicle behaviors, based on AIBA’s understanding of the relations between the scene objects.
A driving scene consists of objects such as lanes, sidewalks, cars, pedestrians, bicycles, traffic signs, etc., all of them being connected to each other in a particular way (e.g. a traffic sign displays information for a driver). An example of such a driving scene, processed by AIBA within EB robinos, is depicted in Figure 1. EB robinos is a functional software architecture from Elektrobit Automotive GmbH, with open interfaces and software modules that manages the complexity of autonomous driving. The EB robinos reference architecture integrates the components following the sense, plan, act decomposition paradigm. Moreover, it also makes use of AI technology within its software modules in order to cope with the highly unstructured real-world driving environment.
2. Driving Scene Description
The driving scene description is given from a human driver’s perspective, and it formulates properties derived from the definitions of classes, subclasses and objects which represent the core of an abstraction model, based on the authors’ previous work. The main idea behind AIBA is to model, or formalize, the HDr understanding process and afterwards transform it into a formal model for behavior arbitration in Autonomous vehicles.
2.1 Driving Scene Analysis
A human driver is able to perceive the scene’s objects and observe them. This means that the HDr identifies the concepts and the different properties of the objects. In the end the driver can describe the scene in Natural Language (NL), as for the traffic example in Fig. 1: “the car is near exit E1; the main road continues straight and will reach the location L1, L2, L3; the traffic has a medium density and takes place under normal circumstances; the car is in the 3rd lane in safe vicinity to other cars”. Apparently, this message eludes a lot of information, but if it is shared with other human drivers, it proves to be a piece of very important and comprehensive knowledge.
The different scene objects are linked between them. Intuition assumes that the most important links are those established with the front car, or the main road, while the less important links are those between the ego-car and the buildings.
The links definition is a first step in the knowledge process, which means it establishes the subjects of interest and also the importance level of each subject. The HDr scene understanding synthesis contains the following steps: identifying the link between the objects, allocating models to each link, running the models and afterwards finding a strategy to act. In fact, the HDr creates an implicit system and simulates it.
The links have different meanings and importance, or significance. Specifically, a human driver knows the traffic rules and how to get to his destination. These rules will determine traffic priorities, thus making the HDr to attach a greater importance to those links which are more important to his strategy.
In the next step, a description is established for each link. During the driving, the HDr adapts, or refines, the mentioned description by observation. The driver, by using the importance of the links, simulates a scene description. If we analyze the aim of driving scene understanding, we will observe that its origins are the stability in time and space. More precisely, the human driver has a driving task which can be accomplished if the possibility of locomotion is preserved in the current position and during a specific time. Intuitively, the stability is related to the objects in the scene and can be reached by understanding the scene. This understanding does not solve the driving problem, but offers the information upon which the human driver decides to act on a certain behavior.
3. Driving scene modeling
Entities like objects, links, or networks, which have been introduced in the previous section, have correspondences in the modelling process. Our intention is to approximate the HD understanding process through a formal representation. More precisely, this assignment mimics an input/output process: using a perceived scene, the AIBA model must output a description which offers all the information needed within the AD system to arbitrate the driving behavior.
The block diagram representation of AIBA is illustrated in Fig. 3, where the information flow emulates the human driver scene understanding phenomenon.
Our experiments were conducted in our own autonomous vehicles prototyping simulator GridSim and in Virtual Test Drive(VTD).
GridSim is a two dimensional birds’ eye view autonomous driving simulator engine, which uses a car-like robot architecture to generate occupancy grids from simulated sensors. It allows for multiple scenarios to be easily represented and loaded into the simulator as backgrounds, while the kinematic engine itself is based on the single-track kinematic model.
In such a model, a no-slip assumption for the wheels on the driving surface is considered. The vehicle obeys the ”non-holonomic” assumption, expressed as a differential constraint on the motion of the car. The non-holonomic constraint restricts the vehicle from making lateral displacements, without simultaneously moving forward.
Occupancy grids are often used for environment perception and navigation, applications which require techniques for data fusion and obstacles avoidance. We used such a representation in our previous work for driving context classiﬁcation. We assume that the driving area should coincide with free space, while non-drivable areas may be represented by other trafﬁc participants (dynamic obstacles), road boundaries, buildings, or other static obstacles. The virtual trafﬁc participants inside GridSim are generated by sampling their trajectory from a uniform distribution which describes their steering angle’s rate of change, as well as their longitudinal velocity. GridSim determines the sensor’s freespace and occupied areas, where the participants are considered as obstacles. This representation shows free-space and occupied areas in a bird’s eye perspective. An example of such a representation can be seen on the left side of the below picture .
On the right side of the above picture we can observe the Virtual TestDrive. This is a complete tool-chain for driving simulation applications. The tool-kit is used for the creation, configuration, presentation and evaluation of virtual environments in the scope of based simulations. It is used for the development of ADAS and automated driving systems as well as the core for training simulators. It covers the full range from the generation of 3D content to the simulation of complex traffic scenarios and, finally, to the simulation of either simplified or physically driven sensors.