# OpenCDA: An Open Cooperative Driving Automation Framework Integrated with
Co-Simulation

Runsheng Xu1, Yi Guo2, Xu Han1, Xin Xia1, Hao Xiang1, Jiaqi Ma1∗ 1Runsheng Xu,
Xu Han, Xin Xia, Hao Xiang, Jiaqi Ma are with UCLA Mobility Lab, University of
California, Los Angeles (UCLA)2Yi Guo is with University of
Cincinnati∗Corresponding<EMAIL_ADDRESS>
###### Abstract

Although Cooperative Driving Automation (CDA) has attracted considerable
attention in recent years, there remain numerous open challenges in this
field. The gap between existing simulation platforms that mainly concentrate
on single-vehicle intelligence and CDA development is one of the critical
barriers, as it inhibits researchers from validating and comparing different
CDA algorithms conveniently. To this end, we propose OpenCDA, a generalized
framework and tool for developing and testing CDA systems. Specifically,
OpenCDA is composed of three major components: a co-simulation platform with
simulators of different purposes and resolutions, a full-stack cooperative
driving system, and a scenario manager. Through the interactions of these
three components, our framework offers a straightforward way for researchers
to test different CDA algorithms at both levels of traffic and individual
autonomy. More importantly, OpenCDA is highly modularized and installed with
benchmark algorithms and test cases. Users can conveniently replace any
default module with customized algorithms and use other default modules of the
CDA platform to perform evaluations of the effectiveness of new
functionalities in enhancing the overall CDA performance. An example of
platooning implementation is used to illustrate the framework’s capability for
CDA research. The codes of OpenCDA are available in the UCLA Mobility Lab
GitHub page.

##  I INTRODUCTION

By leveraging cutting-edge technologies to circumvent traditional
infrastructure enhancement constraints, Intelligent Transportation Systems
(ITS) are reshaping transportation and have demonstrated a tremendous
potential to boost the transportation system management, operations, safety,
and efficiency. One of the essential sub-fields in ITS is Cooperative Driving
Automation (CDA), which is defined in SAE J3216 [1] and refers to vehicle-
highway automation that uses Machine-to-Machine communication to enable
cooperation among two or more entities (e.g., vehicles, pedestrians,
infrastructure components) with capable communication technologies. By
enabling the status-sharing, intent-sharing, and maneuver cooperation between
entities, the traffic efficiency, energy consumption, and safety of the
driving can be significantly improved [2].

Although CDA has been an active field in recent years, it is still in its
infancy. One of the major barriers to the development of CDA is the high cost
and potential safety issues to conduct field experiments as they usually
require multiple expensive connected automated vehicles (CAVs) and extra-large
testing space [3]. One approach to facilitating experimental research with
minimum cost is to prototype and validate the CDA algorithms in a simulated
environment. However, existing simulation platforms featured with full-stack
software development of autonomous driving provided limited supports for CDA
capabilities. As far as we know, there is no existing open-source (or
commercial) tool dedicated to CDA by featuring both traffic and vehicles with
full CDA vehicle software pipeline. As a result, it becomes very challenging
to find an easy and flexible way for researchers to deploy, validate and
compare the impact of different CDA algorithms on the dynamic driving tasks of
CAVs in simulation. Most of the research uses ad-hoc simulation capabilities
with different qualities, making the algorithmic and functional performance
not comparable between studies.

To overcome such challenges, we introduce OpenCDA, a generalized open-source
framework encapsulated with co-simulation for CDA research. OpenCDA provides a
full-stack CDA software that contains the common self-driving modules composed
of sensing, computation, and actuation capabilities, and cooperative features
as defined in SAE J3216 (e.g., vehicular communication, information sharing,
agreements seeking). OpenCDA is developed purely in Python [4] for fast
prototyping. Built upon these basic modules, OpenCDA supports a range of
common cooperative driving applications, such as platooning, cooperative
perception, cooperative merge, and speed harmonization. More importantly,
OpenCDA offers a scenario database that includes various standard scenarios
for testing of different cooperative driving applications as benchmarks. Users
can easily replace any default modules in OpenCDA with their designs and test
them in the supplied scenarios. If users desire to produce their scenarios,
our framework also provides simple APIs to support such customization. We
select CARLA [5] and SUMO [6] to render the environment, simulate the vehicle
dynamics, and generate the traffic flow. Since our framework is designed with
high flexibility, it can also be extended to integrate additional simulators,
such as communication simulators (ns-3 [7]) and vehicle dynamics simulators
(e.g., CARSim [8]).

The key features of OpenCDA can be summarized as CIFMB:

  * •

Connectivity and Cooperation: OpenCDA supports various levels and categories
of cooperation between CAVs in simulation. This differentiates OpenCDA with
other single vehicle automation tools.

  * •

Integration: OpenCDA integrates CARLA and SUMO together for realistic scene
rendering, vehicle modeling and traffic simulation.

  * •

Full-stack System: OpenCDA provides a full-stack software system that contains
perception, localization, planning, control, and V2X communication modules.

  * •

Modularity: OpenCDA is highly modularized, enabling users to conveniently
replace any default algorithms or protocols with their own customzied design.

  * •

Benchmark: OpenCDA offers benchmark testing scenarios, state-of-the-art
benchmark algorithms for all modules, benchmark testing road maps, and
benchmark evaluation metrics.

The paper is organized as follows. Section II will review existing frameworks
aiming to support cooperative driving automation and different cooperative
driving applications. In section III, we will describe the overall
architecture of OpenCDA and reveal the details of each major component. In
section IV, we will showcase a concrete example of how platooning, one of the
most important applications in CDA, is implemented under our framework.
Afterward, a case study for platooning scenario testings will be introduced.
Section V will present the experiment results using our default guidance
algorithm and compare it with customized algorithms to prove the effectiveness
of our framework.

##  II Related Work

In the past decades, various CDA applications have emerged and imposed
significant impacts on ITS. One of the representative applications is the
Cooperative Adaptive Cruise Control(CACC), which has been studied extensively,
such as [9, 10]. CAVs can form stable strings with short following gaps by
utilizing CACC, improving the stability, safety, comfort, and traffic
performance in terms of throughput and delay [11]. For freeway traffic, the
cooperative merge has been a popular topic as it allows the speed coordination
between mainline vehicles and merging vehicles to create qualified gaps for
safe merging [12]. Speed harmonization also attracts much attention due to its
capability of gradually decreasing upstream traffic speed in a heavily
congested area to reduce the stop-and-go traffic and prevent congestion
formation [13, 14, 15, 16]. Moreover, there are also some CDA applications for
intersection control, including vehicular trajectory control [17], traffic
signal control [18], and joint control of traffic signal and vehicular
trajectories [19].

Although extensive research has been carried out in this field, there are few
open-sourced simulation platforms for CDA. Segata et al. [20] proposes an
extension for Veins [21] to provide the basic platooning capability. Recently,
SUMO [6] integrates the Simpla package for basic platoon formations. Wu et al.
[22] also present a platform for integrating the traffic simulation and
reinforcement learning controllers. However, these platforms only stay at the
level of traffic analysis and fail to support full-stack software development
and testing for CDA, including perception, planning, decision-making, control,
and communication.

##  III Overview of OpenCDA

Figure 1: The overall architecture design of OpenCDA.The full-stack software
of the designed cooperative driving system interacts with simulation tools to
test the system performance in provided scenarios

OpenCDA is a generalized framework integrated with co-simulation for
intelligent and dynamic cooperative driving. It supports various cooperation
between automated vehicles and provides benchmarking scenario database and CDA
algorithms. As Fig. 1 depicts, OpenCDA is composed of three major components –
the simulation tools, cooperative driving automation system built in Python,
and scenario manager.

###  III-A Simulation Tools

CARLA [5] is selected as one of the simulation tools in OpenCDA for automated
driving simulation. CARLA is a free, open-source automated driving simulator
that aims to accelerate the development of new automated driving technologies.
It utilizes Unreal Engine [23] to produce high-quality scene rendering,
realistic physics, and basic sensor modeling. The CARLA platform defines a
versatile simulation API that users and developers can control over all the
elements of the simulation from sensor placement to prototyping and testing
the perception, planning, and control algorithms. A key feature of CARLA is
its scalable architecture, following a server-multi-client approach to allow
for the distribution of computation into multiple nodes. The server will keep
updating the physics of the environment, and the client-side will be
controlled by users through the CARLA API. Our cooperative driving system is
embedded with CARLA API to perform cooperative dynamic driving tasks and
evaluate the vehicle performance under the individual autonomy level.

