diff --git a/.github/issue_template.md b/.github/issue_template.md
index d4909e2f0..d7542eb6d 100644
--- a/.github/issue_template.md
+++ b/.github/issue_template.md
@@ -2,9 +2,17 @@
Thanks for contributing to CARLA!
+If you are reporting an issue, please use the following outline:
+
+CARLA version:
+Platform/OS:
+Problem you have experienced:
+What you expected to happen:
+Steps to reproduce:
+Other information (documentation you consulted, workarounds you tried):
+
If you are asking a question please make sure your question was not asked before
-by searching among the existing issues. Also make sure you have read our
-documentation and FAQ at http://carla.readthedocs.io.
+by searching among the existing issues and checking the CARLA forum https://github.com/carla-simulator/carla/discussions. Also make sure you have read ourdocumentation and FAQ at http://carla.readthedocs.io.
If your question is about creating content (assets, levels) you'll most likely
have all the info you need in the Unreal Engine's documentation
@@ -13,7 +21,4 @@ https://docs.unrealengine.com
Please, keep the threads focused and single-themed. Make them easy to find
for everyone.
-If you are reporting an issue, please provide the CARLA version number you are
-using and your Platform/OS.
-
--->
+-->
\ No newline at end of file
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 4ddf6458c..eb8dde331 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,3 +1,52 @@
+## CARLA 0.9.12
+
+ * Changed the resolution of the cached map in Traffic Manager from 0.1 to 5 meters
+ * Fixed import sumo_integration module from other scripts
+ * CARLA now is built with Visual Studio 2019 in Windows
+ * Fixed bug causing the RoadOptions at the BehaviorAgent to not work as intended
+ * Upgrading to Unreal Engine 4.26
+ * Added generation attribute to vehicles and pedestrians
+ * Added Lincoln 2020 vehicle dimensions for CarSim integration
+ * Enabling the **no_delay** option to RPC and stream sockets
+ * The special nomenclature to define roads (ROAD_ROAD), sidewalks (ROAD_SIDEWALK)... can be at any position of the asset name
+ * Improved performance bencharmark script: sync, map and sensor selection, ...
+ * Improved performance, destroyed PhysX state for vehicles when physics are disable
+ * Improved parallelism of raycast sensors in system with large number of cores
+ * Added 'visualize_multiple_sensors' example
+ * Added 'check_lidar_bb' util script
+ * Added optional flag to `client.replay_file()` `replay_sensors` to enable or disable the replaying the sensors
+ * Improved manual_control: now cameras are set in relation with car size
+ * Client required files are sent from the server to a local cache (OpenDRIVE, Traffic Manager...)
+ * Added CHRONO library for vehicle dynamics simulation (https://projectchrono.org/)
+ - Supported JSON vehicle definition
+ - Unsupported collision dynamics
+ * Added performance benchmarking section to documentation
+ * Added API functions to traffic light actor `get_effect_waypoints()`, `get_light_boxes()` and `get_opendrive_id()`
+ * Added API functions to world `get_traffic_lights_from_waypoint()`, `get_traffic_lights_in_junction` and `get_traffic_light_from_opendrive_id`
+ * Added API parameters to `WorldSettings`: `tile_stream_distance` and `actor_active_distance`
+ * Added API parameters and functions to `Osm2OdrSettings`: `proj_string`, `center_map`, `generate_traffic_lights`, `all_junctions_with_traffic_lights`, `set_osm_way_types`, and `set_traffic_light_excluded_way_types`
+ * Added API function to enable car telemetry
+ * CARLA is compatible with the last RoadRunner nomenclature for road assets
+ * Fixed a bug when importing a FBX map with some **_** in the FBX name
+ * Extended make import process for applying road painter materials (carla art tool)
+ * Added Large Map feature to CARLA, alowing to import large maps divided in square tiles (at most 2kmx2km per tile). Only section of a Large Map can be loaded at a time which introduces a sleep state for actors that are far away from the hero vehicle
+ * Added creation of custom JSON file for applying decals to imported roads
+ * Added ApplyVehiclePhysicsControl to commands
+ * Added flush in the sublevel loading to increase carla's determinism in Opt maps
+ * Fix bug in carla.Transform.get_up_vector()
+ * Fix bug in lidar channel point count
+ * Fix imu: some weird cases were given nan values
+ * Fix bugs in apply_physics_control and friction trigger
+ * Exposed tire parameters for longitudinal and lateral stiffness in the PhysicsControl.
+ * When setting a global plan at the LocalPlanner, it is now optional to stop the automatic fill of the waypoint buffer
+ * Improved agent's vehicle detection to also take into account the actor bounding boxes
+ * Added Optical Flow camera
+ * API extensions:
+ - Added `set_wheel_steer_direction()` function to change the bone angle of each wheel of a vehicle
+ - Added `get_wheel_steer_angle()` function to get the steer angle of a vehicle wheel
+ - Added `scattering_intensity` , `mie_scattering_scale` , `rayleigh_scattering_scale` to PythonAPI for changing weather attributes
+ - Improved the python agents API. Old behaviors have been improved and new ones have also been added, improving the functionalities of the agents. Several bugs have also been fixed
+
## CARLA 0.9.11
* Improved the documentation for use with pandoc tool by converting html tags to their markdown equivalent
diff --git a/Co-Simulation/Carsim/Lincoln2020/Sprung_Mass.png b/Co-Simulation/Carsim/Lincoln2020/Sprung_Mass.png
new file mode 100644
index 000000000..0fb59fc65
Binary files /dev/null and b/Co-Simulation/Carsim/Lincoln2020/Sprung_Mass.png differ
diff --git a/Co-Simulation/Carsim/Lincoln2020/Vehicle_Thumb.png b/Co-Simulation/Carsim/Lincoln2020/Vehicle_Thumb.png
new file mode 100644
index 000000000..fe3328141
Binary files /dev/null and b/Co-Simulation/Carsim/Lincoln2020/Vehicle_Thumb.png differ
diff --git a/Co-Simulation/Carsim/Lincoln2020/Vehicles/Assembly/Lincoln2020.png b/Co-Simulation/Carsim/Lincoln2020/Vehicles/Assembly/Lincoln2020.png
new file mode 100644
index 000000000..59af8243f
Binary files /dev/null and b/Co-Simulation/Carsim/Lincoln2020/Vehicles/Assembly/Lincoln2020.png differ
diff --git a/Co-Simulation/Carsim/Lincoln2020/Vehicles/Sprung_Mass/Lincoln2020.par b/Co-Simulation/Carsim/Lincoln2020/Vehicles/Sprung_Mass/Lincoln2020.par
new file mode 100644
index 000000000..7d4b12549
--- /dev/null
+++ b/Co-Simulation/Carsim/Lincoln2020/Vehicles/Sprung_Mass/Lincoln2020.par
@@ -0,0 +1,49 @@
+PARSFILE
+#FullDataName Vehicle: Sprung Mass`Lincoln 2020`CARLA
+#VehCode Rigid sprung mass
+#RingCtrl0 0
+#CheckBox2 0
+X_LENGTH 2860
+Y_LENGTH 1500
+iaxle 2
+iside 1
+LX_AXLE 2860
+LX_CG_SU 1471
+M_SU 2404
+IXX_SU 536.6
+IYY_SU 1536.7
+IZZ_SU 1536.7
+IXZ_SU 0
+*RX 0.472
+*RY 0.800
+*RZ 0.800
+Y_CG_SU 0
+H_CG_SU 359
+IXY_SU 0
+IYZ_SU 0
+Z_LENGTH 1300
+Y_LENGTH 1800
+*HWC_LF 359
+*HWC_RF 359
+*HWC_LR 359
+*HWC_RR 359
+H_WC 359
+iside 2
+H_WC 359
+iaxle 1
+iside 1
+H_WC 359
+iside 2
+H_WC 359
+iaxle 2
+iside 1
+
+LOG_ENTRY Used Dataset: Vehicle: Sprung Mass; { CARLA } Lincoln 2020
+#Library : Vehicle: Sprung Mass
+#DataSet : Lincoln 2020
+#Category: CARLA
+#FileID : SprMass_d80b7dcb-e4b1-4456-9d41-6fc41b8cd79a
+#Product : CarSim 2020.0
+#VehCode Rigid sprung mass
+
+END
diff --git a/Co-Simulation/PTV-Vissim/data/vtypes.json b/Co-Simulation/PTV-Vissim/data/vtypes.json
index 083c4f56e..0947130a9 100644
--- a/Co-Simulation/PTV-Vissim/data/vtypes.json
+++ b/Co-Simulation/PTV-Vissim/data/vtypes.json
@@ -5,10 +5,10 @@
"vehicle.bmw.grandtourer",
"vehicle.citroen.c3",
"vehicle.jeep.wrangler_rubicon",
- "vehicle.lincoln.mkz2017",
- "vehicle.mercedes-benz.coupe",
- "vehicle.mini.cooperst",
- "vehicle.mustang.mustang",
+ "vehicle.lincoln.mkz_2017",
+ "vehicle.mercedes.coupe",
+ "vehicle.mini.cooper_s",
+ "vehicle.ford.mustang",
"vehicle.nissan.micra",
"vehicle.nissan.patrol",
"vehicle.seat.leon",
diff --git a/Co-Simulation/Sumo/data/vtypes.json b/Co-Simulation/Sumo/data/vtypes.json
index 6bb1436da..b78ae48b3 100644
--- a/Co-Simulation/Sumo/data/vtypes.json
+++ b/Co-Simulation/Sumo/data/vtypes.json
@@ -24,16 +24,16 @@
"vehicle.jeep.wrangler_rubicon": {
"vClass": "passenger"
},
- "vehicle.lincoln.mkz2017": {
+ "vehicle.lincoln.mkz_2017": {
"vClass": "passenger"
},
- "vehicle.mercedes-benz.coupe": {
+ "vehicle.mercedes.coupe": {
"vClass": "passenger"
},
- "vehicle.mini.cooperst": {
+ "vehicle.mini.cooper_s": {
"vClass": "passenger"
},
- "vehicle.mustang.mustang": {
+ "vehicle.ford.mustang": {
"vClass": "passenger"
},
"vehicle.nissan.micra": {
@@ -49,11 +49,11 @@
"vClass": "passenger",
"guiShape": "passenger/van"
},
- "vehicle.dodge_charger.police": {
+ "vehicle.dodge.charger_police": {
"vClass": "authority",
"guiShape": "police"
},
- "vehicle.bmw.isetta": {
+ "vehicle.micro.microlino": {
"vClass": "evehicle"
},
"vehicle.toyota.prius": {
diff --git a/Co-Simulation/Sumo/examples/carlavtypes.rou.xml b/Co-Simulation/Sumo/examples/carlavtypes.rou.xml
index 10c794bcd..966b2b31a 100644
--- a/Co-Simulation/Sumo/examples/carlavtypes.rou.xml
+++ b/Co-Simulation/Sumo/examples/carlavtypes.rou.xml
@@ -4,17 +4,17 @@
-
+
-
-
+
+
-
+
-
+
@@ -23,7 +23,7 @@
-
+
diff --git a/Co-Simulation/Sumo/examples/rou/Town01.rou.xml b/Co-Simulation/Sumo/examples/rou/Town01.rou.xml
index 9007ca4a9..ba84ae1ed 100644
--- a/Co-Simulation/Sumo/examples/rou/Town01.rou.xml
+++ b/Co-Simulation/Sumo/examples/rou/Town01.rou.xml
@@ -9,13 +9,13 @@
-
+
-
+
@@ -33,10 +33,10 @@
-
+
-
+
@@ -54,19 +54,19 @@
-
+
-
+
-
+
-
+
@@ -78,7 +78,7 @@
-
+
@@ -90,7 +90,7 @@
-
+
@@ -102,7 +102,7 @@
-
+
@@ -120,25 +120,25 @@
-
+
-
+
-
+
-
+
-
+
@@ -150,10 +150,10 @@
-
+
-
+
@@ -168,19 +168,19 @@
-
+
-
+
-
+
-
+
@@ -204,13 +204,13 @@
-
+
-
+
-
+
@@ -222,7 +222,7 @@
-
+
@@ -234,10 +234,10 @@
-
+
-
+
@@ -252,28 +252,28 @@
-
+
-
+
-
+
-
+
-
+
diff --git a/Co-Simulation/Sumo/examples/rou/Town04.rou.xml b/Co-Simulation/Sumo/examples/rou/Town04.rou.xml
index ec5075b3b..688743c4d 100644
--- a/Co-Simulation/Sumo/examples/rou/Town04.rou.xml
+++ b/Co-Simulation/Sumo/examples/rou/Town04.rou.xml
@@ -3,25 +3,25 @@
-
+
-
+
-
+
-
+
-
+
@@ -51,7 +51,7 @@
-
+
@@ -60,7 +60,7 @@
-
+
@@ -69,7 +69,7 @@
-
+
@@ -78,7 +78,7 @@
-
+
@@ -87,7 +87,7 @@
-
+
@@ -96,7 +96,7 @@
-
+
@@ -129,10 +129,10 @@
-
+
-
+
@@ -141,19 +141,19 @@
-
+
-
+
-
+
@@ -168,10 +168,10 @@
-
+
-
+
@@ -180,7 +180,7 @@
-
+
@@ -198,7 +198,7 @@
-
+
@@ -216,10 +216,10 @@
-
+
-
+
@@ -234,10 +234,10 @@
-
+
-
+
@@ -273,7 +273,7 @@
-
+
@@ -288,7 +288,7 @@
-
+
@@ -309,16 +309,16 @@
-
+
-
+
-
+
@@ -327,7 +327,7 @@
-
+
@@ -339,13 +339,13 @@
-
+
-
+
@@ -363,13 +363,13 @@
-
+
-
+
@@ -384,7 +384,7 @@
-
+
@@ -393,13 +393,13 @@
-
+
-
+
@@ -411,7 +411,7 @@
-
+
@@ -426,7 +426,7 @@
-
+
@@ -438,7 +438,7 @@
-
+
@@ -453,7 +453,7 @@
-
+
@@ -468,7 +468,7 @@
-
+
@@ -480,7 +480,7 @@
-
+
@@ -489,7 +489,7 @@
-
+
@@ -504,7 +504,7 @@
-
+
@@ -528,25 +528,25 @@
-
+
-
+
-
+
-
+
@@ -573,7 +573,7 @@
-
+
@@ -585,13 +585,13 @@
-
+
-
+
-
+
diff --git a/Co-Simulation/Sumo/examples/rou/Town05.rou.xml b/Co-Simulation/Sumo/examples/rou/Town05.rou.xml
index 1dd0a6c02..3e8689592 100644
--- a/Co-Simulation/Sumo/examples/rou/Town05.rou.xml
+++ b/Co-Simulation/Sumo/examples/rou/Town05.rou.xml
@@ -3,7 +3,7 @@
-
+
@@ -30,13 +30,13 @@
-
+
-
+
@@ -51,16 +51,16 @@
-
+
-
+
-
+
@@ -72,13 +72,13 @@
-
+
-
+
@@ -93,13 +93,13 @@
-
+
-
+
@@ -117,7 +117,7 @@
-
+
@@ -132,19 +132,19 @@
-
+
-
+
-
+
@@ -153,7 +153,7 @@
-
+
@@ -180,7 +180,7 @@
-
+
@@ -237,7 +237,7 @@
-
+
@@ -249,7 +249,7 @@
-
+
@@ -276,10 +276,10 @@
-
+
-
+
@@ -288,7 +288,7 @@
-
+
@@ -300,7 +300,7 @@
-
+
@@ -309,7 +309,7 @@
-
+
@@ -336,13 +336,13 @@
-
+
-
+
@@ -351,7 +351,7 @@
-
+
@@ -375,13 +375,13 @@
-
+
-
+
-
+
@@ -390,19 +390,19 @@
-
+
-
+
-
+
-
+
@@ -450,7 +450,7 @@
-
+
@@ -459,16 +459,16 @@
-
+
-
+
-
+
@@ -492,7 +492,7 @@
-
+
@@ -501,7 +501,7 @@
-
+
@@ -510,10 +510,10 @@
-
+
-
+
@@ -528,10 +528,10 @@
-
+
-
+
@@ -540,7 +540,7 @@
-
+
@@ -552,10 +552,10 @@
-
+
-
+
@@ -573,19 +573,19 @@
-
+
-
+
-
+
@@ -594,7 +594,7 @@
-
+
diff --git a/Co-Simulation/Sumo/requirements.txt b/Co-Simulation/Sumo/requirements.txt
index ee1cba5c8..5d7ded3c7 100644
--- a/Co-Simulation/Sumo/requirements.txt
+++ b/Co-Simulation/Sumo/requirements.txt
@@ -1 +1 @@
-lxml==4.5.0
+lxml==4.6.2
diff --git a/Co-Simulation/Sumo/spawn_npc_sumo.py b/Co-Simulation/Sumo/spawn_npc_sumo.py
index 1dd28d947..226729f90 100644
--- a/Co-Simulation/Sumo/spawn_npc_sumo.py
+++ b/Co-Simulation/Sumo/spawn_npc_sumo.py
@@ -143,10 +143,13 @@ def main(args):
blueprints = [
x for x in blueprints if vtypes[x]['vClass'] not in ('motorcycle', 'bicycle')
]
- blueprints = [x for x in blueprints if not x.endswith('isetta')]
+ blueprints = [x for x in blueprints if not x.endswith('microlino')]
blueprints = [x for x in blueprints if not x.endswith('carlacola')]
blueprints = [x for x in blueprints if not x.endswith('cybertruck')]
blueprints = [x for x in blueprints if not x.endswith('t2')]
+ blueprints = [x for x in blueprints if not x.endswith('sprinter')]
+ blueprints = [x for x in blueprints if not x.endswith('firetruck')]
+ blueprints = [x for x in blueprints if not x.endswith('ambulance')]
if not blueprints:
raise RuntimeError('No blueprints available due to user restrictions.')
@@ -165,10 +168,15 @@ def main(args):
vclass = vtypes[type_id]['vClass']
allowed_edges = [e for e in sumo_edges if e.allows(vclass)]
- edge = random.choice(allowed_edges)
+ if allowed_edges:
+ edge = random.choice(allowed_edges)
- traci.route.add('route_{}'.format(i), [edge.getID()])
- traci.vehicle.add('sumo_{}'.format(i), 'route_{}'.format(i), typeID=type_id)
+ traci.route.add('route_{}'.format(i), [edge.getID()])
+ traci.vehicle.add('sumo_{}'.format(i), 'route_{}'.format(i), typeID=type_id)
+ else:
+ logging.error(
+ 'Could not found a route for %s. No vehicle will be spawned in sumo',
+ type_id)
while True:
start = time.time()
diff --git a/Co-Simulation/Sumo/sumo_integration/bridge_helper.py b/Co-Simulation/Sumo/sumo_integration/bridge_helper.py
index 8a2a907e5..c922e48cd 100644
--- a/Co-Simulation/Sumo/sumo_integration/bridge_helper.py
+++ b/Co-Simulation/Sumo/sumo_integration/bridge_helper.py
@@ -14,6 +14,7 @@
import json
import logging
import math
+import os
import random
import carla # pylint: disable=import-error
@@ -34,7 +35,9 @@ class BridgeHelper(object):
blueprint_library = []
offset = (0, 0)
- with open('data/vtypes.json') as f:
+ _vtypes_path = os.path.join(os.path.dirname(os.path.realpath(__file__)), "..", "data",
+ "vtypes.json")
+ with open(_vtypes_path) as f:
_VTYPES = json.load(f)['carla_blueprints']
@staticmethod
diff --git a/Co-Simulation/Sumo/sumo_integration/sumo_simulation.py b/Co-Simulation/Sumo/sumo_integration/sumo_simulation.py
index 05d38a2f2..7756ff80a 100644
--- a/Co-Simulation/Sumo/sumo_integration/sumo_simulation.py
+++ b/Co-Simulation/Sumo/sumo_integration/sumo_simulation.py
@@ -335,8 +335,8 @@ class SumoSimulation(object):
# Retrieving net from configuration file.
self.net = _get_sumo_net(cfg_file)
- # Creating a random route to be able to spawn carla actors.
- traci.route.add("carla_route", [traci.edge.getIDList()[0]])
+ # To keep track of the vehicle classes for which a route has been generated in sumo.
+ self._routes = set()
# Variable to asign an id to new added actors.
self._sequential_id = 0
@@ -424,7 +424,20 @@ class SumoSimulation(object):
"""
actor_id = 'carla' + str(self._sequential_id)
try:
- traci.vehicle.add(actor_id, 'carla_route', typeID=type_id)
+ vclass = traci.vehicletype.getVehicleClass(type_id)
+ if vclass not in self._routes:
+ logging.debug('Creating route for %s vehicle class', vclass)
+ allowed_edges = [e for e in self.net.getEdges() if e.allows(vclass)]
+ if allowed_edges:
+ traci.route.add("carla_route_{}".format(vclass), [allowed_edges[0].getID()])
+ self._routes.add(vclass)
+ else:
+ logging.error(
+ 'Could not found a route for %s. No vehicle will be spawned in sumo',
+ type_id)
+ return INVALID_ACTOR_ID
+
+ traci.vehicle.add(actor_id, 'carla_route_{}'.format(vclass), typeID=type_id)
except traci.exceptions.TraCIException as error:
logging.error('Spawn sumo actor failed: %s', error)
return INVALID_ACTOR_ID
diff --git a/Docs/adv_agents.md b/Docs/adv_agents.md
new file mode 100644
index 000000000..eb299052f
--- /dev/null
+++ b/Docs/adv_agents.md
@@ -0,0 +1,199 @@
+# CARLA Agents
+
+CARLA Agent scripts allow a vehicle to either follow a random, endless route or take the shortest route to a given destination. Agents obey traffic lights and react to other obstacles in the road. There are three agent types available. Parameters such as target speed, braking distance, tailgating behavior, and more can be modified. Actor classes can be modified or used as a base class to create custom agents according to the user's needs.
+
+- [__Overview of agent scripts__](#overview-of-agent-scripts)
+ - [Planning and control](#planning-and-control)
+ - [Agent behaviors](#agent-behaviors)
+- [__Implement an agent__](#implement-an-agent)
+- [__Behavior types__](#behavior-types)
+ - [Create your own behavior type](#create-your-own-behavior-type)
+- [__Creating an agent__](#creating-an-agent)
+
+---
+
+## Overview of agent scripts
+
+The main scripts involved in the CARLA Agents are found in `PythonAPI/carla/agents/navigation`. They fall into two categories; __planning and control__ and __agent behaviors__.
+
+### Planning and control
+
+- __`controller.py`:__ Combines longitudinal and lateral PID controllers into a single class, __VehiclePIDController__, used for low-level control of vehicles from the client side of CARLA.
+- __`global_route_planner.py`:__ Gets detailed topology from the CARLA server to build a graph representation of the world map, providing waypoint and road option information for the __Local Planner__.
+- __`local_planner.py`:__ Follows waypoints based on control inputs from the __VehiclePIDController__. Waypoints can either be provided by the __Global Route Planner__ or be calculated dynamically, choosing random paths at junctions, similar to the [Traffic Manager](adv_traffic_manager.md).
+
+### Agent behaviors
+
+- __`basic_agent.py`:__ Contains an agent base class that implements a __Basic Agent__ that roams around the map or reaches a target destination in the shortest distance possible, avoiding other vehicles, responding to traffic lights but ignoring stop signs.
+- __`behavior_agent.py`:__ Contains a class that implements a more complex __Behavior Agent__ that can reach a target destination in the shortest distance possible, following traffic lights, signs, and speed limits while tailgating other vehicles. There are three predefined types that condition how the agent behaves.
+- __`behavior_types.py`:__ Contains the parameters for the behavior types that condition the __Behavior Agent__; Cautious, Normal, and Aggressive.
+
+---
+
+## Implement an agent
+
+This section will explain how to use the example CARLA Agent classes in your own scripts. At the end of the section, you will find out how to run an example script that shows the different agents in action.
+
+__1.__ Import the agent class you want to use:
+
+```py
+# To import a basic agent
+from agents.navigation.basic_agent import BasicAgent
+
+# To import a behavior agent
+from agents.navigation.behavior_agent import BehaviorAgent
+```
+
+__2.__ Any vehicle can be turned into an agent. [Spawn a vehicle](core_actors.md#spawning) and pass it as an argument to the agent class to instantiate it:
+
+```py
+# To start a basic agent
+agent = BasicAgent(vehicle)
+
+# To start a behavior agent with an aggressive profile
+agent = BehaviorAgent(vehicle, behavior='aggressive')
+```
+
+Read more about behavior types and how to configure your own in the section [__behavior types__](#behavior-types).
+
+__3.__ You can set a destination for the agent to travel to. If you don't set a destination for the agent, it will roam endlessly around the map. To set the destination, provide the agent with a [location](python_api.md#carlalocation):
+
+```py
+destination = random.choice(spawn_points).location
+agent.set_destination(destination)
+```
+
+__5.__ Vehicle controls and behaviors are applied during a navigation step. During each step, the __Basic Agent__ will apply a vehicle control and react to any vehicles or traffic lights by performing an emergency stop. The __Behavior Agent__ will react to traffic lights, avoid pedestrians, follow cars and navigate intersections according to the behavior type you applied:
+
+```py
+while True:
+ vehicle.apply_control(agent.run_step())
+```
+
+__6.__ You can check if the agent has finished its trajectory and perform an action when that happens. The following snippet will end the simulation once your vehicle has reached its destination:
+
+```py
+while True:
+ if agent.done():
+ print("The target has been reached, stopping the simulation")
+ break
+
+ vehicle.apply_control(agent.run_step())
+```
+
+__7.__ Instead of finishing the simulation when an agent has reached its target destination, a new, random route can be generated for the agent to follow:
+
+```py
+while True:
+ if agent.done():
+ agent.set_destination(random.choice(spawn_points).location)
+ print("The target has been reached, searching for another target")
+
+ vehicle.apply_control(agent.run_step())
+```
+
+The __Basic Agent__ provides a few methods to manipulate agent behavior or program routes to follow:
+
+- __`set_target_speed(speed)`:__ Set the target speed in km/h
+- __`follow_speed_limits(value=True)`:__ Sets the agent to follow speed limits.
+- __`set_destination(end_location, start_location=None)`:__ The agent will travel from a specific start location to an end location via the shortest route possible. If no start location is provided, it will use the current agent location.
+- __`set_global_plan(plan, stop_waypoint_creation=True, clean_queue=True)`:__ Adds a specific plan for the agent to follow. The plan argument should consist of a list of `[carla.Waypoint, RoadOption]` that will be the path the agent needs to take. `stop_waypoint_creation` will prevent waypoints from being automatically created once the path has run its course. `clean_queue` will reset the agent's current plan.
+- __`trace_route(start_waypoint, end_waypoint)`:__ Gets the shortest distance between two waypoints from the Global Route Planner and returns the path as a list of `[carla.Waypoint, RoadOption]` for the agent to follow.
+- __`ignore_traffic_lights(active=True)`:__ Set the agent to ignore or obey traffic lights.
+- __`ignore_stop_signs(active=True)`:__ Set the agent to ignore or obey stop signs.
+- __`ignore_vehicles(active=True)`:__ Set the agent to ignore or react to other vehicles.
+
+The `automatic_control.py` script, found in `PythonAPI/examples`, is an example of the Basic and Behavior Agents in action. To try the script, navigate to the example directory and run the following command:
+
+```sh
+# To run with a basic agent
+python3 automatic_control.py --agent=Basic
+
+# To run with a behavior agent
+python3 automatic_control.py --agent=Behavior --behavior=aggressive
+```
+
+---
+
+## Behavior types
+
+Behavior types for the behavior agent are defined in `behavior_types.py`. The three pre-configured profiles are __'cautious'__, __'normal'__, and __'aggressive'__. You can use the set profiles, modify them or create your own. The following variables can be adjusted:
+
+- __`max_speed`__: The maximum speed in km/h your vehicle will be able to reach.
+- __`speed_lim_dist`__: Value in km/h that defines how far your vehicle's target speed will be from the current speed limit (e.g., if the speed limit is 30km/h and `speed_lim_dist` is 10km/h, then the target speed will be 20km/h)
+- __`speed_decrease`__: How quickly in km/h your vehicle will slow down when approaching a slower vehicle ahead.
+- __`safety_time`__: Time-to-collision; an approximation of the time it will take for your vehicle to collide with one in front if it brakes suddenly.
+- __`min_proximity_threshold`__: The minimum distance in meters from another vehicle or pedestrian before your vehicle performs a maneuver such as avoidance, or tailgating.
+- __`braking_distance`__: The distance from a pedestrian or vehicle at which your vehicle will perform an emergency stop.
+- __`tailgate_counter`__: A counter to avoid tailgating too quickly after the last tailgate.
+
+## Create your own behavior type
+
+To create your own behavior type:
+
+__1.__ Create the class for your behavior type in `behavior_types.py`:
+
+```py
+class ProfileName(object):
+ # complete value definitions
+```
+
+__2.__ Define and instantiate your behavior type in the `behavior_agent.py` script:
+
+```py
+# Parameters for agent behavior
+if behavior == 'cautious':
+ self._behavior = Cautious()
+
+elif behavior == 'normal':
+ self._behavior = Normal()
+
+elif behavior == 'aggressive':
+ self._behavior = Aggressive()
+
+elif behavior == '':
+ self._behavior = ()
+```
+
+---
+
+## Creating an agent
+
+The CARLA Agents are just examples of the kind of agents users can run. Users can build upon the __Basic Agent__ to create their own agents. The possibilities are endless. There are only two elements that are necessary for every agent, __the initialization__ and the __run step__.
+
+Find an example of a minimal layout of a custom agent below:
+
+```py
+import carla
+
+from agents.navigation.basic_agent import BasicAgent
+
+class CustomAgent(BasicAgent):
+ def __init__(self, vehicle, target_speed=20, debug=False):
+ """
+ :param vehicle: actor to apply to local planner logic onto
+ :param target_speed: speed (in Km/h) at which the vehicle will move
+ """
+ super().__init__(target_speed, debug)
+
+ def run_step(self, debug=False):
+ """
+ Execute one step of navigation.
+ :return: carla.VehicleControl
+ """
+ # Actions to take during each simulation step
+ control = carla.VehicleControl()
+ return control
+```
+
+Check out the `basic_agent.py` and `behavior_agent.py` scripts to explore their structure and functions for more ideas on how to create your own.
+
+---
+
+You can explore the provided agent scripts, expand upon them or use them as a baseline to create your own. If you have any questions about the agents, feel free to post in the [forum](https://github.com/carla-simulator/carla/discussions/).
+
+
+
+
+
+
diff --git a/Docs/adv_benchmarking.md b/Docs/adv_benchmarking.md
new file mode 100644
index 000000000..8027c829a
--- /dev/null
+++ b/Docs/adv_benchmarking.md
@@ -0,0 +1,203 @@
+# Benchmarking Performance
+
+We provide a benchmarking script to enable users to easily analyze the performance of CARLA in their own environment. The script can be configured to run a number of scenarios that combine different maps, sensors and weather conditions. It reports the average and standard deviation of FPS under the requested scenarios.
+
+In this section we detail the requirements to run the benchmark, where to find the script, the flags available to customize the scenarios that are run and examples on how to run the commands.
+
+We have also included our results of a separate benchmark which measures performance in CARLA in a specific environment when using different combinations of number of vehicles, enabling physics and/or enabling Traffic Manager. The results are presented alongside the CARLA version used and the environment the test was performed in.
+
+- [__The benchmark script__](#the-benchmark-script)
+ - [__Before you begin__](#before-you-begin)
+ - [__Synopsis__](#synopsis)
+ - [__Flags__](#flags)
+- [__CARLA performance report__](#carla-performance-report)
+
+
+---
+## The benchmark script
+
+The benchmark script can be found in `PythonAPI/util`. It has several flags available to customize the scenarios to be tested which are detailed in the synopsis below.
+
+
+### Before you begin
+
+The benchmarking script requires some dependencies to be installed before you can run it:
+
+```python
+python -m pip install -U py-cpuinfo==5.0.0
+python -m pip install psutil
+python -m pip install python-tr
+python -m pip install gpuinfo
+python -m pip install GPUtil
+```
+
+### Synopsis
+
+`python3` [`performance_benchmark.py`](https://github.com/carla-simulator/carla/blob/master/PythonAPI/util/performance_benchmark.py) [`[--host HOST]`](#-host-ip_address) [`[--port PORT]`](#-port-port) [`[--file FILE]`](#-file-filenamemd) [`[--tm]`](#-tm)
+[`[--ticks TICKS]`](#-ticks) [`[--sync]`](#-sync) [`[--async]`](#-async))
+[`[--fixed_dt FIXED_DT]`](#-fixed_dt) [`[--render_mode]`](#-render_mode))
+[`[--no_render_mode]`](#-no_render_mode) [`[--show_scenarios]`](#-show_scenarios))
+[`[--sensors SENSORS [SENSORS ...]]`](#-sensors-integer))
+[`[--maps MAPS [MAPS ...]]`](#-maps-townname))
+[`[--weather WEATHER [WEATHER ...]]`](#-weather-integer)
+
+
+
+#### Flags
+
+###### `--host`: IP_ADDRESS
+>> __Default__: Localhost.
+
+>> Configures the host of the server.
+
+
+###### `--port`: PORT
+>> __Default__: 2000
+
+>> Configures the TCP port to listen to.
+
+###### `--file`: filename.md
+>> __Default__: benchmark.md
+
+>> Writes results in markdown table format to a file.
+
+###### `--tm`
+
+>> Switch to Traffic Manager benchmark
+
+###### `--ticks`
+
+>> __Default__: 100
+
+>> Sets the number of ticks to use for each scenario.
+
+###### `--sync`
+
+>> __Default mode.__
+
+>> Runs benchmark in synchronous mode.
+
+###### `--async`
+
+>> Runs benchmark in asynchronous mode.
+
+###### `--fixed_dt`
+
+>> __Default__: 0.05
+
+>> For use with synchronous mode if you would like to set the delta timestep.
+
+###### `--render_mode`
+
+>> Runs benchmark in rendering mode.
+
+###### `--no_render_mode`
+
+>> __Default mode.__
+
+>> Runs benchmark in non-rendering mode.
+
+###### `--show_scenarios`
+
+>> When the script is run with only this flag you will see a list of all the scenario parameters available.
+
+>> When combined with other flags you will see a preview of the scenarios that will be run without actually executing them.
+
+###### `--sensors`: INTEGER
+>> __Default__: All
+
+>> Sensors to be used in the benchmark. Chose between LIDAR and RGB camera:
+
+>> * __`0`__: cam-300x200
+>> * __`1`__: cam-800x600
+>> * __`2`__: cam-1900x1080
+>> * __`3`__: cam-300x200 cam-300x200 (two cameras)
+>> * __`4`__: LIDAR: 100k
+>> * __`5`__: LIDAR: 500k
+>> * __`6`__: LIDAR: 1M
+
+
+###### `--maps`: TownName
+
+>> __Default__: All maps
+
+>> All [CARLA maps][carla_maps], both layered and sub-layered, are available.
+
+[carla_maps]: https://carla.readthedocs.io/en/latest/core_map/#carla-maps
+
+###### `--weather`: INTEGER
+
+>> __Default__: All weather conditions
+
+>> Change the weather conditions:
+
+>> * __`0`__: ClearNoon
+>> * __`1`__: CloudyNoon
+>> * __`2`__: SoftRainSunset
+
+## How to run the benchmark
+
+1. Start CARLA:
+
+ # Linux:
+ ./CarlaUE4.sh
+ # Windows:
+ CarlaUE4.exe
+ # Source:
+ make launch
+
+
+2. In a separate terminal navigate to `PythonAPI/util` to find the `performance_benchmark.py` script:
+
+>> * Show all possible scenarios without running them:
+```shell
+python3 performance_benchmark.py --show_scenarios
+```
+
+>> * Show what scenarios will run when configurations are applied without actually executing them:
+```shell
+python3 performance_benchmark.py --sensors 2 5 --maps Town03 Town05 --weather 0 1 --show_scenarios`
+```
+
+>> * Execute the performance benchmark for those scenarios:
+```shell
+python3 performance_benchmark.py --sensors 2 5 --maps Town03 Town05 --weather 0 1
+```
+
+>> * Perform the benchmark for asynchronous mode and rendering mode:
+```shell
+python3 performance_benchmark.py --async --render_mode
+```
+
+---
+## CARLA performance report
+
+
+The following table details the performance effect on average FPS when running CARLA with increasing numbers of vehicles and different combinations of enabling and/or disabling physics and Traffic Manager.
+
+* CARLA Version: Dev branch on 29/01/21 (commit 198fa38c9b1317c114ac15dff130766253c02832)
+* Environment Specs: Intel(R) Xeon(R) CPU E5-1620 v3 @ 3.50GHz / 32 GB / NVIDIA GeForce GTX 1080 Ti
+
+
+|Num Vehicles|Phy: Off TM: Off|Phy: On TM: Off|Phy: Off TM: On|Phy: On TM: On|
+|------------|----------------|---------------|---------------|--------------|
+|0 |1220 |1102 |702 |729 |
+|1 |805 |579 |564 |422 |
+|10 |473 |223 |119 |98 |
+|50 |179 |64 |37 |26 |
+|100 |92 |34 |22 |15 |
+|150 |62 |21 |17 |10 |
+|200 |47 |15 |14 |7 |
+|250 |37 |11 |12 |6 |
+
+---
+
+If you have any questions regarding the performance benchmarks then don't hesitate to post in the forum.
+
+
\ No newline at end of file
diff --git a/Docs/adv_opendrive.md b/Docs/adv_opendrive.md
index 7c2c68c46..eda1d1ef6 100644
--- a/Docs/adv_opendrive.md
+++ b/Docs/adv_opendrive.md
@@ -48,7 +48,10 @@ python3 config.py -x opendrive/TownBig.xodr
```
!!! Important
- __[client.generate_opendrive_world()](python_api.md#carla.Client.generate_opendrive_world)__ uses __content of the OpenDRIVE file parsed as string__. On the contrary, __`config.py`__ script needs __the path to the `.xodr` file__.
+ __[client.generate_opendrive_world()](python_api.md#carla.Client.generate_opendrive_world)__ uses __content of the OpenDRIVE file parsed as string__. On the contrary, __`config.py`__ script needs __the path to the `.xodr` file__.
+
+!!! Note
+ If you experience the error `opendrive could not be correctly parsed`, ensure that there are write permissions on the `CarlaUE4/Content/Carla/Maps/OpenDrive/` directory. This is required by the server to parse the `xodr` file correctly.
---
## Mesh generation
@@ -73,7 +76,7 @@ Doubts and suggestions in the forum.
diff --git a/Docs/adv_ptv.md b/Docs/adv_ptv.md
index 0fcdba9e2..4318d32ed 100644
--- a/Docs/adv_ptv.md
+++ b/Docs/adv_ptv.md
@@ -60,7 +60,7 @@ Open CARLA and mess around for a while. If there are any doubts, feel free to po
diff --git a/Docs/adv_recorder.md b/Docs/adv_recorder.md
index 59e615fa0..8dbce237a 100644
--- a/Docs/adv_recorder.md
+++ b/Docs/adv_recorder.md
@@ -311,7 +311,7 @@ Now it is time to experiment for a while. Use the recorder to playback a simulat
diff --git a/Docs/adv_rendering_options.md b/Docs/adv_rendering_options.md
index 6773a89f1..f547712d6 100644
--- a/Docs/adv_rendering_options.md
+++ b/Docs/adv_rendering_options.md
@@ -1,16 +1,15 @@
# Rendering options
-There are few details to take into account at the time of configuring a simulation. This page covers the more important ones.
+This guide details the different rendering options available in CARLA, including quality levels, no-rendering mode and off-screen mode. It also explains how version 0.9.12 of CARLA differs from previous versions in these respects.
-* [__Graphics quality__](#graphics-quality)
- * [Vulkan vs OpenGL](#vulkan-vs-opengl)
- * [Quality levels](#quality-levels)
-* [__No-rendering mode__](#no-rendering-mode)
-* [__Off-screen mode__](#off-screen-mode)
- * [Off-screen Vs no-rendering](#off-screen-vs-no-rendering)
-* [__Running off-screen using a preferred GPU__](#running-off-screen-using-a-preferred-gpu)
- * [Docker - recommended approach](#docker-recommended-approach)
- * [Deprecated - emulate the virtual display](#deprecated-emulate-the-virtual-display)
+- [__Graphics quality__](#graphics-quality)
+ - [Vulkan graphics API](#vulkan-graphics-api)
+ - [Quality levels](#quality-levels)
+- [__No-rendering mode__](#no-rendering-mode)
+- [__Off-screen mode__](#off-screen-mode)
+ - [Off-screen Vs no-rendering](#off-screen-vs-no-rendering)
+ - [Setting off-screen mode (Version 0.9.12+)](#setting-off-screen-mode-version-0912)
+ - [Setting off-screen mode (Versions prior to 0.9.12)](#setting-off-screen-mode-versions-prior-to-0912)
!!! Important
@@ -19,23 +18,15 @@ There are few details to take into account at the time of configuring a simulati
---
## Graphics quality
-### Vulkan vs OpenGL
+### Vulkan graphics API
-Vulkan is the default graphics API used by Unreal Engine, and CARLA. It consumes more memory, but performs faster and makes for a better frame rate. However, it is quite experimental, especially in Linux, and it may lead to some issues.
-
-There is the option to change to OpenGL. Use a flag when running CARLA.
-
-```sh
-cd carla && ./CarlaUE4.sh -opengl
-```
-When working with the build version of CARLA, Unreal Engine needs to be set to use OpenGL. [Here][UEdoc] is a documentation regarding different command line options for Unreal Engine.
-[UEdoc]: https://docs.unrealengine.com/en-US/Programming/Basics/CommandLineArguments/index.html
+Starting from version 0.9.12, CARLA runs on Unreal Engine 4.26 which only supports the Vulkan graphics API. Previous versions of CARLA could be configured to use OpenGL. If you are using a previous version of CARLA, please select the corresponding documentation version in the lower right corner of the screen for more information.
### Quality levels
-CARLA also allows for two different graphic quality levels. __Epic__, the default is the most detailed. __Low__ disables all post-processing and shadows, the drawing distance is set to 50m instead of infinite.
+CARLA has two different levels for graphics quality. __Epic__ is the default and is the most detailed. __Low__ disables all post-processing and shadows and the drawing distance is set to 50m instead of infinite.
-The simulation runs significantly faster in __Low__ mode. This is not only used when there are technical limitations or precision is nonessential. It may be useful to train agents under conditions with simpler data or regarding only close elements.
+The simulation runs significantly faster in __Low__ mode. This is helpful in situations where there are technical limitations, where precision is nonessential or to train agents under conditions with simpler data or involving only close elements.
The images below compare both modes. The flag used is the same for Windows and Linux. There is no equivalent option when working with the build, but the UE editor has its own quality settings. Go to `Settings/Engine Scalability Settings` for a greater customization of the desired quality.
@@ -61,7 +52,8 @@ The images below compare both modes. The flag used is the same for Windows and L
This mode disables rendering. Unreal Engine will skip everything regarding graphics. This mode prevents rendering overheads. It facilitates a lot traffic simulation and road behaviours at very high frequencies. To enable or disable no-rendering mode, change the world settings, or use the provided script in `/PythonAPI/util/config.py`.
-Here is an example on how to enable and then disable it via script.
+Below is an example on how to enable and then disable it via script:
+
```py
settings = world.get_settings()
settings.no_rendering_mode = True
@@ -70,7 +62,8 @@ world.apply_settings(settings)
settings.no_rendering_mode = False
world.apply_settings(settings)
```
-And here is an example on how to disable and then enable rendering using the `config.py`.
+To disable and enable rendering via the command line, run the following commands:
+
```sh
cd PythonAPI/util && python3 config.py --no-rendering
```
@@ -78,7 +71,8 @@ cd PythonAPI/util && python3 config.py --no-rendering
cd PythonAPI/util && python3 config.py --rendering
```
-The script `PythonAPI/examples/no_rendering_mode.py` will enable no-rendering mode, and use __Pygame__ to create an aerial view using simple graphics.
+The script `PythonAPI/examples/no_rendering_mode.py` will enable no-rendering mode, and use __Pygame__ to create an aerial view using simple graphics:
+
```sh
cd PythonAPI/examples && python3 no_rendering_mode.py
```
@@ -89,125 +83,87 @@ cd PythonAPI/examples && python3 no_rendering_mode.py
---
## Off-screen mode
-Unreal Engine needs for a screen in order to run. However, there is a workaround for remote servers with no display, or desktop users with a GPU not connected to any screen.
-
-The simulator launches but there is no available window. It runs in the same way as normal mode. This mode tricks Unreal Engine into running in a "fake screen".
+Starting from version 0.9.12, CARLA runs on Unreal Engine 4.26 which introduced support for off-screen rendering. In previous versions of CARLA, off-screen rendering depended upon the graphics API you were using.
### Off-screen vs no-rendering
-It is important to understand the disctintion them to prevent misunderstandings.
+It is important to understand the distinction between __no-rendering mode__ and __off-screen mode__:
-* In __no-rendering__, Unreal Engine does not render anything. Graphics are not computed.
-* In __off-screen__, Unreal Engine is working as usual, rendering is computed. Simply, there is no display available. GPU sensors return data when off-screen, and no-rendering mode can be enabled at will.
+- __No-rendering mode:__ Unreal Engine does not render anything. Graphics are not computed. GPU based sensors return empty data.
+- __Off-screen mode:__ Unreal Engine is working as usual, rendering is computed but there is no display available. GPU based sensors return data.
-### Setting off-screen mode
+### Setting off-screen mode (Version 0.9.12+)
-This is __only possible in Linux while using OpenGL__. Unreal Engine crushes when Vulkan is running off-screen, and this issue is yet to be fixed by Epic.
+To start CARLA in off-screen mode, run the following command:
-To force the simulator run off-screen set the environment variable `DISPLAY` to empty and run CARLA using OpenGL.
+```sh
+./CarlaUE4.sh -RenderOffScreen
+```
+
+### Setting off-screen mode (Versions prior to 0.9.12)
+
+Using off-screen mode differs if you are using either OpenGL or Vulkan.
+
+__Using OpenGL__, you can run in off-screen mode in Linux by running the following command:
```sh
# Linux
DISPLAY= ./CarlaUE4.sh -opengl
```
----
-## Running off-screen using a preferred GPU
-### Docker - recommended approach
+__Vulkan__ requires extra steps because it needs to communicate to the display X server using the X11 network protocol to work properly. The following steps will guide you on how to set up an Ubuntu 18.04 machine without a display so that CARLA can run with Vulkan.
-The best way to run a headless CARLA and select the GPU is to [__run CARLA in a Docker__](build_docker.md).
+__1. Fetch the latest NVIDIA driver:__
-This section contains an alternative tutorial, but this method is deprecated and performance is much worse. It is here only for those who Docker is not an option.
-
-
-### Deprecated - emulate the virtual display
-
-
-
- Show deprecated tutorial on how to emulate the virtual display
-
-
-!!! Warning
- This tutorial is deprecated. To run headless CARLA, please [__run CARLA in a Docker__](build_docker.md).
-
-* __Requirements:__
-
-This tutorial only works in Linux and makes it possible for a remote server using several graphical cards to use CARLA on all GPUs. This is also translatable to a desktop user trying to use CARLA with a GPU that is not plugged to any screen. To achieve that, the steps can be summarized as:
-
-__1.__ Configure the server to have Nvidia working with no display.
-__2.__ Use VNC and VGL to simulate a display connected to any GPU.
-__3.__ Run CARLA.
-
-This tutorial was tested in Ubuntu 16.04 using NVIDIA 384.11 drivers.
-
-* __[Latest Nvidia drivers](http://www.nvidia.es/Download/index.aspx)__
-* __[OpenGL](https://www.khronos.org/opengl/wiki/Getting_Started)__: needed to use Virtual GL (VGL). OpenGL can be installed via apt:
```sh
-sudo apt-get install freeglut3-dev mesa-utils
+wget http://download.nvidia.com/XFree86/Linux-x86_64/450.57/NVIDIA-Linux-x86_64-450.57.run
```
-* __[VGL](https://virtualgl.org/vgldoc/2_2_1/#hd004001)__: redirects 3D rendering commands from Unix and Linux OpenGL to the hardware in a dedicated server.
-* __[TurboVNC 2.11](https://cdn.rawgit.com/TurboVNC/turbovnc/2.1.1/doc/index.html#hd005001)__: graphical desktop-sharing system to connect remotely to the server.
+__2. Install the driver:__
-* __Extra packages__: necessary to make Unreal work.
```sh
-sudo apt install x11-xserver-utils libxrandr-dev
+sudo /bin/bash NVIDIA-Linux-x86_64-450.57.run --accept-license --no-questions --ui=none
```
-!!! Warning
- Make sure that VNC version is compatible with Unreal. The one above worked properly during the making of this tutorial.
-
-* __Configure the X__
+__3. Install the xserver related dependencies:__
-Generate a X compatible with the Nvdia installed and able to run without display:
+```sh
+sudo apt-get install -y xserver-xorg mesa-utils libvulkan1
+```
- sudo nvidia-xconfig -a --use-display-device=None --virtual=1280x1024
+__4. Configure the xserver:__
-* __Emulate the virtual display__
+```sh
+sudo nvidia-xconfig --preserve-busid -a --virtual=1280x1024
+```
-Run a Xorg. Here number 7 is used, but it could be labeled with any free number:
+__5. Set the SDL_VIDEODRIVER variable.__
- sudo nohup Xorg :7 &
+```sh
+ENV SDL_VIDEODRIVER=x11
+```
-Run an auxiliary remote VNC-Xserver. This will create a virtual display "8":
+__6. Run the xserver:__
- /opt/TurboVNC/bin/vncserver :8
+```sh
+sudo X :0 &
+```
-If everything is working fine the following command will run glxinfo on Xserver 7 selecting the GPU labeled as 0:
+__7. Run CARLA:__
- DISPLAY=:8 vglrun -d :7.0 glxinfo
+```sh
+DISPLAY=:0.GPU ./CarlaUE4.sh -vulkan
+```
-!!! Important
- To run on other GPU, change the `7.X` pattern in the previous command. To set it to GPU 1: `DISPLAY=:8 vglrun -d :7.1 glxinfo`
-
-* __Extra__
-
-To disable the need of sudo when creating the `nohup Xorg` go to `/etc/X11/Xwrapper.config` and change `allowed_users=console` to `allowed_users=anybody`.
-
-It may be needed to stop all Xorg servers before running `nohup Xorg`. The command for that could change depending on your system. Generally for Ubuntu 16.04 use:
-
- sudo service lightdm stop
-
-* __Running CARLA__
-
-To run CARLA on a certain `` in a certain `$CARLA_PATH` use the following command:
-
- DISPLAY=:8 vglrun -d :7. $CARLA_PATH/CarlaUE4/Binaries/Linux/CarlaUE4
-
-!!! Note
- The `8` and `7.X` variables in the previous command depend on which were used while emulating the virtual display.
-
-
+CARLA provides a Dockerfile that performs all the above steps [here](https://github.com/carla-simulator/carla/blob/0.9.12/Util/Docker/Release.Dockerfile).
---
-That is all there is to know about the different rendering options in CARLA.
-
-Open CARLA and mess around for a while. If there are any doubts, feel free to post these in the forum.
+Any issues or doubts related with this topic can be posted in the CARLA forum.
diff --git a/Docs/adv_rss.md b/Docs/adv_rss.md
index 1219c34da..6ec09807c 100644
--- a/Docs/adv_rss.md
+++ b/Docs/adv_rss.md
@@ -124,7 +124,7 @@ Open CARLA and mess around for a while. If there are any doubts, feel free to po
diff --git a/Docs/adv_sumo.md b/Docs/adv_sumo.md
index 25a466c69..e045191da 100644
--- a/Docs/adv_sumo.md
+++ b/Docs/adv_sumo.md
@@ -94,9 +94,9 @@ python3 run_synchronization.py --tls-manager carla --sumo-gui
The co-simulation with SUMO makes for an additional feature. Vehicles can be spawned in CARLA through SUMO, and managed by the later as the Traffi Manager would do.
-The script `spawn_npc_sumo.py` is almost equivalent to the already-known `spawn_npc.py`. This script automatically generates a SUMO network in a temporal folder, based on the active town in CARLA. The script will create random routes and let the vehicles roam around.
+The script `spawn_npc_sumo.py` is almost equivalent to the already-known `generate_traffic.py`. This script automatically generates a SUMO network in a temporal folder, based on the active town in CARLA. The script will create random routes and let the vehicles roam around.
-As the script runs a synchronous simulation, and spawns vehicles in it, the arguments are the same that appear in `run_synchronization.py` and `spawn_npc.py`.
+As the script runs a synchronous simulation, and spawns vehicles in it, the arguments are the same that appear in `run_synchronization.py` and `generate_traffic.py`.
* __`--host`__ *(default: 127.0.0.1)* — IP of the host server.
* __`--port`__ *(default: 2000)* — TCP port to listen to.
@@ -125,7 +125,7 @@ Open CARLA and mess around for a while. If there are any doubts, feel free to po
diff --git a/Docs/adv_synchrony_timestep.md b/Docs/adv_synchrony_timestep.md
index 04e4cb089..ffb6e3bec 100644
--- a/Docs/adv_synchrony_timestep.md
+++ b/Docs/adv_synchrony_timestep.md
@@ -2,15 +2,16 @@
This section deals with two fundamental concepts in CARLA. Their configuration defines how does time go by in the simulation, and how does the server make the simulation move forward.
-* [__Simulation time-step__](#simulation-time-step)
- * [Variable time-step](#variable-time-step)
- * [Fixed time-step](#fixed-time-step)
- * [Tips when recording the simulation](#tips-when-recording-the-simulation)
- * [Time-step limitations](#time-step-limitations)
-* [__Client-server synchrony__](#client-server-synchrony)
- * [Setting synchronous mode](#setting-synchronous-mode)
- * [Using synchronous mode](#using-synchronous-mode)
-* [__Possible configurations__](#possible-configurations)
+* [__Simulation time-step__](#simulation-time-step)
+ * [Variable time-step](#variable-time-step)
+ * [Fixed time-step](#fixed-time-step)
+ * [Tips when recording the simulation](#tips-when-recording-the-simulation)
+ * [Physics substepping](#physics-substepping)
+* [__Client-server synchrony__](#client-server-synchrony)
+ * [Setting synchronous mode](#setting-synchronous-mode)
+ * [Using synchronous mode](#using-synchronous-mode)
+* [__Possible configurations__](#possible-configurations)
+* [__Physics determinism__](#physics-determinism)
---
## Simulation time-step
@@ -94,7 +95,19 @@ fixed_delta_seconds <= max_substep_delta_time * max_substeps
```
In order to have an optimal physical simulation, the substep delta time should at least
-be below 0.01666 and ideally below 0.01.
+be below `0.01666` and ideally below `0.01`.
+
+To demonstrate the effect of optimal physical sub-stepping, consider the following graphs. The first graph shown below illustrates velocity over time in simulations with different fixed simulation time steps. The physical delta time is constant in all simulations at the default value of `0.01`. We can see that velocity is not affected by the difference in simulation time steps only.
+
+>>>>>![velocity with fixed physical delta time](../img/physics_convergence_fixed_pdt.png)
+
+The second graph shows velocity over time in simulations with a fixed simulation time step of `0.04`. We can see that once the physical delta time surpasses `0.01`, deviations start to occur in the constancy of velocity, increasing in severity as physical delta time increases.
+
+>>>>>![velocity with varied physical delta time](../img/physics_convergence_fixed_dt.png)
+
+We can demonstrate this deviation again by showing the effect of the same difference in physical delta time with a fixed simulation time step in the measurement of z-acceleration, with convergence occurring only when the physical delta time is `0.01` or less.
+
+>>>>>![physics convergence z acceleration](../img/physics_convergence_z_acceleration.png)
---
## Client-server synchrony
@@ -183,6 +196,17 @@ The configuration of time-step and synchrony, leads for different settings. Here
!!! Warning
__In synchronous mode, always use a fixed time-step__. If the server has to wait for the user, and it is using a variable time-step, time-steps will be too big. Physics will not be reliable. This issue is better explained in the __time-step limitations__ section.
+---
+
+## Physics determinism
+
+CARLA supports physics and collision determinism under specific circumstances:
+
+- __Synchronous mode and fixed delta seconds must be enabled:__ Determinism requires the client to be in perfect sync with the server to ensure that commands are applied correctly and to produce accurate and reproducible results. A constant time step must be enforced by setting `fixed_delta_seconds`. If this is not set, the time step will be automatically computed at each step depending on the simulation performance.
+- __Synchronous mode must be enabled before loading or reloading the world:__ Differing timestamps can arise if the world is not in synchronous mode from the very beginning. This can generate small differences in physics simulation and in the life cycle of objects such as traffics lights.
+- __The world must be reloaded for each new repetition:__ Reload the world each time you want to reproduce a simulation.
+- __Commands should be batched instead of issued one at a time:__ Although rare, in a busy simulation or overloaded server, single issued commands can become lost. If commands are batched in a [`apply_batch_sync`](python_api.md/#carla.Client.apply_batch_sync) command, the command is guaranteed to be executed or return a failure response.
+
---
@@ -192,7 +216,7 @@ Open CARLA and mess around for a while. Any suggestions or doubts are welcome in
diff --git a/Docs/adv_traffic_manager.md b/Docs/adv_traffic_manager.md
index 60ac8e41b..df20ea389 100644
--- a/Docs/adv_traffic_manager.md
+++ b/Docs/adv_traffic_manager.md
@@ -1,229 +1,271 @@
# Traffic Manager
-* [__What is it?__](#what-is-it)
-* [__Architecture__](#architecture)
- * [ALSM](#alsm)
- * [Command array](#command-array)
- * [Control loop](#control-loop)
- * [In-Memory Map](#in-memory-map)
- * [PBVT](#pbvt)
- * [PID controller](#pid-controller)
- * [Simulation state](#simulation-state)
- * [Stages](#stages)
- * [Vehicle registry](#vehicle-registry)
-* [__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)
-* [__Deterministic mode__](#deterministic-mode)
-* [__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)
- * [Synchronous mode](#synchronous-mode)
-* [__Summary__](#summary)
+
+- [__What is the Traffic Manager?__](#what-is-the-traffic-manager)
+ - [Structured design](#structured-design)
+ - [User customization](#user-customization)
+- [__Architecture__](#architecture)
+ - [Overview](#overview)
+ - [ALSM](#alsm)
+ - [Vehicle registry](#vehicle-registry)
+ - [Simulation state](#simulation-state)
+ - [Control loop](#control-loop)
+ - [In-Memory Map](#in-memory-map)
+ - [PBVT](#pbvt)
+ - [PID controller](#pid-controller)
+ - [Command array](#command-array)
+ - [Stages of the Control Loop](#stages-of-the-control-loop)
+- [__Using the Traffic Manager__](#using-the-traffic-manager)
+ - [Vehicle behavior considerations](#vehicle-behavior-considerations)
+ - [Creating a Traffic Manager](#creating-a-traffic-manager)
+ - [Configuring autopilot behavior](#configuring-autopilot-behavior)
+ - [Stopping a Traffic Manager](#stopping-a-traffic-manager)
+- [__Deterministic mode__](#deterministic-mode)
+- [__Hybrid physics mode__](#hybrid-physics-mode)
+- [__Running multiple Traffic Managers__](#running-multiple-traffic-managers)
+ - [Traffic Manager servers and clients](#traffic-manager-servers-and-clients)
+ - [Multi-client simulations](#multi-client-simulations)
+ - [Multi-TM simulations](#multi-tm-simulations)
+ - [Multi-simulation](#multi-simulation)
+- [__Synchronous mode__](#synchronous-mode)
+- [__Traffic manager in large maps__](#traffic-manager-in-large-maps)
---
-## What is it?
+## What is the Traffic Manager?
-The Traffic Manager, TM for short, is the module in charge of controlling vehicles inside the simulation. It is built on top of the CARLA API in C++. Its goal is to populate the simulation with realistic urban traffic conditions. Users can customize some behaviours, for example to set specific learning circumstances. Every TM controls vehicles registered to it by setting autopilot to true, and is accounting for the rest by considering them unregistered.
+The Traffic Manager (TM) is the module that controls vehicles in autopilot mode in a simulation. Its goal is to populate a simulation with realistic urban traffic conditions. Users can customize some behaviors, for example, to set specific learning circumstances.
### Structured design
-The TM is built on the client-side of the CARLA architecture. It replaces the server-side autopilot. The execution flow is divided in __stages__ with independent operations and goals. This facilitates the development of phase-related functionalities and data structures, while also improving computational efficiency. Each stage runs on a different thread. Communication with the rest is managed through synchronous messaging between the stages.The information flows only in one direction.
+
+TM is built on CARLA's client-side. The execution flow is divided into __stages__, each with independent operations and goals. This facilitates the development of phase-related functionalities and data structures while improving computational efficiency. Each stage runs on a different thread. Communication with other stages is managed through synchronous messaging. Information flows in one direction.
### User customization
-Users must have some control over the traffic flow by setting parameters that allow, force or encourage specific behaviours. Users can change the traffic behaviour as they prefer, both online and offline. For example they could allow a car to ignore the speed limits or force a lane change. Being able to play around with behaviours is a must when trying to simulate reality. It is necessary to train driving systems under specific and atypical circumstances.
+Users have some control over the traffic flow by setting parameters that allow, force, or encourage specific behaviors. Users can change the traffic behavior as they prefer, both online and offline. For example, cars can be allowed to ignore the speed limits or force a lane change. Being able to play around with behaviors is indispensable when trying to simulate reality. Driving systems need to be trained under specific and atypical circumstances.
---
## Architecture
+### Overview
+
![Architecture](img/tm_2_architecture.jpg)
+The above diagram is a representation of the internal architecture of the TM. The C++ code for each component can be found in `LibCarla/source/carla/trafficmanager`. Each component is explained in detail in the following sections. A simplified overview of the logic is as follows:
+__1. Store and update the current state of the simulation.__
+- The [Agent Lifecycle & State Management](#alsm) (ALSM) scans the world to keep track of all the vehicles and walkers present and to clean up entries for those that no longer exist. All the data is retrieved from the server and is passed through several [stages](#stages-of-the-control-loop). The ALSM is the only component that makes calls to the server.
+- The [vehicle registry](#vehicle-registry) contains an array of vehicles on autopilot (controlled by the TM) and a list of pedestrians and vehicles not on autopilot (not controlled by the TM).
+- The [simulation state](#simulation-state) is a cache store of the position, velocity, and additional information of all the vehicles and pedestrians in the simulation.
-The previous diagram is a summary of the internal architecture of the Traffic Manager. The inner structure of the TM can be easily translated to code, and each relevant component has its equivalent in the C++ code (.cpp files) inside `LibCarla/source/carla/trafficmanager`. The functions and relations of these components are explained in the following sections.
+__2. Calculate the movement of every autopilot vehicle.__
-Nevertheless, the logic of it can be simplified as follows.
+The TM generates viable commands for all vehicles in the [vehicle registry](#vehicle-registry) according to the [simulation state](#simulation-state). Calculations for each vehicle are done separately. These calculations are divided into different [stages](#stages-of-the-control-loop). The [control loop](#control-loop) makes sure that all calculations are consistent by creating __synchronization barriers__ between stages. No vehicle moves to the next stage before calculations are finished for all vehicles in the current stage. Each vehicle goes through the following stages:
-__1. Store and update the current state of the simulation.__
-First of all, the [ALSM](#alsm) (Agent Lifecycle & State Management) scans the world to keep track of all the vehicles and walkers present in it, and clean up entries for those that no longer exist. All the data is retrieved from the server, and then passed to the [stages](#stages). In such way, calls to the server are isolated in the ALSM, and these information can be easily accessible onwards. The [vehicle registry](#vehicle-registry) contains an array with the registered vehicles, and a list with the rest of vehicles and pedestrians. The [simulation state](#simulation-state) stores in cache the position and velocity and some additional information of all the cars and walkers.
+>__2.1 - [Localization Stage](#stage-1-localization-stage).__
-__2. Calculate the movement of every registered vehicle.__
-The main goal of the TM is to generate viable commands for all the vehicles in the [vehicle registry](#vehicle-registry), according to the [simulation state](#simulation-state). The calculations for each vehicle are done separatedly. These calculations are divided in different [stages](#stages). The [control loop](#control-loop) makes sure that all the calculations are consistent by creating __synchronization barriers__ in between stages. No one moves to the following stage before the calculations for all the vehicles are finished in the current one. Each vehicle has to go through the following stages.
- __2.1 - [Localization Stage](#stage-1-localization-stage).__
-TM vehicles do not have a predefined route, and path choices are taken randomly at junctions. Having this in mind, the [In-Memory Map](#in-memory-map) simplifies the map as a grid of waypoints, and a near-future path to follow is created as a list of waypoints ahead. The path of every vehicle will be stored by the [PBVT](#pbvt) component (Path Buffers & Vehicle Tracking), so that these can be easily accessible and modified in future stages.
- __2.2 - [Collision Stage](#stage-2-collision-stage).__
-During this stage, bounding boxes are extended over the path of each vehicle to identify potential collision hazards, which are then managed when necessary.
- __2.3 - [Traffic Light Stage](#stage-3-traffic-light-stage).__
-Similar to the Collision Stage, this stage identifies potential hazards that affect the path of the vehicle according to traffic light influence, stop signs, and junction priority.
- __2.4 - [Motion Planner Stage](#stage-4-motion-planner-stage).__
-Once a path has been defined, this stage computes vehicle movement. A [PID controller](#pid-controller) is used to determine how to reach the target values. This movement is then translated into an actual CARLA command to be applied.
+>Paths are created dynamically using a list of nearby waypoints collected from the [In-Memory Map](#in-memory-map), a simplification of the simulation map as a grid of waypoints. Directions at junctions are chosen randomly. Each vehicle's path is stored and maintained by the [Path Buffers & Vehicle Tracking](#pbvt) (PBVT) component for easy access and modification in future stages.
-__3. Apply the commands in the simulation.__
-Finally, the TM has calculated the next command for every vehicle, and now it is only a matter of applying them. All the commands are gathered by the [command array](#command-array), and sent to the CARLA server in a batch so that they are applied in the same frame.
+>__2.2 - [Collision Stage](#stage-2-collision-stage).__
-And thus the cycle is concluded. The TM follows this logic on every step of the simulation. For a better understanding of the role that each component plays, this section includes an in-depth description of each of them.
+>Bounding boxes are extended over each vehicle's path to identify and navigate potential collision hazards.
+
+>__2.3 - [Traffic Light Stage](#stage-3-traffic-light-stage).__
+
+>Similar to the Collision Stage, potential hazards that affect each vehicle's path due to traffic light influence, stop signs, and junction priority are identified.
+
+>__2.4 - [Motion Planner Stage](#stage-4-motion-planner-stage).__
+
+>Vehicle movement is computed based on the defined path. A [PID controller](#pid-controller) determines how to reach the target waypoints. This is then translated into a CARLA command for application in the next step.
+
+__3. Apply the commands in the simulation.__
+
+Commands generated in the previous step are collected into the [command array](#command-array) and sent to the CARLA server in a batch to be applied in the same frame.
+
+The following sections will explain each component and stage in the TM logic described above in more detail.
### ALSM
-ALSM stands for __Agent Lifecycle and State Management__. First step in the logic cycle. Provides context over the current state of the simulation.
+ALSM stands for __Agent Lifecycle and State Management__. It is the first step in the TM logic cycle and provides context of the simulation's current state.
-* Scans the world to keep track of all the vehicles and walkers in it, their positions and velocities. If physics are enabled, the velocity is retrieved by [Vehicle.get_velocity()](python_api.md#carla.Vehicle). Instead, if physics are disabled, the velocity is computed using the history of position updates over time.
-* Stores the position, velocity and additional information (traffic light influence, bounding boxes, etc) of every vehicle and walker in the [simulation state](#simulation-state) module.
-* Updates the list of registered vehicles stored by the [vehicle registry](#vehicle-registry).
-* Updates entries in the [control loop](#control-loop) and [PBVT](#pbvt) modules to match the list of registered vehicles.
+The ALSM component:
-__Related .cpp files:__ `ALSM.h`, `ALSM.cpp`.
+- Scans the world to keep track of all vehicles and pedestrians, their positions and velocities. If physics are enabled, the velocity is retrieved by [Vehicle.get_velocity()](python_api.md#carla.Vehicle). Otherwise, the velocity is calculated using the history of position updates over time.
+- Stores the position, velocity, and additional information (traffic light influence, bounding boxes, etc) of every vehicle and pedestrian in the [simulation state](#simulation-state) component.
+- Updates the list of TM-controlled vehicles in the [vehicle registry](#vehicle-registry).
+- Updates entries in the [control loop](#control-loop) and [PBVT](#pbvt) components to match the vehicle registry.
-### Command array
-
-Last step in the TM logic cycle. Receives commands for all the registered vehicles and applies them.
-
-* Receives a series of [carla.VehicleControl](python_api.md#carla.VehicleControl) from the [Motion Planner Stage](#stage-4-motion-planner-stage).
-* Constructs a batch for all the commands to be applied during the same frame.
-* Sends the batch to the CARLA server. Either __apply_batch()__ or __apply_batch_synch()__ in [carla.Client](../python_api/#carla.Client) will be called, depending if the simulation is running in asynchronous or synchronous mode, respectively.
-
-__Related .cpp files:__ `TrafficManagerLocal.cpp`.
-
-### Control loop
-
-Manages the process of calculating the next command for all the registered vehicles, so that these are done in synchrony.
-
-* Receives from the [vehicle registry](#vehicle-registry) an array of the vehicles registered to the TM.
-* Loops over said array, performing calculations per vehicle separatedly.
-* These calculations are divided in a series of [stages](#stages).
-* Synchronization barriers are placed between stages so that consistency is guaranteed. Calculations for all vehicles must finish before any of them moves to the next stage, ensuring that all vehicles are updated in the same frame.
-* Coordinates the transition between [stages](#stages) so that all the calculations are done in sync.
-* When the last stage ([Motion Planner Stage](#stage-4-motion-planner-stage)) finishes, the [command array](#command-array) is sent to the server. In this way, there are no frame delays between the calculations of the control loop, and the commands being applied.
-
-__Related .cpp files:__ `TrafficManagerLocal.cpp`.
-
-### In-Memory Map
-
-Helper module contained by the [PBVT](#pbvt) and used during the [Localization Stage](#stage-1-localization-stage).
-
-* Discretizes the map into a grid of waypoints.
-* Includes waypoints in a specific data structure with more information to connect waypoints and identify roads, junctions...
-* Identifies these structures with an ID that is used to quickly spot vehicles in nearby areas.
-
-__Related .cpp files:__ `InMemoryMap.cpp` and `SimpleWaypoint.cpp`.
-
-### PBVT
-
-PBVT stands for __Path Buffer and Vehicle Tracking__. This data structure contains the expected path for every vehicle so that it can be easily accessible during the [control loop](#control-loop).
-
-* Contains a map of deque objects with an entry per vehicle.
-* For each vehicle, contains a set of waypoints describing its current location and near-future path.
-* Contains the [In-Memory Map](#in-memory-map) that will be used by the [Localization Stage](#stage-1-localization-stage) to relate every vehicle to the nearest waypoint, and possible overlapping paths.
-
-### PID controller
-
-Helper module that performs calculations during the [Motion Planner Stage](#stage-4-motion-planner-stage).
-
-* Using the information gathered by the [Motion Planner Stage](#stage-4-motion-planner-stage), estimates the throttle, brake and steering input needed to reach a target value.
-* The adjustment is made depending on the specific parameterization of the controller, which can be modified if desired. Read more about [PID controllers](https://en.wikipedia.org/wiki/PID_controller) to learn how to do it.
-
-__Related .cpp files:__ `PIDController.cpp`.
-
-### Simulation state
-
-Stores information about the vehicles in the world so that it can be easily accessible during all the process.
-
-* Receives the current state of all vehicles and walkers in the world from the [ALSM](#alsm), including their position, velocity and some additional information (such as traffic light influence and state). It also stores some additional information such as whereas these vehicles are under the inffluence of a traffic light and what is the current state of said traffic light.
-* Stores in cache all the information so that no additional calls to the server are needed during the [control loop](#control-loop).
-
-__Related .cpp files:__ `SimulationState.cpp`, `SimulationState.h`.
-
-### Stages
-
-##### Stage 1- Localization Stage
-
-First stage in the [control loop](#control-loop). Defines a near-future path for registered vehicles.
-
-* Obtains the position and velocity of all the vehicles from [simulation state](#simulation-state).
-* Using the [In-Memory Map](#in-memory-map), relates every vehicle with a list of waypoints that describes its current location and near-future path, according to its trajectory. The faster the vehicle goes, the larger said list will be.
-* The path is updated according to planning decisions such as lane changes, speed limit, distance to leading vehicle parameterization, etc.
-* The [PBVT](#pbvt) module stores the path for all the vehicles.
-* These paths are compared with each other, in order to estimate possible collision situations. Results are passed to the following stage: [Colllision stage](#stage-2-collision-stage).
-
-__Related .cpp files:__ `LocalizationStage.cpp` and `LocalizationUtils.cpp`.
-
-##### Stage 2- Collision Stage
-
-Second stage in the [control loop](#control-loop). Triggers collision hazards.
-
-* Receives a list of pairs of vehicles with possible overlapping paths from the [Localization Stage](#stage-1-localization-stage).
-* For every pair, extends bounding boxes along the path ahead (geodesic boundaries), to check if they actually overlap and the risk of collision is real.
-* Hazards for all the possible collisions will be sent to the [Motion Planner Stage](#stage-4-motion-planner-stage) to modify the path accordingly.
-
-__Related .cpp files:__ `CollisionStage.cpp`.
-
-##### Stage 3- Traffic Light Stage
-
-Third stage in the [control loop](#control-loop). Triggers hazards to follow traffic regulations such as traffic lights, stop signs, and priority at junctions.
-
-* If the vehicle is under the influence of a yellow or red traffic light, or a stop sign, sets a traffic hazard.
-* If the vehicle is in a non-signalized junction, a bounding box is extended along its path. Vehicles with overlapping paths follow a FIFO order to move, and waits are set to a fixed time.
-
-__Related .cpp files:__ `TrafficLightStage.cpp`.
-
-##### Stage 4- Motion Planner Stage
-
-Fourth and last stage in the [control loop](#control-loop). Generates the CARLA command that will be applied to the vehicle.
-
-* Gathers all the information so far: position and velocity of the vehicles ([simulation state](#simulation-state)), their path ([PBVT](#pbvt)), hazards ([Collision Stage](#stage-2-collision-stage) and [Traffic Light Stage](#stage-3-traffic-light-stage)).
-* Makes high-level decisins about how should the vehicle move, for example computing the brake needed to prevent a collision hazard. A [PID controller](#pid-controller) is used to estimate behaviors according to target values.
-* Translates the desired movement to a [carla.VehicleControl](python_api.md#carla.VehicleControl) that can be applied to the vehicle.
-* Sends the resulting CARLA commands to the [command array](#command-array).
-
-__Related .cpp files:__ `MotionPlannerStage.cpp`.
+__Related .cpp files:__ `ALSM.h`, `ALSM.cpp`.
### Vehicle registry
-Keeps track of all the vehicles and walkers in the simulation.
+The vehicle registry keeps track of all vehicles and pedestrians in the simulation.
-* The [ALSM](#alsm) scans the world and passes an updated list of walkers and vehicles.
-* Vehicles registered to the TM are stored in a separated array that will be iterated on during the [control loop](#control-loop).
+The vehicle registry:
-__Related .cpp files:__ `MotionPlannerStage.cpp`.
+- Is passed an updated list of vehicles and pedestrians from the [ALSM](#alsm).
+- Stores vehicles registered to the TM in a separate array for iteration during the [control loop](#control-loop).
+
+__Related .cpp files:__ `MotionPlannerStage.cpp`.
+
+### Simulation state
+
+The simulation state stores information about all vehicles in the simulation for easy access and modification in later stages.
+
+The simulation state:
+
+- Receives data from the [ALSM](#alsm) including current actor position, velocity, traffic light influence, traffic light state, etc.
+- Stores all information in cache, avoiding subsequent calls to the server during the [control loop](#control-loop).
+
+__Related .cpp files:__ `SimulationState.cpp`, `SimulationState.h`.
+
+### Control loop
+
+The control loop manages the calculations of the next command for all autopilot vehicles so they are performed synchronously. The control loop consists of four different [stages](#stages-of-the-control-loop); localization, collision, traffic light, and motion planner.
+
+The control loop:
+
+- Receives an array of TM-controlled vehicles from the [vehicle registry](#vehicle-registry).
+- Performs calculations for each vehicle separately by looping over the array.
+- Divides calculations into a series of [stages](#stages-of-the-control-loop).
+- Creates synchronization barriers between stages to guarantee consistency. Calculations for all vehicles are finished before any of them move to the next stage, ensuring all vehicles are updated in the same frame.
+- Coordinates the transition between [stages](#stages-of-the-control-loop) so all calculations are done in sync.
+- Sends the [command array](#command-array) to the server when the last stage ([Motion Planner Stage](#stage-4-motion-planner-stage)) finishes so there are no frame delays between the command calculations and the command application.
+
+__Related .cpp files:__ `TrafficManagerLocal.cpp`.
+
+### In-Memory Map
+
+The In-Memory Map is a helper module contained within the [PBVT](#pbvt) and is used during the [Localization Stage](#stage-1-localization-stage).
+
+The In-Memory Map:
+
+- Converts the map into a grid of discrete waypoints.
+- Includes waypoints in a specific data structure with more information to connect waypoints and identify roads, junctions, etc.
+- Identifies these structures with an ID used to locate vehicles in nearby areas quickly.
+
+__Related .cpp files:__ `InMemoryMap.cpp` and `SimpleWaypoint.cpp`.
+
+### PBVT
+
+PBVT stands for __Path Buffer and Vehicle Tracking__. The PBVT is a data structure that contains the expected path for every vehicle and allows easy access to data during the [control loop](#control-loop).
+
+The PBVT:
+
+- Contains a map of deque objects with one entry per vehicle.
+- Contains a set of waypoints for each vehicle describing its current location and near-future path.
+- Contains the [In-Memory Map](#in-memory-map) used by the [Localization Stage](#stage-1-localization-stage) to relate every vehicle to the nearest waypoint and possible overlapping paths.
+
+### PID controller
+
+The PID controller is a helper module that performs calculations during the [Motion Planner Stage](#stage-4-motion-planner-stage).
+
+The PID controller:
+
+- Estimates the throttle, brake, and steering input needed to reach a target value using the information gathered by the [Motion Planner Stage](#stage-4-motion-planner-stage).
+- Makes adjustments depending on the specific parameterization of the controller. Parameters can be modified if desired. Read more about [PID controllers](https://en.wikipedia.org/wiki/PID_controller) to learn how to make modifications.
+
+__Related .cpp files:__ `PIDController.cpp`.
+### Command Array
+
+The Command Array represents the last step in the TM logic cycle. It receives commands for all the registered vehicles and applies them.
+
+The Command Array:
+
+- Receives a series of [carla.VehicleControl](python_api.md#carla.VehicleControl)'s from the [Motion Planner Stage](#stage-4-motion-planner-stage).
+- Batches all commands to be applied during the same frame.
+- Sends the batch to the CARLA server calling either __apply_batch()__ or __apply_batch_synch()__ in [carla.Client](../python_api/#carla.Client) depending on whether the simulation is running in asynchronous or synchronous mode, respectively.
+
+__Related .cpp files:__ `TrafficManagerLocal.cpp`.
+
+### Stages of the Control Loop
+
+##### Stage 1- Localization Stage
+
+The Localization Stage defines a near-future path for vehicles controlled by the TM.
+
+The Localization Stage:
+
+- Obtains the position and velocity of all vehicles from the [simulation state](#simulation-state).
+- Uses the [In-Memory Map](#in-memory-map) to relate every vehicle with a list of waypoints that describes its current location and near-future path according to its trajectory. The faster the vehicle goes, the longer the list will be.
+- Updates the path according to planning decisions such as lane changes, speed limit, distance to leading vehicle parameterization, etc.
+- Stores the path for all vehicles in the [PBVT](#pbvt) module.
+- Compares paths with each other to estimate possible collision situations. Results are passed to the Collision Stage.
+
+__Related .cpp files:__ `LocalizationStage.cpp` and `LocalizationUtils.cpp`.
+
+##### Stage 2- Collision Stage
+
+The Collision Stage triggers collision hazards.
+
+The Collision Stage:
+
+- Receives from the [Localization Stage](#stage-1-localization-stage) a list of vehicle pairs whose paths could potentially overlap.
+- Extends bounding boxes along the path ahead (geodesic boundaries) for each vehicle pair to check if they actually overlap and determine whether the risk of collision is real.
+- Sends hazards for all possible collisions to the [Motion Planner Stage](#stage-4-motion-planner-stage) to modify the path accordingly.
+
+__Related .cpp files:__ `CollisionStage.cpp`.
+
+##### Stage 3- Traffic Light Stage
+
+The Traffic Light stage triggers hazards due to traffic regulators such as traffic lights, stop signs, and priority at junctions.
+
+The Traffic Light stage:
+
+- Sets a traffic hazard if a vehicle is under the influence of a yellow or red traffic light or a stop sign.
+- Extends a bounding box along a vehicle's path if it is in an unsignaled junction. Vehicles with overlapping paths follow a "First-In-First-Out" order to move. Wait times are set to a fixed value.
+
+__Related .cpp files:__ `TrafficLightStage.cpp`.
+
+##### Stage 4- Motion Planner Stage
+
+The Motion Planner Stage generates the CARLA commands to be applied to vehicles.
+
+The Motion Planner Stage:
+
+- Gathers a vehicle's position and velocity ([simulation state](#simulation-state)), path ([PBVT](#pbvt)), and hazards ([Collision Stage](#stage-2-collision-stage) and [Traffic Light Stage](#stage-3-traffic-light-stage)).
+- Makes high-level decisions about how a vehicle should move, for example, computing the brake needed to prevent a collision hazard. A [PID controller](#pid-controller) is used to estimate behaviors according to target values.
+- Translates the desired movement to a [carla.VehicleControl](python_api.md#carla.VehicleControl) for application to the vehicle.
+- Sends the resulting CARLA commands to the [Command Array](#command-array).
+
+__Related .cpp files:__ `MotionPlannerStage.cpp`.
---
-## Using the Traffic Manager
+## Using the Traffic Manager
-### General considerations
+### Vehicle behavior considerations
-First of all there are some general behaviour patterns the TM will generate that should be understood beforehand. These statements are inherent to the way the TM is implemented:
+The TM implements general behavior patterns that must be taken into consideration when you set vehicles to autopilot:
-* __Vehicles are not goal-oriented__ they follow a trajectory and whenever approaching a junction, choose a path randomly. Their path is endless, and will never stop roaming around the city.
-* __Vehicles' target speed is 70% their current speed limit:__ unless any other value is set.
-* __Junction priority does not follow traffic regulations:__ the TM has a priority system to be used while junction complexity is solved. This may cause some issues such as a vehicle inside a roundabout yielding to a vehicle trying to get in.
+- __Vehicles are not goal-oriented,__ they follow a dynamically produced trajectory and choose a path randomly when approaching a junction. Their path is endless.
+- __Vehicles' target speed is 70% of their current speed limit__ unless any other value is set.
+- __Junction priority does not follow traffic regulations.__ The TM uses its own priority system at junctions. The resolution of this restriction is a work in progress. In the meantime, some issues may arise, for example, vehicles inside a roundabout yielding to a vehicle trying to get in.
+
+TM behavior can be adjusted through the Python API. For specific methods, see the TM section of the Python API [documentation](../python_api/#carla.TrafficManager). Below is a general summary of what is possible through the API:
+
+| Topic | Description |
+| ----- | ----------- |
+| **General:** | - Create a TM instance connected to a port. - Retrieve the port where a TM is connected. |
+| **Safety conditions:** | - Set a minimum distance between stopped vehicles (for a single vehicle or for all vehicles). This will affect the minimum moving distance. - Set the desired speed as a percentage of the current speed limit (for a single vehicle or for all vehicles). - Reset traffic lights. |
+| **Collision managing:** | - Enable/Disable collisions between a vehicle and a specific actor. - Make a vehicle ignore all other vehicles. - Make a vehicle ignore all walkers. - Make a vehicle ignore all traffic lights. |
+| **Lane changes:** | - Force a lane change, ignoring possible collisions. - Enable/Disable lane changes for a vehicle. |
+| **Hybrid physics mode:** | - Enable/Disable hybrid physics mode. - Change the radius in which physics is enabled. |
-The TM provides a set of possibilities so the user can establish specific behaviours. All the methods accessible from the Python API are listed in the [documentation](../python_api/#carla.TrafficManager). However, here is a brief summary of what the current possibilities are.
-| Topic | Description |
-| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| **General:** | **1\.** Use a carla.Client to create a TM instance connected to a port. **2\.** Retrieve the port where a TM is connected. |
-| **Safety conditions:** | **1\.** Set a minimum distance between stopped vehicles (for a vehicle or all of them). This will affect the minimum moving distance. **2\.** Set an intended speed regarding current speed limitation (for a vehicle or all of them). **3\.** Reset traffic lights. |
-| **Collision managing:** | **1\.** Enable/Disable collisions between a vehicle and a specific actor. **2\.** Make a vehicle ignore all the other vehicles. **3\.** Make a vehicle ignore all the walkers. **4\.** Make a vehicle ignore all the traffic lights. |
-| **Lane changes:** | **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. |
-
-
### Creating a Traffic Manager
-A TM instance can be created by any [carla.Client](python_api.md#carla.Client) specifying the port that will be used. The default port is `8000`.
+!!! Note
+ TM is designed to work in synchronous mode. Using TM in asynchronous mode can lead to unexpected and undesirable results. Read more in the section [__Synchronous mode__](#synchronous-mode).
+
+A TM instance is created by a [`carla.Client`](python_api.md#carla.Client), passing the port to be used. The default port is `8000`.
+
+To create a TM instance:
```python
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. 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.
+To enable autopilot for a set of vehicles, retrieve the port of the TM instance and set `set_autopilot` to `True`, passing the TM port at the same time. 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 one:
```python
tm_port = tm.get_port()
@@ -231,9 +273,9 @@ tm_port = tm.get_port()
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 [*Running multiple Traffic Managers*](#running-multiple-traffic-managers) section to learn more about this.
+ Creating or connecting to a TM in multi-client situations is different from the above example. Learn more in the section [__Running multiple Traffic Managers__](#running-multiple-traffic-managers).
-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.
+The `generate_traffic.py` script in `/PythonAPI/examples` provides an example of how to create a TM instance using a port passed as a script argument and register every vehicle spawned to it by setting the autopilot to `True` in a batch:
```py
traffic_manager = client.get_trafficmanager(args.tm-port)
@@ -244,9 +286,9 @@ batch.append(SpawnActor(blueprint, transform).then(SetAutopilot(FutureActor, Tru
traffic_manager.global_percentage_speed_difference(30.0)
```
-### Setting a Traffic Manager
+### Configuring autopilot behavior
-The following example creates an instance of the TM and sets a dangerous behaviour for a specific car that will ignore all traffic lights, leave no safety distance with the rest and drive at 120% its current speed limit.
+The following example creates a TM instance and configures dangerous behavior for a specific vehicle so it will ignore all traffic lights, leave no safety distance from other vehicles, and drive 20% faster than the current speed limit:
```python
tm = client.get_trafficmanager(port)
@@ -259,7 +301,8 @@ tm.distance_to_leading_vehicle(danger_car,0)
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.
+The example below sets the same list of vehicles to autopilot but instead configures them with moderate driving behavior. The vehicles drive 80% slower than the current speed limit, leaving at least 5 meters between themselves and other vehicles, and never perform lane changes:
+
```python
tm = client.get_trafficmanager(port)
tm_port = tm.get_port()
@@ -274,56 +317,65 @@ for v in my_vehicles:
### 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.
+The TM is not an actor that needs to be destroyed; it will stop when the client that created it stops. This is automatically managed by the API, the user does not have to do anything. However, when shutting down a TM, the user must destroy the vehicles controlled by it, otherwise they will remain immobile on the map. The script `generate_traffic.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 about [*Running multiple Traffic Managers*](#running-multiple-traffic-managers).
+```py
+client.apply_batch([carla.command.DestroyActor(x) for x in vehicles_list])
+```
+
+!!! 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 about [__Running multiple Traffic Managers__](#running-multiple-traffic-managers).
---
## Deterministic mode
-In deterministic mode, the Traffic Manager will always produce the same results and behaviours under the same conditions. Do not mistake determinism with the recorder. While the recorder allows you to store the log of a simulation to play it back, determinism ensures that Traffic Manager will always have the same output over different executions of a script, if the same conditions are maintained.
+In deterministic mode, the TM will produce the same results and behaviors under the same conditions. Do not mistake determinism with the recorder. While the recorder allows you to store the log of a simulation to play it back, determinism ensures that the TM will always have the same output over different executions of a script as long as the same conditions are maintained.
-Deterministic mode is meant to be used __in synchronous mode only__. In asynchronous mode, there is much less control over the simulation, and determinism cannot be achieved. Read the considerations to run [TM in synchronous mode](#synchronous-mode) before using it.
+Deterministic mode is available __in synchronous mode only__. In asynchronous mode, there is less control over the simulation and determinism cannot be achieved. Read more in the section [__"Synchronous mode"__](#synchronous-mode) before starting.
-
-To enable deterministic mode, simply call the following method in your script.
+To enable deterministic mode, use the following method:
```py
my_tm.set_random_device_seed(seed_value)
-```
+```
-`seed_value` is an `int` number from which all the random numbers will be generated. The value is not relevant itself, but the same value will always result in the same output. Two simulations, with the same conditions, that use the same seed value, will be deterministic.
+`seed_value` is an `int` number from which random numbers will be generated. The value itself is not relevant, but the same value will always result in the same output. Two simulations, with the same conditions, that use the same seed value, will be deterministic.
-The deterministic mode can be tested when using the `spawn_npc.py` example script, using a simple argument. The following example sets the seed to `9` for no specific reason.
+To maintain determinism over multiple simulation runs, __the seed must be set for every simulation__. For example, each time the world is [reloaded](python_api.md#carla.Client.reload_world), the seed must be set again:
+
+```py
+client.reload_world()
+my_tm.set_random_device_seed(seed_value)
+```
+
+Deterministic mode can be tested in the `generate_traffic.py` example script by passing a seed value as an argument. The following example populates a map with 50 autopilot actors in synchronous mode and sets the seed to an arbitrary value of `9`:
```sh
cd PythonAPI/examples
-python3 spawn_npc.py -n 50 --sync --seed 9
+python3 generate_traffic.py -n 50 --seed 9
```
!!! Warning
- Make sure to set both the world and the TM to synchronous mode before enabling deterministic mode.
+ The CARLA server and the TM must be in synchronous mode before enabling deterministic mode. Read more [here](#synchronous-mode) about synchronous mode in TM.
---
## Hybrid physics mode
-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.
+Hybrid mode allows users to disable most physics calculations for all autopilot vehicles, or for autopilot vehicles outside of a certain radius of a vehicle tagged with `hero`. This removes the vehicle physics bottleneck from a simulation. Vehicles whose physics are disabled will move by teleportation. Basic calculations for linear acceleration are maintained to ensure position updates and vehicle speed remain realistic and the toggling of physics calculations on vehicles is fluid.
-The hybrid mode is disabled by default. There are two ways to enable it.
+Hybrid mode uses the [`Actor.set_simulate_physics()`](https://carla.readthedocs.io/en/latest/python_api/#carla.Actor.set_simulate_physics) method to toggle physics calculations. It is disabled by default. There are two options to enable it:
-* [__TrafficManager.set_hybrid_physics_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.
+* [__`TrafficManager.set_hybrid_physics_mode(True)`__](https://carla.readthedocs.io/en/latest/python_api/#carla.TrafficManager.set_hybrid_physics_mode) — This method enables hybrid mode for the TM object calling it.
+* __Running `generate_traffic.py` with the flag `--hybrid`__ — This example script creates a TM and spawns vehicles in autopilot. It then sets these vehicles to hybrid mode when the `--hybrid` flag is passed as a script argument.
-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.
+To modify the behavior of hybrid mode, use the following two parameters:
-* __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.
+* __Radius__ *(default = 50 meters)* — The radius is relative to vehicles tagged with `hero`. All vehicles inside this radius will have physics enabled; vehicles outside of the radius will have physics disabled. The size of the radius is modified using [`traffic_manager.set_hybrid_physics_radius(r)`](python_api.md#carla.TrafficManager.set_hybrid_physics_radius).
+* __Hero vehicle__ — A vehicle tagged with `role_name='hero'` that acts as the center of the radius.
+ * __If there is no hero vehicle,__ all vehicles' physics will be disabled.
+ * __If there is more than one hero vehicle,__ the radius will be considered for them all, creating 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__.
+The clip below shows how physics is enabled and disabled when hybrid mode is active. The __hero vehicle__ is tagged with a __red square__. Vehicles with __physics disabled__ are tagged with a __blue square__. When inside the hero vehicle's radius of influence, __physics are enabled and the tag becomes green__.
![Welcome to CARLA](img/tm_hybrid.gif)
@@ -331,14 +383,15 @@ The following example shows how the physics are enabled and disabled when hybrid
---
## Running multiple Traffic Managers
-### Definitions
+### Traffic Manager servers and clients
-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 CARLA client creates a TM by specifying to the server which port to use. If a port is not specified, the default `8000` will be used. If further TMs are created on the same port, they will become __TM-Clients__ and the original TM will become a __TM-Server__. These titles define how a TM behaves within a simulation.
-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
+A TM-Server is created if it was the first TM to connect to a free port and then other TMs (TM-Clients) connected to the same port it was running on. __The TM-Server will dictate the behavior of all the TM-Clients__, e.g., if the TM-Server is stopped, all TM-Clients will stop.
-* __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.
+The following code creates two TM-Servers. Each one connects to a different, unused port:
```py
tm01 = client01.get_trafficmanager() # tm01 --> tm01 (p=8000)
@@ -347,65 +400,64 @@ tm01 = client01.get_trafficmanager() # tm01 --> tm01 (p=8000)
tm02 = client02.get_trafficmanager(5000) # tm02(p=5000) --> tm02 (p=5000)
```
-* __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.
+###### TM-Client
-```py
+A TM-Client is created when a TM connects to a port occupied by another TM (TM-Server). The TM-Client behavior will be dictated by the TM-Server.
+
+The following code creates two TM-Clients, each one connecting with the TM-Servers created in the section above.
+
+```py
tm03 = client03.get_trafficmanager() # tm03 --> tm01 (p=8000).
```
```py
tm04 = client04.get_trafficmanager(5000) # tm04(p=5000) --> tm02 (p=5000)
```
-!!! Important
- Note how the default creation of a TM uses always `port=8000`, and so, only the first time a __TM-Server__ is created. The rest will be __TM-Clients__ connecting to it.
+The CARLA server keeps a register of all TM instances by storing the port and the client IP (hidden to the user) that link to them. There is currently 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__.
-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__.
+### Multi-client simulations
-!!! Note
- The class `TrafficManager.cpp` acts as a central hub managing all the different TM instances.
+In a multi-client simulation, multiple TMs are created on the same port. The first TM will be a TM-Server and the rest will be TM-Clients connecting to it. The TM-Server will dictate the behavior of all the 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
+terminal 2: python3 generate_traffic.py --port 4000 --tm-port 4050 # TM-Server
+terminal 3: python3 generate_traffic.py --port 4000 --tm-port 4050 # TM-Client
```
-### MultiTM
+### Multi-TM simulations
+
+In a multi-TM simulation, multiple TM instances are created on distinct ports. Each TM instance will control its own behavior:
-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
+terminal 2: python3 generate_traffic.py --port 4000 --tm-port 4050 # TM-Server A
+terminal 3: python3 generate_traffic.py --port 4000 --tm-port 4550 # TM-Server B
```
-### Multisimulation
+### Multi-simulation
-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.
+Multi-simulation is when more than one CARLA server is running at the same time. The TM needs to connect to the relevant CARLA server port. 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
+terminal 3: python3 generate_traffic.py --port 4000 --tm-port 4050 # TM-Server A connected to simulation A
+terminal 4: python3 generate_traffic.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 concept of multi-simulation is independent of the TM 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 multi-client TM while simulation B is running a multi-TM 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.
+The most likely issue arising from the above set-up is a client trying to connect to an already existing TM that is not running on the selected simulation. If this happens, an error message will appear and the connection will be aborted to prevent interferences between simulations.
---
-## Other considerations
+## Synchronous mode
-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.
+TM is designed to work in synchronous mode. Both the CARLA server and TM should be set to synchronous in order to function properly. __Using TM in asynchronous mode can lead to unexpected and undesirable results,__ however, if asynchronous mode is required, the simulation should run at 20-30 fps at least.
-### Synchronous mode
+The script below demonstrates how to set both the server and TM to synchronous mode:
-If the CARLA server is set to synchronous mode, the Traffic Manager must be set to synchronous mode too. To do so, your script should be similar to the following:
```py
...
@@ -413,7 +465,7 @@ If the CARLA server is set to synchronous mode, the Traffic Manager must be set
init_settings = world.get_settings()
settings = world.get_settings()
settings.synchronous_mode = True
-# Right after that, set the Traffic Manager to sync mode
+# After that, set the TM to sync mode
my_tm.set_synchronous_mode(True)
...
@@ -423,37 +475,74 @@ world.apply_settings(init_settings)
world.tick()
...
-# Disable the sync mode always, before the script ends
+# Always disable sync mode before the script ends to prevent the server blocking whilst waiting for a tick
settings.synchronous_mode = False
my_tm.set_synchronous_mode(False)
```
-When using the `spawn_npc.py` example script, the TM can be set to synchronous mode just by passing an argument.
+The `generate_traffic.py` example script starts a TM and populates the map with vehicles and pedestrians. It automatically sets the TM and the CARLA server to synchronous mode:
```sh
cd PythonAPI/examples
-python3 spawn_npc.py -n 50 --sync
+python3 generate_traffic.py -n 50
```
-If more than one Traffic Manager is set to synchronous mode, the synchrony will fail. Follow these general guidelines to avoid issues.
+If asynchronous mode is required, use the `--async` flag when running the above command.
-* In a __[multiclient](#multiclient)__ situation, only the __TM-Server__ must be set to synchronous mode.
-* In a __[multiTM](#multitm)__ situation, only __one of the TM-Server__ must be set to synchronous mode.
-* The __[ScenarioRunner module](https://carla-scenariorunner.readthedocs.io/en/latest/)__, already runs a TM. In this case, the TM inside ScenarioRunner will be the one set to sync mode.
+If more than one TM is set to synchronous mode, synchrony will fail. Follow these guidelines to avoid issues:
+
+- In a __[multiclient](#multiclient)__ situation, only the __TM-Server__ should be set to synchronous mode.
+- In a __[multiTM](#multitm)__ situation, only __one TM-Server__ should be set to synchronous mode.
+- The __[ScenarioRunner module](https://carla-scenariorunner.readthedocs.io/en/latest/)__ runs a TM automatically. The TM inside ScenarioRunner will automatically be the one set to sync mode.
!!! Warning
- Disable the synchronous mode (both, world and TM sync mode) in the script doing the ticks before it finishes. Otherwise, the server will be blocked, waiting forever for a tick.
+ Disable synchronous mode (for both the world and TM) in your script managing ticks before it finishes to prevent the server blocking, waiting forever for a tick.
---
-## Summary
+## Traffic manager in large maps
-The Traffic Manager is one of the most complex features in CARLA and so, one that is prone to all kind of unexpected and really specific issues. The CARLA forum is open to everybody to post any doubts or suggestions, and it is the best way to keep track of issues and help the CARLA community to become greater. Feel free to login and join the community.
+To understand how the TM works on large maps, make sure to first familiarise yourself with how large maps work by reading the documentation [here](large_map_overview.md).
+
+The behavior of autopilot vehicles in large maps depends on whether or not there is a hero vehicle present:
+
+__Hero vehicle not present__
+
+All autopilot vehicles will be considered dormant actors. The dormant autopilot actors will be moved around the map as in hybrid mode. The vehicles will not be rendered since there is no hero vehicle to trigger map tile streaming.
+
+__Hero vehicle present__
+
+Autopilot vehicles will become dormant when they exceed the value defined by `actor_active_distance`. To set this value, use the Python API:
+
+```py
+settings = world.get_settings()
+
+# Actors will become dormant 2km away from the ego vehicle
+settings.actor_active_distance = 2000
+
+world.apply_settings(settings)
+```
+
+In the TM, dormant actors can be configured to continually respawn around the hero vehicle instead of remaining dormant on other parts of the map. This option can be configured using the `set_respawn_dormant_vehicles` method in the Python API. Vehicles will be respawned within a user-definable distance of the hero vehicle. The upper and lower boundaries of the respawnable distance can be set using the `set_boundaries_respawn_dormant_vehicles` method. Note that the upper distance will not be bigger than the tile streaming distance of the large map and the minimum lower distance is 20m.
+
+To enable respawning of dormant vehicles within 25 and 700 meters of the hero vehicle:
+
+```py
+my_tm.set_respawn_dormant_vehicles(True)
+my_tm.set_boundaries_respawn_dormant_vehicles(25,700)
+```
+
+If collisions prevent a dormant actor from being respawned, the TM will retry on the next simulation step.
+
+If dormant vehicles are not respawned, their behavior will depend on whether hybrid mode is enabled. If hybrid mode has been enabled, then the dormant actors will be teleported around the map. If hybrid mode is not enabled, then dormant actor's physics will not be computed and they will stay in place until they are no longer dormant.
+
+---
+
+If you have any questions about the TM, then you can ask in the [forum](https://github.com/carla-simulator/carla/discussions).
diff --git a/Docs/build_docker_unreal.md b/Docs/build_docker_unreal.md
new file mode 100644
index 000000000..6a43c1b92
--- /dev/null
+++ b/Docs/build_docker_unreal.md
@@ -0,0 +1,96 @@
+# Build Unreal Engine and CARLA in Docker
+
+This guide explains how Unreal Engine and CARLA can be built from scratch using Docker. The resulting image can then used to create CARLA packages or to prepare assets for use in a CARLA package. This process should not be confused with the pre-built CARLA Docker image used to run CARLA on multiple servers or without a display. The documentation for that can be found [here](build_docker.md).
+
+- [__Before you begin__](#before-you-begin)
+ - [__System Requirements__](#system-requirements)
+ - [__Software requirements__](#software-requirements)
+- [__Building the images__](#building-the-images)
+- [__Next Steps: Packages__](#next-steps-packages)
+
+---
+
+## Before you begin
+
+##### System Requirements
+
+You will need to meet the following system requirements:
+
+- 64-bit version of Docker is Ubuntu 16.04+
+- Minimum 8GB of RAM
+- Minimum 600GB available disk space for the initial container build process
+
+##### Software requirements
+
+__Docker:__
+
+Install Docker by following the installation instructions [here](https://docs.docker.com/engine/install/).
+
+__Python__:
+
+You will need to have Python 3.6 or higher installed and properly set in your system Path. For installation instructions and Python documentation, check [here](https://www.python.org/downloads/).
+
+__Unreal Engine GitHub Access__:
+
+Starting with version 0.9.12, CARLA uses a modified fork of Unreal Engine 4.26. This fork contains patches specific to CARLA. This will be downloaded during the Docker build process. For this download, __you need to have a GitHub account linked to Unreal Engine's account__. If you don't have this set up, please follow [this guide](https://www.unrealengine.com/en-US/ue4-on-github) before going any further. You will need to log in to your account during the build process.
+
+__CARLA:__
+
+The Dockerfiles and tools needed to build Unreal Engine for CARLA and CARLA itself are located in the `Util/Docker` directory of the CARLA source repository.
+
+If you don't already have it, download the repository using the following command:
+
+```sh
+git clone https://github.com/carla-simulator/carla
+```
+
+---
+
+## Building the images
+
+The following steps will each take a long time.
+
+__1. Build the CARLA prerequisites image.__
+
+The following command will build an image called `carla-prerequisites` using `Prerequisites.Dockerfile`. In this build we install the compiler and required tools, download the Unreal Engine 4.26 fork and compile it. You will need to provide your login details as build arguments for the download of Unreal Engine to be successful:
+
+```sh
+docker build --build-arg EPIC_USER= --build-arg EPIC_PASS= -t carla-prerequisites -f Prerequisites.Dockerfile .
+```
+
+__2. Build the final CARLA image.__
+
+The following command will use the image created in the previous step to build the final CARLA image based on the current master branch (latest release) of the CARLA repository:
+
+```sh
+docker build -t carla -f Carla.Dockerfile .
+```
+
+If you would like to build a specific branch or tag of the CARLA repository, run the following command:
+
+```sh
+docker build -t carla -f Carla.Dockerfile . --build-arg GIT_BRANCH=
+```
+
+---
+
+## Next Steps: Packages
+
+The CARLA image created in this guide is used to create standalone CARLA packages or to package assets such as maps or meshes so they can be used in a CARLA package. This is achieved through the use of the `docker_tools.py` script found in `Util/Docker`. This script uses [`docker-py`](https://github.com/docker/docker-py) to work with the Docker image.
+
+The `docker_tools.py` script can be used to:
+
+- __Create a CARLA package__: Find the tutorial [here](tuto_A_create_standalone.md#export-a-package-using-docker)
+- __Cook assets to be consumed in a CARLA package:__ Find the tutorial [here](tuto_A_add_props.md#ingestion-in-a-carla-package)
+- __Prepare a map so it's ready for use in a CARLA package:__ Find the tutorial [here](tuto_M_add_map_package.md)
+
+---
+
+Any issues or doubts related with this topic can be posted in the CARLA forum.
+
+
diff --git a/Docs/build_faq.md b/Docs/build_faq.md
index c034c993a..27ce114dc 100644
--- a/Docs/build_faq.md
+++ b/Docs/build_faq.md
@@ -4,7 +4,7 @@ Some of the most common issues regarding CARLA installation and builds are liste
@@ -37,6 +37,7 @@ CARLA forum
* ["make launch" is not working on Windows.](#make-launch-is-not-working-on-windows)
* [Make is missing libintl3.dll or/and libiconv2.dll.](#make-is-missing-libintl3dll-orand-libiconv2dll)
* [Modules are missing or built with a different engine version.](#modules-are-missing-or-built-with-a-different-engine-version)
+* [There is no `dist` folder in `PythonAPI/carla` despite a successful output message.](#there-is-no-dist-folder-in-pythonapicarla-despite-a-successful-output-message)
---
@@ -48,6 +49,7 @@ CARLA forum
* [Can't run CARLA neither binary nor source build.](#cant-run-carla-neither-binary-nor-source-build)
* [ImportError: DLL load failed: The specified module could not be found.](#importerror-dll-load-failed-the-specified-module-could-not-be-found)
* [ImportError: DLL load failed while importing libcarla: %1 is not a valid Win32 app.](#importerror-dll-load-failed-while-importing-libcarla-1-is-not-a-valid-win32-app)
+* [ImportError: No module named 'carla'](#importerror-no-module-named-carla)
---
@@ -55,6 +57,8 @@ CARLA forum
* [Fatal error: 'version.h' has been modified since the precompiled header.](#fatal-error-versionh-has-been-modified-since-the-precompiled-header)
* [Create a binary version of CARLA.](#create-a-binary-version-of-carla)
+* [Can I package CARLA for Windows on a Linux machine and vice versa?](#can-i-package-carla-for-windows-on-a-linux-machine-and-vice-versa)
+* [How do I uninstall the CARLA client library?](#how-do-i-uninstall-the-carla-client-library)
---
@@ -64,17 +68,15 @@ CARLA forum
###### Expected disk space to build CARLA.
-> It is advised to have at least 30-50GB free. Building CARLA requires about 25GB of disk space, plus Unreal Engine, which is similar in size.
->
-> Unreal Engine on Linux requires much more disk space as it keeps all the intermediate files. [This thread](https://answers.unrealengine.com/questions/430541/linux-engine-size.html) discusses the matter.
+> It is advised to have at least 170GB free. Building CARLA requires about 35GB of disk space, plus Unreal Engine which requires about 95-135GB.
###### Recommended hardware to run CARLA.
-> CARLA is a performance demanding software. At the very minimum it requires a 4GB GPU or, even better, a dedicated GPU capable of running Unreal Engine.
+> CARLA is a performance demanding software. At the very minimum it requires a 6GB GPU or, even better, a dedicated GPU capable of running Unreal Engine.
>
-> Take a look at [Unreal Engine's recommended hardware](https://wiki.unrealengine.com/Recommended_Hardware).
+> Take a look at [Unreal Engine's recommended hardware](https://www.ue4community.wiki/recommended-hardware-x1p9qyg0).
---
@@ -92,14 +94,14 @@ CARLA forum
> Many different issues can be dragged out during the build installation and will manifest themselves like this. Here is a list of the most likely reasons why:
>
-> * __Run Unreal Engine 4.24.__ Something may have failed when building Unreal Engine. Try running UE editor on its own and check that it is the 4.24 release.
+> * __Run Unreal Engine 4.26.__ Something may have failed when building Unreal Engine. Try running UE editor on its own and check that it is the 4.26 release.
> * __Download the assets.__ The server will not be able to run without the visual content. This step is mandatory.
-> * __UE4_ROOT is not defined.__ The environment variable is not set. Remember to make it persistent session-wide by adding it to the `~/.bashrc` or `~/.profile`. Otherwise it will need to be set for every new shell. Run `export UE4_ROOT=~/UnrealEngine_4.24` to set the variable this time.
+> * __UE4_ROOT is not defined.__ The environment variable is not set. Remember to make it persistent session-wide by adding it to the `~/.bashrc` or `~/.profile`. Otherwise it will need to be set for every new shell. Run `export UE4_ROOT=` to set the variable this time.
> * __Check dependencies.__ Make sure that everything was installed properly. Maybe one of the commands was skipped, unsuccessful or the dependencies were not suitable for the system.
> * __Delete CARLA and clone it again.__ Just in case something went wrong. Delete CARLA and clone or download it again.
-> * __Meet system requirements.__ Ubuntu version should be 16.04 or later. CARLA needs around 15GB of disk space and a dedicated GPU (or at least one with 4GB) to run.
+> * __Meet system requirements.__ Ubuntu version should be 16.04 or later. CARLA needs around 170GB of disk space and a dedicated GPU (or at least one with 6GB) to run.
>
-> Other specific reasons for a system to show conflicts with CARLA may occur. Please, post these on the [forum](https://forum.carla.org/) so the team can get to know more about them.
+> Other specific reasons for a system to show conflicts with CARLA may occur. Please, post these on the [forum](https://github.com/carla-simulator/carla/discussions/) so the team can get to know more about them.
@@ -109,8 +111,8 @@ CARLA forum
>
> __2. Is git properly installed?__ Sometimes an error shows incompatibilities with the `https` protocol. It can be solved easily by uninstalling and reinstalling git. Open a terminal and run the following commands:
>
-> $ sudo apt-get remove git #Uninstall git
-> $ sudo apt install git-all #install git
+> sudo apt-get remove git #Uninstall git
+> sudo apt install git-all #install git
>
@@ -120,18 +122,18 @@ CARLA forum
> Run the following command.
>
>
-> $ pip3 install -Iv setuptools==47.3.1
+> pip3 install -Iv setuptools==47.3.1
>
>
> And build the PythonAPI again.
>
>
-> $ make PythonAPI
+> make PythonAPI
>
>
> Try to build the docs to test if everything is running properly. A successful message should show.
>
-> $ make PythonAPI.docs
+> make PythonAPI.docs
@@ -140,39 +142,44 @@ CARLA forum
> ![faq_rpc_error](img/faq_rpc_error.jpg)
>
> If running a script returns an output similar to this, there is a problem with the `.egg` file in the PythonAPI.
+
+!!! Important
+ If you are using 0.9.12+, there are several methods to use/install the client library. If you are using one of the newer methods for the client library (`.whl` or PyPi download) the information in this section will not be relevant to you.
>
> First of all, open `/PythonAPI/carla/dist`. There should be an `.egg` file for the corresponding CARLA and Python version you are using (similar to `carla-0.X.X-pyX.X-linux-x86_64.egg`). Make sure the file matches the Python version you are using. To check your Python version use the following command.
>
>
-> $ python3 --version # CARLA no longer provides support for Python2, so we are dismissing it here
+> python3 --version
+> # or for Python 2
+> python --version
>
>
> If either the file is missing or you think it could be corrupted, try rebuilding again.
>
-> $ make clean
-> $ make PythonAPI
-> $ make launch
+> make clean
+> make PythonAPI
+> make launch
>
>
> Now try one of the example scripts again.
>
-> $ cd PythonAPI/examples
-> $ python3 dynamic_weather.py
+> cd PythonAPI/examples
+> python3 dynamic_weather.py
>
> If the error persists, the problem is probably related with your PythonPATH. These scripts automatically look for the `.egg` file associated with the build, so maybe there is another `.egg` file in your PythonPATH interfering with the process. Show the content of the PythonPATH with the following command.
>
>
-> $ echo $PYTHONPATH
+> echo $PYTHONPATH
>
> Look up in the output for other instances of `.egg` files in a route similar to `PythonAPI/carla/dist`, and get rid of these. They probably belong to other instances of CARLA installations. For example, if you also installed CARLA via *apt-get*, you can remove it with the following command, and the PythonPATH will be cleaned too.
>
-> $ sudo apt-get purge carla-simulator
+> sudo apt-get purge carla-simulator
>
> Ultimately there is the option to add the `.egg` file of your build to the PythonPATH using the `~/.bashrc`. This is not the recommended way. It would be better to have a clear PythonPATH and simply add the path to the necessary `.egg` files in the scripts.
>
> First, open `~/.bashrc`.
>
-> $ gedit ~/.bashrc
+> gedit ~/.bashrc
>
>
> Add the following lines to `~/.bashrc`. These store the path to the build `.egg` file, so that Python can automatically find it. Save the file, and reset the terminal for changes to be effective.
@@ -201,7 +208,7 @@ CARLA forum
>
> __1.__ Go to `carla/Unreal/CarlaUE4` and right-click the `CarlaUE4.uproject`.
> __2.__ Click on __Generate Visual Studio project files__.
-> __3.__ Open the file generated with Visual Studio 2017.
+> __3.__ Open the file generated with Visual Studio 2019.
> __4.__ Compile the project with Visual Studio. The shortcut is F7. The build will fail, but the issues found will be shown below.
>
> Different issues may result in this specific error message. The user [@tamakoji](https://github.com/tamakoji) solved a recurrent case where the source code hadn't been cloned properly and the CARLA version could not be set (when downloading this as a .zip from git).
@@ -228,13 +235,13 @@ CARLA forum
> This issue occurs when trying to use the _make_ command either to build the server or the client. Even if CMake is installed, updated and added to the environment path. There may be a conflict between Visual Studio versions.
>
-> Leave only VS2017 and completely erase the rest.
+> Leave only VS2019 and completely erase the rest.
###### Error C2440, C2672: compiler version.
-> The build is not using the 2017 compiler due to conflicts with other Visual Studio or Microsoft Compiler versions. Uninstall these and rebuild again.
+> The build is not using the 2019 compiler due to conflicts with other Visual Studio or Microsoft Compiler versions. Uninstall these and rebuild again.
>
> Visual Studio is not good at getting rid of itself. To completely clean Visual Studio from the computer go to `Program Files (x86)\Microsoft Visual Studio\Installer\resources\app\layout` and run `.\InstallCleanup.exe -full`. This may need admin permissions.
>
@@ -242,13 +249,13 @@ CARLA forum
>
> ```
>
-> VisualStudio2017
+> VisualStudio2019
>
> ```
>
> ```
>
-> VisualStudio2017
+> VisualStudio2019
>
> ```
@@ -259,13 +266,13 @@ CARLA forum
> Many different issues can be dragged out during the build installation and manifest themselves like this. Here is a list of the most likely reasons why:
>
> * __Restart the computer.__ There is a lot going on during the Windows build. Restart and make sure that everything is updated properly.
-> * __Run Unreal Engine 4.24.__ Something may have failed when building Unreal Engine. Run the Editor and check that version 4.24 is being used.
+> * __Run Unreal Engine 4.26.__ Something may have failed when building Unreal Engine. Run the Editor and check that version 4.26 is being used.
> * __Download the assets.__ The server will not be able to run without the visual content. This step is mandatory.
-> * __Visual Studio 2017.__ If there are other versions of Visual Studio installed or recently uninstalled, conflicts may arise. To completely clean Visual Studio from the computer go to `Program Files (x86)\Microsoft Visual Studio\Installer\resources\app\layout` and run `.\InstallCleanup.exe -full`.
+> * __Visual Studio 2019.__ If there are other versions of Visual Studio installed or recently uninstalled, conflicts may arise. To completely clean Visual Studio from the computer go to `Program Files (x86)\Microsoft Visual Studio\Installer\resources\app\layout` and run `.\InstallCleanup.exe -full`.
> * __Delete CARLA and clone it again.__ Just in case something went wrong. Delete CARLA and clone or download it again.
-> * __Meet system requirements.__ CARLA needs around 30-50GB of disk space and a dedicated GPU (or at least one with 4GB) to run.
+> * __Meet system requirements.__ CARLA needs around 170GB of disk space and a dedicated GPU (or at least one with 6GB) to run.
>
-> Other specific reasons for a system to show conflicts with CARLA may occur. Please, post these on the [forum](https://forum.carla.org/) so the team can get to know more about them.
+> Other specific reasons for a system to show conflicts with CARLA may occur. Please, post these on the [forum](https://github.com/carla-simulator/carla/discussions/) so the team can get to know more about them.
@@ -279,6 +286,12 @@ CARLA forum
> Click on __Accept__ to rebuild them.
+
+
+###### There is no `dist` folder in `PythonAPI/carla` despite a successful output message.
+
+>In Windows, the `make PythonAPI` command can return a message that the Python API was installed successfully when it actually wasn't. If there is no `dist` folder created in the `PythonAPI/carla` directory after you see this output, then look at the command output higher up. It is likely an error occurred and the build needs to be retried after correcting the error and running `make clean`.
+
---
## Running CARLA
@@ -308,7 +321,7 @@ CARLA forum
###### Can't run CARLA neither binary nor source build.
-> NVIDIA drivers may be outdated. Make sure that this is not the case. If the issue is still unresolved, take a look at the [forum](https://forum.carla.org/) and post the specific issue.
+> NVIDIA drivers may be outdated. Make sure that this is not the case. If the issue is still unresolved, take a look at the [forum](https://github.com/carla-simulator/carla/discussions/) and post the specific issue.
@@ -322,6 +335,47 @@ CARLA forum
> A 32-bit Python version is creating conflicts when trying to run a script. Uninstall it and leave only the Python3 x64 required.
+
+
+###### ImportError: No module named 'carla'
+
+> This error occurs because Python cannot find the CARLA library. The CARLA library is contained in an `.egg` file, located in the directory `PythonAPI/carla/dist` and all the example scripts will look for it in this directory. The `.egg` file follows the nomenclature of `carla--py-.egg`.
+>
+
+!!! Important
+ CARLA only used `.egg` files for the client library in versions prior to 0.9.12. If you are using 0.9.12+, there are several methods to use/install the client library. If you are using one of the newer methods for the client library (`.whl` or PyPi download) the information in this section will not be relevant to you.
+
+ Read more about the newer methods to use/install the client library in the [__Quickstart tutorial__](start_quickstart.md#carla-0912).
+
+>If you are using a packaged version of CARLA, there will be several `.egg` files, corresponding to different versions of Python, depending on the version of CARLA. Make sure you are running the scripts with one of these Python versions. To check the default Python version, type the following into the command line:
+>
+>
+> python3 --version
+> # or
+> python --version
+>
+
+>If you built Python from source, the `.egg` file will be built according to the default Python version on your system. In Linux this will be the default Python version returned for:
+
+
+> /usr/bin/env python3 --version
+> # or if you specify ARGS="--python-version=2"
+> /usr/bin/env python2 --version
+
+
+>In Windows it will be the default Python version for:
+
+> py -3 --version
+
+>Make sure you are running your scripts with the version of Python that corresponds to your `.egg` file.
+>In Linux, you may also need to set your Python path to point to the CARLA `.egg`. To do this, run the following command:
+
+> export PYTHONPATH=$PYTHONPATH:/PythonAPI/carla/dist/
+> # Check if CARLA can now be found
+> python3 -c 'import carla;print("Success")'
+
+>Be aware that virtual environments, or other Python environments like Conda, can complicate the installation of CARLA. Make sure you have set up your Python defaults and paths accordingly.
+
---
## Other
@@ -331,8 +385,8 @@ CARLA forum
> This happens from time to time due to Linux updates. There is a special target in the Makefile for this issue. It takes a long time but fixes the issue:
>
-> $ make hard-clean
-> $ make CarlaUE4Editor
+> make hard-clean
+> make CarlaUE4Editor
@@ -342,4 +396,23 @@ CARLA forum
>
> Alternatively, it is possible to compile a binary version of CARLA within Unreal Editor. Open the CarlaUE4 project, go to the menu `File/Package Project`, and select a platform. This may take a while.
----
\ No newline at end of file
+
+
+###### Can I package CARLA for Windows on a Linux machine and vice versa?
+
+>Although this feature is available for Unreal Engine, it is not available in CARLA. We have a number of dependencies that are not supported to be cross compiled.
+
+
+###### How do I uninstall the CARLA client library?
+
+>If you installed the client library using __pip/pip3__, you should uninstall it by running:
+
+```sh
+# Python 3
+pip3 uninstall carla
+
+# Python 2
+pip uninstall carla
+```
+
+---
diff --git a/Docs/build_linux.md b/Docs/build_linux.md
index 124c05e61..12b2c6f4e 100644
--- a/Docs/build_linux.md
+++ b/Docs/build_linux.md
@@ -1,115 +1,36 @@
# Linux build
-* [__Linux build command summary__](#linux-build-command-summary)
-* [__Requirements__](#requirements)
- * [System specifics](#system-specifics)
- * [Dependencies](#dependencies)
-* [__GitHub__](#github)
-* [__Unreal Engine__](#unreal-engine)
-* [__CARLA build__](#carla-build)
- * [Clone repository](#clone-repository)
- * [Get assets](#get-assets)
- * [Set the environment variable](#set-the-environment-variable)
- * [make CARLA](#make-carla)
+This guide details how to build CARLA from source on Linux. There are two parts. Part one details system requirements and installations of required software, and part two details how to actually build and run CARLA.
-The build process can be quite long and tedious. The **[F.A.Q.](build_faq.md)** page offers solution for the most common complications. Alternatively, use the [CARLA forum](https://forum.carla.org/c/installation-issues/linux) to post any unexpected issues that may occur.
+The build process is long (4 hours or more) and involves several kinds of software. It is highly recommended to read through the guide fully before starting.
+
+If you come across errors or difficulties then have a look at the **[F.A.Q.](build_faq.md)** page which offers solutions for the most common complications. Alternatively, use the [CARLA forum](https://github.com/carla-simulator/carla/discussions) to post any queries you may have.
+
+- [__Part One: Prerequisites__](#part-one-prerequisites)
+ - [System requirements](#system-requirements)
+ - [Software requirements](#software-requirements)
+ - [Unreal Engine](#unreal-engine)
+- [__Part Two: Build CARLA__](#part-two-build-carla)
+ - [Clone the CARLA repository](#clone-the-carla-repository)
+ - [Get assets](#get-assets)
+ - [Set Unreal Engine environment variable](#set-unreal-engine-environment-variable)
+ - [Build CARLA](#build-carla)
+ - [Other make commands](#other-make-commands)
---
-## Linux build command summary
+## Part One: Prerequisites
-
- Show command lines to build on Linux
+### System requirements
-```sh
-# Make sure to meet the minimum requirements
-# Read the complete documentation to understand each step
-
-# Install dependencies
-sudo apt-get update &&
-sudo apt-get install wget software-properties-common &&
-sudo add-apt-repository ppa:ubuntu-toolchain-r/test &&
-wget -O - https://apt.llvm.org/llvm-snapshot.gpg.key|sudo apt-key add - &&
-sudo apt-add-repository "deb http://apt.llvm.org/$(lsb_release -c --short)/ llvm-toolchain-$(lsb_release -c --short)-8 main" &&
-sudo apt-get update
-
-# Additional dependencies for Ubuntu 18.04
-sudo apt-get install build-essential clang-8 lld-8 g++-7 cmake ninja-build libvulkan1 python python-pip python-dev python3-dev python3-pip libpng-dev libtiff5-dev libjpeg-dev tzdata sed curl unzip autoconf libtool rsync libxml2-dev &&
-pip2 install --user setuptools &&
-pip3 install --user -Iv setuptools==47.3.1
-
-# Additional dependencies for previous Ubuntu versions
-sudo apt-get install build-essential clang-8 lld-8 g++-7 cmake ninja-build libvulkan1 python python-pip python-dev python3-dev python3-pip libpng16-dev libtiff5-dev libjpeg-dev tzdata sed curl unzip autoconf libtool rsync libxml2-dev &&
-pip2 install --user setuptools &&
-pip3 install --user -Iv setuptools==47.3.1 &&
-pip2 install --user distro &&
-pip3 install --user distro
-
-# Change default clang version
-sudo update-alternatives --install /usr/bin/clang++ clang++ /usr/lib/llvm-8/bin/clang++ 180 &&
-sudo update-alternatives --install /usr/bin/clang clang /usr/lib/llvm-8/bin/clang 180
-
-# Get a GitHub and a UE account, and link both
-# Install git
-
-# Download Unreal Engine 4.24
-git clone --depth=1 -b 4.24 https://github.com/EpicGames/UnrealEngine.git ~/UnrealEngine_4.24
-cd ~/UnrealEngine_4.24
-
-# Download and install the UE patches
-wget https://carla-releases.s3.eu-west-3.amazonaws.com/Backup/UE4_patch_vulkan.patch
-wget https://carla-releases.s3.eu-west-3.amazonaws.com/Backup/UE4_patch_wheels.patch
-git apply UE4_patch_vulkan.patch UE4_patch_wheels.patch
-
-# Build UE
-./Setup.sh && ./GenerateProjectFiles.sh && make
-
-# Open the UE Editor to check everything works properly
-cd ~/UnrealEngine_4.24/Engine/Binaries/Linux && ./UE4Editor
-
-# Clone the CARLA repository
-git clone https://github.com/carla-simulator/carla
-
-# Get the CARLA assets
-cd ~/carla
-./Update.sh
-
-# Set the environment variable
-export UE4_ROOT=~/UnrealEngine_4.24
-
-# make the CARLA client and the CARLA server
-make PythonAPI
-make launch
-
-# Press play in the Editor to initialize the server
-# Run example scripts to test CARLA
-# Terminal A
-cd PythonAPI/examples
-python3 spawn_npc.py
-# Terminal B
-cd PythonAPI/examples
-python3 spawn_npc.py
-python3 dynamic_weather.py
-
-# Optionally, to compile the PythonAPI for Python2, run the following command in the root CARLA directory
-make PythonAPI ARGS="--python-version=2"
-```
-
-
-
----
-## Requirements
-
-### System specifics
-
-* __Ubuntu 18.04.__ CARLA provides support for previous Ubuntu versions up to 16.04. **However** proper compilers are needed for UE to work properly. Dependencies for Ubuntu 18.04 and previous versions are listed separatedly below. Make sure to install the ones corresponding to your system.
-* __100GB disk space.__ The complete build will require quite a lot of space, especially the Unreal Engine build (around 80GB). Make sure to have around 100GB of free disk space.
-* __An adequate GPU.__ CARLA aims for realistic simulations, so the server needs at least a 4GB GPU. A dedicated GPU is highly recommended for machine learning.
-* __Two TCP ports and good internet connection.__ 2000 and 2001 by default. Be sure neither the firewall nor any other application block these.
+* __Ubuntu 18.04.__ CARLA provides support for previous Ubuntu versions up to 16.04. **However** proper compilers are needed for Unreal Engine to work properly. Dependencies for Ubuntu 18.04 and previous versions are listed separatedly below. Make sure to install the ones corresponding to your system.
+* __130 GB disk space.__ Carla will take around 31 GB and Unreal Engine will take around 91 GB so have about 130 GB free to account for both of these plus additional minor software installations.
+* __An adequate GPU.__ CARLA aims for realistic simulations, so the server needs at least a 6 GB GPU although 8 GB is recommended. A dedicated GPU is highly recommended for machine learning.
+* __Two TCP ports and good internet connection.__ 2000 and 2001 by default. Make sure that these ports are not blocked by firewalls or any other applications.
-### Dependencies
+### Software requirements
-CARLA needs many dependencies to run. Some of them are built automatically during this process, such as *Boost.Python*. Others are binaries that should be installed before starting the build (*cmake*, *clang*, different versions of *Python* and much more). In order to do so, run the commands below in a terminal window.
+CARLA requires many different kinds of software to run. Some are built during the CARLA build process itself, such as *Boost.Python*. Others are binaries that should be installed before starting the build (*cmake*, *clang*, different versions of *Python*, etc.). To install these requirements, run the following commands:
```sh
sudo apt-get update &&
@@ -124,23 +45,18 @@ sudo apt-get update
The following commands depend on your Ubuntu version. Make sure to choose accordingly.
__Ubuntu 18.04__.
+
```sh
-sudo apt-get install build-essential clang-8 lld-8 g++-7 cmake ninja-build libvulkan1 python python-pip python-dev python3-dev python3-pip libpng-dev libtiff5-dev libjpeg-dev tzdata sed curl unzip autoconf libtool rsync libxml2-dev &&
-pip2 install --user setuptools &&
-pip3 install --user -Iv setuptools==47.3.1 &&
-pip2 install --user distro &&
-pip3 install --user distro
+sudo apt-get install build-essential clang-8 lld-8 g++-7 cmake ninja-build libvulkan1 python python-pip python-dev python3-dev python3-pip libpng-dev libtiff5-dev libjpeg-dev tzdata sed curl unzip autoconf libtool rsync libxml2-dev git
```
__Previous Ubuntu__ versions.
+
```sh
-sudo apt-get install build-essential clang-8 lld-8 g++-7 cmake ninja-build libvulkan1 python python-pip python-dev python3-dev python3-pip libpng16-dev libtiff5-dev libjpeg-dev tzdata sed curl unzip autoconf libtool rsync libxml2-dev &&
-pip2 install --user setuptools &&
-pip3 install --user -Iv setuptools==47.3.1 &&
-pip2 install --user distro &&
-pip3 install --user distro
+sudo apt-get install build-essential clang-8 lld-8 g++-7 cmake ninja-build libvulkan1 python python-pip python-dev python3-dev python3-pip libpng16-dev libtiff5-dev libjpeg-dev tzdata sed curl unzip autoconf libtool rsync libxml2-dev git
```
-__All Ubuntu systems__.
+__All Ubuntu systems__.
+
To avoid compatibility issues between Unreal Engine and the CARLA dependencies, use the same compiler version and C++ runtime library to compile everything. The CARLA team uses clang-8 and LLVM's libc++. Change the default clang version to compile Unreal Engine and the CARLA dependencies.
```sh
@@ -148,72 +64,73 @@ sudo update-alternatives --install /usr/bin/clang++ clang++ /usr/lib/llvm-8/bin/
sudo update-alternatives --install /usr/bin/clang clang /usr/lib/llvm-8/bin/clang 180
```
----
-## GitHub
+Starting with CARLA 0.9.12, users have the option to install the CARLA Python API using `pip` or `pip3`. Version 20.3 or higher is required. To check if you have a suitable version, run the following command:
-__1.__ Create a [GitHub](https://github.com/) account. CARLA is organized in different GitHub repositories, so an account will be needed to clone said repositories.
+```sh
+# For Python 3
+pip3 -V
-__2.__ Install [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) to manage the repositories via terminal.
+# For Python 2
+pip -V
+```
-__3.__ Create an [Unreal Engine](https://www.unrealengine.com/en-US/feed) account to access the Unreal Engine repositories, which are set to private.
+If you need to upgrade:
-__4.__ Connect both your GitHub and Unreal Engine accounts. Go to your personal settings in there is a section in [Unreal Engine](https://www.unrealengine.com/en-US/)'s website. Click on `Connections > Accounts`, and link both accounts. [Here](https://www.unrealengine.com/en-US/blog/updated-authentication-process-for-connecting-epic-github-accounts) is a brief explanation just in case.
+```sh
+# For Python 3
+pip3 install --upgrade pip
-!!! Warning
- New Unreal Engine accounts need activation. After creating the account, a verification mail will be sent. Check it out, or the UE repository will be shown as non-existent in the following steps.
+# For Python 2
+pip install --upgrade pip
+```
+
+You must install the following Python dependencies:
+
+```sh
+pip install --user setuptools &&
+pip3 install --user -Iv setuptools==47.3.1 &&
+pip install --user distro &&
+pip3 install --user distro &&
+pip install --user wheel &&
+pip3 install --user wheel auditwheel
+```
---
+
## Unreal Engine
-The current version of CARLA runs on __Unreal Engine 4.24__ only. In this guide, the installation will be done in `~/UnrealEngine_4.24`, but the path can be changed. If your path is different, change the following commands accordingly.
+Starting with version 0.9.12, CARLA uses a modified fork of Unreal Engine 4.26. This fork contains patches specific to CARLA.
-!!! Note
- Alternatively to this section, there is another [guide](https://docs.unrealengine.com/en-US/Platforms/Linux/BeginnerLinuxDeveloper/SettingUpAnUnrealWorkflow/index.html) to build UE on Linux. When consulting it, remember that CARLA will need the __4.24 release__, not the latest.
+Be aware that to download this fork of Unreal Engine, __you need to have a GitHub account linked to Unreal Engine's account__. If you don't have this set up, please follow [this guide](https://www.unrealengine.com/en-US/ue4-on-github) before going any further.
+
+__1.__ Clone the content for CARLA's fork of Unreal Engine 4.26 to your local computer:
-__1.__ Clone the content for Unreal Engine 4.24 in your local computer.
```sh
-git clone --depth=1 -b 4.24 https://github.com/EpicGames/UnrealEngine.git ~/UnrealEngine_4.24
+ git clone --depth 1 -b carla https://github.com/CarlaUnreal/UnrealEngine.git ~/UnrealEngine_4.26
```
-__2.__ Get into the directory where UE4.24 has been cloned.
+__2.__ Navigate into the directory where you cloned the repository:
```sh
-cd ~/UnrealEngine_4.24
+ cd ~/UnrealEngine_4.26
```
-__3.__ Download a patch for Unreal Engine. This patch fixes some Vulkan visualization issues that may occur when changing the map. Download and install it with the following commands.
+__3.__ Make the build. This may take an hour or two depending on your system.
```sh
-wget https://carla-releases.s3.eu-west-3.amazonaws.com/Linux/UE_Patch/430667-13636743-patch.txt 430667-13636743-patch.txt
-patch --strip=4 < 430667-13636743-patch.txt
+ ./Setup.sh && ./GenerateProjectFiles.sh && make
```
-!!! Warning
- If UE has already been built, install the patch, and make the build again.
-
-
-__4.__ Make the build. This may take an hour or two depending on your system.
+__4.__ Open the Editor to check that Unreal Engine has been installed properly.
```sh
-./Setup.sh && ./GenerateProjectFiles.sh && make
+ cd ~/UnrealEngine_4.26/Engine/Binaries/Linux && ./UE4Editor
```
-__5.__ Open the Editor to check that UE has been properly installed.
-```sh
-cd ~/UnrealEngine_4.24/Engine/Binaries/Linux && ./UE4Editor
-```
-
-Any issues this far are related with Unreal Engine. There is not much CARLA can do about it. However, the [build documentation](https://github.com/EpicGames/UnrealEngine/blob/release/Engine/Build/BatchFiles/Linux/README.md) provided by Unreal Engine may be helpful.
-
---
-## CARLA build
-The system should be ready to start building CARLA. Just for clarity, a brief summary so far.
-* Minimum technical requirements to run CARLA are suitable.
-* Dependencies have been properly installed.
-* GitHub account is ready.
-* Unreal Engine 4.24 runs smooth.
+## Part Two: Build CARLA
!!! Note
Downloading aria2 with `sudo apt-get install aria2` will speed up the following commands.
-### Clone repository
+### Clone the CARLA repository
@@ -221,115 +138,173 @@ The system should be ready to start building CARLA. Just for clarity, a brief su
CARLA repository
-The official repository of the project. Either download and extract it, or clone the repository with the following command line.
+The button above will take you to the official repository of the project. Either download from there and extract it locally or clone it using the following command:
```sh
-git clone https://github.com/carla-simulator/carla
+ git clone https://github.com/carla-simulator/carla
```
-Now the latest state of the simulator, known as `master` branch in the repository, has been copied in local. Here is brief introduction to the most relevant branches of the repository. Remember that you can change and check your branches with the command `git branch`.
-
-* __`master` branch__ — Latest fixes and features that have been tested. These will be featured in the next CARLA release.
-* __`dev` branch__ — Latest fixes and features still in development and testing. This branch will be merged with `master` when the time for a new release comes.
-* __`stable` branch__ — Latest version of CARLA tagged as stable. Previous CARLA versions also have their own branch.
+!!! Note
+ The `master` branch contains the current release of CARLA with the latest fixes and features. Previous CARLA versions are tagged with the version name. Always remember to check the current branch in git with the command `git branch`.
### Get assets
-Download the assets, as they are necessary to run CARLA. These are stored in a separated package to reduce the size of the build. A script downloads and extracts the latest stable assets automatically. The package is >3GB, so the download may take some time.
+You will need to download the __latest__ assets to work with the current version of CARLA. We provide a script to automate this process. To use the script, run the following command in the CARLA root folder:
-__1.__ Get into your root carla directory. The path should correspond with the repository just cloned.
```sh
-cd ~/carla
-```
-__2.__ Run the script to get the assets.
-```sh
-./Update.sh
+ ./Update.sh
```
+
+The assets will be downloaded and extracted to the appropriate location.
+
!!! Important
To download the assets currently in development, visit [Update CARLA](build_update.md#get-development-assets) and read __Get development assets__.
+To download the assets for a __specific version__ of CARLA:
-### Set the environment variable
-
-This is necessary for CARLA to find the Unreal Engine 4.24 installation folder.
+1. From the root CARLA directory, navigate to `\Util\ContentVersions.txt`. This document contains the links to the assets for all CARLA releases.
+2. Extract the assets in `Unreal\CarlaUE4\Content\Carla`. If the path doesn't exist, create it.
+3. Extract the file with a command similar to the following:
```sh
-export UE4_ROOT=~/UnrealEngine_4.24
+ tar -xvzf .tar.gz.tar -C C:\path\to\carla\Unreal\CarlaUE4\Content\Carla
```
-The variable should be added to `~/.bashrc` or `~/.profile` to be set persistently session-wide. Otherwise, it will only be accessible from the current shell. To do this, follow these steps.
+### Set Unreal Engine environment variable
+
+For CARLA to find the correct installation of Unreal Engine, we need to set the CARLA environment variable.
+
+To set the variable for this session only:
-__1.__ Open `~/.bashrc`.
```sh
-gedit ~/.bashrc
+ export UE4_ROOT=~/UnrealEngine_4.26
```
-__2.__ Write the environment variable in the `~/.bashrc` file: `export UE4_ROOT=~/UnrealEngine_4.24`
+To set the variable so it persists across sessions:
+__1.__ Open `~/.bashrc` or `./profile`.
+```sh
+ gedit ~/.bashrc
+
+ # or
+
+ gedit ~/.profile
+```
+
+__2.__ Add the following line to the bottom of the file:
+
+```sh
+ export UE4_ROOT=~/UnrealEngine_4.26
+```
__3.__ Save the file and reset the terminal.
+### Build CARLA
+This section outlines the commands to build CARLA. __All commands should be run in the root CARLA folder.__
-### 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.
+There are two parts to the build process for CARLA, compiling the client and compiling the server.
!!! Warning
Make sure to run `make PythonAPI` to prepare the client and `make launch` for the server.
Alternatively `make LibCarla` will prepare the CARLA library to be imported anywhere.
-* __make PythonAPI__ compiles the API client, necessary to grant control over the simulation. It is only needed the first time. Remember to run it again when updating CARLA. Scripts will be able to run after this command is executed.
-```sh
-make PythonAPI
-```
+__1.__ __Compile the Python API client__:
-* __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
-make launch
-```
-The project may ask to build other instances such as `UE4Editor-Carla.dll` the first time. Agree in order to open the project. During the first launch, the editor may show warnings regarding shaders and mesh distance fields. These take some time to be loaded and the city will not show properly until then.
+The Python API client grants control over the simulation. Compilation of the Python API client is required the first time you build CARLA and again after you perform any updates. After the client is compiled, you will be able to run scripts to interact with the simulation.
-
-Finally, let's test the simulator. Inside `PythonAPI/examples` and `PythonAPI/util` there are some example scripts that may be especially useful for starters. The following commands will spawn some life into the town, and create a weather cycle. Each script should be run in one terminal
+The following command compiles the Python API client:
```sh
-# Support for Python2 was provided until 0.9.10 (not included)
-# Terminal A
-cd PythonAPI/examples
-python3 spawn_npc.py
-# Terminal B
-cd PythonAPI/examples
-python3 dynamic_weather.py
+ make PythonAPI
```
+
+Optionally, to compile the PythonAPI for a specific version of Python, run the below command in the root CARLA directory.
+
+```sh
+ # Delete versions as required
+ make PythonAPI ARGS="--python-version=2.7, 3.6, 3.7, 3.8"
+```
+
+The CARLA client library will be built in two distinct, mutually exclusive forms. This gives users the freedom to choose which form they prefer to run the CARLA client code. The two forms include `.egg` files and `.whl` files. Choose __one__ of the following options below to use the client library:
+
+__A. `.egg` file__
+
+>The `.egg` file does not need to be installed. All of CARLA's example scripts automatically [look for this file](build_system.md#versions-prior-to-0912) when importing CARLA.
+
+>If you previously installed a CARLA `.whl`, the `.whl` will take precedence over an `.egg` file.
+
+__B. `.whl` file__
+
+>The `.whl` file should be installed using `pip` or `pip3`:
+
+```sh
+# Python 3
+pip3 install .whl
+
+# Python 2
+pip install .whl
+```
+
+>This `.whl` file cannot be distributed as it is built specifically for your OS.
+
+!!! Warning
+ Issues can arise through the use of different methods to install the CARLA client library and having different versions of CARLA on your system. It is recommended to use virtual environments when installing the `.whl` and to [uninstall](build_faq.md#how-do-i-uninstall-the-carla-client-library) any previously installed client libraries before installing new ones.
+
+
+__2.__ __Compile the server__:
+
+The following command compiles and launches Unreal Engine. Run this command each time you want to launch the server or use the Unreal Engine editor:
+
+```sh
+ make launch
+```
+
+The project may ask to build other instances such as `UE4Editor-Carla.dll` the first time. Agree in order to open the project. During the first launch, the editor may show warnings regarding shaders and mesh distance fields. These take some time to be loaded and the map will not show properly until then.
+
+
+__3.__ __Start the simulation__:
+
+Press **Play** to start the server simulation. The camera can be moved with `WASD` keys and rotated by clicking the scene while moving the mouse around.
+
+Test the simulator using the example scripts inside `PythonAPI\examples`. With the simulator running, open a new terminal for each script and run the following commands to spawn some life into the town and create a weather cycle:
+
+```sh
+ # Terminal A
+ cd PythonAPI/examples
+ python3 -m pip install -r requirements.txt
+ python3 generate_traffic.py
+
+ # Terminal B
+ cd PythonAPI/examples
+ python3 dynamic_weather.py
+```
+
!!! Important
- If the simulation is running at very low FPS rates, go to `Edit/Editor preferences/Performance` in the UE editor and disable __Use less CPU when in background__.
+ If the simulation is running at a very low FPS rate, go to `Edit -> Editor preferences -> Performance` in the Unreal Engine editor and disable `Use less CPU when in background`.
-Optionally, to compile the PythonAPI for Python2, run the following command in the root CARLA directory.
-```sh
-make PythonAPI ARGS="--python-version=2"
-```
-Now CARLA is ready to go. Here is a brief summary of the most useful `make` commands available.
+### Other make commands
+
+There are more `make` commands that you may find useful. Find them in the table below:
| Command | Description |
| ------- | ------- |
| `make help` | Prints all available commands. |
| `make launch` | Launches CARLA server in Editor window. |
| `make PythonAPI` | Builds the CARLA client. |
+| `make LibCarla` | Prepares the CARLA library to be imported anywhere. |
| `make package` | Builds CARLA and creates a packaged version for distribution. |
| `make clean` | Deletes all the binaries and temporals generated by the build system. |
| `make rebuild` | `make clean` and `make launch` both in one command. |
-
-
---
-Read the **[F.A.Q.](build_faq.md)** page or post in the [CARLA forum](https://forum.carla.org/c/installation-issues/linux) for any issues regarding this guide.
+Read the **[F.A.Q.](build_faq.md)** page or post in the [CARLA forum](https://github.com/carla-simulator/carla/discussions) for any issues regarding this guide.
-Some recommendations after finishing the build. Learn how to update the CARLA build or take your first steps in the simulation, and learn some core concepts.
+Up next, learn how to update the CARLA build or take your first steps in the simulation, and learn some core concepts.
diff --git a/Docs/build_system.md b/Docs/build_system.md
index 612cf4d69..af4e68a77 100644
--- a/Docs/build_system.md
+++ b/Docs/build_system.md
@@ -3,7 +3,9 @@
* [__Setup__](#setup)
* [__LibCarla__](#libcarla)
* [__CarlaUE4 and Carla plugin__](#carlaue4-and-carla-plugin)
-* [__PythonAPI__](#pythonapi)
+* [__PythonAPI__](#pythonapi)
+ - [Versions 0.9.12+](#versions-0912)
+ - [Versions prior to 0.9.12](#versions-prior-to-0912)
> _This document is a work in progress, only the Linux build system is taken into account here._
@@ -74,9 +76,36 @@ make launch
---
## PythonAPI
+### Versions 0.9.12+
Compiled using Python's `setuptools` ("setup.py"). Currently requires the following to be installed in the machine: Python, libpython-dev, and
-libboost-python-dev; both for Python 2.7 and 3.5.
+libboost-python-dev, pip>=20.3, wheel, and auditwheel.
+
+Command:
+
+```sh
+make PythonAPI
+```
+
+Creates two files that each contain the client library and correspond to the supported Python version on the system. One file is a `.whl` file and the other is an `.egg` file. This allows for the option of two different, mutually exclusive ways to use the client library.
+
+>__A. .whl file__
+
+>>The `.whl` is installed using the command:
+
+>> pip install .whl
+
+>>There is no need to import the library path directly in scripts as is required in previous versions or `.egg` files (see section [__Versions prior to 0.9.12__](#versions-prior-to-0912)); `import carla` is sufficient.
+
+>__B. .egg file__
+
+>>See the section [__Versions prior to 0.9.12__](#versions-prior-to-0912) for more information.
+
+
+### Versions prior to 0.9.12
+
+Compiled using Python's `setuptools` ("setup.py"). Currently requires the following to be installed in the machine: Python, libpython-dev, and
+libboost-python-dev.
Command
diff --git a/Docs/build_update.md b/Docs/build_update.md
index 01b367ae7..ff6f93c29 100644
--- a/Docs/build_update.md
+++ b/Docs/build_update.md
@@ -13,7 +13,7 @@ To post unexpected issues, doubts or suggestions, feel free to login in the CARL
diff --git a/Docs/build_windows.md b/Docs/build_windows.md
index c7d824484..94581ad5d 100644
--- a/Docs/build_windows.md
+++ b/Docs/build_windows.md
@@ -4,23 +4,22 @@ This guide details how to build CARLA from source on Windows. There are two part
The build process is long (4 hours or more) and involves several kinds of software. It is highly recommended to read through the guide fully before starting.
-If you come across errors or difficulties then have a look at the **[F.A.Q.](build_faq.md)** page which offers solutions for the most common complications. Alternatively, use the [CARLA forum](https://forum.carla.org/c/installation-issues/linux) to post any queries you may have.
+If you come across errors or difficulties then have a look at the **[F.A.Q.](build_faq.md)** page which offers solutions for the most common complications. Alternatively, use the [CARLA forum](https://github.com/carla-simulator/carla/discussions) to post any queries you may have.
-- [Part One: Prerequisites](#part-one-prerequisites)
+- [__Part One: Prerequisites__](#part-one-prerequisites)
- [System requirements](#system-requirements)
- [Software requirements](#software-requirements)
- [Minor installations](#minor-installations)
- [Python dependencies](#python-dependencies)
- [Major installations](#major-installations)
- - [Visual Studio 2017](#visual-studio-2017)
+ - [Visual Studio 2019](#visual-studio-2019)
- [Unreal Engine](#unreal-engine)
-- [Part Two: Build CARLA](#part-two-build-carla)
+- [__Part Two: Build CARLA__](#part-two-build-carla)
- [Clone the CARLA repository](#clone-the-carla-repository)
- [Get assets](#get-assets)
- [Set Unreal Engine environment variable](#set-unreal-engine-environment-variable)
- [Build CARLA](#build-carla)
- [Other make commands](#other-make-commands)
-- [Summary](#summary)
---
@@ -31,7 +30,7 @@ In this section you will find details of system requirements, minor and major so
* __x64 system.__ The simulator should run in any 64 bits Windows system.
* __165 GB disk space.__ CARLA itself will take around 32 GB and the related major software installations (including Unreal Engine) will take around 133 GB.
-* __An adequate GPU.__ CARLA aims for realistic simulations, so the server needs at least a 6 GB GPU though we would recommend 8 GB. A dedicated GPU is highly recommended for machine learning.
+* __An adequate GPU.__ CARLA aims for realistic simulations, so the server needs at least a 6 GB GPU although 8 GB is recommended. A dedicated GPU is highly recommended for machine learning.
* __Two TCP ports and good internet connection.__ 2000 and 2001 by default. Make sure that these ports are not blocked by firewalls or any other applications.
### Software requirements
@@ -41,22 +40,38 @@ In this section you will find details of system requirements, minor and major so
* [__CMake__](https://cmake.org/download/) generates standard build files from simple configuration files.
* [__Git__](https://git-scm.com/downloads) is a version control system to manage CARLA repositories.
* [__Make__](http://gnuwin32.sourceforge.net/packages/make.htm) generates the executables. It is necessary to use __Make version 3.81__, otherwise the build may fail. If you have multiple versions of Make installed, check that you are using version 3.81 in your PATH when building CARLA. You can check your default version of Make by running `make --version`.
+* [__7Zip__](https://www.7-zip.org/) is a file compression software. This is required for automatic decompression of asset files and prevents errors during build time due to large files being extracted incorrectly or partially.
* [__Python3 x64__](https://www.python.org/downloads/) is the main scripting language in CARLA. Having a x32 version installed may cause conflict, so it is highly advisable to have it uninstalled.
!!! Important
Be sure that the above programs are added to the [environment path](https://www.java.com/en/download/help/path.xml). Remember that the path added should correspond to the progam's `bin` directory.
#### Python dependencies
-Run the following command to install the dependencies for the Python API client:
+Starting with CARLA 0.9.12, users have the option to install the CARLA Python API using `pip3`. Version 20.3 or higher is required. To check if you have a suitable version, run the following command:
- pip3 install --user setuptools
+```sh
+pip3 -V
+```
+
+If you need to upgrade:
+
+```sh
+pip3 install --upgrade pip
+```
+
+You must install the following Python dependencies:
+
+```sh
+pip3 install --user setuptools
+pip3 install --user wheel
+```
#### Major installations
-##### Visual Studio 2017
+##### Visual Studio 2019
-Get the 2017 version of Visual Studio from [here](https://developerinsider.co/download-visual-studio-2017-web-installer-iso-community-professional-enterprise/). Choose __Community__ for the free version. Use the _Visual Studio Installer_ to install three additional elements:
+Get the 2019 version of Visual Studio from [here](https://developerinsider.co/download-visual-studio-2019-web-installer-iso-community-professional-enterprise/). Choose __Community__ for the free version. Use the _Visual Studio Installer_ to install three additional elements:
-* __Windows 8.1 SDK.__ Select it in the _Installation details_ section on the right or go to the _Indivdual Components_ tab and look under the _SDKs, libraries, and frameworks_ heading.
+* __Windows 8.1 SDK.__ Select it in the _Installation details_ section on the right or go to the _Indivdual Components_ tab and look under the _SDKs, libraries, and frameworks_ heading.
* __x64 Visual C++ Toolset.__ In the _Workloads_ section, choose __Desktop development with C++__. This will enable a x64 command prompt that will be used for the build. Check that it has been installed correctly by pressing the `Windows` button and searching for `x64`. Be careful __not to open a `x86_x64` prompt__.
* __.NET framework 4.6.2__. In the _Workloads_ section, choose __.NET desktop development__ and then in the _Installation details_ panel on the right, select `.NET Framework 4.6.2 development tools`. This is required to build Unreal Engine.
@@ -65,44 +80,40 @@ Get the 2017 version of Visual Studio from [here](https://developerinsider.co/do
##### Unreal Engine
-From CARLA 0.9.11 onwards we have included fixes to Unreal Engine that require modification to the engine itself. This means that it is no longer possible to use the Unreal Engine version provided by Epic Games Launcher with CARLA and instead we need to build a modified version.
+Starting with version 0.9.12, CARLA uses a modified fork of Unreal Engine 4.26. This fork contains patches specific to CARLA.
-To build the modified version, follow the commands listed below to download the engine's code from source and apply the patches that we provide. Be aware that to download Unreal Engine's source code, __you need to have a GitHub account linked to Unreal Engine's account__. If you don't have this set up, please follow [this guide](https://www.unrealengine.com/en-US/ue4-on-github) before going any further.
+Be aware that to download this fork of Unreal Engine, __you need to have a GitHub account linked to Unreal Engine's account__. If you don't have this set up, please follow [this guide](https://www.unrealengine.com/en-US/ue4-on-github) before going any further.
To build the modified version of Unreal Engine:
-1. In a terminal, navigate to the location you want to save Unreal Engine and clone the 4.24 branch:
+__1.__ In a terminal, navigate to the location you want to save Unreal Engine and clone the _carla_ branch:
- git clone --depth=1 -b 4.24 https://github.com/EpicGames/UnrealEngine.git
+```sh
+ git clone --depth 1 -b carla https://github.com/CarlaUnreal/UnrealEngine.git .
+```
+!!! Note
+ Keep the Unreal Engine folder as close as `C:\\` as you can because if the path exceeds a certain length then `Setup.bat` will return errors in step 3.
- !!! Note
- Keep the Unreal Engine folder as close as `C:\\` as you can because if the path exceeds a certain length then `Setup.bat` will return errors in step 3.
+__2.__ Run the configuration scripts:
-2. Inside Unreal Engine's source folder, download the patch and apply it:
+```sh
+ Setup.bat
+ GenerateProjectFiles.bat
+```
- cd UnrealEngine
- powershell -Command "(New-Object System.Net.WebClient).DownloadFile('https://carla-releases.s3.eu-west-3.amazonaws.com/Backup/UE4_patch_wheels.patch', 'UE4_patch_wheels.patch')"
- git apply UE4_patch_wheels.patch
+__3.__ Compile the modified engine:
+>1. Open the `UE4.sln` file inside the source folder with Visual Studio 2019.
-3. Run the configuration scripts:
-
- Setup.bat
- GenerateProjectFiles.bat
-
-4. Compile the modified engine:
-
- 1. Open the `UE4.sln` file inside the source folder with Visual Studio 2017.
-
- 2. In the build bar ensure that you have selected 'Development Editor', 'Win64' and 'UnrealBuildTool' options. Check [this guide](https://docs.unrealengine.com/en-US/ProductionPipelines/DevelopmentSetup/BuildingUnrealEngine/index.html) if you need any help.
+>2. In the build bar ensure that you have selected 'Development Editor', 'Win64' and 'UnrealBuildTool' options. Check [this guide](https://docs.unrealengine.com/en-US/ProductionPipelines/DevelopmentSetup/BuildingUnrealEngine/index.html) if you need any help.
- 3. In the solution explorer, right-click `UE4` and select `Build`.
+>3. In the solution explorer, right-click `UE4` and select `Build`.
-5. Once the solution is compiled you can open the engine to check that everything was correct by launching the executable `Engine\Binaries\Win64\UE4Editor.exe`.
+__4.__ Once the solution is compiled you can open the engine to check that everything was installed correctly by launching the executable `Engine\Binaries\Win64\UE4Editor.exe`.
- !!! Note
- If the installation was successful, this should be recognised by Unreal Engine's version selector. You can check this by right-clicking on any `.uproject` file and selecting `Switch Unreal Engine version`. You should see a pop-up showing `Source Build at PATH` where PATH is the installation path that you have chosen. If you can not see this selector or the `Generate Visual Studio project files` when you right-click on `.uproject` files, something went wrong with the Unreal Engine installation and you will likely need to reinstall it correctly.
+!!! Note
+ If the installation was successful, this should be recognised by Unreal Engine's version selector. You can check this by right-clicking on any `.uproject` file and selecting `Switch Unreal Engine version`. You should see a pop-up showing `Source Build at PATH` where PATH is the installation path that you have chosen. If you can not see this selector or the `Generate Visual Studio project files` when you right-click on `.uproject` files, something went wrong with the Unreal Engine installation and you will likely need to reinstall it correctly.
!!! Important
A lot has happened so far. It is highly advisable to restart the computer before continuing.
@@ -119,23 +130,24 @@ To build the modified version of Unreal Engine:
-The button above will take you to the official repository of the project. Either download from there and extract it or clone it using the following command:
+The button above will take you to the official repository of the project. Either download from there and extract it locally or clone it using the following command:
-
- git clone https://github.com/carla-simulator/carla
+```sh
+ git clone https://github.com/carla-simulator/carla
+```
!!! Note
- The `master` branch contains the current release of CARLA with the latest fixes and features. Previous CARLA versions have their own branch. Always remember to check the current branch in git with the command `git branch`.
+ The `master` branch contains the current release of CARLA with the latest fixes and features. Previous CARLA versions are tagged with the version name. Always remember to check the current branch in git with the command `git branch`.
### Get assets
Download the __latest__ assets to work with the current version of CARLA by running the following command in the CARLA root folder:
-```shell
-Update.bat
+```sh
+ Update.bat
```
-The assets will be downloaded and extracted to the appropriate location.
+The assets will be downloaded and extracted to the appropriate location if have 7zip installed. If you do not have this software installed, you will need to manually extract the file contents to `Unreal\CarlaUE4\Content\Carla`.
To download the assets for a __specific version__ of CARLA:
@@ -143,7 +155,9 @@ To download the assets for a __specific version__ of CARLA:
2. Extract the assets in `Unreal\CarlaUE4\Content\Carla`. If the path doesn't exist, create it.
3. Extract the file with a command similar to the following:
- tar -xvzf .tar.gz.tar -C C:\path\to\carla\Unreal\CarlaUE4\Content\Carla
+```sh
+ tar -xvzf .tar.gz.tar -C C:\path\to\carla\Unreal\CarlaUE4\Content\Carla
+```
### Set Unreal Engine environment variable
@@ -154,7 +168,7 @@ To set the environment variable:
1. Open Windows Control Panel and go to `Advanced System Settings` or search for `Advanced System Settings` in the Windows search bar.
2. On the `Advanced` panel open `Environment Variables...`.
3. Click `New...` to create the variable.
-4. Name the variable `UE4_ROOT` and choose the path to the installation folder of the desired UE4 installation.
+4. Name the variable `UE4_ROOT` and choose the path to the installation folder of the desired Unreal Engine installation.
### Build CARLA
@@ -162,49 +176,67 @@ To set the environment variable:
This section outlines the commands to build CARLA.
- All commands should be run in the root CARLA folder.
-- Commands should be executed via the __x64 Native Tools Command Prompt for VS 2017__. Open this by clicking the `Windows` key and searching for `x64`.
+- Commands should be executed via the __x64 Native Tools Command Prompt for VS 2019__. Open this by clicking the `Windows` key and searching for `x64`.
There are two parts to the build process for CARLA, compiling the client and compiling the server.
-1. __Compile the Python API client__:
+__1.__ __Compile the Python API client__:
- The Python API client grants control over the simulation. Compilation of the Python API client is required the first time you build CARLA and again after you perform any updates. After the client is compiled, you will be able to run scripts to interact with the simulation.
+The Python API client grants control over the simulation. Compilation of the Python API client is required the first time you build CARLA and again after you perform any updates. After the client is compiled, you will be able to run scripts to interact with the simulation.
- The following command compiles the Python API client:
+The following command compiles the Python API client:
- make PythonAPI
+```sh
+ make PythonAPI
+```
- __Note that when the compilation is done, you may see a successful output in the terminal even if the compilation of the Python API client was unsuccessful.__ Check for any errors in the terminal output and check that a `.egg` file exists in `PythonAPI\carla\dist`. If you come across any errors, check the [F.A.Q.](build_faq.md) or post in the [CARLA forum](https://forum.carla.org/c/installation-issues/linux).
+The CARLA client library will be built in two distinct, mutually exclusive forms. This gives users the freedom to choose which form they prefer to run the CARLA client code. The two forms include `.egg` files and `.whl` files. Choose __one__ of the following options below to use the client library:
+__A. `.egg` file__
-2. __Compile the server__:
+>The `.egg` file does not need to be installed. All of CARLA's example scripts automatically [look for this file](build_system.md#versions-prior-to-0912) when importing CARLA.
- The following command compiles and launches Unreal Engine. Run this command each time you want to launch the server or use the Unreal Engine editor:
+>If you previously installed a CARLA `.whl`, the `.whl` will take precedence over an `.egg` file.
- make launch
+__B. `.whl` file__
- The project may ask to build other instances such as `UE4Editor-Carla.dll` the first time. Agree in order to open the project. During the first launch, the editor may show warnings regarding shaders and mesh distance fields. These take some time to be loaded and the map will not show properly until then.
+>The `.whl` file should be installed using `pip3`:
-3. __Start the simulation__:
+```sh
+pip3 install .whl
+```
- Press **Play** to start the server simulation. The camera can be moved with `WASD` keys and rotated by clicking the scene while moving the mouse around.
+>This `.whl` file cannot be distributed as it is built specifically for your OS.
- Test the simulator using the example scripts inside `PythonAPI\examples`. With the simulator running, open a new terminal for each script and run the following commands to spawn some life into the town and create a weather cycle:
+!!! Warning
+ Issues can arise through the use of different methods to install the CARLA client library and having different versions of CARLA on your system. It is recommended to use virtual environments when installing the `.whl` and to [uninstall](build_faq.md#how-do-i-uninstall-the-carla-client-library) any previously installed client libraries before installing new ones.
+__2.__ __Compile the server__:
+The following command compiles and launches Unreal Engine. Run this command each time you want to launch the server or use the Unreal Engine editor:
+```sh
+ make launch
+```
+
+The project may ask to build other instances such as `UE4Editor-Carla.dll` the first time. Agree in order to open the project. During the first launch, the editor may show warnings regarding shaders and mesh distance fields. These take some time to be loaded and the map will not show properly until then.
+
+__3.__ __Start the simulation__:
+
+Press **Play** to start the server simulation. The camera can be moved with `WASD` keys and rotated by clicking the scene while moving the mouse around.
+
+Test the simulator using the example scripts inside `PythonAPI\examples`. With the simulator running, open a new terminal for each script and run the following commands to spawn some life into the town and create a weather cycle:
+
+```sh
# Terminal A
cd PythonAPI\examples
- pip install -r requirements.txt
- python3 spawn_npc.py
+ pip3 install -r requirements.txt
+ python3 generate_traffic.py
# Terminal B
cd PythonAPI\examples
python3 dynamic_weather.py
-
-!!! Note
- If you encounter the error `ModuleNotFoundError: No module named 'carla'` while running a script, you may be running a different version of Python than the one used to install the client. Go to `PythonAPI\carla\dist` and check the version of Python used in the `.egg` file.
-
+```
!!! Important
If the simulation is running at a very low FPS rate, go to `Edit -> Editor preferences -> Performance` in the Unreal Engine editor and disable `Use less CPU when in background`.
@@ -223,51 +255,10 @@ There are more `make` commands that you may find useful. Find them in the table
| `make clean` | Deletes all the binaries and temporals generated by the build system. |
| `make rebuild` | `make clean` and `make launch` both in one command. |
+
---
-## Summary
-
-Below is a summary of the requirements and commands needed to build CARLA on Windows:
-
- # Make sure to meet the minimum requirements:
- #
- # x64 system
- # 165 GB disk space
- # 6 - 8 GB GPU
- # Two TCP ports and good internet connection
-
- # Necessary software:
- # CMake
- # Git
- # Make
- # Python3 x64
- # Modified Unreal Engine 4.24
- # Visual Studio 2017 with Windows 8.1 SDK, x64 Visual C++ Toolset and .NET framework 4.6.2
-
- # Set environment variables for the software
-
- # Clone the CARLA repository
- git clone https://github.com/carla-simulator/carla
-
- # Get assets
- # Set UE4_ROOT environment variable
-
- # make the CARLA client and the CARLA server
- # open the x64 Native Tools Command Prompt for VS 2017 to execute the following commands
- make PythonAPI
- make launch
-
- # Press play in the Editor to initialize the server
- # Run example scripts to test CARLA
- # Terminal A
- cd PythonAPI\examples
- pip install -r requirements.txt
- python3 spawn_npc.py
- # Terminal B
- cd PythonAPI\examples
- python3 dynamic_weather.py
-
-Read the **[F.A.Q.](build_faq.md)** page or post in the [CARLA forum](https://forum.carla.org/c/installation-issues/linux) for any issues regarding this guide.
+Read the **[F.A.Q.](build_faq.md)** page or post in the [CARLA forum](https://github.com/carla-simulator/carla/discussions) for any issues regarding this guide.
Now that you have built CARLA, learn how to update the CARLA build or take your first steps in the simulation, and learn some core concepts.
@@ -284,6 +275,3 @@ First steps
-
-
-
diff --git a/Docs/carsim_integration.md b/Docs/carsim_integration.md
deleted file mode 100644
index 0bdd0c998..000000000
--- a/Docs/carsim_integration.md
+++ /dev/null
@@ -1,129 +0,0 @@
-# CARSIM Integration (Beta)
-
-This integration allows CARLA to forward all vehicle controls to CarSim in order to make all
-the physics calculations of the vehicle and send back the new state of the vehicle to CARLA.
-
-* [__Requisites__](#requisites)
-* [__Setup Carsim__](#set-up-carsim)
- * [__SIM file__](#sim-file)
- * [__On Windows__](#on-windows)
- * [__On Ubuntu__](#on-ubuntu)
- * [__Vehicle Sizes__](#vehicle-sizes)
-* [__Run Simulation__](#run-simulation)
-
----
-## Requisites
-
-* [CarSim](https://www.carsim.com/products/carsim/index.php) software + licence
-* Unreal 4.24 plugin (version 2020.0): [Vehicle dynamics](https://www.unrealengine.com/marketplace/en-US/product/carsim-vehicle-dynamics)
-* CARLA compiled with flag **--carsim** (CARLA packages are CarSim ready)
-
-It is necessary to have a licence for CarSim software set up and running.
-
-For the communication with Unreal it is necessary to install the free plugin in UE called [**vehicle
-dynamics**](https://www.unrealengine.com/marketplace/en-US/product/carsim-vehicle-dynamics).
-* **For Ubuntu** only:
- 1) Download the plugin version 2020.0 from [here](https://www.carsim.com/users/unreal_plugin/unreal_plugin_2020_0.php)
- 2) After downloading the plugin replace the file **CarSim.Build.cs** with the one [here](https://carla-releases.s3.eu-west-3.amazonaws.com/Backup/CarSim.Build.cs). We added the proper solver to use.
-
-If you use CARLA from source, then you need to compile the server with the **--carsim** flag:
-```sh
-make CarlaUE4Editor ARGS="--carsim"
-```
-All packages are already compiled with the **--carsim** flag, so they are ready to use with CarSim.
-
-## Set Up CarSim
-#### SIM File
-
-You need to generate the .sim file that describes the simulation to run in both CARLA and
-CarSim. The CarSim plugin needs this file to know about the simulation to run.
-
-##### On Windows
-
-You can use the GUI to generate the file once you have all the parameters configured.
-
-![generate .sim file](img/carsim_generate.jpg)
-
-For Windows systems, a **.sim** file looks like this:
-
-```
-SIMFILE
-
-SET_MACRO $(ROOT_FILE_NAME)$ Run_dd7a828d-4b14-4c77-9d09-1974401d6b25
-SET_MACRO $(OUTPUT_PATH)$ D:\carsim\Data\Results
-SET_MACRO $(WORK_DIR)$ D:\carsim\Data\
-SET_MACRO $(OUTPUT_FILE_PREFIX)$ $(WORK_DIR)$Results\Run_dd7a828d-4b14-4c77-9d09-1974401d6b25\LastRun
-
-FILEBASE $(OUTPUT_FILE_PREFIX)$
-INPUT $(WORK_DIR)$Results\$(ROOT_FILE_NAME)$\Run_all.par
-INPUTARCHIVE $(OUTPUT_FILE_PREFIX)$_all.par
-ECHO $(OUTPUT_FILE_PREFIX)$_echo.par
-FINAL $(OUTPUT_FILE_PREFIX)$_end.par
-LOGFILE $(OUTPUT_FILE_PREFIX)$_log.txt
-ERDFILE $(OUTPUT_FILE_PREFIX)$.vs
-PROGDIR D:\carsim\
-DATADIR D:\carsim\Data\
-GUI_REFRESH_V CarSim_RefreshEvent_7760
-RESOURCEDIR D:\carsim\\Resources\
-PRODUCT_ID CarSim
-PRODUCT_VER 2020.0
-ANIFILE D:\carsim\Data\runs\animator.par
-VEHICLE_CODE i_i
-EXT_MODEL_STEP 0.00050000
-PORTS_IMP 0
-PORTS_EXP 0
-
-DLLFILE D:\carsim\Programs\solvers\carsim_64.dll
-END
-```
-##### On Ubuntu
-For Ubuntu there is no way to create these files via GUI. You need to generate them in Windows and
-move the related .par, .txt, .vs files to Ubuntu. You then need to modify the .sim file so that the
-variables `INPUT`, `INPUTARCHIVE`, `LOGFILE`, etc point towards the same files in your Ubuntu
-system. Finally, you need to replace the `DLLFILE` line to point towards the CarSim solver which
-in the default installation will be `SOFILE /opt/carsim_2020.0/lib64/libcarsim.so.2020.0`. Your .sim
-file should be similar to this:
-
-```
-SIMFILE
-
-FILEBASE /path/to/LastRun
-INPUT /path/to/Run_all.par
-INPUTARCHIVE /path/to/LastRun_all.par
-ECHO /path/to/LastRun_echo.par
-FINAL /path/to/LastRun_end.par
-LOGFILE /path/to/LastRun_log.txt
-ERDFILE /path/to/LastRun.vs
-PROGDIR /opt/carsim_2020.0/lib64/
-DATADIR .
-PRODUCT_ID CarSim
-PRODUCT_VER 2020.0
-VEHICLE_CODE i_i
-
-SOFILE /opt/carsim_2020.0/lib64/libcarsim.so.2020.0
-END
-```
-#### Vehicle Sizes
-
-Care needs to be taken regarding the sizes of vehicles. CarSim lets you specify the dimensions of
-the vehicle to use, but currently there is no correlation between a CarSim vehicle and a CARLA
-vehicle. That means that the vehicles in both parts have different dimensions, and the CARLA vehicle is only used as a placeholder in the simulation.
-
-![carsim vehicle sizes](img/carsim_vehicle_sizes.jpg)
-
-## Run Simulation
-
-You only need to spawn a CARLA vehicle and enable CarSim on it with the Python API function
-
-```sh
-vehicle.enable_carsim()
-```
-
-Now all input controls sent to the vehicle will be forwarded to CarSim, which will update the
-physics and send back the status of the vehicle (the transform) to the CARLA vehicle.
-
-Once the simulation has finished you can analyze all the data in CarSim as usual.
-
-![carsim analysis](img/carsim_analysis.jpg)
-
-
diff --git a/Docs/core_actors.md b/Docs/core_actors.md
index 51eea777a..377b8d7ac 100644
--- a/Docs/core_actors.md
+++ b/Docs/core_actors.md
@@ -1,28 +1,28 @@
# 2nd. Actors and blueprints
-Actors not only include vehicles and walkers, but also sensors, traffic signs, traffic lights, and the spectator. It is crucial to have fully understanding on how to operate on them.
+Actors not only include vehicles and walkers, but also sensors, traffic signs, traffic lights, and the spectator. It is crucial to have full understanding on how to operate on them.
-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/).
+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://github.com/carla-simulator/carla/discussions/).
-* [__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__](#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
-These layouts allow the user to smoothly incorporate new actors into the simulation. They are already-made models with animations and a series of attributes. Some of these are modifiable and others are not. These attributes include, among others, vehicle color, amount of channels in a lidar sensor, a walker's speed, and much more.
+These layouts allow the user to smoothly incorporate new actors into the simulation. They are already-made models with animations and a series of attributes. Some of these are modifiable and others are not. These attributes include, among others, vehicle color, amount of channels in a lidar sensor, a walker's speed, and much more.
-Available blueprints are listed in the [blueprint library](bp_library.md), along with their attributes.
+Available blueprints are listed in the [blueprint library](bp_library.md), along with their attributes. Vehicle and walker blueprints have a generation attribute that indicates if they are a new (gen 2) or old (gen 1) asset.
### Managing the blueprint library
@@ -212,37 +212,51 @@ if traffic_light.get_state() == carla.TrafficLightState.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.
+[__carla.Vehicle__](python_api.md#carla.Vehicle) is a special type of actor. It incorporates special internal components that simulate the physics of wheeled vehicles. This is achieved by applying four types of different controls:
* __[carla.VehicleControl](python_api.md#carla.VehicleControl)__ provides input for driving commands such as throttle, steering, brake, etc.
```py
-vehicle.apply_control(carla.VehicleControl(throttle=1.0, steer=-1.0))
+ vehicle.apply_control(carla.VehicleControl(throttle=1.0, steer=-1.0))
```
-* __[carla.VehiclePhysicsControl](python_api.md#carla.VehiclePhysicsControl)__ defines physical attributes of the vehicle. Besides many different attribute, this controller contains two more controllers. [carla.GearPhysicsControl](python_api.md#carla.GearPhysicsControl) for the gears. The other is a list of [carla.WheelPhysicsControl](python_api.md#carla.WheelPhysicsControl), that provide specific control over the different wheels.
+* __[carla.VehiclePhysicsControl](python_api.md#carla.VehiclePhysicsControl)__ defines physical attributes of the vehicle and contains two more controllers:
+
+ * [carla.GearPhysicsControl](python_api.md#carla.GearPhysicsControl) which controls the gears.
+ * [carla.WheelPhysicsControl](python_api.md#carla.WheelPhysicsControl) which provides specific control over each wheel.
```py
-vehicle.apply_physics_control(carla.VehiclePhysicsControl(max_rpm = 5000.0, center_of_mass = carla.Vector3D(0.0, 0.0, 0.0), torque_curve=[[0,400],[5000,400]]))
+ vehicle.apply_physics_control(carla.VehiclePhysicsControl(max_rpm = 5000.0, center_of_mass = carla.Vector3D(0.0, 0.0, 0.0), torque_curve=[[0,400],[5000,400]]))
```
-In order to apply physics and detect collisions, vehicles have a [carla.BoundingBox](python_api.md#carla.BoundingBox) encapsulating them.
+Vehicles have a [carla.BoundingBox](python_api.md#carla.BoundingBox) encapsulating them. This bounding box allows physics to be applied to the vehicle and enables collisions to be detected.
```py
-box = vehicle.bounding_box
-print(box.location) # Location relative to the vehicle.
-print(box.extent) # XYZ half-box extents in meters.
+ box = vehicle.bounding_box
+ print(box.location) # Location relative to the vehicle.
+ print(box.extent) # XYZ half-box extents in meters.
```
-Vehicles include other functionalities unique to them.
-
-* The __autopilot mode__ will subscribe them to the [Traffic manager](adv_traffic_manager.md), and simulate real urban conditions. This module is hard-coded, not based on machine learning.
+The physics of vehicle wheels can be improved by enabling the [sweep wheel collision parameter][enable_sweep]. The default wheel physics uses single ray casting from the axis to the floor for each wheel but when sweep wheel collision is enabled, the full volume of the wheel is checked against collisions. It can be enabled as such:
```py
-vehicle.set_autopilot(True)
+ physics_control = vehicle.get_physics_control()
+ physics_control.use_sweep_wheel_collision = True
+ vehicle.apply_physics_control(physics_control)
```
-* __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.
+
+[enable_sweep]: https://carla.readthedocs.io/en/latest/python_api/#carla.VehiclePhysicsControl.use_sweep_wheel_collision
+
+
+Vehicles include other functionalities unique to them:
+
+* __Autopilot mode__ will subscribe a vehicle to the [Traffic Manager](adv_traffic_manager.md) to simulate real urban conditions. This module is hard-coded, not based on machine learning.
+
+```py
+ vehicle.set_autopilot(True)
+```
+* __Vehicle lights__ have to be turned on and off by the user. Each vehicle has a set of lights listed in [__carla.VehicleLightState__](python_api.md#carla.VehicleLightState). Not all vehicles have lights integrated. At the time of writing, vehicles with integrated lights are as follows:
+ * __Bikes:__ All bikes have a front and back position light.
+ * __Motorcycles:__ Yamaha and Harley Davidson models.
+ * __Cars:__ Audi TT, Chevrolet Impala, both Dodge police cars, Dodge Charger, Audi e-tron, Lincoln 2017 and 2020, Mustang, Tesla Model 3, Tesla Cybertruck, Volkswagen T2 and the Mercedes C-Class.
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.
@@ -293,7 +307,7 @@ Keep reading to learn more or visit the forum to post any doubts or suggestions
diff --git a/Docs/core_concepts.md b/Docs/core_concepts.md
index ce87df825..047588653 100644
--- a/Docs/core_concepts.md
+++ b/Docs/core_concepts.md
@@ -81,7 +81,7 @@ Keep reading to learn more. Visit the forum to post any doubts or suggestions th
diff --git a/Docs/core_map.md b/Docs/core_map.md
index 67b1d09a3..a7cf3edfc 100644
--- a/Docs/core_map.md
+++ b/Docs/core_map.md
@@ -2,72 +2,95 @@
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)
- * [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__](#the-map)
+ - [Changing the map](#changing-the-map)
+ - [Landmarks](#landmarks)
+ - [Lanes](#lanes)
+ - [Junctions](#junctions)
+ - [Waypoints](#waypoints)
+ - [Environment Objects](#environment-objects)
+- [__Navigation in CARLA__](#navigation-in-carla)
+ - [Navigating through waypoints](#navigating-through-waypoints)
+ - [Generating a map navigation](#generating-a-map-navigation)
+- [__CARLA maps__](#carla-maps)
+ - [Non-layered maps](#non-layered-maps)
+ - [Layered maps](#layered-maps)
---
## The map
-A map includes both the 3D model of a town and its road definition. Every map is based on an OpenDRIVE file describing the road layout fully annotated. The way the [OpenDRIVE standard 1.4](http://www.opendrive.org/docs/OpenDRIVEFormatSpecRev1.4H.pdf) defines roads, lanes, junctions, etc. is extremely important. It determines the possibilities of the API and the reasoning behind decisions made.
+A map includes both the 3D model of a town and its road definition. A map's road definition is based on an OpenDRIVE file, a standarized, annotated road definition format. The way the [OpenDRIVE standard 1.4](http://www.opendrive.org/docs/OpenDRIVEFormatSpecRev1.4H.pdf) defines roads, lanes, junctions, etc. determines the functionality of the Python API and the reasoning behind decisions made.
-The Python API makes for a high level querying system to navigate these roads. It is constantly evolving to provide a wider set of tools.
+The Python API acts as a high level querying system to navigate these roads. It is constantly evolving to provide a wider set of tools.
### Changing the map
-__To change the map, the world has to change too__. Everything will be rebooted and created from scratch, besides the Unreal Editor itself. There are two ways to do so.
+__To change the map, the world has to change too__. The simulation will be recreated from scratch. You can either restart with the same map in a new world or you can change both the map and the world:
-* `reload_world()` creates a new instance of the world with the same map.
-* `load_world()` changes the current map and creates a new world.
+- `reload_world()` creates a new instance of the world with the same map.
+- `load_world()` changes the current map and creates a new world.
```py
world = client.load_world('Town01')
```
-The client can get a list of available maps. Each map has a `name` attribute that matches the name of the currently loaded city, e.g. _Town01_.
+
+Each map has a `name` attribute that matches the name of the currently loaded city, e.g. _Town01_. To get a list of the available maps:
+
```py
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.
+Traffic signs defined in the OpenDRIVE file are translated to CARLA as landmark objects that can be queried from the API. The following methods and classes can be used to manipulate and work with landmark objects:
-* __[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.
+- __[`carla.Landmark`](https://carla.readthedocs.io/en/latest/python_api/#carla.Landmark)__ objects represent OpenDRIVE signals. The attributes and methods of this class describe the landmark and its area of influence.
+ - [`carla.LandmarkOrientation`](https://carla.readthedocs.io/en/latest/python_api/#carla.LandmarkOrientation) states the orientation of the landmark with regard to the road's geometry definition.
+ - [`carla.LandmarkType`](https://carla.readthedocs.io/en/latest/python_api/#carla.LandmarkType) contains common landmark types to facilitate translation to OpenDRIVE types.
+- __[`carla.Waypoint`](https://carla.readthedocs.io/en/latest/python_api/#carla.Waypoint)__ can get landmarks located a certain distance ahead of it. The landmark type to get can be specified.
+- __[`carla.Map`](https://carla.readthedocs.io/en/latest/python_api/#carla.Map)__ retrieves sets of landmarks. It can return all landmarks in the map, or those which have a common ID, type or group.
+- __[`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 represent them in the simulation.
```py
my_waypoint.get_landmarks(200.0,True)
```
-### Lanes
+### Waypoints
-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.
+A [`carla.Waypoint`](python_api.md#carla.Waypoint) is a 3D-directed point in the CARLA world corresponding to an OpenDRIVE lane. Everything related to waypoints happens on the client-side; communication with the server is only needed once to get the [map object](python_api.md#carlamap) containing the waypoint information.
-The lane markings surrounding a lane can be accessed through [__carla.LaneMarking__](python_api.md#carla.LaneMarking). These are defined with a series of variables.
+Each waypoint contains a [`carla.Transform`](python_api.md#carla.Transform) which states its location on the map and the orientation of the lane containing it. The variables `road_id`,`section_id`,`lane_id` and `s` correspond to the OpenDRIVE road. The `id` of the waypoint is constructed from a hash combination of these four values.
-* [__carla.LaneMarkingType__](python_api.md#carla.LaneMarkingType) are enum values according to OpenDRIVE standards.
-* [__carla.LaneMarkingColor__](python_api.md#carla.LaneMarkingColor) are enum values to determine the color of the marking.
-* __width__ to state thickness of the marking.
-* [__carla.LaneChange__](python_api.md#carla.LaneChange) to state permissions to perform lane changes.
+!!! Note
+ Waypoints closer than __2cm within the same road__ share the same `id`.
-Waypoints use these to aknowledge traffic permissions.
+A waypoint holds information about the __lane__ containing it. This information includes the lane's left and right __lane markings__, a boolean to determine if it's inside a junction, the lane type, width, and lane changing permissions.
```py
-# Get the lane type where the waypoint is.
+# Access lane information from a waypoint
+inside_junction = waypoint.is_junction()
+width = waypoint.lane_width
+right_lm_color = waypoint.right_lane_marking.color
+```
+
+### 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.
+
+The lane markings surrounding a lane are accessed through [`carla.LaneMarking`](python_api.md#carla.LaneMarking). Lane markings are defined by a series of variables:
+
+- __color:__ [`carla.LaneMarkingColor`](python_api.md#carla.LaneMarkingColor) are enum values that define the marking's color.
+- __lane_change:__ [`carla.LaneChange`](python_api.md#carla.LaneChange) states if the lane permits turning left, right, both or none.
+- __type:__ [`carla.LaneMarkingType`](python_api.md#carla.LaneMarkingType) are enum values that define the type of marking according to the OpenDRIVE standard.
+- __width:__ defines the marking's thickness.
+
+The below example shows to get information about the lane type, lane markings, and lane change permissions at a specific waypoint:
+
+```py
+# Get the lane type of the waypoint
lane_type = waypoint.lane_type
-# Get the type of lane marking on the left.
+# Get the type of lane marking on the left.
left_lanemarking_type = waypoint.left_lane_marking.type()
# Get available lane changes for this waypoint.
@@ -76,98 +99,110 @@ lane_change = waypoint.lane_change
### Junctions
-A [carla.Junction](python_api.md#carla.Junction) represents an OpenDRIVE junction. This class provides for a bounding box to state whereas lanes or vehicles are inside of it.
+A [`carla.Junction`](python_api.md#carla.Junction) represents an OpenDRIVE junction. This class encompasses a junction with a bounding box to identify lanes or vehicles within it.
-The most remarkable method of this class returns a pair of waypoints per lane inside the junction. Each pair is located at the starting and ending point of the junction boundaries.
+The `carla.Junction` class contains the `get_waypoints` method which returns a pair of waypoints for every lane within the junction. Each pair is located at the start and end points of the junction boundaries.
```py
waypoints_junc = my_junction.get_waypoints()
```
-### Waypoints
+### Environment Objects
-A [__carla.Waypoint__](python_api.md#carla.Waypoint) is a 3D-directed point. These are prepared to mediate between the world and the openDRIVE definition of the road. Everything related with waypoints happens on the client-side, so there no communication with the server is needed.
+Every object on a CARLA map has a set of associated variables which can be found [here][env_obj]. Included in these variables is a [unique ID][env_obj_id] that can be used to [toggle][toggle_env_obj] that object's visibility on the map. You can use the Python API to [fetch][fetch_env_obj] the IDs of each environment object based on their [semantic tag][semantic_tag]:
-Each waypoint contains a [carla.Transform](python_api.md#carla.Transform). This states its location on the map and the orientation of the lane containing it. The variables `road_id`,`section_id`,`lane_id` and `s` translate this transform to the OpenDRIVE road. These combined, create the `id` of the waypoint.
+ # Get the buildings in the world
+ world = client.get_world()
+ env_objs = world.get_environment_objects(carla.CityObjectLabel.Buildings)
-!!! Note
- Due to granularity, waypoints closer than __2cm within the same road__ share the same `id`.
+ # Access individual building IDs and save in a set
+ building_01 = env_objs[0]
+ building_02 = env_objs[1]
+ objects_to_toggle = {building_01.id, building_02.id}
-A waypoint also contains some information regarding the __lane__ containing it. Specifically its left and right __lane markings__, and a boolean to determine if it is inside a junction.
+ # Toggle buildings off
+ world.enable_environment_objects(objects_to_toggle, False)
+ # Toggle buildings on
+ world.enable_environment_objects(objects_to_toggle, True)
+
+See an example of distinct objects being toggled:
+
+![toggle_objects_gif](img/objects_small.gif)
+
+[env_obj]: https://carla.readthedocs.io/en/latest/python_api/#carla.EnvironmentObject
+[env_obj_id]: https://carla.readthedocs.io/en/latest/python_api/#carla.EnvironmentObject.id
+[toggle_env_obj]: https://carla.readthedocs.io/en/latest/python_api/#carla.World.enable_environment_objects
+[fetch_env_obj]: https://carla.readthedocs.io/en/latest/python_api/#carla.World.get_environment_objects
+[semantic_tag]: https://carla.readthedocs.io/en/latest/python_api/#carla.CityObjectLabel
-```py
-# Examples of a waypoint accessing to lane information
-inside_junction = waypoint.is_junction()
-width = waypoint.lane_width
-right_lm_color = waypoint.right_lane_marking.color
-```
---
## Navigation in CARLA
-Navigation in CARLA is managed via the waypoint API. This consists of a summary of methods in [carla.Waypoint](python_api.md#carla.Waypoint) and [carla.Map](python_api.md#carla.Map).
-
-All the queries happen on the client-side. The client only communicates with the server when retrieving the map object that will be used for the queries. There is no need to retrieve the map (`world.get_map()`) more than once.
+Navigation in CARLA is managed via the Waypoint API, a combination of methods from [`carla.Waypoint`](python_api.md#carla.Waypoint) and [`carla.Map`](python_api.md#carla.Map).
+The client must initially communicate with the server to retrieve the map object containing the waypoint information. This is only required once, all subsequent queries are performed on the client side.
### Navigating through waypoints
-Waypoints have a set of methods to connect with others and create a road flow. All of these methods follow traffic rules to determine only places where the vehicle can go.
+The Waypoint API exposes methods that allow waypoints to connect to each other and construct a path along a road for vehicles to navigate:
+
+- `next(d)` creates a list of waypoints within an approximate distance, `d`, __in the direction of the lane__. The list contains one waypoint for each possible deviation.
+- `previous(d)` creates a list of waypoints waypoint within an approximate distance, `d`, __in the opposite direction of the lane__. The list contains one waypoint for each possible deviation.
+- `next_until_lane_end(d)` and `previous_until_lane_start(d)` return a list of waypoints a distance `d` apart. The lists go from the current waypoint to the end and beginning of its lane, respectively.
+- `get_right_lane()` and `get_left_lane()` return the equivalent waypoint in an adjacent lane, if one exists. A lane change maneuver can be made by finding the next waypoint to the one on its right/left lane, and moving to it.
-* `next(d)` creates a list of waypoints at an approximate distance `d` __in the direction of the lane__. The list contains one waypoint for each deviation possible.
-* `previous(d)` creates a list of waypoints waypoint at an approximate distance `d` __on the opposite direction of the lane__. The list contains one waypoint for each deviation possible.
-* `next_until_lane_end(d)` and `previous_until_lane_start(d)` returns a list of waypoints a distance `d` apart. The list goes from the current waypoint to the end and start of its lane, respectively.
-* `get_right_lane()` and `get_left_lane()` return the equivalent waypoint in an adjacent lane, if any. A lane change maneuver can be made by finding the next waypoint to the one on its right/left lane, and moving to it.
```py
-# Disable physics, in this example the vehicle is teleported.
-vehicle.set_simulate_physics(False)
-while True:
- # Find next waypoint 2 meters ahead.
- waypoint = random.choice(waypoint.next(2.0))
- # Teleport the vehicle.
- vehicle.set_transform(waypoint.transform)
-```
+# Find next waypoint 2 meters ahead.
+waypoint = waypoint.next(2.0)
+```
-### Generating a map navigation
+### Generating map navigation
-The instance of the map is provided by the world. It will be useful to create routes and make vehicles roam around the city and reach goal destinations.
+The client needs to make a request to the server to get the `.xodr` map file and parse it to a [`carla.Map`](python_api.md#carla.Map) object. This only needs to be done once.
-The following method asks the server for the XODR map file, and parses it to a [carla.Map](python_api.md#carla.Map) object. It only needs to be calle once. Maps can be quite heavy, and successive calls are unnecessary and expensive.
+To get the map object:
```py
map = world.get_map()
```
-* __Get recommended spawn points for vehicles__ pointed by developers. There is no ensurance that these spots will be free.
+The map object contains __recommended spawn points__ for the creation of vehicles. You can get a list of these spawn points, each one containing a [`carla.Transform`](python_api.md#carlatransform), using the method below. Bear in mind that the spawn points may be occupied already, resulting in failed creation of vehicles due to collisions.
+
```py
spawn_points = world.get_map().get_spawn_points()
```
-* __Get the closest waypoint__ to a specific location or to a certain `road_id`, `lane_id` and `s` in OpenDRIVE.
+You can get started with waypoints by __[getting](python_api.md#carla.Map.get_waypoint) the closest waypoint__ to a specific location or to a particular `road_id`, `lane_id` and `s` value in the map's OpenDRIVE definition:
+
```py
-# Nearest waypoint on the center of a Driving or Sidewalk lane.
+# Nearest waypoint in the center of a Driving or Sidewalk lane.
waypoint01 = map.get_waypoint(vehicle.get_location(),project_to_road=True, lane_type=(carla.LaneType.Driving | carla.LaneType.Sidewalk))
#Nearest waypoint but specifying OpenDRIVE parameters.
waypoint02 = map.get_waypoint_xodr(road_id,lane_id,s)
```
-* __Generate a collection of waypoints__ to visualize the city lanes. Creates waypoints all over the map, for every road and lane. All of them will be an approximate distance apart.
+The below example shows how to __generate a collection of waypoints__ to visualize the city lanes. This will create waypoints all over the map, for every road and lane. All of them will approximately 2 meters apart:
+
```py
waypoint_list = map.generate_waypoints(2.0)
```
-* __Generate road topology__. Returns a list of pairs (tuples) of waypoints. For each pair, the first element connects with the second one and both define the starting and ending point of each lane in the map.
+To __generate a minimal graph of road topology__, use the example below. This will return a list of pairs (tuples) of waypoints. The first element in each pair connects with the second element and both define the start and end points of each lane in the map. More information on this method is found in the [PythonAPI](python_api.md#carla.Map.get_topology).
+
```py
waypoint_tuple_list = map.get_topology()
```
-* __Convert simulation point to geographical coordinates.__ Transforms a certain location to a [carla.GeoLocation](python_api.md#carla.GeoLocation) with latitude and longitude values.
+The example below __converts a `carla.Transform` to geographical latitude and longitude coordinates,__ in the form of a [`carla.GeoLocation`](python_api.md#carla.GeoLocation):
+
```py
my_geolocation = map.transform_to_geolocation(vehicle.transform)
```
-* __Save road information.__ Converts the road information to OpenDRIVE format, and saves it to disk.
+Use the following example to __save road information__ in OpenDRIVE format to disk:
+
```py
info_map = map.to_opendrive()
```
@@ -175,51 +210,60 @@ info_map = map.to_opendrive()
---
## CARLA maps
-So far there are seven different maps available. Each one has unique features and is useful for different purposes. Hereunder is a brief sum up on them.
+There are eight towns in the CARLA ecosystem and each of those towns have two kinds of map, non-layered and layered. [Layers][layer_api] refer to the grouped objects within a map and consist of the following:
+
+- NONE
+- Buildings
+- Decals
+- Foliage
+- Ground
+- ParkedVehicles
+- Particles
+- Props
+- StreetLights
+- Walls
+- All
+
+[layer_api]: https://carla.readthedocs.io/en/latest/python_api/#carlamaplayer
+
+### Non-layered maps
+
+Non-layered maps are shown in the table below (click the town name to see an overhead image of the layout). All of the layers are present at all times and cannot be toggled on or off in these maps. Up until CARLA 0.9.11, these were the only kinds of map available.
!!! Note
- Users can [customize a map](tuto_A_map_customization.md) or even [create a new map](tuto_A_add_map.md) to be used in CARLA.
+ Users can [customize a map](tuto_A_map_customization.md) or even [create a new map](tuto_M_custom_map_overview.md) to be used in CARLA.
-| Town | Summary |
-| -------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
-| **Town01** | A basic town layout with all "T junctions". |
-| **Town02** | Similar to **Town01**, but smaller. |
-| **Town03** | The most complex town, with a 5-lane junction, a roundabout, unevenness, a tunnel, and much more. Essentially a medley. |
-| **Town04** | An infinite loop with a highway and a small town. |
-| **Town05** | Squared-grid town with cross junctions and a bridge. It has multiple lanes per direction. Useful to perform lane changes. |
-| **Town06** | Long highways with many highway entrances and exits. It also has a [**Michigan left**](). |
-| **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. |
+| Town | Summary |
+| -----------| ------ |
+| **[Town01](img/Town01.jpg)** | A basic town layout consisting of "T junctions".|
+| **[Town02](img/Town02.jpg)** | Similar to **Town01**, but smaller.|
+| **[Town03](img/Town03.jpg)** | The most complex town, with a 5-lane junction, a roundabout, unevenness, a tunnel, and more.|
+| **[Town04](img/Town04.jpg)** | An infinite loop with a highway and a small town.|
+| **[Town05](img/Town05.jpg)** | Squared-grid town with cross junctions and a bridge. It has multiple lanes per direction. Useful to perform lane changes. |
+| **[Town06](img/Town06.jpg)** | Long highways with many highway entrances and exits. It also has a [**Michigan left**](). |
+| **[Town07](img/Town07.jpg)** | A rural environment with narrow roads, barns and hardly any traffic lights. |
+| **[Town10](img/Town10.jpg)** | A city environment with different environments such as an avenue or promenade, and more realistic textures.|
-
+### Layered maps
+The layout of layered maps is the same as non-layered maps but it is possible to toggle off and on the layers of the map. There is a minimum layout that cannot be toggled off and consists of roads, sidewalks, traffic lights and traffic signs. Layered maps can be identified by the suffix `_Opt`, for example, `Town01_Opt`. With these maps it is possible to [load][load_layer] and [unload][unload_layer] layers via the Python API:
-![Town01](img/Town01.jpg)
-*Above: Town01*
+ # Load layered map for Town 01 with minimum layout plus buildings and parked vehicles
+ world = client.load_world('Town01_Opt', carla.MapLayer.Buildings | carla.MapLayer.ParkedVehicles)
-![Town02](img/Town02.jpg)
-*Above: Town02*
+ # Toggle all buildings off
+ world.unload_map_layer(carla.MapLayer.Buildings)
-![Town03](img/Town03.jpg)
-*Above: Town03*
+ # Toggle all buildings on
+ world.load_map_layer(carla.MapLayer.Buildings)
-![Town04](img/Town04.jpg)
-*Above: Town04*
+[load_layer]: https://carla.readthedocs.io/en/latest/python_api/#carla.World.load_map_layer
+[unload_layer]: https://carla.readthedocs.io/en/latest/python_api/#carla.World.unload_map_layer
-![Town05](img/Town05.jpg)
-*Above: Town05*
+See an example of all layers being loaded and unloaded in sequence:
-![Town06](img/Town06.jpg)
-*Above: Town06*
+![map-layers](img/sublevels.gif)
-![Town07](img/Town07.jpg)
-*Above: Town07*
-
-![Town10](img/Town10.jpg)
-*Above: Town10*
-
-
-
---
That is a wrap as regarding maps and navigation in CARLA. The next step takes a closer look into sensors types, and the data they retrieve.
@@ -228,7 +272,7 @@ Keep reading to learn more or visit the forum to post any doubts or suggestions
diff --git a/Docs/core_sensors.md b/Docs/core_sensors.md
index b739f1f40..ae1e79b2d 100644
--- a/Docs/core_sensors.md
+++ b/Docs/core_sensors.md
@@ -102,16 +102,18 @@ Sensor data differs a lot between sensor types. Take a look at the [sensors refe
### Cameras
-Take a shot of the world from their point of view. The helper class [carla.ColorConverter](python_api.md#carla.ColorConverter) will modify said image to represent different information.
+Take a shot of the world from their point of view. For cameras that return [carla.Image](<../python_api#carlaimage>), you can use the helper class [carla.ColorConverter](python_api.md#carla.ColorConverter) to modify the image to represent different information.
* __Retrieve data__ every simulation step.
-| Sensor | Output | Overview |
-| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Depth | [carla.Image](<../python_api#carlaimage>) | Renders the depth of the elements in the field of view in a gray-scale map. |
-| RGB | [carla.Image](<../python_api#carlaimage>) | Provides clear vision of the surroundings. Looks like a normal photo of the scene. |
-| Semantic segmentation | [carla.Image](<../python_api#carlaimage>) | Renders elements in the field of view with a specific color according to their tags. |
+|Sensor |Output | Overview |
+| ----------------- | ---------- | ------------------ |
+| Depth | [carla.Image](<../python_api#carlaimage>) |Renders the depth of the elements in the field of view in a gray-scale map. |
+| RGB | [carla.Image](<../python_api#carlaimage>) | Provides clear vision of the surroundings. Looks like a normal photo of the scene. |
+| Optical Flow | [carla.Image](<../python_api#carlaimage>) | Renders the motion of every pixel from the camera. |
+| Semantic segmentation | [carla.Image](<../python_api#carlaimage>) | Renders elements in the field of view with a specific color according to their tags. |
+| DVS | [carla.DVSEventArray](<../python_api#carladvseventarray>) | Measures changes of brightness intensity asynchronously as an event stream. |
@@ -184,7 +186,7 @@ Python API reference
diff --git a/Docs/core_world.md b/Docs/core_world.md
index 79d54045c..586638e11 100644
--- a/Docs/core_world.md
+++ b/Docs/core_world.md
@@ -2,7 +2,7 @@
The client and the world are two of the fundamentals of CARLA, a necessary abstraction to operate the simulation and its actors.
-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.
+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://github.com/carla-simulator/carla/discussions/) is there to solve them.
* [__The client__](#the-client)
* [Client creation](#client-creation)
@@ -264,7 +264,7 @@ Keep reading to learn more. Visit the forum to post any doubts or suggestions th
diff --git a/Docs/download.md b/Docs/download.md
index e6f33e586..b011270e3 100644
--- a/Docs/download.md
+++ b/Docs/download.md
@@ -1,51 +1,52 @@
# Download
+### Latest Release
+
+- [CARLA 0.9.12](https://github.com/carla-simulator/carla/releases/tag/0.9.12/) - [Documentation](https://carla.readthedocs.io/en/0.9.12/)
+
### Nightly build
-> This is an automated build with the latest changes pushed to our "master"
-> branch. It contains the very last fixes and features that will be part of the
+> This is an automated build with the latest changes pushed to our `dev`
+> branch. It contains the very latest fixes and features that will be part of the
> next release, but also some experimental changes. Use at your own risk!
- [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/)]
+### Versions 0.9.x
-> These are the version of CARLA, more frequently updated and with the latest
-> features. Keep in mind that the API and features in this channel can (and
-> probably will) change.
+> Here are the previous versions of CARLA with links to the specific documentation for each version:
-- [CARLA 0.9.10](https://github.com/carla-simulator/carla/releases/tag/0.9.10)
-- [CARLA 0.9.9](https://github.com/carla-simulator/carla/releases/tag/0.9.9)
-- [CARLA 0.9.8](https://github.com/carla-simulator/carla/releases/tag/0.9.8)
-- [CARLA 0.9.7](https://github.com/carla-simulator/carla/releases/tag/0.9.7)
-- [CARLA 0.9.6](https://github.com/carla-simulator/carla/releases/tag/0.9.6)
-- [CARLA 0.9.5](https://github.com/carla-simulator/carla/releases/tag/0.9.5)
-- [CARLA 0.9.4](https://github.com/carla-simulator/carla/releases/tag/0.9.4)
-- [CARLA 0.9.3](https://github.com/carla-simulator/carla/releases/tag/0.9.3)
-- [CARLA 0.9.2](https://github.com/carla-simulator/carla/releases/tag/0.9.2)
-- [CARLA 0.9.1](https://github.com/carla-simulator/carla/releases/tag/0.9.1)
-- [CARLA 0.9.0](https://github.com/carla-simulator/carla/releases/tag/0.9.0)
-- [CARLA 0.8.4](https://github.com/carla-simulator/carla/releases/tag/0.8.4)
-- [CARLA 0.8.3](https://github.com/carla-simulator/carla/releases/tag/0.8.3)
+- [CARLA 0.9.11](https://github.com/carla-simulator/carla/releases/tag/0.9.11/) - [Documentation](https://carla.readthedocs.io/en/0.9.11/)
+- [CARLA 0.9.10](https://github.com/carla-simulator/carla/releases/tag/0.9.10/) - [Documentation](https://carla.readthedocs.io/en/0.9.10/)
+- [CARLA 0.9.9](https://github.com/carla-simulator/carla/releases/tag/0.9.9/) - [Documentation](https://carla.readthedocs.io/en/0.9.9/)
+- [CARLA 0.9.8](https://github.com/carla-simulator/carla/releases/tag/0.9.8/) - [Documentation](https://carla.readthedocs.io/en/0.9.8/)
+- [CARLA 0.9.7](https://github.com/carla-simulator/carla/releases/tag/0.9.7/) - [Documentation](https://carla.readthedocs.io/en/0.9.7/)
+- [CARLA 0.9.6](https://github.com/carla-simulator/carla/releases/tag/0.9.6/) - [Documentation](https://carla.readthedocs.io/en/0.9.6/)
+- [CARLA 0.9.5](https://github.com/carla-simulator/carla/releases/tag/0.9.5/) - [Documentation](https://carla.readthedocs.io/en/0.9.5/)
+- [CARLA 0.9.4](https://github.com/carla-simulator/carla/releases/tag/0.9.4/) - [Documentation](https://carla.readthedocs.io/en/0.9.4/)
+- [CARLA 0.9.3](https://github.com/carla-simulator/carla/releases/tag/0.9.3/) - [Documentation](https://carla.readthedocs.io/en/0.9.3/)
+- [CARLA 0.9.2](https://github.com/carla-simulator/carla/releases/tag/0.9.2/) - [Documentation](https://carla.readthedocs.io/en/0.9.2/)
+- [CARLA 0.9.1](https://github.com/carla-simulator/carla/releases/tag/0.9.1/) - [Documentation](https://carla.readthedocs.io/en/0.9.1/)
+- [CARLA 0.9.0](https://github.com/carla-simulator/carla/releases/tag/0.9.0/) - [Documentation](https://carla.readthedocs.io/en/0.9.0/)
-### Stable [[Documentation](https://carla.readthedocs.io/en/stable/)]
+### Versions 0.8.x
-> The most tested and robust release out there!
-
-- [CARLA 0.8.2](https://github.com/carla-simulator/carla/releases/tag/0.8.2)
+- [CARLA 0.8.4](https://github.com/carla-simulator/carla/releases/tag/0.8.4/) - [Documentation](https://carla.readthedocs.io/en/0.8.4/)
+- [CARLA 0.8.3](https://github.com/carla-simulator/carla/releases/tag/0.8.3/)
+- [CARLA 0.8.2](https://github.com/carla-simulator/carla/releases/tag/0.8.2/) - [Documentation](https://carla.readthedocs.io/en/stable/)
- - -
### Docker
-All the versions are also available to pull from DockerHub
+All versions are available to pull from DockerHub:
```sh
docker pull carlasim/carla:X.X.X
```
-Use tag "latest" for the nightly build
+Use tag "latest" for the most recent release:
```sh
docker pull carlasim/carla:latest
diff --git a/Docs/ecosys_ansys.md b/Docs/ecosys_ansys.md
new file mode 100644
index 000000000..22f3a38e9
--- /dev/null
+++ b/Docs/ecosys_ansys.md
@@ -0,0 +1,8 @@
+# Ansys Real Time Radar Model: Training a Vehicle Longitudinal Controller Using Reinforcement Learning
+
+In a webinair series in April 2021, [Ansys](https://www.ansys.com/) presented the details of their integration of the Ansys Real Time Radar (RTR) with the CARLA simulator. Here you can download and view the presentation slides and videos that accompanied the webinair.
+
+The presentation details how the RTR was integrated with CARLA to train a vehicle longitudinal controller using reinforcement learning and includes the model, action space and reward policy used. The videos show the results of the training in the CARLA simulator.
+
+View the presentation [here](https://drive.google.com/file/d/1xtGaI8Ls6C8Jh-PQvKRrLKs6c3ri3WQ2/view) and the videos [here](https://drive.google.com/file/d/1whHE1MKhzQtW3jj4dJCW6A3mCjUnNaJI/view).
+
diff --git a/Docs/extra.css b/Docs/extra.css
index d64c890d3..e05b7f95b 100644
--- a/Docs/extra.css
+++ b/Docs/extra.css
@@ -12,6 +12,13 @@
text-align: center;
}
+/************************* NAV BAR **************************/
+
+.caption {
+ /* background-color: #d6d6d6;
+ color: #404040; */
+ text-decoration: underline;
+}
/************************* DEFAULT TABLES **************************/
@@ -244,3 +251,18 @@ table tbody td{
top: 70px;
left: 1100px;
}
+
+/************************* LATEST WARNING BANNER **************************/
+
+.dev-version-warning {
+ padding-top: 15px;
+ padding-bottom: 15px;
+ padding-left: 15px;
+ padding-right: 15px;
+ margin-bottom: 8px;
+ color: #404040;
+ font-weight: bold;
+ background-color: #f55c47;
+ text-align: center;
+ border-radius: 5px;
+}
diff --git a/Docs/extra.js b/Docs/extra.js
new file mode 100644
index 000000000..58e37b47e
--- /dev/null
+++ b/Docs/extra.js
@@ -0,0 +1,9 @@
+$(document).ready(function () {
+ if(window.location.href.indexOf("/latest/") != -1) {
+ var banner = document.createElement("div");
+ var section = document.getElementsByClassName("section");
+ banner.className = "dev-version-warning";
+ banner.innerHTML = "You are currently reading documentation for the \"dev\" branch of CARLA. This documentation refers to features currently in development and may result in unexpected behaviour. To read documentation for previous releases, select the desired version in the bottom, right-hand corner of the screen.";
+ section[0].insertBefore(banner,section[0].childNodes[0]);
+ }
+});
\ No newline at end of file
diff --git a/Docs/img/EmissiveIntensity.gif b/Docs/img/EmissiveIntensity.gif
new file mode 100644
index 000000000..66f07aeb7
Binary files /dev/null and b/Docs/img/EmissiveIntensity.gif differ
diff --git a/Docs/img/RecorderTrafficLight.jpg b/Docs/img/RecorderTrafficLight.jpg
deleted file mode 100644
index 70ce11827..000000000
Binary files a/Docs/img/RecorderTrafficLight.jpg and /dev/null differ
diff --git a/Docs/img/RecorderTrafficLight.png b/Docs/img/RecorderTrafficLight.png
new file mode 100644
index 000000000..96053d5e3
Binary files /dev/null and b/Docs/img/RecorderTrafficLight.png differ
diff --git a/Docs/img/base_mesh.png b/Docs/img/base_mesh.png
new file mode 100644
index 000000000..d601bd0c9
Binary files /dev/null and b/Docs/img/base_mesh.png differ
diff --git a/Docs/img/building_diffuse_alpha.png b/Docs/img/building_diffuse_alpha.png
new file mode 100644
index 000000000..ab740227e
Binary files /dev/null and b/Docs/img/building_diffuse_alpha.png differ
diff --git a/Docs/img/building_material.png b/Docs/img/building_material.png
new file mode 100644
index 000000000..bddb7fdc3
Binary files /dev/null and b/Docs/img/building_material.png differ
diff --git a/Docs/img/choose_material.png b/Docs/img/choose_material.png
new file mode 100644
index 000000000..1913b1067
Binary files /dev/null and b/Docs/img/choose_material.png differ
diff --git a/Docs/img/collision_mesh.png b/Docs/img/collision_mesh.png
new file mode 100644
index 000000000..f64edb84c
Binary files /dev/null and b/Docs/img/collision_mesh.png differ
diff --git a/Docs/img/collision_mesh_vehicle.png b/Docs/img/collision_mesh_vehicle.png
new file mode 100644
index 000000000..3d0089a5b
Binary files /dev/null and b/Docs/img/collision_mesh_vehicle.png differ
diff --git a/Docs/img/copy_wheel_blueprint.png b/Docs/img/copy_wheel_blueprint.png
new file mode 100644
index 000000000..85411841c
Binary files /dev/null and b/Docs/img/copy_wheel_blueprint.png differ
diff --git a/Docs/img/decals_meshes.png b/Docs/img/decals_meshes.png
new file mode 100644
index 000000000..5e1fc586c
Binary files /dev/null and b/Docs/img/decals_meshes.png differ
diff --git a/Docs/img/disable_rendering.png b/Docs/img/disable_rendering.png
new file mode 100644
index 000000000..c914f7df0
Binary files /dev/null and b/Docs/img/disable_rendering.png differ
diff --git a/Docs/img/large_map_export_fbx.png b/Docs/img/large_map_export_fbx.png
new file mode 100644
index 000000000..f67f3f73e
Binary files /dev/null and b/Docs/img/large_map_export_fbx.png differ
diff --git a/Docs/img/levels.png b/Docs/img/levels.png
new file mode 100644
index 000000000..3ef13a5b6
Binary files /dev/null and b/Docs/img/levels.png differ
diff --git a/Docs/img/map_size.png b/Docs/img/map_size.png
new file mode 100644
index 000000000..091da83bb
Binary files /dev/null and b/Docs/img/map_size.png differ
diff --git a/Docs/img/map_size_sync.png b/Docs/img/map_size_sync.png
new file mode 100644
index 000000000..f9a2a3be5
Binary files /dev/null and b/Docs/img/map_size_sync.png differ
diff --git a/Docs/img/map_tiles.png b/Docs/img/map_tiles.png
new file mode 100644
index 000000000..5f3aa88d9
Binary files /dev/null and b/Docs/img/map_tiles.png differ
diff --git a/Docs/img/master_material.png b/Docs/img/master_material.png
new file mode 100644
index 000000000..d0930a23d
Binary files /dev/null and b/Docs/img/master_material.png differ
diff --git a/Docs/img/move_assets.png b/Docs/img/move_assets.png
new file mode 100644
index 000000000..9f36880c4
Binary files /dev/null and b/Docs/img/move_assets.png differ
diff --git a/Docs/img/new_level.png b/Docs/img/new_level.png
new file mode 100644
index 000000000..26d5f2825
Binary files /dev/null and b/Docs/img/new_level.png differ
diff --git a/Docs/img/objects_small.gif b/Docs/img/objects_small.gif
new file mode 100644
index 000000000..164792054
Binary files /dev/null and b/Docs/img/objects_small.gif differ
diff --git a/Docs/img/optical_flow.png b/Docs/img/optical_flow.png
new file mode 100644
index 000000000..03dae41be
Binary files /dev/null and b/Docs/img/optical_flow.png differ
diff --git a/Docs/img/physical_asset_mesh.png b/Docs/img/physical_asset_mesh.png
new file mode 100644
index 000000000..97f85b3b7
Binary files /dev/null and b/Docs/img/physical_asset_mesh.png differ
diff --git a/Docs/img/physics_convergence_fixed_dt.png b/Docs/img/physics_convergence_fixed_dt.png
new file mode 100644
index 000000000..273389d90
Binary files /dev/null and b/Docs/img/physics_convergence_fixed_dt.png differ
diff --git a/Docs/img/physics_convergence_fixed_pdt.png b/Docs/img/physics_convergence_fixed_pdt.png
new file mode 100644
index 000000000..938f23b92
Binary files /dev/null and b/Docs/img/physics_convergence_fixed_pdt.png differ
diff --git a/Docs/img/physics_convergence_z_acceleration.png b/Docs/img/physics_convergence_z_acceleration.png
new file mode 100644
index 000000000..78970645f
Binary files /dev/null and b/Docs/img/physics_convergence_z_acceleration.png differ
diff --git a/Docs/img/roadrunner_export.png b/Docs/img/roadrunner_export.png
new file mode 100644
index 000000000..6d85e5c49
Binary files /dev/null and b/Docs/img/roadrunner_export.png differ
diff --git a/Docs/img/rr_world_settings.png b/Docs/img/rr_world_settings.png
new file mode 100644
index 000000000..f57a414e7
Binary files /dev/null and b/Docs/img/rr_world_settings.png differ
diff --git a/Docs/img/sublevels.gif b/Docs/img/sublevels.gif
new file mode 100644
index 000000000..c81cab7bc
Binary files /dev/null and b/Docs/img/sublevels.gif differ
diff --git a/Docs/img/ue_duplicate_basemap.png b/Docs/img/ue_duplicate_basemap.png
new file mode 100644
index 000000000..6663c78cc
Binary files /dev/null and b/Docs/img/ue_duplicate_basemap.png differ
diff --git a/Docs/img/ue_generate_routes.png b/Docs/img/ue_generate_routes.png
new file mode 100644
index 000000000..ae1ac009c
Binary files /dev/null and b/Docs/img/ue_generate_routes.png differ
diff --git a/Docs/img/ue_import_asset.png b/Docs/img/ue_import_asset.png
new file mode 100644
index 000000000..16e457639
Binary files /dev/null and b/Docs/img/ue_import_asset.png differ
diff --git a/Docs/img/ue_noexport.png b/Docs/img/ue_noexport.png
new file mode 100644
index 000000000..eac7519ea
Binary files /dev/null and b/Docs/img/ue_noexport.png differ
diff --git a/Docs/img/ue_tl_group.jpg b/Docs/img/ue_tl_group.jpg
index e6ebc8779..b2ad6e910 100644
Binary files a/Docs/img/ue_tl_group.jpg and b/Docs/img/ue_tl_group.jpg differ
diff --git a/Docs/img/vehicle_factory.png b/Docs/img/vehicle_factory.png
new file mode 100644
index 000000000..9207760dd
Binary files /dev/null and b/Docs/img/vehicle_factory.png differ
diff --git a/Docs/img/vehicle_mesh.png b/Docs/img/vehicle_mesh.png
new file mode 100644
index 000000000..331d447df
Binary files /dev/null and b/Docs/img/vehicle_mesh.png differ
diff --git a/Docs/img/vehicle_telemetry.png b/Docs/img/vehicle_telemetry.png
new file mode 100644
index 000000000..54e5998f1
Binary files /dev/null and b/Docs/img/vehicle_telemetry.png differ
diff --git a/Docs/img/wheel_blueprint.png b/Docs/img/wheel_blueprint.png
new file mode 100644
index 000000000..fd6dfbaaa
Binary files /dev/null and b/Docs/img/wheel_blueprint.png differ
diff --git a/Docs/img/wheel_shape.png b/Docs/img/wheel_shape.png
new file mode 100644
index 000000000..a0a04fd68
Binary files /dev/null and b/Docs/img/wheel_shape.png differ
diff --git a/Docs/index.md b/Docs/index.md
index 1a3183709..5e101e925 100644
--- a/Docs/index.md
+++ b/Docs/index.md
@@ -1,28 +1,30 @@
# CARLA Documentation
-Welcome to the CARLA documentation.
+Welcome to the CARLA documentation.
-This home page contains an index with a brief description of the different sections in the documentation. Feel free to read in whatever order preferred. In any case, here are a few suggestions for newcomers.
+This home page contains an index with a brief description of the different sections in the documentation. Feel free to read in whatever order preferred. In any case, here are a few suggestions for newcomers.
-* __Install CARLA.__ Either follow the [Quick start installation](start_quickstart.md) to get a CARLA release or [make the build](build_linux.md) for a desired platform.
-* __Start using CARLA.__ The section titled [First steps](core_concepts.md) is an introduction to the most important concepts.
-* __Check the API.__ there is a handy [Python API reference](python_api.md) to look up the classes and methods available.
+* __Install CARLA.__ Either follow the [Quick start installation](start_quickstart.md) to get a CARLA release or [make the build](build_linux.md) for a desired platform.
+* __Start using CARLA.__ The section titled [First steps](core_concepts.md) is an introduction to the most important concepts.
+* __Check the API.__ there is a handy [Python API reference](python_api.md) to look up the classes and methods available.
-The CARLA forum is available to post any doubts or suggestions that may arise during the reading.
+The CARLA forum is available to post any doubts or suggestions that may arise during the reading.
+
+
!!! Warning
- Change the docs version to fit the CARLA version you are using. Use the pannel in the bottom-right side of this window to change to previous versions. ![docs_version_panel](img/docs_version_panel.jpg)
+ __Change the docs version to fit the CARLA version you are using__. Use the panel in the bottom-right side of this window to change to previous versions. __The _Latest_ version points to documentation in the `dev` branch__ which may refer to features currently in development and __not available__ in any packaged version of CARLA, as well general documentation improvements. ![docs_version_panel](img/docs_version_panel.jpg)
---
## Getting started
[__Introduction__](start_introduction.md) — What to expect from CARLA.
-[__Quick start__](start_quickstart.md) — Get the CARLA releases.
+[__Quick start package installation__](start_quickstart.md) — Get the CARLA releases.
## Building CARLA
@@ -31,7 +33,7 @@ CARLA forum
[__Windows build__](build_windows.md) — Make the build on Windows.
[__Update CARLA__](build_update.md) — Get up to date with the latest content.
[__Build system__](build_system.md) — Learn about the build and how it is made.
-[__Running in a Docker__](build_docker.md) — Run CARLA using a container solution.
+[__CARLA in Docker__](build_docker.md) — Run CARLA using a container solution.
[__F.A.Q.__](build_faq.md) — Some of the most frequent installation issues.
@@ -42,18 +44,25 @@ CARLA forum
[__3rd. Maps and navigation__](core_map.md) — Discover the different maps and how do vehicles move around.
[__4th. Sensors and data__](core_sensors.md) — Retrieve simulation data using sensors.
-## Advanced steps
+## Advanced concepts
[__OpenDRIVE standalone mode__](adv_opendrive.md) — Use any OpenDRIVE file as a CARLA map.
[__PTV-Vissim co-simulation__](adv_ptv.md) — Run a synchronous simulation between CARLA and PTV-Vissim.
[__Recorder__](adv_recorder.md) — Register the events in a simulation and play it again.
[__Rendering options__](adv_rendering_options.md) — From quality settings to no-render or off-screen modes.
[__RSS__](adv_rss.md) — An implementation of RSS in the CARLA client library.
-[__SUMO co-simulation__](adv_sumo.md) — Run a synchronous simulation between CARLA and SUMO.
[__Synchrony and time-step__](adv_synchrony_timestep.md) — Client-server communication and simulation time.
+[__Benchmarking Performance__](adv_benchmarking.md) — Perform benchmarking using our prepared script.
+[__CARLA Agents__](adv_agents.md) — Agents scripts allow single vehicles to roam the map or drive to a set destination.
+
+## Traffic Simulation
+
+[__ Traffic Simulation Overview__](ts_traffic_simulation_overview.md) — An overview of the different options available to populate your scenes with traffic
[__Traffic Manager__](adv_traffic_manager.md) — Simulate urban traffic by setting vehicles to autopilot mode.
+[__SUMO co-simulation__](adv_sumo.md) — Run a synchronous simulation between CARLA and SUMO.
+[__Scenic__](tuto_G_scenic.md) — Follow an example of defining different scenarios using the Scenic library.
## References
-[__Python API reference__](python_api.md) — Classes and methods in the Python API.
+[__Python API reference__](python_api.md) — Classes and methods in the Python API.
[__Blueprint library__](bp_library.md) — Blueprints provided to spawn actors.
[__C++ reference__](ref_cpp.md) — Classes and methods in CARLA C++.
[__Recorder binary file format__](ref_recorder_binary_file_format.md) — Detailed explanation of the recorder file format.
@@ -63,33 +72,56 @@ CARLA forum
[__carlaviz — web visualizer__](plugins_carlaviz.md) — Plugin that listens the simulation and shows the scene and some simulation data in a web browser.
## ROS bridge
-[__ROS bridge installation__](ros_installation.md) — The different ways to install the ROS bridge.
-[__CARLA messages reference__](ros_msgs.md) — Contains explanations and fields for every type of CARLA message available in ROS.
-[__Launchfiles reference__](ros_launchs.md) — Lists the launchfiles and nodes provided, and the topics being consumed and published.
+[__ROS bridge documentation__](ros_documentation.md) — Brief overview of the ROS bridge and a link to the full documentation
+## Custom Maps
+
+[__Overview of custom maps in CARLA__](tuto_M_custom_map_overview.md) — An overview of the process and options involved in adding a custom, standard sized map
+[__Create a map in RoadRunner__](tuto_M_generate_map.md) — How to generate a customs, standard sized map in RoadRunner
+[__ Import map in CARLA package__](tuto_M_add_map_package.md) How to import a map in a CARLA package
+[__Import map in CARLA source build__](tuto_M_add_map_source.md) — How to import a map in CARLA built from source
+[__Alternative ways to import maps__](tuto_M_add_map_alternative.md) — Alternative methods to import maps
+[__ Manually prepare map package__](tuto_M_manual_map_package.md) — How to prepare a map for manual import
+[__Customizing maps: Layered maps__](tuto_M_custom_layers.md) — How to create sub-layers in your custom map
+[__ Customizing maps: Traffic lights and signs__](tuto_M_custom_add_tl.md) — How to add traffic lights and signs to your custom map
+[__ Customizing maps: Road painter__](tuto_M_custom_road_painter.md) — How to use the road painter tool to change the apearance of the road
+[__Customizing Maps: Procedural Buildings__](tuto_M_custom_buildings.md) — Populate your custom map with buildings
+[__ Customizing maps: Weather and landscape__](tuto_M_custom_weather_landscape.md) — Create the weather profile for your custom map and populate the landscape
+[__Generate pedestrian navigation__](tuto_M_generate_pedestrian_navigation.md) — Obtain the information needed for walkers to move around.
+
+## Large Maps
+
+[__Large maps overview__](large_map_overview.md) — An explanation of how large maps work in CARLA
+[__Create a Large Map in RoadRunner__](large_map_roadrunner.md) — How to create a large map in RoadRunner
+[__Import/Package a Large Map__](large_map_import.md) — How to import a large map
## Tutorials — General
[__Add friction triggers__](tuto_G_add_friction_triggers.md) — Define dynamic box triggers for wheels.
[__Control vehicle physics__](tuto_G_control_vehicle_physics.md) — Set runtime changes on a vehicle physics.
[__Control walker skeletons__](tuto_G_control_walker_skeletons.md) — Animate walkers using skeletons.
+[__Generate maps with OpenStreetMap__](tuto_G_openstreetmap.md) — Use OpenStreetMap to generate maps for use in simulations.
[__Retrieve simulation data__](tuto_G_retrieve_data.md) — A step by step guide to properly gather data using the recorder.
+[__CarSim Integration (Beta)__](tuto_G_carsim_integration.md) — Tutorial on how to run a simulation using the CarSim vehicle dynamics engine.
+[__RLlib Integration__](tuto_G_rllib_integration.md) — Find out how to run your own experiment using the RLlib library.
+[__Chrono Integration__](tuto_G_chrono.md) — Use the Chrono integration to simulation physics
+[__Build Unreal Engine and CARLA in Docker__](build_docker_unreal.md) — Build Unreal Engine and CARLA in Docker
## Tutorials — Assets
-[__Add a new map__](tuto_A_add_map.md) — Create and ingest a new map.
[__Add a new vehicle__](tuto_A_add_vehicle.md) — Prepare a vehicle to be used in CARLA.
[__Add new props__](tuto_A_add_props.md) — Import additional props into CARLA.
[__Create standalone packages__](tuto_A_create_standalone.md) — Generate and handle standalone packages for assets.
-[__Map customization__](tuto_A_map_customization.md) — Edit an existing map.
[__Material customization__](tuto_A_material_customization.md) — Edit vehicle and building materials.
-[__Vehicle modelling__](tuto_A_vehicle_modelling.md) — Create a new vehicle for CARLA.
## Tutorials — Developers
-[__Contribute with new assets__](tuto_D_contribute_assets.md) — Add new content to CARLA.
+[__How to upgrade content__](tuto_D_contribute_assets.md) — Add new content to CARLA.
[__Create a sensor__](tuto_D_create_sensor.md) — Develop a new sensor to be used in CARLA.
+[__Create semantic tags__](tuto_D_create_semantic_tags.md) — Define customized tags for semantic segmentation.
[__Customize vehicle suspension__](tuto_D_customize_vehicle_suspension.md) — Modify the suspension system of a vehicle.
-[__Make a release__](tuto_D_make_release.md) — For developers who want to publish a release.
[__Generate detailed colliders__](tuto_D_generate_colliders.md) — Create detailed colliders for vehicles.
-[__Generate pedestrian navigation__](tuto_D_generate_pedestrian_navigation.md) — Obtain the information needed for walkers to move around.
+[__Make a release__](tuto_D_make_release.md) — How to make a release of CARLA
+## CARLA Ecosystem
+
+[__Ansys Real Time Radar Model__](ecosys_ansys.md) — Details about the Ansys RTR Webinair
## Contributing
[__Contribution guidelines__](cont_contribution_guidelines.md) — The different ways to contribute to CARLA.
[__Code of conduct__](cont_code_of_conduct.md) — Standard rights and duties for contributors.
diff --git a/Docs/large_map_import.md b/Docs/large_map_import.md
new file mode 100644
index 000000000..22687e43b
--- /dev/null
+++ b/Docs/large_map_import.md
@@ -0,0 +1,150 @@
+# Import/Package a Large Map
+
+Large maps generated in RoadRunner can be imported into the source build of CARLA and packaged for distribution and usage in a CARLA standalone package. The process is very simlar to that of standard maps with the addition of specific nomenclature for tiles and batch importing.
+
+- [__Files and folders__](#files-and-folders)
+- [__Create the JSON description (Optional)__](#create-the-json-description-optional)
+- [__Making the import__](#making-the-import)
+- [__Package a large map__](#package-a-large-map)
+
+---
+
+## Files and folders
+
+All files to be imported should be placed in the `Import` folder of the root CARLA directory. These files should include:
+
+- The mesh of the map in multiple `.fbx` files representing different tiles of the map.
+- The OpenDRIVE definition in a single `.xodr` file.
+
+!!! Warning
+ You cannot import large maps and standard maps at the same time.
+
+The naming convention of map tiles is very important. Each map tile should be named according to the following convention:
+
+```
+_Tile__.fbx
+```
+
+Be aware that a more positive __y coordinate__ refers to a tile lower on the y-axis. For example,`Map01_Tile_0_1` would sit just below `Map01_Tile_0_0`.
+
+>>>>>>>>![map_tiles](../img/map_tiles.png)
+
+A resulting `Import` folder with a package containing a large map made of four tiles should have a structure similar to the one below:
+
+```sh
+Import
+│
+└── Package01
+ ├── Package01.json
+ ├── Map01_Tile_0_0.fbx
+ ├── Map01_Tile_0_1.fbx
+ ├── Map01_Tile_1_0.fbx
+ ├── Map01_Tile_1_1.fbx
+ └── Map01.xodr
+
+```
+
+!!! Note
+ The `package.json` file is not strictly necessary. If there is no `package.json` file created, the automated import process will create one. Find out more about to structure your own `package.json` in the next section.
+
+---
+
+## Create the JSON description (Optional)
+
+The `.json` description is created automatically during the import process, but there is also the option to create one manually. An existing `.json` description will override any values passed as arguments in the import process.
+
+The `.json` file should be created in the root folder of the package. The file name will be the package distribution name. The content of the file describes a JSON array of __maps__ and __props__ with basic information for each one.
+
+__Maps__ need the following parameters:
+
+- __name:__ Name of the map. This must be the same as the `.fbx` and `.xodr` files.
+- __xodr:__ Path to the `.xodr` file.
+- __use_carla_materials:__ If __True__, the map will use CARLA materials. Otherwise, it will use RoadRunner materials.
+- __tile_size:__ The size of the tiles. Default value is 2000 (2kmx2km).
+- __tiles:__ A list of the `.fbx` tile files that make up the entire map.
+
+__Props__ are not part of this tutorial. Please see [this](tuto_A_add_props.md) tutorial for how to add new props.
+
+The resulting `.json` file should resemble the following:
+
+```json
+{
+ "maps": [
+ {
+ "name": "Map01",
+ "xodr": "./Map01.xodr",
+ "use_carla_materials": true,
+ "tile_size": 2000,
+ "tiles": [
+ "./Map01_Tile_0_0.fbx",
+ "./Map01_Tile_0_1.fbx",
+ "./Map01_Tile_1_0.fbx",
+ "./Map01_Tile_1_1.fbx"
+ ]
+ }
+ ],
+ "props": []
+}
+```
+
+
+
+---
+
+## Making the import
+
+When all files have been placed in the `Import` folder, run the following command in the root CARLA folder:
+
+```sh
+make import
+```
+
+Depending on your system, Unreal Engine may consume too much memory to be able to import all files at once. You can choose to import the files in batches of MB by running the command:
+
+```sh
+make import ARGS="--batch-size=200"
+```
+
+Two more flags exist for the `make import` command:
+
+- `--package=` specifies the name of the package. By default, this is set to `map_package`. Two packages cannot have the same name, so using the default value will lead to errors on a subsequent ingestion. __It is highly recommended to change the name of the package__. Use this flag by running the command:
+
+```sh
+make import ARGS="--package="
+```
+
+- `--no-carla-materials` specifies that you do not want to use the default CARLA materials (road textures etc). You will use the RoadRunner materials instead. This flag is __only required if you are not__ providing your own [`.json` file](tuto_M_manual_map_package.md). Any value in the `.json` file will override this flag. Use this flag by running the command:
+
+```sh
+make import ARGS="--no-carla-materials"
+```
+
+All files will be imported and prepared to be used in the Unreal Editor. The map package will be created in `Unreal/CarlaUE4/Content`. A base map tile, ``, will be created as a streaming level for all the tiles. The base tile will contain the sky, weather, and large map actors and will be ready for use in a simulation.
+
+!!! Note
+ It is currently not recommended to use the customization tools provided for standard maps in the Unreal Editor, e.g., road painter, procedural buildings, etc.
+
+---
+
+## Package a large map
+
+To package your large map so it can be used in the CARLA standalone package, run the following command:
+
+```sh
+make package ARGS="--packages="
+```
+
+This will create a standalone package compressed in a `.tar.gz` file. The files will be saved in the `Dist` folder on Linux, and `/Build/UE4Carla/` on Windows. They can then be distributed and packaged to use in standalone CARLA packages.
+
+---
+
+If you have any questions about the large map import and packaging process, then you can ask in the [forum](https://github.com/carla-simulator/carla/discussions).
+
+
+
+
diff --git a/Docs/large_map_overview.md b/Docs/large_map_overview.md
new file mode 100644
index 000000000..b49b9b49c
--- /dev/null
+++ b/Docs/large_map_overview.md
@@ -0,0 +1,86 @@
+# Large maps overview
+
+- [__Large maps overview__](#large-maps-overview)
+- [__Tile streaming__](#tile-streaming)
+- [__Dormant actors__](#dormant-actors)
+
+---
+
+## Large maps overview
+
+The large map feature in CARLA allows users to perform simulations at a vast scale. In CARLA, large maps are divided into square tiles no larger than 2kmx2km. Tiles are streamed in and out of the server based on their proximity (streaming distance) to the ego vehicle. Other actors on the map are also managed according to their streaming distance from the ego vehicle.
+
+---
+
+## Tile streaming
+
+The ego vehicle is integral to the loading and unloading of map tiles. Tiles are streamed in and out of the server based on the value of the streaming distance from the ego vehicle. For example, tiles located outside the streaming distance will not be rendered in the simulation, and tiles within the streaming distance will be rendered. The rendered tiles will change as the hero vehicle moves.
+
+To set a vehicle as ego, use the [`set_attribute`](python_api.md#carla.ActorBlueprint.set_attribute) method as shown below:
+
+```py
+blueprint.set_attribute('role_name', 'hero' )
+world.spawn_actor(blueprint, spawn_point)
+```
+
+Use the code snippet below to set the streaming distance so tiles will be loaded within a 2km radius of the ego vehicle:
+
+```py
+settings = world.get_settings()
+settings.tile_stream_distance = 2000
+world.apply_settings(settings)
+```
+
+You can also set the streaming distance using `config.py`:
+
+```sh
+cd PythonAPI/util
+python3 config.py --tile-stream-distance 2000
+```
+
+!!! Note
+ Large maps currently supports only one ego vehicle at a time.
+
+---
+
+## Dormant actors
+
+The large map feature introduces the concept of dormant actors to CARLA. Dormant actors exist within the context of large maps only. Dormant actors are non-ego-vehicle actors in the simulation that are located outside of the __actor active distance__ of the ego vehicle, e.g., vehicles far from the ego vehicle. The actor active distance can be equal to or less than the streaming distance.
+
+If an actor finds itself outside of the actor active distance of the ego vehicle, it will become dormant. The actor will still exist, but it will not be rendered. Physics will not be calculated (unless running in hybrid mode via the traffic manager), although [location](python_api.md#carla.Actor.set_location) and [transformation](python_api.md#carla.Actor.set_transform) can still be set. Once the dormant actor comes within actor active distance of the ego vehicle again, it will wake up, and its rendering and physics will resume as normal.
+
+Actors controlled by the Traffic Manager have distinct behaviors that can be configured when operating within a large map. Read more in the [Traffic Manager documentation](adv_traffic_manager.md#traffic-manager-in-large-maps) to find out about how this works.
+
+An actor will become dormant or wake up on a [`world.tick()`](python_api.md#carla.World.tick).
+
+To set the actor active distance to a 2 km radius around the ego vehicle:
+
+```py
+settings = world.get_settings()
+settings.actor_active_distance = 2000
+world.apply_settings(settings)
+```
+
+You can also set the actor active distance using `config.py`:
+
+```sh
+cd PythonAPI/util
+python3 config.py --actor-active-distance 2000
+```
+
+To check if an actor is dormant, you can use the Python API:
+
+```py
+actor.is_dormant
+```
+
+---
+
+If you have any questions about large maps, then you can ask in the [forum](https://github.com/carla-simulator/carla/discussions).
+
+
diff --git a/Docs/large_map_roadrunner.md b/Docs/large_map_roadrunner.md
new file mode 100644
index 000000000..9cf24cf63
--- /dev/null
+++ b/Docs/large_map_roadrunner.md
@@ -0,0 +1,108 @@
+# Create a Large Map in RoadRunner
+
+RoadRunner is the recommended software to create large maps to be imported into CARLA. This guide outlines what RoadRunner is, things to consider when building the large map and how to export custom large maps ready for importing into CARLA.
+
+- [__Introduction to RoadRunner__](#introduction-to-roadrunner)
+- [__Before you start__](#before-you-start)
+- [__Build a large map in RoadRunner__](#build-a-large-map-in-roadrunner)
+- [__Export a large map in RoadRunner__](#export-a-large-map-in-roadrunner)
+- [__Next steps__](#next-steps)
+---
+## Introduction to RoadRunner
+
+RoadRunner is an interactive editor that lets you design 3D scenes for simulating and testing automated driving systems. It can be used to create road layouts and accompanying OpenDRIVE and geometry information. Find out more about RoadRunner [here][rr_home].
+
+RoadRunner is part of the MATLAB Campus-Wide Licenses, so many universities can provide unlimited academic access. [Check][rr_eligibility] if your university has access. Reach out to *automated-driving@mathworks.com* for any questions or troubles regarding accessibility. There is also a [trial version][rr_trial_version] available.
+
+A license for RoadRunner is also available to everyone participating in the CARLA Leaderboard. Click [here][rr_leaderboard] for more information.
+
+[rr_home]: https://www.mathworks.com/products/roadrunner.html
+[rr_trial_version]: https://www.mathworks.com/products/roadrunner.html
+[rr_eligibility]: https://www.mathworks.com/academia/tah-support-program/eligibility.html
+[rr_leaderboard]: https://www.mathworks.com/academia/student-competitions/carla-autonomous-driving-challenge.html
+
+---
+## Before you start
+
+You will need to install RoadRunner. You can follow the [installation guide][rr_docs] at the Mathworks website.
+
+[rr_docs]: https://www.mathworks.com/help/roadrunner/ug/install-and-activate-roadrunner.html
+
+---
+
+## Build a large map in RoadRunner
+
+The specifics of how to build a large map in RoadRunner go beyond the scope of this guide, however, there are video tutorials available in the [RoadRunner documentation][rr_tutorials].
+
+If you are building a large map with elevation, the recommended largest size of the map is 20km by 20km. Maps larger than this may cause RoadRunner to crash on export.
+
+[rr_tutorials]: https://www.mathworks.com/support/search.html?fq=asset_type_name:video%20category:roadrunner/index&page=1&s_tid=CRUX_topnav
+
+---
+
+## Export a large map in RoadRunner
+
+Below is a basic guideline to export your custom large map from RoadRunner.
+
+[exportlink]: https://www.mathworks.com/help/roadrunner/ug/Exporting-to-CARLA.html
+
+Once you have made your map in RoadRunner you will be able to export it. Be aware that __the road layout cannot be modified after it has been exported.__ Before exporting, ensure that:
+
+- The map is centered at (0,0) to ensure the map can be visualized correctly in Unreal Engine.
+- The map definition is correct.
+- The map validation is correct, paying close attention to connections and geometries.
+
+
+>>>>![CheckGeometry](../img/check_geometry.jpg)
+
+Once the map is ready, click on the `OpenDRIVE Preview Tool` button to visualize the OpenDRIVE road network and give everything one last check.
+
+>>>>![checkopen](../img/check_open.jpg)
+
+!!! note
+ _OpenDrive Preview Tool_ makes it easier to test the integrity of the map. If there are any errors with junctions, click on `Maneuver Tool`, and `Rebuild Maneuver Roads`.
+
+Make sure the full map is selected for export by clicking on the [_World settings tool_](https://www.mathworks.com/help/roadrunner/ref/worldsettingstool.html) and dragging the edges of the blue boundary box to encompass the full area you would like to export. when it's ready, click on _Apply World Changes_.
+
+![world_bounds_settings](img/rr_world_settings.png)
+
+When you are ready to export:
+
+__1.__ Export the `.fbx`:
+
+ - In the main toolbar, select `File` -> `Export` -> `Firebox (.fbx)`
+
+__2.__ In the window that pops up:
+
+>- Check the following options:
+ - _Split by Segmentation_: Divides the mesh by semantic segmentation and imroves pedestrian navigation.
+ - _Power of Two Texture Dimensions_: Improves performance.
+ - _Embed Textures_: Ensures textures are embedded in the mesh.
+ - _Export to Tiles_: Choose the size of the tiles. The maximum size that can be used by CARLA is 2000 x 2000.
+ - _Export Individual Tiles_: Generates the individual tiles needed for streaming large maps in CARLA.
+
+>>>>>>![export_large_map_fbx](../img/large_map_export_fbx.png)
+
+__3.__ Export the `.xodr`:
+
+ - In the main toolbar, select `File` -> `Export` -> `OpendDRIVE (.xodr)`
+
+!!! Warning
+ Make sure that the `.xodr` and the `.fbx` files have the same name.
+
+---
+
+## Next steps
+
+You are now ready to import your map into CARLA. See the [__Import a Large Map__](large_map_import.md) guide for more details.
+
+---
+
+If you have any questions about the process, then you can ask in the [forum](https://github.com/carla-simulator/carla/discussions).
+
+
\ No newline at end of file
diff --git a/Docs/plugins_carlaviz.md b/Docs/plugins_carlaviz.md
index e5975a5ad..36dcb06a7 100644
--- a/Docs/plugins_carlaviz.md
+++ b/Docs/plugins_carlaviz.md
@@ -123,10 +123,11 @@ Here is a list of options available for visualization. Additional elements may s
* `/stop_sign` — Show the map's stop signs in the visualization window.
-Try to spawn some actors. These will be automatically updated in the visualization window.
+Try to spawn some actors. These will be automatically updated in the visualization window.
```sh
cd PythonAPI/examples
-python3 spawn_npc.py -n 10 -w 5
+# Spawns actors in a synchronous mode simulation
+python3 generate_traffic.py -n 10 -w 5
```
![carlaviz_full](img/plugins_carlaviz_full.jpg)
@@ -149,7 +150,7 @@ That is all there is to know about the carlaviz plugin. If there are any doubts,
diff --git a/Docs/python_api.md b/Docs/python_api.md
index 764d26bbb..1fef3aa4e 100644
--- a/Docs/python_api.md
+++ b/Docs/python_api.md
@@ -1,5 +1,5 @@
#Python API reference
-This reference contains all the details the Python API. To consult a previous reference for a specific CARLA release, change the documentation version using the panel in the bottom right corner. This will change the whole documentation to a previous state. Remember to go back to latest to get the details of the current state of CARLA.
+This reference contains all the details the Python API. To consult a previous reference for a specific CARLA release, change the documentation version using the panel in the bottom right corner. This will change the whole documentation to a previous state. Remember that the latest version is the `dev` branch and may show features not available in any packaged versions of CARLA.
## carla.Actor
CARLA defines actors as anything that plays a role in the simulation or can be moved around. That includes: pedestrians, vehicles, sensors and traffic signs (considering traffic lights as part of these). Actors are spawned in the simulation by [carla.World](#carla.World) and they need for a [carla.ActorBlueprint](#carla.ActorBlueprint) to be created. These blueprints belong into a library provided by CARLA, find more about them [here](bp_library.md).
@@ -42,12 +42,31 @@ Tells the simulator to destroy this actor and returns True if it was succ
_
- **disable_constant_velocity**(**self**)
Disables any constant velocity previously set for a [carla.Vehicle](#carla.Vehicle) actor.
+- **enable_chrono_physics**(**self**, **max_substeps**, **max_substep_delta_time**, **vehicle_json**, **powertrain_json**, **tire_json**, **base_json_path**)
+Enables Chrono physics on a spawned vehicle.
+ - **Parameters:**
+ - `max_substeps` (_int_) – Max number of Chrono substeps.
+ - `max_substep_delta_time` (_int_) – Max size of substep.
+ - `vehicle_json` (_str_) – Path to vehicle json file relative to `base_json_path`.
+ - `powertrain_json` (_str_) – Path to powertrain json file relative to `base_json_path`.
+ - `tire_json` (_str_) – Path to tire json file relative to `base_json_path`.
+ - `base_json_path` (_str_) – Path to `chrono/data/vehicle` folder. E.g., `/home/user/carla/Build/chrono-install/share/chrono/data/vehicle/` (the final `/` character is required).
+ - **Note:** _Ensure that you have started the CARLA server with the `ARGS="--chrono"` flag. You will not be able to use Chrono physics without this flag set.
+_
+ - **Warning:** _Collisions are not supported. When a collision is detected, physics will revert to the default CARLA physics.
+_
- **enable_constant_velocity**(**self**, **velocity**)
Sets a vehicle's velocity vector to a constant value over time. The resulting velocity will be approximately the `velocity` being set, as with __set_target_velocity()__.
- **Parameters:**
- `velocity` (_[carla.Vector3D](#carla.Vector3D) – m/s_) – Velocity vector in local space.
+ - **Note:** _Only [carla.Vehicle](#carla.Vehicle) actors can use this method.
+_
- **Warning:** _Enabling a constant velocity for a vehicle managed by the [Traffic Manager](https://[carla.readthedocs.io](#carla.readthedocs.io)/en/latest/adv_traffic_manager/) may cause conflicts. This method overrides any changes in velocity by the TM.
_
+- **show_debug_telemetry**(**self**, **enabled**=True)
+Enables or disables the telemetry on this vehicle. This shows information about the vehicles current state and forces applied to it in the spectator window. Only information for one vehicle can be shown so if you enable a second one, the previous will be automatically disabled.
+ - **Parameters:**
+ - `enabled` (_bool_)
##### Getters
- **get_acceleration**(**self**)
@@ -72,6 +91,10 @@ Returns the world this actor belongs to.
- **Return:** _[carla.World](#carla.World)_
##### Setters
+- **set_enable_gravity**(**self**, **enabled**)
+Enables or disables gravity for the actor. __Default__ is True.
+ - **Parameters:**
+ - `enabled` (_bool_)
- **set_location**(**self**, **location**)
Teleports the actor to a given location.
- **Parameters:**
@@ -82,17 +105,13 @@ Enables or disables the simulation of physics on this actor.
- **Parameters:**
- `enabled` (_bool_)
- **set_target_angular_velocity**(**self**, **angular_velocity**)
-Sets the actor's angular velocity vector. The modification will be effective two frames after the setting. Also, this is applied before the physics step so the resulting angular velocity will be affected by external forces at this frame such as friction.
+Sets the actor's angular velocity vector. This is applied before the physics step so the resulting angular velocity will be affected by external forces such as friction.
- **Parameters:**
- `angular_velocity` (_[carla.Vector3D](#carla.Vector3D) – deg/s_)
- - **Note:** _The update will not be effective until two frames after it is set.
-_
- **set_target_velocity**(**self**, **velocity**)
-Sets the actor's velocity vector. The modification will be effective two frames after the setting. Also, this is applied before the physics step so the resulting velocity will be affected by external forces at this frame such as friction.
+Sets the actor's velocity vector. This is applied before the physics step so the resulting angular velocity will be affected by external forces such as friction.
- **Parameters:**
- `velocity` (_[carla.Vector3D](#carla.Vector3D)_)
- - **Note:** _The update will not be effective until two frames after it is set.
-_
- **set_transform**(**self**, **transform**)
Teleports the actor to a given transform (location and rotation).
- **Parameters:**
@@ -193,7 +212,7 @@ Returns the actor's attribute with `id` as identifier if existing.
- **Setter:** _[carla.ActorBlueprint.set_attribute](#carla.ActorBlueprint.set_attribute)_
##### Setters
-- **set_attribute**(**self**, **id**, **value**)
+- **set_attribute**(**self**, **id**, **value**)
If the `id` attribute is modifiable, changes its value to `value`.
- **Parameters:**
- `id` (_str_) – The identifier for the attribute that is intended to be changed.
@@ -355,7 +374,7 @@ Parses the location and extent of the bounding box to string.
---
## carla.CityObjectLabel
-Enum declaration that contains the different tags available to filter the bounding boxes returned by [carla.World.get_level_bbs](#carla.World.get_level_bbs)(). These values correspond to the [semantic tag](https://[carla.readthedocs.io](#carla.readthedocs.io)/en/latest/ref_sensors/#semantic-segmentation-camera) that the elements in the scene have.
+Enum declaration that contains the different tags available to filter the bounding boxes returned by [carla.World.get_level_bbs](#carla.World.get_level_bbs)(). These values correspond to the [semantic tag](ref_sensors.md#semantic-segmentation-camera) that the elements in the scene have.
### Instance Variables
- **None**
@@ -391,18 +410,18 @@ The Client connects CARLA to the server which runs the simulation. Both server a
The client also has a recording feature that saves all the information of a simulation while running it. This allows the server to replay it at will to obtain information and experiment with it. [Here](adv_recorder.md) is some information about how to use this recorder.
### Methods
-- **\__init__**(**self**, **host**=127.0.0.1, **port**=2000, **worker_threads**=0)
+- **\__init__**(**self**, **host**=127.0.0.1, **port**=2000, **worker_threads**=0)
Client constructor.
- **Parameters:**
- `host` (_str_) – IP address where a CARLA Simulator instance is running. Default is localhost (127.0.0.1).
- `port` (_int_) – TCP port where the CARLA Simulator instance is running. Default are 2000 and the subsequent 2001.
- `worker_threads` (_int_) – Number of working threads used for background updates. If 0, use all available concurrency.
- **apply_batch**(**self**, **commands**)
-Executes a list of commands on a single simulation step and retrieves no information. If you need information about the response of each command, use the __apply_batch_sync()__ method. [Here](https://github.com/carla-simulator/carla/blob/10c5f6a482a21abfd00220c68c7f12b4110b7f63/PythonAPI/examples/spawn_npc.py#L126) is an example on how to delete the actors that appear in [carla.ActorList](#carla.ActorList) all at once.
+Executes a list of commands on a single simulation step and retrieves no information. If you need information about the response of each command, use the __apply_batch_sync()__ method. [Here](https://github.com/carla-simulator/carla/blob/master/PythonAPI/examples/generate_traffic.py) is an example on how to delete the actors that appear in [carla.ActorList](#carla.ActorList) all at once.
- **Parameters:**
- `commands` (_list_) – A list of commands to execute in batch. Each command is different and has its own parameters. They appear listed at the bottom of this page.
-- **apply_batch_sync**(**self**, **commands**, **due_tick_cue**=False)
-Executes a list of commands on a single simulation step, blocks until the commands are linked, and returns a list of command.Response that can be used to determine whether a single command succeeded or not. [Here](https://github.com/carla-simulator/carla/blob/10c5f6a482a21abfd00220c68c7f12b4110b7f63/PythonAPI/examples/spawn_npc.py#L112-L116) is an example of it being used to spawn actors.
+- **apply_batch_sync**(**self**, **commands**, **due_tick_cue**=False)
+Executes a list of commands on a single simulation step, blocks until the commands are linked, and returns a list of command.Response that can be used to determine whether a single command succeeded or not. [Here](https://github.com/carla-simulator/carla/blob/master/PythonAPI/examples/generate_traffic.py) is an example of it being used to spawn actors.
- **Parameters:**
- `commands` (_list_) – A list of commands to execute in batch. The commands available are listed right above, in the method **apply_batch()**.
- `due_tick_cue` (_bool_) – A boolean parameter to specify whether or not to perform a [carla.World.tick](#carla.World.tick) after applying the batch in _synchronous mode_. It is __False__ by default.
@@ -426,13 +445,18 @@ Reload the current world, note that a new world is created with default settings
- **Parameters:**
- `reset_settings` (_bool_) – Option to reset the episode setting to default values, set to false to keep the current settings. This is useful to keep sync mode when changing map and to keep deterministic scenarios.
- **Raises:** RuntimeError when corresponding.
-- **replay_file**(**self**, **name**, **start**, **duration**, **follow_id**)
+- **replay_file**(**self**, **name**, **start**, **duration**, **follow_id**, **replay_sensors**)
Load a new world with default settings using `map_name` map. All actors present in the current world will be destroyed, __but__ traffic manager instances will stay alive.
- **Parameters:**
- `name` (_str_) – Name of the file containing the information of the simulation.
- `start` (_float – seconds_) – Time where to start playing the simulation. Negative is read as beginning from the end, being -10 just 10 seconds before the recording finished.
- `duration` (_float – seconds_) – Time that will be reenacted using the information `name` file. If the end is reached, the simulation will continue.
- `follow_id` (_int_) – ID of the actor to follow. If this is 0 then camera is disabled.
+ - `replay_sensors` (_bool_) – Flag to enable or disable the spawn of sensors during playback.
+- **request_file**(**self**, **name**)
+Requests one of the required files returned by [carla.Client.get_required_files](#carla.Client.get_required_files).
+ - **Parameters:**
+ - `name` (_str_) – Name of the file you are requesting.
- **show_recorder_actors_blocked**(**self**, **filename**, **min_time**, **min_distance**)
The terminal will show the information registered for actors considered blocked. An actor is considered blocked when it does not move a minimum distance in a period of time, being these `min_distance` and `min_time`.
- **Parameters:**
@@ -486,6 +510,11 @@ Returns a list of strings containing the paths of the maps available on server.
- **get_client_version**(**self**)
Returns the client libcarla version by consulting it in the "Version.h" file. Both client and server can use different libcarla versions but some issues may arise regarding unexpected incompatibilities.
- **Return:** _str_
+- **get_required_files**(**self**, **folder**, **download**=True)
+Asks the server which files are required by the client to use the current map. Option to download files automatically if they are not already in the cache.
+ - **Parameters:**
+ - `folder` (_str_) – Folder where files required by the client will be downloaded to.
+ - `download` (_bool_) – If True, downloads files that are not already in cache.
- **get_server_version**(**self**)
Returns the server libcarla version by consulting it in the "Version.h" file. Both client and server should use the same libcarla version.
- **Return:** _str_
@@ -499,6 +528,12 @@ Returns the world object currently active in the simulation. This world will be
- **Return:** _[carla.World](#carla.World)_
##### Setters
+- **set_files_base_folder**(**self**, **path**)
+ - **Parameters:**
+ - `path` (_str_) – Specifies the base folder where the local cache for required files will be placed.
+- **set_replayer_ignore_hero**(**self**, **ignore_hero**)
+ - **Parameters:**
+ - `ignore_hero` (_bool_) – Enables or disables playback of the hero vehicle during a playback of a recorded simulation.
- **set_replayer_time_factor**(**self**, **time_factor**=1.0)
When used, the time speed of the reenacted simulation is modified at will. It can be used several times while a playback is in curse.
- **Parameters:**
@@ -511,7 +546,8 @@ Sets the maxixum time a network call is allowed before blocking it and raising a
---
## carla.CollisionEvent
-
Inherited from _[carla.SensorData](#carla.SensorData)_
Class that defines a collision data for sensor.other.collision. The sensor creates one of this for every collision detected which may be many for one simulation step. Learn more about this [here](ref_sensors.md#collision-detector).
+Inherited from _[carla.SensorData](#carla.SensorData)_
+Class that defines a collision data for sensor.other.collision. The sensor creates one of this for every collision detected which may be many for one simulation step. Learn more about this [here](ref_sensors.md#collision-detector).
### Instance Variables
- **actor** (_[carla.Actor](#carla.Actor)_)
@@ -588,7 +624,7 @@ Polarity of the event. __True__ for positive and __False__ for negative.
---
## carla.DVSEventArray
-Class that defines a stream of events in [[carla.DVSEvent](#carla.DVSEvent)](#[carla.DVSEvent](#carla.DVSEvent)). Such stream is an array of arbitrary size depending on the number of events. This class also stores the field of view, the height and width of the image and the timestamp from convenience. Learn more about them [here](ref_sensors.md).
+Class that defines a stream of events in [carla.DVSEvent](#carla.DVSEvent). Such stream is an array of arbitrary size depending on the number of events. This class also stores the field of view, the height and width of the image and the timestamp from convenience. Learn more about them [here](ref_sensors.md).
### Instance Variables
- **fov** (_float – degrees_)
@@ -636,7 +672,7 @@ Draws an arrow from `begin` to `end` pointing in that direction.
- `arrow_size` (_float – meters_) – Size of the tip of the arrow.
- `color` (_[carla.Color](#carla.Color)_) – RGB code to color the object. Red by default.
- `life_time` (_float – seconds_) – Shape's lifespan. By default it only lasts one frame. Set this to 0 for permanent shapes.
-- **draw_box**(**self**, **box**, **rotation**, **thickness**=0.1, **color**=(255,0,0), **life_time**=-1.0)
+- **draw_box**(**self**, **box**, **rotation**, **thickness**=0.1, **color**=(255,0,0), **life_time**=-1.0)
Draws a box, ussually to act for object colliders.
- **Parameters:**
- `box` (_[carla.BoundingBox](#carla.BoundingBox)_) – Object containing a location and the length of a box for every axis.
@@ -659,7 +695,7 @@ Draws a point `location`.
- `size` (_float – meters_) – Density of the point.
- `color` (_[carla.Color](#carla.Color)_) – RGB code to color the object. Red by default.
- `life_time` (_float – seconds_) – Shape's lifespan. By default it only lasts one frame. Set this to 0 for permanent shapes.
-- **draw_string**(**self**, **location**, **text**, **draw_shadow**=False, **color**=(255,0,0), **life_time**=-1.0)
+- **draw_string**(**self**, **location**, **text**, **draw_shadow**=False, **color**=(255,0,0), **life_time**=-1.0)
Draws a string in a given location of the simulation which can only be seen server-side.
- **Parameters:**
- `location` (_[carla.Location](#carla.Location) – meters_) – Spot in the simulation where the text will be centered.
@@ -745,7 +781,8 @@ Height regarding ground level.
---
## carla.GnssMeasurement
-
Inherited from _[carla.SensorData](#carla.SensorData)_
Class that defines the Gnss data registered by a sensor.other.gnss. It essentially reports its position with the position of the sensor and an OpenDRIVE geo-reference.
+Inherited from _[carla.SensorData](#carla.SensorData)_
+Class that defines the Gnss data registered by a sensor.other.gnss. It essentially reports its position with the position of the sensor and an OpenDRIVE geo-reference.
### Instance Variables
- **altitude** (_float – meters_)
@@ -763,7 +800,8 @@ West/East value of a point on the map.
---
## carla.IMUMeasurement
-
Inherited from _[carla.SensorData](#carla.SensorData)_
Class that defines the data registered by a sensor.other.imu, regarding the sensor's transformation according to the current [carla.World](#carla.World). It essentially acts as accelerometer, gyroscope and compass.
+Inherited from _[carla.SensorData](#carla.SensorData)_
+Class that defines the data registered by a sensor.other.imu, regarding the sensor's transformation according to the current [carla.World](#carla.World). It essentially acts as accelerometer, gyroscope and compass.
### Instance Variables
- **accelerometer** (_[carla.Vector3D](#carla.Vector3D) – m/s2_)
@@ -781,7 +819,8 @@ Angular velocity.
---
## carla.Image
-
Inherited from _[carla.SensorData](#carla.SensorData)_
Class that defines an image of 32-bit BGRA colors that will be used as initial data retrieved by camera sensors. There are different camera sensors (currently three, RGB, depth and semantic segmentation) and each of these makes different use for the images. Learn more about them [here](ref_sensors.md).
+Inherited from _[carla.SensorData](#carla.SensorData)_
+Class that defines an image of 32-bit BGRA colors that will be used as initial data retrieved by camera sensors. There are different camera sensors (currently three, RGB, depth and semantic segmentation) and each of these makes different use for the images. Learn more about them [here](ref_sensors.md).
### Instance Variables
- **fov** (_float – degrees_)
@@ -987,6 +1026,8 @@ Type 310.
Type 311.
- **Highway**
Type 330.
+- **DeadEnd**
+Type 357.
- **RecomendedSpeed**
Type 380.
- **RecomendedSpeedEnd**
@@ -1010,7 +1051,8 @@ Traffic rules allow turning either right or left.
---
## carla.LaneInvasionEvent
-
Inherited from _[carla.SensorData](#carla.SensorData)_
Class that defines lanes invasion for sensor.other.lane_invasion. It works only client-side and is dependant on OpenDRIVE to provide reliable information. The sensor creates one of this every time there is a lane invasion, which may be more than once per simulation step. Learn more about this [here](ref_sensors.md#lane-invasion-detector).
+Inherited from _[carla.SensorData](#carla.SensorData)_
+Class that defines lanes invasion for sensor.other.lane_invasion. It works only client-side and is dependant on OpenDRIVE to provide reliable information. The sensor creates one of this every time there is a lane invasion, which may be more than once per simulation step. Learn more about this [here](ref_sensors.md#lane-invasion-detector).
### Instance Variables
- **actor** (_[carla.Actor](#carla.Actor)_)
@@ -1120,7 +1162,8 @@ Computed intensity for this point as a scalar value between [0.0 , 1.0].
---
## carla.LidarMeasurement
-
Inherited from _[carla.SensorData](#carla.SensorData)_
Class that defines the LIDAR data retrieved by a sensor.lidar.ray_cast. This essentially simulates a rotating LIDAR using ray-casting. Learn more about this [here](ref_sensors.md#lidar-raycast-sensor).
+Inherited from _[carla.SensorData](#carla.SensorData)_
+Class that defines the LIDAR data retrieved by a sensor.lidar.ray_cast. This essentially simulates a rotating LIDAR using ray-casting. Learn more about this [here](ref_sensors.md#lidar-raycast-sensor).
### Instance Variables
- **channels** (_int_)
@@ -1351,7 +1394,8 @@ Switch of a light. It is __True__ when the light is on.
---
## carla.Location
-
Inherited from _[carla.Vector3D](#carla.Vector3D)_
Represents a spot in the world.
+Inherited from _[carla.Vector3D](#carla.Vector3D)_
+Represents a spot in the world.
### Instance Variables
- **x** (_float – meters_)
@@ -1374,6 +1418,9 @@ Returns Euclidean distance from this location to another one.
- **Return:** _float – meters_
##### Dunder methods
+- **\__abs__**(**self**)
+Returns a Location with the absolute value of the components x, y and z.
+ - **Return:** _[carla.Location](#carla.Location)_
- **\__eq__**(**self**, **other**=[carla.Location](#carla.Location))
Returns __True__ if both locations are the same point in space.
- **Return:** _bool_
@@ -1432,6 +1479,9 @@ Returns the landmarks of a specific type. Landmarks retrieved using this method
- **Parameters:**
- `type` (_string_) – The type of the landmarks.
- **Return:** _list([carla.Landmark](#carla.Landmark))_
+- **get_crosswalks**(**self**)
+Returns a list of locations with all crosswalk zones in the form of closed polygons. The first point is repeated, symbolizing where the polygon begins and ends.
+ - **Return:** _list([carla.Location](#carla.Location))_
- **get_landmark_group**(**self**, **landmark**)
Returns the landmarks in the same group as the specified landmark (including itself). Returns an empty list if the landmark does not belong to any group.
- **Parameters:**
@@ -1443,7 +1493,7 @@ Returns a list of recommendations made by the creators of the map to be used as
- **get_topology**(**self**)
Returns a list of tuples describing a minimal graph of the topology of the OpenDRIVE file. The tuples contain pairs of waypoints located either at the point a road begins or ends. The first one is the origin and the second one represents another road end that can be reached. This graph can be loaded into [NetworkX](https://networkx.github.io/) to work with. Output could look like this: [(w0, w1), (w0, w2), (w1, w3), (w2, w3), (w0, w4)].
- **Return:** _list(tuple([carla.Waypoint](#carla.Waypoint), [carla.Waypoint](#carla.Waypoint)))_
-- **get_waypoint**(**self**, **location**, **project_to_road**=True, **lane_type**=[carla.LaneType.Driving](#carla.LaneType.Driving))
+- **get_waypoint**(**self**, **location**, **project_to_road**=True, **lane_type**=[carla.LaneType.Driving](#carla.LaneType.Driving))
Returns a waypoint that can be located in an exact location or translated to the center of the nearest lane. Said lane type can be defined using flags such as `LaneType.Driving & LaneType.Shoulder`.
The method will return None if the waypoint is not found, which may happen only when trying to retrieve a waypoint for an exact location. That eases checking if a point is inside a certain road, as otherwise, it will return the corresponding waypoint.
- **Parameters:**
@@ -1485,7 +1535,8 @@ All layers selected.
---
## carla.ObstacleDetectionEvent
-
Inherited from _[carla.SensorData](#carla.SensorData)_
Class that defines the obstacle data for sensor.other.obstacle. Learn more about this [here](ref_sensors.md#obstacle-detector).
+Inherited from _[carla.SensorData](#carla.SensorData)_
+Class that defines the obstacle data for sensor.other.obstacle. Learn more about this [here](ref_sensors.md#obstacle-detector).
### Instance Variables
- **actor** (_[carla.Actor](#carla.Actor)_)
@@ -1523,6 +1574,59 @@ If __True__, Pedestrian navigation will be enabled using Recast tool. For very l
---
+## carla.OpticalFlowImage
+Inherited from _[carla.SensorData](#carla.SensorData)_
+Class that defines an optical flow image of 2-Dimension float (32-bit) vectors representing the optical flow detected in the field of view. The components of the vector represents the displacement of an object in the image plane. Each component outputs values in the normalized range [-2,2] which scales to [-2 size, 2 size] with size being the total resolution in the corresponding component.
+
+### Instance Variables
+- **fov** (_float – degrees_)
+Horizontal field of view of the image.
+- **height** (_int_)
+Image height in pixels.
+- **width** (_int_)
+Image width in pixels.
+- **raw_data** (_bytes_)
+
+### Methods
+
+##### Getters
+- **get_color_coded_flow**(**self**)
+Visualization helper. Converts the optical flow image to an RGB image.
+ - **Return:** _[carla.Image](#carla.Image)_
+
+##### Dunder methods
+- **\__getitem__**(**self**, **pos**=int)
+- **\__iter__**(**self**)
+Iterate over the [carla.OpticalFlowPixel](#carla.OpticalFlowPixel) that form the image.
+- **\__len__**(**self**)
+- **\__setitem__**(**self**, **pos**=int, **color**=[carla.Color](#carla.Color))
+- **\__str__**(**self**)
+
+---
+
+## carla.OpticalFlowPixel
+Class that defines a 2 dimensional vector representing an optical flow pixel.
+
+### Instance Variables
+- **x** (_float_)
+Optical flow in the x component.
+- **y** (_float_)
+Optical flow in the y component.
+
+### Methods
+- **\__init__**(**self**, **x**=0, **y**=0)
+Initializes the Optical Flow Pixel. Zero by default.
+ - **Parameters:**
+ - `x` (_float_)
+ - `y` (_float_)
+
+##### Dunder methods
+- **\__eq__**(**self**, **other**=[carla.OpticalFlowPixel](#carla.OpticalFlowPixel))
+- **\__ne__**(**self**, **other**=[carla.OpticalFlowPixel](#carla.OpticalFlowPixel))
+- **\__str__**(**self**)
+
+---
+
## carla.Osm2Odr
Class that converts an OpenStreetMap map to OpenDRIVE format, so that it can be loaded in CARLA. Find out more about this feature in the [docs](tuto_G_openstreetmap.md).
@@ -1550,6 +1654,26 @@ Offset in the Y axis. Default value is __0.0__.
Width of the lanes described in the resulting XODR map. Default value is __4.0__.
- **elevation_layer_height** (_float – meters_)
Defines the height separating two different [OpenStreetMap layers](https://wiki.openstreetmap.org/wiki/Key:layer). Default value is __0.0__.
+- **center_map** (_bool_)
+When this option is enabled, the geometry of the map will be displaced so that the origin of coordinates matches the center of the bounding box of the entire road map.
+- **proj_string** (_str_)
+Defines the [proj4](https://github.com/OSGeo/proj.4) string that will be used to compute the projection from geocoordinates to cartesian coordinates. This string will be written in the resulting OpenDRIVE unless the options `use_offsets` or `center_map` are enabled as these options override some of the definitions in the string.
+- **generate_traffic_lights** (_bool_)
+Indicates wether to generate traffic light data in the OpenDRIVE. Road types defined by `set_traffic_light_excluded_way_types(way_types)` will not generate traffic lights.
+- **all_junctions_with_traffic_lights** (_bool_)
+When disabled, the converter will generate traffic light data from the OpenStreetMaps data only. When enabled, all junctions will generate traffic lights.
+
+### Methods
+
+##### Setters
+- **set_osm_way_types**(**self**, **way_types**)
+Defines the OpenStreetMaps road types that will be imported to OpenDRIVE. By default the road types imported are `motorway, motorway_link, trunk, trunk_link, primary, primary_link, secondary, secondary_link, tertiary, tertiary_link, unclassified, residential`. For a full list of road types check [here](https://wiki.openstreetmap.org/wiki/Main_Page).
+ - **Parameters:**
+ - `way_types` (_list(str)_) – The list of road types.
+- **set_traffic_light_excluded_way_types**(**self**, **way_types**)
+Defines the OpenStreetMaps road types that will not generate traffic lights even if `generate_traffic_lights` is enabled. By default the road types excluded are `motorway_link, primary_link, secondary_link, tertiary_link`.
+ - **Parameters:**
+ - `way_types` (_list(str)_) – The list of road types.
---
@@ -1574,7 +1698,8 @@ The velocity of the detected object towards the sensor.
---
## carla.RadarMeasurement
-
Inherited from _[carla.SensorData](#carla.SensorData)_
Class that defines and gathers the measures registered by a sensor.other.radar, representing a wall of points in front of the sensor with a distance, angle and velocity in relation to it. The data consists of a [carla.RadarDetection](#carla.RadarDetection) array. Learn more about this [here](ref_sensors.md#radar-sensor).
+Inherited from _[carla.SensorData](#carla.SensorData)_
+Class that defines and gathers the measures registered by a sensor.other.radar, representing a wall of points in front of the sensor with a distance, angle and velocity in relation to it. The data consists of a [carla.RadarDetection](#carla.RadarDetection) array. Learn more about this [here](ref_sensors.md#radar-sensor).
### Instance Variables
- **raw_data** (_bytes_)
@@ -1740,7 +1865,8 @@ Enum declaration used in [carla.RssSensor](#carla.RssSensor) to set the log leve
---
## carla.RssResponse
-
Inherited from _[carla.SensorData](#carla.SensorData)_
Class that contains the output of a [carla.RssSensor](#carla.RssSensor). This is the result of the RSS calculations performed for the parent vehicle of the sensor.
+Inherited from _[carla.SensorData](#carla.SensorData)_
+Class that contains the output of a [carla.RssSensor](#carla.RssSensor). This is the result of the RSS calculations performed for the parent vehicle of the sensor.
A [carla.RssRestrictor](#carla.RssRestrictor) will use the data to modify the [carla.VehicleControl](#carla.VehicleControl) of the vehicle.
@@ -1792,7 +1918,8 @@ Disables the _stay on road_ feature.
---
## carla.RssSensor
-
Inherited from _[carla.Sensor](#carla.Sensor)_
This sensor works a bit differently than the rest. Take look at the [specific documentation](adv_rss.md), and the [rss sensor reference](ref_sensors.md#rss-sensor) to gain full understanding of it.
+Inherited from _[carla.Sensor](#carla.Sensor)_
+This sensor works a bit differently than the rest. Take look at the [specific documentation](adv_rss.md), and the [rss sensor reference](ref_sensors.md#rss-sensor) to gain full understanding of it.
The RSS sensor uses world information, and a [RSS library](https://github.com/intel/ad-rss-lib) to make safety checks on a vehicle. The output retrieved by the sensor is a [carla.RssResponse](#carla.RssResponse). This will be used by a [carla.RssRestrictor](#carla.RssRestrictor) to modify a [carla.VehicleControl](#carla.VehicleControl) before applying it to a vehicle.
@@ -1858,7 +1985,8 @@ ID of the actor hit by the ray.
---
## carla.SemanticLidarMeasurement
-
Inherited from _[carla.SensorData](#carla.SensorData)_
Class that defines the semantic LIDAR data retrieved by a sensor.lidar.ray_cast_semantic. This essentially simulates a rotating LIDAR using ray-casting. Learn more about this [here](ref_sensors.md#semanticlidar-raycast-sensor).
+Inherited from _[carla.SensorData](#carla.SensorData)_
+Class that defines the semantic LIDAR data retrieved by a sensor.lidar.ray_cast_semantic. This essentially simulates a rotating LIDAR using ray-casting. Learn more about this [here](ref_sensors.md#semanticlidar-raycast-sensor).
### Instance Variables
- **channels** (_int_)
@@ -1891,7 +2019,8 @@ Iterate over the [carla.SemanticLidarDetection](#carla.SemanticLidarDetection) r
---
## carla.Sensor
-
Inherited from _[carla.Actor](#carla.Actor)_
Sensors compound a specific family of actors quite diverse and unique. They are normally spawned as attachment/sons of a vehicle (take a look at [carla.World](#carla.World) to learn about actor spawning). Sensors are thoroughly designed to retrieve different types of data that they are listening to. The data they receive is shaped as different subclasses inherited from [carla.SensorData](#carla.SensorData) (depending on the sensor).
+Inherited from _[carla.Actor](#carla.Actor)_
+Sensors compound a specific family of actors quite diverse and unique. They are normally spawned as attachment/sons of a vehicle (take a look at [carla.World](#carla.World) to learn about actor spawning). Sensors are thoroughly designed to retrieve different types of data that they are listening to. The data they receive is shaped as different subclasses inherited from [carla.SensorData](#carla.SensorData) (depending on the sensor).
Most sensors can be divided in two groups: those receiving data on every tick (cameras, point clouds and some specific sensors) and those who only receive under certain circumstances (trigger detectors). CARLA provides a specific set of sensors and their blueprint can be found in [carla.BlueprintLibrary](#carla.BlueprintLibrary). All the information on their preferences and settlement can be found [here](ref_sensors.md), but the list of those available in CARLA so far goes as follow.
Receive data on every tick.
@@ -1914,7 +2043,7 @@ Iterate over the [carla.SemanticLidarDetection](#carla.SemanticLidarDetection) r
When True the sensor will be waiting for data.
### Methods
-- **listen**(**self**, **callback**)
+- **listen**(**self**, **callback**)
The function the sensor will be calling to every time a new measurement is received. This function needs for an argument containing an object type [carla.SensorData](#carla.SensorData) to work with.
- **Parameters:**
- `callback` (_function_) – The called function with one argument containing the sensor data.
@@ -1978,7 +2107,8 @@ Time register of the frame at which this measurement was taken given by the OS i
---
## carla.TrafficLight
-
Inherited from _[carla.TrafficSign](#carla.TrafficSign)_
A traffic light actor, considered a specific type of traffic sign. As traffic lights will mostly appear at junctions, they belong to a group which contains the different traffic lights in it. Inside the group, traffic lights are differenciated by their pole index.
+Inherited from _[carla.TrafficSign](#carla.TrafficSign)_
+A traffic light actor, considered a specific type of traffic sign. As traffic lights will mostly appear at junctions, they belong to a group which contains the different traffic lights in it. Inside the group, traffic lights are differenciated by their pole index.
Within a group the state of traffic lights is changed in a cyclic pattern: one index is chosen and it spends a few seconds in green, yellow and eventually red. The rest of the traffic lights remain frozen in red this whole time, meaning that there is a gap in the last seconds of the cycle where all the traffic lights are red. However, the state of a traffic light can be changed manually.
@@ -2000,6 +2130,9 @@ Resets the state of the traffic lights of the group to the initial state at the
_
##### Getters
+- **get_affected_lane_waypoints**(**self**)
+Returns a list of waypoints indicating the positions and lanes where the traffic light is having an effect.
+ - **Return:** _list([carla.Waypoint](#carla.Waypoint))_
- **get_elapsed_time**(**self**)
The client returns the time in seconds since current light state started according to last tick. The method does not call the simulator.
- **Return:** _float – seconds_
@@ -2012,6 +2145,12 @@ Returns all traffic lights in the group this one belongs to.
- **Return:** _list([carla.TrafficLight](#carla.TrafficLight))_
- **Note:** _This method calls the simulator.
_
+- **get_light_boxes**(**self**)
+Returns a list of the bounding boxes encapsulating each light box of the traffic light.
+ - **Return:** _list([carla.BoundingBox](#carla.BoundingBox))_
+- **get_opendrive_id**(**self**)
+Returns the OpenDRIVE id of this traffic light.
+ - **Return:** _str_
- **get_pole_index**(**self**)
Returns the index of the pole that identifies it as part of the traffic light group of a junction.
- **Return:** _int_
@@ -2023,6 +2162,9 @@ The client returns the time set for the traffic light to be red, according to la
The client returns the state of the traffic light according to last tick. The method does not call the simulator.
- **Return:** _[carla.TrafficLightState](#carla.TrafficLightState)_
- **Setter:** _[carla.TrafficLight.set_state](#carla.TrafficLight.set_state)_
+- **get_stop_waypoints**(**self**)
+Returns a list of waypoints indicating the stop position for the traffic light. These waypoints are computed from the trigger boxes of the traffic light that indicate where a vehicle should stop.
+ - **Return:** _list([carla.Waypoint](#carla.Waypoint))_
- **get_yellow_time**(**self**)
The client returns the time set for the traffic light to be yellow, according to last tick. The method does not call the simulator.
- **Return:** _float – seconds_
@@ -2038,7 +2180,7 @@ Sets a given time for the red state to be active.
- **Parameters:**
- `red_time` (_float – seconds_)
- **Getter:** _[carla.TrafficLight.get_red_time](#carla.TrafficLight.get_red_time)_
-- **set_state**(**self**, **state**)
+- **set_state**(**self**, **state**)
Sets a given state to a traffic light actor.
- **Parameters:**
- `state` (_[carla.TrafficLightState](#carla.TrafficLightState)_)
@@ -2117,8 +2259,6 @@ During the collision detection stage, which runs every frame, this method sets a
- **Parameters:**
- `actor` (_[carla.Actor](#carla.Actor)_) – The vehicle that is going to ignore walkers on scene.
- `perc` (_float_) – Between 0 and 100. Amount of times collisions will be ignored.
-- **reset_traffic_lights**(**self**)
-Resets every traffic light in the map to its initial state.
- **vehicle_percentage_speed_difference**(**self**, **actor**, **percentage**)
Sets the difference the vehicle's intended speed and its current speed limit. Speed limits can be exceeded by setting the `perc` to a negative value.
Default is 30. Exceeding a speed limit can be done using negative percentages.
@@ -2132,18 +2272,25 @@ Returns the port where the Traffic Manager is connected. If the object is a TM-C
- **Return:** _uint16_
##### Setters
+- **set_boundaries_respawn_dormant_vehicles**(**self**, **lower_bound**=25.0, **upper_bound**=actor_active_distance)
+Sets the upper and lower boundaries for dormant actors to be respawned near the hero vehicle.
+ - **Parameters:**
+ - `lower_bound` (_float_) – The minimum distance in meters from the hero vehicle that a dormant actor will be respawned.
+ - `upper_bound` (_float_) – The maximum distance in meters from the hero vehicle that a dormant actor will be respawned.
+ - **Warning:** _The `upper_bound` cannot be higher than the `actor_active_distance`. The `lower_bound` cannot be less than 25.
+_
- **set_global_distance_to_leading_vehicle**(**self**, **distance**)
Sets the minimum distance in meters that vehicles have to keep with the rest. The distance is in meters and will affect the minimum moving distance. It is computed from center to center of the vehicle objects.
- **Parameters:**
- `distance` (_float – meters_) – Meters between vehicles.
-- **set_hybrid_mode_radius**(**self**, **r**=70.0)
-With hybrid physics on, changes the radius of the area of influence where physics are enabled.
- - **Parameters:**
- - `r` (_float – meters_) – New radius where physics are enabled.
- **set_hybrid_physics_mode**(**self**, **enabled**=False)
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:**
- `enabled` (_bool_) – If __True__, enables the hybrid physics.
+- **set_hybrid_physics_radius**(**self**, **r**=50.0)
+With hybrid physics on, changes the radius of the area of influence where physics are enabled.
+ - **Parameters:**
+ - `r` (_float – meters_) – New radius where physics are enabled.
- **set_osm_mode**(**self**, **mode_switch**=True)
Enables or disables the OSM mode. This mode allows the user to run TM in a map created with the [OSM feature](tuto_G_openstreetmap.md). These maps allow having dead-end streets. Normally, if vehicles cannot find the next waypoint, TM crashes. If OSM mode is enabled, it will show a warning, and destroy vehicles when necessary.
- **Parameters:**
@@ -2157,6 +2304,10 @@ During the localization stage, this method sets a percent chance that vehicle wi
Sets a specific random seed for the Traffic Manager, thereby setting it to be deterministic.
- **Parameters:**
- `value` (_int_) – Seed value for the random number generation of the Traffic Manager.
+- **set_respawn_dormant_vehicles**(**self**, **mode_switch**=False)
+If __True__, vehicles in large maps will respawn near the hero vehicle when they become dormant. Otherwise, they will stay dormant until they are within `actor_active_distance` of the hero vehicle again.
+ - **Parameters:**
+ - `mode_switch` (_bool_)
- **set_synchronous_mode**(**self**, **mode_switch**=True)
Sets the Traffic Manager to [synchronous mode](adv_traffic_manager.md#synchronous-mode). In a [multiclient situation](adv_traffic_manager.md#multiclient), only the TM-Server can tick. Similarly, in a [multiTM situation](adv_traffic_manager.md#multitm), only one TM-Server must tick. Use this method in the client that does the world tick, and right after setting the world to synchronous mode, to set which TM will be the master while in sync.
- **Parameters:**
@@ -2167,7 +2318,8 @@ _
---
## carla.TrafficSign
-
Inherited from _[carla.Actor](#carla.Actor)_
Traffic signs appearing in the simulation except for traffic lights. These have their own class inherited from this in [carla.TrafficLight](#carla.TrafficLight). Right now, speed signs, stops and yields are mainly the ones implemented, but many others are borne in mind.
+Inherited from _[carla.Actor](#carla.Actor)_
+Traffic signs appearing in the simulation except for traffic lights. These have their own class inherited from this in [carla.TrafficLight](#carla.TrafficLight). Right now, speed signs, stops and yields are mainly the ones implemented, but many others are borne in mind.
### Instance Variables
- **trigger_volume**
@@ -2275,6 +2427,9 @@ Z-axis value.
- `z` (_float_)
##### Dunder methods
+- **\__abs__**(**self**)
+Returns a Vector3D with the absolute value of the components x, y and z.
+ - **Return:** _[carla.Vector3D](#carla.Vector3D)_
- **\__add__**(**self**, **other**=[carla.Vector3D](#carla.Vector3D))
- **\__eq__**(**self**, **other**=[carla.Vector3D](#carla.Vector3D))
Returns __True__ if values for every axis are equal.
@@ -2292,7 +2447,8 @@ Returns the axis values for the vector parsed as string.
---
## carla.Vehicle
-
Inherited from _[carla.Actor](#carla.Actor)_
One of the most important group of actors in CARLA. These include any type of vehicle from cars to trucks, motorbikes, vans, bycicles and also official vehicles such as police cars. A wide set of these actors is provided in [carla.BlueprintLibrary](#carla.BlueprintLibrary) to facilitate differente requirements. Vehicles can be either manually controlled or set to an autopilot mode that will be conducted client-side by the traffic manager.
+Inherited from _[carla.Actor](#carla.Actor)_
+One of the most important group of actors in CARLA. These include any type of vehicle from cars to trucks, motorbikes, vans, bycicles and also official vehicles such as police cars. A wide set of these actors is provided in [carla.BlueprintLibrary](#carla.BlueprintLibrary) to facilitate differente requirements. Vehicles can be either manually controlled or set to an autopilot mode that will be conducted client-side by the traffic manager.
### Instance Variables
- **bounding_box** (_[carla.BoundingBox](#carla.BoundingBox)_)
@@ -2340,6 +2496,13 @@ Retrieves the traffic light actor affecting this vehicle (if any) according to l
- **get_traffic_light_state**(**self**)
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 green.
- **Return:** _[carla.TrafficLightState](#carla.TrafficLightState)_
+- **get_wheel_steer_angle**(**self**, **wheel_location**)
+Returns the physics angle in degrees of a vehicle's wheel.
+ - **Parameters:**
+ - `wheel_location` (_[carla.VehicleWheelLocation](#carla.VehicleWheelLocation)_)
+ - **Return:** _float_
+ - **Note:** _Returns the angle based on the physics of the wheel, not the visual angle.
+_
##### Setters
- **set_autopilot**(**self**, **enabled**=True, **port**=8000)
@@ -2352,6 +2515,13 @@ Sets the light state of a vehicle using a flag that represents the lights that a
- **Parameters:**
- `light_state` (_[carla.VehicleLightState](#carla.VehicleLightState)_)
- **Getter:** _[carla.Vehicle.get_light_state](#carla.Vehicle.get_light_state)_
+- **set_wheel_steer_direction**(**self**, **wheel_location**, **angle_in_deg**)
+Sets the angle of a vehicle's wheel visually.
+ - **Parameters:**
+ - `wheel_location` (_[carla.VehicleWheelLocation](#carla.VehicleWheelLocation)_)
+ - `angle_in_deg` (_float_)
+ - **Warning:** _Does not affect the physics of the vehicle.
+_
##### Dunder methods
- **\__str__**(**self**)
@@ -2459,7 +2629,7 @@ Enable the use of sweep for wheel collision. By default, it is disabled and it u
List of wheel physics objects. This list should have 4 elements, where index 0 corresponds to the front left wheel, index 1 corresponds to the front right wheel, index 2 corresponds to the back left wheel and index 3 corresponds to the back right wheel. For 2 wheeled vehicles, set the same values for both front and back wheels.
### Methods
-- **\__init__**(**self**, **torque_curve**=[[0.0, 500.0], [5000.0, 500.0]], **max_rpm**=5000.0, **moi**=1.0, **damping_rate_full_throttle**=0.15, **damping_rate_zero_throttle_clutch_engaged**=2.0, **damping_rate_zero_throttle_clutch_disengaged**=0.35, **use_gear_autobox**=True, **gear_switch_time**=0.5, **clutch_strength**=10.0, **final_ratio**=4.0, **forward_gears**=list(), **mass**=1000.0, **drag_coefficient**=0.3, **center_of_mass**=[0.0, 0.0, 0.0], **steering_curve**=[[0.0, 1.0], [10.0, 0.5]], **wheels**=list())
+- **\__init__**(**self**, **torque_curve**=[[0.0, 500.0], [5000.0, 500.0]], **max_rpm**=5000.0, **moi**=1.0, **damping_rate_full_throttle**=0.15, **damping_rate_zero_throttle_clutch_engaged**=2.0, **damping_rate_zero_throttle_clutch_disengaged**=0.35, **use_gear_autobox**=True, **gear_switch_time**=0.5, **clutch_strength**=10.0, **final_ratio**=4.0, **forward_gears**=list(), **drag_coefficient**=0.3, **center_of_mass**=[0.0, 0.0, 0.0], **steering_curve**=[[0.0, 1.0], [10.0, 0.5]], **wheels**=list(), **use_sweep_wheel_collision**=False, **mass**=1000.0)
VehiclePhysicsControl constructor.
- **Parameters:**
- `torque_curve` (_list([carla.Vector2D](#carla.Vector2D))_)
@@ -2477,6 +2647,8 @@ VehiclePhysicsControl constructor.
- `center_of_mass` (_[carla.Vector3D](#carla.Vector3D)_)
- `steering_curve` (_[carla.Vector2D](#carla.Vector2D)_)
- `wheels` (_list([carla.WheelPhysicsControl](#carla.WheelPhysicsControl))_)
+ - `use_sweep_wheel_collision` (_bool_)
+ - `mass` (_float – kilograms_)
##### Dunder methods
- **\__eq__**(**self**, **other**=[carla.VehiclePhysicsControl](#carla.VehiclePhysicsControl))
@@ -2485,8 +2657,28 @@ VehiclePhysicsControl constructor.
---
+## carla.VehicleWheelLocation
+`enum` representing the position of each wheel on a vehicle. Used to identify the target wheel when setting an angle in [carla.Vehicle.set_wheel_steer_direction](#carla.Vehicle.set_wheel_steer_direction) or [carla.Vehicle.get_wheel_steer_angle](#carla.Vehicle.get_wheel_steer_angle).
+
+### Instance Variables
+- **FL_Wheel**
+Front left wheel of a 4 wheeled vehicle.
+- **FR_Wheel**
+Front right wheel of a 4 wheeled vehicle.
+- **BL_Wheel**
+Back left wheel of a 4 wheeled vehicle.
+- **BR_Wheel**
+Back right wheel of a 4 wheeled vehicle.
+- **Front_Wheel**
+Front wheel of a 2 wheeled vehicle.
+- **Back_Wheel**
+Back wheel of a 2 wheeled vehicle.
+
+---
+
## carla.Walker
-
Inherited from _[carla.Actor](#carla.Actor)_
This class inherits from the [carla.Actor](#carla.Actor) and defines pedestrians in the simulation. Walkers are a special type of actor that can be controlled either by an AI ([carla.WalkerAIController](#carla.WalkerAIController)) or manually via script, using a series of [carla.WalkerControl](#carla.WalkerControl) to move these and their skeletons.
+Inherited from _[carla.Actor](#carla.Actor)_
+This class inherits from the [carla.Actor](#carla.Actor) and defines pedestrians in the simulation. Walkers are a special type of actor that can be controlled either by an AI ([carla.WalkerAIController](#carla.WalkerAIController)) or manually via script, using a series of [carla.WalkerControl](#carla.WalkerControl) to move these and their skeletons.
### Instance Variables
- **bounding_box** (_[carla.BoundingBox](#carla.BoundingBox)_)
@@ -2513,7 +2705,8 @@ The client returns the control applied to this walker during last tick. The meth
---
## carla.WalkerAIController
-
Inherited from _[carla.Actor](#carla.Actor)_
Class that conducts AI control for a walker. The controllers are defined as actors, but they are quite different from the rest. They need to be attached to a parent actor during their creation, which is the walker they will be controlling (take a look at [carla.World](#carla.World) if you are yet to learn on how to spawn actors). They also need for a special blueprint (already defined in [carla.BlueprintLibrary](#carla.BlueprintLibrary) as "controller.ai.walker"). This is an empty blueprint, as the AI controller will be invisible in the simulation but will follow its parent around to dictate every step of the way.
+Inherited from _[carla.Actor](#carla.Actor)_
+Class that conducts AI control for a walker. The controllers are defined as actors, but they are quite different from the rest. They need to be attached to a parent actor during their creation, which is the walker they will be controlling (take a look at [carla.World](#carla.World) if you are yet to learn on how to spawn actors). They also need for a special blueprint (already defined in [carla.BlueprintLibrary](#carla.BlueprintLibrary) as "controller.ai.walker"). This is an empty blueprint, as the AI controller will be invisible in the simulation but will follow its parent around to dictate every step of the way.
### Methods
- **go_to_location**(**self**, **destination**)
@@ -2522,7 +2715,7 @@ Sets the destination that the pedestrian will reach.
- `destination` (_[carla.Location](#carla.Location) – meters_)
- **start**(**self**)
Enables AI control for its parent walker.
-- **stop**(**self**)
+- **stop**(**self**)
Disables AI control for its parent walker.
##### Setters
@@ -2692,9 +2885,15 @@ Fog start distance. Values range from 0 to infinite.
Wetness intensity. It only affects the RGB camera sensor. Values range from 0 to 100.
- **fog_falloff** (_float_)
Density of the fog (as in specific mass) from 0 to infinity. The bigger the value, the more dense and heavy it will be, and the fog will reach smaller heights. Corresponds to Fog Height Falloff in the UE docs. If the value is 0, the fog will be lighter than air, and will cover the whole scene. A value of 1 is approximately as dense as the air, and reaches normal-sized buildings. For values greater than 5, the air will be so dense that it will be compressed on ground level.
+- **scattering_intensity** (_float_)
+Controls how much the light will contribute to volumetric fog. When set to 0, there is no contribution.
+- **mie_scattering_scale** (_float_)
+Controls interaction of light with large particles like pollen or air pollution resulting in a hazy sky with halos around the light sources. When set to 0, there is no contribution.
+- **rayleigh_scattering_scale** (_float_)
+Controls interaction of light with small particles like air molecules. Dependent on light wavelength, resulting in a blue sky in the day or red sky in the evening.
### Methods
-- **\__init__**(**self**, **cloudiness**=0.0, **precipitation**=0.0, **precipitation_deposits**=0.0, **wind_intensity**=0.0, **sun_azimuth_angle**=0.0, **sun_altitude_angle**=0.0, **fog_density**=0.0, **fog_distance**=0.0, **wetness**=0.0, **fog_falloff**=0.2)
+- **\__init__**(**self**, **cloudiness**=0.0, **precipitation**=0.0, **precipitation_deposits**=0.0, **wind_intensity**=0.0, **sun_azimuth_angle**=0.0, **sun_altitude_angle**=0.0, **fog_density**=0.0, **fog_distance**=0.0, **wetness**=0.0, **fog_falloff**=0.0, **scattering_intensity**=0.0, **mie_scattering_scale**=0.0, **rayleigh_scattering_scale**=0.0331)
Method to initialize an object defining weather conditions. This class has some presets for different noon and sunset conditions listed in a note below.
- **Parameters:**
- `cloudiness` (_float_) – 0 is a clear sky, 100 complete overcast.
@@ -2707,6 +2906,9 @@ Method to initialize an object defining weather conditions. This class has some
- `fog_distance` (_float – meters_) – Distance where the fog starts in meters.
- `wetness` (_float_) – Humidity percentages of the road, from 0 to 100.
- `fog_falloff` (_float_) – Density (specific mass) of the fog, from 0 to infinity.
+ - `scattering_intensity` (_float_) – Controls how much the light will contribute to volumetric fog. When set to 0, there is no contribution.
+ - `mie_scattering_scale` (_float_) – Controls interaction of light with large particles like pollen or air pollution resulting in a hazy sky with halos around the light sources. When set to 0, there is no contribution.
+ - `rayleigh_scattering_scale` (_float_) – Controls interaction of light with small particles like air molecules. Dependent on light wavelength, resulting in a blue sky in the day or red sky in the evening.
- **Note:** _ClearNoon, CloudyNoon, WetNoon, WetCloudyNoon, SoftRainNoon, MidRainyNoon, HardRainNoon, ClearSunset, CloudySunset, WetSunset, WetCloudySunset, SoftRainSunset, MidRainSunset, HardRainSunset.
_
@@ -2739,6 +2941,12 @@ Maximum brake torque.
Maximum handbrake torque.
- **position** (_[carla.Vector3D](#carla.Vector3D)_)
World position of the wheel. This is a read-only parameter.
+- **long_stiff_value** (_float – kg per radian_)
+Tire longitudinal stiffness per unit gravitational acceleration. Each vehicle has a custom value.
+- **lat_stiff_max_load** (_float_)
+Maximum normalized tire load at which the tire can deliver no more lateral stiffness no matter how much extra load is applied to the tire. Each vehicle has a custom value.
+- **lat_stiff_value** (_float_)
+Maximum stiffness per unit of lateral slip. Each vehicle has a custom value.
### Methods
- **\__init__**(**self**, **tire_friction**=2.0, **damping_rate**=0.25, **max_steer_angle**=70.0, **radius**=30.0, **max_brake_torque**=1500.0, **max_handbrake_torque**=3000.0, **position**=(0.0,0.0,0.0))
@@ -2781,7 +2989,7 @@ Casts a ray from the specified initial_location to final_location. The function
- `initial_location` (_[carla.Location](#carla.Location)_) – The initial position of the ray.
- `final_location` (_[carla.Location](#carla.Location)_) – The final position of the ray.
- **Return:** _list([carla.LabelledPoint](#carla.LabelledPoint))_
-- **enable_environment_objects**(**self**, **env_objects_ids**, **enable**)
+- **enable_environment_objects**(**self**, **env_objects_ids**, **enable**)
Enable or disable a set of EnvironmentObject identified by their id. These objects will appear or disappear from the level.
- **Parameters:**
- `env_objects_ids` (_set(int)_) – Set of EnvironmentObject ids to change.
@@ -2796,11 +3004,11 @@ Projects the specified point downwards in the scene. The functions casts a ray f
- `location` (_[carla.Location](#carla.Location)_) – The point to be projected.
- `search_distance` (_float_) – The maximum distance to perform the projection.
- **Return:** _[carla.LabelledPoint](#carla.LabelledPoint)_
-- **load_map_layer**(**self**, **map_layers**)
+- **load_map_layer**(**self**, **map_layers**)
Loads the selected layers to the level. If the layer is already loaded the call has no effect.
- **Parameters:**
- `map_layers` (_[carla.MapLayer](#carla.MapLayer)_) – Mask of level layers to be loaded.
- - **Warning:** _This only affects "Opt" maps._
+ - **Warning:** _This only affects "Opt" maps. The minimum layout includes roads, sidewalks, traffic lights and traffic signs._
- **on_tick**(**self**, **callback**)
This method is used in [__asynchronous__ mode](https://[carla.readthedocs.io](#carla.readthedocs.io)/en/latest/adv_synchrony_timestep/). It starts callbacks from the client for the function defined as `callback`, and returns the ID of the callback. The function will be called everytime the server ticks. It requires a [carla.WorldSnapshot](#carla.WorldSnapshot) as argument, which can be retrieved from __wait_for_tick()__. Use __remove_on_tick()__ to stop the callbacks.
- **Parameters:**
@@ -2819,7 +3027,7 @@ Stops the callback for `callback_id` started with __on_tic
- `callback_id` (_callback_) – The callback to be removed. The ID is returned when creating the callback.
- **reset_all_traffic_lights**(**self**)
Resets the cycle of all traffic lights in the map to the initial state.
-- **spawn_actor**(**self**, **blueprint**, **transform**, **attach_to**=None, **attachment**=Rigid)
+- **spawn_actor**(**self**, **blueprint**, **transform**, **attach_to**=None, **attachment**=Rigid)
The method will create, return and spawn an actor into the world. The actor will need an available blueprint to be created and a transform (location and rotation). It can also be attached to a parent with a certain attachment type.
- **Parameters:**
- `blueprint` (_[carla.ActorBlueprint](#carla.ActorBlueprint)_) – The reference from which the actor will be created.
@@ -2842,11 +3050,11 @@ Same as __spawn_actor()__ but returns None o
- `attach_to` (_[carla.Actor](#carla.Actor)_) – The parent object that the spawned actor will follow around.
- `attachment` (_[carla.AttachmentType](#carla.AttachmentType)_) – Determines how fixed and rigorous should be the changes in position according to its parent object.
- **Return:** _[carla.Actor](#carla.Actor)_
-- **unload_map_layer**(**self**, **map_layers**)
+- **unload_map_layer**(**self**, **map_layers**)
Unloads the selected layers to the level. If the layer is already unloaded the call has no effect.
- **Parameters:**
- `map_layers` (_[carla.MapLayer](#carla.MapLayer)_) – Mask of level layers to be unloaded.
- - **Warning:** _This only affects "Opt" maps._
+ - **Warning:** _This only affects "Opt" maps. The minimum layout includes roads, sidewalks, traffic lights and traffic signs._
- **wait_for_tick**(**self**, **seconds**=10.0)
This method is used in [__asynchronous__ mode](https://[carla.readthedocs.io](#carla.readthedocs.io)/en/latest/adv_synchrony_timestep/). It makes the client wait for a server tick. When the next frame is computed, the server will tick and return a snapshot describing the new state of the world.
- **Parameters:**
@@ -2886,7 +3094,7 @@ Asks the server for the XODR containing the map file, and returns this parsed as
- **Warning:** _This method does call the simulation. It is expensive, and should only be called once.
_
- **get_random_location_from_navigation**(**self**)
-This can only be used with walkers. It retrieves a random location to be used as a destination using the __go_to_location()__ method in [carla.WalkerAIController](#carla.WalkerAIController). This location will be part of a sidewalk. Roads, crosswalks and grass zones are excluded. The method does not take into consideration locations of existing actors so if a collision happens when trying to spawn an actor, it will return an error. Take a look at [`spawn_npc.py`](https://github.com/carla-simulator/carla/blob/e73ad54d182e743b50690ca00f1709b08b16528c/PythonAPI/examples/spawn_npc.py#L179) for an example.
+This can only be used with walkers. It retrieves a random location to be used as a destination using the __go_to_location()__ method in [carla.WalkerAIController](#carla.WalkerAIController). This location will be part of a sidewalk. Roads, crosswalks and grass zones are excluded. The method does not take into consideration locations of existing actors so if a collision happens when trying to spawn an actor, it will return an error. Take a look at [`generate_traffic.py`](https://github.com/carla-simulator/carla/blob/master/PythonAPI/examples/generate_traffic.py) for an example.
- **Return:** _[carla.Location](#carla.Location)_
- **get_settings**(**self**)
Returns an object containing some data about the simulation such as synchrony between client and server or rendering mode.
@@ -2894,7 +3102,7 @@ Returns an object containing some data about the simulation such as synchrony be
- **get_snapshot**(**self**)
Returns a snapshot of the world at a certain moment comprising all the information about the actors.
- **Return:** _[carla.WorldSnapshot](#carla.WorldSnapshot)_
-- **get_spectator**(**self**)
+- **get_spectator**(**self**)
Returns the spectator actor. The spectator is a special type of actor created by Unreal Engine, usually with ID=0, that acts as a camera and controls the view in the simulator window.
- **Return:** _[carla.Actor](#carla.Actor)_
- **get_traffic_light**(**self**, **landmark**)
@@ -2902,6 +3110,22 @@ Provided a landmark, returns the traffic light object it describes.
- **Parameters:**
- `landmark` (_[carla.Landmark](#carla.Landmark)_) – The landmark object describing a traffic light.
- **Return:** _[carla.TrafficLight](#carla.TrafficLight)_
+- **get_traffic_light_from_opendrive_id**(**self**, **traffic_light_id**)
+Returns the traffic light actor corresponding to the indicated OpenDRIVE id.
+ - **Parameters:**
+ - `traffic_light_id` (_str_) – The OpenDRIVE id.
+ - **Return:** _[carla.TrafficLight](#carla.TrafficLight)_
+- **get_traffic_lights_from_waypoint**(**self**, **waypoint**, **distance**)
+This function performs a search along the road in front of the specified waypoint and returns a list of traffic light actors found in the specified search distance.
+ - **Parameters:**
+ - `waypoint` (_[carla.Waypoint](#carla.Waypoint)_) – The input waypoint.
+ - `distance` (_float_) – Search distance.
+ - **Return:** _list([carla.TrafficLight](#carla.TrafficLight))_
+- **get_traffic_lights_in_junction**(**self**, **junction_id**)
+Returns the list of traffic light actors affecting the junction indicated in `junction_id`.
+ - **Parameters:**
+ - `junction_id` (_int_) – The id of the junction.
+ - **Return:** _list([carla.TrafficLight](#carla.TrafficLight))_
- **get_traffic_sign**(**self**, **landmark**)
Provided a landmark, returns the traffic sign object it describes.
- **Parameters:**
@@ -2916,6 +3140,11 @@ Retrieves an object containing weather parameters currently active in the simula
- **Setter:** _[carla.World.set_weather](#carla.World.set_weather)_
##### Setters
+- **set_pedestrians_cross_factor**(**self**, **percentage**)
+ - **Parameters:**
+ - `percentage` (_float_) – Sets the percentage of pedestrians that can walk on the road or cross at any point on the road. Value should be between `0.0` and `1.0`. For example, a value of `0.1` would allow 10% of pedestrians to walk on the road. __Default is `0.0`__.
+ - **Note:** _Should be set before pedestrians are spawned.
+_
- **set_weather**(**self**, **weather**)
Changes the weather parameteres ruling the simulation to another ones defined in an object.
- **Parameters:**
@@ -2949,6 +3178,10 @@ The maximum number of physics substepping that are allowed. By default, the valu
Configure the max draw distance for each mesh of the level.
- **deterministic_ragdolls** (_bool_)
Defines wether to use deterministic physics for pedestrian death animations or physical ragdoll simulation. When enabled, pedestrians have less realistic death animation but ensures determinism. When disabled, pedestrians are simulated as ragdolls with more realistic simulation and collision but no determinsm can be ensured.
+- **tile_stream_distance** (_float_)
+Used for large maps only. Configures the maximum distance from the hero vehicle to stream tiled maps. Regions of the map within this range will be visible (and capable of simulating physics). Regions outside this region will not be loaded.
+- **actor_active_distance** (_float_)
+Used for large maps only. Configures the distance from the hero vehicle to convert actors to dormant. Actors within this range will be active, and actors outside will become dormant.
### Methods
- **\__init__**(**self**, **synchronous_mode**=False, **no_rendering_mode**=False, **fixed_delta_seconds**=0.0)
@@ -3145,6 +3378,23 @@ Vehicle control to be applied.
---
+## command.ApplyVehiclePhysicsControl
+Command adaptation of __apply_physics_control()__ in [carla.Vehicle](#carla.Vehicle). Applies a new physics control to a vehicle, modifying its physical parameters.
+
+### Instance Variables
+- **actor_id** (_int_)
+Vehicle actor affected by the command.
+- **control** (_[carla.VehiclePhysicsControl](#carla.VehiclePhysicsControl)_)
+Physics control to be applied.
+
+### Methods
+- **\__init__**(**self**, **actor**, **control**)
+ - **Parameters:**
+ - `actor` (_[carla.Actor](#carla.Actor) or int_) – Actor or its ID to whom the command will be applied to.
+ - `control` (_[carla.VehiclePhysicsControl](#carla.VehiclePhysicsControl)_)
+
+---
+
## command.ApplyWalkerControl
Command adaptation of __apply_control()__ in [carla.Walker](#carla.Walker). Applies a control to a walker.
@@ -3232,6 +3482,22 @@ Port of the Traffic Manager where the vehicle is to be registered or unlisted.
---
+## command.SetEnableGravity
+Command adaptation of __set_enable_gravity()__ in [carla.Actor](#carla.Actor). Enables or disables gravity on an actor.
+
+### Instance Variables
+- **actor_id** (_[carla.Actor](#carla.Actor) or int_)
+Actor that is affected by the command.
+- **enabled** (_bool_)
+
+### Methods
+- **\__init__**(**self**, **actor**, **enabled**)
+ - **Parameters:**
+ - `actor` (_[carla.Actor](#carla.Actor) or int_) – Actor or Actor ID to which the command will be applied to.
+ - `enabled` (_bool_)
+
+---
+
## command.SetSimulatePhysics
Command adaptation of __set_simulate_physics()__ in [carla.Actor](#carla.Actor). Determines whether an actor will be affected by physics or not.
@@ -3266,6 +3532,22 @@ Defines the light state of a vehicle.
---
+## command.ShowDebugTelemetry
+Command adaptation of __show_debug_telemetry()__ in [carla.Actor](#carla.Actor). Displays vehicle control telemetry data.
+
+### Instance Variables
+- **actor_id** (_[carla.Actor](#carla.Actor) or int_)
+Actor that is affected by the command.
+- **enabled** (_bool_)
+
+### Methods
+- **\__init__**(**self**, **actor**, **enabled**)
+ - **Parameters:**
+ - `actor` (_[carla.Actor](#carla.Actor) or int_) – Actor or Actor ID to which the command will be applied to.
+ - `enabled` (_bool_)
+
+---
+
## command.SpawnActor
Command adaptation of __spawn_actor()__ in [carla.World](#carla.World). Spawns an actor into the world based on the blueprint provided and the transform. If a parent is provided, the actor is attached to it.
@@ -3318,9 +3600,63 @@ document.getElementById("snipets-container").innerHTML = null;
}
+
+
+Snippet for carla.World.load_map_layer
+
+
+
+```py
+
+# This recipe toggles on several layers in our "_Opt" maps
+
+# Load town one with only minimum layout (roads, sidewalks, traffic lights and traffic signs)
+world = client.load_world('Town01_Opt', carla.MapLayer.None)
+
+# Toggle all buildings on
+world.load_map_layer(carla.MapLayer.Buildings)
+
+# Toggle all foliage on
+world.load_map_layer(carla.MapLayer.Foliage)
+
+# Toggle all parked vehicles on
+world.load_map_layer(carla.MapLayer.ParkedVehicles)
+
+
+```
+
+
+
+
+
+
+Snippet for carla.World.unload_map_layer
+
+
+
+```py
+
+# This recipe toggles off several layers in our "_Opt" maps
+
+# Load town one with minimum layout (roads, sidewalks, traffic lights and traffic signs)
+# as well as buildings and parked vehicles
+world = client.load_world('Town01_Opt', carla.MapLayer.Buildings | carla.MapLayer.ParkedVehicles)
+
+# Toggle all buildings off
+world.unload_map_layer(carla.MapLayer.Buildings)
+
+# Toggle all parked vehicles off
+world.unload_map_layer(carla.MapLayer.ParkedVehicles)
+
+
+```
+
+
+
+
-Snipet for carla.Map.get_waypoint
+Snippet for carla.Map.get_waypoint
+Snippet for carla.Vehicle.set_wheel_steer_direction
+
+
+
+```py
+
+# Sets the appearance of the vehicles front wheels to 40°. Vehicle physics will not be affected.
+
+vehicle.set_wheel_steer_direction(carla.VehicleWheelLocation.FR_Wheel, 40.0)
+vehicle.set_wheel_steer_direction(carla.VehicleWheelLocation.FL_Wheel, 40.0)
+
+
+```
+
-Snipet for carla.DebugHelper.draw_string
+Snippet for carla.DebugHelper.draw_string
@@ -3633,13 +3988,43 @@ while True:
```
-
+
+
+
+
+
+
+Snippet for carla.World.enable_environment_objects
+
+
+
+```py
+
+# This recipe turn visibility off and on for two specifc buildings on the map
+
+# Get the buildings in the world
+world = client.get_world()
+env_objs = world.get_environment_objects(carla.CityObjectLabel.Buildings)
+
+# Access individual building IDs and save in a set
+building_01 = env_objs[0]
+building_02 = env_objs[1]
+objects_to_toggle = {building_01.id, building_02.id}
+
+# Toggle buildings off
+world.enable_environment_objects(objects_to_toggle, False)
+# Toggle buildings on
+world.enable_environment_objects(objects_to_toggle, True)
+
+
+```
+
-Snipet for carla.Client.__init__
+Snippet for carla.Client.__init__
@@ -3678,13 +4063,13 @@ Snipet for carla.Client.__init__
```
-
+
-Snipet for carla.TrafficLight.set_state
+Snippet for carla.TrafficLight.set_state
@@ -3721,7 +4106,7 @@ if vehicle_actor.is_at_traffic_light():
```
-
+
diff --git a/Docs/ref_recorder_binary_file_format.md b/Docs/ref_recorder_binary_file_format.md
index d1345999b..19f7be7b2 100644
--- a/Docs/ref_recorder_binary_file_format.md
+++ b/Docs/ref_recorder_binary_file_format.md
@@ -177,7 +177,7 @@ This packet records the position and orientation of all actors of type **vehicle
This packet records the state of all **traffic lights** in the scene. Which means that it
stores the state (red, orange or green) and the time it is waiting to change to a new state.
-![state](img/RecorderTrafficLight.jpg)
+![state](img/RecorderTrafficLight.png)
### Packet 8 - Vehicle animation
diff --git a/Docs/ref_sensors.md b/Docs/ref_sensors.md
index 9c4d43942..a83301d31 100644
--- a/Docs/ref_sensors.md
+++ b/Docs/ref_sensors.md
@@ -1,18 +1,19 @@
# Sensors reference
-* [__Collision detector__](#collision-detector)
-* [__Depth camera__](#depth-camera)
-* [__GNSS sensor__](#gnss-sensor)
-* [__IMU sensor__](#imu-sensor)
-* [__Lane invasion detector__](#lane-invasion-detector)
-* [__LIDAR sensor__](#lidar-sensor)
-* [__Obstacle detector__](#obstacle-detector)
-* [__Radar sensor__](#radar-sensor)
-* [__RGB camera__](#rgb-camera)
-* [__RSS sensor__](#rss-sensor)
-* [__Semantic LIDAR sensor__](#semantic-lidar-sensor)
-* [__Semantic segmentation camera__](#semantic-segmentation-camera)
-* [__DVS camera__](#dvs-camera)
+- [__Collision detector__](#collision-detector)
+- [__Depth camera__](#depth-camera)
+- [__GNSS sensor__](#gnss-sensor)
+- [__IMU sensor__](#imu-sensor)
+- [__Lane invasion detector__](#lane-invasion-detector)
+- [__LIDAR sensor__](#lidar-sensor)
+- [__Obstacle detector__](#obstacle-detector)
+- [__Radar sensor__](#radar-sensor)
+- [__RGB camera__](#rgb-camera)
+- [__RSS sensor__](#rss-sensor)
+- [__Semantic LIDAR sensor__](#semantic-lidar-sensor)
+- [__Semantic segmentation camera__](#semantic-segmentation-camera)
+- [__DVS camera__](#dvs-camera)
+- [__Optical Flow camera__](#optical-flow-camera)
!!! Important
All the sensors use the UE coordinate system (__x__-*forward*, __y__-*right*, __z__-*up*), and return coordinates in local space. When using any visualization software, pay attention to its coordinate system. Many invert the Y-axis, so visualizing the sensor data directly may result in mirrored outputs.
@@ -265,6 +266,7 @@ The rotation of the LIDAR can be tuned to cover a specific angle on every simula
| `rotation_frequency` | float | 10.0 | LIDAR rotation frequency. |
| `upper_fov` | float | 10.0 | Angle in degrees of the highest laser. |
| `lower_fov` | float | -30.0 | Angle in degrees of the lowest laser. |
+| `horizontal_fov` | float | 360.0 | Horizontal field of view in degrees, 0 - 360. |
| `atmosphere_attenuation_rate` | float | 0.004 | Coefficient that measures the LIDAR instensity loss per meter. Check the intensity computation above. |
| `dropoff_general_rate` | float | 0.45 | General proportion of points that are randomy dropped. |
| `dropoff_intensity_limit` | float | 0.8 | For the intensity based drop-off, the threshold intensity value above which no points are dropped. |
@@ -335,7 +337,7 @@ The sensor creates a conic view that is translated to a 2D point map of the elem
Points measured are contained in [carla.RadarMeasurement](python_api.md#carla.RadarMeasurement) as an array of [carla.RadarDetection](python_api.md#carla.RadarDetection), which specifies their polar coordinates, distance and velocity.
This raw data provided by the radar sensor can be easily converted to a format manageable by __numpy__:
```py
-# To get a numpy [[vel, altitude, azimuth, depth],...[,,,]]:
+# To get a numpy [[vel, azimuth, altitude, depth],...[,,,]]:
points = np.frombuffer(radar_data.raw_data, dtype=np.dtype('f4'))
points = np.reshape(points, (len(radar_data), 4))
```
@@ -449,9 +451,9 @@ Since these effects are provided by UE, please make sure to check their document
| `min_fstop` | float | 1\.2 | Maximum aperture. |
| `blade_count` | int | 5 | Number of blades that make up the diaphragm mechanism. |
| `exposure_mode` | str | `histogram` | Can be `manual` or `histogram`. More in [UE4 docs](). |
-| `exposure_compensation` | float | **Linux:** \-1.5 **Windows:** 0\.0 | Logarithmic adjustment for the exposure. 0: no adjustment, -1:2x darker, -2:4 darker, 1:2x brighter, 2:4x brighter. |
-| `exposure_min_bright` | float | 7\.0 | In `exposure_mode: "histogram"`. Minimum brightness for auto exposure. The lowest the eye can adapt within. Must be greater than 0 and less than or equal to `exposure_max_bright`. |
-| `exposure_max_bright` | float | 9\.0 | In \`exposure\_mode: "histogram"\`. Maximum brightness for auto exposure. The highestthe eye can adapt within. Must be greater than 0 and greater than or equal to \`exposure\_min\_bright\`. |
+| `exposure_compensation` | float | **Linux:** \+0.75 **Windows:** 0\.0 | Logarithmic adjustment for the exposure. 0: no adjustment, -1:2x darker, -2:4 darker, 1:2x brighter, 2:4x brighter. |
+| `exposure_min_bright` | float | 10\.0 | In `exposure_mode: "histogram"`. Minimum brightness for auto exposure. The lowest the eye can adapt within. Must be greater than 0 and less than or equal to `exposure_max_bright`. |
+| `exposure_max_bright` | float | 12\.0 | In \`exposure\_mode: "histogram"\`. Maximum brightness for auto exposure. The highestthe eye can adapt within. Must be greater than 0 and greater than or equal to \`exposure\_min\_bright\`. |
| `exposure_speed_up` | float | 3\.0 | In `exposure_mode: "histogram"`. Speed at which the adaptation occurs from dark to bright environment. |
| `exposure_speed_down` | float | 1\.0 | In `exposure_mode: "histogram"`. Speed at which the adaptation occurs from bright to dark environment. |
| `calibration_constant` | float | 16\.0 | Calibration constant for 18% albedo. |
@@ -660,14 +662,15 @@ __2.__ Run the simulation using `python3 config.py --fps=10`.
-| Blueprint attribute | Type | Description |
-| ------------------------------------- | ------------------------------------- | ------------------------------------- |
+| Blueprint attribute | Type | Default | Description |
+| ------------------------------------- | ------------------ | ------------------- | ------------------------------------- |
| `channels` | int | 32 | Number of lasers. |
| `range` | float | 10.0 | Maximum distance to measure/raycast in meters (centimeters for CARLA 0.9.6 or previous). |
| `points_per_second` | int | 56000 | Points generated by all lasers per second. |
| `rotation_frequency` | float | 10.0 | LIDAR rotation frequency. |
| `upper_fov` | float | 10.0 | Angle in degrees of the highest laser. |
| `lower_fov` | float | -30.0 | Angle in degrees of the lowest laser. |
+| `horizontal_fov` | float | 360.0 | Horizontal field of view in degrees, 0 - 360. |
| `sensor_tick` | float | 0.0 | Simulation seconds between sensor captures (ticks). |
@@ -793,7 +796,7 @@ The following tags are currently available:
A Dynamic Vision Sensor (DVS) or Event camera is a sensor that works radically differently from a conventional camera. Instead of capturing
intensity images at a fixed rate, event cameras measure changes of intensity asynchronously, in the form of a stream of events, which encode per-pixel
-brightness changes. Event cameras possess outstanding properties when compared to standard cameras. They have a very high dynamic range (140 dB
+brightness changes. Event cameras possess distinct properties when compared to standard cameras. They have a very high dynamic range (140 dB
versus 60 dB), no motion blur, and high temporal resolution (in the order of microseconds). Event cameras are thus sensors that can provide high-quality
visual information even in challenging high-speed scenarios and high dynamic range environments, enabling new application domains for vision-based
algorithms.
@@ -816,10 +819,14 @@ contrast threshold `C` for one dimension `x` over time `t`. Observe how the even
The current implementation of the DVS camera works in a uniform sampling manner between two consecutive synchronous frames. Therefore, in order to
emulate the high temporal resolution (order of microseconds) of a real event camera, the sensor requires to execute at a high frequency (much higher
-frequency than a conventional camera). Effectively, the number of events increases as faster a CARLA car drives. Therefore, the sensor frequency
-should increase accordingly with the dynamic of the scene. The user should find their balance between time accuracy and computational cost.
+frequency than a conventional camera). Effectively, the number of events increases the faster a CARLA car drives. Therefore, the sensor frequency
+should increase accordingly with the dynamics of the scene. The user should find a balance between time accuracy and computational cost.
-The provided script `manual_control.py` uses the DVS camera in order to show how to configure the sensor, how to get the stream of events and how to depict such events in an image format, usually called event frame.
+The provided script [`manual_control.py`][manual_control] uses the DVS camera in order to show how to configure the sensor, how to get the stream of events and how to depict such events in an image format, usually called event frame.
+
+[manual_control]: https://github.com/carla-simulator/carla/blob/master/PythonAPI/examples/manual_control.py
+
+Note that due to the sampling method of the DVS camera, if there is no pixel difference between two consecutive synchronous frames the camera will not return an image. This will always occur in the first frame, as there is no previous frame to compare to and also in the event that there has been no movement between frames.
![DVSCameraWorkingPrinciple](img/sensor_dvs.gif)
@@ -838,3 +845,45 @@ DVS is a camera and therefore has all the attributes available in the RGB camera
| `log_eps` | float | 0\.001 | Epsilon value used to convert images to log: `L = log(eps + I / 255.0)`. Where `I` is the grayscale value of the RGB image: `I = 0.2989*R + 0.5870*G + 0.1140*B`. |
+
+---
+
+## Optical Flow Camera
+
+The Optical Flow camera captures the motion perceived from the point of view of the camera. Every pixel recorded by this sensor encodes the velocity of that point projected to the image plane. The velocity of a pixel is encoded in the range [-2,2]. To obtain the motion in pixel units, this information can be scaled with the image size to [-2 * image_size, 2 * image_size].
+
+![optical_flow](img/optical_flow.png)
+
+#### Optical Flow camera attributes
+
+| Blueprint attribute | Type | Default | Description |
+| ------------------- | ---- | ------- | ----------- |
+| `image_size_x` | int | 800 | Image width in pixels. |
+| `image_size_y` | int | 600 | Image height in pixels. |
+| `fov` | float | 90.0 | Horizontal field of view in degrees. |
+| `sensor_tick` | float | 0.0 | Simulation seconds between sensor captures (ticks). |
+
+#### Optical Flow camera lens distortion attributes
+
+| Blueprint attribute | Type | Default | Description |
+| ------------------------------------------------------- | ------------------------------------------------------- | ------------------------------------------------------- | ------------------------------------------------------- |
+| `lens_circle_falloff` | float | 5\.0 | Range: [0.0, 10.0] |
+| `lens_circle_multiplier` | float | 0\.0 | Range: [0.0, 10.0] |
+| `lens_k` | float | \-1.0 | Range: [-inf, inf] |
+| `lens_kcube` | float | 0\.0 | Range: [-inf, inf] |
+| `lens_x_size` | float | 0\.08 | Range: [0.0, 1.0] |
+| `lens_y_size` | float | 0\.08 | Range: [0.0, 1.0] |
+
+#### Output attributes
+
+| Sensor data attribute | Type | Description |
+| --------------------- | ---- | ----------- |
+| `frame` | int | Frame number when the measurement took place. |
+| `timestamp` | double | Simulation time of the measurement in seconds since the beginning of the episode. |
+| `transform` | [carla.Transform](<../python_api#carlatransform>) | Location and rotation in world coordinates of the sensor at the time of the measurement. |
+| `width` | int | Image width in pixels. |
+| `height` | int | Image height in pixels. |
+| `fov` | float | Horizontal field of view in degrees. |
+| `raw_data` | bytes | Array of BGRA 64-bit pixels containing two float values. |
+
+
diff --git a/Docs/release_readme.md b/Docs/release_readme.md
index d00e264ed..5b715f1fa 100644
--- a/Docs/release_readme.md
+++ b/Docs/release_readme.md
@@ -23,7 +23,7 @@ Let's start by adding some live to the city, open a new terminal window and
execute
```sh
-./spawn_npc.py -n 80
+./generate_traffic.py -n 80
```
This adds 80 vehicles to the world driving in "autopilot" mode. Back to the
diff --git a/Docs/ros_documentation.md b/Docs/ros_documentation.md
new file mode 100644
index 000000000..2a01f28e1
--- /dev/null
+++ b/Docs/ros_documentation.md
@@ -0,0 +1,16 @@
+# ROS Bridge
+
+__Full documentation of the ROS bridge is found [__here__](https://carla.readthedocs.io/projects/ros-bridge/en/latest/).__
+
+---
+
+The ROS bridge enables two-way communication between ROS and CARLA. The information from the CARLA server is translated to ROS topics. In the same way, the messages sent between nodes in ROS get translated to commands to be applied in CARLA.
+
+The ROS bridge is compatible with both ROS 1 and ROS 2.
+
+The ROS bridge boasts the following features:
+
+- Provides sensor data for LIDAR, Semantic LIDAR, Cameras (depth, segmentation, rgb, dvs), GNSS, Radar and IMU.
+- Provides object data such as transforms, traffic light status, visualisation markers, collision and lane invasion.
+- Control of AD agents through steering, throttle and brake.
+- Control of aspects of the CARLA simulation like synchronous mode, playing and pausing the simulation and setting simulation parameters.
diff --git a/Docs/ros_installation.md b/Docs/ros_installation.md
deleted file mode 100644
index ecac2c016..000000000
--- a/Docs/ros_installation.md
+++ /dev/null
@@ -1,178 +0,0 @@
-# ROS bridge installation
-
-The ROS bridge enables two-way communication between ROS and CARLA. The information from the CARLA server is translated to ROS topics. In the same way, the messages sent between nodes in ROS get translated to commands to be applied in CARLA.
-
-* [__Requirements__](#requirements)
- * [Python version](#python-version)
-* [__Bridge installation__](#bridge-installation)
- * [A. Using Debian repository](#a-using-debian-repository)
- * [B. Using source repository](#b-using-source-repository)
-* [__Run the ROS bridge__](#run-the-ros-bridge)
-* [__Setting CARLA__](#setting-carla)
-
-!!! Important
- ROS is still [experimental](http://wiki.ros.org/noetic/Installation) for Windows, so the ROS bridge has only been tested for Linux systems.
-
----
-## Requirements
-
-Make sure that both requirements work properly before continuing with the installation.
-
-* __ROS Kinetic/Melodic__ — Install the ROS version corresponding to your system. Additional ROS packages may be required, depending on the user needs. [rviz](http://wiki.ros.org/rviz) is highly recommended to visualize ROS data.
- * [__ROS Kinetic__](http://wiki.ros.org/kinetic/Installation) — For Ubuntu 16.04 (Xenial).
- * [__ROS Melodic__](http://wiki.ros.org/melodic/Installation/Ubuntu) — For Ubuntu 18.04 (Bionic).
- * [__ROS Noetic__](http://wiki.ros.org/noetic#Installation) — For Ubuntu 20.04 (Focal).
-* __CARLA 0.9.7 or later__ — Previous versions are not compatible with the ROS bridge. Follow the [quick start installation](start_quickstart.md) or make the build for [Linux](build_linux.md).
-
-### Python version
-
-The Python version needed to run the ROS bridge depends on the ROS version being used.
-
-* __ROS Kinetic__ and __ROS Melodic__ — Python2.
-* __ROS Noetic__ — Python3.
-
-CARLA provides different Python support depending on the installation method. Here is a summary.
-
-* __CARLA release packages__ — Provide support for Python2 and Python3, so these can be used with any ROS version.
-* __Windows build__ — Provides Support for the default Python installation in the system, so the ROS installation should match this.
-* __Linux build__ — Provides support for Python3 by default (ROS Noetic). If Python2 is needed, the PythonAPI can be built for Python2 running the following command in the CARLA root directory.
-```sh
-make PythonAPI ARGS="--python-version=2" # The numeric argument can be changed to build for any specific Python version
-```
-
----
-## Bridge installation
-
-!!! Important
- To install ROS bridge versions prior to 0.9.10, change to a previous version of the documentation using the pannel in the bottom right corner of the window, and follow the old instructions. ![docs_version_panel](img/docs_version_panel.jpg)
-
-### A. Using Debian repository
-
-Set up the Debian repository in the system.
-```sh
-sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 1AF1527DE64CB8D9
-sudo add-apt-repository "deb [arch=amd64] http://dist.carla.org/carla $(lsb_release -sc) main"
-```
-Install the ROS bridge, and check for the installation in the `/opt/` folder.
-```sh
-sudo apt-get update # Update the Debian package index
-sudo apt-get install carla-ros-bridge # Install the latest ROS bridge version, or update the current installation
-```
-
-This repository contains features from CARLA 0.9.10 and later versions. To install a specific version add the version tag to the installation command.
-```sh
-sudo apt-get install carla-ros-bridge=0.9.10-1 # In this case, "0.9.10" refers to the ROS bridge version, and "1" to the Debian revision
-```
-
-### B. Using source repository
-
-A catkin workspace is needed to use the ROS bridge. It should be cloned and built in there. The following code creates a new workspace, and clones the repository in there.
-
-```sh
-# Setup folder structure
-mkdir -p ~/carla-ros-bridge/catkin_ws/src
-cd ~/carla-ros-bridge
-git clone https://github.com/carla-simulator/ros-bridge.git
-cd ros-bridge
-git submodule update --init
-cd ../catkin_ws/src
-ln -s ../../ros-bridge
-source /opt/ros/kinetic/setup.bash # Watch out, this sets ROS Kinetic
-cd ..
-
-# Install required ros-dependencies
-rosdep update
-rosdep install --from-paths src --ignore-src -r
-
-# Build
-catkin_make
-```
-
----
-## Run the ROS bridge
-
-__1) Run CARLA.__ The way to do so depends on the CARLA installation.
-
-* __Quick start/release package.__ `./CarlaUE4.sh` in `carla/`.
-* __Debian installation.__ `./CarlaUE4.sh` in `opt/carla-simulator/`.
-* __Build installation.__ `make launch` in `carla/`.
-
-__2) Add the source path.__ The source path for the workspace has to be added, so that the ROS bridge can be used from a terminal.
-
-* __Source for apt ROS bridge.__
-```sh
-source /opt/carla-ros-bridge//setup.bash
-```
-
-* __Source for ROS bridge repository download.__
-```sh
-source ~/carla-ros-bridge/catkin_ws/devel/setup.bash
-```
-
-!!! Important
- The source path can be set permanently, but it will cause conflict when working with another workspace.
-
-__3) Start the ROS bridge.__ Use any of the different launch files available to check the installation. Here are some suggestions.
-
-```sh
-# Option 1: start the ros bridge
-roslaunch carla_ros_bridge carla_ros_bridge.launch
-
-# Option 2: start the ros bridge together with RVIZ
-roslaunch carla_ros_bridge carla_ros_bridge_with_rviz.launch
-
-# Option 3: start the ros bridge together with an example ego vehicle
-roslaunch carla_ros_bridge carla_ros_bridge_with_example_ego_vehicle.launch
-```
-
-
-
-
ImportError: no module named CARLA
-
-
-The path to CARLA Python is missing. The apt installation does this automatically, but it may be missing for other installations. Execute the following command with the complete path to the .egg file (included). Use the one supported by the Python version installed.
-
-Note: .egg files may be either in `/PythonAPI/` or `/PythonAPI/dist/` depending on the CARLA installation.
-
-```sh
- export PYTHONPATH=$PYTHONPATH:/PythonAPI/
-```
-
-Import CARLA from Python and wait for a sucess message to check the installation.
-```sh
-python3 -c 'import carla;print("Success")'
-```
-
-
----
-## Setting CARLA
-
-To modify the way CARLA works along with the ROS bridge, edit [`share/carla_ros_bridge/config/settings.yaml`](https://github.com/carla-simulator/ros-bridge/blob/master/carla_ros_bridge/config/settings.yaml).
-
-* __Host/port.__ Network settings to connect to CARLA using a Python client.
-* __Synchronous mode.__
- * __If false (default).__ Data is published on every `world.on_tick()` and every `sensor.listen()` callbacks.
- * __If true__ The bridge waits for all the sensor messages expected before the next tick. This might slow down the overall simulation but ensures reproducible results.
-* __Wait for vehicle command.__ In synchronous mode, pauses the tick until a vehicle control is completed.
-* __Simulation time-step.__ Simulation time (delta seconds) between simulation steps. __It must be lower than 0.1__. Take a look at the [documentation](adv_synchrony_timestep.md) to learn more about this.
-* __Role names for the Ego vehicles.__ Role names to identify ego vehicles. These will be controllable from ROS and thus, relevant topics will be created.
-
-!!! Warning
- In synchronous mode only the ros-bridge is allowed to tick. Other clients must passively wait.
-
-### Synchronous mode
-
-To control the step update when in synchronous mode, use the following topic. The message contains a constant named `command` that allows to __Pause/Play__ the simulation, and execute a __single step__.
-
-
-
-| Topic | Message type |
-| ------------------------------------------------ | ------------------------------------------------ |
-| `/carla/control` | [carla\_msgs.CarlaControl](<../ros_msgs#carlacontrolmsg>) |
-
-
-
-The [Control rqt plugin](https://github.com/carla-simulator/ros-bridge/blob/master/rqt_carla_control/README.md) launches a new window with a simple interface. It is used to manage the steps and publish in the corresponding topic. Simply run the following when CARLA in synchronous mode.
-```sh
-rqt --standalone rqt_carla_control
-```
diff --git a/Docs/ros_launchs.md b/Docs/ros_launchs.md
deleted file mode 100644
index 84a9b7b9b..000000000
--- a/Docs/ros_launchs.md
+++ /dev/null
@@ -1,392 +0,0 @@
-# Launchfiles reference
-
----
-## carla_ackermann_control.launch
-
-Creates a node to manage a vehicle using Ackermann controls instead of the CARLA control messages. The node reads the vehicle info from CARLA and uses it to define the controller. A simple Python PID is used to adjust acceleration/velocity. This is a Python dependency that can be easily installed with _pip_.
-```sh
-pip install --user simple-pid
-```
-It is possible to modify the parameters in runtime via ROS dynamic reconfigure. Initial parameters can be set using a `settings.yaml`. The path to it depends on the bridge installation.
-
-* __Deb repository installation__,
-`/opt/carla-ros-bridge/melodic/share/carla_ackermann_control/config/settings.yaml`.
-* __Source repository installation__,
-`/catkin_ws/src/ros-bridge/carla_ackermann_control/config/settings.yaml`.
-
-
-
/carla_ackermann_control_ego_vehicle(Node)
-Converts [AckermannDrive messages](http://docs.ros.org/jade/api/ackermann_msgs/html/msg/AckermannDrive.html) to [CarlaEgoVehicleControl.msg](ros_msgs.md#carlaegovehiclecontrolmsg). Speed is in __m/s__, steering angle in __radians__ and refers to driving angle, not wheel angle.
-
-
-
-* /carla/ego_vehicle/ackermann_control/parameter_descriptions — [dynamic_reconfigure/ConfigDescription](http://docs.ros.org/melodic/api/dynamic_reconfigure/html/msg/ConfigDescription.html)
-* /carla/ego_vehicle/ackermann_control/control_info — [carla_ackermann_control.EgoVehicleControlInfo](ros_msgs.md#egovehiclecontrolinfomsg)
-* /carla/ego_vehicle/ackermann_control/parameter_updates — [dynamic_reconfigure/Config](http://wiki.ros.org/dynamic_reconfigure)
-* /carla/ego_vehicle/vehicle_control_cmd — [carla_msgs.CarlaEgoVehicleControl](ros_msgs.md#carlaegovehiclecontrolmsg)
-
----
-## carla_ego_vehicle.launch
-
-Spawns an ego vehicle (`role-name="ego_vehicle"`). The argument `sensor_definition_file` describes the sensors attached to the vehicle. It is the location of a __.json__ file. The format of this file is explained [here](https://github.com/carla-simulator/ros-bridge/tree/master/carla_ego_vehicle).
-
-To spawn the vehicle at a specific location, publish in `/carla/ego_vehicle/initialpose`, or use __RVIZ__ and select a position with __2D Pose estimate__.
-
-
-
carla_ego_vehicle_ego_vehicle(Node)
-Spawns an ego vehicle with sensors attached, and waits for world information.
-
-
Subscribed to:
-
-* /carla/ego_vehicle/initialpose — [geometry_msgs/PoseWithCovarianceStamped](http://docs.ros.org/melodic/api/geometry_msgs/html/msg/PoseWithCovarianceStamped.html)
-* /carla/world_info — [carla_msgs.CarlaWorldInfo](ros_msgs.md#carlaworldinfomsg)
-
----
-## carla_example_ego_vehicle.launch
-Based on carla_ego_vehicle.launch, spawns an ego vehicle (`role-name="ego_vehicle"`). The file `sensors.json` describes the sensors attached. The path to it depends on the bridge installation.
-
-* __Deb repository installation__,
-`/opt/carla-ros-bridge/melodic/share/carla_ego_vehicle/config/sensors.json`.
-* __Source repository installation__,
-`/catkin_ws/src/ros-bridge/carla_ego_vehicle/config/sensors.json`.
-
-
-
carla_ego_vehicle_ego_vehicle(Node)
-Spawns an ego vehicle with sensors attached and waits for world information.
-
-
Subscribed to:
-
-* /carla/ego_vehicle/initialpose — [geometry_msgs/PoseWithCovarianceStamped](http://docs.ros.org/melodic/api/geometry_msgs/html/msg/PoseWithCovarianceStamped.html)
-* /carla/world_info — [carla_msgs.CarlaWorldInfo](ros_msgs.md#carlaworldinfomsg)
-
----
-## carla_infrastructure.launch
-Spawns infrastructure sensors and requires the argument `infrastructure_sensor_definition_file` with the location of a __.json__ file describing these sensors.
-
-
-
/carla_infrastructure(Node)
-Spawns the infrastructure sensors passed as arguments.
-
-
Subscribed to:
-
-* /carla/world_info — [carla_msgs.CarlaWorldInfo](ros_msgs.md#carlaworldinfomsg)
-
----
-## carla_ros_bridge.launch
-Creates a node with some basic communications between CARLA and ROS.
-
-
-
carla_ros_bridge(Node)
-Publishes the data regarding the current state of the simulation. Reads the debug shapes being drawn.
-
-
-Converts [AckermannDrive messages](http://docs.ros.org/jade/api/ackermann_msgs/html/msg/AckermannDrive.html) to [CarlaEgoVehicleControl.msg](ros_msgs.md#carlaegovehiclemsg). Speed is in __m/s__, steering angle is in __radians__ and refers to driving angle, not wheel angle.
-
-
-
-* /carla/ego_vehicle/ackermann_control/parameter_descriptions — [dynamic_reconfigure/ConfigDescription](http://docs.ros.org/melodic/api/dynamic_reconfigure/html/msg/ConfigDescription.html)
-* /carla/ego_vehicle/ackermann_control/control_info — [carla_ackermann_control.EgoVehicleControlInfo](ros_msgs.md#egovehiclecontrolinfomsg)
-* /carla/ego_vehicle/ackermann_control/parameter_updates — [dynamic_reconfigure/Config](http://wiki.ros.org/dynamic_reconfigure)
-* /carla/ego_vehicle/vehicle_control_cmd — [carla_msgs.CarlaEgoVehicleControl](ros_msgs.md#carlaegovehiclecontrolmsg)
-
----
-## carla_ros_bridge_with_example_ego_vehicle.launch
-
-Spawns an ego vehicle with sensors attached, and starts communications between CARLA and ROS. Both share current simulation state, sensor and ego vehicle data. The ego vehicle is set ready to be used in manual control.
-
-
-
carla_ros_bridge(Node)
-In charge of the communications between CARLA and ROS. They share the current state of the simulation, traffic lights, vehicle controllers and sensor data.
-
-Retrieves information from CARLA regarding the ego vehicle. Uses keyboard input to publish controller messages for the ego vehicle. The information retrieved includes static data, current state, sensor data, and simulation settings.
-
-
-Runs an instance of RVIZ, and waits for Lidar data.
-
-
Subscribed to:
-
-* /carla/vehicle_marker — [visualization_msgs/Marker](http://docs.ros.org/melodic/api/visualization_msgs/html/msg/Marker.html)
-* /carla/vehicle_marker_array — [visualization_msgs/MarkerArray](http://docs.ros.org/melodic/api/visualization_msgs/html/msg/MarkerArray.html)
-* /carla/ego_vehicle/lidar/front/point_cloud — [sensor_msgs.PointCloud2](http://docs.ros.org/melodic/api/sensor_msgs/html/msg/PointCloud2.html)
-
-
----
-## carla_manual_control.launch
-
-A ROS version of the CARLA script `manual_control.py`. It has some prequisites.
-
-* __To display an image__, a camera with role-name `view` and resolution 800x600.
-* __To display the position__, a gnss sensor with role-name `gnss1`.
-* __To detect other sensor data__, the corresponding sensor.
-
-
-
-
/carla_manual_control_ego_vehicle(Node)
-Retrieves information from CARLA regarding the ego vehicle. Uses keyboard input to publish controller messages for the ego vehicle. The information retrieved includes static data, current state, sensor data, and simulation settings.
-
-
-
-* /carla/ego_vehicle/enable_autopilot — [std_msgs.Bool](http://docs.ros.org/melodic/api/std_msgs/html/msg/Bool.html)
-* /carla/ego_vehicle/vehicle_control_cmd_manual — [carla_msgs.CarlaEgoVehicleControl](ros_msgs.md#carlaegovehiclecontrolmsg)
-* /carla/ego_vehicle/vehicle_control_manual_override — [std_msgs.Bool](http://docs.ros.org/melodic/api/std_msgs/html/msg/Bool.html)
-
----
-## carla_pcl_recorder.launch
-Creates a pointcloud map for the current CARLA level. An autopilot ego vehicle roams around the map with a LIDAR sensor attached.
-
-The point clouds are saved in the `/tmp/pcl_capture` directory. Once the capture is done, the overall size can be reduced.
-
-```sh
-#create one point cloud file
-pcl_concatenate_points_pcd /tmp/pcl_capture/*.pcd
-
-#filter duplicates
-pcl_voxel_grid -leaf 0.1,0.1,0.1 output.pcd map.pcd
-
-#verify the result
-pcl_viewer map.pcd
-```
-
-The launch file requires some functionality that is not part of the python egg-file. The PYTHONPATH has to be extended.
-
-```sh
-export PYTHONPATH=/PythonAPI/carla/dist/carla-.egg:/PythonAPI/carla/
-```
-
-
-
carla_ros_bridge(Node)
-In charge of most of the communications between CARLA and ROS. Both share the current state of the simulation, traffic lights, vehicle controllers and sensor data.
-
-
-Retrieves information from CARLA regarding the ego vehicle. Uses keyboard input to publish controller messages for the ego vehicle. The information retrieved includes static data, current state, sensor data, and simulation settings.
-
-
-
-* /carla/ego_vehicle/lidar/lidar1/point_cloud — [sensor_msgs.PointCloud2](http://docs.ros.org/melodic/api/sensor_msgs/html/msg/PointCloud2.html)
-
----
-## carla_waypoint_publisher.launch
-
-Calculates a waypoint route for an ego vehicle. The route is published in `/carla//waypoints`. The goal is either read from the ROS topic `/carla//goal`, or a fixed spawnpoint is used.
-The prefered way of setting a goal is to click __2D Nav Goal__ in RVIZ.
-
-The launch file requires some functionality that is not part of the python egg-file. The PYTHONPATH has to be extended.
-```sh
-export PYTHONPATH=$PYTHONPATH:/PythonAPI/carla-.egg:/PythonAPI/carla/
-```
-
-
-
/carla_waypoint_publisher(Node)
-Uses the current pose of the ego vehicle as starting point. If the vehicle is respawned or moved, the route is calculated again.
-
-
Subscribed to:
-
-* /carla/world_info — [carla_msgs.CarlaWorldInfo](ros_msgs.md#carlaworldinfomsg)
diff --git a/Docs/ros_msgs.md b/Docs/ros_msgs.md
deleted file mode 100644
index b21f90355..000000000
--- a/Docs/ros_msgs.md
+++ /dev/null
@@ -1,350 +0,0 @@
-# CARLA messages reference
-
-The following reference lists all the CARLA messages available in the ROS bridge.
-
-Any doubts regarding these messages or the CARLA-ROS bridge can be solved in the forum.
-
-
-
----
-## CarlaActorInfo.msg
-
-Information shared between ROS and CARLA regarding an actor.
-
-| Field | Type | Description |
-| ---------------------------------------------------------- | ---------------------------------------------------------- | ---------------------------------------------------------- |
-| `id` | uint32 | The ID of the actor. |
-| `parent_id` | uint32 | The ID of the parent actor. \`0\` if no parent available. |
-| `type` | string | The identifier of the blueprint this actor was based on. |
-| `rolename` | string | Role assigned to the actor when spawned. |
-
-
-
-
----
-## CarlaActorList.msg
-
-A list of messages with some basic information for CARLA actors.
-
-| Field | Type | Description |
-| -------------------------------------------------------- | -------------------------------------------------------- | -------------------------------------------------------- |
-| `actors` | [CarlaActorInfo](<#carlaactorinfomsg>) | List of messages with actors' information. |
-
-
-
----
-## CarlaCollisionEvent.msg
-
-Data retrieved on a collision event detected by the collision sensor of an actor.
-
-| Field | Type | Description |
-| ------------------------------------------------------------------------- | ------------------------------------------------------------------------- | ------------------------------------------------------------------------- |
-| `header` | [Header]() | Time stamp and frame ID when the message is published. |
-| `other_actor_id` | uint32 | ID of the actor against whom the collision was detected. |
-| `normal_impulse` | geometry\_msgs/Vector3 | Vector representing resulting impulse from the collision. |
-
-
-
-
----
-## CarlaControl.msg
-
-These messages control the simulation while in synchronous mode. The constant defined is translated as stepping commands.
-
-| Field | Type | Description |
-| ----------------------------------------------------------- | ----------------------------------------------------------- | ----------------------------------------------------------- |
-| `command` | int8 | **PLAY**=0 **PAUSE**=1 **STEP\_ONCE**=2 |
-
-
-
-!!! Important
- In synchronous mode, only the ROS bridge client is allowed to tick.
-
----
-## CarlaEgoVehicleControl.msg
-
-Messages sent to apply a control to a vehicle in both modes, autopilot and manual. These are published in a stack.
-
-| Field | Type | Description |
-| ------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
-| `header` | [Header]() | Time stamp and frame ID when the message is published. |
-| `throttle` | float32 | Scalar value to cotrol the vehicle throttle: **[0.0, 1.0]** |
-| `steer` | float32 | Scalar value to control the vehicle steering direction: **[-1.0, 1.0]** to control the vehicle steering |
-| `brake` | float32 | Scalar value to control the vehicle brakes: **[0.0, 1.0]** |
-| `hand_brake` | bool | If **True**, the hand brake is enabled. |
-| `reverse` | bool | If **True**, the vehicle will move reverse. |
-| `gear` | int32 | Changes between the available gears in a vehicle. |
-| `manual_gear_shift` | bool | If **True**, the gears will be shifted using `gear`. |
-
-
----
-## CarlaEgoVehicleInfo.msg
-
-Static information regarding a vehicle, mostly the attributes used to define the vehicle's physics.
-
-| Field | Type | Description |
-| -------------------------------------------------------------- | -------------------------------------------------------------- | -------------------------------------------------------------- |
-| `id` | uint32 | ID of the vehicle actor. |
-| `type` | string | The identifier of the blueprint this vehicle was based on. |
-| `type` | string | The identifier of the blueprint this vehicle was based on. |
-| `rolename` | string | Role assigned to the vehicle. |
-| `wheels` | [CarlaEgoVehicleInfoWheel](<#carlaegovehicleinfowheelmsg>) | List of messages with information regarding wheels. |
-| `max_rpm` | float32 | Maximum RPM of the vehicle's engine. |
-| `moi` | float32 | Moment of inertia of the vehicle's engine. |
-| `damping_rate_full_throttle` | float32 | Damping rate when the throttle is at maximum. |
-| `damping_rate_zero_throttle` `_clutch_engaged` | float32 | Damping rate when the throttle is zero with clutch engaged. |
-| `damping_rate_zero_throttle` `_clutch_disengaged` | float32 | Damping rate when the throttle is zero with clutch disengaged. |
-| `use_gear_autobox` | bool | If **True**, the vehicle will have an automatic transmission. |
-| `gear_switch_time` | float32 | Switching time between gears. |
-| `clutch_strength` | float32 | The clutch strength of the vehicle. Measured in **Kgm^2/s**. |
-| `mass` | float32 | The mass of the vehicle measured in Kg. |
-| `drag_coefficient` | float32 | Drag coefficient of the vehicle's chassis. |
-| `center_of_mass` | geometry\_msgs/Vector3 | The center of mass of the vehicle. |
-
-
-
-
-
----
-## CarlaEgoVehicleInfoWheel.msg
-
-Static information regarding a wheel that will be part of a [CarlaEgoVehicleInfo.msg](#carlaegovehicleinfomsg) message.
-
-| Field | Type | Description |
-| -------------------------------------------------------- | -------------------------------------------------------- | -------------------------------------------------------- |
-| `tire_friction` | float32 | A scalar value that indicates the friction of the wheel. |
-| `damping_rate` | float32 | The damping rate of the wheel. |
-| `max_steer_angle` | float32 | The maximum angle in degrees that the wheel can steer. |
-| `radius` | float32 | The radius of the wheel in centimeters. |
-| `max_brake_torque` | float32 | The maximum brake torque in Nm. |
-| `max_handbrake_torque` | float32 | The maximum handbrake torque in Nm. |
-| `position` | geometry\_msgs/Vector3 | World position of the wheel. |
-
-
-
-
----
-## CarlaEgoVehicleStatus.msg
-
-Current status of the vehicle as an object in the world.
-
-| Field | Type | Description |
-| ------------------------------------------------------------------------- | ------------------------------------------------------------------------- | ------------------------------------------------------------------------- |
-| `header` | [Header]() | Time stamp and frame ID when the message is published. |
-| `velocity` | float32 | Current speed of the vehicle. |
-| `acceleration` | geometry\_msgs/Accel | Current acceleration of the vehicle. |
-| `orientation` | geometry\_msgs/Quaternion | Current orientation of the vehicle. |
-| `control` | [CarlaEgoVehicleControl](<#carlaegovehiclecontrolmsg>) | Current control values as reported by CARLA. |
-
-
-
-
-
----
-## CarlaLaneInvasionEvent.msg
-
-These messages publish lane invasions detected by a lane-invasion sensor attached to a vehicle. The invasions detected in the last step are passed as a list with a constant definition to identify the lane crossed.
-
-
-
-| Field | Type | Description |
-| ---------------------------------------------------- | ---------------------------------------------------- | ---------------------------------------------------- |
-| `header` | [header]() | Time stamp and frame ID when the message is published. |
-| `crossed_lane_markings` | int32[] | **LANE\_MARKING\_OTHER**=0 **LANE\_MARKING\_BROKEN**=1 **LANE\_MARKING\_SOLID**=2 |
-
-
-
-
----
-## CarlaScenario.msg
-
-Details for a test scenario.
-
-
-| Field | Type | Description |
-| ---------------------------------- | ---------------------------------- | ---------------------------------- |
-| `name` | string | Name of the scenario. |
-| `scenario_file` | string | Test file for the scenario. |
-| `destination` | geometry\_msgs/Pose | Goal location of the scenario. |
-| `target_speed` | float64 | Desired speed during the scenario. |
-
-
-
-
----
-## CarlaScenarioList.msg
-
-List of test scenarios to run in ScenarioRunner.
-
-
-| Field | Type | Description |
-| -------------------------------------- | -------------------------------------- | -------------------------------------- |
-| `scenarios` | [CarlaScenario[]](<#carlascenariomsg>) | List of scenarios. |
-
-
-
-
----
-## CarlaScenarioRunnerStatus.msg
-
-Current state of the ScenarioRunner. It is managed using a constant.
-
-
-| Field | Type | Description |
-| ------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `status` | uint8 | Current state of the scenario as an enum: **STOPPED**=0 **STARTING**=1 **RUNNING**=2 **SHUTTINGDOWN**=3 **ERROR**=4 |
-
-
-
-## CarlaStatus.msg
-
-Current world settings of the simulation.
-
-
-| Field | Type | Description |
-| -------------------------------------------------- | -------------------------------------------------- | -------------------------------------------------- |
-| `frame` | uint64 | Current frame number. |
-| `fixed_delta_seconds` | float32 | Simulation time between last and current step. |
-| `synchronous_mode` | bool | If **True**, synchronous mode is enabled. |
-| `synchronous_mode_running` | bool | **True** when the simulation is running. **False** when it is paused. |
-
-
-
-## CarlaTrafficLightStatus.msg
-
-Constant definition regarding the state of a traffic light.
-
-| Field | Type | Description |
-| ---------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- |
-| `id` | uint32 | ID of the traffic light actor. |
-| `state` | uint8 | **RED**=0 **YELLOW**=1 **GREEN**=2 **OFF**=3 **UNKNOWN**=4 |
-
-
-
-## CarlaTrafficLightStatusList.msg
-
-List of traffic lights with their status.
-
-| Field | Type | Description |
-| ---------------------------------------------------------- | ---------------------------------------------------------- | ---------------------------------------------------------- |
-| `scenarios` | [CarlaTrafficLightStatus[]](<#carlatrafficlightstatusmsg>) | A list of messages summarizing traffic light states. |
-
-
-
-## CarlaWalkerControl.msg
-
-Information needed to apply a movement controller to a walker.
-
-| Field | Type | Description |
-| ------------------------------------------------- | ------------------------------------------------- | ------------------------------------------------- |
-| `direction` | geometry\_msgs/Vector3 | Vector that controls the direction of the walker. |
-| `speed` | float32 | A scalar value to control the walker's speed. |
-| `jump` | bool | If **True**, the walker will jump. |
-
-
-
-## CarlaWaypoint.msg
-
-Data contained in a waypoint object.
-
-| Field | Type | Description |
-| ---------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
-| `road_id` | int32 | OpenDRIVE road's id. |
-| `section_id` | int32 | OpenDRIVE section's id, based on the order that they are originally defined. |
-| `lane_id` | int32 | OpenDRIVE lane's id, this value can be positive or negative which represents the direction of the current lane with respect to the road. |
-| `is_junction` | bool | **True**, if the current Waypoint is on a junction as defined by OpenDRIVE. |
-| `is_junction` | [geometry\_msgs/Pose]() | **True** when the simulation is running. **False** when it is paused. |
-
-
-
-## CarlaWorldInfo.msg
-
-Information about the current CARLA map.
-
-| Field | Type | Description |
-| ---------------------------------------------------- | ---------------------------------------------------- | ---------------------------------------------------- |
-| `map_name` | string | Name of the CARLA map loaded in the current world. |
-| `opendrive` | string | .xodr OpenDRIVE file of the current map as a string. |
-
-
-
-## EgoVehicleControlCurrent.msg
-
-Current time, speed and acceleration values of the vehicle. Used by the controller. It is part of a `Carla_Ackermann_Control.EgoVehicleControlInfo.msg` message.
-
-| Field | Type | Description |
-| ----------------------------------------------- | ----------------------------------------------- | ----------------------------------------------- |
-| `time_sec` | float32 | Current time when the controller is applied. |
-| `speed` | float32 | Current speed applied by the controller. |
-| `speed_abs` | float32 | Speed as an absolute value. |
-| `accel` | float32 | Current acceleration applied by the controller. |
-
-
-
-## EgoVehicleControlInfo.msg
-
-Current values within an Ackermann controller. These messages are useful for debugging.
-
-| Field | Type | Description |
-| ------------------------------------------------------------------------- | ------------------------------------------------------------------------- | ------------------------------------------------------------------------- |
-| `header` | [header]() | Time stamp and frame ID when the message is published. |
-| `restrictions` | [EgoVehicleControlMaxima](<#egovehiclecontrolmaximamsg>) | Limits to the controller values. |
-| `target` | [EgoVehicleControlTarget](<#egovehiclecontroltargetmsg>) | Limits to the controller values. |
-| `current` | [EgoVehicleControlCurrent](<#egovehiclecontrolcurrentmsg>) | Limits to the controller values. |
-| `status` | [EgoVehicleControlStatus](<#egovehiclecontrolstatusmsg>) | Limits to the controller values. |
-| `output` | [CarlaEgoVehicleControl](<#carlaegovehiclecontrolmsg>) | Limits to the controller values. |
-
-
-
-## EgoVehicleControlMaxima.msg
-
-Controller restrictions (limit values). It is part of a `Carla_Ackermann_Control.EgoVehicleControlInfo.msg` message.
-
-| Field | Type | Description |
-| -------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- |
-| `max_steering_angle` | float32 | Max. steering angle for a vehicle. |
-| `max_speed` | float32 | Max. speed for a vehicle. |
-| `max_accel` | float32 | Max. acceleration for a vehicle. |
-| `max_decel` | float32 | Max. deceleration for a vehicle. Default: **8m/s^2** |
-| `min_accel` | float32 | Min. acceleration for a vehicle. When the Ackermann taget accel. exceeds this value, the input accel. is controlled. |
-| `max_pedal` | float32 | Min. pedal. |
-
-
-
-## EgoVehicleControlStatus.msg
-
-Current status of the ego vehicle controller. It is part of a `Carla_Ackermann_Control.EgoVehicleControlInfo.msg` message.
-
-| Field | Type | Description |
-| -------------------------------- | -------------------------------- | -------------------------------- |
-| `status` | string | Current control status. |
-| `speed_control_activation_count` | uint8 | Speed controller. |
-| `speed_control_accel_delta` | float32 | Speed controller. |
-| `speed_control_accel_target` | float32 | Speed controller. |
-| `accel_control_pedal_delta` | float32 | Acceleration controller. |
-| `accel_control_pedal_target` | float32 | Acceleration controller. |
-| `brake_upper_border` | float32 | Borders for lay off pedal. |
-| `throttle_lower_border` | float32 | Borders for lay off pedal. |
-
-
-
-
-## EgoVehicleControlTarget.msg
-
-Target values of the ego vehicle controller. It is part of a `Carla_Ackermann_Control.EgoVehicleControlInfo.msg` message.
-
-| Field | Type | Description |
-| ----------------------------------------- | ----------------------------------------- | ----------------------------------------- |
-| `steering_angle` | float32 | Target steering angle for the controller. |
-| `speed` | float32 | Target speed for the controller. |
-| `speed_abs` | float32 | Speed as an absolute value. |
-| `accel` | float32 | Target acceleration for the controller. |
-| `jerk` | float32 | Target jerk for the controller. |
-
-
diff --git a/Docs/start_introduction.md b/Docs/start_introduction.md
index 753b021d4..5ba1ab1ba 100644
--- a/Docs/start_introduction.md
+++ b/Docs/start_introduction.md
@@ -3,8 +3,8 @@
![Welcome to CARLA](img/welcome.png)
!!! important
- This documentation refers to the latest development versions of CARLA, 0.9.0 or
- later. There is another documentation for the stable version 0.8 [here](https://carla.readthedocs.io/en/stable/getting_started/), though it should only be used for specific queries.
+ This document refers to the latest version of CARLA. For documentation of previous versions, select the required version in the bottom right hand corner where you see this button: ![docs_version_panel](img/docs_version_panel.jpg)
+
CARLA is an open-source autonomous driving simulator. It was built from scratch to serve as a modular and flexible API to address a range of tasks involved in the problem of autonomous driving. One of the main goals of CARLA is to help democratize autonomous driving R&D, serving as a tool that can be easily accessed and customized by users. To do so, the simulator has to meet the requirements of different use cases within the general problem of driving (e.g. learning driving policies, training perception algorithms, etc.). CARLA is grounded on Unreal Engine to run the simulation and uses the OpenDRIVE standard (1.4 as today) to define roads and urban settings. Control over the simulation is granted through an API handled in Python and C++ that is constantly growing as the project does.
diff --git a/Docs/start_quickstart.md b/Docs/start_quickstart.md
index 4f48f64ec..0b0c59e68 100644
--- a/Docs/start_quickstart.md
+++ b/Docs/start_quickstart.md
@@ -1,99 +1,94 @@
-# Quick start
+# Quick start package installation
-* __[Installation summary](#installation-summary)__
-* __[Requirements](#requirements)__
+This guide shows how to download and install the packaged version of CARLA. The package includes the CARLA server and two options for the client library. There are additional assets that can be downloaded and imported into the package. Advanced customization and development options that require use of the Unreal Engine editor are not available but these can be accessed by using the build version of CARLA for either [Windows](build_windows.md) or [Linux](build_linux.md).
+
+* __[Before you begin](#before-you-begin)__
* __[CARLA installation](#carla-installation)__
* [A. Debian CARLA installation](#a-debian-carla-installation)
* [B. Package installation](#b-package-installation)
* __[Import additional assets](#import-additional-assets)__
+* __[Install client library](#install-client-library)__
+ * [CARLA versions prior to 0.9.12](#carla-versions-prior-to-0912)
+ * [CARLA 0.9.12+](#carla-0912)
* __[Running CARLA](#running-carla)__
* [Command-line options](#command-line-options)
-* __[Updating CARLA](#updating-carla)__
-* __[Follow-up](#follow-up)__
-
+* __[Updating CARLA](#updating-carla)__
+* __[Follow-up](#follow-up)__
---
-## Installation summary
+## Before you begin
-
-
- Show command line summary for the quick start installation
-
+The following requirements should be fulfilled before installing CARLA:
+
+* __System requirements.__ CARLA is built for Windows and Linux systems.
+* __An adequate GPU.__ CARLA aims for realistic simulations, so the server needs at least a 6 GB GPU although we would recommend 8 GB. A dedicated GPU is highly recommended for machine learning.
+* __Disk space.__ CARLA will use about 20 GB of space.
+* __Python.__ [Python]((https://www.python.org/downloads/)) is the main scripting language in CARLA. CARLA supports Python 2.7 and Python 3 on Linux, and Python 3 on Windows.
+* __Pip.__ Some installation methods of the CARLA client library require __pip__ or __pip3__ (depending on your Python version) version 20.3 or higher. To check your __pip__ version:
+
+>> # For Python 3
+>> pip3 -V
+
+>> # For Python 2
+>> pip -V
+
+>If you need to upgrade:
+
+>> # For Python 3
+>> pip3 install --upgrade pip
+
+>> # For Python 2
+>> pip install --upgrade pip
+
+* __Two TCP ports and good internet connection.__ 2000 and 2001 by default. Make sure that these ports are not blocked by firewalls or any other applications.
+* __Other requirements.__ CARLA requires some Python dependencies. Install the dependencies according to your operating system:
+
+### Windows
```sh
-# Install required modules Pygame and Numpy
- pip install --user pygame numpy
-
-# There are two different ways to install CARLA
-
-# Option A) Debian package installation
-# This repository contains CARLA 0.9.10 and later. To install previous CARLA versions, change to a previous version of the docs using the pannel in the bottom right part of the window
-sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 1AF1527DE64CB8D9
-sudo add-apt-repository "deb [arch=amd64] http://dist.carla.org/carla $(lsb_release -sc) main"
-sudo apt-get update
-sudo apt-get install carla-simulator # Install the latest CARLA version or update the current installation
-sudo apt-get install carla-simulator=0.9.10-1 # install a specific CARLA version
-cd /opt/carla-simulator
-./CarlaUE4.sh
-
-# Option B) Package installation
-# Go to: https://github.com/carla-simulator/carla/blob/master/Docs/download.md
-# Download the desired package and additional assets
-# Extract the package
-# Extract the additional assets in `/Import`
-# Run CARLA (Linux).
-./CarlaUE.sh
-# Run CARLA (Windows)
-> CarlaUE4.exe
-
-# Run a script to test CARLA.
-cd PythonAPI/examples
-python3 spawn_npc.py # Support for Python2 is provided in the CARLA release packages
-
+pip3 install --user pygame numpy
```
-
----
-## Requirements
+### Linux
-The quick start installation uses a pre-packaged version of CARLA. The content is comprised in a boundle that can run automatically with no build installation needed. The API can be accesseded fully but advanced customization and development options are unavailable.
-The requirements are simpler than those for the build installation.
-
-* __Server side.__ A 4GB minimum GPU will be needed to run a highly realistic environment. A dedicated GPU is highly advised for machine learning.
-* __Client side.__ [Python](https://www.python.org/downloads/) is necessary to access the API via command line. Also, a good internet connection and two TCP ports (2000 and 2001 by default).
-* __System requirements.__ Any 64-bits OS should run CARLA. However, since release 0.9.9, __CARLA cannot run in 16.04 Linux systems with default compilers__. These should be upgraded to work with CARLA.
-* __Other requirements.__ Two Python modules: [Pygame](https://pypi.org/project/pygame/) to create graphics directly with Python, and [Numpy](https://pypi.org/project/numpy/) for great calculus.
-
-To install both modules using [pip](https://pip.pypa.io/en/stable/installing/), run the following commands.
```sh
- pip install --user pygame numpy
-```
+pip install --user pygame numpy &&
+pip3 install --user pygame numpy
+```
+
---
## CARLA installation
-The __Debian installation__ is the easiest way to get the latest release in Linux.
-__Download the GitHub repository__ to get either a specific release or the Windows version of CARLA.
+There are two methods to download and install CARLA as a package:
+
+__A)__ [Download the Debian package.](#a-debian-carla-installation)
+
+__B)__ [Download the package from GitHub.](#b-package-installation)
### A. Debian CARLA installation
-Set up the Debian repository in the system.
+The Debain package is available for both Ubuntu 18.04 and Ubuntu 20.04, however __the officially supported platform is Ubuntu 18.04__.
+
+__1.__ Set up the Debian repository in the system:
```sh
-sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 1AF1527DE64CB8D9
-sudo add-apt-repository "deb [arch=amd64] http://dist.carla.org/carla $(lsb_release -sc) main"
-```
-Install CARLA and check for the installation in the `/opt/` folder.
-```sh
-sudo apt-get update # Update the Debian package index
-sudo apt-get install carla-simulator # Install the latest CARLA version, or update the current installation
-cd /opt/carla-simulator # Open the folder where CARLA is installed
+ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 1AF1527DE64CB8D9
+ sudo add-apt-repository "deb [arch=amd64] http://dist.carla.org/carla $(lsb_release -sc) main"
```
-This repository contains CARLA 0.9.10 and later versions. To install a specific version add the version tag to the installation command.
+__2.__ Install CARLA and check for the installation in the `/opt/` folder:
```sh
-sudo apt-get install carla-simulator=0.9.10-1 # In this case, "0.9.10" refers to a CARLA version, and "1" to the Debian revision
+ sudo apt-get update # Update the Debian package index
+ sudo apt-get install carla-simulator # Install the latest CARLA version, or update the current installation
+ cd /opt/carla-simulator # Open the folder where CARLA is installed
+```
+
+This repository contains CARLA 0.9.10 and later versions. To install a specific version add the version tag to the installation command:
+```sh
+ apt-cache madison carla-simulator # List the available versions of Carla
+ sudo apt-get install carla-simulator=0.9.10-1 # In this case, "0.9.10" refers to a CARLA version, and "1" to the Debian revision
```
!!! Important
- To install CARLA versions prior to 0.9.10, change to a previous version of the documentation using the pannel in the bottom right corner of the window, and follow the old instructions.
+ To install CARLA versions prior to 0.9.10, change to a previous version of the documentation using the panel in the bottom right corner of the window, and follow the old instructions.
### B. Package installation
@@ -104,86 +99,184 @@ sudo apt-get install carla-simulator=0.9.10-1 # In this case, "0.9.10" refers to
-The repository contains different versions of the simulator available. _Development_ and _stable_ sections list the packages for the different official releases. The later the version the more experimental it is. The _nightly build_ is the current development version as today and so, the most unstable.
+This repository contains different versions of CARLA. You will find options to download the __current release__ with all the most recent fixes and features, __previous releases__ and a __nightly build__ with all the developmental fixes and features (the nightly build is the most unstable version of CARLA).
-There may be many files per release. The package is a compressed file named as __CARLA_version.number__.
-
-Download and extract the release file. It contains a precompiled version of the simulator, the Python API module and some scripts to be used as examples.
+The package is a compressed file named __CARLA_version.number__. Download and extract the release file. It contains a precompiled version of the simulator, the Python API module and some scripts to be used as examples.
---
## Import additional assets
-For every release there are other packages containing additional assets and maps, such as __Additional_Maps_0.9.9.2__ for CARLA 0.9.9.2, which contains __Town06__, __Town07__, and __Town10__. These are stored separatedly to reduce the size of the build, so they can only be run after these packages are imported.
+Each release has it's own additional package of extra assets and maps. This additional package includes the maps __Town06__, __Town07__, and __Town10__. These are stored separately to reduce the size of the build, so they can only be imported after the main package has been installed.
-Download and move the package to the _Import_ folder, and run the following script to extract them.
+__1.__ [Download](https://github.com/carla-simulator/carla/blob/master/Docs/download.md) the appropriate package for your desired version of CARLA.
+
+__2.__ Extract the package:
+
+- __On Linux__:
+
+ - move the package to the _Import_ folder and run the following script to extract the contents:
```sh
-> cd ~/carla
-> ./ImportAssets.sh
+ cd path/to/carla/root
+
+ ./ImportAssets.sh
```
-!!! Note
- On Windows, directly extract the package on the root folder.
+- __On Windows__:
+
+ - Extract the contents directly in the root folder.
+
+---
+
+## Install client library
+
+### CARLA versions prior to 0.9.12
+
+Previous versions of CARLA did not require the Python library to be installed, they came with an `.egg` file that was ready to use out of the box. __CARLA versions 0.9.12+ change this behavior significantly; there are several options available to install the client library.__ If you are using a version of CARLA prior to 0.9.12, please select that version in the bottom right corner of the screen to see the relevant documentation. Otherwise, read on below about the available options in CARLA 0.9.12+.
+
+### CARLA 0.9.12+
+
+There are several options available to install and use the CARLA client library:
+
+- __.egg__ file
+- __.whl__ file
+- __Downloadable Python package__
+
+Read more below about the requirements and limitations of each method before deciding which one to use. Please note that mixing the different methods can lead to incompatibilities, so use virtual environments when possible or [uninstall](build_faq.md#how-do-i-uninstall-the-carla-client-library) a previously installed library before using a new one.
+
+>__A. .egg files__
+
+>>CARLA provides `.egg` files in `PythonAPI/carla/dist/` for different Python versions that are ready to use out of the box. Each of the example scripts in `PythonAPI/examples` includes a [code snippet](build_system.md#versions-prior-to-0912) that looks for this file automatically. In Linux, you may need to add this file to your `PYTHONPATH`. Read more about `.egg` files in CARLA [here](build_faq.md#importerror-no-module-named-carla).
+
+>>__If you have previously installed the client library with `pip`, this will take precedence over the `.egg` file__. You will need to [uninstall](build_faq.md#how-do-i-uninstall-the-carla-client-library) the previous library first.
+
+>__B. .whl files__
+
+>>CARLA provides `.whl` files for different Python versions. You will need to install the `.whl` file. The `.whl` file is found in `PythonAPI/carla/dist/`. There is one file per supported Python version, indicated by the file name (e.g., carla-0.9.12-__cp36__-cp36m-manylinux_2_27_x86_64.whl indicates Python 3.6).
+
+>>__It is recommended to install the CARLA client library in a virtual environment to avoid conflicts when working with multiple versions.__
+
+>>To install the CARLA client library, run the following command, choosing the file appropriate to your desired Python version. You will need __pip/pip3__ version 20.3 or above. See the [__Before you begin__](#before-you-begin) section for how to check the version and upgrade __pip/pip3__:
+
+>> # Python 3
+>> pip3 install .whl
+
+>> # Python 2
+>> pip install .whl
+
+>>If you previously installed the client library, you should [uninstall](build_faq.md#how-do-i-uninstall-the-carla-client-library) the old one before installing the new one.
+
+>__C. Downloadable Python package__
+
+>>The CARLA client library can be downloaded from [PyPi](https://pypi.org/project/carla/). This library is compatible with Python versions 2.7, 3.6, 3.7, and 3.8. To install it you will need __pip/pip3__ version 20.3 or above. See the [__Before you begin__](#before-you-begin) section for how to check the version and upgrade __pip/pip3__.
+
+>>__It is recommended to install the CARLA client library in a virtual environment to avoid conflicts when working with multiple versions.__
+
+>>To install the client library from PyPi, run the following command:
+
+>> # Python 3
+>> pip3 install carla
+
+>> # Python 2
+>> pip install carla
+
+>>The PyPi download is suitable for use with CARLA packages only (i.e., not with a version built from source). Since the PyPi download __only contains the client library__, it is most useful in situations where you will be communicating with a remote CARLA server where you do not require downloading a full CARLA package.
---
## Running CARLA
-Open a terminal in the main CARLA folder. Run the following command to execute the package file and start the simulation:
+The method to start a CARLA server depends on the installation method you used and your operating system:
+
+- Debian installation:
```sh
-# Linux:
-> ./CarlaUE4.sh
-# Windows:
-> CarlaUE4.exe
-```
-!!! Important
- In the __deb installation__, `CarlaUE4.sh` will be in `/opt/carla-simulator/bin/`, instead of the main `carla/` folder where it normally is.
+ cd /opt/carla-simulator/bin/
-A window containing a view over the city will pop up. This is the _spectator view_. To fly around the city use the mouse and `WASD` keys (while clicking). The server simulator is now running and waiting for a client to connect and interact with the world.
-Now it is time to start running scripts. The following example will spawn some life into the city:
+ ./CarlaUE4.sh
+```
+
+- Linux package installation:
```sh
-# Go to the folder containing example scripts
-> cd PythonAPI/examples
+ cd path/to/carla/root
-> python3 spawn_npc.py # Support for Python2 is provided in the CARLA release packages
+ ./CarlaUE4.sh
```
+- Windows package installation:
+
+```sh
+ cd path/to/carla/root
+
+ CarlaUE4.exe
+```
+
+A window containing a view over the city will pop up. This is the _spectator view_. To fly around the city use the mouse and `WASD` keys, holding down the right mouse button to control the direction.
+
+This is the server simulator which is now running and waiting for a client to connect and interact with the world. You can try some of the example scripts to spawn life into the city and drive a car:
+
+```sh
+ # Terminal A
+ cd PythonAPI\examples
+
+ python3 -m pip install -r requirements.txt # Support for Python2 is provided in the CARLA release packages
+
+ python3 generate_traffic.py
+
+ # Terminal B
+ cd PythonAPI\examples
+
+ python3 manual_control.py
+```
#### Command-line options
-There are some configuration options available when launching CARLA.
+There are some configuration options available when launching CARLA and they can be used as follows:
+
+```sh
+ ./CarlaUE4.sh -carla-rpc-port=3000
+```
* `-carla-rpc-port=N` Listen for client connections at port `N`. Streaming port is set to `N+1` by default.
* `-carla-streaming-port=N` Specify the port for sensor data streaming. Use 0 to get a random unused port. The second port will be automatically set to `N+1`.
* `-quality-level={Low,Epic}` Change graphics quality level. Find out more in [rendering options](adv_rendering_options.md).
-* __[Full list of UE4 command-line arguments][ue4clilink].__ There is a lot of options provided by UE. However, not all of these will be available in CARLA.
+* __[List of Unreal Engine 4 command-line arguments][ue4clilink].__ There are a lot of options provided by Unreal Engine however not all of these are available in CARLA.
[ue4clilink]: https://docs.unrealengine.com/en-US/Programming/Basics/CommandLineArguments
-```sh
-> ./CarlaUE4.sh -carla-rpc-port=3000
-```
-The script `PythonAPI/util/config.py` provides for more configuration options.
+
+The script [`PythonAPI/util/config.py`][config] provides more configuration options and should be run when the server has been started:
+
+[config]: https://github.com/carla-simulator/carla/blob/master/PythonAPI/util/config.py
```sh
-> ./config.py --no-rendering # Disable rendering
-> ./config.py --map Town05 # Change map
-> ./config.py --weather ClearNoon # Change weather
+ ./config.py --no-rendering # Disable rendering
+ ./config.py --map Town05 # Change map
+ ./config.py --weather ClearNoon # Change weather
-> ./config.py --help # Check all the available configuration options
+ ./config.py --help # Check all the available configuration options
```
---
## Updating CARLA
-The packaged version requires no updates. The content is bundled and thus, tied to a specific version of CARLA. Everytime there is a release, the repository will be updated. To run this latest or any other version, delete the previous and install the one desired.
+There is no way to update the packaged version of CARLA. When a new version is released, the repository is updated and you will need to delete the previous version and install the new version.
+
+If you installed the client library using __pip/pip3__, you should uninstall it by running:
+
+```sh
+# Python 3
+pip3 uninstall carla
+
+# Python 2
+pip uninstall carla
+```
---
## Follow-up
-Thus concludes the quick start installation process. In case any unexpected error or issue occurs, the [CARLA forum](https://forum.carla.org/) is open to everybody. There is an _Installation issues_ category to post this kind of problems and doubts.
+By now you should have a packaged version of CARLA up and running. If you came across any difficulties during the installation process, feel free to post in the [CARLA forum](https://github.com/carla-simulator/carla/discussions/) or in the [Discord](https://discord.gg/8kqACuC) channel.
-So far, CARLA should be operative in the desired system. Terminals will be used to contact the server via script, interact with the simulation and retrieve data. To do so, it is essential to understand the core concepts in CARLA. Read the __First steps__ section to learn on those. Additionally, all the information about the Python API regarding classes and its methods can be accessed in the [Python API reference](python_api.md).
+The next step is to learn more about the core concepts in CARLA. Read the __First steps__ section to start learning. You can also find all the information about the Python API classes and methods in the [Python API reference](python_api.md).
diff --git a/Docs/ts_traffic_simulation_overview.md b/Docs/ts_traffic_simulation_overview.md
new file mode 100644
index 000000000..838c2edea
--- /dev/null
+++ b/Docs/ts_traffic_simulation_overview.md
@@ -0,0 +1,100 @@
+# Traffic Simulation in CARLA
+
+Traffic simulation is integral to the accurate and efficient training and testing of autonomous driving stacks. CARLA provides a number of different options to simulate traffic and specific traffic scenarios. This section is an overview of the options available to help decide which is the best fit for your use case.
+
+- [__Scenario Runner and OpenScenario__](#scenario-runner-and-openscenario)
+- [__Traffic Manager__](#traffic-manager)
+- [__Scenic__](#scenic)
+- [__SUMO__](#sumo)
+
+---
+
+## Scenario Runner and OpenScenario
+
+Scenario Runner provides [predefined traffic scenarios](https://carla-scenariorunner.readthedocs.io/en/latest/list_of_scenarios/) out of the box and also allows users to [define their own](https://carla-scenariorunner.readthedocs.io/en/latest/creating_new_scenario/) scenarios using either Python or the [OpenSCENARIO 1.0 standard](https://releases.asam.net/OpenSCENARIO/1.0.0/ASAM_OpenSCENARIO_BS-1-2_User-Guide_V1-0-0.html#_foreword).
+
+The primary use of OpenSCENARIO is the description of complex maneuvers that involve multiple vehicles. Users can see which features of OpenSCENARIO are supported by Scenario Runner [here](https://carla-scenariorunner.readthedocs.io/en/latest/openscenario_support/). These features include Maneuvers, Actions, Conditions, Stories and the Storyboard.
+
+Scenario Runner has to be installed [separately](https://github.com/carla-simulator/scenario_runner) from the main CARLA package.
+
+__Useful for:__
+
+- Creating complex traffic scenarios and routes to prepare AD agents for evaluation in the [CARLA leaderboard](https://leaderboard.carla.org/).
+- Defining bespoke [metrics](https://carla-scenariorunner.readthedocs.io/en/latest/metrics_module/) that can be run against recordings of the scenario simulation, foregoing the need to run simulations repeatedly.
+
+
+
+---
+
+## Traffic Manager
+
+Traffic Manager is a module within CARLA that controls certain vehicles in a simulation from the client side. Vehicles are registered to Traffic Manager via the [`carla.Vehicle.set_autopilot`](https://carla.readthedocs.io/en/latest/python_api/#carla.Vehicle.set_autopilot) method or [`command.SetAutopilot`](https://carla.readthedocs.io/en/latest/python_api/#commandsetautopilot) class. Control of each vehicle is managed through a cycle of [distinct stages](adv_traffic_manager.md#stages) which each run on a different thread.
+
+__Useful for:__
+
+- Populating a simulation with realistic urban traffic conditions.
+- [Customizing traffic behaviours](adv_traffic_manager.md#general-considerations) to set specific learning circumstances.
+- Developing phase-related functionalities and data structures while improving computational efficiency.
+
+
+
+---
+
+## Scenic
+
+[Scenic](https://scenic-lang.readthedocs.io) is a domain-specific probabilistic programming language for modeling the environments of cyber-physical systems like robots and autonomous cars. Scenic provides an [specialized domain](https://scenic-lang.readthedocs.io/en/latest/modules/scenic.simulators.carla.html) to facilitate execution of Scenic scripts on the CARLA simulator.
+
+Scenic scenario definitions are easy to read and construct. A tutorial to create a simple scenario is provided [here](tuto_G_scenic.md).
+
+__Useful for:__
+
+- Generating multiple, diverse scenarios with a single scenario definition.
+- Defining probabilistic policies for dynamic agents to take actions over time in response to the state of the world.
+
+
+
+---
+
+## SUMO
+
+[SUMO](https://sumo.dlr.de/docs/SUMO_at_a_Glance.html) is an open source, microscopic, multi-modal traffic simulation. In SUMO, each vehicle is modelled explicitly, has its own route, and moves individually through the network. Simulations are deterministic by default but there are various options for introducing randomness.
+
+CARLA provides a co-simulation feature with SUMO that allows distribution of tasks between the two simulators. Vehicles can be spawned in CARLA through SUMO, and managed by SUMO much as the Traffic Manager would do.
+
+__Useful for:__
+
+- Exploitation of the capabilities of both CARLA and SUMO in one package.
+
+
+
+---
+
+If you have any doubts about the different options available to simulate traffic in CARLA, feel free to post in the forum or in [Discord](https://discord.gg/8kqACuC).
+
+
+
diff --git a/Docs/tuto_A_add_map.md b/Docs/tuto_A_add_map.md
deleted file mode 100644
index 67deaa404..000000000
--- a/Docs/tuto_A_add_map.md
+++ /dev/null
@@ -1,517 +0,0 @@
-# Add a new map
-
-Users can create their own maps, and run CARLA using these. The creation of the map object is quite independent from CARLA. Nonetheless, the process to ingest it has been refined to be automatic. Thus, the new map can be used in CARLA almost out-of-the-box.
-
-* [__Introduction__](#introduction)
-* [__Create a map with RoadRunner__](#create-a-map-with-roadrunner)
- * [Export from RoadRunner](#export-from-roadrunner)
-* [__Map ingestion in a CARLA package__](#map-ingestion-in-a-carla-package)
-* [__Map ingestion in a build from source__](#map-ingestion-in-a-build-from-source)
- * [Modify pedestrian navigation](#modify-pedestrian-navigation)
-* [__Deprecated ways to import a map__](#deprecated-ways-to-import-a-map)
-
----
-## Introduction
-
-RoadRunner is the recommended software to create a map due to its simplicity. Some basic steps on how to do it are provided in [the next section](#create-a-map-with-roadrunner). The resulting map should consist of a `.fbx` and a `.xodr` with the mesh and road network informtion respectively.
-
-The process of the map ingestion has been simplified to minimize the users' intervention. For said reason, there are certains steps have been automatized.
-
-* __Package `.json` file and folder structure__. Normally packages need a certain folder structure and a `.json` file describing them to be imported. However, as regards the map ingestion, this can be created automatically during the process.
-* __Traffic signs and traffic lights.__ The simulator will generate the traffic lights, stops, and yields automatically when running. These will be creatd according to their `.xodr` definition. The rest of landmarks present in the road map will not be physically on scene, but they can be queried using the API.
-* __Pedestrian navigation.__ The ingestion will generate a `.bin` file describing the pedestrian navigation. It is based on the sidewalks and crosswalks that appear in the OpenDRIVE map. This can only be modified if working in a build from source.
-
-!!! Important
- If a map contains additional elements besides the `.fbx` and `.xodr`, the package has to be [prepared manually](#prepare-the-package-manually).
-
-The map ingestion process differs, depending if the package is destined to be in a CARLA package (e.g., 0.9.9) or a build from source.
-
-There are other ways to import a map into CARLA, which are now deprecated. They require the user to manually set the map ready. Nonetheless, as they may be useful for specific cases when the user wants to customize a specific setting, they are listed in the [last section](#deprecated-ways-to-import-a-map) of this tutorial.
-
----
-## Create a map with RoadRunner
-
-RoadRunner is an accessible and powerful software from Vector Zero to create 3D scenes. Since the release of R2020b (16th September 2020), it has been added to the MATLAB Campus Wide Licenses, so many universities can provide unlimited academic access. [Check](https://www.mathworks.com/academia/tah-support-program/eligibility.html) if your university has access. Reach out to *automated-driving@mathworks.com* for any question or trouble regarding accessibility. Additionally, there is a [trial version](https://es.mathworks.com/products/roadrunner.html) available, and an [installation guide][rr_docs].
-
-[rr_docs]: https://tracetransit.atlassian.net/wiki/spaces/VS/pages/740622413/Getting+Started
-
-The process is quite straightforward, but there are some things to take into account.
-
-* __Center the map__ in (0,0).
-* __Create the map definition.__ Take a look at the [official tutorials](https://www.youtube.com/channel/UCAIXf4TT8zFbzcFdozuFEDg/playlists).
-* __Check the map validation.__ Take a close look at all connections and geometries.
-
-![CheckGeometry](img/check_geometry.jpg)
-
-Once the map is ready, click on the `OpenDRIVE Preview Tool` button to visualize the OpenDRIVE road network. Give one last check to everything. Once the map is exported, it cannot be modified.
-
-![checkopen](img/check_open.jpg)
-
-!!! note
- _OpenDrive Preview Tool_ makes it easier to test the integrity of the map. If there is any error with junctions, click on `Maneuver Tool`, and `Rebuild Maneuver Roads`.
-
-### Export from RoadRunner
-
-__1. Export the scene using the CARLA option.__ `File/Export/CARLA(.fbx+.xml+.xodr)`
-
-__2. Leave `Export individual Tiles` unchecked.__ This will generate only one _.fbx_ with all the pieces. It makes easier to keep track of the map.
-
-__3. Click `Export`.__
-
-This will generate a `mapname.fbx` and `mapname.xodr` files within others. There is more detailed information about how to export to CARLA in [VectorZero's documentation][exportlink].
-
-[exportlink]: https://tracetransit.atlassian.net/wiki/spaces/VS/pages/752779356/Exporting+to+CARLA
-
-!!! Warning
- Make sure that the .xodr and the .fbx files have the same name.
-
----
-## Map ingestion in a CARLA package
-
-This is the recommended method to import a map into a CARLA package. It will run a Docker image of Unreal Engine to import the files, and export them as a standalone package. The Docker image takes 4h and 400GB to be built. However, this is only needed the first time.
-
-__1. Build a Docker image of Unreal Engine.__ Follow [these instructions](https://github.com/carla-simulator/carla/tree/master/Util/Docker) to build the image.
-
-__2. Change permissions on the input folder.__ If no `.json` file is provided, the Docker will try to create it on the input folder. To be successful, said folder must have all permissions enabled for others.
-
-```sh
-#Go to the parent folder, where the input folder is contained
-chmod 777 input_folder
-```
-
-!!! Note
- This is not necessary if the package is [prepared manually](#prepare-the-package-manually), and contains a `.json` file.
-
-__2. Run the script to cook the map.__ In the folder `~/carla/Util/Docker` there is a script that connects with the Docker image previously created, and makes the ingestion automatically. It only needs the path for the input and output files, and the name of the package to be ingested. If no `.json` is provided, the name must be `map_package`.
-
-```sh
-python3 docker_tools.py --input ~/path_to_input_folder --output ~/path_to_output_folder --packages map_package
-```
-!!! Warning
- If the argument `--package ` is not provided, the Docker will make a package of CARLA.
-
-__3. Locate the package__. The Docker should have generated the package `map_package.tar.gz` in the output path. This is the standalone package for the assets.
-
-__4. Import the package into CARLA.__
-
-* __On Windows__ extract the package in the `WindowsNoEditor` folder.
-
-* __On Linux__ move the package to the `Import` folder, and run the script to import it.
-
-```sh
-cd Util
-./ImportAssets.sh
-```
-
-__5. Change the name of the package folder__. Two packages cannot have the same name in CARLA. Go to `Content` and find the package. Change the name if necessary, to use one that identifies it.
-
----
-## Map ingestion in a build from source
-
-This is method is meant to be used if working with the source version of CARLA. Place the maps to be imported in the `Import` folder. The script will make the ingestion, but the pedestrian navigation will have to be generated after that. Make sure that the name of the `.xodr` and `.fbx` files are the same for each of the maps being imported. Otherwise, the script will not recognize them as a map.
-
-There are two parameters to be set.
-
-* __Name of the package.__ By default, the script ingest the map or maps in a package named `map_package`. This could lead to error the second time an ingestion is made, as two packages cannot have the same name. __It is highly recommended to change the name of the package__.
-```sh
-ARGS="--package package_name"
-```
-
-* __Usage of CARLA materials.__ By default, the maps imported will use CARLA materials, but this can be changed using a flag.
-```sh
-ARGS="--no-carla-materials"
-```
-
-Check that there is an `.fbx` and a `.xodr` for each map in the `Import` folder, and make the ingestion.
-
-```sh
-make import ARGS="--package package_name --no-carla-materials"
-```
-
-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.__ 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
-
-The pedestrian navigation is managed using a `.bin`. However, before generating it, there are two things to be done.
-
-* __Add crosswalk meshes.__ Crosswalks defined inside the `.xodr` remain in the logic of the map, but are not visible. For each of them, create a plane mesh that extends a bit over both sidewalks connected. __Place it overlapping the ground, and disable its physics and rendering__.
-
-!!! Note
- To generate new crosswalks, change the name of the mesh to `Road_Crosswalk`. Avoid doing so if the crosswalk is in the `.xodr`. Otherwise, it will be duplicated.
-
-![ue_crosswalks](img/ue_crosswalks.jpg)
-
-* __Customize the map.__ In is common to modify the map after the ingestion. Props such as trees, streetlights or grass zones are added, probably interfering with the pedestrian navigation. Make sure to have the desired result before generating the pedestrian navigation. Otherwise, it will have to be generated again.
-
-Now that the version of the map is final, it is time to generate the pedestrian navigation file.
-
-__1.__ Select the __Skybox object__ and add a tag `NoExport` to it. Otherwise, the map will not be exported, as the size would be too big.
-
-![ue_skybox_no_export](img/ue_noexport.jpg)
-
-__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).
-
-* Sidewalk = `Road_Sidewalk`.
-* Crosswalk = `Road_Crosswalk`.
-* Grass = `Road_Grass`.
-
-![ue_meshes](img/ue_meshes.jpg)
-
-__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`.
-
-__6.__ Run the following command to generate the navigation file.
-
-* __Windows__
-```sh
-build.bat map_file # map_file has no extension
-```
-* __Linux__
-```sh
-./build.sh map_file # map_file has no extension
-```
-
-__7.__ Move the `.bin` into the `Nav` folder of the package that contains the map.
-
----
-## Deprecated ways to import a map
-
-There are other ways to import a map used in previous CARLA releases. These required to manually cook the map and prepare everything, so they are now deprecated. However, they are explained below in case they are needed.
-
-### Prepare the package manually
-
-A package needs to follow a certain folder structure and contain a `.json` file describing it. This steps can be saved under certains circumstances, but doing it manually will always work.
-
-
- Read how to prepare the folder structure and .json file
-
-
-#### Create the folder structure
-
-__1. Create a folder inside `carla/Import`.__ The name of the folder is not relevant.
-
-__2. Create different subfolders__ for each map to import.
-
-__3. Move the files of each map to the corresponding subfolder.__ A subfolder will contain a specific set of elements.
-
-* The mesh of the map in a `.fbx`.
-* The OpenDRIVE definition in a `.xodr`.
-* Optionally, the textures required by the asset.
-
-
-For instance, an `Import` folder with one package containing two maps should have a structure similar to the one below.
-
-```sh
-Import
-│
-└── Package01
- ├── Package01.json
- ├── Map01
- │ ├── Asphalt1_Diff.jpg
- │ ├── Asphalt1_Norm.jpg
- │ ├── Asphalt1_Spec.jpg
- │ ├── Grass1_Diff.jpg
- │ ├── Grass1_Norm.jpg
- │ ├── Grass1_Spec.jpg
- │ ├── LaneMarking1_Diff.jpg
- │ ├── LaneMarking1_Norm.jpg
- │ ├── LaneMarking1_Spec.jpg
- │ ├── Map01.fbx
- │ └── Map01.xodr
- └── Map02
- └── Map02.fbx
-```
-
-#### Create the JSON description
-
-Create a `.json` file in the root folder of the package. Name the file after the package. Note that this will be the distribution name. The content of the file will describe a JSON array of __maps__ and __props__ with basic information for each of them.
-
-__Maps__ need the following parameters.
-
-* __name__ of the map. This must be the same as the `.fbx` and `.xodr` files.
-* __source__ path to the `.fbx`.
-* __use_carla_materials__. If __True__, the map will use CARLA materials. Otherwise, it will use RoadRunner materials.
-* __xodr__ Path to the `.xodr`.
-
-__Props__ are not part of this tutorial. The field will be left empty. There is another tutorial on how to [add new props](tuto_A_add_props.md).
-
-In the end, the `.json` should look similar to the one below.
-
-```json
-{
- "maps": [
- {
- "name": "Map01",
- "source": "./Map01/Map01.fbx",
- "use_carla_materials": true,
- "xodr": "./Map01/Map01.xodr"
- },
- {
- "name": "Map02",
- "source": "./Map02/Map02.fbx",
- "use_carla_materials": false,
- "xodr": "./Map02/Map02.xodr"
- }
- ],
- "props": [
- ]
-}
-```
-
-
-
-### RoadRunner plugin import
-
-This software provides specific plugins for CARLA. Get those and follow some simple steps to get the map.
-
-
- Read RoadRunner plugin import guide
-
-
-!!! Warning
- These importing tutorials are deprecated. There are new ways to [ingest a map](#map-ingestion) to simplify the process.
-
-### Plugin installation
-
-These plugins will set everything ready to be used in CARLA. It makes the import process more simple.
-
-__1. Locate the plugins__ in RoadRunner's installation folder
-`/usr/bin/VectorZero/Tools/Unreal/Plugins`.
-
-__2. Copy those folders__ to the CarlaUE4 plugins directory `/carla/Unreal/CarlaUE4/Plugins/`.
-
-__3. Rebuild the plugin__ following the instructions below.
-
-* __a) Rebuild on Windows.__
- * Right-click the `.uproject` file and `Generate Visual Studio project files`.
- * Open the project and build the plugins.
-
-* __b) Rebuild on Linux.__
- * Run the following command.
-```sh
-> UE4_ROOT/GenerateProjectFiles.sh -project="carla/Unreal/CarlaUE4/CarlaUE4.uproject" -game -engine
-```
-
-__4. Restart Unreal Engine.__ Make sure the checkbox is on for both plugins `Edit > Plugins`.
-
-![rr_ue_plugins](img/rr-ue4_plugins.jpg)
-
-### Import map
-
-__1. Import the _mapname.fbx_ file__ to a new folder under `/Content/Carla/Maps` with the `Import` button.
-
-![ue_import](img/ue_import_mapname.jpg)
-
-__2. Set `Scene > Hierarchy Type`__ to _Create One Blueprint Asset_ (selected by default).
-__3. Set `Static Meshes > Normal Import Method`__ to _Import Normals_.
-
-![ue_import_options](img/ue_import_options.jpg)
-
-__4. Click `Import`.__
-__5. Save the current level__ `File > Save Current As...` > _mapname_.
-
-The new map should now appear next to the others in the Unreal Engine _Content Browser_.
-
-![ue_level_content](img/ue_level_content.jpg)
-
-
-!!! Note
- The tags for semantic segmentation will be assigned by the name of the asset. And the asset moved to the corresponding folder in `Content/Carla/PackageName/Static`. To change these, move them manually after imported.
-
-
-### Manual import
-
-This process requires to go through all the process manually. From importing _.fbx_ and _.xodr_ to setting the static meshes.
-
-
- Read manual import guide
-
-
-!!! Warning
- These importing tutorials are deprecated. There are new ways to [ingest a map](#map-ingestion) to simplify the process.
-
-This is the generic way to import maps into Unreal Engine using any _.fbx_ and _.xodr_ files. As there is no plugin to ease the process, there are many settings to be done before the map is available in CARLA.
-
-__1. Create a new level__ with the **Map** name in Unreal `Add New > Level` under `Content/Carla/Maps`.
-__2. Copy the illumination folder and its content__ from the BaseMap `Content/Carla/Maps/BaseMap`, and paste it in the new level. Otherwise, the map will be in the dark.
-
-![ue_illumination](img/ue_illumination.jpg)
-
-### Import binaries
-
-__1. Import the _mapname.fbx_ file__ to a new folder under `/Content/Carla/Maps` with the `Import` button. __Make sure the following options are unchecked.__
-
-* Auto Generate Collision
-* Combine Meshes
-* Force Front xAxis
-* Normal Import Method - _To import normals_
-
-__2. Check the following options.__
-
-* Convert Scene Unit
-* _To import materials and textures._
- * Material Import Method - _To create new materials_
- * Import Textures
-
-![ue_import_file](img/ue_import_file.jpg)
-
-__3. Check that the static meshes have appeared__ in the chosen folder.
-
-__4. Drag the meshes__ into the level.
-
-![ue_meshes](img/ue_drag_meshes.jpg)
-
-__5. Center the meshes at point (0,0,0)__ when Unreal finishes loading.
-
-![Transform_Map](img/transform.jpg)
-
-__6. Generate collisions__. Otherwise, pedestrians and vehicles will fall into the abyss.
-
-* Select the meshes meant to have colliders.
-* Right-click `Asset Actions > Bulk Edit via Property Matrix...`.
-
- ![ue_selectmesh_collision](img/ue_selectmesh_collision.jpg)
-
-* Search for _collision_ in Property's Matrix search box.
-* Change `Collision complexity` from `Project Default` to `Use Complex Collision As Simple`.
-
- ![ue_collision_complexity](img/ue_collision_complexity.jpg)
-
-* Go to `File > Save All`.
-
-__7. Move the static meshes__ from `Content/Carla/Maps/mapfolder` to the corresponding `Carla/Static` subsequent folder. This will be meaningful for the semantic segmentation ground truth.
-
- * `Terrain/mapname`
- * `Road/mapname`
- * `RoadLines/mapname`
-
-```sh
-Content
-└── Carla
- ├── Blueprints
- ├── Config
- ├── Exported Maps
- ├── HDMaps
- ├── Maps
- └── Static
- ├── Terrain
- │ └── mapname
- │ └── Static Meshes
- │
- ├── Road
- │ └── mapname
- │ └── Static Meshes
- │
- ├── RoadLines
- | └── mapname
- | └── Static Meshes
- └── Sidewalks
- └── mapname
- └── Static Meshes
-```
-
-![ue__semantic_segmentation](img/ue_ssgt.jpg)
-
-### Import OpenDRIVE files
-
-__1. Copy the `.xodr` file__ inside the `Content/Carla/Maps/OpenDrive` folder.
-__2. Open the Unreal level.__ Drag the _Open Drive Actor_ inside the level. It will read the level's name. Search the Opendrive file with the same name and load it.
-
-![ue_opendrive_actor](img/ue_opendrive_actor.jpg)
-
-
-
-
-
-### Set traffic and pedestrian behaviour
-
-This software provides specific plugins for CARLA. Get those and follow some simple steps to get the map.
-
-
- Read traffic and pedestrian setting guide
-
-!!! Warning
- These importing tutorials are deprecated. There are new ways to [ingest a map](#map-ingestion) to simplify the process.
-
-### Set traffic behavior
-
-Once everything is loaded into the level, it is time to create traffic behavior.
-
-__1. Click on the _Open Drive Actor_.__
-__2. Check the following boxes in the same order.__
-
-* Add Spawners.
-* _(Optional for more spawn points)_ On Intersections.
-* Generate Routes.
-
-This will generate a series of _RoutePlanner_ and _VehicleSpawnPoint_ actors. These are used for vehicle spawning and navigation.
-
-### Traffic lights and signs
-
-Traffic lights and signs must be placed all over the map.
-
-__1. Drag traffic light/sign actors__ into the level and place them.
-__2. Adjust the [`trigger volume`][triggerlink]__ for each of them. This will determine their area of influence.
- [triggerlink]: python_api.md#carla.TrafficSign.trigger_volume
-
-![ue_trafficlight](img/ue_trafficlight.jpg)
-
-__3. In junctions, drag a traffic light group actor__ into the level. Assign to it all the traffic lights involved and configure their timing. Make sure to understand [how do traffic lights work](http://127.0.0.1:8000/core_actors/#traffic-signs-and-traffic-lights).
-
-![ue_tl_group](img/ue_tl_group.jpg)
-
-__4. Test traffic light timing and traffic trigger volumes.__ This may need trial and error to fit perfectly.
-
-![ue_tlsigns_example](img/ue_tlsigns_example.jpg)
-
-> _Example: Traffic Signs, Traffic lights and Turn based stop._
-
----
-### Add pedestrian navigation
-
-In order to prepare the map for pedestrian navigation, there are some settings to be done before exporting it.
-
-__1.__ Select the __Skybox object__ and add a tag `NoExport` to it. Otherwise, the map will not be exported, as the size would be too big. Any geometry that is not involved or interfering in the pedestrian navigation can be tagged also as `NoExport`.
-
-![ue_skybox_no_export](img/ue_noexport.jpg)
-
-__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).
-
-![ue_meshes](img/ue_meshes.jpg)
-
-__3.__ Crosswalks have to be manually created. For each of them, create a plane mesh that extends a bit over both sidewalks connected. __Place it overlapping the ground, and disable its physics and rendering__.
-
-![ue_crosswalks](img/ue_crosswalks.jpg)
-
-__4.__ Name these planes following the common format `Road_Crosswalk_mapname`.
-
-__5.__ Press `G` to deselect everything, and export the map. `File > Export CARLA...`.
-__6.__ Run RecastDemo `./RecastDemo`.
-
- * Select `Solo Mesh` from the `Sample` parameter's box.
- * Select the _mapname.obj_ file from the `Input Mesh` parameter's box.
-![recast_example](img/recast_example.jpg)
-
-__7.__ Click on the `Build` button.
-__8.__ Once the build has finished, click on the `Save` button.
-__9.__ Change the **filename** of the binary file generated at `RecastDemo/Bin` to `mapname.bin`.
-__10.__ Drag the _mapname.bin_ file into the `Nav` folder under `Content/Carla/Maps`.
-
-
-
-
----
-
-That comprises the process to create and import a new map into CARLA. If during the process any doubts arise, feel free to post these in the forum.
-
-
\ No newline at end of file
diff --git a/Docs/tuto_A_add_props.md b/Docs/tuto_A_add_props.md
index c3af52f42..e5f9f77f0 100644
--- a/Docs/tuto_A_add_props.md
+++ b/Docs/tuto_A_add_props.md
@@ -45,7 +45,7 @@ Import
Create a `.json` file in the root folder of the package. Name the file after the package. Note that this will be the distribution name. The content of the file will describe a JSON array of __maps__ and __props__ with basic information for each of them.
-__Maps__ are not part of this tutorial, so this definition will be empty. There is a specific tutorial to [__add a new map__](tuto_A_add_map.md).
+__Maps__ are not part of this tutorial, so this definition will be empty. There is a specific tutorial to [__add a new map__](tuto_M_custom_map_overview.md).
__Props__ need the following parameters.
@@ -161,7 +161,7 @@ That is all there is to know about the different ways to import new props into C
diff --git a/Docs/tuto_A_add_vehicle.md b/Docs/tuto_A_add_vehicle.md
index 557ea48e0..f27a8f128 100644
--- a/Docs/tuto_A_add_vehicle.md
+++ b/Docs/tuto_A_add_vehicle.md
@@ -1,119 +1,241 @@
# Add a new vehicle
-This tutorial covers step by step the process to add a new vehicle model. From the very moment the model is finished, to a simple test in CARLA.
+This tutorial details how to add a new vehicle to CARLA. There are two sections, one for 4 wheeled vehicles and one for 2 wheeled vehicles. There is an outline of the basic requirements that must be fulfilled when modeling your vehicle to ensure that it works well in CARLA and instructions on configurations required after the vehicle has been imported into Unreal Engine.
-* [__Add a 4 wheeled vehicle__](#add-a-4-wheeled-vehicle)
- * [Bind the skeleton](#bind-the-skeleton)
- * [Import and prepare the vehicle](#import-and-prepare-the-vehicle)
-* [__Add a 2 wheeled vehicle__](#add-a-2-wheeled-vehicle)
+* [__Add a 4 wheeled vehicle__](#add-a-4-wheeled-vehicle)
+ * [Bind and model the vehicle](#bind-and-model-the-vehicle)
+ * [Import and configure the vehicle](#import-and-configure-the-vehicle)
+* [__Add a 2 wheeled vehicle__](#add-a-2-wheeled-vehicle)
!!! Important
- This tutorial only applies to users that work with a build from source, and have access to the Unreal Editor.
+ This tutorial only applies to users that work with a build from source, and have access to the Unreal Engine Editor.
---
## Add a 4 wheeled vehicle
-### Bind the skeleton
+Vehicles added to CARLA need to use a __common base skeleton__ which is found [__here__](https://carla-assets.s3.eu-west-3.amazonaws.com/fbx/VehicleSkeleton.rar). This link will download a folder called `VehicleSkeleton.rar` which contains the base skeleton in two different `.fbx` formats, one in ASCII and the other in binary. The format you use will depend on your 3D modeling software requirements.
-CARLA provides a general skeleton for 4-wheeled vehicles that must be used by all of them. The position of the bones can be changed, but rotating them, adding new ones or changing the hierarchy will lead to errors.
+__The positions of the skeleton bones can be changed but any other manipulation such as rotation, addition of new bones, or changing the current hierarchy will lead to errors. __
-__1. Download the skeleton__ from the CARLA repositories. [Here](https://carla-assets.s3.eu-west-3.amazonaws.com/fbx/VehicleSkeleton.rar) is the link to `General4WheeledVehicleSkeleton`, the reference skeleton for 4 wheeled vehicles.
+---
-__2. Import the skeleton__ into the 3D project of the new vehicle. This could be in Maya, Blender or whichever software used for modelling.
+### Bind and model the vehicle
-__3. Bind the bones__ to the corresponding portions of the mesh. Make sure to center the wheels' bones within the mesh.
+This section details the minimum requirements in the modeling stage of your vehicle to make sure it can be used successfully in CARLA. The process involves binding the skeleton correctly to the base and wheels of the vehicle, creating Physical Asset and raycast sensor meshes, and exporting to the correct format.
-* __Front left wheel__ — `Wheel_Front_Left`.
-* __Front right wheel__ — `Wheel_Front_Right`.
-* __Rear left wheel__ — `Wheel_Rear_Left`.
-* __Rear right wheel__ — `Wheel_Rear_Right`.
-* __Rest of the mesh__ — `VehicleBase`.
+__1. Import the base skeleton.__
+
+Import the base skeleton into your preferred 3D modeling software. Common editors include Maya and Blender.
+
+__2. Bind the bones.__
+
+Bind the bones to the corresponding portions of the vehicle mesh according to the nomenclature below. Make sure to center the wheels' bones within the mesh.
+
+* __Front left wheel:__ `Wheel_Front_Left`
+* __Front right wheel:__ `Wheel_Front_Right`
+* __Rear left wheel:__ `Wheel_Rear_Left`
+* __Rear right wheel:__ `Wheel_Rear_Right`
+* __Rest of the mesh:__ `VehicleBase`
!!! Warning
- Do not add new bones, change their names or the hierarchy.
+ Do not make any changes to the bone names or the hierarchy nor add any new bones.
-__4. Export the result__. Select all the meshes and the base of the skeleton and export as `.fbx`.
+__3. Model your vehicle.__
+
+Vehicles should have between approximately 50,000 - 100,000 tris. We model the vehicles using the size and scale of actual cars.
+
+We recommend that you divide the vehicle into the following materials:
+
+>1. __Bodywork__: The metallic part of the vehicle. This material is changed to Unreal Engine material. Logos and details can be added but, to be visible, they must be painted in a different color by using the alpha channels in the Unreal Engine editor.
+- __Glass_Ext__: A layer of glass that allows visibility from the outside to the inside of the vehicle.
+- __Glass_Int__: A layer of glass that allows visibility from the inside to the outside of the vehicle.
+- __Lights__: Headlights, indicator lights, etc.
+- __LightGlass_Ext__: A layer of glass that allows visibility from the outside to the inside of the light.
+- __LightGlass_Int__: A layer of glass that allows visibility from the inside to the outside of the light.
+- __LicensePlate__: A rectangular plane of 29x12 cm. You can use the CARLA provided `.fbx` for best results, download it [here](https://carla-assets.s3.eu-west-3.amazonaws.com/fbx/LicensePlate.rar). The texture will be assigned automatically in Unreal Engine.
+- __Interior__: Any other details that don't fit in the above sections can go into _Interior_.
+
+Materials should be named using the format `M_CarPart_CarName`, e.g., `M_Bodywork_Mustang`.
+
+Textures should be named using the format `T_CarPart_CarName`, e.g., `T_Bodywork_Mustang`. Textures should be sized as 2048x2048.
+
+Unreal Engine automatically creates LODs but you can also create them manually in your 3D editor. Tri counts are as follows:
+
+- __LOD 0__: 100,000 tris
+- __LOD 1__: 80,000 tris
+- __LOD 2__: 60,000 tris
+- __LOD 3__: 30,000 tris
-### Import and prepare the vehicle
+__4. Create the Physical Asset mesh.__
-* __1. Create a new folder__ named `` in `Content/Carla/Static/Vehicle`.
-
+The Physical Asset mesh is an additional mesh that allows Unreal Engine to calculate the vehicle's physics. It should be as simple as possible, with a reduced number of polygons, and should cover the whole vehicle except for the wheels. See the image below for an example.
-* __2. Import the `.fbx`__ in its folder. The Skeletal Mesh will appear along with two new files, `_PhysicsAssets` and `_Skeleton`.
- * __2.1 - *Import Content Type*__ — `Geometry and Skinning Weights`.
- * __2.2 - *Normal Import Method*__ — `Import Normals`.
- * __2.3 - *Material Import Method*__ — Optionally choose `Do not create materials` and uncheck `Import Textures` to avoid Unreal creating its own default materials.
+>>![physical asset mesh](../img/physical_asset_mesh.png)
-!!! Note
- If Unreal does not create the vehicle materials, these will have to be created manually.
+The Physical Asset mesh should be exported as a separate `.fbx` file. The final file should fulfill the following requirements:
-* __3. Open `_PhysicsAssets`__ to set the vehicle colliders.
- * __3.1 - Change the wheels' colliders__ — Select a sphere and adjust it to the shape of the wheel.
- * __3.2 - Change the wheels' *Physics Type*__ — Select `Kinematic` for all of them.
- * __3.3 - Change the general collider__ — Select a box and adjust it to the shape of the vehicle.
- * __3.4 - Enable *Simulation Generates Hit Event*__ — Check it for all of the physics' bodies.
+- Have a base mesh. This should be a copy of the Physical Asset mesh. It should have the same name as the original vehicle.
+- The Physical Asset mesh must be named using the format `UCX__`, __otherwise it will not be recognized by Unreal Engine.__
+- The mesh must not extend beyond the boundaries of the original model.
+- The mesh should have the same position as the original model.
-![add_vehicle_step_03](img/add_vehicle_step_03.jpg)
-
Step 3, set colliders.
+>>![base mesh](../img/base_mesh.png)
-* __4. Create the Animation Blueprint__. In the new vehicle folder, click right and go to `Create advanced asset/Animation/Animation blueprint`.
- * __4.1 - *Parent Class*__ — `VehicleAnimInstance`.
- * __4.2 - *Skeleton*__ — `_Skeleton`.
- * __4.3 - Rename the blueprint__ — `BP__anim`.
- * __4.4 - Copy an existing Animation Blueprint__ — Go to `Content/Carla/Static/Vehicle` and choose any vehicle folder. Open its Animation Blueprint and copy the content from the *AnimGraph*.
- * __4.5 - Compile the Animation Blueprint__ — Connect the content in the blueprint and click the button `Compile` on the top left corner.
+Export the final mesh as an `.fbx` file with the name `SMC_.fbx`.
-![add_vehicle_step_04](img/add_vehicle_step_04.jpg)
-
Step 4.5, connect the blueprint.
+__5. Create the mesh for the raycast sensor.__
-* __5. Create a folder for the vehicle blueprints__. Go to `Content/Carla/Blueprints/Vehicles` and create a new folder ``.
-
-* __6. Create blueprints for the wheels__. Inside the folder, right-click and go to `Created advanced assets/Blueprints class`. Create two blueprints derived from `VehicleWheel`, one named `_FrontWheel` and the other `_RearWheel`.
- * __6.1 - *Shape radius*__ — Exactly the radius, not diameter, of the wheel mesh.
- * __6.2 - *Tire Config*__ — `CommonTireConfig`.
- * __6.3 - On the front wheel__ — Set `Steer Angle`, default is `70`. Uncheck `Affected by Handbrake`.
- * __6.4 - On the rear wheel__ — Set `Steer Angle` to `0`. Check `Affected by Handbrake`.
+The raycast sensor mesh sets up the vehicle's shape that will be detected by the raycast sensors (RADAR, LiDAR, and Semantic LiDAR). This mesh should have a slightly more defined geometry than the Physical Asset mesh in order to increase the realism of sensor simulation but not as detailed as the car mesh for performance reasons.
-![add_vehicle_step_06](img/add_vehicle_step_06.jpg)
-
Step 6.3, front wheel setup.
+Consider the following points when creating the raycast sensor mesh:
-* __7. Create a blueprint for the vehicle__. Inside the folder, create another blueprint derived from `BaseVehiclePawn` and named `BP_`.
- * __7.1 - *Mesh*__ — Choose the skeletal mesh of the vehicle.
- * __7.2 - *Anim class*__ — Choose the Animation blueprint created in *step 4*.
- * __7.3 - *Vehicle bounds*__ — Adjust it to include the whole volume of the vehicle.
+- The mesh should cover all aspects of the vehicle, including wheels, side mirrors, and grilles.
+- The wheels should be cylinders of no more than 16 loops.
+- Various meshes can be joined together if required.
+- The mesh(es) must not extend beyond the boundaries of the original model.
+- The mesh(es) should have the same position as the original.
-!!! Note
- These options appear in the menu *Components* on the left side of the window.
+>>![collision mesh](../img/collision_mesh.png)
-![add_vehicle_step_07](img/add_vehicle_step_07.jpg)
-
Step 6.3, create the blueprint.
+Export the final mesh as an `.fbx` file with the name `SM_sc_.fbx`.
-* __8. Pair the wheels with their blueprint__. In `Vehicle Movement/Wheel Setups` expand the menu and prepare each wheel.
- * __8.1 - *Wheel_Front_Left*__ — `_FrontWheel`
- * __8.2 - *Wheel_Front_Right*__ — `_FrontWheel`
- * __8.3 - *Wheel_Rear_Left*__ — `_RearWheel`
- * __8.4 - *Wheel_Rear_Right*__ — `_RearWheel`
+__5. Export the vehicle mesh(es).__
-![add_vehicle_step_08](img/add_vehicle_step_08.jpg)
-
Step 8, pair the wheels.
+Select all the main vehicle mesh(es) and the skeleton base and export as `.fbx`.
-* __9 - Compile the blueprint__ — Click the button `Compile` on the top left corner.
-
-* __10 - Add the vehicle__. In `Content/Carla/Blueprint/Vehicle`, open the `VehicleFactory` and add a new element to the array of vehicles.
- * __10.1 - *Make*__ — Choose a name to be used in Unreal.
- * __10.2 - *Model*__ — Choose the name to be used in the blueprint library in CARLA.
- * __10.3 - *Class*__ — `BP_`.
- * __10.4 - *Recommended colors*__ — Optionally, provide a set of recommended colors for the vehicle.
+---
-![add_vehicle_step_10](img/add_vehicle_step_10.jpg)
-
Step 10, add the new vehicle.
+### Import and configure the vehicle
+
+This section details the process of importing the vehicle into Unreal Engine for use in CARLA. Perform these steps in the Unreal Engine editor.
+
+__1. Create the vehicle folder.__
+
+Create a new folder named `` in `Content/Carla/Static/Vehicles/4Wheeled`.
+
+__2. Import the `.fbx`.__
+
+Inside the new vehicle folder, import your main vehicle skeleton `.fbx` by right-clicking in the **_Content Browser_** and selecting **_Import into Game/Carla/Static/Vehicles/4Wheeled/_**.
+
+In the dialogue box that pops up:
+
+- Set **_Import Content Type_** to `Geometry and Skinning Weights`.
+- Set **_Normal Import Method_** to `Import Normals`.
+- Optionally set **_Material Import Method_** to `Do not create materials`. Uncheck **_Import Textures_** to avoid Unreal Engine creating default materials.
+
+The Skeletal Mesh will appear along with two new files, `_PhysicsAssets` and `_Skeleton`.
+
+Import the rest of your `.fbx` files separately from the main vehicle skeleton `.fbx` file.
+
+__3. Set the physical asset mesh.__
+
+>1. Open `_PhysicsAssets` from the **_Content Browser_**.
+- Right-click on the `Vehicle_Base` mesh in the **_Skeleton Tree_** panel and go to **_Copy Collision from StaticMesh_**.
+- Search for and select your `SMC_` file. You should see the outline of the physical asset mesh appear in the viewport.
+- Delete the default capsule shape from the `Vehicle_Base`.
+- Select all the wheels:
+ - Go to the **_Tools_** panel and change the **_Primitive Type_** to `Sphere`.
+ - Go to the **_Details_** panel and change **_Physics Type_** to `Kinematic`.
+ - Set **_Linear Damping_** to `0`. This will eliminate any extra friction on the wheels.
+- Enable **_Simulation Generates Hit Event_** for all meshes.
+- Click **_Re-generate Bodies_**.
+- Adjust the wheel sphere to the size of the wheel.
+- Save and close the window.
+
+>![Collision mesh](../img/collision_mesh_vehicle.png)
+
+__4. Create the Animation Blueprint.__
+
+>1. In the **_Content Browser_**, right-click inside your vehicle folder and select **_Animation -> Animation Blueprint_**.
+- In **_Parent Class_** search for and select `VehicleAnimInstance`.
+- In **_Target Skeleton_** search for and select `_Skeleton`.
+- Press **_OK_** and rename the blueprint as `AnimBP_`.
+
+__5. Configure the Animation Blueprint.__
+
+To ease the process of configuring the animation blueprint, we will copy an existing one from a native CARLA vehicle:
+
+>1. Go to `Content/Carla/Static/Vehicle` and choose any CARLA vehicle folder. Open its Animation Blueprint.
+- In the **_My Blueprint_** panel, double click on **_AnimGraph_**. You will see the graph come up in the viewport.
+- Click and drag to select the **_Mesh Space Ref Pose_**, **_Wheel Handler_**, and **_Component To Local_** components. Right-click and select **_Copy_**.
+- Go back to your own vehicle Animation Blueprint and paste the copied contents into the graph area.
+- Click and drag from the standing figure in the **_Component To Local_** component to the figure in **_Output Pose_** to join the components together.
+- Click **_Compile_** in the top left corner. You should now see a pulsating line flowing through the entire sequence.
+- Save and close the window.
+
+>>![add_vehicle_step_04](img/add_vehicle_step_04.jpg)
+
+__6. Prepare the vehicle and wheel blueprints.__
+
+>1. In the **_Content Browser_**, go to `Content/Carla/Blueprints/Vehicles` and create a new folder ``.
+- Inside the folder, right-click and go to **_Blueprint Class_**. Open the **_All Classes_** section in the pop-up.
+- Search for `BaseVehiclePawn` and press **_Select_**.
+- Rename the file as `BP_`.
+- Go to the folder of any of the native CARLA vehicles in `Carla/Blueprints/Vehicles`. From the **_Content Browser_**, copy the four wheel blueprints into the blueprint folder for your own vehicle. Rename the files to replace the old vehicle name with your own vehicle name.
+
+>>![Copy wheel blueprints](../img/copy_wheel_blueprint.png)
+
+__7. Configure the wheel blueprints.__
+
+>1. In your vehicle blueprint folder, open all four of the wheel blueprints.
+- In the **_Class Defaults_** panel, set **_Collision Mesh_** to `Wheel_Shape`. __Omitting this step will cause the vehicle wheels to sink into the ground__.
+- Adjust the values for wheel shape radius, width, mass, and damping rate according to your vehicle specifications.
+- Set **_Tire Config_** to `CommonTireConfig`
+- On the front wheels set **_Steer Angle_** according to your preferences (default is `70`). Uncheck **_Affected by Handbrake_**.
+- On the rear wheels set **_Steer Angle_** to `0`. Check **_Affected by Handbrake_**.
+- When setting the suspension values, you can use the values [here](tuto_D_customize_vehicle_suspension.md) as a guide.
+- Compile and save.
+
+>>![wheel shape](../img/wheel_shape.png)
+
+__8. Configure vehicle blueprint.__
+
+>1. From the **_Content Browser_**, open your `BP_`.
+- In the **_Components_** panel, select **_Mesh (VehicleMesh) (Inherited)_**.
+- In the **_Details_** panel, go to **_Skeletal Mesh_** and search for and select the base skeleton file of your vehicle (located in the `Carla/Static/Vehicles/4Wheeled/` folder).
+- Go to **_Anim Class_** in the **_Details_** panel. Search for and select your `AnimBP_` file.
+- In the **_Components_** panel, select **_Custom Collision (Inherited)_**.
+- Select **_Static Mesh_** in the **_Details_** panel and search for your `SM_sc_` raycast sensor mesh.
+- In the **_Components_** panel, select **_VehicleMovement (MovementComp) (Inherited)_**.
+- In the **_Details_** panel, search for `wheel`. You will find settings for each of the wheels. For each one, click on **_Wheel Class_** and search for the `BP__` file that corresponds to the correct wheel position.
+
+>>>>![wheel blueprint](../img/wheel_blueprint.png)
+
+If you have any additional meshes for your vehicle (doors, lights, etc.,) separate from the base mesh:
+
+>1. Drag them into the **_Mesh (VehicleMesh) (Inherited)_** hierarchy in the **_Components_** panel.
+- Select the extra meshes in the hierarchy and search for `Collision` in the **_Details_** panel.
+- Set **_Collision Presets_** to `NoCollision`.
+- Select any lights meshes in the hierarchy. Search for `Tag` in the **_Details_** panel and add the tag `emissive`.
+
+Click **_Save_** and **_Compile_**.
+
+
+
+__9. Add the vehicle to the Blueprint Library__.
+
+>1. In `Content/Carla/Blueprint/Vehicle`, open the `VehicleFactory` file.
+- In the **_Generate Definitions_** tab, double click **_Vehicles_**.
+- In the **_Details_** panel, expand the **_Default Value_** section and add a new element to the vehicles array.
+- Fill in the **_Make_** and **_Model_** of your vehicle.
+- Fill in the **_Class_** value with your `BP_` file.
+- Optionally, provide a set of recommended colors for the vehicle.
+- Compile and save.
+
+>![vehicle factory](../img/vehicle_factory.png)
+
+__10. Test the vehicle__.
+
+Launch CARLA, open a terminal in `PythonAPI/examples` and run the following command:
-* __11. Test the vehicle__. Launch CARLA, open a terminal in `PythonAPI/examples` and run the following command.
```sh
-python3 manual_control.py --filter # The name used in step 10.2
+python3 manual_control.py --filter # The make or model defined in step 9
```
+!!! Note
+ Even if you used upper case characters in your make and model, they need to be converted to lower case when passed to the filter.
+
---
## Add a 2 wheeled vehicle
diff --git a/Docs/tuto_A_create_standalone.md b/Docs/tuto_A_create_standalone.md
index d4b8aca82..d0ff341a6 100644
--- a/Docs/tuto_A_create_standalone.md
+++ b/Docs/tuto_A_create_standalone.md
@@ -2,11 +2,12 @@
It is a common practice in CARLA to manage assets with standalone packages. Keeping them aside allows to reduce the size of the build. These asset packages can be easily imported into a CARLA package anytime. They also become really useful to easily distribute assets in an organized way.
-* [__Export a package from the UE4 Editor__](#export-a-package-from-the-ue4-editor)
-* [__Import assets into a CARLA package__](#import-assets-into-a-carla-package)
+- [__Export a package from the UE4 Editor__](#export-a-package-from-the-ue4-editor)
+- [__Export a package using Docker__](#export-a-package-using-docker)
+- [__Import assets into a CARLA package__](#import-assets-into-a-carla-package)
---
-## Export a package from the UE4 Editor
+## Export a package in a CARLA build from source
Once assets are imported into Unreal, users can generate a __standalone package__ for them. This will be used to distribute the content to CARLA packages such as 0.9.8.
@@ -18,8 +19,26 @@ make package ARGS="--packages=Package1,Package2"
This will create a standalone package compressed in a `.tar.gz` file for each of the packages listed. The files will be saved in `Dist` folder on Linux, and `/Build/UE4Carla/` on Windows.
-!!! Note
- As an alternative, the [Docker method](tuto_A_add_map.md#via-docker) will create the standalone package without the need of having Unreal Engine in the system.
+---
+
+## Export a package using Docker
+
+Unreal Engine and CARLA can be built in a Docker image which can then be used to create a package or export assets for use in a package.
+
+To create the Docker image, follow the tutorial [here](build_docker_unreal.md).
+
+When you have the image ready:
+
+1. Navigate to `Util/Docker`.
+2. Create a CARLA package or prepare assets for use in a package by running one of the following commands:
+
+```sh
+# To create a standalone package
+./docker_tools.py --output /output/path
+
+#To cook assets to be consumed in a CARLA package
+./docker_tools.py --input /assets/to/import/path --output /output/path --packages PkgeName1,PkgeName2
+```
---
## Import assets into a CARLA package
@@ -35,7 +54,7 @@ cd Import
```
!!! Note
- Standalone packages cannot be directly imported into a CARLA build. Follow the tutorials to import [props](tuto_A_add_props.md), [maps](tuto_A_add_map.md) or [vehicles](tuto_A_add_vehicle.md).
+ Standalone packages cannot be directly imported into a CARLA build. Follow the tutorials to import [props](tuto_A_add_props.md), [maps](tuto_M_custom_map_overview.md) or [vehicles](tuto_A_add_vehicle.md).
---
@@ -43,7 +62,7 @@ That sumps up how to create and use standalone packages in CARLA. If there is an
\ No newline at end of file
diff --git a/Docs/tuto_A_map_customization.md b/Docs/tuto_A_map_customization.md
deleted file mode 100644
index cd03e6666..000000000
--- a/Docs/tuto_A_map_customization.md
+++ /dev/null
@@ -1,178 +0,0 @@
-# Map customization tools
-
-There are several tools provided by the CARLA team that allow users to edit maps at will from the Unreal Editor. This tutorial introduces the most relevant tools, according to their purpose.
-
-* [__Serial meshes__](#add-serial-meshes)
- * [BP_RepSpline](#bp_repspline)
- * [BP_Spline](#bp_spline)
- * [BP_Wall](#bp_wall)
- * [BP_SplinePowerLine](#bp_splinepowerline)
-* [__Procedural buildings__](#add-serial-meshes)
- * [Building structure](#building-structure)
- * [Structure modifications](#structure-modifications)
-* [__Weather customization__](#weather-customization)
- * [BP_Weather](#bp_weather)
- * [BP_Sky](#bp_sky)
-
-!!! Important
- This tutorial only applies to users that work with a build from source, and have access to the Unreal Editor.
-
----
-## Add serial meshes
-
-There is a series of blueprints in `Carla/Blueprints/LevelDesign` that are useful to add props aligned in one direction. All of them use a series of meshes, and a Bezier curve that establishes the path where the props are placed.
-
-There are differences between them, that make them fit specific purposes. However, the all work the same way. Only the parametrization presents differences.
-
-* __Initialize the series__. The blueprints need a __Static Mesh__ that will be repeated. Initially, only one element will appear, standing on the starting point of a Bezier curve with two nodes, beginning and ending.
-* __Define the path__. Press __Alt__ over one of the nodes, to create a new one and modify the curve. A new mesh will appear on every node of the curve, and the space between nodes will be filled with elements __separated by a distance__ measure. Adjust the curve using the weights on every node.
-* __Customize the pattern__. This is where the blueprints present differences between each other.
-
-!!! Warning
- New props will probably interfere with the mesh navigation. If necessary, rebuild that as explained [here](tuto_A_add_map.md#generate-pedestrian-navigation) after doing these changes.
-
-### BP_RepSpline
-
-The blueprint __BP_RepSpline__ adds __individual__ elements along the path defined by a Bezier curve. There are some specificic parameters that change the serialization.
-
-* __Distance between__ — Set the distance between elements.
-* __Offset rotation__ — Set a fixed rotation for the different axis.
-* __Random rotation__ — Set a range of random rotations for the different axis.
-* __Offset translation__ — Set a range of random locations along the different axis.
-* __Max Number of Meshes__ — Set the maximum amount of elements that will be place between nodes of the curve.
-* __World aligned ZY__ — If selected, the elements will be vertically aligned regarding the world axis.
-* __EndPoint__ — If selected, an element will be added in the ending node of the curve.
-* __Collision enabled__ — Set the type of collisions enabled for the meshes.
-
-![bp_repspline_pic](img/map_customization/BP_Repspline.jpg)
-
BP_RepSpline example.
-
-### BP_Spline
-
-The blueprint __BP_Spline__ adds __connected__ elements __strictly__ following the path defined by a Bezier curve. The mesh will be warped to fit the path created.
-
-* __Gap distance__ — Add a separation between elements.
-
-![bp_spline_pic](img/map_customization/BP_Spline.jpg)
-
BP_Spline example.
-
-### BP_Wall
-
-The blueprint __BP_Wall__ adds __connected__ elements along the path defined by a Bezier curve. The mesh will not be warped to fit the curve, but the nodes will be respected.
-
-* __Distance between__ — Set the distance between elements.
-* __Vertically aligned__ — If selected, the elements will be vertically aligned regarding the world axis.
-* __Scale offset__ — Scale the length of the mesh to round out the connection between elements.
-
-![bp_wall_pic](img/map_customization/BP_Wall.jpg)
-
BP_Wall example.
-
-### BP_SplinePowerLine
-
-The blueprint __BP_SplinePowerLine__ adds __electricity poles__ along the path defined by a Bezier curve, and __connects them with power lines__.
-
-This blueprint can be found in `Carla/Static/Pole`. This blueprint allows to set an __array of meshes__ to repeat, to provide variety.
-
-![bp_splinepowerline_pic](img/map_customization/BP_Splinepowerline.jpg)
-
BP_SplinePowerLine example.
-
-The power line that connects the pole meshes can be customized.
-
-* __Choose the mesh__ that will be used as wire.
-* __Edit the tension__ value. If `0`, the power lines will be staight. The bigger the value, the looser the connection.
-* __Set the sockets__. Sockets are empty meshes that represent the connection points of the power line. A wire is created form socket to socket between poles. The amount of sockets can be changed inside the pole meshes.
-
-![bp_powerline_socket_pic](img/map_customization/BP_Splinepowerline_Sockets.jpg)
-
Visualization of the sockets for BP_SplinePowerLine.
-
-!!! Important
- The amount of sockets and their names should be consistent between poles. Otherwise, visualization issues may arise.
-
----
-## Procedural buildings
-
-The blueprint __BP_Procedural_Building__ in `Content/Carla/Blueprints/LevelDesign` creates a realistic building using key meshes that are repeated along the structure. For each of them, the user can provide an array of meshes that will be used at random for variety. The meshes are only created once, and the repetitions will be instances of the same to save up costs.
-
-!!! Note
- Blueprints can be used instead of meshes, to allow more variety and customization for the building. Blueprints can use behaviour trees to set illumination inside the building, change the materials used, and much more.
-
-### Building structure
-
-The key meshes will be updated everytime a change is made, and the building will disappear. Enable `Create automatically` or click on `Create Building` to see the new result.
-
-These key meshes can be percieved as pieces of the building's structure. They can be grouped in four categories.
-
-* __Base__ — The ground floor of the building.
-* __Body__ — The middle floors of the building.
-* __Top__ — The highest floor of the building.
-* __Roof__ — Additional mesh that used to fill the spaces in the middle of the top floor.
-
-For each of them, except the __Roof__, there is a mesh to fill the center of the floor, and a __Corner__ mesh that will be placed on the sides of the floor. The following picture represents the global structure.
-
-![bp_procedural_building_visual](img/map_customization/BP_Procedural_Building_Visual.jpg)
-
Visualization of the building structure.
-
-The __Base parameters__ set the dimensions of the building.
-
-* __Num Floors__ — Floors of the building. Repetitions of the __Body__ meshes.
-* __Length X and Length Y__ — Area of the building. Repetitions of the central meshes for each side of the building.
-
-![bp_procedural_building_full](img/map_customization/BP_Procedural_Building_Full.jpg)
-
Example of BP_Procedural_Building.
-
-### Structure modifications
-
-There are some additional options to modify the general structure of the building.
-
-* __Disable corners__ — If selected, no corner meshes will be used.
-* __Use full blocks__ — If selected, the structure of the building will use only one mesh per floor. No corners nor repetitions will appear in each floor.
-* __Doors__ — Meshes that appear in the ground floor, right in front of the central meshes. The amount of dloors and their location can be set. `0` is the initial position, `1` the next base repetition, and so on.
-* __Walls__ — Meshes that substitute one or more sides of the building. For example, a plane mesh can be used to paint one side of the building.
-
-![bp_procedural_building_extras](img/map_customization/BP_Procedural_Building_Extras.jpg)
-
On the left, a building with no cornes and one door. On the right, a building with a wall applied to one side of the building. The wall is a texture with no fire escape.
-
----
-## Weather customization
-
-The weather can be easily customized by the users in CARLA using the PythonAPI. However, there is some configuration that users can do in order to set the default weather for a map. The weather parameters available for configuration by the following blueprints, are the same accessible from the API. These are described [here](https://carla.readthedocs.io/en/latest/python_api/#carlaweatherparameters).
-
-### BP_Weather
-
-This blueprint is loaded into the world when the simulation starts. It contains the default weather parameters for every map, and these can be modified at will.
-
-__1. Open the BP_Weather__ in `Content/Carla/Blueprints/Weather`.
-
-__2. Go to the Weather group__ in the blueprint.
-
-__3. Choose the desired town__ and modify the parameters.
-
-![bp_weather_pic](img/map_customization/BP_Weather.jpg)
-
-Array containing default weather parameters for every CARLA map. Town01 opened.
-
-### BP_Sky
-
-This blueprint groups all the weather parameters. It can be loaded into the scene when there is no CARLA server running, and used to ea test different configurations before setting a new default weather.
-
-__1. Find the BP_Sky__ in `Content/Carla/Blueprints/Weather`.
-
-__2. Load the blueprint in the scene.__ Drag it into the scene view.
-
-__3. Edit the weather parameters.__ The weather in the scene will be updated accordingly.
-
-!!! Important
- If more than one blueprint is loaded into the scene, the weather will be duplicated with weird results, such as having two suns.
-
----
-
-That is all there is so far, regarding the different map customization tools available in CARLA.
-
-Open CARLA and mess around for a while. If there are any doubts, feel free to post these in the forum.
-
-
\ No newline at end of file
diff --git a/Docs/tuto_A_material_customization.md b/Docs/tuto_A_material_customization.md
index 81e89fb10..fc360a6e2 100644
--- a/Docs/tuto_A_material_customization.md
+++ b/Docs/tuto_A_material_customization.md
@@ -5,12 +5,8 @@ The CARLA team prepares every asset to run under certain default settings. Howev
* [__Car materials__](#car-materials)
* [__Customize car materials__](#customize-car-materials)
* [Exterior properties](#exterior-properties)
-* [__Building material__](#building-material)
+* [__Building materials__](#building-materials)
* [__Customize a building material__](#customize-a-building-material)
-* [__Customize the road__](#customize-the-road)
- * [Create a group material](#create-a-group-material)
- * [Change the appearance of the road](#change-the-appearance-of-the-road)
- * [Update the appearance of lane markings](#update-the-appearance-of-lane-markings)
!!! Important
This tutorial only applies to users that work with a build from source, and have access to the Unreal Editor.
@@ -112,6 +108,8 @@ The materials applied to buildings are made of four basic textures that are comb
* `RGB` — Channels with the base colors.
* `Alpha` — This channel defines a mask that allows to modify the color of the portions in white. This is useful to create some variations from the same material.
+![building_diffuse_alpha](img/building_diffuse_alpha.png)
+
* __ORME__ — Maps different properties of the material using specific channels.
* `Ambient occlusion` — Contained in the `R` channel.
* `Roughness` — Contained in the `G` channel.
@@ -124,16 +122,22 @@ The materials applied to buildings are made of four basic textures that are comb
* __Emissive__ — If applicable, this texture is used to set the emissive base colors of the texture.
* `RGB` — Color information for the emissive elements in the texture.
+![emissive](img/EmissiveIntensity.gif)
+
---
## Customize a building material
Similarly to car materials, a building material can be greatly changed if desired, but it is only recommended if the user has some expertise with Unreal Engine. However, there is some customization available for the two main shaders that buildings use.
-* __Glass shader__ — `M_CarWindows_Master`.
+
+![building_material](img/building_material.png)
+
+
+* __Glass shader__ — `M_GlassMaster`.
* `Opacity` — Enable color changes on the white area on the __Diffuse__ `Alpha` texture.
* `Color` — Tint to be applied based on the white area on the __Diffuse__ `Alpha` texture.
-* __Building shader__ — `M_Building_Master`
+* __Building shader__ — `M_MaterialMaster`
* `Change Color` — Enable color changes on the white area on the __Diffuse__ `Alpha` texture.
* `Color` — Tint to be applied based on the white area on the __Diffuse__ `Alpha` texture.
* `Emissive Texture` — Enable the usage of an __Emissive__ texture.
@@ -143,128 +147,6 @@ Similarly to car materials, a building material can be greatly changed if desire
* `MetallicCorrection` — Changes the intensity of the metallic map.
* `NormalFlatness` — Changes the intensity of the normal map.
-
----
-## Customize the road
-
-__RoadPainter__ is a tool that uses OpenDRIVE information to paint roads. To be able to do so, a blueprint is used, which uses a master material, a render target of the road as canvas, and additional decals and meshes. The master material grous a collection of materials that will be used by the blueprint, using brushes to blend their application.
-This makes for an easy way to change drastically the appearence of the road. The initial geometry of the road is painted like a canvas. There is no need to apply photometry techniques nor consider the UVs of the geometry. The result is achieved simply by blending textures and creating masks.
-
-### Create a group material
-
-First of all, a group material will be created. This will contain the instances of the materials the road will be painted with.
-
-__1. Create an instance of the RoadMaster material.__ It can be found in `Game/Carla/Static/GenericMaterials/RoadPainterMaterials`.
-
-![materials_RoadMaster_Materials](img/material_customization/Materials_RoadMaster.jpg)
-
Panel to set materials to be applied on the road.
-
-__2. Set the `RenderTarget`.__ [Create a render target](https://docs.unrealengine.com/en-US/Engine/Rendering/RenderTargets/BlueprintRenderTargets/HowTo/CreatingTextures/index.html) for the road map that is being used. In `Texture Parameter Values` enable `Texture mask` and add the texture.
-
-![materials_RoadMaster_RenderTarget](img/material_customization/Materials_RenderTarget.jpg)
-
Panel where the Render Target should be set.
-
-__3. Set the map size.__ In `Scalar Parameter Values` the field `Map units (CM)`. If the size is not known, use a temporary value. The real size of the map can be retrieved later, when using the blueprint.
-__4. Choose the materials to be applied.__ There is space for one base material and three additional materils that will be used to paint over the base one. The painting information will be stored in the RGB channels of a RenderTarget, one channel per material. Add them to the fields `Base Material`, `Material 1`, `Material 2`, and `Material 3`.
-
-### Change the appearance of the road
-
-The appearence of the road is changed using a blueprint provided by CARLA. The blueprint will paint the road using the materials passed, combined with some brush settings. Additionally, decals and meshes can be added so that the final result is more detailed. This tool takes into account road information and will paint the elements using the orientation of the lane, unless an offset is stated.
-
-!!! Note
- This tool does not interfere with the weather settings that change the road's appearence, such as wetness or precipitation.
-
-__1. Create an instance of the RoadPainter blueprint.__ It can be found in `Carla/Blueprints/LevelDesign`. This blueprint determines how is the road being painted, and how are the materials in `RoadMaster` being used.
-__2. Set the `RenderTarget` and the `Map size`.__ In the `Paint` category. These must be the same as in the __RoadMaster__ material.
-
-![materials_RoadPaint_MatchSize](img/material_customization/Materials_Road_Matchsize.jpg)
-
Panels in group material and road blueprint where the Render Target and Map Size values should match.
-
-!!! Note
- The `Z-size` option in the `Default` panel will give you the exact size of the map. Increase this by a little and make sure both, the blueprint and the master material have the same value.
-
-__3. Apply the group material.__ Select all the road meshes and apply the instance.
-
-__4. For each material, set the brush to be used.__ There are different brushes available in `GenericMaterials/RoadStencil/Alphas`. The materials will be applied over the road using the brush and parameters stated here.
-
-* `Stencil size` — Size of the brush.
-* `Brush strength` — Roughness of the outline.
-* `Spacebeween Brushes` — Distance between strokes.
-* `Max Jitter` — Size variation of the brush between strokes.
-* `Stencil` — The brush to be used.
-* `Rotation` — Rotation applied to the stroke.
-
-![materials_roadpaint_brushes](img/material_customization/Materials_Brush.jpg)
-
-
-__5. For each material, apply it to the desired portions of the road.__ In the `Default` section, there is a series of buttons to choose how materials are applied.
-
-* `Paint all roads` — Applies the brush to all the road.
-* `Paint by actor` — Paints a specific actor being selected.
-* `Paint over circle` — Paints using a circular pattern, useful to provide variation.
-* `Paint over square` — Paints using a square pattern, useful to provide variation.
-
-This section also contains options to erase the changes applied.
-
-* `Clear all` — Erases all the painting applied by the blueprint.
-* `Clear materials` — Remove the materials currently active.
-* `Clear material by actor` — Removes material closest to the actor selected.
-
-![materials_roadpaint_brushes](img/material_customization/Materials_RoadPainter_Default.jpg)
-
Different painting and erasing options.
-
-!!! Note
- Move the editor view a little for the changes to be visible.
-
-__5. Add decals and meshes.__ Add the elements to the corresponding array and set some basic parameters for how should these be spawned over the road.
-
-* `Decal/Mesh Scale` — Scale of the decal/mesh per axis.
-* `Fixed Decal/Mesh Offset` — Deviation from the center of the lane per axis.
-* `Decal/Mesh Random Offset` — Max deviation from the center of the lane per axis.
-* `Decal/Mesh Random Yaw` — Max random yaw rotation.
-* `Decal/Mesh Min Scale` — Minimum random scale applied to the decal/mesh.
-* `Decal/Mesh Max Scale` — Max random scale applied to the decal/mesh.
-
-![materials_](img/material_customization/Materials_DecalsMeshes.jpg)
-
Decals and Meshes panels.
-
-__6. Spawn the decals and meshes.__ Use the buttons `Spawn decals` and `Spawn meshes` to do so.
-
-__7. Play around.__ Try different settings, materials and brushes to obtain completely different results. This tool allows to create different presets for the road appearence and changing between them simply by changing the group material and updating a few settings.
-
-Here is an example of the how the appearence of the road changes along the previous steps.
-
-![materials_roadpaint_mat00](img/material_customization/Materials_Road_MaterialBase.jpg)
-
-
-### Update the appearance of lane markings
-
-After the road's appearance has been customized, the lane markings should be updated accordingly to get a realistic look. The process to do so, is really simple.
-
-__1. Create a copy of the group material.__ This has be the same as it was for the road.
-__2. Select the lane marking meshes.__
-__3. Mark them as lane markings.__ In `Static Switch Parameter Values` enable `LaneMark`. This will update the lane markings to be consistent to the painting applied to the road.
-__4. Choose the color of the lane marking.__ In `Texture` set the `LaneColor` to the value desired. This will set the lane markings selected to have a base paint of the stated color.
-
-
---
That is a wrap on the most remarkable ways users can customize the materials of vehicles and buildings.
@@ -273,7 +155,7 @@ Any doubts that may arise are more than welcomed in the forum.
\ No newline at end of file
diff --git a/Docs/tuto_A_vehicle_modelling.md b/Docs/tuto_A_vehicle_modelling.md
deleted file mode 100644
index 06d536dca..000000000
--- a/Docs/tuto_A_vehicle_modelling.md
+++ /dev/null
@@ -1,116 +0,0 @@
-# How to model vehicles
-
-* [__4-wheeled Vehicles__](#4-wheeled-vehicles)
- * [Modelling](#modelling)
- * [Naming materials](#naming-materials)
- * [Texturing](#texturing)
- * [Rigging](#rigging)
- * [LODs](#lods)
-
----
-## 4-Wheeled Vehicles
-
-### Modelling
-
-Vehicles must have a minimum of 10.000 and a maximum of 17.000 Tris
-approximately. We model the vehicles using the size and scale of actual cars.
-The bottom part of the vehicle consists of a plane adjusted to the Bodywork.
-
-The vehicle must be divided in 6 materials:
-
- 1. **BodyWork:**
- The Bodywork includes the chassis, doors, car handle, and front and back
- parts of the vehicle. The BodyWork material is controlled by Unreal Engine.
- You can add logos and some details, but remember, all the details will be
- painted by Unreal using the same color. Use the alpha channel if you want to
- paint details with a different color.
-
- 2. **Wheels:**
- Model the Wheels with hubcaps and add details to the tire with Substance. In
- the UV, add the tires and the hubcaps separately.
-
- 3. **Interior:**
- The Interior includes the seats, the steering wheel, and the bottom of the
- vehicle. You don’t need to add much detail here.
-
- 4. **Details:**
- Lights, logos, exhaust pipes, protections, and grille.
-
- 5. **Glass:**
- Light glasses, windows, etc. This material is controlled by Unreal.
-
- 6. **LicencePlate:**
- Put a rectangular plane with this size 29-12 cm, for the licence Plate.
- We assign the license plate texture.
-
-### Naming materials
-
-* M(Material)_"CarName"_Bodywork(part of car)
-
-* M_"CarName"_Wheel
-
-* M_"CarName"_Interior
-
-* M_"CarName"_Details
-
-* M_"CarName"_Glass
-
-* M_"CarName"_LicencePlate
-
-### Texturing
-
-The size of the textures is 2048x2048.
-
-* T_"CarName"_PartOfMaterial_d (BaseColor)
-
-* T_"CarName"_PartOfMaterial_n (Normal)
-
-* T_"CarName"_PartOfMaterial_orm (OcclusionRoughnessMetallic)
-
-* **EXAMPLE**:
-Type of car Tesla Model 3
-
-TEXTURES
-* T_Tesla3_BodyWork_d
-* T_Tesla3_BodyWork_n
-* T_Tesla3_BodyWork_orm
-
-MATERIAL
-* M_Tesla3_BodyWork
-
-### Rigging
-
-The easiest way is to copy the "General4WheeledVehicleSkeleton" present in our project,
-either by exporting it and copying it to your model or by creating your skeleton
-using the same bone names and orientation.
-
-The model and every bone must be oriented towards positive X axis with the Z
-axis facing upwards.
-
-_Bone Setup:_
-
-Vhehicle_Base: The origin point of the mesh, place it in the point (0,0,0) of the scene.
-
-* Wheel_Front_Left: Set the joint's position in the middle of the Wheel.
-
-* Wheel_Front_Right: Set the joint's position in the middle of the Wheel.
-
-* Wheel_Rear_Left: Set the joint's position in the middle of the Wheel.
-
-* Wheel_Rear_Left: Set the joint's position in the middle of the Wheel.
-
-#### LODs
-
-All vehicle LODs must be made in Maya or other 3D software. Because Unreal does
-not generate LODs automatically, you can adjust the number of Tris to make a
-smooth transitions between levels.
-
-* _Level 0_ - Original
-
-* _Level 1_ - Deleted 2.000/2.500 Tris (_Do not delete the interior and steering wheel_)
-
-* _Level 2_ - Deleted 2.000/2.500 Tris (_Do not delete the interior_)
-
-* _Level 3_ - Deleted 2.000/2.500 Tris (_Delete the interior_)
-
-* _Level 4_ - Simple shape of a vehicle.
diff --git a/Docs/tuto_D_create_semantic_tags.md b/Docs/tuto_D_create_semantic_tags.md
index cc4fa5151..3a9e8de14 100644
--- a/Docs/tuto_D_create_semantic_tags.md
+++ b/Docs/tuto_D_create_semantic_tags.md
@@ -68,7 +68,7 @@ __Open `World.cpp`__ in `carla/PythonAPI/carla/sourc/libcarla` and add the new t
---
-Read the **[F.A.Q.](build_faq.md)** page or post in the [CARLA forum](https://forum.carla.org/c/installation-issues/linux) for any issues, doubts or suggestions.
+Read the **[F.A.Q.](build_faq.md)** page or post in the [CARLA forum](https://github.com/carla-simulator/carla/discussions) for any issues, doubts or suggestions.
What's next?
diff --git a/Docs/tuto_D_customize_vehicle_suspension.md b/Docs/tuto_D_customize_vehicle_suspension.md
index 624555314..3ed1ffb20 100644
--- a/Docs/tuto_D_customize_vehicle_suspension.md
+++ b/Docs/tuto_D_customize_vehicle_suspension.md
@@ -120,7 +120,7 @@ Use the forum to post any doubts, issues or suggestions regarding this topic.
diff --git a/Docs/tuto_D_generate_colliders.md b/Docs/tuto_D_generate_colliders.md
index 89562d39b..b4b0bf864 100644
--- a/Docs/tuto_D_generate_colliders.md
+++ b/Docs/tuto_D_generate_colliders.md
@@ -134,7 +134,7 @@ Open CARLA and mess around for a while. If there are any doubts, feel free to po
diff --git a/Docs/tuto_D_generate_pedestrian_navigation.md b/Docs/tuto_D_generate_pedestrian_navigation.md
deleted file mode 100644
index 685ea214b..000000000
--- a/Docs/tuto_D_generate_pedestrian_navigation.md
+++ /dev/null
@@ -1,68 +0,0 @@
-# How to generate the pedestrian navigation info
-
-The pedestrians to walk need information about the map in a specific format. That file that describes the map for navigation is a binary file with extension `.BIN`, and they are saved in the **Nav** folder of the map. Each map needs a `.BIN` file with the same name that the map, so automatically can be loaded with the map.
-
-This `.BIN` file is generated from the Recast & Detour library and has all the information that allows pathfinding and crow management.
-
-If we need to generate this `.BIN` file for a custom map, we need to follow this process:
-
-* Export the map meshes
-* Rebuild the `.BIN` file with RecastBuilder
-* Copy the `.BIN` file in a `Nav/` folder with the map
-
----
-## Export meshes
-
-We have several types of meshes for navigation. The meshes need to be identified as one of those types, using specific nomenclature.
-
-| Type | Start with | Description |
-| ----------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |
-| Ground | `Road_Sidewalk` | Pedestrians can walk over these meshes freely (sidewalks...). |
-| Grass | `Road_Crosswalk` | Pedestrians can walk over these meshes but as a second option if no ground is found. |
-| Road | `Road_Grass` | Pedestrians won't be allowed to walk on it unless we specify some percentage of pedestrians that will be allowed. |
-| Crosswalk | `Road_Road`, `Road_Curb`, `Road_Gutter`, `Road_Marking` | Pedestrians can cross the roads only through these meshes. |
-| Block | Any other name | Pedestrians will avoid these meshes always (are obstacles like traffic lights, trees, houses...). |
-
-
-
-
-
-For instance, all road meshes need to start with `Road_Road` e.g: `Road_Road_Mesh_1`, `Road_Road_Mesh_2`...
-
-This nomenclature is used by RoadRunner when it exports the map, so we are just following the same.
-
-Also, we don't need to export meshes that are not of interest by the navigation system, like landscapes where pedestrians will not walk, or UE4's _sky domes_, rivers, lakes and so on.
-We can **tag** any mesh with the name **NoExport** and then the exporter will ignore that mesh.
-
-Once we have all meshes with the proper nomenclature and tagged the ones that we want to ignore, we can call the Carla Exporter that is found under the `File > Actors > Carla Exporter`:
-
-![Carla Exporter](img/tuto_D_pedestrian_CarlaExporter.jpg)
-
-The `.OBJ` file will be saved with the name of the map with extension OBJ in the **CarlaUE4/Saved** folder of UE4.
-
----
-## Rebuild the navigation binary
-
-With Recast & Detour library comes an executable file that needs to be used to generate the final `.BIN` file.
-The executable uses by default the parameters to work on Carla, and you only need to pass as parameter the `.OBJ` you exported above, and the `.BIN` will be created.
-
-You can find the executable, on the `Carla/Build/recast-{version}-install/bin/` folder, already compiled when Carla was installed.
-
-Run:
-
-```sh
-$ RecastBuilder test.object
-```
-
-And it will create a `test.bin` file, that needs to be copied to the map folder, inside the `Nav/` folder.
-
-For example, this would be the structure of files of a Test map:
-
-```
-Test/
- ├─ Test.umap
- ├─ Nav/
- │ └─ Test.bin
- └─ OpenDrive/
- └─ Test.xodr
-```
diff --git a/Docs/tuto_G_carsim_integration.md b/Docs/tuto_G_carsim_integration.md
new file mode 100644
index 000000000..78625e7a0
--- /dev/null
+++ b/Docs/tuto_G_carsim_integration.md
@@ -0,0 +1,142 @@
+# CarSim Integration (Beta)
+
+CARLA's integration with CarSim allows vehicle controls in CARLA to be forwarded to CarSim. CarSim will do all required physics calculations of the vehicle and return the new state to CARLA.
+
+This page shows you how to generate a `.sim` file, explains how vehicle dimensions relate between CARLA and CarSim and how to run a simulation on CARLA using the CarSim integration.
+
+!!! Warning
+ This feature is in beta release. This means that development of the feature is ongoing and some aspects of the feature may not work as expected. If you come across any problems feel free to open an issue on [GitHub](https://github.com/carla-simulator/carla).
+
+* [__Before you begin__](#before-you-begin)
+* [__Set up CarSim__](#set-up-carsim)
+ * [__Generate the .sim file__](#generate-the-sim-file)
+ * [__On Windows__](#on-windows)
+ * [__On Ubuntu__](#on-ubuntu)
+ * [__Vehicle sizes__](#vehicle-sizes)
+* [__Run the simulation__](#run-the-simulation)
+
+---
+## Before you begin
+
+1. You will need a license for CarSim and to have the software up and running. If you don't currently have a license for CarSim, you can contact the team [here](https://www.carsim.com/forms/additional_information.php) for information.
+2. To allow communication with Unreal Engine you will need to install the VehicleSim Dynamics plugin (version 2020.0) for Unreal Engine 4.24. For information on finding specific versions of the plugin, check this [link](https://www.carsim.com/products/supporting/unreal/index.php). Installation of the plugin will depend on your operating system:
+
+ __For Windows__:
+
+ Get the plugin [here](https://www.unrealengine.com/marketplace/en-US/product/carsim-vehicle-dynamics).
+
+ __For Ubuntu__:
+
+ 1. Download the plugin [here](https://www.carsim.com/users/unreal_plugin/unreal_plugin_2020_0.php).
+ 2. Replace the file `CarSim.Build.cs` with the file found [here](https://carla-releases.s3.eu-west-3.amazonaws.com/Backup/CarSim.Build.cs) in order to use the correct solver for Ubuntu.
+
+3. This step can be skipped if you are using the packaged version of CARLA. The packaged version has already been compiled using this flag but if you are building CARLA from source then you will need to compile the server with the `--carsim` flag.
+
+ If you are building CARLA from source, run the following command in the root folder to compile the server with the `--carsim` flag:
+
+```sh
+ make launch ARGS="--carsim"
+```
+
+## Set up CarSim
+
+The following section details how to generate the `.sim` file which is required to run the simulation. There is also important information detailed regarding the relationship of vehicle sizes between CARLA and CarSim.
+
+#### Generate the .sim file
+
+The `.sim` file describes the simulation to be run in both CARLA and CarSim. This file is required by the plugin to run the simulation. There is currently no way to generate this file on Ubuntu, however we will describe below how to use a previously generated file to run the simulation on Ubuntu.
+
+##### On Windows
+
+After you have configured all the parameters on CarSim, use the GUI to generate the `.sim` file as highlighted below:
+
+![generate .sim file](img/carsim_generate.jpg)
+
+The resulting `.sim` file should look something like this:
+
+```
+SIMFILE
+
+SET_MACRO $(ROOT_FILE_NAME)$ Run_dd7a828d-4b14-4c77-9d09-1974401d6b25
+SET_MACRO $(OUTPUT_PATH)$ D:\carsim\Data\Results
+SET_MACRO $(WORK_DIR)$ D:\carsim\Data\
+SET_MACRO $(OUTPUT_FILE_PREFIX)$ $(WORK_DIR)$Results\Run_dd7a828d-4b14-4c77-9d09-1974401d6b25\LastRun
+
+FILEBASE $(OUTPUT_FILE_PREFIX)$
+INPUT $(WORK_DIR)$Results\$(ROOT_FILE_NAME)$\Run_all.par
+INPUTARCHIVE $(OUTPUT_FILE_PREFIX)$_all.par
+ECHO $(OUTPUT_FILE_PREFIX)$_echo.par
+FINAL $(OUTPUT_FILE_PREFIX)$_end.par
+LOGFILE $(OUTPUT_FILE_PREFIX)$_log.txt
+ERDFILE $(OUTPUT_FILE_PREFIX)$.vs
+PROGDIR D:\carsim\
+DATADIR D:\carsim\Data\
+GUI_REFRESH_V CarSim_RefreshEvent_7760
+RESOURCEDIR D:\carsim\\Resources\
+PRODUCT_ID CarSim
+PRODUCT_VER 2020.0
+ANIFILE D:\carsim\Data\runs\animator.par
+VEHICLE_CODE i_i
+EXT_MODEL_STEP 0.00050000
+PORTS_IMP 0
+PORTS_EXP 0
+
+DLLFILE D:\carsim\Programs\solvers\carsim_64.dll
+END
+```
+##### On Ubuntu
+
+There is no way to create the `.sim` file via GUI on Ubuntu. In order to proceed you will need to follow these steps:
+
+1. Generate the `.sim` file in Windows or use the file template below.
+2. Modify the `.sim` file so the variables `INPUT`, `INPUTARCHIVE`, `LOGFILE` and so on point towards the corresponding files in your Ubuntu
+system.
+3. Replace the `DLLFILE` line to point towards the CarSim solver which, in the default installation, will be `SOFILE /opt/carsim_2020.0/lib64/libcarsim.so.2020.0`.
+
+The resulting file should be similar to this:
+
+```
+SIMFILE
+
+FILEBASE /path/to/LastRun
+INPUT /path/to/Run_all.par
+INPUTARCHIVE /path/to/LastRun_all.par
+ECHO /path/to/LastRun_echo.par
+FINAL /path/to/LastRun_end.par
+LOGFILE /path/to/LastRun_log.txt
+ERDFILE /path/to/LastRun.vs
+PROGDIR /opt/carsim_2020.0/lib64/
+DATADIR .
+PRODUCT_ID CarSim
+PRODUCT_VER 2020.0
+VEHICLE_CODE i_i
+
+SOFILE /opt/carsim_2020.0/lib64/libcarsim.so.2020.0
+END
+```
+#### Vehicle sizes
+
+Although CarSim lets you specify the dimensions of the vehicle to use in the simulation, there is currently no correlation between a CarSim vehicle and a CARLA
+vehicle. This means that the vehicles in both programmes will have different dimensions. The role of the CARLA vehicle is only to act as a placeholder during the simulation.
+
+![carsim vehicle sizes](img/carsim_vehicle_sizes.jpg)
+
+!!! Note
+ There is no correlation between vehicle size in CARLA and CarSim. The CARLA vehicle is only a simulation placeholder.
+
+## Run the simulation
+
+All that is needed when running the simulation is to enable CarSim when you spawn a vehicle. This can be done by passing the path to the `.sim` file to the following [method](https://carla.readthedocs.io/en/latest/python_api/#carla.Vehicle.enable_carsim) of the Python API:
+
+```sh
+vehicle.enable_carsim()
+```
+
+All input controls sent to the vehicle will be forwarded to CarSim. CarSim will update the
+physics and send back the status of the vehicle (the transform) to the CARLA vehicle.
+
+Once the simulation has finished you can analyze all the data in CarSim as usual.
+
+![carsim analysis](img/carsim_analysis.jpg)
+
+
diff --git a/Docs/tuto_G_chrono.md b/Docs/tuto_G_chrono.md
new file mode 100644
index 000000000..279cc2bc2
--- /dev/null
+++ b/Docs/tuto_G_chrono.md
@@ -0,0 +1,75 @@
+# Chrono Integration
+
+This guide outlines what Chrono is, how to use it in CARLA, and the limitations involved in the integration.
+
+- [__Project Chrono__](#project-chrono)
+- [__Using Chrono on CARLA__](#using-chrono-on-carla)
+ - [Configuring the server](#configuring-the-server)
+ - [Enabling Chrono physics](#enabling-chrono-physics)
+- [__Limitations__](#limitations)
+
+---
+
+## Project Chrono
+
+[Project Chrono](https://projectchrono.org/) is an open-source, multi-physics simulation engine that provides highly realistic vehicle dynamics using a template-based approach. The integration in CARLA allows users to utilize Chrono templates to simulate vehicle dynamics while navigating a map.
+
+---
+
+## Using Chrono on CARLA
+
+To use the Chrono integration, you must first configure the server with a tag on startup and then use the PythonAPI to enable it on a spawned vehicle. Read on for more details.
+
+### Configuring the server
+
+Chrono will only work if the CARLA server is compiled with the Chrono tag.
+
+__In the build from source version of CARLA__, run the following command to start the server:
+
+```sh
+make launch ARGS="--chrono"
+```
+
+---
+
+### Enabling Chrono physics
+
+Chrono physics is enabled using the `enable_chrono_physics` method available through the [Actor](python_api.md#carlaactor) class. As well as values for substeps and substep delta time, it requires three template files and a base path to locate those files:
+
+- __`base_path`:__ Path of the directory which contains the template files. This is necessary to ensure that auxiliary files referenced from the template files have a common base path from which to search.
+- __`vehicle_json`:__ Path of the vehicle template file relative to the `base_path`.
+- __`tire_json`:__ Path of the tire template file relative to the `base_path`.
+- __`powertrain_json`:__ Path of the powertrain template file relative to the `base_path`.
+
+!!! Important
+ Double-check your paths. Incorrect or missing paths can cause Unreal Engine to crash.
+
+There are a variety of example template files for different vehicles available in `Build/chrono-install/share/chrono/data/vehicle`. Read the Project Chrono [documentation](https://api.projectchrono.org/manual_vehicle.html) to find out more about their vehicle examples and how to create templates.
+
+See below for an example of how to enable Chrono physics:
+
+```python
+ # Spawn your vehicle
+ vehicle = world.spawn_actor(bp, spawn_point)
+
+ # Set the base path
+ base_path = "/path/to/carla/Build/chrono-install/share/chrono/data/vehicle/"
+
+ # Set the template files
+
+ vehicle_json = "sedan/vehicle/Sedan_Vehicle.json"
+ powertrain_json = "sedan/powertrain/Sedan_SimpleMapPowertrain.json"
+ tire_json = "sedan/tire/Sedan_TMeasyTire.json"
+
+ # Enable Chrono physics
+
+ vehicle.enable_chrono_physics(5000, 0.002, vehicle_json, powertrain_json, tire_json, base_path)
+```
+
+You can try the Chrono physics integration using the example script `manual_control_chrono.py` found in `PythonAPI/examples`. After running the script, press `Ctrl + o` to enable Chrono.
+
+---
+
+### Limitations
+
+This integration does not support collisions. __When a collision occurs, the vehicle will revert to CARLA default physics.__
diff --git a/Docs/tuto_G_control_vehicle_physics.md b/Docs/tuto_G_control_vehicle_physics.md
index 41eb51769..de2772ce1 100644
--- a/Docs/tuto_G_control_vehicle_physics.md
+++ b/Docs/tuto_G_control_vehicle_physics.md
@@ -1,16 +1,18 @@
-# How to control vehicle physics
+# Control and monitor vehicle physics
-Physics properties can be tuned for vehicles and its wheels.
-These changes are applied **only** on runtime, and values are set back to default ones when
-the execution ends.
+Physics properties can be tuned for vehicles and their wheels.
+These changes are applied **only** on runtime, and values are set back to default when the execution ends.
These properties are controlled through a
[carla.VehiclePhysicsControl](python_api.md#carla.VehiclePhysicsControl) object,
which also provides the control of each wheel's physics through a
[carla.WheelPhysicsControl](python_api.md#carla.WheelPhysicsControl) object.
+- [__Vehicle control code example__](#vehicle-control-code-example)
+- [__Viewing vehicle telemetry__](#viewing-vehicle-telemetry)
+
---
-## Example
+## Vehicle control code example
```py
import carla
@@ -23,17 +25,16 @@ def main():
# Get World and Actors
world = client.get_world()
- current_map = world.get_map()
actors = world.get_actors()
# Get a random vehicle from world (there should be one at least)
vehicle = random.choice([actor for actor in actors if 'vehicle' in actor.type_id])
# Create Wheels Physics Control
- front_left_wheel = carla.WheelPhysicsControl(tire_friction=4.5, damping_rate=1.0, max_steer_angle=70.0, radius=30.0)
- front_right_wheel = carla.WheelPhysicsControl(tire_friction=2.5, damping_rate=1.5, max_steer_angle=70.0, radius=25.0)
- rear_left_wheel = carla.WheelPhysicsControl(tire_friction=1.0, damping_rate=0.2, max_steer_angle=0.0, radius=15.0)
- rear_right_wheel = carla.WheelPhysicsControl(tire_friction=1.5, damping_rate=1.3, max_steer_angle=0.0, radius=20.0)
+ front_left_wheel = carla.WheelPhysicsControl(tire_friction=2.0, damping_rate=1.5, max_steer_angle=70.0, long_stiff_value=1000)
+ front_right_wheel = carla.WheelPhysicsControl(tire_friction=2.0, damping_rate=1.5, max_steer_angle=70.0, long_stiff_value=1000)
+ rear_left_wheel = carla.WheelPhysicsControl(tire_friction=3.0, damping_rate=1.5, max_steer_angle=0.0, long_stiff_value=1000)
+ rear_right_wheel = carla.WheelPhysicsControl(tire_friction=3.0, damping_rate=1.5, max_steer_angle=0.0, long_stiff_value=1000)
wheels = [front_left_wheel, front_right_wheel, rear_left_wheel, rear_right_wheel]
@@ -50,12 +51,23 @@ def main():
physics_control.mass = 10000
physics_control.drag_coefficient = 0.25
physics_control.steering_curve = [carla.Vector2D(x=0, y=1), carla.Vector2D(x=100, y=1), carla.Vector2D(x=300, y=1)]
- physics_control.wheels = wheels
physics_control.use_sweep_wheel_collision = True
+ physics_control.wheels = wheels
# Apply Vehicle Physics Control for the vehicle
vehicle.apply_physics_control(physics_control)
+ print(physics_control)
if __name__ == '__main__':
main()
```
+
+---
+
+## Viewing vehicle telemetry
+
+Vehicle telemetry can be visualised by calling the [`Actor.enable_debug_telemetry`](python_api.md#carla.Actor.enable_debug_telemetry) method. This will provide graph views of several metrics on the server window as well as vehicle reference points on the simulation window.
+
+![vehicle_telemetry](img/vehicle_telemetry.png)
+
+You can try the telemetry visualisation tool in the example script `manual_control.py` located in `PythonAPI/examples`. Activate the telemetry view by pressing `T`.
diff --git a/Docs/tuto_G_openstreetmap.md b/Docs/tuto_G_openstreetmap.md
index f80bdd0c7..2e369ce51 100644
--- a/Docs/tuto_G_openstreetmap.md
+++ b/Docs/tuto_G_openstreetmap.md
@@ -1,59 +1,85 @@
# Generate maps with OpenStreetMap
-OpenStreetMap is an open license map of the world developed by contributors. Sections of these map can be exported to a `.osm` file, the OpenSreetMap format, which is essentially an XML. CARLA can convert this file to OpenDRIVE format and ingest it as any other OpenDRIVE map using the [OpenDRIVE Standalone Mode](#adv_opendrive.md). The process is quite straightforward.
+In this guide you will learn:
-* [__1- Obtain a map with OpenStreetMap__](#1-obtain-a-map-with-openstreetmap)
-* [__2- Convert to OpenDRIVE format__](#2-convert-to-opendrive-format)
-* [__3- Import into CARLA__](#3-import-into-carla)
+- How to export a map from OpenStreetMaps.
+- The different formats of map that can be used in CARLA and each format's limitations.
+- How to convert the native `.osm` format to `.xodr`.
+- How to include traffic light information in the `.xodr` file.
+- How to run the final map in a CARLA simulation.
+
+[OpenStreetMap](https://www.openstreetmap.org) is an open data map of the world developed by thousands of contributors and licensed under the [Open Data Commons Open Database License](https://opendatacommons.org/licenses/odbl/). Sections of the map can be exported to an XML formatted `.osm` file. CARLA can convert this file to an OpenDRIVE format and ingest it using the [OpenDRIVE Standalone Mode](#adv_opendrive.md).
+
+- [__Export a map with OpenStreetMap__](#export-a-map-with-openstreetmap)
+- [__Using OpenStreetMaps in CARLA__](#using-openstreetmaps-in-carla)
+- [__Convert OpenStreetMap format to OpenDRIVE format__](#convert-openstreetmap-format-to-opendrive-format)
+ - [Linux](#linux)
+ - [Windows](#windows)
+ - [Generate Traffic Lights](#generate-traffic-lights)
+- [__Ingest into CARLA__](#ingest-into-carla)
---
-## 1- Obtain a map with OpenStreetMap
+## Export a map with OpenStreetMap
-The first thing to do is use [OpenStreetMap](https://www.openstreetmap.org) to generate the file containing the map information.
+This section explains how to export your desired map information from Open Street Map:
-__1.1. Go to [openstreetmap.org](https://www.openstreetmap.org)__. If the map is not properly visualized, try changing the layer in the righ pannel.
+__1.__ Navigate to the [Open Street Map website](https://www.openstreetmap.org). You will see the map view and a panel on the right side of the window where you can configure different map layers, query different features, toggle the legend, and more.
-__1.2 Search for a desired location__ and zoom in to a specific area.
+__2.__ Search for your desired location and zoom in to a specific area.
![openstreetmap_view](img/tuto_g_osm_web.jpg)
-!!! Warning
- Due to the Unreal Engine limitations, CARLA can ingest maps of a limited size (large cities like Paris push the limits of the engine). Additionally, the bigger the map, the longer the conversion to OpenDRIVE will take.
+!!! Note
+ If you would like to use a map of a large area, for example, Paris, you may consider using CARLA's [__Large Map__ feature](large_map_overview.md).
-__1.3.Click on `Export`__ in the upper left side of the window. The __Export__ pannel will open.
+__3.__ Click on _Export_ on the upper left side of the window to open the _Export_ panel.
-__1.4. Click on `Manually select a different area`__ in the __Export__ pannel.
+__4.__ Click on _Manually select a different area_ in the _Export_ panel.
-__1.5. Select a custom area__ by dragging the corners of the square area in the viewport.
+__5.__ Select a custom area by dragging the corners of the square area in the viewport.
-__1.6. Click the `Export` button__ in the __Export__ pannel, and save the map information of the selected area as a `.osm` file.
+__6.__ Click the _Export_ button in the _Export_ panel and save the map information of the selected area as a `.osm` file.
![openstreetmap_area](img/tuto_g_osm_area.jpg)
---
-## 2- Convert to OpenDRIVE format
+## Using OpenStreetMaps in CARLA
-CARLA can read a the content in the `.osm` file generated with OpenStreetMap, and convert it to OpenDRIVE format so that it can be ingested as a CARLA map. This can be done using the following classes in the PythonAPI.
+Open Street Map data can be used in CARLA via three different methods. The method you use will depend on if the data is in the original `.osm` format or if you convert the file to `.xodr` using the conversion method explained in the following sections. Keeping the file in `.osm` is the most restrictive method as it does not allow for settings customization.
-* __[carla.Osm2Odr](python_api.md#carla.Osm2Odr)__ – The class that does the conversion. It takes the content of the `.osm` parsed as strind, and returns a string containing the resulting `.xodr`.
- * `osm_file` — The content of the initial `.osm` file parsed as string.
- * `settings` — A [carla.Osm2OdrSettings](python_api.md#carla.Osm2OdrSettings) object containing the settings to parameterize the conversion.
-* __[carla.Osm2OdrSettings](python_api.md#carla.Osm2OdrSettings)__ – Helper class that contains different parameters used during the conversion.
- * `use_offsets` *(default False)* — Determines whereas the map should be generated with an offset, thus moving the origin from the center according to that offset.
- * `offset_x` *(default 0.0)* — Offset in the X axis.
- * `offset_y` *(default 0.0)* — Offset in the Y axis.
- * `default_lane_width` *(default 4.0)* — Determines the width that lanes should have in the resulting XODR file.
- * `elevation_layer_height` *(default 0.0)* — Determines the height separating elements in different layers, used for overlapping elements. Read more on [layers](https://wiki.openstreetmap.org/wiki/Key:layer).
+__Options available for `.xodr` format:__
+
+- Generate the map in your own script. __This method allows parameterization.__
+- Pass the file as a parameter to CARLA's `config.py`. __This method does not allow parameterization.__
+
+__Options available for `.osm` format:__
+
+- Pass the file as a parameter to CARLA's `config.py`. __This method does not allow parameterization.__
+
+The following sections will provide more detail on the options listed above.
+
+---
+
+## Convert OpenStreetMap format to OpenDRIVE format
+
+This section demonstrates how to use the Python API to convert the `.osm` file we exported in the previous section to `.xodr` format so that it is ready for use in CARLA.
+
+The [carla.Osm2OdrSettings](python_api.md#carla.Osm2OdrSettings) class is used to configure conversion settings such as offset values, traffic light generation, origin coordinates, and more. The full list of configurable parameters is found in the Python API [documentation](python_api.md#carla.Osm2OdrSettings). The [carla.Osm2Odr](python_api.md#carla.Osm2Odr) class uses these settings to parse the `.osm` data and output it in `.xodr` format.
+
+In Windows, the `.osm` file must be encoded to `UTF-8`. This is not necessary in Linux. Below are example code snippets that show how to perform the file conversion depending on your operating system:
+
+##### Linux
-The input and output of the conversion are not the `.osm` and `.xodr` files itself, but their content. For said reason, the code should be similar to the following.
```py
# Read the .osm data
-f = open("path/to/osm/file", 'r') # Windows will need to encode the file in UTF-8. Read the note below.
+f = open("path/to/osm/file", 'r')
osm_data = f.read()
f.close()
# Define the desired settings. In this case, default values.
settings = carla.Osm2OdrSettings()
+# Set OSM road types to export to OpenDRIVE
+settings.set_osm_way_types(["motorway", "motorway_link", "trunk", "trunk_link", "primary", "primary_link", "secondary", "secondary_link", "tertiary", "tertiary_link", "unclassified", "residential"])
# Convert to .xodr
xodr_data = carla.Osm2Odr.convert(osm_data, settings)
@@ -63,21 +89,72 @@ f.write(xodr_data)
f.close()
```
-!!! Note
- To read the OSM file in Windows, import `io` at the beginning of the script and change the open line to `f = io.open("test", mode="r", encoding="utf-8")`.
+##### Windows
+```py
+import io
-The resulting file contains the road information in OpenDRIVE format.
+# Read the .osm data
+f = io.open("test", mode="r", encoding="utf-8")
+osm_data = f.read()
+f.close()
+
+# Define the desired settings. In this case, default values.
+settings = carla.Osm2OdrSettings()
+# Set OSM road types to export to OpenDRIVE
+settings.set_osm_way_types(["motorway", "motorway_link", "trunk", "trunk_link", "primary", "primary_link", "secondary", "secondary_link", "tertiary", "tertiary_link", "unclassified", "residential"])
+# Convert to .xodr
+xodr_data = carla.Osm2Odr.convert(osm_data, settings)
+
+# save opendrive file
+f = open("path/to/output/file", 'w')
+f.write(xodr_data)
+f.close()
+```
+
---
-## 3- Import into CARLA
+### Generate Traffic Lights
-Finally, the OpenDRIVE file can be easily ingested in CARLA using the [OpenDRIVE Standalone Mode](adv_opendrive.md).
+Open Street Map data can define which junctions are controlled with traffic lights. To use this traffic light data in CARLA, you need to enable it in the OSM map settings via the Python API before converting the `.osm` file to `.xodr` format:
-__a) Using your own script__ — Call for [`client.generate_opendrive_world()`](python_api.md#carla.Client.generate_opendrive_world) through the API. This will generate the new map, and block the simulation until it is ready.
-Use the [carla.OpendriveGenerationParameters](python_api.md#carla.OpendriveGenerationParameters) class to set the parameterization of the mesh generation.
+```py
+# Define the desired settings. In this case, default values.
+settings = carla.Osm2OdrSettings()
+# enable traffic light generation from OSM data
+settings.generate_traffic_lights = True
+# Convert to .xodr
+xodr_data = carla.Osm2Odr.convert(osm_data, settings)
+```
+
+Traffic light data quality can vary depending on the region from which you extract data. Some traffic light information may be missing completely. To work within these limitations, you can use the Python API to configure all junctions to be controlled with traffic lights:
+
+```py
+settings.all_junctions_with_traffic_lights = True
+```
+
+You can also exclude certain roads, e.g., motorway links, from generating traffic lights:
```
+settings.set_traffic_light_excluded_way_types(["motorway_link"])
+```
+
+---
+## Ingest into CARLA
+
+This section explains how to use the different options available to ingest your Open Street Map information into CARLA using the [OpenDRIVE Standalone Mode](adv_opendrive.md).
+
+There are three options available:
+
+[__A)__](#a-use-your-own-script) Generate the map using a converted `.xodr` file in your own custom Python script. __This method allows parameterization.__
+[__B)__](#b-pass-xodr-to-configpy) Pass a converted `.xodr` file as a parameter to the CARLA `config.py` script. __This method does not allow parameterization.__
+[__C)__](#c-pass-osm-to-configpy) Pass the original `.osm` file as a parameter to the CARLA `config.py` script. __This method does not allow parameterization.__
+
+###### A) Use your own script
+
+Generate the new map and block the simulation until it is ready by calling [`client.generate_opendrive_world()`](python_api.md#carla.Client.generate_opendrive_world). Use the [carla.OpendriveGenerationParameters](python_api.md#carla.OpendriveGenerationParameters) class to configure the mesh generation. See below for an example:
+
+```py
vertex_distance = 2.0 # in meters
max_road_length = 500.0 # in meters
wall_height = 0.0 # in meters
@@ -93,31 +170,48 @@ world = client.generate_opendrive_world(
```
!!! Note
- `wall_height = 0.0` is strongly recommended. OpenStreetMap defines lanes in opposing directions as different roads. If walls are generated, this result in wall overlapping and undesired collisions.
+ `wall_height = 0.0` is strongly recommended. OpenStreetMap defines lanes in opposing directions as different roads. If walls are generated, this will result in wall overlapping and undesired collisions.
-__b) Using `config.py`__ — The script can load an OpenStreetMap file directly into CARLA using a new argument.
+###### B) Pass `.xodr` to `config.py`
+
+After you have started a CARLA server, run the following command in a separate terminal to load your Open Street Map:
+
+```sh
+cd PythonAPI/util
+
+python3 config.py -x=/path/to/xodr/file
```
+
+[Default parameters](python_api.md#carla.OpendriveGenerationParameters) will be used.
+###### C) Pass `.osm` to `config.py`
+
+After you have started a CARLA server, run the following command in a separate terminal to load your Open Street Map:
+
+```sh
+cd PythonAPI/util
+
python3 config.py --osm-path=/path/to/OSM/file
```
-!!! Important
- [client.generate_opendrive_world()](python_api.md#carla.Client.generate_opendrive_world) requires the __content of the OpenDRIVE file parsed as string__, and allows parameterization. On the contrary, __`config.py`__ script needs __the path to the `.xodr` file__ and always uses default parameters.
-Either way, the map should be ingested automatically in CARLA and the result should be similar to this.
+[Default parameters](python_api.md#carla.OpendriveGenerationParameters) will be used.
+
+
+Regardless of the method used, the map will be ingested into CARLA and the result should be similar to the image below:
+
![opendrive_meshissue](img/tuto_g_osm_carla.jpg)
Outcome of the CARLA map generation using OpenStreetMap.
+
!!! Warning
- The roads generated end abruptly in the borders of the map. This will cause the TM to crash when vehicles are not able to find the next waypoint. To avoid this, the OSM mode is set to __True__ by default ([set_osm_mode()](python_api.md#carlatrafficmanager)). This will show a warning, and destroy vehicles when necessary.
+ The roads generated end abruptly at the borders of the map. This will cause the Traffic Manager to crash when vehicles are not able to find the next waypoint. To avoid this, the OSM mode in the Traffic Manager is set to __True__ by default ([`set_osm_mode()`](python_api.md#carlatrafficmanager)). This will show a warning and destroy vehicles when necessary.
---
-That is all there is to know about how to use OpenStreetMap to generate CARLA maps.
-
-For issues and doubts related with this topic can be posted in the CARLA forum.
+Any issues and doubts related with this topic can be posted in the CARLA forum.
\ No newline at end of file
diff --git a/Docs/tuto_G_retrieve_data.md b/Docs/tuto_G_retrieve_data.md
index 72decc458..4a3c3427e 100644
--- a/Docs/tuto_G_retrieve_data.md
+++ b/Docs/tuto_G_retrieve_data.md
@@ -199,7 +199,7 @@ python3 spawn_npc.py -n 50 -w 50 --safe
--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)
- --sync Synchronous mode execution
+ --async Asynchronous mode execution
```
@@ -840,7 +840,6 @@ Hereunder are the two scripts gathering the fragments of code for this tutorial.
tutorial_ego.py
```py
-
import glob
import os
import sys
@@ -1076,7 +1075,6 @@ if __name__ == '__main__':
tutorial_replay.py
```py
-
import glob
import os
import sys
@@ -1338,7 +1336,7 @@ Visit the forum to post any doubts or suggestions that have come to mind during
diff --git a/Docs/tuto_G_rllib_integration.md b/Docs/tuto_G_rllib_integration.md
new file mode 100644
index 000000000..185d77b4a
--- /dev/null
+++ b/Docs/tuto_G_rllib_integration.md
@@ -0,0 +1,234 @@
+# RLlib Integration
+
+The RLlib integration brings support between the [Ray/RLlib](https://github.com/ray-project/ray) library and CARLA, allowing the easy use of the CARLA environment for training and inference purposes. Ray is an open source framework that provides a simple, universal API for building distributed applications. Ray is packaged with RLlib, a scalable reinforcement learning library, and Tune, a scalable hyperparameter tuning library.
+
+The RLlib integration allows users to create and use CARLA as an environment of Ray and use that environment for training and inference purposes. The integration is ready to use both locally and in the cloud using AWS.
+
+In this guide we will outline the requirements needed for running the RLlib integration both locally and on AWS, the structure of the integration repository, an overview of how to use the library and then an example of how to set up a Ray experiment using CARLA as an environment.
+
+- [__Before you begin__](#before-you-begin)
+ - [Requirements for running locally](#requirements-for-running-locally)
+ - [Requirements for running on AWS Cloud](#requirements-for-running-on-aws-cloud)
+- [__RLlib repository structure__](#rllib-repository-structure)
+- [__Creating your own experiment__](#creating-your-own-experiment)
+ - [The experiment class](#1-the-experiment-class)
+ - [The environment configuration](#2-the-environment-configuration)
+ - [The training and inference scripts](#3-the-training-and-inference-scripts)
+- [__DQN example__](#dqn-example)
+- [__Running on AWS__](#running-on-aws)
+ - [Configure AWS](#configure-aws)
+ - [Create the training AMI](#create-the-training-ami)
+ - [Configure the cluster](#configure-the-cluster)
+ - [Run the training](#run-the-training)
+ - [Running the DQN example on AWS](#running-the-dqn-example-on-aws)
+
+---
+
+## Before you begin
+
+- Download the RLlib integration from [GitHub](https://github.com/carla-simulator/rllib-integration/tree/main) or clone the repository directly:
+
+```sh
+ git clone https://github.com/carla-simulator/rllib-integration.git
+```
+
+- Requirements vary depending on if you are running locally or on AWS:
+
+>###### Requirements for running locally
+
+>>- [Install a package version of CARLA](https://github.com/carla-simulator/carla/releases) and import the [additional assets](https://carla.readthedocs.io/en/latest/start_quickstart/#import-additional-assets). __The recommended version is CARLA 0.9.11__ as the integration was designed and tested with this version. Other versions may be compatible but have not been fully tested, so use these at your own discretion.
+>>- Navigate into the root folder of the RLlib integration repository and install the Python requirements:
+
+ pip3 install -r requirements.txt
+
+>>- Set an environment variable to locate the CARLA package by running the command below or add `CARLA_ROOT=path/to/carla` to your `.bashrc` file:
+
+ export CARLA_ROOT=path/to/carla
+
+>###### Requirements for running on AWS Cloud
+
+>>- The requirements for running on AWS are taken care of automatically in an install script found in the RLlib integration repository. Find more details in the section ["Running on AWS"](#running-on-aws).
+
+---
+
+## RLlib repository structure
+
+The repository is divided into three directories:
+
+- `rllib_integration` contains all the infrastructure related to CARLA and how to set up the CARLA server, clients and actors. This provides the basic structure that all training and testing experiments must follow.
+- `aws` has the files needed to run in an AWS instance. `aws_helper.py` provides several functionalities that ease the management of EC2 instances, including instance creation and sending and receiving data.
+- `dqn_example` and the `dqn_*` files in the root directory provide an easy-to-understand example on how to set up a Ray experiment using CARLA as its environment.
+
+---
+
+## Creating your own experiment
+
+This section provides a general overview on how to create your own experiment. For a more specific example, see the next section ["DQN example"](#dqn-example).
+
+You will need to create at least four files:
+
+- The experiment class
+- The environment configuration
+- The training and inference scripts
+
+
+#### 1. The experiment class
+
+To use the CARLA environment you need to define a training experiment. Ray requires environments to return a series of specific information. You can see details on the CARLA environment in [`rllib-integration/rllib_integration/carla_env.py`][carlaEnv].
+
+The information required by Ray is dependent on your specific experiment so all experiments should inherit from [`BaseExperiment`][baseExperiment]. This class contains all the functions that need to be overwritten for your own experiment. These are all functions related to the actions, observations and rewards of the training.
+
+[carlaEnv]: https://github.com/carla-simulator/rllib-integration/blob/main/rllib_integration/carla_env.py
+[baseExperiment]: https://github.com/carla-simulator/rllib-integration/blob/main/rllib_integration/base_experiment.py#L41
+
+#### 2. The environment configuration
+
+The experiment should be configured through a `.yaml` file. Any settings passed through the configuration file will override the default settings. The locations of the different default settings are explained below.
+
+The configuration file has three main uses:
+
+1. Sets up most of the CARLA server and client settings, such as timeout or map quality. See the default values [here][defaultCarlaSettings].
+2. Sets up variables specific to your experiment as well as specifying town conditions and the spawning of the ego vehicle and its sensors. The default settings are found [here][defaultExperimentSettings] and provide an example of how to set up sensors.
+3. Configures settings specific to [Ray's training][raySettings]. These settings are related to the specific trainer used. If you are using a built-in model, you can apply settings for it here.
+
+[defaultCarlaSettings]: https://github.com/carla-simulator/rllib-integration/blob/main/rllib_integration/carla_core.py#L23
+[defaultExperimentSettings]: https://github.com/carla-simulator/rllib-integration/blob/main/rllib_integration/base_experiment.py#L12
+[raySettings]: https://github.com/ray-project/ray/blob/master/rllib/agents/trainer.py
+
+#### 3. The training and inference scripts
+
+The last step is to create your own training and inference scripts. This part is completely up to you and is dependent on the Ray API. If you want to create your own specific model, check out [Ray's custom model documentation][rayCustomModel].
+
+[rayCustomModel]: https://docs.ray.io/en/master/rllib-models.html#custom-models-implementing-your-own-forward-logic
+
+---
+
+## DQN example
+
+This section builds upon the previous section to show a specific example on how to work with the RLlib integration using the [BirdView pseudosensor][birdview] and Ray's [DQNTrainer][dqntrainer].
+
+[birdview]: https://github.com/carla-simulator/rllib-integration/blob/main/rllib_integration/sensors/bird_view_manager.py
+[dqntrainer]: https://github.com/ray-project/ray/blob/master/rllib/agents/dqn/dqn.py#L285
+
+The structure of the DQN example is as follows:
+
+- __The experiment class__: [`DQNExperiment`][dqnExperiment], which overwrites the methods of the `BaseExperiment` class.
+- __The configuration file__: [`dqn_example/dqn_config.yaml`][dqnConfig]
+- __The training file__: [`dqn_train.py`][dqnTrain]
+- __The inference file__:
+ - __With Ray__: [`dqn_inference_ray.py`][dqnInferenceRay]
+ - __Without Ray__: [`dqn_inference.py`][dqnInference]
+
+[dqnExperiment]: https://github.com/carla-simulator/rllib-integration/blob/main/dqn_example/dqn_experiment.py#L19
+[dqnConfig]: https://github.com/carla-simulator/rllib-integration/blob/main/dqn_example/dqn_config.yaml
+[dqnTrain]: https://github.com/carla-simulator/rllib-integration/blob/main/dqn_train.py
+[dqnInferenceRay]: https://github.com/carla-simulator/rllib-integration/blob/main/dqn_inference_ray.py
+[dqnInference]: https://github.com/carla-simulator/rllib-integration/blob/main/dqn_inference.py
+
+To run the example locally:
+
+1. Install pytorch:
+
+ pip3 install -r dqn_example/dqn_requirements.txt
+
+2. Run the training file:
+
+ python3 dqn_train.py dqn_example/dqn_config.yaml --name dqn
+
+!!! Note
+ The default configuration uses 1 GPU and 12 CPUs, so if your local machine doesn't have that capacity, lower the numbers in the [configuration file][dqnConfig].
+
+ If you experience out of memory problems, consider reducing the `buffer_size` parameter.
+
+---
+
+## Running on AWS
+
+This section explains how to use the RLlib integration to automatically run training and inference on AWS EC2 instances. To handle the scaling of instances we use the [Ray autoscaler API][rayAutoscaler].
+
+[rayAutoscaler]: https://docs.ray.io/en/latest/cluster/index.html
+
+#### Configure AWS
+
+You will need to configure your boto3 environment correctly. Check [here][awsBoto3] for more information.
+
+[awsBoto3]: https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html
+
+#### Create the training AMI
+
+Use the provided [`aws_helper.py`][awsHelper] script to automatically create the image needed for training by running the command below, passing in the name of the base image and the installation script `install.sh` found in [`rllib-integration/aws/install`][installsh]:
+
+ python3 aws_helper.py create-image --name --installation-scripts --instance-type --volume-size
+
+[awsHelper]: https://github.com/carla-simulator/rllib-integration/blob/main/aws/aws_helper.py
+[installsh]: https://github.com/carla-simulator/rllib-integration/blob/main/aws/install/install.sh
+
+#### Configure the cluster
+
+Once the image is created, there will be an output with image information. To use the Ray autoscaler, update the `` and `` settings in your [autoscaler configuration file][autoscalerSettings] with the information from the output.
+
+[autoscalerSettings]: https://docs.ray.io/en/latest/cluster/config.html
+
+#### Run the training
+
+With the image created, you can use Ray's API to run the training on the cluster:
+
+1. Initialize the cluster:
+
+ ray up
+
+2. (Optional) If the local code has been modified after the cluster initialization, run this command to update it:
+
+ ray rsync-up
+
+3. Run the training:
+
+ ray submit
+
+4. (Optional) Monitor the cluster status:
+
+ ray attach
+ watch -n 1 ray status
+
+5. Shutdown the cluster:
+
+ ray down
+
+
+#### Running the DQN example on AWS
+
+To run the DQN example on AWS:
+
+1. Create the image by passing the [`dqn_example/dqn_autoscaler.yaml`][dqnAutoscaler] configuration to the following command:
+
+ python3 aws_helper.py create-image --name --installation-scripts install/install.sh --instance-type --volume-size
+
+[dqnAutoscaler]: https://github.com/carla-simulator/rllib-integration/blob/main/dqn_example/dqn_autoscaler.yaml
+
+2. Update the `` and `` settings in [`dqn_autoscaler.yaml`][dqnAutoscaler] with the information provided by the previous command.
+
+3. Initialize the cluster:
+
+ ray up dqn_example/dqn_autoscaler.yaml
+
+4. (Optional) Update remote files with local changes:
+
+ ray rsync-up dqn_example/dqn_autoscaler.yaml dqn_example .
+ ray rsync-up dqn_example/dqn_autoscaler.yaml rllib_integration .
+
+5. Run the training:
+
+ ray submit dqn_example/dqn_autoscaler.yaml dqn_train.py -- dqn_example/dqn_config.yaml --auto
+
+6. (Optional) Monitor the cluster status:
+
+ ray attach dqn_example/dqn_autoscaler.yaml
+ watch -n 1 ray status
+
+7. Shutdown the cluster:
+
+ ray down dqn_example/dqn_autoscaler.yaml
+
+---
+
+This guide has outlined how to install and run the RLlib integration on AWS and on a local machine. If you have any questions or ran into any issues working through the guide, feel free to post in the [forum](https://github.com/carla-simulator/carla/discussions/) or raise an issue on [GitHub](https://github.com/carla-simulator/rllib-integration).
diff --git a/Docs/tuto_G_scenic.md b/Docs/tuto_G_scenic.md
new file mode 100644
index 000000000..81e648989
--- /dev/null
+++ b/Docs/tuto_G_scenic.md
@@ -0,0 +1,186 @@
+# Scenic
+
+This guide provides an overview of how to use Scenic with CARLA to generate multiple, diverse scenarios with a single scenario definition. It assumes that users have prior knowledge of the Scenic syntax. If you need to learn more about Scenic, then read their ["Getting Started with Scenic"](https://scenic-lang.readthedocs.io/en/latest/quickstart.html) guide and have a look at their tutorials for creating [static](https://scenic-lang.readthedocs.io/en/latest/tutorials/tutorial.html) and [dynamic](https://scenic-lang.readthedocs.io/en/latest/tutorials/dynamics.html) scenarios.
+
+By the end of the guide you will know:
+
+- The minimum requirements needed to run a Scenic script on CARLA.
+- How to write a simple scenario definition to generate a multitude of scenario simulations.
+- How to run a Scenic script on CARLA.
+- Parameters used to configure Scenic simulations on CARLA.
+
+---
+
+- [__Before you begin__](#before-you-begin)
+- [__Scenic domains__](#scenic-domains)
+- [__Creating a Scenic scenario to use with CARLA__](#creating-a-scenic-scenario-to-use-with-carla)
+- [__Run the scenario__](#run-the-scenario)
+- [__Additional parameters__](#additional-parameters)
+
+---
+
+## Before you begin
+
+Before using Scenic with CARLA, you will need to fulfill the following requirements:
+
+- Install [Python 3.8](https://www.python.org/downloads/) or higher.
+- Install [Scenic](https://scenic-lang.readthedocs.io/en/latest/quickstart.html#installation).
+
+---
+
+## Scenic Domains
+
+Scenic has a general driving domain which allows users to define scenarios that can be run on any driving simulator. In addition, it has other domains that are specific to each simulator. Check [here](https://scenic-lang.readthedocs.io/en/latest/libraries.html) for more information on Scenic domains.
+
+Of particular importance within each domain are the behaviour and actions definitions. Check the links below for reference material to behaviours and actions from the Scenic driving domain and the CARLA domain:
+
+- [Behaviours in the Scenic driving domain](https://scenic-lang.readthedocs.io/en/latest/modules/scenic.domains.driving.behaviors.html)
+- [Behaviours in the CARLA domain](https://scenic-lang.readthedocs.io/en/latest/modules/scenic.simulators.carla.behaviors.html)
+- [Actions in the Scenic driving domain](https://scenic-lang.readthedocs.io/en/latest/modules/scenic.domains.driving.actions.html)
+- [Actions in the CARLA domain](https://scenic-lang.readthedocs.io/en/latest/modules/scenic.simulators.carla.actions.html#module-scenic.simulators.carla.actions)
+
+---
+
+## Creating a Scenic scenario to use with CARLA
+
+This section walks through how to write a basic Scenic script in which a leading vehicle decelerates suddenly due to an obstacle in the road. An ego vehicle then needs to brake suddenly to avoid a collison with the leading vehicle. The [full script](https://github.com/BerkeleyLearnVerify/Scenic/blob/master/examples/carla/Carla_Challenge/carlaChallenge2.scenic) is found in the Scenic repository along with other examples involving more complex road networks.
+
+__1.__ Set the map parameters and declare the model to be used in the scenario:
+
+- An `.xodr` file should be set as the value for the [`map`][scenic_map] parameter, this will be used later to generate road network information.
+- The parameter `carla_map` refers to the name of the CARLA map you would like to use in the simulation. If this is defined then Scenic will load all the assets of the map (buildings, trees, etc.), and if not, then the [OpenDRIVE standalone mode](adv_opendrive.md) will be used.
+- The model includes all the utilities specific to running scenarios on CARLA. This should be defined in all the scripts you want to run on CARLA.
+
+```scenic
+## SET MAP AND MODEL
+param map = localPath('../../../tests/formats/opendrive/maps/CARLA/Town01.xodr')
+param carla_map = 'Town01'
+model scenic.simulators.carla.model
+```
+
+[scenic_map]: https://scenic-lang.readthedocs.io/en/latest/modules/scenic.domains.driving.model.html?highlight=map#module-scenic.domains.driving.model
+
+__2.__ Define the constants to be used in the scenario:
+
+The scenario involves two vehicles, the leading vehicle and the ego vehicle. We will define the ego vehicle model, the speeds of both cars, the distance threshold for braking and the amount of brake to apply.
+
+```scenic
+## CONSTANTS
+EGO_MODEL = "vehicle.lincoln.mkz_2017"
+EGO_SPEED = 10
+EGO_BRAKING_THRESHOLD = 12
+
+LEAD_CAR_SPEED = 10
+LEADCAR_BRAKING_THRESHOLD = 10
+
+BRAKE_ACTION = 1.0
+```
+
+__3__. Define the scenario behaviours:
+
+In this scenario we will use the Scenic [behaviour library](https://scenic-lang.readthedocs.io/en/latest/modules/scenic.domains.driving.behaviors.html) to instruct the ego vehicle to follow the lane at the predefined speed and then brake hard when it gets within a certain distance of another vehicle. The leading vehicle will also follow the lane at the predefined speed and brake hard within a certain distance of any objects:
+
+```scenic
+## DEFINING BEHAVIORS
+# EGO BEHAVIOR: Follow lane, and brake after passing a threshold distance to the leading car
+behavior EgoBehavior(speed=10):
+ try:
+ do FollowLaneBehavior(speed)
+
+ interrupt when withinDistanceToAnyCars(self, EGO_BRAKING_THRESHOLD):
+ take SetBrakeAction(BRAKE_ACTION)
+
+# LEAD CAR BEHAVIOR: Follow lane, and brake after passing a threshold distance to obstacle
+behavior LeadingCarBehavior(speed=10):
+ try:
+ do FollowLaneBehavior(speed)
+
+ interrupt when withinDistanceToAnyObjs(self, LEADCAR_BRAKING_THRESHOLD):
+ take SetBrakeAction(BRAKE_ACTION)
+```
+
+__4.__ Generate the road network:
+
+The Scenic [roads library](https://scenic-lang.readthedocs.io/en/latest/modules/scenic.domains.driving.roads.html) is used to generate the road network geometry and traffic information. The road network is represented by an instance of the [`Network`](https://scenic-lang.readthedocs.io/en/latest/modules/scenic.domains.driving.roads.html#scenic.domains.driving.roads.Network) class and is generated from the `.xodr` file defined at the beginning of the script.
+
+```scenic
+## DEFINING SPATIAL RELATIONS
+# make sure to put '*' to uniformly randomly select from all elements of the list, 'lanes'
+lane = Uniform(*network.lanes)
+```
+
+__5.__ Set the scene:
+
+We will now define the starting positions for the vehicles and placement of objects.
+
+- Place a trash can in the middle of the lane:
+
+```scenic
+obstacle = Trash on lane.centerline
+```
+
+- Place the leading car driving at the predefined speed along the road at a distance of between 50 and 30 meters behind the obstacle:
+
+```scenic
+leadCar = Car following roadDirection from obstacle for Range(-50, -30),
+ with behavior LeadingCarBehavior(LEAD_CAR_SPEED)
+```
+
+- Place the ego vehicle driving at the predefined speed along the road at a distance of between 15 to 10 meters behind the leading vehicle:
+
+```scenic
+ego = Car following roadDirection from leadCar for Range(-15, -10),
+ with blueprint EGO_MODEL,
+ with behavior EgoBehavior(EGO_SPEED)
+```
+
+- Make it a requirement that the scene takes place more than 80 meters from an intersection:
+
+```scenic
+require (distance to intersection) > 80
+```
+
+__6.__ Set an end point so the script knows when the scene is finished:
+
+The scenario will end when the speed of the ego vehicle goes below 0.1 meters per second and is situated less than 30 meters from the obstacle.
+
+```scenic
+terminate when ego.speed < 0.1 and (distance to obstacle) < 30
+```
+
+---
+
+### Run the scenario
+
+To run the Scenic scenario:
+
+__1.__ Start the CARLA server.
+
+__2.__ Run the following command:
+
+```scenic
+scenic path/to/scenic/script.scenic --simulate
+```
+
+A pygame window will appear and the scenario will play out repeatedly, each time generating a unique scenario within the bounds of the restrictions set in the script. To stop the scenario generation, press `ctrl + C` in the terminal.
+
+---
+
+### Additional parameters
+
+The CARLA model provides several global parameters than can be overridden in scenarios using the [`param` statement](https://scenic-lang.readthedocs.io/en/latest/syntax_details.html#param-identifier-value) or via the command line using the [`--param` option](https://scenic-lang.readthedocs.io/en/latest/options.html#cmdoption-p).
+
+Below is a table of configurable parameters in the CARLA model:
+
+| Name | Value | Description |
+|------|-------|-------------|
+| `carla_map` | `str` | Name of the CARLA map to use (e.g. 'Town01'). If set to ``None``, CARLA will attempt to create a world in the OpenDRIVE standalone mode using the `.xodr` file defined in the [`map`][scenic_map] parameter. |
+| `timestep` | `float` | Timestep to use for simulations (how frequently Scenic interrupts CARLA to run behaviors, check requirements, etc.) in seconds. Default is 0.1 seconds. |
+| `weather` | `str` or `dict` | Weather to use for the simulation. Can be either a string identifying one of the CARLA weather presets (e.g. 'ClearSunset') or a dictionary specifying all the [weather parameters](python_api.md#carla.WeatherParameters)). Default is a uniform distribution over all the weather presets. |
+| `address` | `str` | IP address to connect to CARLA. Default is localhost (127.0.0.1).|
+| `port` | `int` | Port to connect to CARLA. Default is 2000. |
+| `timeout` | `float` | Maximum time in seconds to wait when attempting to connect to CARLA. Default is 10.|
+| `render` | `int` | Whether or not to have CARLA create a window showing the simulations from the point of view of the ego object: `1` for yes, `0` for no. Default `1`. |
+| `record` | `str` | If nonempty, folder in which to save CARLA record files for replaying simulations. |
+
+
diff --git a/Docs/tuto_M_add_map_alternative.md b/Docs/tuto_M_add_map_alternative.md
new file mode 100644
index 000000000..64faa7fd9
--- /dev/null
+++ b/Docs/tuto_M_add_map_alternative.md
@@ -0,0 +1,171 @@
+# Alternative methods to import maps
+
+This guide describes alternative methods to import maps into CARLA. These methods involve more manual steps than the processes described in the [package](tuto_M_add_map_package.md) and [source](tuto_M_add_map_source.md) import guides. First we will describe the RoadRuner plugin and then the manual import method.
+
+- [__RoadRunner plugin import__](#roadrunner-plugin-import)
+- [__Manual import__](#manual-import)
+
+---
+
+## RoadRunner plugin import
+
+The RoadRunner software from MathWorks provides plugins for Unreal Engine to help ease the import process of maps into CARLA.
+
+#### Plugin installation
+
+__1.__ The plugins are available for download from the [MathWorks website](https://www.mathworks.com/help/roadrunner/ug/Downloading-Plugins.html). MathWorks also has a [full tutorial](https://www.mathworks.com/help/roadrunner/ug/Exporting-to-CARLA.html), similar to this one, on how to import maps to CARLA using the plugins.
+
+__2.__ Extract the contents of the downloaded folder and move the folders `RoadRunnerImporter`, `RoadRunnerCarlaIntegration` and `RoadRunnerMaterials` to `/Unreal/CarlaUE4/Plugins/`.
+
+__3.__ Rebuild the plugin following the instructions below:
+
+* __On Windows.__
+ * Right-click the `.uproject` file in `/Unreal/CarlaUE4` and select `Generate Visual Studio project files`.
+ * In the root folder of CARLA, run the command:
+
+```sh
+make launch
+```
+
+* __On Linux.__
+ * Run the following command:
+```sh
+UE4_ROOT/GenerateProjectFiles.sh -project="carla/Unreal/CarlaUE4/CarlaUE4.uproject" -game -engine
+```
+
+__4.__ In the Unreal Engine window, make sure the checkbox is selected for both plugins `Edit > Plugins`.
+
+![rr_ue_plugins](../img/rr-ue4_plugins.jpg)
+
+### Import map
+
+__1.__ Import the `.fbx` file to a new folder under `/Content/Carla/Maps` with the `Import` button.
+
+![ue_import](../img/ue_import_mapname.jpg)
+
+__2.__ Set `Scene > Hierarchy Type` to _Create One Blueprint Asset_ (selected by default).
+__3.__ Set `Static Meshes > Normal Import Method` to _Import Normals_.
+
+![ue_import_options](../img/ue_import_options.jpg)
+
+__4.__ Click `Import`.
+__5.__ Save the current level `File` -> `Save Current As...` -> ``.
+
+The new map should now appear next to the others in the Unreal Engine _Content Browser_.
+
+![ue_level_content](../img/ue_level_content.jpg)
+
+
+!!! Note
+ The tags for semantic segmentation will be assigned according to the name of the asset. The asset will be moved to the corresponding folder in `Content/Carla/PackageName/Static`. To change these, move them manually after importing.
+
+---
+
+## Manual import
+
+This method of importing maps can be used with generic `.fbx` and `.xodr` files. If you are using RoadRunner, you should use the export method `Firebox (.fbx)`, `OpenDRIVE (.xodr)` or `Unreal (.fbx + .xml)`. Do not use the `Carla Exporter` option because you will run into compatibility issues with the `.fbx` file.
+
+To import a map manually to Unreal Engine:
+
+__1.__ In your system's file explorer, copy the `.xodr` file to `/Unreal/CarlaUE4/Content/Carla/Maps/OpenDrive`.
+
+__2.__ Open the Unreal Engine editor by running `make launch` in the carla root directory. In the _Content Browser_ of the editor, navigate to `Content/Carla/Maps/BaseMap` and duplicate the `BaseMap`. This will provide a blank map with the default sky and lighting objects.
+
+>>![ue_duplicate_basemap](../img/ue_duplicate_basemap.png)
+
+__3.__ Create a new folder with the name of your map package in the `Content/Carla/Maps` directory and save the duplicated map there with the same name as your `.fbx` and `.xodr` files.
+
+__4.__ In the _Content Browser_ of the Unreal Engine editor, navigate back to `Content/Carla/Maps`. Right click in the grey area and select `Import to /Game/Carla/Maps...` under the heading _Import Asset_.
+
+>>![ue_import_asset](../img/ue_import_asset.png)
+
+__5.__ In the configuration window that pops up, make sure:
+
+>- These options are unchecked:
+ * Auto Generate Collision
+ * Combine Meshes
+ * Force Front xAxis
+- In the following drop downs, the corresponding options are selected:
+ * Normal Import Method - _Import Normals_
+ * Material Import Method - _Create New Materials_
+- These options are checked:
+ * Convert Scene Unit
+ * Import Textures
+
+>>![ue_import_file](../img/ue_import_file.jpg)
+
+__6.__ Click `Import`.
+
+__7.__ The meshes will appear in the _Content Browser_. Select the meshes and drag them into the scene.
+
+>>![ue_meshes](../img/ue_drag_meshes.jpg)
+
+__8.__ Center the meshes at 0,0,0.
+
+>>![Transform_Map](../img/transform.jpg)
+
+__9.__ In the _Content Browser_, select all the meshes that need to have colliders. This refers to any meshes that will interact with pedestrians or vehicles. The colliders prevent them from falling into the abyss. Right-click the selected meshes and select `Asset Actions > Bulk Edit via Property Matrix...`.
+
+>>![ue_selectmesh_collision](../img/ue_selectmesh_collision.jpg)
+
+__10.__ Search for _collision_ in the search box.
+
+__11.__ Change `Collision Complexity` from `Project Default` to `Use Complex Collision As Simple` and close the window.
+
+>>![ue_collision_complexity](../img/ue_collision_complexity.jpg)
+
+__12.__ Confirm the collision setting has been applied correctly by pressing `Alt + c`. You will see a black web over the meshes.
+
+__13.__ To create the ground truth for the semantic segmentation sensor, move the static meshes to the corresponding `Carla/Static/` folder following the structure below:
+
+ Content
+ └── Carla
+ ├── Blueprints
+ ├── Config
+ ├── Exported Maps
+ ├── HDMaps
+ ├── Maps
+ └── Static
+ ├── Terrain
+ │ └── mapname
+ │ └── Static Meshes
+ │
+ ├── Road
+ │ └── mapname
+ │ └── Static Meshes
+ │
+ ├── RoadLines
+ | └── mapname
+ | └── Static Meshes
+ └── Sidewalks
+ └── mapname
+ └── Static Meshes
+
+__14.__ In the _Modes_ panel, search for the __Open Drive Actor__ and drag it into the scene.
+
+>>![ue_opendrive_actor](../img/ue_opendrive_actor.jpg)
+
+__15.__ In the _Details_ panel, check `Add Spawners` and then click on the box beside `Generate Routes`. This will find the `.xodr` file with the same map name in the `/Unreal/CarlaUE4/Content/Carla/Maps/OpenDrive` directory and use it to generate a series of _RoutePlanner_ and _VehicleSpawnPoint_ actors.
+
+>>![ue_generate_routes](../img/ue_generate_routes.png)
+
+---
+
+## Next steps
+
+You will now be able to open your map in the Unreal Editor and run simulations. From here, you will be able to customize the map and generate the pedestrian navigation data. We recommend generating the pedestrian navigation after all customization has finished, so there is no chance of obstacles blocking the pedestrian paths.
+
+CARLA provides several tools and guides to help with the customization of your maps:
+
+- [Implement sub-levels in your map.](tuto_M_custom_layers.md)
+- [Add and configure traffic lights and signs.](tuto_M_custom_add_tl.md)
+- [Add buildings with the procedural building tool.](tuto_M_custom_buildings.md)
+- [Customize the road with the road painter tool.](tuto_M_custom_road_painter.md)
+- [Customize the weather](tuto_M_custom_weather_landscape.md#weather-customization)
+- [Customize the landscape with serial meshes.](tuto_M_custom_weather_landscape.md#add-serial-meshes)
+
+Once you have finished with the customization, you can [generate the pedestrian navigation information](tuto_M_generate_pedestrian_navigation.md).
+
+---
+
+It is recommended to use the automated processes for importing maps detailed in the guides for [CARLA packages](tuto_M_add_map_package.md) and [CARLA source build](tuto_M_add_map_source.md), however the methods listed in this section can be used if required. If you encounter any issues with the alternative methods, feel free to post in the [forum](https://github.com/carla-simulator/carla/discussions).
diff --git a/Docs/tuto_M_add_map_package.md b/Docs/tuto_M_add_map_package.md
new file mode 100644
index 000000000..fcffa07b2
--- /dev/null
+++ b/Docs/tuto_M_add_map_package.md
@@ -0,0 +1,76 @@
+# Ingesting Maps in a CARLA package
+
+This section describes the process of ingesting maps into __a package (binary) version of CARLA__. If you are using a version of CARLA that has been built from source to ingest maps then follow the guidelines [here][source_ingest] instead.
+
+This process is only available for Linux systems. The import process involves running a Docker image of Unreal Engine to import the relevant files and then export them as a standalone package which can then be configured to be used in CARLA. The Docker image takes around 4h and 600-700 GB to be built. This is only needed the first time the image is built.
+
+- [__Before you begin__](#before-you-begin)
+- [__Map ingestion in a CARLA package__](#map-ingestion-in-a-carla-package)
+
+---
+
+## Before you begin
+
+- You will need to fulfill the following system requirements:
+ - 64-bit version of [Docker](https://docs.docker.com/engine/install/) in Ubuntu 16.04+
+ - Minimum 8GB of RAM
+ - Minimum 700 GB available disk space for building container images
+ - [Git](https://git-scm.com/downloads) version control
+- Ensure you are using a package (binary) version of CARLA. If you are using a version of CARLA that has been built from source to ingest maps then follow the guidelines [here][source_ingest] instead.
+- You should have at least two files, `.xodr` and `.fbx` that have been [generated][rr_generate_map] from a map editor such as RoadRunner.
+- These files should have the same value for `` in order to be recognised as the same map.
+
+
+[source_ingest]: tuto_M_add_map_source.md
+[import_map_package]: tuto_M_add_map_package.md
+[rr_generate_map]: tuto_M_generate_map.md
+
+---
+## Map ingestion in a CARLA package
+
+__1.__ CARLA provides all the utilities to build Unreal Engine in a Docker image and to compile CARLA using that image. The tools are found in the source code available in GitHub. Clone the repository using the following command:
+
+```sh
+ git clone https://github.com/carla-simulator/carla
+```
+
+__2.__ Build the Docker image of Unreal Engine by following [these instructions](https://github.com/carla-simulator/carla/tree/master/Util/Docker).
+
+__3.__ Create an `input_folder`. This is where you will put the files to be imported. Docker will automatically create a `.json` file describing the package folder structure. Change permissions on the `input_folder` for this to be created successfully:
+
+```sh
+ #Go to the parent folder, where the input folder is contained
+ chmod 777 input_folder
+```
+
+> !!! Note
+ This is not necessary if the package is [prepared manually](tuto_M_manual_map_package.md), and contains a `.json` file already.
+
+__4.__ Create an `output_folder`. This is where the Docker image will write the output files after it has cooked the map.
+
+__5.__ Navigate to `~/carla/Util/Docker`. This is where the ingestion script is located. The script requires the path for the `input_folder` and `output_folder` and the name of the package to be ingested. If a `.json` file is provided, the name of that file is the package name, if no `.json` is provided, the name must be `map_package`:
+
+```sh
+ python3 docker_tools.py --input ~/path_to_input_folder --output ~/path_to_output_folder --packages map_package
+```
+
+> !!! Warning
+ If the argument `--packages map_package` is not provided, the Docker image will make a package of CARLA.
+
+__6.__ The package will be generated in the `output_folder` as `.tar.gz`. This is the standalone package that is now ready to be imported into CARLA. Move the package to the `Import` folder in the CARLA root directory (of the package/binary version where you will be using the map), and run the following script from the root directory to import it:
+
+```sh
+ ./ImportAssets.sh
+```
+
+__7.__ To run a simulation with the new map, run CARLA and then change the map using the `config.py` file:
+
+```sh
+ cd PythonAPI/util
+ python3 config.py --map
+```
+
+
+---
+
+Your map is now ready to run simulations in CARLA. If you have any questions about the process then you can ask in the [forum](https://github.com/carla-simulator/carla/discussions) or you can try running some of our [example scripts](https://github.com/carla-simulator/carla/tree/master/PythonAPI/examples) on your new map to test it out.
\ No newline at end of file
diff --git a/Docs/tuto_M_add_map_source.md b/Docs/tuto_M_add_map_source.md
new file mode 100644
index 000000000..768b553d0
--- /dev/null
+++ b/Docs/tuto_M_add_map_source.md
@@ -0,0 +1,71 @@
+# Ingesting Maps in CARLA Built From Source
+
+This section describes the process of ingesting maps into __CARLA that has been built from source__. If you are using a package (binary) version of CARLA to ingest maps then follow the guidelines [here][package_ingest] instead.
+
+The ingestion process involves importing the relevant map files by compiling them into a package. This package can then be opened in the Unreal Engine editor and customized before generating the pedestrian navigation file and finally adding it to the package.
+
+[package_ingest]: tuto_M_add_map_package.md
+
+- [__Before you begin__](#before-you-begin)
+- [__Map ingestion__](#map-ingestion)
+- [__Next steps__](#next-steps)
+
+---
+
+## Before you begin
+
+- Ensure you are using a version of CARLA that has been built from source. If you are using a packaged (binary) version of CARLA then follow the tutorial [here][import_map_package].
+- You should have at least two files, `.xodr` and `.fbx` that have been [generated][rr_generate_map] from a map editor such as RoadRunner.
+- These files should have the same value for `` in order to be recognised as the same map.
+- You can ingest multiple maps into the same package. Each map should have a unique name.
+
+[import_map_package]: tuto_M_add_map_package.md
+[rr_generate_map]: tuto_M_generate_map.md
+
+---
+## Map ingestion
+
+__1.__ Place the map files to be imported in the `Import` folder found in the CARLA root directory.
+
+__2.__ Run the command below to ingest the files:
+
+```sh
+make import
+```
+
+__Note that there are two optional parameter flags that can be set__:
+
+- `--package=` specifies the name of the package. By default, this is set to `map_package`. Two packages cannot have the same name, so using the default value will lead to errors on a subsequent ingestion. __It is highly recommended to change the name of the package__. Use this flag by running the command:
+
+```sh
+make import ARGS="--package="
+```
+
+- `--no-carla-materials` specifies that you do not want to use the default CARLA materials (road textures etc). You will use the RoadRunner materials instead. This flag is __only required if you are not__ providing your own [`.json` file](tuto_M_manual_map_package.md). Any value in the `.json` file will override this flag. Use this flag by running the command:
+
+```sh
+make import ARGS="--no-carla-materials"
+```
+
+A folder will be created in `Unreal/CarlaUE4/Content` with the name of your map package. It will contain config files, overdrive information, static asset information and navigation information.
+
+---
+
+## Next steps
+
+You will now be able to open your map in the Unreal Editor and run simulations. From here, you will be able to customize the map and generate the pedestrian navigation data. We recommend generating the pedestrian navigation after all customization has finished, so there is no chance of obstacles blocking the pedestrian paths.
+
+CARLA provides several tools and guides to help with the customization of your maps:
+
+- [Implement sub-levels in your map.](tuto_M_custom_layers.md)
+- [Add and configure traffic lights and signs.](tuto_M_custom_add_tl.md)
+- [Add buildings with the procedural building tool.](tuto_M_custom_buildings.md)
+- [Customize the road with the road painter tool.](tuto_M_custom_road_painter.md)
+- [Customize the weather](tuto_M_custom_weather_landscape.md#weather-customization)
+- [Customize the landscape with serial meshes.](tuto_M_custom_weather_landscape.md#add-serial-meshes)
+
+Once you have finished with the customization, you can [generate the pedestrian navigation information](tuto_M_generate_pedestrian_navigation.md).
+
+---
+
+If you have any questions about the process, then you can ask in the [forum](https://github.com/carla-simulator/carla/discussions).
\ No newline at end of file
diff --git a/Docs/tuto_M_custom_add_tl.md b/Docs/tuto_M_custom_add_tl.md
new file mode 100644
index 000000000..aa61faae1
--- /dev/null
+++ b/Docs/tuto_M_custom_add_tl.md
@@ -0,0 +1,63 @@
+# Customizing maps: Traffic Lights and Signs
+
+This guide explains how to add traffic lights and signs to your custom map, configure the area of influence of each one, and how to configure traffic lights as a group at junctions. This option is only available to users who have access to the Unreal Engine editor.
+
+- [__Traffic Lights__](#traffic-lights)
+- [__Traffic signs__](#traffic-signs)
+- [__Next steps__](#next-steps)
+
+---
+
+## Traffic lights
+
+To add traffic lights to your new map:
+
+__1.__ From the _Content Browser_, navigate to `Content/Carla/Static/TrafficLight/StreetLights_01`. You will find several different traffic light blueprints to choose from.
+
+__2.__ Drag the traffic lights into the scene and position them in the desired location. Press the space bar on your keyboard to toggle between positioning, rotation, and scaling tools.
+
+__3.__ Adjust the [`trigger volume`][triggerlink] for each traffic light by selecting the _BoxTrigger_ component in the _Details_ panel and adjusting the values in the _Transform_ section. This will determine the traffic light's area of influence.
+
+>>![ue_trafficlight](../img/ue_trafficlight.jpg)
+
+__4.__ For junctions, drag the `BP_TrafficLightGroup` actor into the level. Assign all the traffic lights in the junction to the traffic light group by adding them to the _Traffic Lights_ array in the _Details_ panel.
+
+>>![ue_tl_group](../img/ue_tl_group.jpg)
+
+__5.__ Traffic light timing is only configurable through the Python API. See the documentation [here](core_actors.md#traffic-signs-and-traffic-lights) for more information.
+
+>>![ue_tlsigns_example](../img/ue_tlsigns_example.jpg)
+
+> _Example: Traffic Signs, Traffic lights and Turn based stop._
+
+[triggerlink]: python_api.md#carla.TrafficSign.trigger_volume
+
+---
+
+## Traffic signs
+
+To add traffic lights to your new map:
+
+__1.__ From the _Content Browser_, navigate to `Content/Carla/Static/TrafficSign`. You will find several different traffic light blueprints to choose from.
+
+__2.__ Drag the traffic lights into the scene and position them in the desired location. Press the space bar on your keyboard to toggle between positioning, rotation, and scaling tools.
+
+__3.__ Adjust the [`trigger volume`][triggerlink] for each traffic sign by selecting the _BoxTrigger_ component in the _Details_ panel and adjusting the values in the _Transform_ section. This will determine the traffic light's area of influence. Not all traffic signs have a trigger volume. Those that do, include the yield, stop and speed limit signs.
+
+---
+
+## Next steps
+
+Continue customizing your map using the tools and guides below:
+
+- [Implement sub-levels in your map.](tuto_M_custom_layers.md)
+- [Add buildings with the procedural building tool.](tuto_M_custom_buildings.md)
+- [Customize the road with the road painter tool.](tuto_M_custom_road_painter.md)
+- [Customize the weather](tuto_M_custom_weather_landscape.md#weather-customization)
+- [Customize the landscape with serial meshes.](tuto_M_custom_weather_landscape.md#add-serial-meshes)
+
+Once you have finished with the customization, you can [generate the pedestrian navigation information](tuto_M_generate_pedestrian_navigation.md).
+
+---
+
+If you have any questions about the process then you can ask in the [forum](https://github.com/carla-simulator/carla/discussions).
diff --git a/Docs/tuto_M_custom_buildings.md b/Docs/tuto_M_custom_buildings.md
new file mode 100644
index 000000000..4a9ed0f5c
--- /dev/null
+++ b/Docs/tuto_M_custom_buildings.md
@@ -0,0 +1,78 @@
+# Customizing Maps: Procedural Buildings
+
+- [__Procedural buildings__](#add-serial-meshes)
+ - [Building structure](#building-structure)
+ - [Structure modifications](#structure-modifications)
+- [__Next steps__](#next-steps)
+
+---
+
+## Procedural buildings
+
+The procedural building tool allows you to create rectangular buildings composed of different levels. Each level is built using a configurable array of meshes or a single blueprint. If an array of meshes is used, each mesh will be repeated along the level at random to provide variety. The meshes are created once and each repition will be an instance of that mesh. This improves performance of your map.
+
+### Building structure
+
+To get started on your building:
+
+1. In the _Content Browser_ of the Unreal Engine editor, navigate to `Content/Carla/Blueprints/LevelDesign`.
+2. Drag the `BP_Procedural_Building` into the scene.
+
+In the _Details_ panel, you will see all the options available to customize your building. Every time a change is made here, the building will disappear from the scene view, as the key meshes are updated. Click on _Create Building_ to see the new result, or enable _Create automatically_ to avoid having to repeat this step.
+
+The key meshes are pieces of the building's structure. They fall into four categories:
+
+- __Base:__ The ground floor.
+- __Body:__ The middle floors.
+- __Top:__ The highest floor.
+- __Roof:__ The roof that covers the top floor.
+
+For each of them, except the __Roof__, there is a mesh to fill the center of the floor, and a __Corner__ mesh that will be placed on the sides of the floor. The following picture represents the global structure.
+
+![bp_procedural_building_visual](../img/map_customization/BP_Procedural_Building_Visual.jpg)
+
Visualization of the building structure.
+
+The __Base parameters__ set the dimensions.
+
+- __Num Floors:__ Floors of the building. Repetitions of the __Body__ meshes.
+- __Length X and Length Y:__ Length and breadth of the building. Repetitions of the central meshes for each side of the building.
+
+![bp_procedural_building_full](../img/map_customization/BP_Procedural_Building_Full.jpg)
+
Example of BP_Procedural_Building.
+
+### Structure modifications
+
+There are some additional options to modify the general structure of the building.
+
+- __Disable corners:__ If selected, no corner meshes will be used.
+- __Use full blocks:__ If selected, the structure of the building will use only one mesh per floor. No corners nor repetitions will appear in each floor.
+- __Doors:__ Meshes that appear in the ground floor, right in front of the central meshes. The amount of doors and their location can be set. `0` is the initial position, `1` the next base repetition, and so on.
+- __Walls:__ Meshes that substitute one or more sides of the building. For example, a plane mesh can be used to paint one side of the building.
+
+![bp_procedural_building_extras](../img/map_customization/BP_Procedural_Building_Extras.jpg)
+
On the left, a building with no cornes and one door. On the right, a building with a wall applied to one side of the building. The wall is a texture with no fire escape.
+
+---
+
+## Next steps
+
+Continue customizing your map using the tools and guides below:
+
+- [Implement sub-levels in your map.](tuto_M_custom_layers.md)
+- [Add and configure traffic lights and signs.](tuto_M_custom_add_tl.md)
+- [Customize the road with the road painter tool.](tuto_M_custom_road_painter.md)
+- [Customize the weather](tuto_M_custom_weather_landscape.md#weather-customization)
+- [Customize the landscape with serial meshes.](tuto_M_custom_weather_landscape.md#add-serial-meshes)
+
+Once you have finished with the customization, you can [generate the pedestrian navigation information](tuto_M_generate_pedestrian_navigation.md).
+
+---
+
+If you have any questions about the process, then you can ask in the [forum](https://github.com/carla-simulator/carla/discussions).
+
+
diff --git a/Docs/tuto_M_custom_layers.md b/Docs/tuto_M_custom_layers.md
new file mode 100644
index 000000000..bb8c15965
--- /dev/null
+++ b/Docs/tuto_M_custom_layers.md
@@ -0,0 +1,89 @@
+# Customizing Maps: Layered Maps
+
+Utilizing levels in your custom map enables multiple people to work on a single map concurrently. It also allows you to use the Python API to load and unload layers on your map during a simulation, just like the [layered CARLA maps](core_map.md#layered-maps).
+
+This guide will explain how to add a new level, how to add assets to a level, and how to configure a level to be always loaded or not.
+
+- [__Add a new level__](#add-a-new-level)
+- [__Add assets to a level__](#add-assets-to-a-level)
+- [__Configure level loading options__](#configure-level-loading-options)
+- [__Next steps__](#next-steps)
+
+---
+
+## Add a new level
+
+All new levels in your map will be nested within the parent level, known as the _Persistent Level_. To create a new level:
+
+__1. Open the levels panel.__
+
+1. In the Unreal Engine editor, open _Window_ from the menu bar.
+2. Click on _Levels_.
+
+__2. Create a new level.__
+
+1. In the _Levels_ panel, click on _Levels_ and select _Create New..._.
+2. Choose _Empty Level_.
+3. Save the level in `Content/Carla/Maps/Sublevels//`. To integrate the level with the CARLA Python API, use the naming convention `_`, e.g., `TutorialMap_Buildings`. For a list of available layers, check [here](core_map.md#carla-maps).
+
+>>>>>>![create new level](../img/new_level.png)
+
+---
+
+## Add assets to a level
+
+__1. Select the level to which you want to add assets__.
+
+In the _Levels_ panel, double-click the level to which you would like to add assets. Make sure the level is unlocked by toggling the lock icon.
+
+__2. Select the assets to add.__
+
+1. Select all the assets you would like to add to the level.
+2. Right-click and go to _Level_.
+3. Click on _Move Selection to Current Level_.
+
+__3. Save the level.__
+
+If a level has pending changes to save, you will see a pencil icon next to it in the _Levels_ panel. Click this to save the changes.
+
+![moving assets](../img/move_assets.png)
+
+---
+
+## Configure level loading options
+
+Levels can be configured to be able to be toggled or to be always loaded. To configure the level for either option:
+
+1. Right-click the level in the _Levels_ panel and go to _Change Streaming Method_.
+2. Choose the desired setting:
+ 1. _Always Loaded_: The level __will not be able__ to be toggled via the Python API.
+ 2. _Blueprint_: The level __will be able__ to be toggled via the Python API. A blue dot will appear beside the level name.
+
+Regardless of the setting, you will still be able to toggle the level in the editor by pressing the eye icon.
+
+>>>>>>![levels](../img/levels.png)
+
+---
+
+## Next steps
+
+Continue customizing your map using the tools and guides below:
+
+- [Add and configure traffic lights and signs.](tuto_M_custom_add_tl.md)
+- [Add buildings with the procedural building tool.](tuto_M_custom_buildings.md)
+- [Customize the road with the road painter tool.](tuto_M_custom_road_painter.md)
+- [Customize the weather](tuto_M_custom_weather_landscape.md#weather-customization)
+- [Customize the landscape with serial meshes.](tuto_M_custom_weather_landscape.md#add-serial-meshes)
+
+Once you have finished with the customization, you can [generate the pedestrian navigation information](tuto_M_generate_pedestrian_navigation.md).
+
+---
+
+If you have any questions about the process, then you can ask in the [forum](https://github.com/carla-simulator/carla/discussions).
+
+
diff --git a/Docs/tuto_M_custom_map_overview.md b/Docs/tuto_M_custom_map_overview.md
new file mode 100644
index 000000000..624b2935b
--- /dev/null
+++ b/Docs/tuto_M_custom_map_overview.md
@@ -0,0 +1,80 @@
+# Add a new map
+
+Users of CARLA can create custom maps and use them to run simulations. There are several ways to import custom maps in CARLA. The method to be used will depend on whether you are using a packaged version of CARLA or a version built from source. This section gives an overview of what you need to start the process, the different options available to import, and customization and pedestrian navigation tools available.
+
+- [__Overview__](#overview)
+- [__Generation__](#generation)
+- [__Importation__](#importation)
+- [__Customization__](#customization)
+- [__Generate pedestrian navigation__](#generate-pedestrian-navigation)
+
+---
+
+## Overview
+
+Using custom maps in CARLA involves four main processes:
+
+1. Generation
+2. Importation
+3. Customization
+4. Pedestrian Navigation
+
+Read on further for additional general information on each process.
+
+---
+
+## Generation
+
+CARLA requires map geometry information in `.fbx` format and OpenDRIVE information in `.xodr` format. The current recommended software to generate these files is RoadRunner.
+
+__[This guide](tuto_M_generate_map.md) explains how to use RoadRunner to generate the map information.__
+
+---
+
+## Importation
+
+There are several ways to import your map into CARLA.
+
+If you are using a __package version__ of CARLA, you will import your map using Docker. This option is only available in Linux, and you will not have the ability to customize the map using the Unreal Editor. __You will find the guide [here](tuto_M_add_map_package.md).__
+
+If you are using a __source build__ version of CARLA, there are three methods available to import your map:
+
+1. Using the automatic `make import` process (recommended). __You will find the guide [here](tuto_M_add_map_source.md).__
+2. Using the RoadRunner plugin. __You will find the guide [here](tuto_M_add_map_alternative.md#roadrunner-plugin-import).__
+3. Manually importing the map into Unreal Engine. __You will find the guide [here](tuto_M_add_map_alternative.md#manual-import).__
+
+The following video explains some of the methods available to import maps into CARLA:
+
+
+
+
+
+---
+
+## Customization
+
+As well as hundreds of static meshes ready to be added to the landscape, CARLA provides several tools and guides to help you customize your map:
+
+- __Add sub-levels:__ Sub-levels will allow multiple people to work on the same map at the same time. They will also allow you to toggle layers of your map with the Python API, just like the CARLA layered maps. __You will find the guide [here](tuto_M_custom_layers.md).__
+- __Set default weather:__ Experiment with different weather presets, and when you find the right combination, set the default weather for your map. __You will find the guide [here](tuto_M_custom_weather_landscape.md#weather-customization).__
+- __Populate landscape:__ Use blueprints to populate the landscape with repeating meshes such as street lights, power lines, and walls. __You will find the guide [here](tuto_M_custom_weather_landscape.md#add-serial-meshes).__
+- __Paint the roads:__ Paint the roads with a master material that blends different textures. Add decals and meshes such as fallen leaves, cracks, or manholes. __You will find the guide [here](tuto_M_custom_road_painter.md).__
+- __Add procedural buildings:__ Add buildings with a custom size, amount of floors, and variable mesh combinations using the procedural building blueprint. __You will find the guide [here](tuto_M_custom_buildings.md).__
+- __Add traffic lights and signs:__ Add traffic lights and signs and configure their area of influence. Group traffic lights at junctions. __You will find the guide [here](tuto_M_custom_add_tl.md).__
+
+---
+
+## Generate pedestrian navigation
+
+For pedestrians to be spawned and navigate the map, you need to generate the pedestrian navigation information using the tool provided by CARLA. Pedestrian navigation should be generated after you complete the customization of your map so that obstacles are not created over the top of navigation paths. __You can find the guide [here](tuto_M_generate_pedestrian_navigation.md).__
+
+---
+
+If you have any questions about the above process, feel free to post these in the [forum](https://github.com/carla-simulator/carla/discussions).
+
+
\ No newline at end of file
diff --git a/Docs/tuto_M_custom_road_painter.md b/Docs/tuto_M_custom_road_painter.md
new file mode 100644
index 000000000..5e45d7765
--- /dev/null
+++ b/Docs/tuto_M_custom_road_painter.md
@@ -0,0 +1,240 @@
+# Customizing Maps: Road Painter
+
+This guide explains what the road painter tool is, how to use it to customize the appearance of the road by combining different textures, how to add decals and meshes and how to update the appearance of lane markings according to the road texture.
+
+- [__What is the road painter?__](#what-is-the-road-painter)
+- [__Before you begin__](#before-you-begin)
+- [__Establish the road painter, master material and render target__](#establish-the-road-painter-master-material-and-render-target)
+- [__Prepare the master material__](#prepare-the-master-material)
+- [__Paint the road__](#paint-the-road)
+- [__Update the appearance of lane markings__](#update-the-appearance-of-lane-markings)
+- [__Next steps__](#next-steps)
+
+---
+
+## What is the road painter?
+
+The Road Painter tool is a blueprint that uses OpenDRIVE information to paint roads quickly. It takes a master material and applies it to a render target of the road to use as a canvas. The master material is made up of a collection of materials that can be blended using brushes and applied as masks. There is no need to apply photometry techniques nor consider the UVs of the geometry.
+
+---
+
+## Before you begin
+
+The road painter uses the OpenDRIVE information to paint the roads. Make sure that your `.xodr` file has the same name as your map for this to work correctly.
+
+---
+
+## Establish the road painter, master material and render target
+
+__1. Create the `RoadPainter` actor.__
+
+1. In the _Content Browser_, navigate to `Content/Carla/Blueprints/LevelDesign`.
+2. Drag the `RoadPainter` into the scene.
+
+__2. Create the Render Target.__
+
+1. In the _Content Browser_, navigate to `Content/Carla/Blueprints/LevelDesign/RoadPainterAssets`.
+2. Right-click on the `RenderTarget` file and select `Duplicate`.
+3. Rename to `Tutorial_RenderTarget`.
+
+__3. Create the master material instance.__
+
+1. In the _Content Browser_, navigate to `Game/Carla/Static/GenericMaterials/RoadPainterMaterials`.
+2. Right-click on `M_RoadMaster` and select _Create Material Instance_.
+3. Rename to `Tutorial_RoadMaster`.
+
+__4. Re-calibrate the _Map Size (Cm)_ so that it is equal to the actual size of the map.__
+
+1. Select the `RoadPainter` actor in the scene.
+2. Go to the _Details_ panel and press the _Z-Size_ button. You will see the value in _Map Size (Cm)_ change.
+
+>>>>>![map size](../img/map_size.png)
+
+__5. Synchronize the map size between the `RoadPainter` and `Tutorial_RoadMaster`.__
+
+1. In the _Content Browser_, open `Tutorial_RoadMaster`.
+2. Copy the value _Map Size (Cm)_ from the previous step and paste it to _Global Scalar Parameter Values -> Map units (CM)_ in the `Tutorial_RoadMaster` window.
+3. Press save.
+
+>>>>>>![img](../img/map_size_sync.png)
+
+__6. Create the communication link between the road painter and the master material.__
+
+The `Tutorial_RenderTarget` will be the communication link between the road painter and `Tutorial_RoadMaster`.
+
+1. In the `Tutorial_RoadMaster` window, apply the `Tutorial_RenderTarget` to _Global Texture Parameter Values -> Texture Mask_.
+2. Save and close.
+3. In the main editor window, select the road painter actor, go to the _Details_ panel and apply the `Tutorial_RenderTarget` to _Paint -> Render Target_.
+
+---
+
+## Prepare the master material
+
+The `Tutorial_RoadMaster` material you created holds the base material, extra material information, and parameters that will be applied via your `Tutorial_RenderTarget`. You can configure one base material and up to three additional materials.
+
+>>![master materials](../img/master_material.png)
+
+To configure the materials, double-click the `Tutorial_RoadMaster` file. In the window that appears, you can select and adjust the following values for each material according to your needs:
+
+- Brightness
+- Hue
+- Saturation
+- AO Intensity
+- NormalMap Intensity
+- Roughness Contrast
+- Roughness Intensity
+
+You can change the textures for each material by selecting the following values and searching for a texture in the search box:
+
+- Diffuse
+- Normal
+- ORMH
+
+Explore some of the CARLA textures available in `Game/Carla/Static/GenericMaterials/Asphalt/Textures`.
+
+---
+
+### Paint the road
+
+__1. Create the link between the road painter and the roads.__
+
+1. In the main editor window, search for `Road_Road` in the _World Outliner_ search box.
+2. Press `Ctrl + A` to select all the roads.
+3. In the _Details_ panel, go to the _Materials_ section and apply `Tutorial_RoadMaster` to _Element 0_, _Element 1_, _Element 2_, and _Element 3_.
+
+__2. Choose the material to customize.__
+
+Each of the materials we added to `Tutorial_RoadMaster` are applied to the roads separately and application is configured with the _Brush_ tool. To apply and customize a material:
+
+1. Select the road painter actor
+2. In the _Details_ panel, select the material to work with in the _Mask Color_ dropdown menu.
+
+>>>>>>![choose material](../img/choose_material.png)
+
+__3. Set the brush and stencil parameters.__
+
+There are a variety of stencils to choose from in `GenericMaterials/RoadStencil/Alphas`. The stencil is used to paint the road according to your needs and can be adjusted using the following values:
+
+- _Stencil size_ — Size of the brush.
+- _Brush strength_ — Roughness of the outline.
+- _Spacebeween Brushes_ — Distance between strokes.
+- _Max Jitter_ — Size variation of the brush between strokes.
+- _Stencil_ — The brush to use.
+- _Rotation_ — Rotation applied to the stroke.
+
+>>>>>>![materials_roadpaint_brushes](../img/material_customization/Materials_Brush.jpg)
+
+
+__4. Apply each material to the desired portions of the road.__
+
+Choose where to apply the selected material via the buttons in the _Default_ section of the _Details_ panel:
+
+* _Paint all roads_ — Paint all the roads.
+* _Paint by actor_ — Paint a specific, selected actor.
+* _Paint over circle_ — Paint using a circular pattern, useful to provide variation.
+* _Paint over square_ — Paint using a square pattern, useful to provide variation.
+
+This section also contains options to erase the applied changes.
+
+* _Clear all_ — Erase all the painted material.
+* _Clear materials_ — Remove the currently active materials.
+* _Clear material by actor_ — Remove the material closest to the selected actor.
+
+>>>>>>![materials_roadpaint_brushes](../img/material_customization/Materials_RoadPainter_Default.jpg)
+
Different painting and erasing options.
+
+__5. Add decals and meshes.__
+
+You can explore the available decals and meshes in `Content/Carla/Static/Decals` and `Content/Carla/Static`. Add them to road painter by extending and adding to the _Decals Spawn_ and _Meshes Spawn_ arrays. For each one you can configure the following parameters:
+
+- _Number of Decals/Meshes_ - The amount of each decal or mesh to paint.
+- _Decal/Mesh Scale_ — Scale of the decal/mesh per axis.
+- _Fixed Decal/Mesh Offset_ — Deviation from the center of the lane per axis.
+- _Random Offset_ — Max deviation from the center of the lane per axis.
+- _Decal/Mesh Random Yaw_ — Max random yaw rotation.
+- _Decal/Mesh Min Scale_ — Minimum random scale applied to the decal/mesh.
+- _Decal/Mesh Max Scale_ — Max random scale applied to the decal/mesh.
+
+>>>>>>![materials_](../img/decals_meshes.png)
+
Decals and Meshes panels.
+
+
+Once you have configured your meshes and decals, spawn them by pressing `Spawn decals` and `Spawn meshes`.
+
+!!! Note
+ Make sure that meshes and decals do not have collisions enabled that can interfere with cars on the road and lower any bounding boxes to the level of the road.
+
+__7. Experiment to get your desired appearance.__
+
+Experiment with different materials, textures, settings, decals, and meshes to get your desired look. Below are some example images of how the appearance of the road changes during the process of painting each material.
+
+![materials_roadpaint_mat00](../img/material_customization/Materials_Road_MaterialBase.jpg)
+
+
+
+---
+
+## Update the appearance of lane markings
+
+After you have painted the roads, you can update the appearance of the road markings by following these steps:
+
+__1. Make a copy of the master material.__
+
+1. In the _Content Browser_, navigate to `Game/Carla/Static/GenericMaterials/RoadPainterMaterials`.
+2. Right-click on `Tutorial_RoadMaster` and select _Create Material Instance_.
+3. Rename to `Tutorial_LaneMarkings`.
+
+__2. Configure the lane marking material.__
+
+1. In the _Content Browser_, double-click on `Tutorial_LaneMarkings`.
+2. In the _Details_ panel, go to the _Global Static Switch Parameter Values_ section and check the boxes on the left and right of _LaneMark_.
+3. Go to the _Texture_ section and check the boxes for _LaneColor_ and _Uv Size_.
+4. Choose your preferred color for the lane markings in _LaneColor_.
+5. _Save_ and close.
+
+__3. Select the road marking meshes.__
+
+Drag the material onto the lane markings you wish to color. Repeat the whole process for different colors of lane markings if required.
+
+---
+
+## Next steps
+
+Continue customizing your map using the tools and guides below:
+
+- [Implement sub-levels in your map.](tuto_M_custom_layers.md)
+- [Add and configure traffic lights and signs.](tuto_M_custom_add_tl.md)
+- [Add buildings with the procedural building tool.](tuto_M_custom_buildings.md)
+- [Customize the weather](tuto_M_custom_weather_landscape.md#weather-customization)
+- [Customize the landscape with serial meshes.](tuto_M_custom_weather_landscape.md#add-serial-meshes)
+
+Once you have finished with the customization, you can [generate the pedestrian navigation information](tuto_M_generate_pedestrian_navigation.md).
+
+---
+
+If you have any questions about the process, then you can ask in the [forum](https://github.com/carla-simulator/carla/discussions).
+
+
diff --git a/Docs/tuto_M_custom_weather_landscape.md b/Docs/tuto_M_custom_weather_landscape.md
new file mode 100644
index 000000000..bbcbde989
--- /dev/null
+++ b/Docs/tuto_M_custom_weather_landscape.md
@@ -0,0 +1,174 @@
+# Customizing maps: Weather and Landscape
+
+CARLA provides several blueprints to help ease the creation of default weather settings for your maps and to populate the lanscape with serial meshes such as street lights, power lines, etc.
+
+This guide will explain where each one of these blueprints are located and how to use and configure them.
+
+- [__Weather customization__](#weather-customization)
+ - [BP_Sky](#bp_sky)
+ - [BP_Weather](#bp_weather)
+- [__Serial meshes__](#add-serial-meshes)
+ - [BP_RepSpline](#bp_repspline)
+ - [BP_Spline](#bp_spline)
+ - [BP_Wall](#bp_wall)
+ - [BP_SplinePoweLine](#bp_splinepoweline)
+- [__Next steps__](#next-steps)
+
+!!! Important
+ This tutorial only applies to users that work with a build from source, and have access to the Unreal Editor.
+
+---
+
+## Weather customization
+
+This section explains how to experiment with different weather parameters before setting your map's default weather, and once you are happy with the settings, how to configure the default weather parameters for your map.
+
+### BP_Sky
+
+The `BP_Sky` blueprint is neccessary to bring light and weather to your map. It can also be used to test different weather configurations before deciding on your default weather parameters.
+
+It is likely the `BP_Sky` blueprint will already be loaded in your map. If not you can add it by dragging it into the scene from `Content/Carla/Blueprints/Weather`.
+
+To try out different weather parameters, go to the _Details_ panel of the `BP_Sky` actor, and play with the values in the _Parameters_ section.
+
+!!! Important
+ If more than one `BP_Sky` blueprint is loaded into the scene, the weather will be duplicated with undesirable results, e.g, having two suns.
+
+### BP_Weather
+
+The default weather for your map is defined in the `BP_Weather` blueprint. This blueprint allows you to set the same parameters as are available through the Python API. These parameters are described [here](https://carla.readthedocs.io/en/latest/python_api/#carlaweatherparameters).
+
+To set the default weather for your map:
+
+__1. Open the `BP_Weather` blueprint.__
+
+In the _Content Browser_, navigate to `Content/Carla/Blueprints/Weather` and double-click on `BP_Weather`.
+
+__2. Add your town.__
+
+In the _Details_ panel of the `BP_Weather` window, go to the _Weather_ section and add your town to the _Default Weathers_ array.
+
+__3. Configure your default weather parameters.__
+
+For each weather parameter, set your desired value. When you are finished, press _Compile_ then _Save_ and close.
+
+>>>>>![bp_weather_pic](../img/map_customization/BP_Weather.jpg)
+
+Array containing default weather parameters for every CARLA map. Town01 opened.
+
+
+---
+
+## Add serial meshes
+
+There are four blueprints available to add props aligned in one direction, e.g., walls, powerlines, street lights. These blueprints use a series of meshes distributed along a Bezier curve. Each one is initialized in the same way:
+
+__1. Initialize the series.__
+
+Drag the blueprint into the scene. You will see one element standing at the starting point of a Bezier curve with two nodes marking the beginning and ending.
+
+__2. Define the path.__
+
+Select the direction arrow of the element and press __Alt__ while dragging the element in the direction you want to go. This will create a new element which can be used to define the curve. As you drag, a new mesh will appear either on every node of the curve or every time you press `Alt` while dragging, depending on the blueprint.
+
+__3. Customize the pattern.__
+
+The following sections will describe the different customization parameters available to each blueprint.
+
+### BP_RepSpline
+
+The `BP_RepSpline` blueprint is found in `Carla/Blueprints/LevelDesign`. It is used to add __individual__ elements along a path defined by a Bezier curve.
+
+The serialization is customized via the following values:
+
+- _Distance between_ — Set the distance between elements.
+- _Offset rotation_ — Set a fixed rotation for the different axis.
+- _Random rotation_ — Set a range of random rotations for the different axis.
+- _Offset translation_ — Set a range of random locations along the different axis.
+- _Max Number of Meshes_ — Set the maximum amount of elements that will be place between nodes of the curve.
+- _World aligned ZY_ — If selected, the elements will be vertically aligned regarding the world axis.
+- _EndPoint_ — If selected, an element will be added at the end node of the curve.
+- _Collision enabled_ — Set the type of collisions enabled for the meshes.
+
+![bp_repspline_pic](../img/map_customization/BP_Repspline.jpg)
+
BP_RepSpline example.
+
+### BP_Spline
+
+The `BP_Spline` blueprint is found in `Carla/Blueprints/LevelDesign`. It adds __connected__ elements that __strictly__ follow a path defined by a Bezier curve. The mesh will be warped to fit the path created.
+
+The blueprint can be customized using the following value:
+
+- _Gap distance_ — Add a separation between elements.
+
+![bp_spline_pic](../img/map_customization/BP_Spline.jpg)
+
BP_Spline example.
+
+### BP_Wall
+
+The `BP_Wall` blueprint is found in `Carla/Blueprints/LevelDesign`. It adds __connected__ elements along a path defined by a Bezier curve. The mesh will not be warped to fit the curve, but the nodes will be respected.
+
+- _Distance between_ — Set the distance between elements.
+- _Vertically aligned_ — If selected, the elements will be vertically aligned regarding the world axis.
+- _Scale offset_ — Scale the length of the mesh to round out the connection between elements.
+
+![bp_wall_pic](../img/map_customization/BP_Wall.jpg)
+
BP_Wall example.
+
+### BP_SplinePoweLine
+
+The __BP_SplinePoweLine__ blueprint is found in `Carla/Static/Pole/PoweLine`. It adds __electricity poles__ along a path defined by a Bezier curve and __connects them with power lines__.
+
+To provide variety, you can provide the blueprint with an array of powerline meshes to populate the path. To do this:
+
+1. Double-click the __BP_SplinePoweLine__ blueprint in the _Content Browser_.
+2. In the _Details_ panel, go to the _Default_ section.
+3. Expand the _Array Meshes_ and add to or change it according to your needs.
+4. Press _Compile_, then save and close the window.
+
+![bp_splinepowerline_pic](../img/map_customization/BP_Splinepowerline.jpg)
+
BP_SplinePowerLine example.
+
+To alter the line tension of the power lines:
+
+1. Select the blueprint actor in the editor scene and go to the _Details_ panel.
+2. Go to the _Default_ section.
+3. Adjust the value in _Tension_. `0` indicates that the lines will be straight.
+
+To increase the amount of wires:
+
+1. In the _Content Browser_, double-click on one of the pole meshes.
+2. Go to the _Socket Manager_ panel.
+3. Configure existing sockets or add new ones by clicking _Create Socket_. Sockets are empty meshes that represent the connection points of the power line. A wire is created form socket to socket between poles.
+
+![bp_powerline_socket_pic](../img/map_customization/BP_Splinepowerline_Sockets.jpg)
+
Visualization of the sockets for BP_SplinePowerLine.
+
+
+!!! Important
+ The amount of sockets and their names should be consistent between poles. Otherwise, visualization issues may arise.
+
+---
+
+## Next steps
+
+Continue customizing your map using the tools and guides below:
+
+- [Implement sub-levels in your map.](tuto_M_custom_layers.md)
+- [Add and configure traffic lights and signs.](tuto_M_custom_add_tl.md)
+- [Add buildings with the procedural building tool.](tuto_M_custom_buildings.md)
+- [Customize the road with the road painter tool.](tuto_M_custom_road_painter.md)
+- [Customize the landscape with serial meshes.](tuto_M_custom_weather_landscape.md#add-serial-meshes)
+
+Once you have finished with the customization, you can [generate the pedestrian navigation information](tuto_M_generate_pedestrian_navigation.md).
+
+---
+
+If you have any questions about the process, then you can ask in the [forum](https://github.com/carla-simulator/carla/discussions).
+
+
\ No newline at end of file
diff --git a/Docs/tuto_M_generate_map.md b/Docs/tuto_M_generate_map.md
new file mode 100644
index 000000000..208f4b40b
--- /dev/null
+++ b/Docs/tuto_M_generate_map.md
@@ -0,0 +1,107 @@
+# Generating Maps in RoadRunner
+
+RoadRunner is the recommended software to create maps to be imported into CARLA. This guide outlines what RoadRunner is, things to consider when building the map and how to export custom maps ready for importing into CARLA.
+
+- [__Introduction to RoadRunner__](#introduction-to-roadrunner)
+- [__Before you start__](#before-you-start)
+- [__Build a map in RoadRunner__](#build-a-map-in-roadrunner)
+- [__Export a map in RoadRunner__](#export-a-map-in-roadrunner)
+- [__Next steps__](#next-steps)
+---
+## Introduction to RoadRunner
+
+RoadRunner is an interactive editor that lets you design 3D scenes for simulating and testing automated driving systems. It can be used to create road layouts and accompanying OpenDRIVE and geometry information. Find out more about RoadRunner [here][rr_home].
+
+RoadRunner is part of the MATLAB Campus-Wide Licenses, so many universities can provide unlimited academic access. [Check][rr_eligibility] if your university has access. Reach out to *automated-driving@mathworks.com* for any questions or troubles regarding accessibility. There is also a [trial version][rr_trial_version] available.
+
+A license for RoadRunner is also available to everyone participating in the CARLA Leaderboard. Click [here][rr_leaderboard] for more information.
+
+[rr_home]: https://www.mathworks.com/products/roadrunner.html
+[rr_trial_version]: https://www.mathworks.com/products/roadrunner.html
+[rr_eligibility]: https://www.mathworks.com/academia/tah-support-program/eligibility.html
+[rr_leaderboard]: https://www.mathworks.com/academia/student-competitions/carla-autonomous-driving-challenge.html
+
+---
+## Before you start
+
+You will need to install RoadRunner. You can follow the [installation guide][rr_docs] at the Mathworks website.
+
+[rr_docs]: https://www.mathworks.com/help/roadrunner/ug/install-and-activate-roadrunner.html
+
+---
+
+## Build a map in RoadRunner
+
+The specifics of how to build a map in RoadRunner go beyond the scope of this guide, however, there are video tutorials available in the [RoadRunner documentation][rr_tutorials].
+
+__Keep in mind that a map heavy with props can slow the import process significantly.__ This is because Unreal Engine needs to convert every mesh to an Unreal asset. If you plan to import your map into a source build version of CARLA, we highly recommend that you only create the road layout in RoadRunner and leave any customization until after the map has been imported into Unreal Engine. CARLA provides several tools that you can use in the Unreal Engine editor to simplify the customization process.
+
+---
+
+## Export a map in RoadRunner
+
+[rr_tutorials]: https://www.mathworks.com/support/search.html?fq=asset_type_name:video%20category:roadrunner/index&page=1&s_tid=CRUX_topnav
+
+Below is a basic guideline to export your custom map from RoadRunner. You can find more detailed information about how to export to CARLA in [MathWorks' documentation][exportlink].
+
+[exportlink]: https://www.mathworks.com/help/roadrunner/ug/Exporting-to-CARLA.html
+
+Once you have made your map in RoadRunner you will be able to export it. Be aware that __the road layout cannot be modified after it has been exported.__ Before exporting, ensure that:
+
+- The map is centered at (0,0) to ensure the map can be visualized correctly in Unreal Engine.
+- The map definition is correct.
+- The map validation is correct, paying close attention to connections and geometries.
+
+
+>>>>![CheckGeometry](../img/check_geometry.jpg)
+
+Once the map is ready, click on the `OpenDRIVE Preview Tool` button to visualize the OpenDRIVE road network and give everything one last check.
+
+>>>>![checkopen](../img/check_open.jpg)
+
+!!! note
+ _OpenDrive Preview Tool_ makes it easier to test the integrity of the map. If there are any errors with junctions, click on `Maneuver Tool`, and `Rebuild Maneuver Roads`.
+
+When you are ready to export:
+
+__1.__ Export the scene using the CARLA option:
+
+ - In the main toolbar, select `File` -> `Export` -> `CARLA (.fbx, .xodr, .rrdata.xml)`
+
+__2.__ In the window that pops up:
+
+>- Check the following options:
+ - _Split by Segmentation_: Divides the mesh by semantic segmentation.
+ - _Power of Two Texture Dimensions_: Improves performance.
+ - _Embed Textures_: Ensures textures are embedded in the mesh.
+ - _Export to Tiles_: Choose the size of the tile or leave unchecked for only one piece.
+
+>- Leave unchecked:
+ - _Export Individual Tiles_: Generates one `.fbx` file with all map pieces.
+
+>>>>![roadrunner_export](../img/roadrunner_export.png)
+
+__3.__ Choose the directory where you want to export your files and click `Export`. This will generate `.fbx` and `.xodr` files among others.
+
+!!! Warning
+ Make sure that the `.xodr` and the `.fbx` files have the same name.
+
+---
+
+## Next steps
+
+You are now ready to import your map into CARLA. The next step will depend upon the kind of CARLA installation you are using:
+
+* __For users of CARLA built from source__, follow the guide [__here__](tuto_M_add_map_source.md).
+* __For users of a packaged (binary) version of CARLA__, follow the guide [__here__](tuto_M_add_map_package.md).
+
+---
+
+If you have any questions about the process, then you can ask in the [forum](https://github.com/carla-simulator/carla/discussions).
+
+
\ No newline at end of file
diff --git a/Docs/tuto_M_generate_pedestrian_navigation.md b/Docs/tuto_M_generate_pedestrian_navigation.md
new file mode 100644
index 000000000..44c965733
--- /dev/null
+++ b/Docs/tuto_M_generate_pedestrian_navigation.md
@@ -0,0 +1,90 @@
+# Generate Pedestrian Navigation
+
+To allow pedestrians to navigate a map, you will need to generate a pedestrian navigation file. This guide details what meshes to use and how to generate the file.
+
+- [__Before you begin__](#before-you-begin)
+- [__Pedestrian navigable meshes__](#pedestrian-navigable-meshes)
+- [__Optional pedestrian navigation options__](#optional-pedestrian-navigation-options)
+- [__Generate the pedestrian navigation__](#generate-the-pedestrian-navigation)
+
+---
+
+## Before you begin
+
+Map customization (adding buildings, painting the road, adding landscape features, etc.) should be completed before generating the pedestrian navigation in order to avoid interference or collisions between the two, resulting in the need to generate the pedestrian navigation a second time.
+
+---
+
+## Pedestrian navigable meshes
+
+Pedestrians can only navigate specific meshes. You need to name the meshes you want to include in pedestrian navigation according to the nomenclature in the table below:
+
+| Type | Name includes | Description |
+|------|------------|-------------|
+| Ground | `Road_Sidewalk` or `Roads_Sidewalk` | Pedestrians will walk over these meshes freely. |
+| Crosswalk | `Road_Crosswalk` or `Roads_Crosswalk` | Pedestrians will walk over these meshes as a second option if no ground is found. |
+| Grass | `Road_Grass` or `Roads_Grass` | Pedestrians won't walk on this mesh unless you specify a percentage of them to do so. |
+| Road | `Road_Road` or `Roads_Road` `Road_Curb` or `Roads_Curb` `Road_Gutter` or `Roads_Gutter` `Road_Marking` or `Roads_Marking` | Pedestrians will only cross roads through these meshes. |
+
+
+
+---
+
+## Optional pedestrian navigation options
+
+The following step is not necessary for generating a pedestrian navigation, but allows you to customize pedestrian activity to a certain extent.
+
+- __Generate new crosswalks__.
+
+Avoid doing this if the crosswalk is already defined the `.xodr` file as this will lead to duplication:
+
+1. Create a plane mesh that extends a bit over two sidewalks that you want to connect.
+2. Place the mesh overlapping the ground and disable it's physics and rendering.
+3. Change the name of the mesh to `Road_Crosswalk` or `Roads_Crosswalk`.
+
+![ue_crosswalks](../img/ue_crosswalks.jpg)
+
+---
+## Generate the pedestrian navigation
+
+__1.__ To prevent the map being too large to export, select the __BP_Sky object__ and add a tag `NoExport` to it. If you have any other particularly large meshes that are not involved in the pedestrian navigation, add the `NoExport` tag to them as well.
+
+![ue_skybox_no_export](../img/ue_noexport.png)
+
+__2.__ Double check your mesh names. Mesh names should start with any of the appropriate formats listed below in order to be recognized as areas where pedestrians can walk. By default, pedestrians will be able to walk over sidewalks, crosswalks, and grass (with minor influence over the rest):
+
+* Sidewalk = `Road_Sidewalk` or `Roads_Sidewalk`
+* Crosswalk = `Road_Crosswalk` or `Roads_Crosswalk`
+* Grass = `Road_Grass` or `Roads_Grass`
+
+![ue_meshes](../img/ue_meshes.jpg)
+
+__3.__ Press `ctrl + A` to select everything and export the map by selecting `File` -> `Carla Exporter`. A `.obj` file will be created in `Unreal/CarlaUE4/Saved`.
+
+__4.__ Move the `.obj` and the `.xodr` to `Util/DockerUtils/dist`.
+
+__5.__ Run the following command to generate the navigation file:
+
+* __Windows__
+```sh
+build.bat # has no extension
+```
+* __Linux__
+```sh
+./build.sh # has no extension
+```
+
+__6.__ A `.bin` file will be created. This file contains the information for pedestrian navigation on your map. Move this file to the `Nav` folder of the package that contains the map.
+
+__7.__ Test the pedestrian navigation by starting a simulation and running the example script `generate_traffic.py` in `PythonAPI/examples`.
+
+---
+
+If you have any questions about the process, then you can ask in the [forum](https://github.com/carla-simulator/carla/discussions).
+
+
\ No newline at end of file
diff --git a/Docs/tuto_M_manual_map_package.md b/Docs/tuto_M_manual_map_package.md
new file mode 100644
index 000000000..2af290e03
--- /dev/null
+++ b/Docs/tuto_M_manual_map_package.md
@@ -0,0 +1,99 @@
+# Manual package preparation
+
+A map package follows a certain folder structure and must contain a `.json` file describing that structure. Our automatic map import processes create this `.json` file automatically, but you also have the option to prepare it yourself. Including your own `.json` file will overwrite any arguments passed to the `make import` command.
+
+- [__Standard Maps__](#standard-maps)
+ - [Create the folder structure for the standard maps](#create-the-folder-structure-for-the-standard-maps)
+ - [Create the JSON description for the standard maps](#create-the-json-description-for-the-standard-maps)
+- [__Large Maps__](#large-maps)
+ - [Create the folder structure for the large maps](#create-the-folder-structure-for-the-large-maps)
+ - [Create the JSON description for the large maps](#create-the-json-description-for-the-large-maps)
+
+---
+
+## Standard maps
+### Create the folder structure for the standard maps
+
+__1. Create a folder inside `carla/Import`.__ The name of the folder is not important.
+
+__2. Create different subfolders__ for each map to be imported.
+
+__3. Move the files of each map to the corresponding subfolder.__ A subfolder will contain a specific set of elements:
+
+- The mesh of the map in a `.fbx` file.
+- The OpenDRIVE definition in a `.xodr` file.
+- Optionally, the textures required by the asset.
+
+For instance, an `Import` folder with one package containing two maps should have a structure similar to the one below.
+
+```sh
+Import
+│
+└── Package01
+ ├── Package01.json
+ ├── Map01
+ │ ├── Asphalt1_Diff.jpg
+ │ ├── Asphalt1_Norm.jpg
+ │ ├── Asphalt1_Spec.jpg
+ │ ├── Grass1_Diff.jpg
+ │ ├── Grass1_Norm.jpg
+ │ ├── Grass1_Spec.jpg
+ │ ├── LaneMarking1_Diff.jpg
+ │ ├── LaneMarking1_Norm.jpg
+ │ ├── LaneMarking1_Spec.jpg
+ │ ├── Map01.fbx
+ │ └── Map01.xodr
+ └── Map02
+ └── Map02.fbx
+```
+
+---
+
+### Create the JSON description for the standard maps
+
+Create a `.json` file in the root folder of the package. Name the file after the package. Note that this will be the distribution name. The content of the file will describe a JSON array of __maps__ and __props__ with basic information for each of them.
+
+__Maps__ need the following parameters:
+
+- __name__ of the map. This must be the same as the `.fbx` and `.xodr` files.
+- __source__ path to the `.fbx` file.
+- __use_carla_materials__. If __True__, the map will use CARLA materials. Otherwise, it will use RoadRunner materials.
+- __xodr__ Path to the `.xodr` file.
+
+__Props__ are not part of this tutorial. The field will be left empty. There is another tutorial on how to [add new props](tuto_A_add_props.md).
+
+The resulting `.json` file should resemble the following:
+
+```json
+{
+ "maps": [
+ {
+ "name": "Map01",
+ "source": "./Map01/Map01.fbx",
+ "use_carla_materials": true,
+ "xodr": "./Map01/Map01.xodr"
+ },
+ {
+ "name": "Map02",
+ "source": "./Map02/Map02.fbx",
+ "use_carla_materials": false,
+ "xodr": "./Map02/Map02.xodr"
+ }
+ ],
+ "props": [
+ ]
+}
+```
+
+
+
+---
+
+If you have any questions about the process, then you can ask in the [forum](https://github.com/carla-simulator/carla/discussions).
+
+