Integration of an Agent Model into an Open Simulation Architecture for Scenario-Based Testing of Automated Vehicles
This repository contains the modular integration of our closed-loop agent model within an open simulation architecture presented in our paper. We provide a straight-forward simulation integration approach based on standards such as FMI and the Open Simulation Interface (OSI) enabling the agent model to be integrated within different simulation tools. The model itself is a responsive, closed loop and human-like agent that reacts on other traffic participants and is able to perform basic maneuvers. Find a brief description of the simulation architecture but also the agent model itself in the sections below.
Agent.Model.Integration.mp4
Important
This repository is open-sourced and maintained by the Institute for Automotive Engineering (ika) at RWTH Aachen University.
Simulation, Agent Models and Human-in-the-Loop for Automated Driving are some of many research topics within our Vehicle Intelligence & Automated Driving domain.
If you would like to learn more about how we can support your DevOps or automated driving efforts, feel free to reach out to us!
Timo Woopen - Manager Research Area Vehicle Intelligence & Automated Driving
+49 241 80 23549
timo.woopen@ika.rwth-aachen.de
Integration of an Agent Model into an Open Simulation Architecture for Scenario-Based Testing of Automated Vehicles
Christian Geller, Daniel Becker, Jobst Beckmann, Lutz Eckstein Institute for Automotive Engineering (ika), RWTH Aachen University
Abstract – Simulative and scenario-based testing are crucial methods in the safety assurance for automated driving systems. To ensure that simulation results are reliable, the real world must be modeled with sufficient fidelity, including not only the environment but also the surrounding traffic of a vehicle under test. Thus, the availability of traffic agent models is of common interest to model naturalistic and parameterizable behavior, similar to human drivers. The interchangeability of agent models across different simulation environments represents a major challenge and necessitates harmonization and standardization. That is why we propose a standardized architecture for the integration of agent models based on the Open Simulation Interface (OSI) as a structured message format. In addition, the Functional Mock-up Interface is used for a dynamic exchange of models. Using our architecture enables a simple and modular integration of closed-loop agent models into multiple popular simulation tools. The generic nature of the architecture is demonstrated by integrating a novel and modular agent model into three different simulation tools: OpenPASS, CARLA, and CarMaker. Plausible behavior of the agent model to generate realistic traffic is achieved by defining various capabilities such as naturalistic free driving, vehicle following, and obeying basic traffic rules. In our paper, we motivate the simulation integration architecture and evaluate the agent model regarding its capabilities in both simple scenarios, but also in complex multi-agent traffic simulations. We make both the integration architecture and the agent model publicly available at github.com/ika-rwth-aachen/agent-model-integration.
Fig. 1: Intersection scenario populated by multiple agents within the exemplary simulation tool CARLA. The agent model's main capabilities are highlighted to demonstrate a responsive and human-like behavior. In addition, the general integration process is illustrated, starting with the development of the agent model, subsequent simulation integration, and final testing.
The overall architecture is designed to package the model as an FMU capable of transferring data via OSI. Thus, the model can be either directly downloaded as provided FMU file or alternatively built from source.
We provide a GitHub Action that directly builds the agent model in an FMU package within a GitHub CI workflow. You can download all released FMU packages of the agent model here.
Alternatively, the following steps describe how you can build the resulting ikaAgentModel.fmu
package own your own from source.
We recommend to use Ubuntu 20.04 or higher and at least CMake version 3.5!
Before starting the build process, the repository submodules need to be downloaded:
git submodule update --init --recursive
Note
Due to the usage of the CMake feature ExternalProject_Add()
, there is no need to download and build Protobuf from source.
- Create a
build
directory and enter it:
mkdir build && cd build
- Execute CMake:
cmake -DCMAKE_BUILD_TYPE=Release ..
Note
The default build directory for the FMU
is the subfolder lib/
. If a specific FMU
output dir shall be used, set the variable FMU_OUTDIR
, e.g.
cmake -DCMAKE_BUILD_TYPE=Release -DFMU_OUTDIR=<dir> ..
- Compile the FMU package:
make
Note
Use make -j4
for building on multiple cores
The external FMU parameter DEBUG
enables logging information at runtime within the ${workspace}/debug
folder. The resulting json
files hold information about the horizon
, vehicle_state
, and driver_state
at each timestep.
The final integration of the model into an existing simulation architecture depends significantly on the particular tool, which means that no specific instructions can be given here. While some tools such as CarMaker or OpenPass enable direct support of FMUs, third-party open-source tools such as the Carla-OSI-Service and OSMP-Service can be used for CARLA. Please have a detailed look at the specific documentation of your chosen simulation tool.
Before describing the agent model itself, its framework is briefly described.
The implementation uses the OSI Sensor Model Packaging (OSMP) framework to pack the library as a standardized FMU. This way, the model may be integrated in any simulation platform that supports the Open Simulation Interface (OSI) and FMI.
The figure below illustrates the wrapping around the actual behavior and dynamics model to end up with an encapsulated FMU. The input of the FMU consists of an osi3::SensorView
for the environment representation and an osi3::TrafficCommand
which holds information on the agent's task in the simulation run. On the output side the simulator can either use the provided osi3::TrafficUpdate
to manage the updated pose of the agent or forward the generated sl::DynamicsRequest
message to another module that then calculates an osi3::TrafficUpdate
. Inside the FMU, internal interfaces are used to feed the behavior model and then calculate its new position with a simple vehicle model and controllers for pedal values and the steering angle.
Fig. 2: Agent model packed as FMU integrated into an OSI-based simulation architecture.
The model core itself is open-sourced in a dedicated GitHub repository. However, its basic structure and features are described in this section.
On the left side of the following figure the input interface is shown. It consists of information on the environment (static + dynamic), the route and the ego vehicle. Inside the model these signals are processed as Perception layer. This is currently just a "pass-through" layer, but it would be possible to model the driver's perception ability by disturbing input signals.
The Processing layer takes the environment and traffic data and enriches them with measured values such as TTC or THW. Following, the most suitable maneuver is selected and modeled by conscious guiding variables (e.g. a THW to a leading vehicle that should be maintained). Conscious variables are controlled by the sub-conscious variables acceleration and curvature (Note: Z-micro
corresponds to the later implemented sl::DynamicsRequest
message here).
The Action layer models the actual dynamics of the vehicle and is visualized as Dynamics Model also in the right most block of the previous figure.
Fig. 3: Behavior model architecture (taken from [2]). An extensive discussion of the figure below can be found in [1]
The agent model is implemented such that basic driving maneuvers are modeled which enable the model to perform most driving tasks that are required in urban scenarios (cf. [1]). Those capabilities or basic maneuvers are illustrated as a state diagram in the following:
Fig. 4: Behavior model basic maneuvers (taken from [2]).
The most important parameters are directly configurable using FMU parameters:
Parameter | Description |
---|---|
v_init |
The initial velocity of the agent (in m/s) |
v_desired |
The desired velocity the agent reaches on a straight road (in m/s) |
Note
All other model parameters can be parameterized directly in the source code of the agent model.
When integrating the agent model within the open simulation architecture, a well-defined interface is required. OSI already defines a valid and powerful baseline.
The following fields are required as OSI inputs for the agent model
sensor_view
host_vehicle_id
global_ground_truth
moving_object
base --> all except base_polygon
id
assigned_lane_id --> Is deprecated in osi. Will be changed to classification soon
vehicle_classification --> maybe fill that as well. The deprecated signal above will be changed
lane
id
classification
type --> type_intersection is important
is_host_vehicle_lane
centerline
centerline_is_driving_direction
left_adjacent_lane_id
right_adjacent_lane_id
lane_pairing
right_lane_boundary_id
left_lane_boundary_id
subtype
lane_boundary
id
boundary_line
classification --> not that important for now, but maybe in the future
traffic_sign
main_sign
base
position
classification
assigned_lane
type
value
traffic_light
base --> all except base_polygon
id
classification
color
icon
assigned_lane_id
road_marking --> not right now but for stop lines in the future
traffic_command
action --> the following actions can be considered right now
acquire_global_position_action
# path and trajectory are implemented the same as acquire position:
# the last point of the list is taken and a path along the centerlines
# ist planned. So it is not really a follow path/trajectory action
follow_path_action
follow_trajectory_action
speed_action --> the desired velocity is updated
The following fields are filled from the agent model and can be used by the simulation tool.
osi3
# Values computed by a simple vehicle model and PID controllers for pedal and steering
traffic_update
position (x,y)
velocity (x,y)
acceleration (x,y)
orientation (yaw)
orientation_rate (yaw)
# Can be used when a separate dynamic module is used (not the agent's dynamics module)
sl
# Can be used when a separate dynamic module is used (not the agent's dynamics module)
dynamic_request
curvature_target
longitudinal_acceleration_target
# Note: these are *desired* values from the behavior model
[1] System Design of an Agent Model for the Closed-Loop Simulation of Relevant Scenarios in the Development of ADS, 29th Aachen Colloquium 2020, 07.10.2020, Aachen. Jens Klimke, E.Go Moove GmbH; Daniel Becker, Institut für Kraftfahrzeuge (ika); Univ.-Prof. Dr.-Ing. Lutz Eckstein, Insitut für Kraftfahrzeuge (ika)
[2] Agentenmodell für die Closed-Loop-Simulation von Verkehrszenarien, ATZelektronik 05 Mai 2021, 16. Jahrgang, S.42-46. Daniel Becker, Jens Klimke, Lutz Eckstein. Link
We hope that our agent model integration can help your research. If this is the case, please cite it using the following metadata.
@inproceedings{AgentModelIntegration24,
author = {Geller, Christian and Becker, Daniel and Beckmann, Jobst and Eckstein, Lutz},
title = {{Integration of an Agent Model into an Open Simulation Architecture for Scenario-Based Testing of Automated Vehicles}},
url = {https://github.com/ika-rwth-aachen/agent-model-integration},
year = {2024}
}
The work of this paper has been done in the context of the SUNRISE project which is co-funded by the European Commission’s Horizon Europe Research and Innovation Programme under grant agreement number 101069573. Views and opinions expressed, are those of the author(s) only and do not necessarily reflect those of the European Union or the European Climate, Infrastructure and Environment Executive Agency (CINEA). Neither the European Union nor the granting authority can be held responsible for them.
Additionally, this work received funding from the SET Level and VVM projects as part of the PEGASUS project family, promoted by the German Federal Ministry for Economic Affairs and Energy based on a decision of the Deutsche Bundestag.