However, CARLA lacks the manageability of large volumes of traffic and fails
to represent realistic traffic behavior, thus not ideal for creating a complex
traffic environment for CDA testing [24]. Additionally, CDA’s potential in
improving overall traffic system performance is also of interest. Therefore,
SUMO [6], an open-source traffic/driver behavior simulator, is involved in the
framework because of its capability of handling large-scale and realistic
traffic flows. SUMO has dynamic modeling for each vehicle and allows users to
quickly construct customized traffic scenarios through the TraCI (Traffic
Control Interface) API. Note that even though CARLA provides a traffic manager
module for generating background traffic, they are based on simplistic
behavior rules, which cannot represent real driver behavior.

Further, SUMO can generate traffic using different well-accepted driver models
(e.g., Intelligent Driver Model [25]), and it is more convenient to use SUMO
to take in naturalistic trajectory data (e.g., NGSIM [26]) and use them
directly as the surrounding environment for CDA testing. Since CARLA has
developed a co-simulation feature with SUMO, we provide the option for
researchers to test their algorithms and protocols solely using CARLA, SUMO,
or employing them together. When the co-simulation is activated, SUMO will
control the traffic and transform the background human-driven vehicles into
the CARLA server, and the CAVs controlled by CARLA will react with the traffic
to finish their driving tasks. By distributing the tasks to both CARLA and
SUMO, the evaluation of designed algorithms or protocols can be processed at
both individual level and traffic level.

Note that we do not recommend using the full co-simulation in OpenCDA in all
testing tasks. The users need to understand the evaluation needs (e.g.,
vehicular or traffic behavior) and then select corresponding tools. For
example, if only traffic performance is to be understood, there is no point to
conduct a fully automated driving simulation and investigate the detailed
level of questions such as how sensor outputs and fusion impact traffic
performance, because they are not at the same level of analysis. Traffic
performance is mostly derived directly from driver/vehicle behavior (as a
result of internal mechanisms or algorithms). To this end, in OpenCDA, our
benchmark algorithms, to be discussed in the next section, are implemented in
both SUMO and CARLA (in a consistent manner, but with some differences due to
the fundamental differences between the two simulators in controlling
vehicles), so analysis at any level is possible and consistent.

The OpenCDA framework can also be flexibly enhanced with additional tools,
such as ns-3 or other customized models for wireless communication. However,
we do not consider extremely complex integration of different tools as
necessary for the simple reason that no models can fully replicate the real
world and models should be built only to meet the testing needs of specific
purposes. For example, when evaluating if a certain level of communication
packet drops impact traffic stability, using a full ns-3 tool in the
simulation loop will not only significantly slow down the simulation but also
does not present many benefits as compared to using only simple Monte Carlo
simulation [27].

###  III-B Cooperative Driving System

OpenCDA encapsulates the cooperative driving system with CARLA and SUMO via
simple API to operate cooperative driving tasks. Sensors mounted on CAVs in
CARLA will collect raw sensing information from the simulation environment and
proceed to the sensing layer of the system. The received information is then
processed by the perception module to perceive the operational environment,
utilizing the plan layer to deliver a series of actions, and finally, spawn
the control commands through the actuation layer. The actuation will be sent
back to CARLA actors to execute the movement at each simulation time step. It
is interesting to note that such architecture is also suitable for single-
vehicle intelligence development when there is no cooperation needed. This
means that the OpenCDA tool can simulate mixed traffic of human-driven,
connectivity, and automation.

The cooperation between automated vehicles is activated at the application
layer. In this layer, each CAV will exchange status information (e.g., vehicle
position, signal phasing, and timing), intent information (e.g., perceived
sensing context, planned vehicle trajectory) through the V2X stack, and seek
agreement on a plan (e.g., forming a platoon). Based on different agreements,
there will be corresponding protocols that potentially modify the default
settings of the layers. For instance, when the cooperative perception
application is launched, each CAV doesn’t solely utilize its own raw sensing
information to locate dynamic objects but also retrieves and fuses others’
sensing information to achieve multi-modal, cooperative object detection.

One key feature of the OpenCDA framework is modularity. All layers mentioned
above come with default algorithms or protocols, and users can replace the
default ones with their customization without influencing others parts by just
applying one line of code. We consider this as a desirable feature because
researchers can utilize the default modules and algorithms to evaluate the
ultimate performance of the entire CDA system and it is also possible for
different groups of researchers to compare the algorithms under the same
framework. Additionally, the default algorithms in OpenCDA applications, such
as cooperative platooning and merge, are also state-of-the-art algorithms that
are qualified to serve as benchmark algorithms. Researchers can compare their
algorithms with the OpenCDA benchmarks to demonstrate the capability and
enhancement of the new algorithms.

###  III-C Scenario Manager

The scenario manager in OpenCDA contains four parts: the scenario
configuration file, scenario initializer, special event trigger, and
evaluation functions.

A scenario is a description of how the view of the world alters to time. In
the context of cooperative driving, it encompasses the information of the
static elements of the world (e.g., road topology, surrounding buildings,
static objects on the road surface), and dynamic elements such as the traffic
flow, traffic signal state, and weather. In OpenCDA, the static elements of a
scenario are defined by the default maps in CARLA map library or customized
maps built by xdor [28] and fbx [29] file. The dynamic elements are controlled
by a yaml [30] file. In the yaml file, users can define the traffic flow for
each lane generated by SUMO, including traffic volume and desire speed. If
background traffic produced by CARLA is also introduced, then the number and
spawn positions of these vehicles and the CARLA traffic manager’s settings
also need to be recorded. As mentioned before, our framework comes with an
existing scenario database that stores predefined scenario testings, but users
are welcome to contribute their customized testings to the database.

After the yaml file is created, a configuration loader will load the file into
a Python dictionary. This dictionary will guide the simulation environment
construction and determine the major driving tasks for the target CAVs. A
driving task composed of the starting locations and destinations of the CAVs,
and the intermediate locations to reach.

When the CAVs are executing driving tasks, special events may be triggered. A
good example of such events is that a human-driven vehicle in front of a
platoon suddenly decelerates or stops. These special events are normally
triggered by certain time-step or the positions of CAVs to test the
performance of the cooperative driving system in the corner cases.

A driving task is regarded as finished when the CAV arrives at the
destination. Then the evaluation is carried out to measure the performance of
the whole driving period at an individual level with CARLA and at traffic
level with SUMO.

###  III-D Software Class Design and Logic Flow

To better demonstrate how the interaction of the three major components of
OpenCDA are realized, in this section, we will describe the major software
class components and the procedure of simulation information transferring
between these components by utilizing an example CDA application – vehicle
platooning.

As Fig. 2 depicts, we apply hierarchical class management to control the
simulation neatly. The most fundamental class is called VehicleManager, which
contains the full-stack CDA and Automated Driving System(ADS) benchmark
software for a single CAV. The class member PerceptionManager and
LocalizationManager are responsible for perceiving the surrounding environment
and localize the ego vehicle. The BehaviorAgent plans the driving behavior
(e.g. car following, overtaking, lane changing behavior) for the single CAV,
and the attribute LocalPlanner in BehaviorAgent will generate the trajectory
using cubic spline interpolation and basic vehicle kinematics:

$\displaystyle
y_{t}=\alpha_{0}+\alpha_{1}x_{t}+\alpha_{2}x_{t}^{2}+\alpha_{3}x_{t}^{3}$ (1)
$\displaystyle
a_{t}=\begin{cases}\min(\frac{v_{target}-v_{t}}{\Delta{t}},a^{1}),&\text{if
}v_{target}\geq v_{t}\\\
\max(\frac{v_{target}-v_{t}}{\Delta{t}},a^{2}),&\text{otherwise}\end{cases}$
(2) $\displaystyle x_{t}=v_{t-1}\Delta{t}+\frac{a_{t-1}\Delta{t^{2}}}{2}$ (3)
$\displaystyle v_{t}=v_{t-1}+a_{t-1}\Delta{t}$ (4)

Figure 2: Simplified class diagram of platooning. Note we only exhibits
partial design here.

where $x_{t}\text{,}\leavevmode\nobreak\ y_{t}$ are the planned x and y
coordinates of the vehicle at time step $t$,
$\alpha_{0},\alpha_{1},\alpha_{2}$ are the coefficients of cubic polynomial,
$a_{t}$ is the desired acceleration at the time step $t$, $a^{1},a^{2}$ are
the comfort-related acceleration and deceleration, $\Delta{t}$ is the time
resolution, i.e., simulation step , $v_{target},v_{t}$ are the final target
speed and desired speed at time step $t$. This produced trajectory will be
delivered to ControlManager to generate the throttle, brake, and steering
control commands. The V2XManager will send and receive the packets (currently
regarded as lossless transfer) generated by the components mentioned above to
other CAVs for cooperative driving applications.

