p71924506
/
carla
mirror of https://github.com/carla-simulator/carla.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

sergi-e/p099-updates (#2751) 

* First draft TM updates

* Idle iteration

* Different updates

* Python API weather fix

* Added RSS sensor

* Added nightly builds

* Added texture mention to Town10

* Updated TM

* Updated contact mail

* New update on B,Jo,Ja comments

* Last fixes on Ja comments
This commit is contained in:
sergi.e 2020-04-23 12:40:28 +02:00 committed by GitHub
parent 07ff7f3ad1
commit cd35196d20
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
20 changed files with 327 additions and 209 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

155
Docs/adv_traffic_manager.md
View File

@ -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
<table class ="defTable">
<tbody>
<td><b>TM creation:</b> </td>
<td><b>General:</b> </td>
<td><br>
<b>1.</b> Get a TM instance for a client.</td>
<b>1.</b> Use a carla.Client to create a TM instance connected to a port.<br>
<b>2.</b> Retrieve the port where a TM is connected.</td>
<tr>
<td><b>Safety conditions:</b> </td>
<td><br>
@ -105,7 +113,13 @@ The TM provides a set of possibilities so the user can establish specific behavi
<td><br>
<b>1.</b> Force a lane change disregarding possible collisions. <br>
<b>2.</b> Enable/Disable lane changes for a vehicle.
</td>
</td>
<tr>
<td><b>Hybrid physics mode:</b> </td>
<td><br>
<b>1.</b> Enable/Disable the hybrid physics mode. <br>
<b>2.</b> Change the radius where physics are enabled.
</td>
</tbody>
</table>
<br>
@ -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

4
Docs/build_linux.md
View File

@ -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

13
Docs/build_windows.md
View File

@ -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

2
Docs/cont_code_of_conduct.md
View File

@ -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.

49
Docs/core_actors.md
View File

@ -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.

65
Docs/core_concepts.md
View File

@ -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**. <br>
@ -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.

42
Docs/core_map.md
View File

@ -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
<tr>
<td><b>Town07</b></td>
<td>A rural environment with narrow roads, barely non traffic lights and barns.</td>
<tr>
<td><b>Town10</b></td>
<td>A city environment with with different environments such as an avenue or a promenade, and more realistic textures.</td>
</tbody>
</table>
<br>
@ -228,6 +249,12 @@ So far there are seven different maps available. Each one has unique features an
<div class="text">Town07</div>
</div>
<div class="townslide fade">
<img src="../img/Town10.png">
<div class="text">Town10</div>
</div>
<!-- Next and previous buttons -->
<a class="prev" onclick="plusSlides(-1)">&#10094;</a>
<a class="next" onclick="plusSlides(1)">&#10095;</a>
@ -242,6 +269,7 @@ So far there are seven different maps available. Each one has unique features an
<span class="dot" onclick="currentSlide(5)"></span>
<span class="dot" onclick="currentSlide(6)"></span>
<span class="dot" onclick="currentSlide(7)"></span>
<span class="dot" onclick="currentSlide(8)"></span>
</div>
<script>

18
Docs/core_sensors.md
View File

@ -5,14 +5,14 @@ Sensors are actors that retrieve data from their surroundings. They are crucial
This page summarizes everything necessary to start handling sensors. It introduces the types available and a step-by-step guide of their life cycle. The specifics for every sensor can be found in the [sensors reference](ref_sensors.md).
* [__Sensors step-by-step__](#sensors-step-by-step)
* Setting
* Spawning
* Listening
* Data
* [Setting](#setting)
* [Spawning](#spawning)
* [Listening](#listening)
* [Data](#data)
* [__Types of sensors__](#types-of-sensors)
* Cameras
* Detectors
* Other
* [Cameras](#cameras)
* [Detectors](#detectors)
* [Other](#other)
---
## Sensors step-by-step
@ -196,6 +196,10 @@ Different functionalities such as navigation, measurement of physical properties
<td>Radar</td>
<td><a href="../python_api#carlaradarmeasurement">carla.RadarMeasurement</a></td>
<td>2D point map modelling elements in sight and their movement regarding the sensor. </td>
<tr>
<td>RSS</td>
<td><a href="../python_api#carlarssresponse">carla.RssResponse</a></td>
<td>Modifies the controller applied to a vehicle according to safety checks. This sensor works in a different manner than the rest, and there is specific <a href="../adv_rss">RSS documentation</a> for it. </td>
</tbody>
</table>
<br>

82
Docs/core_world.md
View File

@ -4,23 +4,23 @@ The client and the world are two of the fundamentals of CARLA, a necessary abstr
This tutorial goes from defining the basics and creation of these elements, to describing their possibilities. If any doubt or issue arises during the reading, the [CARLA forum](https://forum.carla.org/) is there to solve them.
* [__The client__](#the-client)
* Client creation
* World connection
* Other client utilities
* [__The world__](#the-world)
* World life cycle
* Get() from the world
* Weather
* World snapshots
* Settings
* [__The client__](#the-client)
* [Client creation](#client-creation)
* [World connection](#world-connection)
* [Other client utilities](#other-client-utilities)
* [__The world__](#the-world)
* [Actors](#actors)
* [Weather](#weather)
* [Debugging](#debugging)
* [World snapshots](#world-snapshots)
* [World settings](#world-settings)
---
## The client
Clients are one of the main elements in the CARLA architecture. They connect to the server, retrieve information, and command changes. That is done via scripts. The client identifies itself, and connects to the world to then operate with the simulation.
Besides that, clients are able to access other CARLA modules, features, and apply command batches. Only command batches will be covered in this section. These are useful for basic things such as spawning lots of actors. The rest of features are more complex, and will be dealt with in other sections.
Besides that, clients are able to access advanced CARLA modules, features, and apply command batches. Only command batches will be covered in this section. These are useful for basic things such as spawning lots of actors. The rest of features are more complex, and they will be addressed in their respective pages in __Advanced steps__.
Take a look at [__carla.Client__](python_api.md#carla.Client) in the Python API reference to learn on specific methods and variables of the class.
@ -63,42 +63,48 @@ world = client.load_world('Town01')
Every world object has an `id` or episode. Everytime the client calls for `load_world()` or `reload_world()` the previous one is destroyed. A new one is created from scratch with a new episode. Unreal Engine is not rebooted in the process.
### Other client utilities
### Using commands
The main purpose of the client object is to get or change the world. Usually it is no longer used after that. However, the client also applies command batches and accesses advanced features. These features are.
__Commands__ are adaptations of some of the most-common CARLA methods, that can be applied in batches. For instance, the [command.SetAutopilot](python_api.md#command.SetAutopilot) is equivalent to [Vehicle.set_autopilot()](python_api.md#carla.Vehicle.set_autopilot), enables the autopilot for a vehicle. However, using the methods [Client.apply_batch](python_api.md#carla.Client.apply_batch) or [Client.apply_batch_sync()](python_api.md#carla.Client.apply_batch_sync), a list of commands can be applied in one single simulation step. This becomes extremely useful for methods that are usually applied to even hundreds of elements.
* __Traffic manager.__ This module is in charge of every vehicle set to autopilot to recreate urban traffic.
* __[Recorder](adv_recorder.md).__ Allows to reenact a previous simulation. Uses [snapshots](core_world.md#world-snapshots) summarizing the simulation state per frame.
The following example uses a batch to destroy a list of vehicles all at once.
As for command batches, the latest sections in the Python API describe the [available commands](python_api.md#command.ApplyAngularVelocity). These are common functions prepared to be executed in lots during the same step of the simulation. They can, for instance, destroy all the vehicles contained in `vehicles_list` at once.
```py
client.apply_batch([carla.command.DestroyActor(x) for x in vehicles_list])
```
`apply_batch_sync()` is only available in [synchronous mode](adv_synchrony_timestep.md). It returns a [command.Response](python_api.md#command.Response) per command applied.
All the commands available are listed in the [latest section](python_api.md#command.ApplyAngularVelocity) of the Python API reference.
### Other client utilities
The main purpose of the client object is to get or change the world, and apply commands. However, it also provides access to some additional features.
* __Traffic manager.__ This module is in charge of every vehicle set to autopilot to recreate urban traffic.
* __[Recorder](adv_recorder.md).__ Allows to reenact a previous simulation. Uses [snapshots](core_world.md#world-snapshots) summarizing the simulation state per frame.
---
## The world
The major ruler of the simulation. Its instance should be retrieved by the client. It does not contain the model of the world itself, that is part of the [Map](core_map.md) class. Instead, most of the information, and general settings can be accessed from this class.
* Actors in the simulation and the spectator.
* Blueprint library.
* Map.
* Simulation settings.
* Snapshots.
* Actors in the simulation and the spectator.
* Blueprint library.
* Map.
* Simulation settings.
* Snapshots.
* Weather and light manager.
Some of its most important methods are _getters_. Take a look at [carla.World](python_api.md#carla.World) to learn more about it.
Some of its most important methods are _getters_, precisely to retrieve information or instances of these elements. Take a look at [carla.World](python_api.md#carla.World) to learn more about it.
### Actors
The world has different methods related with actors that allow for different functionalities.
* Spawn actors (but not destroy them).
* Get every actor on scene, or find one in particular.
* Access the blueprint library.
* Access the spectator actor, the simulation's point of view.
* Retrieve a random location that is fitting to spawn an actor.
* Spawn actors (but not destroy them).
* Get every actor on scene, or find one in particular.
* Access the blueprint library.
* Access the spectator actor, the simulation's point of view.
* Retrieve a random location that is fitting to spawn an actor.
Spawning will be explained in [2nd. Actors and blueprints](core_actors.md). It requires some understanding on the blueprint library, attributes, etc.
@ -121,10 +127,28 @@ There are some weather presets that can be directly applied to the world. These
```py
world.set_weather(carla.WeatherParameters.WetCloudySunset)
```
!!! Note
Changes in the weather do not affect physics. They are only visuals that can be captured by the camera sensors.
__Night mode starts when sun_altitude_angle < 0__, which is considered sunset. This is when street and vehicle lights become especially relevant.
* __Street lights__ automatically turn on when night mode starts. The lights are placed by the developers of the map, and accessible as [__carla.Light__](python_api.md#carla.Light) objects. Their properties can be changed at will. An instance of [__carla.LightManager__](python_api.md#carla.LightManager) can be retrieved to handle groups of lights.
* __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
current_lights = carla.VehicleLightState.NONE
current_lights |= carla.VehicleLightState.Position
vehicle.set_light_state(current_lights)
```
### Debugging
World objects have a [carla.DebugHelper](python_api.md#carla.DebugHelper) object as a public attribute. It allows for different shapes to be drawn during the simulation. These are used to trace the events happening. The following example would draw a red box at an actor's location and rotation.

3
Docs/download.md
View File

@ -6,7 +6,8 @@
> branch. It contains the very last fixes and features that will be part of the
> next release, but also some experimental changes. Use at your own risk!
- [CARLA Nightly Build](http://carla-assets-internal.s3.amazonaws.com/Releases/Linux/Dev/CARLA_Latest.tar.gz)
- [CARLA Nightly Build (Linux)](https://carla-releases.s3.eu-west-3.amazonaws.com/Linux/Dev/CARLA_Latest.tar.gz)
- [CARLA Nightly Build (Windows)](https://carla-releases.s3.eu-west-3.amazonaws.com/Windows/Dev/CARLA_Latest.zip)
### Development [[Documentation](https://carla.readthedocs.io/en/latest/)]

BIN
Docs/img/Town10.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 161 KiB

BIN
Docs/img/tm_hybrid.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 6.3 MiB

23
Docs/python_api.md
View File

@ -1703,6 +1703,9 @@ Default is 30. Exceeding a speed limit can be done using negative percentages.
- **Parameters:**
- `actor` (_[carla.Actor](#carla.Actor)_) – Vehicle whose speed behaviour is being changed.
- `percentage` (_float_) – Percentage difference between intended speed and the current limit.
- <a name="carla.TrafficManager.get_port"></a>**<font color="#7fb800">get_port</font>**(<font color="#00a6ed">**self**</font>)
Returns the port where the Traffic Manager is connected. If the object is a TM-Client, it will return the port of its TM-Server. Read the [documentation](#adv_traffic_manager.md#multiclient-and-multitm-management) to learn the difference.
- **Return:** _uint16_
- <a name="carla.TrafficManager.set_hybrid_physics_mode"></a>**<font color="#7fb800">set_hybrid_physics_mode</font>**(<font color="#00a6ed">**self**</font>, <font color="#00a6ed">**enabled**=False</font>)
Enables or disables the hybrid physics mode. In this mode, vehicle's farther than a certain radius from the ego vehicle will have their physics disabled. Computation cost will be reduced by not calculating vehicle dynamics. Vehicles will be teleported.
- **Parameters:**
@ -1863,11 +1866,11 @@ Retrieves the traffic light actor affecting this vehicle (if any) according to l
- <a name="carla.Vehicle.get_traffic_light_state"></a>**<font color="#7fb800">get_traffic_light_state</font>**(<font color="#00a6ed">**self**</font>)
The client returns the state of the traffic light affecting this vehicle according to last tick. The method does not call the simulator. If no traffic light is currently affecting the vehicle, returns <b>green</b>.
- **Return:** _[carla.TrafficLightState](#carla.TrafficLightState)_
- <a name="carla.Vehicle.set_autopilot"></a>**<font color="#7fb800">set_autopilot</font>**(<font color="#00a6ed">**self**</font>, <font color="#00a6ed">**enabled**=True</font>, <font color="#00a6ed">**tm**=None</font>)
- <a name="carla.Vehicle.set_autopilot"></a>**<font color="#7fb800">set_autopilot</font>**(<font color="#00a6ed">**self**</font>, <font color="#00a6ed">**enabled**=True</font>, <font color="#00a6ed">**port**=8000</font>)
Registers or deletes the vehicle from a Traffic Manager's list. When __True__, the Traffic Manager passed as parameter will move the vehicle around. The autopilot takes place client-side.
- **Parameters:**
- `enabled` (_bool_)
- `tm` (_[carla.TrafficManager](#carla.TrafficManager)_) – The Traffic Manager where the vehicle is registered or unlisted. If __None__ is passed, it will consider a TM at default port `8000`.
- `port` (_uint16_) – The port of the TM-Server where the vehicle is to be registered or unlisted. If __None__ is passed, it will consider a TM at default port `8000`.
- <a name="carla.Vehicle.set_light_state"></a>**<font color="#7fb800">set_light_state</font>**(<font color="#00a6ed">**self**</font>, <font color="#00a6ed">**light_state**</font>)
Sets the light state of a vehicle using a flag that represents the lights that are on and off.
- **Parameters:**
@ -2211,8 +2214,8 @@ Method to initialize an object defining weather conditions. This class has some
- `precipitation` (_float_) – 0 is no rain at all, 100 a heavy rain.
- `precipitation_deposits` (_float_) – 0 means no puddles on the road, 100 means roads completely capped by rain.
- `wind_intensity` (_float_) – 0 is calm, 100 a strong wind.
- `sun_azimuth_angle` (_float_) – 90 is midday, -90 is midnight.
- `sun_altitude_angle` (_float_) – 0 is an arbitrary North, 180 its corresponding South.
- `sun_azimuth_angle` (_float_) – 0 is an arbitrary North, 180 its corresponding South.
- `sun_altitude_angle` (_float_) – 90 is midday, -90 is midnight.
- `fog_density` (_float_) – Density of the fog, from 0 to 100.
- `fog_distance` (_float_) – Distance where the fog starts in meters.
- `wetness` (_float_) – Humidity percentages of the road, from 0 to 100.
@ -2564,7 +2567,7 @@ Speed to be applied.
---
## command.DestroyActor<a name="command.DestroyActor"></a>
Command adaptation of **<font color="#7fb800">destroy()</font>** in [carla.Actor](#carla.Actor) that tells the simulator to destroy this actor. It has no effect if the actor was already destroyed. When executed with **<font color="#7fb800">apply_batch_synch()</font>** in [carla.Client](#carla.Client) there will be a <b>command.Response</b> that will return a boolean stating whether the actor was successfully destroyed.
Command adaptation of **<font color="#7fb800">destroy()</font>** in [carla.Actor](#carla.Actor) that tells the simulator to destroy this actor. It has no effect if the actor was already destroyed. When executed with **<font color="#7fb800">apply_batch_sync()</font>** in [carla.Client](#carla.Client) there will be a <b>command.Response</b> that will return a boolean stating whether the actor was successfully destroyed.
<h3>Instance Variables</h3>
- <a name="command.DestroyActor.actor_id"></a>**<font color="#f8805a">actor_id</font>** (_int_)
@ -2588,7 +2591,7 @@ A string stating the command has failed.
<h3>Methods</h3>
- <a name="command.Response.has_error"></a>**<font color="#7fb800">has_error</font>**(<font color="#00a6ed">**self**</font>)
Returns <b>True</b> if the command represents a successful execution and <b>False</b> if not.
Returns <b>True</b> if the command execution fails, and <b>False</b> if it was successful.
- **Return:** _bool_
---
@ -2601,15 +2604,15 @@ Command adaptation of **<font color="#7fb800">set_autopilot()</font>** in [carla
Actor that is affected by the command.
- <a name="command.SetAutopilot.enabled"></a>**<font color="#f8805a">enabled</font>** (_bool_)
If autopilot should be activated or not.
- <a name="command.SetAutopilot.tm"></a>**<font color="#f8805a">tm</font>** (_[carla.TrafficManager](#carla.TrafficManager)_)
The Traffic Manager where the vehicle is registered or unlisted.
- <a name="command.SetAutopilot.port"></a>**<font color="#f8805a">port</font>** (_uint16_)
Port of the Traffic Manager where the vehicle is to be registered or unlisted.
<h3>Methods</h3>
- <a name="command.SetAutopilot.__init__"></a>**<font color="#7fb800">\__init__</font>**(<font color="#00a6ed">**self**</font>, <font color="#00a6ed">**actor**</font>, <font color="#00a6ed">**enabled**</font>, <font color="#00a6ed">**tm**=None</font>)
- <a name="command.SetAutopilot.__init__"></a>**<font color="#7fb800">\__init__</font>**(<font color="#00a6ed">**self**</font>, <font color="#00a6ed">**actor**</font>, <font color="#00a6ed">**enabled**</font>, <font color="#00a6ed">**port**=8000</font>)
- **Parameters:**
- `actor` (_[carla.Actor](#carla.Actor) or int_) – Actor or its ID to whom the command will be applied to.
- `enabled` (_bool_)
- `tm` (_[carla.TrafficManager](#carla.TrafficManager)_) – The Traffic Manager where the vehicle is registered or unlisted. If __None__ is passed, it will consider a TM at default port `8000`.
- `port` (_uint16_) – The Traffic Manager port where the vehicle is to be registered or unlisted. If __None__ is passed, it will consider a TM at default port `8000`.
---

34
Docs/tuto_A_add_map.md
View File

@ -128,16 +128,9 @@ Check that there is an `.fbx` and a `.xodr` for each map in the `Import` folder,
make import ARGS="--package package_name --no-carla-materials"
```
After the ingestion, only the pedestrian navigation is yet to be generated. However there are some optional steps that can be done before that.
After the ingestion, only the pedestrian navigation is yet to be generated. However there is an optional step that can be done before that.
* __Create new spawning points.__ These will be used in scripts such as `spawn_npc.py`. Place the spawning point 2 to 3 meters above the ground, and a Route Planner's trigger box below it. Orient both in the same direction. When the vehicle falls into the trigger box, the autopilot will be enabled, and the vehicle will be registered to a Traffic Manager.
![ue_vehicle_spawnpoint](img/ue_vehicle_spawnpoint.png)
* __Add the map to the Unreal packaging system.__ This will include the map along with the rest if a CARLA package is created.
`Edit > Project Settings > Project > Packaging > Show Advanced > List of maps to include...` <br>
![ue_maps_to_include](img/ue_maps_to_include.png)
* __Create new spawning points.__ Place them a over the road, around 0.5/1m so the wheels do not collide with the ground. These will be used in scripts such as `spawn_npc.py`.
### Generate pedestrian navigation
@ -160,11 +153,8 @@ __1.__ Select the __Skybox object__ and add a tag `NoExport` to it. Otherwise, t
__2.__ Check the name of the meshes. By default, pedestrians will be able to walk over sidewalks, crosswalks, and grass (with minor influence over the rest).
If no `.json` is provided, the name must be `map_package`
If you don't have a .json then you don't need to specify a name unless you want to change the default map_package name. That is what I was intending to say, sorry.
* Sidewalk = `Road_Sidewalk`.
* Crosswalk = `Road_Crosswalk`.
* Grass = `Road_Grass`.
![ue_meshes](img/ue_meshes.png)
@ -173,22 +163,20 @@ __3.__ Name these planes following the common format `Road_Crosswalk_mapname`.
__4.__ Press `G` to deselect everything, and export the map. `File > Export CARLA...`. A `map_file.obj` file will be created in `Unreal/CarlaUE4/Saved`.
__5.__ Move the `map_file.obj` and the `map_file.xodr` to `Util/DockerUtils/dist`. There are several scripts there that are going to be used.
__5.__ Move the `map_file.obj` and the `map_file.xodr` to `Util/DockerUtils/dist`.
__6.__ Run the following script to extract the crosswalks from the OpenDRIVE. This will create a `crosswalks.obj`.
__6.__ Run the following command to generate the navigation file.
``` sh
python get_xodr_crosswalks.py -f map_file.xodr
```
__7.__ Combine `map_file.obj` and `crosswalks.obj` running the following script. After that, the `map_file.obj` should contain both.
* __Windows__
```sh
python addOBJ.py map_file.obj crosswalks.obj
build.bat map_file # map_file has no extension
```
__8.__ Create the file describing the pedestrian navigation. A `.bin` will be generated in `Util/DockerUtils/Dist`.
* __Linux__
```sh
./RecastBuilder.sh map_file.obj
./build.sh map_file # map_file has no extension
```
__9.__ Move the `.bin` into the `Nav` folder of the package that contains the map.
__7.__ Move the `.bin` into the `Nav` folder of the package that contains the map.
---
## Deprecated ways to import a map

2
Docs/tuto_G_retrieve_data.md
View File

@ -198,7 +198,7 @@ python spawn_npc.py -n 50 -w 50 --safe
--safe avoid spawning vehicles prone to accidents
--filterv PATTERN vehicles filter (default: "vehicle.*")
--filterw PATTERN pedestrians filter (default: "walker.pedestrian.*")
-tm_p P, --tm_port P port to communicate with TM (default: 8000)
-tm_p P, --tm-port P port to communicate with TM (default: 8000)
--sync Synchronous mode execution
```
</details>

8
PythonAPI/docs/actor.yml
View File

@ -216,11 +216,11 @@
- param_name: enabled
type: bool
default: True
- param_name: tm
type: carla.TrafficManager
default: None
- param_name: port
type: uint16
default: 8000
doc: >
The Traffic Manager where the vehicle is registered or unlisted. If __None__ is passed, it will consider a TM at default port `8000`.
The port of the TM-Server where the vehicle is to be registered or unlisted. If __None__ is passed, it will consider a TM at default port `8000`.
doc: >
Registers or deletes the vehicle from a Traffic Manager's list. When __True__, the Traffic Manager passed as parameter will move the vehicle around. The autopilot takes place client-side.
# --------------------------------------

6
PythonAPI/docs/client.yml
View File

@ -396,6 +396,12 @@
Default is 30. Exceeding a speed limit can be done using negative percentages.
# --------------------------------------
- def_name: get_port
params:
return: uint16
doc: >
Returns the port where the Traffic Manager is connected. If the object is a TM-Client, it will return the port of its TM-Server. Read the [documentation](#adv_traffic_manager.md#multiclient-and-multitm-management) to learn the difference.
# --------------------------------------
- def_name: set_hybrid_physics_mode
params:
- param_name: enabled

18
PythonAPI/docs/commands.yml
View File

@ -23,7 +23,7 @@
return: bool
params:
doc: >
Returns <b>True</b> if the command represents a successful execution and <b>False</b> if not.
Returns <b>True</b> if the command execution fails, and <b>False</b> if it was successful.
# --------------------------------------
- class_name: SpawnActor
@ -73,7 +73,7 @@
- class_name: DestroyActor
# - DESCRIPTION ------------------------
doc: >
Command adaptation of **<font color="#7fb800">destroy()</font>** in carla.Actor that tells the simulator to destroy this actor. It has no effect if the actor was already destroyed. When executed with **<font color="#7fb800">apply_batch_synch()</font>** in carla.Client there will be a <b>command.Response</b> that will return a boolean stating whether the actor was successfully destroyed.
Command adaptation of **<font color="#7fb800">destroy()</font>** in carla.Actor that tells the simulator to destroy this actor. It has no effect if the actor was already destroyed. When executed with **<font color="#7fb800">apply_batch_sync()</font>** in carla.Client there will be a <b>command.Response</b> that will return a boolean stating whether the actor was successfully destroyed.
# - PROPERTIES -------------------------
instance_variables:
- var_name: actor_id
@ -318,10 +318,10 @@
type: bool
doc: >
If autopilot should be activated or not.
- var_name: tm
type: carla.TrafficManager
- var_name: port
type: uint16
doc: >
The Traffic Manager where the vehicle is registered or unlisted.
Port of the Traffic Manager where the vehicle is to be registered or unlisted.
# - METHODS ----------------------------
methods:
- def_name: __init__
@ -332,10 +332,10 @@
Actor or its ID to whom the command will be applied to.
- param_name: enabled
type: bool
- param_name: tm
type: carla.TrafficManager
default: None
- param_name: port
type: uint16
default: 8000
doc: >
The Traffic Manager where the vehicle is registered or unlisted. If __None__ is passed, it will consider a TM at default port `8000`.
The Traffic Manager port where the vehicle is to be registered or unlisted. If __None__ is passed, it will consider a TM at default port `8000`.
# --------------------------------------
...

4
PythonAPI/docs/weather.yml
View File

@ -83,12 +83,12 @@
type: float
default: 0.0
doc: >
90 is midday, -90 is midnight.
0 is an arbitrary North, 180 its corresponding South.
- param_name: sun_altitude_angle
type: float
default: 0.0
doc: >
0 is an arbitrary North, 180 its corresponding South.
90 is midday, -90 is midnight.
- param_name: fog_density
type: float
default: 0.0

8
mkdocs.yml
View File

@ -19,10 +19,10 @@ nav:
- 'F.A.Q.': 'build_faq.md'
- First steps:
- 'Core concepts': 'core_concepts.md'
- '1st. World and client': 'core_world.md'
- '2nd. Actors and blueprints': 'core_actors.md'
- '3rd. Maps and navigation': 'core_map.md'
- '4th. Sensors and data': 'core_sensors.md'
- '1st- World and client': 'core_world.md'
- '2nd- Actors and blueprints': 'core_actors.md'
- '3rd- Maps and navigation': 'core_map.md'
- '4th- Sensors and data': 'core_sensors.md'
- Advanced steps:
- 'OpenDRIVE standalone mode': 'adv_opendrive.md'
- 'PTV-Vissim co-simulation': 'adv_ptv.md'