diff --git a/Docs/adv_traffic_manager.md b/Docs/adv_traffic_manager.md index 58ed05958..cab917a37 100644 --- a/Docs/adv_traffic_manager.md +++ b/Docs/adv_traffic_manager.md @@ -1,16 +1,23 @@ # Traffic Manager -* [__What is it?__](#what-is-it) -* [__How does it work?__](#how-does-it-work) - * Architecture - * Stages -* [__Using the Traffic Manager__](#using-the-traffic-manager) - * Parameters - * Creating a Traffic Manager - * Setting the Traffic Manager -* [__Other considerations__](#other-considerations) - * FPS limitations - * Multiclient management -* [__Summary__](#summary) +* [__What is it?__](#what-is-it) +* [__How does it work?__](#how-does-it-work) + * [Architecture](#architecture) + * [Stages](#stages) +* [__Using the Traffic Manager__](#using-the-traffic-manager) + * [General considerations](#general-considerations) + * [Creating a Traffic Manager](#creating-a-traffic-manager) + * [Setting a Traffic Manager](#setting-a-traffic-manager) + * [Stopping a Traffic Manager](#stopping-a-traffic-manager) +* [__Hybrid physics mode__](#hybrid-physics-mode) +* [__Running multiple Traffic Managers__](#running-multiple-traffic-managers) + * [Definitions](#definitions) + * [Multiclient](#multiclient) + * [MultiTM](#multitm) + * [Multisimulation](#multisimulation) +* [__Other considerations__](#other-considerations) + * [FPS limitations](#fps-limitations) + * [Synchronous mode](#synchronous-mode) +* [__Summary__](#summary) --- ## What is it? @@ -82,9 +89,10 @@ The TM provides a set of possibilities so the user can establish specific behavi - + + 1. Use a carla.Client to create a TM instance connected to a port.
+ 2. Retrieve the port where a TM is connected. + + + +
TM creation: General:
- 1. Get a TM instance for a client.
Safety conditions:
@@ -105,7 +113,13 @@ The TM provides a set of possibilities so the user can establish specific behavi
1. Force a lane change disregarding possible collisions.
2. Enable/Disable lane changes for a vehicle. -
Hybrid physics mode:
+ 1. Enable/Disable the hybrid physics mode.
+ 2. Change the radius where physics are enabled. +