Fig. 3 shows the logic flow of the simulation during run time. To run a
scenario test, the users are required to create a yaml file based on the
template that OpenCDA provides to configure the settings of CARLA server
(e.g., synchronous mode versus asynchronous mode), the specifications of the
traffic flow (e.g., the number of human drive vehicles, spawn positions), and
the parameters of each Connected Automated Vehicle (e.g., sensor parameters,
detection model selection, target speed). Subsequently, the ScenarionManager
will load the configuration file, retrieve the necessary parameters, and
deliver them to the CARLA server to settle the simulation environment,
generate traffic flow, and create the VehicleManager for each CAV.

After the server updates the information given by ScenarionManager, the
sensors mounted at each CAV will collect the surrounding environment as well
as the ego vehicle information (e.g., 3D LiDAR points, GNSS data) and share
those through V2XManager. If the upstream cooperative application is
activated, CoopPerceptionManager and CoopLocalizationManager will be utilized
to fuse all contexts obtained from other CAVs for object detection and
localization. Otherwise, the vehicle will switch to the default
PerceptionManager and LocalizationManager, which do not employ shared data.
The processed sensing information (i.e., object 3D pose, ego position) is
delivered to the downstream modules for planning. Similarly, the CAV will
select cooperative strategies to make decisions if corresponding applications
are activated; otherwise, the origin BehaviorAgent and TrajecotryPlanner will
plan the behavior and generate a smooth trajectory, which is passed to the
ControlManager to output the final control commands. The CARLA server will
apply these commands on the corresponding vehicles, execute a single
simulation step, and return the updated information to the VehicleManager for
the next round of simulation.

It is obvious that the design of the logic flow enhances the flexibility and
modularity of OpenCDA as users are capable of choosing the level of
cooperation by just modifying the activation indicator. When the simulation is
terminated, the embedded evaluation toolboxes will assess the driving
performance. We provide default performance measurement for various modules,
including perception (e.g., mean average precision of the 3D bounding box
detection), localization(e.g. error between estimated and true ego-position),
planning (e.g., the smoothness of the planned trajectory), control(e.g,
tracking error) and safety (e.g., hazard frequency). If users demand any
evaluation measurements that are out of the default scope, they can build
customized metrics following the predefined template, which is another key
advantage of OpenCDA.

Figure 3: Logic flow of the simulation process in OpenCDA.

##  IV Experiment Setup and Evaluation Measurement

To prove the effectiveness of OpenCDA, in this section we continue with an
example of vehicle platooning. Our platooning benchmark includes four parts –
the rule-based platooning protocol and algorithms, a customized map with a
long freeway basic and merge segment as Fig. 5 presents, several designed
testing scenarios, and evaluation metrics. Note that we use such customized
map because it leaves enough distance for vehicles to reach high target speed
and perform various cooperative maneuvers. For all the experiments conducted,
we set the simulation time step as 0.05 second, which means the update
frequency of the CARLA server and SUMO is 20Hz.

###  IV-A Platooning Protocol Design

As Fig. 2 shows, in the platooning application, all CAVs in the same platoon
will be managed by the PlatoonManager through a pre-defined protocol. Fig. 4
displays the default platooning protocol in OpenCDA. Overall, the driving task
in a platoon can be divided into different sub-tasks, and platoon members have
various driving modes based on the current platooning status.

When the platooning application is activated, the leading vehicle of the
existing platoon will keep listening to the joining requests from CAVs through
V2XManager. If no such requests are received, the whole platoon will keep
moving forward steadily while the leading vehicle will stay in the leader
drive mode, in which the vehicle shares a similar behavior pattern with CAVs
outside a platoon except overtaking is forbidden. Meanwhile, if the
cooperative perception application is also activated, each platoon member will
also share its raw sensing information (e.g., camera RGB images, 3d lidar
points) and processed sensing information (e.g., detected objects, calibrated
vehicle position) retrieved from PerceptionManager with the leading vehicle
for a better perception.

When there is no joining request, the following vehicles in the platoon will
enter the maintaining mode, in which the driving task is defined as adjusting
the velocity smoothly to keep a constant inter-vehicular time gap to the
preceding members. To accomplish such tasks, the members need to receive some
of the preceding vehicle’s trajectory (e.g., leader, immediate predecessor)
from V2XManager to assist the LocalPlanner creating the trajectories, as shown
below.

$\displaystyle
pos_{j}^{t}=\frac{pos_{j-1}^{t}-L_{j-1}+pos_{j}^{t-\Delta{t}}\times
gap/\Delta{t}}{1+gap/\Delta{t}}$ (5) $\displaystyle
v_{j}^{t}=\frac{||{pos_{j}^{t}-pos_{j}^{t-\Delta{t}}}||}{\Delta{t}}$ (6)

where $pos_{j}^{t}$, $pos_{j-1}^{t}$ are the position of vehicle $j$ and its
proceeding vehicle $j-1$ at time step $t$, $L_{j-1}$ is the length of vehicle
$j-1$, $\Delta{t}$ is the time resolution i.e, simulation step, $gap$ is the
desired inter-vehicular time gap, and $v_{j}^{t}$ is the desired speed of the
$j$th vehicle at time step $t$. In this example, the platooning algorithm only
considers the planned trajectory of the immediate preceding vehicle.

If the platoon receives a joining request, the leading vehicle will exchange
destination, current position, and planned routes with the requesting CAV to
decide whether a feasible joining can be operated. If the request is rejected,
the single CAV will keep searching and stay in single-vehicle driver mode.
Otherwise, the PlatoonManager will choose the best meeting position for the
merging vehicle to join depending on the internal and surrounding information,
and if needed, certain platoon members will adjust their speed to open a gap
for joining. Then the merging vehicle can move to the meeting point and finish
the joining maneuver.

Figure 4: Logic Flow of Platooning Protocol. Figure 5: A snippet of platooning
scenario testing under co-simulation setting. From left to right: Sample
simulation snippet in SUMO, the corresponding view in CARLA where the green
lines and red dots represent planned trajectory path and points respectively,
and the RGB image with 3D lidar points together collected from the sensors
mounted at the CAV. Figure 6: Two different platooning scenario testings.

###  IV-B Platooning Scenario Testing Design

Fig. 5 shows a snippet of the platooning co-simulation testing using the
customized benchmark map of a basic freeway merge segment included in OpenCDA.
This map is formed by a 2800 meters two-lane freeway for the mainstream
traffic and a single-lane on-ramp to allow the merging vehicles to enter the
freeway. In this section, we will exhibit two different platooning testing
scenarios from our database in this benchmark map. Note that all tests are
operated within perception and localization algorithms. We apply yolov5 [31]
for object detection and utilize GNSS/IMU fusion algorithm similar with [32,
33] for localization.

####  IV-B1 Single Lane Platooning

As Fig. 6(a) describes, there is a five-vehicle platoon that keeps driving in
the same lane in this scenario. The objective is to test the platoon’s
stability, which is indicated by the degree of amplified oscillations when the
leading vehicle changes speed dramatically. To meet such a purpose, the
platoon leader will follow a given speed profile to accelerate and decelerate
frequently to identify whether the following members are capable of
maintaining desired inter-vehicular time gap and dampen the speed oscillation.
The OpenCDA provides benchmarking testing scenarios of front vehicle
trajectories, e.g., two types of cycles of testing with distinct speed
profiles. Users can also use their own scenarios for specific purposes by
using the example format.

  * •

In the first cycle, the platoon leader will follow a synthetic speed
trajectory. It drives at 25 m/s for 20 seconds, then accelerates until
reaching the target speed of 30 m/s. The platoon leader will keep this speed
for 20 seconds, then decelerate to reach the initial speed of 25 m/s, and keep
this speed for 20 seconds. There is no traffic flow generated as we aim to
sorely evaluate the platooning protocol in this cycle. Furthermore, the
aggressiveness of the acceleration or deceleration and speed maintaining
duration can be easily modified to divergent levels, and here we just showcase
a single instance.

  * •

In the second cycle, we placed a human-driven vehicle in front of the platoon.
This human-driven vehicle will follow representative speed profiles extracted
from NGSIM data, which is collected from real-world experiments as Fig. 7
displays. The leader demands to have a decent car following behavior, and the
platoon needs to remain stable while the human-driven vehicle radically
adjusts the speed. In such a way, both the car following behaviors of the
platoon leader and the platoon followers will be validated.

Figure 7: Real-world human-driven vehicle speed profile.

####  IV-B2 Cooperative Platoon Joining from Other Lanes

As shown in Fig. 6(b), the mainline has a high-speed traffic flow mixed with
human-driven vehicles managed by SUMO and CAVs controlled by CARLA. When the
single CAV is near the merging area, it will communicate with the mainline
platoon and make a request to join. Once they achieve an agreement, the single
CAV has to finish the merge and join the platoon simultaneously before the
acceleration lane ends. The leader will decide the best merging position and
command certain platoon members to create a gap for the new member.

