12 | 
2 |
3 | # **CARLOS** - An Open, Modular, and Scalable Simulation Framework for the Development and Testing of Software for C-ITS
4 |
5 | This repository contains CARLOS, the official reference implementation of the open, modular and scalable simulation architecture presented in our [paper](https://ieeexplore.ieee.org/document/10588502). We provide a containerized simulation framework based on the open-source simulator [CARLA](http://carla.org/) and enable a simple integration of custom ROS applications. Find below a brief description of the architecture as well as configurations and instructions for demos of three example use cases:
6 | - [Software Prototyping](./software-prototyping/)
7 | - [Data-Driven Development](./data-driven-development/)
8 | - [Automated Testing](./automated-testing/)
9 |
10 |
11 |
12 |
25 | 
26 |
79 |
80 | Our architecture consists of several *sub-layers* encapsulating different components that serve individual purposes:
81 |
82 | - **Simulation Layer** - simulation core equipped with low-level interfaces and capabilities;
83 | - **Control Layer** - tools for interactions with the simulation core;
84 | - **Application Layer** - software interacting with the simulation layer to achieve certain goals;
85 | - **Storage Layer** - persistent data used for or generated by the simulation layer;
86 | - **Orchestation Layer** - automated configuring, coordinating, and managing of all other layers.
87 |
88 | The *simulation layer* contains the core of a simulation software. It performs the simulation work via its graphics and physics engine, and manages the world state. It comes with low-level interfaces that are often specific to the used software. The *control layer* provides tools for interactions with the simulation core via preferably standardized interfaces and communication protocols. The *application layer* contains application-specific user iterfaces and user-defined functions interacting with the simulation. These computational layers are accompanied by the *storage layer* which can both provide data to the other layers or record data generated by the other layers during simulation. Last, the *orchestration layer* automates the configuring, coordinating, and managing of the other layers.
89 |
90 | The various layers are composed into a microservice architecture, fostering scalability, flexibility, reusability, maintainability. We achieve this through a very modular approach in which all major components are containerized.
91 |
92 | CARLOS is a framework that implements the described architecture. We make use of already established software, especially the [CARLA simulator](http://carla.org//). Some additional components from the rich CARLA ecosystem are crucial to our framework and available as specified GitHub forks. We extended these repositories by additional GitHub CI workflows to generate Docker images built with [docker-ros](https://github.com/ika-rwth-aachen/docker-ros). This approach enables an automatic and continual building of up-to-date container images with recent versions of, e.g., ROS, Python, and Ubuntu.
93 |
94 | ### Simulation Core: [***carla-simulator***](https://github.com/ika-rwth-aachen/carla-simulator)
95 |
96 | 
99 | 
108 | 
111 | 
121 | 
124 | 
2 |
3 | # Use Case: *Automated testing*
4 |
5 | >[!NOTE]
6 | > **Background**: In the *automated testing* demo, simulation is considered to systematically evaluate a large number of defined tests, potentially within the safety assurance process. A specific test configuration may encompass both a concrete scenario and well-defined test metrics for evaluation. Thus, a direct interface to a standardized scenario database is favorable, and custom pass-fail criteria need to be configurable to deduce objective test results. Scalability drastically improves efficiency when simulating multiple test configurations. Moreover, embedding the simulation architecture in a CI process further accelerates the entire safety assurance.
7 |
8 | The subsequent demonstration showcases *automated testing* and specifically addresses the following requirements:
9 | - predefined scenario metrics and **automatic evaluation**
10 | - automation and **scalability**
11 | - CI integration with **GitHub actions and workflows**
12 |
13 | ## Getting Started
14 |
15 | > [!IMPORTANT]
16 | > Make sure that all [system requirements](../utils/requirements.md) are fulfilled.
17 | > Additionally, the CI related part of this demo requires a [self-hosted GitHub Runner](https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners) to execute scenarios within a [GitHub workflow](https://docs.github.com/en/actions/using-workflows/about-workflows). The specific requirements for such a runner are listed [below](#self-hosted-github-runner).
18 |
19 | This demo aims to automatically evaluate predefined test scenarios. For this purpose, a test catalog can be defined using OpenSCENARIO files as contained in the [scenarios](../utils/scenarios) folder. These scenarios can be simulated and evaluated using the [carla-scenario-runner](https://github.com/ika-rwth-aachen/carla-scenario-runner). Thus, a basic [docker-compose template](../.github/actions/evaluate-scenario/files/template.yml) only includes the `carla-server` and a `carla-scenario-runner` Docker service. So, in general, the demo enables the efficient execution of multiple scenario-based tests with CARLA, both in local environments and within an automated GitHub CI process.
20 |
21 | ### Manual Testing Pipeline
22 |
23 | In your local environment, you can evaluate multiple scenarios directly, using the provided [run-demo.sh](../run-demo.sh) script:
24 |
25 | ```bash
26 | # carlos$
27 | ./run-demo.sh automated-testing
28 | ```
29 | This executes the [evaluate-scenarios.sh](./evaluate-scenarios.sh) script with default settings. You can also run this script directly and provide custom overrides to the default values by using specific environment variables, flags and arguments. For a detailed overview, please check the script or run:
30 | ```bash
31 | # carlos/automated-testing$
32 | ./evaluate-scenarios.sh -h
33 | ```
34 | The script sequentially evaluates all scenario files in the selected folder. After each scenario run, a detailed evaluation based on the criteria specified in the scenario is presented. An example is shown below.
35 |
36 | 
2 |
3 | # Use Case: *Data-Driven Development*
4 |
5 | >[!NOTE]
6 | > **Background**: The *data-driven development* use case covers development processes using large amounts of data, which are not effectively obtainable in real-world settings, thus motivating simulations. For many applications, simulative data can be sufficiently accurate to be integrated into the data-driven development process. This includes training data for machine learning algorithms but also closed-loop reinforcement learning. Potentially interesting data includes raw sensor but also dynamic vehicle data in a wide variety at large scale. Simulations additionally enable data generation beyond the physical limits of vehicle dynamics or sensor configurations. To accumulate large amounts of data, relevant simulation parameters can be automatically sampled along different dimensions. Subsequently, automation and parallelization empower a cost-effective execution of multiple simulations, especially when using already established orchestration tools.
7 |
8 | The subsequent demonstration showcases rapid *data driven development* and specifically addresses the following requirements:
9 | - high simulation **fidelity**
10 | - **flexibility** and containerization
11 | - automation and **scalability**
12 |
13 | ## Getting Started
14 |
15 | ### Requirements and Installation
16 | > [!IMPORTANT]
17 | > Make sure that all [system requirements](../utils/requirements.md) are fulfilled.
18 | > Additionally, a Python installation is required on the host for this use case. We recommend using [conda](https://docs.conda.io/projects/conda/en/stable/index.html).
19 |
20 | Install and activate the conda environment:
21 |
22 | ```bash
23 | conda env create -f env/environment.yml
24 | conda activate carlos_data_driven_development
25 | ```
26 |
27 | Alternatively, you can also use Pip:
28 |
29 | ```bash
30 | pip install -r env/requirements.txt
31 | ```
32 |
33 | In the initial demo [software-prototyping](../software-prototyping), we demonstrated the integration of a Function Under Test (FUT) with CARLOS, exploring its capabilities through practical experimentation. While these tests validated the general functionality of our image segmentation module, it became clear that there is considerable potential to improve its performance. Given that this module, like many AD functions, relies heavily on machine learning models trained with specific datasets, the quality and quantity of this training data are crucial.
34 |
35 | ### Permutation-based Data Generation
36 |
37 | Given that the specific nature of the data is less critical, the main objective is to generate as much and diverse data as possible. This can be effectively achieved through permutations of the simulation parameters, ensuring both quantity and diversity in the generated dataset.
38 |
39 | Run the demo for permutation-based data generation:
40 | ```bash
41 | # carlos/data-driven-development$
42 | python ./data_generation.py --config config/data-driven-development-demo-permutation-execution.yml
43 | ```
44 |
45 | or use the top-level `run-demo.sh` script:
46 | ```bash
47 | # carlos$
48 | ./run-demo.sh data-driven-development
49 | ```
50 |
51 | Data is generated by creating all possible permutations from a set of configuration parameters, managed through a YAML configuration file. This results in different simulation runs in several parameter dimensions, which are simulated in sequence. A comprehensive [example configuration](./config/data-driven-development-demo-permutation-execution.yml) is provided within the [config](./config/) folder. While the current implementation is limited to the settings specified [below](#configuration-table), the provided code is modular and can be easily customized to fit your requirements.
52 |
53 | ```yaml
54 | run_settings:
55 | num_executions: 1
56 | permutation_settings:
57 | sensors_file:
58 | - ./config/sensors/rgb_segmentation_camera.json
59 | spawn_point:
60 | - "1"
61 | - "2"
62 | - "3"
63 | town:
64 | - Town01
65 | - Town10HD
66 | vehicle_occupancy:
67 | - "0.5"
68 | walker_number:
69 | - "50"
70 | weather:
71 | - ClearSunset
72 | - WetCloudyNoon
73 | ```
74 |
75 | This exemplary demo configures 12 different simulation runs, by applying permutations in the CARLA town, the weather settings and the initial spawning point of the ego vehicle. All simulations run for a maximum simulation time of 60s and all relevant image segmentation data topics are recorded in dedicated ROS bags.
76 |
77 | Thus, data generation at large scale becomes possible and helps developers to achieve diverse and useful data for any application.
78 |
79 | ### Scenario-based Data Generation
80 |
81 | Assuming we improved our model, we are now aiming to evaluate its performance in targeted, real-world scenarios. Hence, we need to generate data in such concrete scenarios, for which the scenario-based data generation feature can be utilized. In this example, we demonstrate how a list of multiple OpenSCENARIO files can be integrated into the data generation pipeline as well to generate data under those specific conditions.
82 |
83 | ```bash
84 | # carlos/data-driven-development$
85 | python ./data_generation.py --config data-driven-development-demo-scenario-execution.yml
86 | ```
87 |
88 | All scenarios are executed sequentially and data is generated analogous to above. The respective configuration file contains mainly a list to specific predefined OpenSCENARIO files, but additionally enables variation in the sensors file:
89 | ```yaml
90 | run_settings:
91 | num_executions: 1
92 | scenario_settings:
93 | scenario_file:
94 | - ../utils/scenarios/town01.xosc
95 | - ../utils/scenarios/town10.xosc
96 | sensors_file:
97 | - ./config/sensors/rgb_segmentation_camera.json
98 | ```
99 |
100 | Following on that initial scenario-based simulation approach, we focus more on the automatic execution and evaluation of scenarios at large scale in the third, [automatic testing demo](../automated-testing/README.md). In addition, a full integration into a CI workflow is provided.
101 |
102 | ### Record Your Own Data
103 |
104 | Follow these steps to record your own data:
105 |
106 | 1. Specify [sensor configuration file(s)](https://carla.readthedocs.io/projects/ros-bridge/en/latest/carla_spawn_objects/#spawning-sensors) to provide sensor data within ROS.
107 | 2. Adjust the parameters in the data pipeline configuration file. A full list of supported parameters is given [below](#configuration-parameters).
108 | 3. Start the pipeline with `./data_generation.py --config 
2 |
3 | # Use Case: *Software Prototyping*
4 |
5 | >[!NOTE]
6 | > **Background**: The *software prototyping* use case addresses the initial development phase of an automated driving function, where developers aim for simple and quick experimenting. It focuses on the flawless integrability of the component under test and assesses the general operability within the overall system. An early integration of different modules facilitates the harmonization of interfaces, which is particularly important when combining modules from different development teams. In many cases, a single example scenario is sufficient to carry out these initial tests. However, all necessary data must already be provided. For many applications, this data may include sensor data such as camera images and lidar point clouds, which is why a high fidelity simulation software such as CARLA may already be needed.
7 |
8 | The subsequent demonstration showcases *software prototyping* and specifically addresses the following requirements:
9 | - Availability of **comprehensive simulation data** in customizable data formats.
10 | - Ability to easily attach custom **Robot Operating System** (ROS)-based functions to the simulation and its provided data.
11 | - Isolation of custom ROS functions and the simulation software through **containerization**.
12 |
13 | ## Getting Started
14 |
15 | > [!IMPORTANT]
16 | > Make sure that all [system requirements](../utils/requirements.md) are fulfilled.
17 |
18 | Directly start the use case demonstration using the top-level `run-demo.sh` script:
19 |
20 | ```bash
21 | ./run-demo.sh software-prototyping
22 | ```
23 |
24 | This example demonstrates a basic CARLA simulation in tandem with the widely used Robot Operations System ([ROS](https://www.ros.org/)). We only cover ROS 2 with this demo. In addition to a CARLA simulation core, a ROS bridge enables communication between CARLA and ROS by translating simulation outputs (e.g. sensor data) to ROS topics. In addition, RViz is used as a visualization component.
25 |
26 | Specifically, there are three main components used in the `software-prototyping` demo:
27 | - [carla-server](https://github.com/ika-rwth-aachen/carla-simulator)
28 | - [carla-ros-bridge](https://github.com/ika-rwth-aachen/carla-ros-bridge)
29 | - [ros-monitoring](https://github.com/ika-rwth-aachen/carlos/blob/main/utils/carla-essentials/README.md#ros-monitoring)
30 | - A containerized image segmentation ROS node that serves as an example on how to attached a custom function to the simulation.
31 |
32 | > [!NOTE]
33 | > A detailed description of the individual components can be found in [components guide](../utils/carla-essentials/README.md).
34 |
35 | ### Quick Start
36 | After starting the `software-prototyping` demo, a CARLA GUI opens up where you can look around using WASD, holding the left or right mouse button and moving the mouse in the desired direction.
37 |
38 | After a short initialization phase, a second window shows up with RViz and a variety of raw sensor data available in ROS. Multiple RGB cameras, a depth and semantic camera, as well as a lidar sensor are attached to a vehicle, visualizing the environment in rich detail.
39 |
40 | The vehicle itself is controlled by the official [carla_ad_agent](https://github.com/carla-simulator/ros-bridge/tree/master/carla_ad_agent) package. However, you can also override the controls using the manual control PyGame window. After hitting B the manual transmission mode is enabled and allows you to drive the vehicle using WASD.
41 |
42 |
43 | 
](../images/tutorial-dynamic-weather.png)
132 |
133 | This example script changes the weather settings of the CARLA server dynamically. It's a simple example for an interaction between the CARLA server and a Python client communicating over two separate Docker containers. The processes can be stopped using CTRL+C.
134 |
135 | The running `carla-server` and `carla-client` containers can be stopped by terminating the Docker Compose setup with CTRL+C in the first terminal. In addition, remove the stopped containers with
136 | ```bash
137 | # stops all specified services and removes their containers completely
138 | docker compose down
139 | ```
140 |
141 | ### CARLA Server + ROS 2
142 |
143 | After observing the CARLA server, we investigate some additional Docker Compose services to bridge information into the ROS 2 world.
144 |
145 | The following command launches all defined services from `docker-compose.yml` file. In addition to the previous container, it launches a `carla-ros-bridge`, and a `ros-monitoring` container. A comprehensive overview about all available Docker services can be found in the [components guide](./components.md).
146 |
147 | ```bash
148 | # launch all services defined in docker-compose.yml
149 | docker compose up
150 | ```
151 |
152 | This mainly starts a CARLA server GUI and an `rviz` window. The `carla-ros-bridge` container an ego vehicle at a random positions with various sensors, including RGB, depth and segmentation cameras, but also lidar and radar sensors. All sensor data is published as `ROS 2` topic and is visualized using RViz in the `ros-monitoring` container.
153 |
154 | Check out the `rviz` setup to get familiar with the simulation setup and all available `ROS 2` topics. You should be seeing something like this:
155 |
156 | [
](../images/tutorial-rviz-overview.png)
157 |
158 | > [!TIP]
159 | > Feel free to observe the available topics within `rviz` or change the [sensors.json](../software-prototyping/sensors.json) file within the container to customize additional sensors.
160 |
161 | Within this tutorial, the `carla-ros-bridge` container offers another GUI, enabling direct control of the ego vehicle in the simulation. A PyGame window allows to drive the vehicle around with the WASD keys or toggling the autopilot with P. While driving around, have a look in RViz to capture the generated sensor data. The setup should look similar to this:
162 |
163 | [
](../images/tutorial-pygame.png)
164 |
165 |
166 | The entire Docker Compose setup including all running containers can be stopped with CTRL+C and removed with
167 | ```bash
168 | # stops all specified services and removes their containers completely
169 | docker compose down
170 |
171 | # restricts X server access again
172 | xhost -local:
173 | ```
174 |
--------------------------------------------------------------------------------
/utils/tutorial/config.rviz:
--------------------------------------------------------------------------------
1 | Panels:
2 | - Class: rviz_common/Displays
3 | Help Height: 0
4 | Name: Displays
5 | Property Tree Widget:
6 | Expanded: ~
7 | Splitter Ratio: 0.5354107618331909
8 | Tree Height: 301
9 | - Class: rviz_common/Selection
10 | Name: Selection
11 | - Class: rviz_common/Tool Properties
12 | Expanded:
13 | - /2D Pose Estimate1
14 | - /Publish Point1
15 | Name: Tool Properties
16 | Splitter Ratio: 0.5886790156364441
17 | - Class: rviz_common/Views
18 | Expanded:
19 | - /Current View1
20 | Name: Views
21 | Splitter Ratio: 0.5
22 | - Class: rviz_common/Views
23 | Expanded:
24 | - /Current View1
25 | Name: Views
26 | Splitter Ratio: 0.5
27 | - Class: rviz_carla_plugin/CarlaControl
28 | Name: CarlaControl
29 | Visualization Manager:
30 | Class: ""
31 | Displays:
32 | - Class: rviz_default_plugins/Image
33 | Enabled: true
34 | Max Value: 1
35 | Median window: 5
36 | Min Value: 0
37 | Name: Orbit
38 | Normalize Range: true
39 | Topic:
40 | Depth: 5
41 | Durability Policy: Volatile
42 | History Policy: Keep Last
43 | Reliability Policy: Reliable
44 | Value: /carla/ego_vehicle/rgb_view/image
45 | Value: true
46 | - Class: rviz_default_plugins/MarkerArray
47 | Enabled: true
48 | Name: MarkerArray
49 | Namespaces:
50 | "": true
51 | Topic:
52 | Depth: 5
53 | Durability Policy: Volatile
54 | History Policy: Keep Last
55 | Reliability Policy: Reliable
56 | Value: /carla/markers
57 | Value: true
58 | - Class: rviz_default_plugins/Image
59 | Enabled: true
60 | Max Value: 1
61 | Median window: 5
62 | Min Value: 0
63 | Name: RGB
64 | Normalize Range: true
65 | Topic:
66 | Depth: 5
67 | Durability Policy: Volatile
68 | History Policy: Keep Last
69 | Reliability Policy: Reliable
70 | Value: /carla/ego_vehicle/rgb_front/image
71 | Value: true
72 | - Class: rviz_default_plugins/Image
73 | Enabled: true
74 | Max Value: 1
75 | Median window: 5
76 | Min Value: 0
77 | Name: Depth
78 | Normalize Range: true
79 | Topic:
80 | Depth: 5
81 | Durability Policy: Volatile
82 | History Policy: Keep Last
83 | Reliability Policy: Reliable
84 | Value: /carla/ego_vehicle/depth_front/image
85 | Value: true
86 | - Class: rviz_default_plugins/Image
87 | Enabled: true
88 | Max Value: 1
89 | Median window: 5
90 | Min Value: 0
91 | Name: Segmentation
92 | Normalize Range: true
93 | Topic:
94 | Depth: 5
95 | Durability Policy: Volatile
96 | History Policy: Keep Last
97 | Reliability Policy: Reliable
98 | Value: /carla/ego_vehicle/semantic_segmentation_front/image
99 | Value: true
100 | - Alpha: 1
101 | Autocompute Intensity Bounds: true
102 | Autocompute Value Bounds:
103 | Max Value: 10
104 | Min Value: -10
105 | Value: true
106 | Axis: Z
107 | Channel Name: intensity
108 | Class: rviz_default_plugins/PointCloud2
109 | Color: 255; 255; 255
110 | Color Transformer: Intensity
111 | Decay Time: 0
112 | Enabled: true
113 | Invert Rainbow: false
114 | Max Color: 255; 255; 255
115 | Max Intensity: 4096
116 | Min Color: 0; 0; 0
117 | Min Intensity: 0
118 | Name: Radar
119 | Position Transformer: XYZ
120 | Selectable: true
121 | Size (Pixels): 3
122 | Size (m): 0.25
123 | Style: Flat Squares
124 | Topic:
125 | Depth: 5
126 | Durability Policy: Volatile
127 | Filter size: 10
128 | History Policy: Keep Last
129 | Reliability Policy: Reliable
130 | Value: /carla/ego_vehicle/radar_front
131 | Use Fixed Frame: true
132 | Use rainbow: true
133 | Value: true
134 | - Alpha: 1
135 | Autocompute Intensity Bounds: true
136 | Autocompute Value Bounds:
137 | Max Value: 10
138 | Min Value: -10
139 | Value: true
140 | Axis: Z
141 | Channel Name: intensity
142 | Class: rviz_default_plugins/PointCloud2
143 | Color: 255; 255; 255
144 | Color Transformer: Intensity
145 | Decay Time: 0
146 | Enabled: true
147 | Invert Rainbow: false
148 | Max Color: 255; 255; 255
149 | Max Intensity: 0.988711416721344
150 | Min Color: 0; 0; 0
151 | Min Intensity: 0.8193727135658264
152 | Name: Lidar
153 | Position Transformer: XYZ
154 | Selectable: true
155 | Size (Pixels): 3
156 | Size (m): 0.10000000149011612
157 | Style: Flat Squares
158 | Topic:
159 | Depth: 5
160 | Durability Policy: Volatile
161 | Filter size: 10
162 | History Policy: Keep Last
163 | Reliability Policy: Reliable
164 | Value: /carla/ego_vehicle/lidar
165 | Use Fixed Frame: true
166 | Use rainbow: true
167 | Value: true
168 | Enabled: true
169 | Global Options:
170 | Background Color: 48; 48; 48
171 | Fixed Frame: map
172 | Frame Rate: 30
173 | Name: root
174 | Tools:
175 | - Class: rviz_default_plugins/Interact
176 | Hide Inactive Objects: true
177 | - Class: rviz_default_plugins/MoveCamera
178 | - Class: rviz_default_plugins/Select
179 | - Class: rviz_default_plugins/FocusCamera
180 | - Class: rviz_default_plugins/Measure
181 | Line color: 128; 128; 0
182 | - Class: rviz_default_plugins/SetInitialPose
183 | Covariance x: 0.25
184 | Covariance y: 0.25
185 | Covariance yaw: 0.06853891909122467
186 | Topic:
187 | Depth: 5
188 | Durability Policy: Volatile
189 | History Policy: Keep Last
190 | Reliability Policy: Reliable
191 | Value: /initialpose
192 | - Class: rviz_default_plugins/SetGoal
193 | Topic:
194 | Depth: 5
195 | Durability Policy: Volatile
196 | History Policy: Keep Last
197 | Reliability Policy: Reliable
198 | Value: /move_base_simple/goal
199 | - Class: rviz_default_plugins/PublishPoint
200 | Single click: true
201 | Topic:
202 | Depth: 5
203 | Durability Policy: Volatile
204 | History Policy: Keep Last
205 | Reliability Policy: Reliable
206 | Value: /clicked_point
207 | Transformation:
208 | Current:
209 | Class: rviz_default_plugins/TF
210 | Value: true
211 | Views:
212 | Current:
213 | Class: rviz_default_plugins/ThirdPersonFollower
214 | Distance: 29.793502807617188
215 | Enable Stereo Rendering:
216 | Stereo Eye Separation: 0.05999999865889549
217 | Stereo Focal Distance: 1
218 | Swap Stereo Eyes: false
219 | Value: false
220 | Focal Point:
221 | X: -5.698474884033203
222 | Y: -0.13345003128051758
223 | Z: -5.542716826312244e-05
224 | Focal Shape Fixed Size: false
225 | Focal Shape Size: 0.05000000074505806
226 | Invert Z Axis: false
227 | Name: Current View
228 | Near Clip Distance: 0.009999999776482582
229 | Pitch: 0.41539913415908813
230 | Target Frame: ego_vehicle
231 | Value: ThirdPersonFollower (rviz_default_plugins)
232 | Yaw: 3.128587007522583
233 | Saved: ~
234 | Window Geometry:
235 | CarlaControl:
236 | collapsed: false
237 | Depth:
238 | collapsed: false
239 | Displays:
240 | collapsed: false
241 | Height: 825
242 | Hide Left Dock: false
243 | Hide Right Dock: false
244 | Orbit:
245 | collapsed: false
246 | QMainWindow State: 000000ff00000000fd0000000300000000000001a8000002e3fc020000000cfb0000001200530065006c0065006300740069006f006e00000001e10000009b0000005c00fffffffb0000001e0054006f006f006c002000500072006f007000650072007400690065007302000001ed000001df00000185000000a3fb000000120056006900650077007300200054006f006f02000001df000002110000018500000122fb000000200054006f006f006c002000500072006f0070006500720074006900650073003203000002880000011d000002210000017afc0000003b00000168000000c700fffffffa000000010100000002fb0000000a005600690065007700730000000000ffffffff0000010000fffffffb000000100044006900730070006c0061007900730100000000000001fe0000015600fffffffb0000002000730065006c0065006300740069006f006e00200062007500660066006500720200000138000000aa0000023a00000294fb00000014005700690064006500530074006500720065006f02000000e6000000d2000003ee0000030bfb0000000c004b0069006e0065006300740200000186000001060000030c00000261fb0000000a00560069006500770073000000017b00000114000000a000fffffffb00000014004f00720062006900740020005600690065007701000002110000013c0000000000000000fb00000018004300610072006c00610043006f006e00740072006f006c0000000249000000aa0000006e00fffffffb0000000a004f007200620069007401000001a9000001750000002800ffffff0000000100000233000002e3fc0200000016fb00000006005200470042010000003b000001cf0000002800fffffffb0000000a0049006d0061006700650100000152000001120000000000000000fb00000018005300650067006d0065006e0074006100740069006f006e0100000210000000800000002800fffffffb0000000a004400650070007400680100000296000000880000002800fffffffb0000000600440056005300000002b10000006d0000000000000000fb00000018005300650067006d0065006e0074006100740069006f006e01000002d5000001080000000000000000fb0000000a0049006d006100670065010000003b000003bd0000000000000000fb0000000a0049006d0061006700650100000256000001a20000000000000000fb0000000a0049006d006100670065010000003b000003a20000000000000000fb0000000a0049006d006100670065010000003b000003250000000000000000fb0000000a0049006d006100670065010000003b000003a20000000000000000fb0000000a0049006d0061006700650100000223000001ba0000000000000000fb0000000a0049006d00610067006501000003b30000002a0000000000000000fb0000000a0049006d006100670065010000023e0000008e0000000000000000fb0000000a0049006d00610067006501000002d20000007d0000000000000000fb0000000a0049006d0061006700650100000355000000880000000000000000fb0000002a00430061006d0065007200610020005300650063006f006e0064002000560065006800690063006c00650100000216000001c70000000000000000fb0000001800440065007000740068002000430061006d006500720061000000020f000000430000000000000000fb0000001e00530065006d0061006e007400690063002000430061006d0065007200610000000247000000430000000000000000fb00000014004400560053002000430061006d0065007200610000000285000000650000000000000000fb0000001e0054006f006f006c002000500072006f00700065007200740069006500730100000041000000780000000000000000fb0000001200530065006c0065006300740069006f006e010000025a000000b20000000000000000000000030000073a000000cafc0100000002fb0000000800540069006d006501000000000000077e0000000000000000fb0000000800540069006d006501000000000000045000000000000000000000034f000002e300000004000000040000000800000008fc0000000100000002000000010000000a0054006f006f006c00730100000000ffffffff0000000000000000
247 | RGB:
248 | collapsed: false
249 | Segmentation:
250 | collapsed: false
251 | Selection:
252 | collapsed: false
253 | Tool Properties:
254 | collapsed: false
255 | Views:
256 | collapsed: false
257 | Width: 1846
258 | X: 73
259 | Y: 30
260 |
--------------------------------------------------------------------------------
/utils/tutorial/docker-compose.yml:
--------------------------------------------------------------------------------
1 | # you can utilize yaml features to avoid repeating yourself and centralizing configurations
2 | x-rviz-config-mount: &rviz-config-mount ./config.rviz:/config.rviz
3 |
4 | # ==============================================================================
5 |
6 | services:
7 |
8 | # starts a CARLA simulator instance named 'carla-server' with a GUI window
9 | carla-server:
10 | extends:
11 | file: ../carla-essentials/carla-services.yml
12 | service: carla-server
13 |
14 | carla-client:
15 | extends:
16 | file: ../carla-essentials/carla-services.yml
17 | service: carla-client
18 | command: sleep infinity
19 |
20 | # starts the carla-ros-bridge
21 | carla-ros-bridge:
22 | extends:
23 | file: ../carla-essentials/carla-services.yml
24 | service: carla-ros-bridge
25 | # ...and then execute them. Note the -ic flag for an interactive bash!
26 | # Without an interactive bash, many important env vars wouldn't be working or even set
27 | command: bash -ic 'ros2 launch carla_ros_bridge carla_ros_bridge_with_example_ego_vehicle.launch.py host:=carla-server'
28 | # .. note that the host name is explictly set to the name of the carla-server Docker service!
29 |
30 | # starts rviz with a GUI window named 'ros-monitoring'
31 | ros-monitoring:
32 | extends:
33 | file: ../carla-essentials/carla-services.yml
34 | service: ros-monitoring
35 | depends_on:
36 | carla-server:
37 | condition: service_healthy
38 | volumes:
39 | # you can mount custom rviz configs...
40 | - *rviz-config-mount
41 | # ...and then use them when starting up rviz with the -d flag
42 | command: bash -ic 'rviz2 -d /config.rviz --ros-args -p use_sim_time:=true &> /dev/null'
43 |
--------------------------------------------------------------------------------