@@ -118,20 +132,23 @@ A TM instance can be created by any [carla.Client](python_api.md#carla.Client) s tm = client.get_trafficmanager(port) ``` -Now the TM needs some vehicles to be in charge of. In order to do so, enable the autopilot mode for the set of vehicles to be managed. In case the client is not connected to any TM, an instance will be created with default presets. +Now the TM needs some vehicles to be in charge of. In order to do so, enable the autopilot mode for the set of vehicles to be managed. Retrieve the port of the TM object that has been created. If no port is provided, it will try to connect to a TM in the default port, `8000`. If the TM does not exist, it will create it. ```python +tm_port = tm.get_port() for v in vehicles_list: - v.set_autopilot(True) + v.set_autopilot(True,tm_port) ``` !!! Note In multiclient situations, creating or connecting to a TM is not that straightforward. Take a look into the [other considerations](#other-considerations) section to learn more about this. The script `spawn_npc.py` in `/PythonAPI/examples` creates a TM instance in the port passed as argument and registers every vehicle spawned to it by setting the autopilot to True on a batch. + ```py -traffic_manager = client.get_trafficmanager(args.tm_port) +traffic_manager = client.get_trafficmanager(args.tm-port) +tm_port = traffic_manager.get_port() ... -batch.append(SpawnActor(blueprint, transform).then(SetAutopilot(FutureActor, True))) +batch.append(SpawnActor(blueprint, transform).then(SetAutopilot(FutureActor, True,tm_port))) ... traffic_manager.global_percentage_speed_difference(30.0) ``` @@ -142,8 +159,9 @@ The following example creates an instance of the TM and sets a dangerous behavio ```python tm = client.get_trafficmanager(port) +tm_port = tm.get_port() for v in my_vehicles: - v.set_autopilot(True) + v.set_autopilot(True,tm_port) danger_car = my_vehicles[0] tm.ignore_lights_percentage(danger_car,100) tm.distance_to_leading_vehicle(danger_car,0) @@ -153,8 +171,9 @@ tm.vehicle_percentage_speed_difference(danger_car,-20) Now, here is an example that registers that same list of vehicles but instead is set to conduct them with a moderate behaviour. The vehicles will drive at 80% their current speed limit, leaving at least 5 meters between them and never perform a lane change. ```python tm = client.get_trafficmanager(port) +tm_port = tm.get_port() for v in my_vehicles: - v.set_autopilot(True) + v.set_autopilot(True,tm_port) danger_car = my_vehicles[0] tm.global_distance_to_leading_vehicle(5) tm.global_percentage_speed_difference(80) @@ -162,27 +181,48 @@ for v in my_vehicles: tm.auto_lane_change(v,False) ``` -!!! Important - Lane changes are currently disabled in the TM due to unintended collisions causing jams. As long as this issues are not fixed, vehicles will remain in the lane they are spawned and the methods to set lane changes will be disabled. - - ### Stopping a Traffic Manager The TM is not an actor that needs to be destroyed, it will stop when the corresponding client does so. This is automatically managed by the API so the user does not have to take care of it. However, it is important that when shutting down a TM, the vehicles registered to it are destroyed. Otherwise, they will stop at place, as no one will be conducting them. The script `spawn_npc.py` does this automatically. !!! Warning - Shutting down a __TM-Server__ will shut down the __TM-Clients__ connecting to it. To learn the difference between a __TM-Server__ and a __TM-Client__ read the following section. + Shutting down a __TM-Server__ will shut down the __TM-Clients__ connecting to it. To learn the difference between a __TM-Server__ and a __TM-Client__ read about [multiclient and multiTM](#multiclient-and-multitm-management). --- -## Multiclient and multiTM management +## Hybrid physics mode -### Different Traffic Manager definitions +In hybrid mode, either all vehicle physics can be disabled, or enabled only in a radius around an ego vehicle with the tag `hero`. This feature removes the vehicle physics bottleneck from the simulator. Since vehicle physics are not active, all cars move by teleportation. This feature relies on [Actor.set_simulate_physics()](https://carla.readthedocs.io/en/latest/python_api/#carla.Actor.set_simulate_physics). However, not all the physics are disregarded. Basic calculations for a linear acceleration are maintained. By doing so, the position update, and vehicle speed still look realistic. That guarantees that when a vehicle enables or disables its physics, the transition is fluid. + +The hybrid mode is disabled by default. There are two ways to enable it. + +* [__TrafficManager.set_hybrid_phisics_mode(True)__](https://carla.readthedocs.io/en/latest/python_api/#carla.TrafficManager.set_hybrid_physics_mode) — This method will enable the hybrid mode for the Traffic Manager object calling it. +* __Running `spawn_npc.py` with the flag `--hybrid`__ — The vehicles spawned will be registered to a Traffic Manager stated inside the script, and this will run with the hybrid physics on. + +The are two parameters ruling the hybrid mode. One is the __radius__ that states the proximity area around any ego vehicle where physics are enabled. The other is the __vehicle__ with , that will act as center of this radius. + +* __Radius__ *(default = 70 meters)* — States the proximity area around the ego vehicle where physics are enabled. The value be changed with [traffic_manager.set_hybrid_mode_radius(r)](https://carla.readthedocs.io/en/latest/python_api/#carla.TrafficManager.set_hybrid_mode_radius). +* __Ego vehicle__ — A vehicle tagged with `role_name='hero'` that will act of the radius. + * __If there is none,__ all the vehicles will disable physics. + * __If there are many,__ the radius will be considered for all of them. That will create different areas of influence with physics enabled. + +The following example shows how the physics are enabled and disabled when hybrid mode is on. The __ego vehicle__ is tagged with a __red square__. Vehicles with __physics disabled__ are tagged with a __blue square__. When inside the area of influence stated by the radius, __physics are enabled and the tag becomes green__. + +![Welcome to CARLA](img/tm_hybrid.gif) + + +--- +## Running multiple Traffic Managers + +### Definitions When working with different clients containing different TM, understanding inner implementation of the TM in the client-server architecture becomes specially relevant. There is one ruling these scenarios: __the port is the key__. A client creates a TM by communicating with the server and passing the intended port to be used for said purpose. The port can either be stated or not, using the default as `8000`. + +* __TM-Server__ — The port is free. This type of TM is in charge of its own logic, managed in `TrafficManagerLocal.cpp`. The following code creates two TM-Servers. Each one connects to a different port, not previously used. + ```py tm01 = client01.get_trafficmanager() # tm01 --> tm01 (p=8000) ``` @@ -190,9 +230,7 @@ tm01 = client01.get_trafficmanager() # tm01 --> tm01 (p=8000) tm02 = client02.get_trafficmanager(5000) # tm02(p=5000) --> tm02 (p=5000) ``` -The previous code creates two different TM, as both have different ports and none of them was previously occupied by another TM. These are __TM-Servers__: instances of the TM created on free ports. - -However, if a client tries to create a TM using a port that is already assigned to another TM, __it will not create its own but connect to the one already existing__. These are __TM-Clients__: instances of the TM created in an occupied port, which connect to the previous existing one. +* __TM-Client__ — The port is occupied by another TM. This instances are not in charge of their own logic. Instead, they ask for changes in the parameters of the __TM-Server__ they are connected to in `TrafficManagerRemote.cpp`. The following code creates two TM-Clients, that connect with the TM-Servers previously created. ```py tm03 = client03.get_trafficmanager() # tm03 --> tm01 (p=8000). @@ -206,27 +244,47 @@ tm04 = client04.get_trafficmanager(5000) # tm04(p=5000) --> tm02 (p=5000) The CARLA server keeps register of all the TM instances internally by storing the port and also the client IP (hidden to the user) that link to them. Right now there is no way to check the TM instances that have been created so far. A connection will always be attempted when trying to create an instance and it will either create a new __TM-Server__ or a __TM-Client__. -### Multiclient VS MultiTM - -Based on the different definitions for a TM, successfully creating a TM can lead to two different results: - -* __TM-Server:__ when the port is free. This type of TM is in charge of its own logic, managed in `TrafficManagerLocal.cpp`. - -* __TM-Client:__ when the port is occupied. It is not in charge of its own logic. Instead, it asks for changes in the parameters of the __TM-Server__ it is connected to in `TrafficManagerRemote.cpp`. - -That creates a clear distinction between having multiple clients and multiple Traffic Managers running: - -* __Multiclient scenario:__ when there is only one TM-Server, but there are other TM-Clients created with the same port definition that are actually connecting to said TM-Server. - -* __MultiTM scenario:__ when there are different TM-Server, created with different port definitions. - !!! Note - The class `TrafficManager.cpp` acts as a central hub managing all the different TM instances. + The class `TrafficManager.cpp` acts as a central hub managing all the different TM instances. + +### Multiclient + +More than one TM instances created with the same port. The first will be a TM-Server. The rest will be TM-Clients connecting to it. +```py +terminal 1: ./CarlaUE4.sh -carla-rpc-port=4000 +terminal 2: python3 spawn_npc.py --port 4000 --tm-port 4050 # TM-Server +terminal 3: python3 spawn_npc.py --port 4000 --tm-port 4050 # TM-Client +``` + +### MultiTM + +Different TM instances with different ports assigned. +```py +terminal 1: ./CarlaUE4.sh -carla-rpc-port=4000 +terminal 2: python3 spawn_npc.py --port 4000 --tm-port 4050 # TM-Server A +terminal 3: python3 spawn_npc.py --port 4000 --tm-port 4550 # TM-Server B +``` + +### Multisimulation + +Multisimulation is when there are more than one CARLA server running at the same time. The TM declaration is not relevant. As long as the computational power allows for it, the TM can run multiple simulations at a time without any problems. + +```py +terminal 1: ./CarlaUE4.sh -carla-rpc-port=4000 # simulation A +terminal 2: ./CarlaUE4.sh -carla-rpc-port=5000 # simulation B +terminal 3: python3 spawn_npc.py --port 4000 --tm-port 4050 # TM-Server A connected to simulation A +terminal 4: python3 spawn_npc.py --port 5000 --tm-port 5050 # TM-Server B connected to simulation B +``` + +The concept of multisimulation is independent from the Traffic Manager itself. The example above runs two CARLA simulations in parallel, A and B. In each of them, a TM-Server is created independently from the other. Simulation A could run a Multiclient TM while simulation B is running a MultiTM, or no TM at all. + +The only possible issue arising from this is a client trying to connect to an already existing TM which is not running on the selected simulation. In case this happens, an error message will appear and the connection will be aborted, to prevent interferences between simulations. + --- ## Other considerations -The TM is a module constantly evolving and trying to adapt the range of possibilities that it presents. For instance, in order to get more realistic behaviours we can have many clients with different TM in charge of sets of vehicles with specific and distinct behaviours. This range of possibilities also makes for a lot of different configurations that can get really complex and specific. For such reason, here are listed of considerations that should be taken into account when working with the TM as it is by the time CARLA 0.9.8 is released: +The TM is a module constantly evolving and trying to adapt the range of possibilities that it presents. For instance, in order to get more realistic behaviours we can have many clients with different TM in charge of sets of vehicles with specific and distinct behaviours. This range of possibilities also makes for a lot of different configurations that can get really complex and specific. For such reason, here are listed of considerations that should be taken into account when working with the TM as it is by the time of writing. ### FPS limitations @@ -240,6 +298,9 @@ The TM stops working properly in asynchronous mode when the simulation is under TM-Clients cannot tick the CARLA server in synchronous mode, __only a TM-Server can call for a tick__. If more than one TM-Server ticks, the synchrony will fail, as the server will move forward on every tick. This is specially relevant when working with the __ScenarioRunner__, which runs a TM. In this case, the TM will be subordinated to the ScenarioRunner and wait for it. +!!! Warning + Disable the synchronous mode in the script doing the ticks before it finishes. Otherwise, the server will be blocked, waiting forever for a tick. + --- ## Summary diff --git a/Docs/build_linux.md b/Docs/build_linux.md index a943b2368..163dfcb9f 100644 --- a/Docs/build_linux.md +++ b/Docs/build_linux.md @@ -232,8 +232,8 @@ The variable should be added to `~/.bashrc` or `~/.profile` to be set persistent The last step is to finally build CARLA. There are different `make` commands to build the different modules. All of them run in the root CARLA folder. !!! Warning - Make sure to run __make launch__ to prepare the server and __make PythonAPI__ for the client. - Alternatively __make libcarla__ will prepare the CARLA library to be imported anywhere. + Make sure to run `make launch` to prepare the server and `make PythonAPI` for the client. + Alternatively `make LibCarla` will prepare the CARLA library to be imported anywhere. * __make launch__ compiles the server simulator and launches Unreal Engine. Press **Play** to start the spectator view and close the editor window to exit. Camera can be moved with `WASD` keys and rotated by clicking the scene while moving the mouse around. ```sh diff --git a/Docs/build_windows.md b/Docs/build_windows.md index 2fd7de4b0..80fa40c7d 100644 --- a/Docs/build_windows.md +++ b/Docs/build_windows.md @@ -124,22 +124,13 @@ Only the assets package is yet to be downloaded. `\Util\ContentVersions.txt` con Download the __latest__ assets to work with the current version of CARLA. -### make CARLA - -Go to the root CARLA folder to make the build. The process may take a while, around 20-40 minutes, it will download and install the necessary libraries. There are different commands to build the different modules. - -!!! Warning - Make sure to run __make launch__ to prepare the server and __make PythonAPI__ for the client. - Alternatively __make libcarla__ will prepare the CARLA library to be imported anywhere. - - ### make CARLA The last step is to finally build CARLA. There are different `make` commands to build the different modules. All of them run in the root CARLA folder. !!! Warning - Make sure to run __make launch__ to prepare the server and __make PythonAPI__ for the client. - Alternatively __make libcarla__ will prepare the CARLA library to be imported anywhere. + Make sure to run `make launch` to prepare the server and `make PythonAPI` for the client. + Alternatively `make LibCarla` will prepare the CARLA library to be imported anywhere. * __make launch__ compiles the server simulator and launches Unreal Engine. Press **Play** to start the spectator view and close the editor window to exit. Camera can be moved with `WASD` keys and rotated by clicking the scene while moving the mouse around. ```sh diff --git a/Docs/cont_code_of_conduct.md b/Docs/cont_code_of_conduct.md index fc6874a29..30b759490 100644 --- a/Docs/cont_code_of_conduct.md +++ b/Docs/cont_code_of_conduct.md @@ -60,7 +60,7 @@ further defined and clarified by project maintainers. ## Enforcement Instances of abusive, harassing, or otherwise unacceptable behavior may be -reported by contacting the project team at [INSERT EMAIL ADDRESS]. All +reported by contacting the project team at info-carla@osvf.org. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. diff --git a/Docs/core_actors.md b/Docs/core_actors.md index c9672e0b8..777a0d3ae 100644 --- a/Docs/core_actors.md +++ b/Docs/core_actors.md @@ -4,18 +4,18 @@ Actors not only include vehicles and walkers, but also sensors, traffic signs, t This section will cover spawning, destruction, types, and how to manage them. However, the possibilities are almost endless. Experiment, take a look at the __tutorials__ in this documentation and share doubts and ideas in the [CARLA forum](https://forum.carla.org/). -* [__Blueprints__](#blueprints) - * Managing the blueprint library -* [__Actor life cycle__](#actor-life-cycle) - * Spawning - * Handling - * Destruction -* [__Types of actors__](#types-of-actors) - * Sensors - * Spectator - * Traffic signs and traffic lights - * Vehicles - * Walkers +* [__Blueprints__](#blueprints) + * [Managing the blueprint library](#managing-the-blueprint-library) +* [__Actor life cycle__](#actor-life-cycle) + * [Spawning](#spawning) + * [Handling](#handling) + * [Destruction](#destruction) +* [__Types of actors__](#types-of-actors) + * [Sensors](#sensors) + * [Spectator](#spectator) + * [Traffic signs and traffic lights](#traffic-signs-and-traffic-lights) + * [Vehicles](#vehicles) + * [Walkers](#walkers) --- ## Blueprints @@ -179,7 +179,12 @@ carla.Rotation(pitch=-90))) ### Traffic signs and traffic lights -So far, CARLA only is aware of some signs: stop, yield and speed limit. Traffic lights are considered an inherited class from the more general traffic sign. __None of these can be found in the blueprint library__ and thus, cannot be spawned. They set traffic conditions, so they are mindfully placed by developers. +Only stops, yields and traffic lights are considered actors in CARLA so far. The rest of the OpenDRIVE signs are accessible from the API as [__carla.Landmark__](python_api.md#carla.Landmark). Their information is accessible using these instances, but they do no exist in the simulation as actors. Landmarks are explained more in detail in the following step, __3rd. Maps and navigation__. + +When the simulation starts, stop, yields and traffic light are automatically generated using the information in the OpenDRIVE file. __None of these can be found in the blueprint library__ and thus, cannot be spawned. + +!!! Note + CARLA maps do not have traffic signs nor lights in the OpenDRIVE file. These are manually placed by developers. [__Traffic signs__](python_api.md#carla.TrafficSign) are not defined in the road map itself, as explained in the following page. Instead, they have a [carla.BoundingBox](python_api.md#carla.BoundingBox) to affect vehicles inside of it. ```py @@ -187,9 +192,6 @@ So far, CARLA only is aware of some signs: stop, yield and speed limit. Traffic if vehicle_actor.is_at_traffic_light(): traffic_light = vehicle_actor.get_traffic_light() ``` -!!! Note - Vehicles will only notice a traffic light if the light is red. - [__Traffic lights__](python_api.md#carla.TrafficLight) are found in junctions. They have their unique ID, as any actor, but also a `group` ID for the junction. To identify the traffic lights in the same group, a `pole` ID is used. The traffic lights in the same group follow a cycle. The first one is set to green while the rest remain frozen in red. The active one spends a few seconds in green, yellow and red, so there is a period of time where all the lights are red. Then, the next traffic light starts its cycle, and the previous one is frozen with the rest. @@ -202,6 +204,9 @@ if traffic_light.get_state() == carla.TrafficLightState.Red: traffic_light.set_set_green_time(4.0) ``` +!!! Note + Vehicles will only be aware of a traffic light if the light is red. + ### Vehicles [__carla.Vehicle__](python_api.md#carla.Vehicle) are a special type of actor. They are remarkable for having better physics. This is achieved applying four types of different controls. @@ -231,18 +236,20 @@ Vehicles include other functionalities unique to them. ```py vehicle.set_autopilot(True) ``` -* __Vehicle lights__ created specifically for each vehicle model. They can be accessed from the API. In order to turn them on/off, the vehicle uses flag values. These are defined in [carla.VehicleLightState](python_api.md#carla.VehicleLightState) and binary operations are used to combine them. +* __Vehicle lights__ have to be turned on/off by the user. Each vehicle has a set of lights listed in [__carla.VehicleLightState__](python_api.md#carla.VehicleLightState). So far, not all vehicles have lights integrated. Here is a list of those that are available by the time of writing. + * __Bikes.__ All of them have a front and back position light. + * __Motorcycles.__ Yamaha and Harley Davidson models. + * __Cars.__ Audi TT, Chevrolet, Dodge (the police car), Etron, Lincoln, Mustang, Tesla 3S, Wolkswagen T2 and the new guests coming to CARLA. + +The lights of a vehicle can be retrieved and updated anytime using the methods [carla.Vehicle.get_light_state](python_api.md#carla.Vehicle.get_light_state) and [carla.Vehicle.set_light_state](#python_api.md#carla.Vehicle.set_light_state). These use binary operations to customize the light setting. ```py -# Turn on position lights +# Turn on position lights current_lights = carla.VehicleLightState.NONE current_lights |= carla.VehicleLightState.Position vehicle.set_light_state(current_lights) ``` -!!! Note - So far, vehicle lights have been implemented only for a specific set of vehicles, listed in the [release post](http://carla.org/2020/03/09/release-0.9.8/#vehicle-lights). - ### Walkers [__carla.Walker__](python_api.md#carla.Walker) work in a similar way as vehicles do. Control over them is provided by controllers. diff --git a/Docs/core_concepts.md b/Docs/core_concepts.md index aec982af5..39337ece7 100644 --- a/Docs/core_concepts.md +++ b/Docs/core_concepts.md @@ -4,12 +4,12 @@ This page introduces the main features and modules in CARLA. Detailed explanatio In order to learn about the different classes and methods in the API, take a look at the [Python API reference](python_api.md). Besides, the [Code recipes](ref_code_recipes.md) reference contains some common code chunks, specially useful during these first steps. - * [__First steps__](#first-steps) - * 1st. World and client - * 2nd. Actors and blueprints - * 3rd. Maps and navigation - * 4th. Sensors and data - * [__Advanced steps__](#advanced-steps) +* [__First steps__](#first-steps) + * [1st- World and client](#1st-world-and-client) + * [2nd- Actors and blueprints](#2nd-actors-and-blueprints) + * [3rd- Maps and navigation](#3rd-maps-and-navigation) + * [4th- Sensors and data](#4th-sensors-and-data) + * [__Advanced steps__](#advanced-steps) !!! Important **This documentation refers to CARLA 0.9.X**.
@@ -18,55 +18,60 @@ In order to learn about the different classes and methods in the API, take a loo --- ## First steps -### 1st. World and client +### 1st- World and client __The client__ is the module the user runs to ask for information or changes in the simulation. A client runs with an IP and a specific port. It communicates with the server via terminal. There can be many clients running at the same time. Advanced multiclient managing requires thorough understanding of CARLA and [synchrony](adv_synchrony_timestep.md). __The world__ is an object representing the simulation. It acts as an abstract layer containing the main methods to spawn actors, change the weather, get the current state of the world, etc. There is only one world per simulation. It will be destroyed and substituted for a new one when the map is changed. -### 2nd. Actors and blueprints +### 2nd- Actors and blueprints An actor is anything that plays a role in the simulation. -* Vehicles. -* Walkers. -* Sensors. -* The spectator. -* Traffic signs and traffic lights. +* Vehicles. +* Walkers. +* Sensors. +* The spectator. +* Traffic signs and traffic lights. __Blueprints__ are already-made actor layouts necessary to spawn an actor. Basically, models with animations and a set of attributes. Some of these attributes can be customized by the user, others don't. There is a [__Blueprint library__](bp_library.md) containing all the blueprints available as well as information on them. -### 3rd. Maps and navigation +### 3rd- Maps and navigation -__The map__ is the object representing the simulated world, the town mostly. There are seven maps available. All of them use OpenDRIVE 1.4 standard to describe the roads. +__The map__ is the object representing the simulated world, the town mostly. There are eight maps available. All of them use OpenDRIVE 1.4 standard to describe the roads. __Roads, lanes and junctions__ are managed by the [Python API](python_api.md) to be accessed from the client. These are used along with the __waypoint__ class to provide vehicles with a navigation path. -__Traffic signs__ and __traffic lights__ have bounding boxes placed on the road. Vehicles become aware of them once inside their bounding box. +__Traffic signs__ and __traffic lights__ are accessible as [__carla.Landmark__](#python_api.md#carla.landmark) objects that contain information about their OpenDRIVE definition. Additionally, the simulator automatically generates stops, yields and traffic light objects when running using the information on the OpenDRIVE file. These have bounding boxes placed on the road. Vehicles become aware of them once inside their bounding box. -### 4th. Sensors and data +### 4th- Sensors and data __Sensors__ wait for some event to happen, and then gather data from the simulation. They call for a function defining how to manage the data. Depending on which, sensors retrieve different types of __sensor data__. A sensor is an actor attached to a parent vehicle. It follows the vehicle around, gathering information of the surroundings. The sensors available are defined by their blueprints in the [Blueprint library](bp_library.md). -* Cameras (RGB, depth and semantic segmentation). -* Collision detector. -* Gnss sensor. -* IMU sensor. -* Lidar raycast. -* Lane invasion detector. -* Obstacle detector. -* Radar. +* Cameras (RGB, depth and semantic segmentation). +* Collision detector. +* Gnss sensor. +* IMU sensor. +* Lidar raycast. +* Lane invasion detector. +* Obstacle detector. +* Radar. +* RSS. --- ## Advanced steps -Hereunder are listed some advanced CARLA features. However, it is highly encouraged to first take a closer look to the pages regarding the first steps in order to learn the basics. +CARLA offers a wide range of features that go beyond the scope of this introduction to the simulator. Here are listed some of the most remarkable ones. However, it is highly encouraged to read the whole __First steps__ section before starting with the advanced steps. -* __Recorder.__ Allows for reenacting previous simulations using snapshots of the world. -* __Rendering options.__ Graphics quality settings, off-screen rendering and a no-rendering mode. -* __Simulation time and synchrony.__ Everything regarding the simulation time and server-client communication. -* __Traffic manager.__ This module is in charge of every vehicle set to autopilot mode. It simulates traffic in the city for the simulation to look like a real urban environment. +* [__OpenDRIVE standalone mode__](adv_opendrive.md). Generates a road mesh using only an OpenDRIVE file. Allows to load any OpenDRIVE map into CARLA without the need of creating assets. +* [__PTV-Vissim co-simulation__](adv_ptv.md). Run a synchronous simulation between CARLA and PTV-Vissim traffic simulator. +* [__Recorder__](adv_recorder.md). Saves snapshots of the simulation state to reenact a simulation with exact precision. +* [__Rendering options__](adv_rendering_options.md). Graphics quality settings, off-screen rendering and a no-rendering mode. +* [__RSS sensor__](adv_rss.md). This sensor is quite different from the rest. It integrates the [C++ Library for Responsibility Sensitive Safety](https://github.com/intel/ad-rss-lib), and modifies a vehicle's trajectory using safety checks. +* [__Simulation time and synchrony__](adv_synchrony_timestep.md). Everything regarding the simulation time and server-client communication. +* [__SUMO co-simulation__](adv_sumo.md). Run a synchronous simulation between CARLA and SUMO traffic simulator. +* [__Traffic manager__](adv_traffic_manager.md). This module is in charge of every vehicle set to autopilot mode. It simulates traffic in the city for the simulation to look like a real urban environment. --- That is a wrap on the CARLA basics. The next step takes a closer look to the world and the clients connecting to it. diff --git a/Docs/core_map.md b/Docs/core_map.md index 9edb6abad..3110bfd78 100644 --- a/Docs/core_map.md +++ b/Docs/core_map.md @@ -2,13 +2,16 @@ After discussing about the world and its actors, it is time to put everything into place and understand the map and how do the actors navigate it. -* [__The map__](#the-map) - * Map changing - * Lanes - * Junctions - * Waypoints -* [__Navigation in CARLA__](#navigation-in-carla) -* [__CARLA maps__](#carla-maps) +* [__The map__](#the-map) + * [Changing the map](#changing-the-map) + * [Landmarks](#landmarks) + * [Lanes](#lanes) + * [Junctions](#junctions) + * [Waypoints](#waypoints) +* [__Navigation in CARLA__](#navigation-in-carla) + * [Navigating through waypoints](#navigating-through-waypoints) + * [Generating a map navigation](#generating-a-map-navigation) +* [__CARLA maps__](#carla-maps) --- ## The map @@ -32,6 +35,21 @@ The client can get a list of available maps. Each map has a `name` attribute tha print(client.get_available_maps()) ``` +### Landmarks + +The traffic signs defined in the OpenDRIVE file are translated into CARLA as landmark objects that can be queried from the API. In order to facilitate their manipulation, there have been several additions to it. + +* __[carla.Landmark](https://carla.readthedocs.io/en/latest/python_api/#carla.Landmark)__ objects represent the OpenDRIVE signals. The attributes and methods describe the landmark, and where it is effective. + * [__carla.LandmarkOrientation__](https://carla.readthedocs.io/en/latest/python_api/#carla.LandmarkOrientation) states the orientation of the landmark with regards of the road's geometry definition. + * [__carla.LandmarkType__](https://carla.readthedocs.io/en/latest/python_api/#carla.LandmarkType) contains some common landmark types, to ease translation to OpenDRIVE types. +* A __[carla.Waypoint](https://carla.readthedocs.io/en/latest/python_api/#carla.Waypoint)__ can get landmarks located a certain distance ahead of it. The type of landmark can be specified. +* The __[carla.Map](https://carla.readthedocs.io/en/latest/python_api/#carla.Map)__ retrieves sets of landmarks. It can return all the landmarks in the map, or those having an ID, type or group in common. +* The __[carla.World](https://carla.readthedocs.io/en/latest/python_api/#carla.World)__ acts as intermediary between landmarks, and the *carla.TrafficSign* and *carla.TrafficLight* that embody them in the simulation. + +```py +my_waypoint.get_landmarks(200.0,True) +``` + ### Lanes The lane types defined by [OpenDRIVE standard 1.4](http://www.opendrive.org/docs/OpenDRIVEFormatSpecRev1.4H.pdf) are translated to the API in [__carla.LaneType__](python_api.md#carla.LaneType) as a series of enum values. @@ -186,6 +204,9 @@ So far there are seven different maps available. Each one has unique features an Town07 A rural environment with narrow roads, barely non traffic lights and barns. + +Town10 +A city environment with with different environments such as an avenue or a promenade, and more realistic textures.
@@ -228,6 +249,12 @@ So far there are seven different maps available. Each one has unique features an
Town07
+
+ +
Town10
+
+ + @@ -242,6 +269,7 @@ So far there are seven different maps available. Each one has unique features an +