To demonstrate OpenCDA’s high modularity and extensibility, we further compare
two different algorithms of choosing the best merging position. The first
approach is heuristic-based. The single CAV will choose the vehicle in the
platoon that has the shortest Euclidean distance as the frontal vehicle for
merging. The second method is Genetic Fuzzy System [34], which utilizes fuzzy
logic to decide the best merging position. Different from a heuristic-based
method, it also takes platoon members’ speed and surrounding human-driven
vehicles’ information into consideration.

###  IV-C Evaluation Measurements

As adequate performance measurements are essential in the testing, we also
provide default evaluation metrics in the scenario benchmark. For platooning
application, we assess the performance from safety, stability, and efficiency.

####  IV-C1 Safety

Safety is always the most critical factor for any automated driving system. In
platooning, not only the leading vehicle needs to avoid collisions with
surrounding human-driven vehicles, but also the following members are required
to keep a safe distance from each other. The safety element can be measured
from two perspectives:

  * •

Time-to-Collision: Time-to-Collision(TTC) refers to the time required for two
vehicles to collide if they continue at their present speed and on the same
path. Here we can extract the TTC performance series of each vehicle
throughout the simulation. It is also possible to estimate the average $TTC$
for each platoon member across all simulation time steps to represent overall
safety by the following equation:

$\displaystyle
ATTC=\frac{\sum_{t=1}^{N}\frac{x_{i}^{t}-x_{i-1}^{t}-l}{v_{i}^{t}-v_{i-1}^{t}}}{N}$
(7)

where $x_{i}^{t}$ is the position of vehicle $i$ at time-step $t$,
$x_{i-1}^{t}$ is the position of the preceding vehicle $i$ at time-step $t$,
$l$ is the length of vehicle $i$, $v_{i}^{t},v_{i-1}^{t}$ are the speed of
vehicle $i$ and $i-1$ at time step $t$ and $N$ is the number of simulation
time-steps at which meets the condition $v_{i}^{t}<v_{i-1}^{t}$.

  * •

Hazard frequency: The number of events that $TTC<TTC_{t}$, where $TTC_{t}$ is
the warning threshold of Time-to-Collision to distinguish between safe and
unsafe events. In this experiment, we set it as 2.5 second, which is suggested
by [35].

####  IV-C2 Stability

The stability of a platoon indicates whether oscillations are amplified from
downstream to upstream vehicles [36]. As it is directly correlated with safety
and energy consumption, proposing corresponding appropriate evaluation
measurements are crucial. In OpenCDA, the following three metrics are used and
users can easily define advanced metrics using the data provided by OpenCDA.

  * •

Inter-vehicular time gap: The time gap between a platoon member and its
proceeding vehicle. The time gap at each simulation step is collected and
plotted, and its mean value and standard deviation across the whole episode
are calculated as well.

  * •

Acceleration The time-series data of acceleration and statistics of the data
(e.g., mean, standard deviation) are calculated to reflect the driving
smoothness of the platoon members.

| Safety | Stability | Efficiency
---|---|---|---
Vehicle id | attc | hf | atg | tg_std | acc_std | tcm | acc_std
0 | NA | 0 | NA | NA | 0.98 | NA | NA
1 | 30.55 | 0 | 0.603 | 0.007 | 0.73 | NA | NA
2 | 30.50 | 0 | 0.602 | 0.003 | 0.65 | NA | NA
3 | 30.43 | 0 | 0.602 | 0.004 | 0.62 | NA | NA
4 | 30.40 | 0 | 0.602 | 0.005 | 0.60 | NA | NA
(a) Single platooning cycle 1

| Safety | Stability | Efficiency
---|---|---|---
Vehicle id | attc | hf | atg | tg_std | acc_std | tcm | acc_std
0 | 32.68 | 0 | NA | NA | 1.42 | NA | NA
1 | 17.1 | 0 | 0.614 | 0.03 | 1.08 | NA | NA
2 | 17.3 | 0 | 0.609 | 0.012 | 0.75 | NA | NA
3 | 18.16 | 0 | 0.608 | 0.007 | 0.55 | NA | NA
4 | 18.92 | 0 | 0.605 | 0.003 | 0.49 | NA | NA
(b) Single platooning cycle 2

| Safety | Stability | Efficiency
---|---|---|---
Vehicle id | attc | hf | atg | tg_std | acc_std | tcm | acc_std
0 | 49.8 | 0 | NA | NA | 0.92 | NA | 0.03
1 | 25.5 | 0 | 0.607 | 0.005 | 0.63 | NA | 0.01
2 | 31.03 | 0 | 0.607 | 0.003 | 0.56 | NA | 0.01
3 | 31.53 | 0 | 0.612 | 0.013 | 1.33 | 13.5 | 2.83
4 | 32.59 | 0 | 0.707 | 0.23 | 0.82 | NA | 1.37
(c) Cooperative merge and platoon join using heuristic method

| Safety | Stability | Efficiency
---|---|---|---
Vehicle id | attc | hf | atg | tg_std | acc_std | tcm | acc_std
0 | 49.8 | 0 | NA | NA | 0.95 | NA | 0.02
1 | 31.40 | 0 | 0.608 | 0.007 | 1.27 | 9.9 | 2.51
2 | 31.24 | 0 | 0.674 | 0.16 | 0.79 | NA | 1.18
3 | 30.14 | 0 | 0.609 | 0.008 | 0.65 | NA | 0.88
4 | 29.9 | 0 | 0.607 | 0.006 | 0.61 | NA | 0.59
(d) Cooperative merge and platoon join using GFS

Table I: Quantitative results of two different scenario tests. The desired
platoon time gap is set to 0.6 second. attc:average time-to-collision(second),
hf:hazard frequency(number of times), atg:average platoon time gap(second),
tg_std:platoon time gap standard deviation(second), tcm: time to complete
maneuver(second)

####  IV-C3 Efficiency

The efficiency refers to the time duration required for platoon joining and
the smoothness of the joining process. It can be evaluated as follows:

  * •

Time to complete the maneuver The time duration starting from the joining
request approved to joining concluded.

  * •

Acceleration The standard deviation of acceleration during the joining
procedure.

  * •

Traffic delay and throughput If SUMO are used and traffic performance is of
interest, overall delay and throughout of traffic are calculated during the
specified simulation period.

[5pt]

Figure 8: The speed, acceleration, time gap and distance gap plotting for each
CAV in the four testing scenarios

##  V Results Analysis

In this section, the results for our benchmark platooning algorithm are
presented and discussed.

###  V-A Single Lane Platooning

Table I (a) presents the average performance of platooning in cycle 1. As we
can see, in spite of the dramatic velocity fluctuation, the platoon members
can still maintain the desired 0.6 second time gap safely with minor
deviations. Similarly, as Table I (b) demonstrates, the leading vehicle is
able to follow the human-driven vehicle safely and smoothly while the whole
platoon can achieve good safety and stability.

Fig. 8 further describes the driving performance at each simulation time step.
For the first cycle, as Fig. 8(a) demonstrates, the platoon followers are able
to keep the designed time gap 0.6s during the whole process, even with the
leading vehicle dramatically increasing and decreasing speeds. When the
platoon leader starts to accelerate suddenly, the platoon members are able to
follow it tightly without any speed-overshooting. When the platoon leader
rapidly steps on the brake, the followers can smoothly decelerate at a
comfortable rate and stay constant time gaps between each other, which
indicates the stability of the platooning. In the real trajectory testing, as
Fig. 4(b) depicts, despite the frequent speed changes of the human-driven
vehicle, the platoon leader is able to follow it safely, and the time gap
between them is around 1.5s. Meanwhile, the platoon member can still keep a
constant time gap of 0.6s even when the front human-driven vehicle rapidly
accelerates or decelerates.

These results of the benchmark algorithms illustrate the whole module pipeline
of the cooperative driving system in our framework is complete and can work
properly for cooperative driving tasks in the simulation environment under
various settings.

###  V-B Cooperative Merge and Join Platoon

Fig. 8 (c) and 8 (d) display the profiles of velocity, acceleration, inter-
vehicular time gap, and distance gap of each of the platoon members during the
scenario testing utilizing two different merging position decision algorithms.
First, the results of these two algorithms are noticeably distinct. The
heuristic-based method chooses the third platoon member as the immediate
proceeding vehicle for joining, while the GFS chooses the leading vehicle.
Second, when the merging CAV operates the cut-in joining using a heuristic-
based method, the time gap between it and the rear member drops under 0.2
seconds, which is potentially dangerous. In contrast, the GFS allows the
merging vehicle to keep the time gap above 0.6 seconds during the whole
joining process, which makes the merging process much safer. Last, the GFS is
more efficient as TableI(e) depicts, it takes 9.9 seconds to end the joining
maneuver while the heuristic-based method needs 13.1 seconds.

In conclusion, the evaluation shows that the GFS is superior to the heuristic-
based method. More importantly, our framework allows efficient and
straightforward method replacement in as simple as one line of code while
maintaining the functionality of the system and the accuracy of other existing
modules. This example perfectly proves the effectiveness of OpenCDA in terms
of validating any customized CDA algorithms.

##  VI Conclusion

In this article, we introduce OpenCDA, a generalized framework and tool for
research and development of Cooperative Driving Automation (CDA). OpenCDA
addresses the gap in the community and is one of the first of its kind – an
easy-to-use fast-prototyping tool that has a full-stack CDA software platform
that covers perception, communication, planning, and control, to enable
researchers to evaluate and compare new CDA algorithms and functions with
benchmarks. The six key features of OpenCDA – Connectivity, Integration, Full-
stack System, Modularity, and Benchmark – have been discussed in detail
through the introduction of the OpenCDA architecture, simulation flow, testing
scenarios and processes, and software design. By exploiting a practical
example of the platooning application, we demonstrate that the modular
pipeline in OpenCDA can function properly for CDA applications and the whole
framework is flexible enough for any customization. Last, but not least,
OpenCDA is an evolving project, and we expect that our team at the UCLA
Mobility Lab and interested parties in the community to continuously
contribute to the project with additional CDA applications, testing scenarios,
enhancements to the existing CDA platform, and integration with other tools
for necessary testing purposes.

## References

  * [1] On-Road Automated Driving (ORAD) committee.  Sae j3216 standard: Taxonomy and definitions for terms related to cooperative driving automation for on-road motor vehicles.  In SAE International, 2020.
  * [2] A. Stevens and J. Hopkin.  Benefits and deployment opportunities for vehicle/roadside cooperative its.  In IET and ITS Conference on Road Transport Information and Control (RTIC 2012), pages 1–6, 2012.
  * [3] Nicholas Hyldmar, Yijun He, and Amanda Prorok.  A fleet of miniature cars for experiments in cooperative driving.  In 2019 International Conference on Robotics and Automation (ICRA), pages 3238–3244, 05 2019.
  * [4] G. vanRossum and J. Deboer.  Interactively testing remote servers using the python programming language.  CWI quarterly, 4:283–304, 1991.
  * [5] Alexey Dosovitskiy, German Ros, Felipe Codevilla, Antonio Lopez, and Vladlen Koltun.  CARLA: An open urban driving simulator.  In Proceedings of the 1st Annual Conference on Robot Learning, pages 1–16, 2017.
  * [6] Pablo Alvarez Lopez, Michael Behrisch, Laura Bieker-Walz, Jakob Erdmann, Yun-Pang Flötteröd, Robert Hilbrich, Leonhard Lücken, Johannes Rummel, Peter Wagner, and Evamarie Wießner.  Microscopic traffic simulation using sumo.  In The 21st IEEE International Conference on Intelligent Transportation Systems. IEEE, 2018.
  * [7] George F. Riley and Thomas R. Henderson.  The ns-3 network simulator.  In Klaus Wehrle, Mesut Günes, and James Gross, editors, Modeling and Tools for Network Simulation, pages 15–34. Springer, 2010.
  * [8] Mechanical Simulation .  Carsim, 2021.
  * [9] Liu Hao, Xingan David Kan Lin Xiao, Xiao-Yun Lu Steven E. Shladover, Wouter Schakel Meng Wang, and Bart van Arem.  Using cooperative adaptive cruise control (cacc) to form high-performance vehicle streams.final report.  2018\.
  * [10] S. Shladover, C. Nowakowski, Xiaoyun Lu, and Robert E. Ferlis.  Cooperative adaptive cruise control (cacc) definitions and operating concepts.  2015\.
  * [11] Yi Guo and Jiaqi Ma.  Leveraging existing high-occupancy vehicle lanes for mixed-autonomy traffic management with emerging connected automated vehicle applications.  Transportmetrica A: Transport Science, 16(3):1375–1399, 2020.
  * [12] Jiaqi Ma, Edward Leslie, Amir Ghiasi, and Yi Guo.  Empirical analysis of a freeway bundled connected-and-automated vehicle application using experimental data.  Journal of Transportation Engineering, 146, 04 2020.
  * [13] A. Ghiasi, Jiaqi Ma, Fang Zhou, and Xiaopeng Li.  Speed harmonization algorithm using connected autonomous vehicles.  2017\.
  * [14] Amir Ghiasi, Xiaopeng Li, and Jiaqi Ma.  A mixed traffic speed harmonization model with connected autonomous vehicles.  Transportation Research Part C: Emerging Technologies, 104:210–233, 2019.
  * [15] Jiaqi Ma, Xiaopeng Li, Steven Shladover, Hesham A. Rakha, Xiao-Yun Lu, Ramanujan Jagannathan, and Daniel J. Dailey.  Freeway speed harmonization.  IEEE Transactions on Intelligent Vehicles, 1(1):78–89, 2016.
  * [16] Alireza Talebpour, Hani S. Mahmassani, and Samer H. Hamdar.  Speed harmonization: Evaluation of effectiveness under congested conditions.  Transportation Research Record, 2391(1):69–79, 2013.
  * [17] Fang Zhou, Xiaopeng Li, and Jiaqi Ma.  Parsimonious shooting heuristic for trajectory design of connected automated traffic part i: Theoretical analysis with generalized time geography.  Transportation Research Part B Methodological, 95, 11 2015.
  * [18] Yiheng Feng, Larry Head, Shayan Khoshmagham, and Mehdi Zamanipour.  A real-time adaptive signal control in a connected vehicle environment.  Transportation Research Part C: Emerging Technologies, 55, 01 2015\.
  * [19] Chunhui Yu, Yiheng Feng, Henry X. Liu, Wanjing Ma, and Xiaoguang Yang.  Integrated optimization of traffic signals and vehicle trajectories at isolated urban intersections.  Transportation Research Part B: Methodological, 112:89–112, 2018\.
  * [20] Michele Segata, Stefan Joerer, Bastian Bloessl, Christoph Sommer, Falko Dressler, and Renato Lo Cigno.  Plexe: A platooning extension for veins.  volume 2015, 12 2014.
  * [21] C. Sommer, R. German, and F. Dressler.  Bidirectionally coupled network and road traffic simulation for improved ivc analysis.  IEEE Transactions on Mobile Computing, 10(1):3–15, 2011.
  * [22] Cathy Wu, Aboudy Kreidieh, Kanaad Parvate, Eugene Vinitsky, and Alexandre M Bayen.  Flow: A modular learning framework for autonomy in traffic, 2020.
  * [23] Epic Games.  Unreal engine.
  * [24] C. Olaverri-Monreal, Javier Errea-Moreno, Alberto Díaz-Álvarez, Carlos Biurrun-Quel, Luis Serrano-Arriezu, and Markus Kuba.  Connection of the sumo microscopic traffic simulator and the unity 3d game engine to evaluate v2x communication-based systems.  Sensors (Basel, Switzerland), 18, 2018.
  * [25] Arne Kesting, Martin Treiber, and Dirk Helbing.  Enhanced intelligent driver model to access the impact of driving strategies on traffic capacity.  Philosophical Transactions of the Royal Society A: Mathematical, Physical and Engineering Sciences, 368(1928):4585–4605, 2010.
  * [26] U.S. Department of Transportation Federal Highway Administration.  Next generation simulation (ngsim) vehicle trajectories and supporting data, 2016.
  * [27] Jiaqi Ma, Fang Zhou, Zhitong Huang, Christopher Melson, Rachel James, and Xiaoxiao Zhang.  Hardware-in-the-loop testing of connected and automated vehicle applications: A use case for queue-aware signalized intersection approach and departure.  Transportation Research Record Journal of the Transportation Research Board, 2672, 01 2018.
  * [28] OpenDRIVE.  Opendrive — Wikipedia, the free encyclopedia, 2005.
  * [29] FBX.  Fbx file format — Wikipedia, the free encyclopedia, 2006.
  * [30] YAML.  Yaml — Wikipedia, the free encyclopedia, 2001.
  * [31] Glenn Jocher, Alex Stoken, Jirka Borovec, NanoCode012, ChristopherSTAN, Liu Changyu, Laughing, tkianai, Adam Hogan, lorenzomammana, yxNONG, AlexWang1900, Laurentiu Diaconu, Marc, wanghaoyang0106, ml5ah, Doug, Francisco Ingham, Frederik, Guilhen, Hatovix, Jake Poznanski, Jiacong Fang, Lijun Yu, changyu98, Mingyu Wang, Naman Gupta, Osama Akhtar, PetrDvoracek, and Prashant Rai.  ultralytics/yolov5: v3.1 - Bug Fixes and Performance Improvements, October 2020.
  * [32] Xin Xia, Ehsan Hashemi, Lu Xiong, Amir Khajepour, and Nan Xu.  Autonomous vehicles sideslip angle estimation: Single antenna gnss/imu fusion with observability analysis.  IEEE Internet of Things Journal, 2021.
  * [33] Lu Xiong, Xin Xia, Yishi Lu, Wei Liu, Letian Gao, Shunhui Song, and Zhuoping Yu.  Imu-based automated vehicle body sideslip angle and attitude estimation aided by gnss using parallel adaptive kalman filters.  IEEE Transactions on Vehicular Technology, 69(10):10668–10680, 2020\.
  * [34] Anoop Sathyan, Jiaqi Ma, and Kelly Cohen.  Decentralized cooperative driving automation: A reinforcement learning framework using genetic fuzzy systems.  Transportmetrica B, 07 2021.
  * [35] Francesco Bella and Roberta Russo.  A collision warning system for rear-end collision: a driving simulator study.  Procedia - Social and Behavioral Sciences, 20:676–686, 12 2011\.
  * [36] Gerrit Naus, Rene Vugts, Jeroen Ploeg, M.J.G. Molengraft, and M. Steinbuch.  String-stable cacc design and experimental validation: A frequency-domain approach.  Vehicular Technology, IEEE Transactions on, 59:4268 – 4279, 12 2010\.


# Coupled high-finesse optical Fabry-Perot microcavities

Steffen Gohlke, Thorsten Langerfeld, Andrea Bergschneider, Michael Köhl
Physikalisches Institut, University of Bonn, Wegelerstrasse 8, 53115 Bonn,
Germany

###### Abstract

Optical fiber Fabry-Perot cavities have been a development facilitating the
efficient integration of high-finesse cavities into fiber-optic assemblies. In
this work, we demonstrate coupling of two high-finesse fiber cavities by
direct photon tunneling between them. We detect the coupled mode spectra and
demonstrated the variability of coupling strength and dissipation rates for
different transverse modes. Moreover, we observe very narrow spectral features
resulting from a dynamical generalizaton of electromagnetically-induced
transparency showing that even dissipative systems without metastable states
can feature long-lived coherences.

Coupled dissipative quantum systems are an important subject in fundamental
science and quantum technologies Breuer and Petruccione (2002). From the
fundamental science perspective, they provide a means to study the effects of
open quantum systems and how quantum systems interact with reservoirs. In
quantum technologies, coupling dissipative quantum systems is ubiquitous in
all kind of interface devices, quantum computers, optomechanics, and hybrid
quantum systems. Even though the variety of implementations of coupled
dissipative quantum systems is large, there are a few underlying conceptual
questions shared between the platforms. Firstly, how to control the
dissipation and what effect different levels of dissipation have onto the
quantum states. Secondly, how dissipation can be utilized to control and,
possibly, enhance quantum coherence Müller  _et al._ (2012).

A promising platform to investigate the phenomena discussed above are coupled
optical cavities, i.e., optical resonators between which photons can
coherently tunnel. Coupled cavities Marcuse (1985); Smith  _et al._ (2004);
Naweed  _et al._ (2005); Totsuka  _et al._ (2007); Li  _et al._ (2010);
Stambaugh  _et al._ (2015); Liu  _et al._ (2017) could act as a model system
for open-system control in which one cavity acts as the system and the second
cavity is a dissipation channel with tuneable coupling to the system and
tuneable dissipation rate. Such a system is described by two resonators with
tunable frequencies $\omega_{L}$ and $\omega_{R}$ coupled by a coherent
coupling rate $g$ via the transmission through the center mirror (see Fig. 1
a). Dissipation from the system happens in the form of photon loss for each of
the two resonators with rates $\kappa_{L}$ and $\kappa_{R}$ due to finite
cavity mirror reflection and scattering or absorption inside the respective
resonator which leads to the respective cavity linewidths. Coupled resonators
have been experimentally realized on a number of platforms Liu  _et al._
(2017), among them coupled ring resonators Naweed  _et al._ (2005); Xu  _et
al._ (2006), and terahertz metamaterials Yahiaoui  _et al._ (2018).

In this work, we realize and study two coupled Fabry-Perot resonators based on
the optical fiber cavity technology (see Fig. 1 b). To this end, we have
prepared an arrangement of two optical fibers, which have been micromachined
to have concave surfaces Hunger  _et al._ (2010); Pfeifer  _et al._ (2022) and
optically coated with a high-reflection coating (T= 100 ppm), centered at
$780\text{\,}\mathrm{n}\mathrm{m}$ wavelength. The two fiber end facets are
$D=$300(10)\text{\,}\mathrm{\SIUnitSymbolMicro m}\text{/}$$ separated from
each other. In between the fiber end facets we insert a coupling mirror, which
divides the mode volume into two, approximately equally long resonators. The
coupling is facilitated by the evanescent wave penetrating through the
coupling mirror (see Fig. 1 a). In contrast to previous work with
microcavities Flowers-Jacobs  _et al._ (2012), we utilize a highly reflective
mirror separating the cavities, such that the coupling strength between the
resonators is on par with the input and output coupling of the resonators,
respectively. This coupler between the cavities composes of a free-standing
commercial silicon nitride (SiN) membrane of thickness
$D_{M}=$500\text{\,}\mathrm{n}\mathrm{m}$$ with a highly reflective optical
coating resulting in a total intensity transmission of
$T=$447(52)\text{\,}\mathrm{p}\mathrm{p}\mathrm{m}$$, improving significantly
over previous work even with macroscopic cavities Stambaugh  _et al._ (2015).
Hence, we expect a coupling parameter of $g\approx
2\pi\times$3.38\text{\,}\mathrm{G}\mathrm{H}\mathrm{z}$$.

Figure 1: Coupled-cavity setup. (a) Schematic of two coupled Fabry-Perot
cavities. (b) Photograph of the experimental setup. The two optical fibers and
the center mirror can be moved using shear piezo actuators. (c) Whitelight
interference at $532\text{\,}\mathrm{n}\mathrm{m}$ of the coated SiN membrane.
We extract a symmetric curvature of radius
$r_{C}=$8\text{\,}\mathrm{m}\mathrm{m}$$.

An important criterion when designing the coupled-cavity setup is the
stability of the cavity modes. Fulfilling the requirement becomes more
challenging with increasing finesse of the cavities since the photons take
more round trips inside the resonator and small imperfections add up. In
particular, the alignment and the flatness of the coupling mirror play
decisive roles in making both cavities simultaneously stable. We have measured
the radius of curvature of the left and the right fiber mirror and the coupler
in a white-light interferometer (see Figure 1 c) and find
$r_{L}=$440\text{\,}\mathrm{\SIUnitSymbolMicro m}\text{/}$$,
$r_{R}=$450\text{\,}\mathrm{\SIUnitSymbolMicro m}\text{/}$$, and
$r_{C}=$8\text{\,}\mathrm{m}\mathrm{m}$$. The flatness of the coupling mirror
is strongly influenced by the internal stress of the applied optical coating.
By means of a circular mask with
$200\text{\,}\mathrm{\SIUnitSymbolMicro}\mathrm{m}$ diameter, the optical
coating was applied only to a circular area, leading to a deviation of only
12% between the curvatures in vertical and horizontal direction. Attempts to
deliberately create internal stress in the SiN membrane during its
manufacturing, which would then be compensated when applying the optical
coating, have not led to significantly improved results. The alignment between
cavity and membrane is achieved by the following procedure: we pre-align the
main fiber cavity using two glass ferrules to guide and support the fibers.
Then, one fiber is retracted and the membrane is inserted in between the
ferrules. We align the membrane using a five-axis translation stage relative
to one fiber end facet to form a stable cavity. Subsequently, the retracted
fiber is pushed forward again and we check for stable cavity with the
membrane. Finally, the membrane is glued to one of the glass ferrules (see
Fig. 1 b).

We characterize our coupled-cavity setup by laser spectroscopy both in
reflection and transmission. To this end, we make use of the tunability of the
laser frequency and the tunability of both resonator lengths. This allows us
to control the detunings $\Delta_{p}=\omega_{p}-\omega_{R}$ and
$\Delta_{L}=\omega_{L}-\omega_{R}$ independently, where $\omega_{p}$ is the
probe laser frequency (see Fig. 1 a). We calibrate the linear dependence
between cavity length and resonance frequency using side-band modulation. One
important aspect to consider is that the nature of the fiber cavity, which
comprises of single-mode optical fibers at each end, allows only for an
efficient coupling of the TEM00 mode of the fibers. Higher-order transverse
modes are severely reduced in signal strength at the detector.

Figure 2: (a), (c) Reflection and transmission spectra of the coupled-cavity
system for fixed right cavity length showing an avoided crossing. (b), (d)
Reflection and transmission spectrum at $\Delta_{L}=0$. We observe a mode
splitting of $g=2\pi\times$2.859(2)\text{\,}\mathrm{G}\mathrm{H}\mathrm{z}$$
at a linewidth of $2\pi\times$189(6)\text{\,}\mathrm{M}\mathrm{H}\mathrm{z}$$.

We probe the reflection spectrum by pumping the left cavity with $\omega_{p}$
and detecting the reflected signal. The spectral weight of the signal
amplitude $R$ is proportional to the field intensity in the left cavity.
Figure 2 a shows the reflection of the coupled-cavity system as function of
the probe laser frequency and the left cavity resonance $\omega_{L}$, while
the right cavity resonance frequency $\omega_{R}$ remains fixed. When the
probe laser is resonant with $\omega_{L}$ and the right cavity is far detuned,
a single resonance is observed with a linewidth caused mainly by cavity losses
$\kappa_{L}$. When the left cavity mode becomes resonant with the right cavity
mode, the optical coupling through the center mirror results in an additional
phase shift of the field, which leads to the avoided crossing. The mode
splitting depends on the field transmission through the center mirror and on
the overlap of the spatial modes in the two cavities. At
$\omega_{L}=\omega_{R}$, the combined cavity modes correspond to the symmetric
and anti-symmetric superpositions of the left and right cavity modes and the
reflection signal ideally reduces to half of the initial height. We observe a
reduction to about 0.4 which points towards non-equal losses $\kappa_{L}$ and
$\kappa_{R}$. In addition to the two main branches, Figure 2 a also shows
signatures of weaker modes, which we attribute to higher-order transverse
modes of different longitudinal modes, see below.

In Figure 2 b, we show the transmission spectrum for the same configuration.
The transmitted signal is proportional to the intensity in the right cavity
and therefore shows the highest signal around zero detuning of the two
cavities. This is expected as the right cavity field can be suppressed both by
non-resonant coupling from left to right cavity as well as by non-resonant
incoupling into the left cavity.

By fitting the spectra with the solutions of a numerical model Jayich  _et
al._ (2008), we extract the normal-mode splitting $2g$ with
$g=2\pi\times$2.859(2)\text{\,}\mathrm{G}\mathrm{H}\mathrm{z}$$ and a
linewidth $189(6)\text{\,}\mathrm{M}\mathrm{H}\mathrm{z}$. Both cavity modes
are TEM00 modes as evidenced by their strong coupling to the output fibers.
The measured coupling strength is within 20% of our theoretical expectation,
however, the cavity losses are larger by a factor of approximately 2 as
compared to the specifications of the optical coating. There are a few effects
that contribute to higher losses. We assume equal mirror transmission of the
fiber mirrors as they have been produced in the same fabrication process.
However, the right cavity contains the SiN-membrane which introduces
absorption losses Jayich  _et al._ (2008); Stambaugh  _et al._ (2014). Since
the measured reflection spectra allow for an analysis of both linewidths
$\kappa_{L}$ and $\kappa_{R}$ independently, we can confirm that the cavity
containing the SiN substrate has higher losses by approximately
$990(176)\text{\,}\mathrm{p}\mathrm{p}\mathrm{m}$. This value corresponds to
an imaginary part of the refractive index of $2.6(4)\times 10^{-4}$.
Additionally, non-perfect alignment of the two cavities and the membrane can
lead to different clipping losses for the sub-cavities. Finally, we have
observed a gradual reduction of the cavity finesse over time while operating
the coupled cavities in air, possibly from contamination.

At the avoided crossing, both coupled cavity modes have equal height and
linewidth and, hence, the symmetric and anti-symmetric superposition of left
and right modes have equal losses. This agrees with transfer matrix
calculations revealing that the field amplitude inside the SiN-membrane is the
same for the symmetric and anti-symmetric superposition.

The selection of different transverse modes in each cavity provides us with a
tuning capability for both the coupling strength $g$ and the losses
$\kappa_{i}$ and therefore gives access to coupling-dominated and loss-
dominated regimes. Figure 3 a shows spectra of higher-order transverse modes
in the right cavity that are coupling to the same higher-order transverse mode
in the left cavity. The normal-mode splitting for this case is reduced as the
spatial mode overlap reduces significantly when selecting different transverse
modes in either cavity.

Figure 3: Characterization of the coupled cavities for various coupling
strengths. (a) Reflection spectra for higher-order transversal cavity modes in
the right cavity result in reduced mode splittings, increasing from left to
right. (b) Cavity losses $\kappa_{L}$ and $\kappa_{R}$ vs. fitted cavity-
coupling $g$. While the losses of the left cavity are constant
$\kappa_{L}=2\pi\times$172(10)\text{\,}\mathrm{M}\mathrm{H}\mathrm{z}$$ over
all coupling strengths, varying loss rates in the second cavity are related to
the coupling to different transversal modes. (c) Fitted Lorentzian linewidths
$\gamma$ from horizontal spectral profiles vs. $\Delta_{p}$ follow the
resonance shape of the right cavity and allow for the independent extraction
of $\kappa_{R}$ from its width and the Purcell factor $4g^{2}/(\kappa_{R})$
from the maximum amplitude. (d) Measured cooperativity
$C_{0}=4g^{2}/(\kappa_{L}\kappa_{R})$ for different cavity couplings reaching
over almost three orders of magnitude from weak to strong coupling. The
cooperativity extracted from the fitted parameters $\kappa_{L}$, $\kappa_{R}$
and $g$ and from the fitted amplitude of the horizontal linewidth are in
agreement.

We analyze the two-dimensional spectra containing higher modes by fitting the
vertical profiles to the numerical model in order to extract the coupling
strength $g$ and the dissipation rates $\kappa_{i}$. Far away from the avoided
crossings, where photon coupling to the right cavity is suppressed, the
observed lineshape is governed by the photon losses of the left cavity
$\kappa_{L}$ only. Note that no photons are lost into the right cavity in this
situation. We observe similar linewidths for all measured reflection spectra
coupling to this mode resulting in an average value of
$\kappa_{L}=2\pi\times$172(10)\text{\,}\mathrm{M}\mathrm{H}\mathrm{z}$$ (see
Fig. 3 b, blue dashed line). Approaching the zero crossing, more and more
field is coherently coupled from the left into the right cavity mode. As a
consequence, the losses of the system cross over along with the detuning
$\Delta_{L}$ from purely $\kappa_{L}$ to $\kappa_{R}$ and thus the linewidths
of the two resonances around the avoided crossing vary along $\Delta_{L}$ if
$\kappa_{L}$ and $\kappa_{R}$ are not equal. We fit the spectral profiles with
our numerical model to determine $\Delta_{L}=0$ and obtain $g$ and
$\kappa_{R}$. We measure a number spectra with various couplings strength and
thereby observe a strong variation of extracted $\kappa_{R}$ depending on
which transverse modes we couple to (see Fig. 3 b, yellow data points), which
we attribute to varying clipping losses for the different higher-order
transversal modes in the right cavity.

We confirm this by directly extracting the losses $\kappa_{R}$ from the
reflection spectra in our coupled-cavity system. For this we analyse
horizontal profiles of the reflection spectra which corresponds to choosing a
given detuning between the fixed right cavity resonance and the pump laser
energy $\Delta_{p}$ and then scanning the left cavity length. If $\omega_{p}$
is far detuned from $\omega_{R}$, i. e. $|\Delta_{p}|\gg 0$, we observe a
resonance at $\omega_{L}$ with a linewidth $\gamma$ identical to $\kappa_{L}$,
as only losses through the left mirror play a role. If $\Delta_{p}\approx 0$,
photons inside the left cavity, can also enter the right cavity. This opens an
additional dissipation channel for photons, resulting in an increase of the
linewidth $\gamma$. Along $\Delta_{p}$, this increase in dissipation follows
the resonance shape of the right cavity mode, as we effectively scan over its
resonance and, hence, we can extract $\kappa_{R}$ from this resonance width
(see Fig 3 c). Interestingly, the loss rate $\gamma$ gets enhanced by
$F=4g^{2}/\kappa_{R}$ compared to $\kappa_{L}$ at $\Delta_{p}=\Delta_{L}=0$,
where $F$ is equivalent to the so-called Purcell factor Purcell (1946) for the
loss-dominated regime. For the coupling-dominated regime, the shift of the
resonance and its decrease in signal strength around $\omega_{p}=\omega_{R}$
allows for the extraction of the linewidth only up to a certain point and the
maximum amplitude extracted via a Lorentzian fit. We show the quantitative
result in terms of the cooperativity $C_{0}=4g^{2}/(\kappa_{L}\kappa_{R})$,
which is related to the Purcell factor by $C_{0}=F/\kappa_{L}$. Fig. 3 d shows
the cooperativities realized in our system. Hereby, the extraction of $C_{0}$
from the increase of the linewidth $\gamma$ from the horizontal profiles of
the spectra and from the fitted system parameters $g$, $\kappa_{L}$ and
$\kappa_{R}$ agree well with each other. The results demonstrate that our
system allowed for a variation of the cooperativity over almost three orders
of magnitude from the dissipation-dominated to the coupling-dominated regime.

When two oscillator modes couple with each other and to a coherent common
driving field, interference effects can significantly alter the amplitude and
phase of the field and cause a non-linear response. In particular, the
spectral response can exhibit features much narrower than the response of the
uncoupled systems. In the case of light-matter interactions, this phenomenon
is referred to as electromagnetically-induced transparency and for coupled
cavity modes, it has been termed coupled-resonator induced transparency (CRIT)
Smith  _et al._ (2004); Naweed  _et al._ (2005); Liu  _et al._ (2017). EIT and
related phenomena have been used to control the dispersion and absorption of
light Totsuka  _et al._ (2007); Fleischhauer  _et al._ (2005).

The standard picture of the EIT/CRIT phenomenon is as follows: there are two
dissipative systems with decay rates $\kappa_{R}$ and $\kappa_{L}$,
respectively, and a coherent coupling strength $g$ between them. If the decay
rates are sufficiently different from each other, say
$\kappa_{L}\gg\kappa_{R}$, and the coupling strength $g$ is significantly less
than the faster decay rate $\kappa_{L}$, spectroscopy of the coupled system
will reveal a narrow spectral feature of a width
$4g^{2}/\kappa_{L}\ll\kappa_{L}$. For stationary case, however, none of the
above conditions for the observability of EIT are fulfilled in our system,
since we have $\kappa_{R}\simeq\kappa_{L}$ and $g\gg\kappa_{L},\kappa_{R}$.

We demonstrate here a generalization of the EIT phenomenon, which we create
and control by scanning the resonance frequency of both cavities
simultaneously across each other’s resonance. To this end, we realize an
asymmetric scan of the two cavity lengths in which the cavity resonance
frequencies are scanned into opposite directions and with different rates
while the probe laser frequency is $\omega_{p}$. In Figure 4 a we show the
reflection spectra of the right cavity for different probe laser detunings.
One observes a narrow spectral feature for which the cavity reflection is
increased or decreased depending on the combination of detunings. This feature
results from the dynamical effect of sweeping the two cavities across the
mutual resonance into opposite directions, see Figure 4 b. We compare our
results to numerical simulations of the coupled resonator fields in which we
assume the cavity fields to be in equilibrium since the pump and decay rates
of the cavities are much faster than the rate of change of the relative
detunings. Our results therefore show that one can realize dynamically very
narrow spectral transparencies in the coupled-cavity arrangement despite not
fulfilling the requirements for stationary EIT/CRIT. This is significantly
different from standard EIT physics, in which at least one long-lived state is
required in order to observe the narrow spectral features and could be used,
for example, for optical switching or optical mode selection.

Figure 4: Dynamical coupled-resonator induced transparency. (a) Coupled-cavity
spectrum for different detunings $\Delta_{L}$ and piezo scan of the membrane
$U_{M}$. (b) Detuning of left and right cavity resulting from the membrane
modulation with $U_{M}$. The friction of the mounting ferrule causes the
reduced resonance scan of the right cavity $\Delta_{R}$. (c) Reflection and
its Pound-Drever-Hall signal for off-resonant (left) and on-resonant (right)
coupled-cavity system. The latter is proportional to the phase. (d)
Corresponding phase shift of the reflectance signal.

In Figure 4 c, we show a detailed scan of both the reflectance and the phase
of the reflected field with and without the EIT phenomenon. The two left plots
show the results without the EIT effect and one observes the Lorentzian
lineshape in the reflectance and the dispersive signal for the variation of
the phase. The two right plots show the signal in presence of the EIT
phenomenon and one observes the narrow spectral feature appearing both in
reflectance and phase measurements.

In summary, we have realized and characterized an arrangement of two coupled
high-finesse Fabry-Perot optical cavities. Spectroscopy of the coupled
cavities reveals the avoided crossing of the coupled cavity modes. Given by
the high reflectivity of the cavity and coupling mirrors, we find a coupling
strength of only a couple of GHz, which, in the future, could make the real-
time observation of photon tunnelling between the two cavities possible.
Further, the excellent transverse access to the cavity modes in our
realization could enable the introduction of optical non-linearities, such as
single atoms, into the cavities towards the quantum simulation of lattice
models using interacting photons Hartmann  _et al._ (2006); Hartmann (2016).

This work has been supported by BMBF (project QR.X), Cluster of Excellence
Matter and Light for Quantum Computing (ML4Q) EXC 2004/1–390534769, and
Deutsche Forschungsgemeinschaft (SFB/TR 185, project A2).

## References

  * Breuer and Petruccione (2002) H. P. Breuer and F. Petruccione,  _The theory of open quantum systems_ (Oxford University Press, Great Clarendon Street, 2002).
  * Müller  _et al._ (2012) M. Müller, S. Diehl, G. Pupillo, and P. Zoller, in  _Advances in Atomic, Molecular, and Optical Physics_, Advances In Atomic, Molecular, and Optical Physics, Vol. 61, edited by P. Berman, E. Arimondo, and C. Lin (Academic Press, 2012) pp. 1–80.
  * Marcuse (1985) D. Marcuse, IEEE Journal of quantum electronics QE-21, 1819 (1985).
  * Smith  _et al._ (2004) D. D. Smith, H. Chang, K. A. Fuller, A. Rosenberger, and R. W. Boyd, Physical Review A 69, 063804 (2004).
  * Naweed  _et al._ (2005) A. Naweed, G. Farca, S. I. Shopova, and A. T. Rosenberger, Physical Review A 71, 1 (2005).
  * Totsuka  _et al._ (2007) K. Totsuka, N. Kobayashi, and M. Tomita, Phys. Rev. Lett. 98, 213904 (2007).
  * Li  _et al._ (2010) Q. Li, T. Wang, Y. Su, M. Yan, and M. Qiu, Opt. Express 18, 8367 (2010).
  * Stambaugh  _et al._ (2015) C. Stambaugh, H. Xu, U. Kemiktarak, J. Taylor, and J. Lawall, Annalen der Physik 527, 81 (2015).
  * Liu  _et al._ (2017) Y. C. Liu, B. B. Li, and Y. F. Xiao, Nanophotonics 6, 789 (2017).
  * Xu  _et al._ (2006) Q. Xu, S. Sandhu, M. L. Povinelli, J. Shakya, S. Fan, and M. Lipson, Physical Review Letters 96, 1 (2006).
  * Yahiaoui  _et al._ (2018) R. Yahiaoui, J. A. Burrow, S. M. Mekonen, A. Sarangan, J. Mathews, I. Agha, and T. A. Searles, Physical Review B 97, 1 (2018).
  * Hunger  _et al._ (2010) D. Hunger, T. Steinmetz, Y. Colombe, C. Deutsch, T. W. Hänsch, and J. Reichel, New Journal of Physics 12 (2010), 10.1088/1367-2630/12/6/065038.
  * Pfeifer  _et al._ (2022) H. Pfeifer, L. Ratschbacher, J. Gallego, C. Saavedra, A. Faßbender, A. von Haaren, W. Alt, S. Hofferberth, M. Köhl, S. Linden, and D. Meschede, Applied Physics B: Lasers and Optics 128, 1 (2022).
  * Flowers-Jacobs  _et al._ (2012) N. Flowers-Jacobs, S. Hoch, J. Sankey, A. Kashkanova, A. Jayich, C. Deutsch, J. Reichel, and J. Harris, Applied Physics Letters 101 (2012).
  * Jayich  _et al._ (2008) A. M. Jayich, J. C. Sankey, B. M. Zwickl, C. Yang, J. D. Thompson, S. M. Girvin, A. A. Clerk, F. Marquardt, and J. G. Harris, New Journal of Physics 10 (2008), 10.1088/1367-2630/10/9/095008.
  * Stambaugh  _et al._ (2014) C. Stambaugh, M. Durand, U. Kemiktarak, and J. Lawall, Applied Optics 53, 4930 (2014).
  * Purcell (1946) E. M. Purcell, Phys. Rev. 69, 681 (1946).
  * Fleischhauer  _et al._ (2005) M. Fleischhauer, A. Imamoglu, and J. P. Marangos, Rev. Mod. Phys. 77, 633 (2005).
  * Hartmann  _et al._ (2006) M. J. Hartmann, F. G. S. L. Brandão, and M. B. Plenio, Nature Physics 2, 849 (2006).
  * Hartmann (2016) M. J. Hartmann, Journal of Optics 18, 104005 (2016).