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

+ +CARLA 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/bp_library.md b/Docs/bp_library.md index e0324ecd5..2a33ec392 100755 --- a/Docs/bp_library.md +++ b/Docs/bp_library.md @@ -83,6 +83,19 @@ Check out the [introduction to blueprints](core_actors.md). - `toe` (_Float_)_ – Modifiable_ - `use_log` (_Bool_)_ – Modifiable_ - `white_clip` (_Float_)_ – Modifiable_ +- **sensor.camera.optical_flow** + - **Attributes:** + - `fov` (_Float_)_ – Modifiable_ + - `image_size_x` (_Int_)_ – Modifiable_ + - `image_size_y` (_Int_)_ – Modifiable_ + - `lens_circle_falloff` (_Float_)_ – Modifiable_ + - `lens_circle_multiplier` (_Float_)_ – Modifiable_ + - `lens_k` (_Float_)_ – Modifiable_ + - `lens_kcube` (_Float_)_ – Modifiable_ + - `lens_x_size` (_Float_)_ – Modifiable_ + - `lens_y_size` (_Float_)_ – Modifiable_ + - `role_name` (_String_)_ – Modifiable_ + - `sensor_tick` (_Float_)_ – Modifiable_ - **sensor.camera.rgb** - **Attributes:** - `black_clip` (_Float_)_ – Modifiable_ @@ -592,6 +605,7 @@ Check out the [introduction to blueprints](core_actors.md). - **vehicle.audi.a2** - **Attributes:** - `color` (_RGBColor_)_ – Modifiable_ + - `generation` (_Int_) - `number_of_wheels` (_Int_) - `object_type` (_String_) - `role_name` (_String_)_ – Modifiable_ @@ -599,6 +613,7 @@ Check out the [introduction to blueprints](core_actors.md). - **vehicle.audi.etron** - **Attributes:** - `color` (_RGBColor_)_ – Modifiable_ + - `generation` (_Int_) - `number_of_wheels` (_Int_) - `object_type` (_String_) - `role_name` (_String_)_ – Modifiable_ @@ -606,6 +621,7 @@ Check out the [introduction to blueprints](core_actors.md). - **vehicle.audi.tt** - **Attributes:** - `color` (_RGBColor_)_ – Modifiable_ + - `generation` (_Int_) - `number_of_wheels` (_Int_) - `object_type` (_String_) - `role_name` (_String_)_ – Modifiable_ @@ -614,6 +630,7 @@ Check out the [introduction to blueprints](core_actors.md). - **Attributes:** - `color` (_RGBColor_)_ – Modifiable_ - `driver_id` (_Int_)_ – Modifiable_ + - `generation` (_Int_) - `number_of_wheels` (_Int_) - `object_type` (_String_) - `role_name` (_String_)_ – Modifiable_ @@ -621,13 +638,7 @@ Check out the [introduction to blueprints](core_actors.md). - **vehicle.bmw.grandtourer** - **Attributes:** - `color` (_RGBColor_)_ – Modifiable_ - - `number_of_wheels` (_Int_) - - `object_type` (_String_) - - `role_name` (_String_)_ – Modifiable_ - - `sticky_control` (_Bool_)_ – Modifiable_ -- **vehicle.bmw.isetta** - - **Attributes:** - - `color` (_RGBColor_)_ – Modifiable_ + - `generation` (_Int_) - `number_of_wheels` (_Int_) - `object_type` (_String_) - `role_name` (_String_)_ – Modifiable_ @@ -635,20 +646,14 @@ Check out the [introduction to blueprints](core_actors.md). - **vehicle.carlamotors.carlacola** - **Attributes:** - `color` (_RGBColor_)_ – Modifiable_ + - `generation` (_Int_) - `number_of_wheels` (_Int_) - `object_type` (_String_) - `role_name` (_String_)_ – Modifiable_ - `sticky_control` (_Bool_)_ – Modifiable_ -- **vehicle.charger2020.charger2020** +- **vehicle.carlamotors.firetruck** - **Attributes:** - - `color` (_RGBColor_)_ – Modifiable_ - - `number_of_wheels` (_Int_) - - `object_type` (_String_) - - `role_name` (_String_)_ – Modifiable_ - - `sticky_control` (_Bool_)_ – Modifiable_ -- **vehicle.chargercop2020.chargercop2020** - - **Attributes:** - - `color` (_RGBColor_)_ – Modifiable_ + - `generation` (_Int_) - `number_of_wheels` (_Int_) - `object_type` (_String_) - `role_name` (_String_)_ – Modifiable_ @@ -656,6 +661,7 @@ Check out the [introduction to blueprints](core_actors.md). - **vehicle.chevrolet.impala** - **Attributes:** - `color` (_RGBColor_)_ – Modifiable_ + - `generation` (_Int_) - `number_of_wheels` (_Int_) - `object_type` (_String_) - `role_name` (_String_)_ – Modifiable_ @@ -663,6 +669,7 @@ Check out the [introduction to blueprints](core_actors.md). - **vehicle.citroen.c3** - **Attributes:** - `color` (_RGBColor_)_ – Modifiable_ + - `generation` (_Int_) - `number_of_wheels` (_Int_) - `object_type` (_String_) - `role_name` (_String_)_ – Modifiable_ @@ -671,13 +678,46 @@ Check out the [introduction to blueprints](core_actors.md). - **Attributes:** - `color` (_RGBColor_)_ – Modifiable_ - `driver_id` (_Int_)_ – Modifiable_ + - `generation` (_Int_) - `number_of_wheels` (_Int_) - `object_type` (_String_) - `role_name` (_String_)_ – Modifiable_ - `sticky_control` (_Bool_)_ – Modifiable_ -- **vehicle.dodge_charger.police** +- **vehicle.dodge.charger_2020** - **Attributes:** - `color` (_RGBColor_)_ – Modifiable_ + - `generation` (_Int_) + - `number_of_wheels` (_Int_) + - `object_type` (_String_) + - `role_name` (_String_)_ – Modifiable_ + - `sticky_control` (_Bool_)_ – Modifiable_ +- **vehicle.dodge.charger_police** + - **Attributes:** + - `color` (_RGBColor_)_ – Modifiable_ + - `generation` (_Int_) + - `number_of_wheels` (_Int_) + - `object_type` (_String_) + - `role_name` (_String_)_ – Modifiable_ + - `sticky_control` (_Bool_)_ – Modifiable_ +- **vehicle.dodge.charger_police_2020** + - **Attributes:** + - `color` (_RGBColor_)_ – Modifiable_ + - `generation` (_Int_) + - `number_of_wheels` (_Int_) + - `object_type` (_String_) + - `role_name` (_String_)_ – Modifiable_ + - `sticky_control` (_Bool_)_ – Modifiable_ +- **vehicle.ford.ambulance** + - **Attributes:** + - `generation` (_Int_) + - `number_of_wheels` (_Int_) + - `object_type` (_String_) + - `role_name` (_String_)_ – Modifiable_ + - `sticky_control` (_Bool_)_ – Modifiable_ +- **vehicle.ford.mustang** + - **Attributes:** + - `color` (_RGBColor_)_ – Modifiable_ + - `generation` (_Int_) - `number_of_wheels` (_Int_) - `object_type` (_String_) - `role_name` (_String_)_ – Modifiable_ @@ -686,6 +726,7 @@ Check out the [introduction to blueprints](core_actors.md). - **Attributes:** - `color` (_RGBColor_)_ – Modifiable_ - `driver_id` (_Int_)_ – Modifiable_ + - `generation` (_Int_) - `number_of_wheels` (_Int_) - `object_type` (_String_) - `role_name` (_String_)_ – Modifiable_ @@ -694,6 +735,7 @@ Check out the [introduction to blueprints](core_actors.md). - **Attributes:** - `color` (_RGBColor_)_ – Modifiable_ - `driver_id` (_Int_)_ – Modifiable_ + - `generation` (_Int_) - `number_of_wheels` (_Int_) - `object_type` (_String_) - `role_name` (_String_)_ – Modifiable_ @@ -701,6 +743,7 @@ Check out the [introduction to blueprints](core_actors.md). - **vehicle.jeep.wrangler_rubicon** - **Attributes:** - `color` (_RGBColor_)_ – Modifiable_ + - `generation` (_Int_) - `number_of_wheels` (_Int_) - `object_type` (_String_) - `role_name` (_String_)_ – Modifiable_ @@ -709,49 +752,71 @@ Check out the [introduction to blueprints](core_actors.md). - **Attributes:** - `color` (_RGBColor_)_ – Modifiable_ - `driver_id` (_Int_)_ – Modifiable_ + - `generation` (_Int_) - `number_of_wheels` (_Int_) - `object_type` (_String_) - `role_name` (_String_)_ – Modifiable_ - `sticky_control` (_Bool_)_ – Modifiable_ -- **vehicle.lincoln.mkz2017** +- **vehicle.lincoln.mkz_2017** - **Attributes:** - `color` (_RGBColor_)_ – Modifiable_ + - `generation` (_Int_) - `number_of_wheels` (_Int_) - `object_type` (_String_) - `role_name` (_String_)_ – Modifiable_ - `sticky_control` (_Bool_)_ – Modifiable_ -- **vehicle.lincoln2020.mkz2020** +- **vehicle.lincoln.mkz_2020** - **Attributes:** - `color` (_RGBColor_)_ – Modifiable_ - `driver_id` (_Int_)_ – Modifiable_ + - `generation` (_Int_) - `number_of_wheels` (_Int_) - `object_type` (_String_) - `role_name` (_String_)_ – Modifiable_ - `sticky_control` (_Bool_)_ – Modifiable_ -- **vehicle.mercedes-benz.coupe** +- **vehicle.mercedes.coupe** - **Attributes:** - `color` (_RGBColor_)_ – Modifiable_ + - `generation` (_Int_) - `number_of_wheels` (_Int_) - `object_type` (_String_) - `role_name` (_String_)_ – Modifiable_ - `sticky_control` (_Bool_)_ – Modifiable_ -- **vehicle.mercedesccc.mercedesccc** +- **vehicle.mercedes.coupe_2020** - **Attributes:** - `color` (_RGBColor_)_ – Modifiable_ + - `generation` (_Int_) - `number_of_wheels` (_Int_) - `object_type` (_String_) - `role_name` (_String_)_ – Modifiable_ - `sticky_control` (_Bool_)_ – Modifiable_ -- **vehicle.mini.cooperst** +- **vehicle.mercedes.sprinter** - **Attributes:** - - `color` (_RGBColor_)_ – Modifiable_ + - `generation` (_Int_) - `number_of_wheels` (_Int_) - `object_type` (_String_) - `role_name` (_String_)_ – Modifiable_ - `sticky_control` (_Bool_)_ – Modifiable_ -- **vehicle.mustang.mustang** +- **vehicle.micro.microlino** - **Attributes:** - `color` (_RGBColor_)_ – Modifiable_ + - `generation` (_Int_) + - `number_of_wheels` (_Int_) + - `object_type` (_String_) + - `role_name` (_String_)_ – Modifiable_ + - `sticky_control` (_Bool_)_ – Modifiable_ +- **vehicle.mini.cooper_s** + - **Attributes:** + - `color` (_RGBColor_)_ – Modifiable_ + - `generation` (_Int_) + - `number_of_wheels` (_Int_) + - `object_type` (_String_) + - `role_name` (_String_)_ – Modifiable_ + - `sticky_control` (_Bool_)_ – Modifiable_ +- **vehicle.mini.cooper_s_2021** + - **Attributes:** + - `color` (_RGBColor_)_ – Modifiable_ + - `generation` (_Int_) - `number_of_wheels` (_Int_) - `object_type` (_String_) - `role_name` (_String_)_ – Modifiable_ @@ -759,6 +824,7 @@ Check out the [introduction to blueprints](core_actors.md). - **vehicle.nissan.micra** - **Attributes:** - `color` (_RGBColor_)_ – Modifiable_ + - `generation` (_Int_) - `number_of_wheels` (_Int_) - `object_type` (_String_) - `role_name` (_String_)_ – Modifiable_ @@ -766,6 +832,15 @@ Check out the [introduction to blueprints](core_actors.md). - **vehicle.nissan.patrol** - **Attributes:** - `color` (_RGBColor_)_ – Modifiable_ + - `generation` (_Int_) + - `number_of_wheels` (_Int_) + - `object_type` (_String_) + - `role_name` (_String_)_ – Modifiable_ + - `sticky_control` (_Bool_)_ – Modifiable_ +- **vehicle.nissan.patrol_2021** + - **Attributes:** + - `color` (_RGBColor_)_ – Modifiable_ + - `generation` (_Int_) - `number_of_wheels` (_Int_) - `object_type` (_String_) - `role_name` (_String_)_ – Modifiable_ @@ -773,12 +848,14 @@ Check out the [introduction to blueprints](core_actors.md). - **vehicle.seat.leon** - **Attributes:** - `color` (_RGBColor_)_ – Modifiable_ + - `generation` (_Int_) - `number_of_wheels` (_Int_) - `object_type` (_String_) - `role_name` (_String_)_ – Modifiable_ - `sticky_control` (_Bool_)_ – Modifiable_ - **vehicle.tesla.cybertruck** - **Attributes:** + - `generation` (_Int_) - `number_of_wheels` (_Int_) - `object_type` (_String_) - `role_name` (_String_)_ – Modifiable_ @@ -786,6 +863,7 @@ Check out the [introduction to blueprints](core_actors.md). - **vehicle.tesla.model3** - **Attributes:** - `color` (_RGBColor_)_ – Modifiable_ + - `generation` (_Int_) - `number_of_wheels` (_Int_) - `object_type` (_String_) - `role_name` (_String_)_ – Modifiable_ @@ -793,6 +871,16 @@ Check out the [introduction to blueprints](core_actors.md). - **vehicle.toyota.prius** - **Attributes:** - `color` (_RGBColor_)_ – Modifiable_ + - `generation` (_Int_) + - `number_of_wheels` (_Int_) + - `object_type` (_String_) + - `role_name` (_String_)_ – Modifiable_ + - `sticky_control` (_Bool_)_ – Modifiable_ +- **vehicle.vespa.zx125** + - **Attributes:** + - `color` (_RGBColor_)_ – Modifiable_ + - `driver_id` (_Int_)_ – Modifiable_ + - `generation` (_Int_) - `number_of_wheels` (_Int_) - `object_type` (_String_) - `role_name` (_String_)_ – Modifiable_ @@ -800,6 +888,7 @@ Check out the [introduction to blueprints](core_actors.md). - **vehicle.volkswagen.t2** - **Attributes:** - `color` (_RGBColor_)_ – Modifiable_ + - `generation` (_Int_) - `number_of_wheels` (_Int_) - `object_type` (_String_) - `role_name` (_String_)_ – Modifiable_ @@ -808,6 +897,7 @@ Check out the [introduction to blueprints](core_actors.md). - **Attributes:** - `color` (_RGBColor_)_ – Modifiable_ - `driver_id` (_Int_)_ – Modifiable_ + - `generation` (_Int_) - `number_of_wheels` (_Int_) - `object_type` (_String_) - `role_name` (_String_)_ – Modifiable_ @@ -818,6 +908,7 @@ Check out the [introduction to blueprints](core_actors.md). - **Attributes:** - `age` (_String_) - `gender` (_String_) + - `generation` (_Int_) - `is_invincible` (_Bool_)_ – Modifiable_ - `role_name` (_String_)_ – Modifiable_ - `speed` (_Float_)_ – Modifiable_ @@ -825,6 +916,7 @@ Check out the [introduction to blueprints](core_actors.md). - **Attributes:** - `age` (_String_) - `gender` (_String_) + - `generation` (_Int_) - `is_invincible` (_Bool_)_ – Modifiable_ - `role_name` (_String_)_ – Modifiable_ - `speed` (_Float_)_ – Modifiable_ @@ -832,6 +924,7 @@ Check out the [introduction to blueprints](core_actors.md). - **Attributes:** - `age` (_String_) - `gender` (_String_) + - `generation` (_Int_) - `is_invincible` (_Bool_)_ – Modifiable_ - `role_name` (_String_)_ – Modifiable_ - `speed` (_Float_)_ – Modifiable_ @@ -839,6 +932,7 @@ Check out the [introduction to blueprints](core_actors.md). - **Attributes:** - `age` (_String_) - `gender` (_String_) + - `generation` (_Int_) - `is_invincible` (_Bool_)_ – Modifiable_ - `role_name` (_String_)_ – Modifiable_ - `speed` (_Float_)_ – Modifiable_ @@ -846,6 +940,7 @@ Check out the [introduction to blueprints](core_actors.md). - **Attributes:** - `age` (_String_) - `gender` (_String_) + - `generation` (_Int_) - `is_invincible` (_Bool_)_ – Modifiable_ - `role_name` (_String_)_ – Modifiable_ - `speed` (_Float_)_ – Modifiable_ @@ -853,6 +948,7 @@ Check out the [introduction to blueprints](core_actors.md). - **Attributes:** - `age` (_String_) - `gender` (_String_) + - `generation` (_Int_) - `is_invincible` (_Bool_)_ – Modifiable_ - `role_name` (_String_)_ – Modifiable_ - `speed` (_Float_)_ – Modifiable_ @@ -860,6 +956,7 @@ Check out the [introduction to blueprints](core_actors.md). - **Attributes:** - `age` (_String_) - `gender` (_String_) + - `generation` (_Int_) - `is_invincible` (_Bool_)_ – Modifiable_ - `role_name` (_String_)_ – Modifiable_ - `speed` (_Float_)_ – Modifiable_ @@ -867,6 +964,7 @@ Check out the [introduction to blueprints](core_actors.md). - **Attributes:** - `age` (_String_) - `gender` (_String_) + - `generation` (_Int_) - `is_invincible` (_Bool_)_ – Modifiable_ - `role_name` (_String_)_ – Modifiable_ - `speed` (_Float_)_ – Modifiable_ @@ -874,6 +972,7 @@ Check out the [introduction to blueprints](core_actors.md). - **Attributes:** - `age` (_String_) - `gender` (_String_) + - `generation` (_Int_) - `is_invincible` (_Bool_)_ – Modifiable_ - `role_name` (_String_)_ – Modifiable_ - `speed` (_Float_)_ – Modifiable_ @@ -881,6 +980,7 @@ Check out the [introduction to blueprints](core_actors.md). - **Attributes:** - `age` (_String_) - `gender` (_String_) + - `generation` (_Int_) - `is_invincible` (_Bool_)_ – Modifiable_ - `role_name` (_String_)_ – Modifiable_ - `speed` (_Float_)_ – Modifiable_ @@ -888,6 +988,7 @@ Check out the [introduction to blueprints](core_actors.md). - **Attributes:** - `age` (_String_) - `gender` (_String_) + - `generation` (_Int_) - `is_invincible` (_Bool_)_ – Modifiable_ - `role_name` (_String_)_ – Modifiable_ - `speed` (_Float_)_ – Modifiable_ @@ -895,6 +996,7 @@ Check out the [introduction to blueprints](core_actors.md). - **Attributes:** - `age` (_String_) - `gender` (_String_) + - `generation` (_Int_) - `is_invincible` (_Bool_)_ – Modifiable_ - `role_name` (_String_)_ – Modifiable_ - `speed` (_Float_)_ – Modifiable_ @@ -902,6 +1004,7 @@ Check out the [introduction to blueprints](core_actors.md). - **Attributes:** - `age` (_String_) - `gender` (_String_) + - `generation` (_Int_) - `is_invincible` (_Bool_)_ – Modifiable_ - `role_name` (_String_)_ – Modifiable_ - `speed` (_Float_)_ – Modifiable_ @@ -909,6 +1012,7 @@ Check out the [introduction to blueprints](core_actors.md). - **Attributes:** - `age` (_String_) - `gender` (_String_) + - `generation` (_Int_) - `is_invincible` (_Bool_)_ – Modifiable_ - `role_name` (_String_)_ – Modifiable_ - `speed` (_Float_)_ – Modifiable_ @@ -916,6 +1020,7 @@ Check out the [introduction to blueprints](core_actors.md). - **Attributes:** - `age` (_String_) - `gender` (_String_) + - `generation` (_Int_) - `is_invincible` (_Bool_)_ – Modifiable_ - `role_name` (_String_)_ – Modifiable_ - `speed` (_Float_)_ – Modifiable_ @@ -923,6 +1028,7 @@ Check out the [introduction to blueprints](core_actors.md). - **Attributes:** - `age` (_String_) - `gender` (_String_) + - `generation` (_Int_) - `is_invincible` (_Bool_)_ – Modifiable_ - `role_name` (_String_)_ – Modifiable_ - `speed` (_Float_)_ – Modifiable_ @@ -930,6 +1036,7 @@ Check out the [introduction to blueprints](core_actors.md). - **Attributes:** - `age` (_String_) - `gender` (_String_) + - `generation` (_Int_) - `is_invincible` (_Bool_)_ – Modifiable_ - `role_name` (_String_)_ – Modifiable_ - `speed` (_Float_)_ – Modifiable_ @@ -937,6 +1044,7 @@ Check out the [introduction to blueprints](core_actors.md). - **Attributes:** - `age` (_String_) - `gender` (_String_) + - `generation` (_Int_) - `is_invincible` (_Bool_)_ – Modifiable_ - `role_name` (_String_)_ – Modifiable_ - `speed` (_Float_)_ – Modifiable_ @@ -944,6 +1052,7 @@ Check out the [introduction to blueprints](core_actors.md). - **Attributes:** - `age` (_String_) - `gender` (_String_) + - `generation` (_Int_) - `is_invincible` (_Bool_)_ – Modifiable_ - `role_name` (_String_)_ – Modifiable_ - `speed` (_Float_)_ – Modifiable_ @@ -951,6 +1060,7 @@ Check out the [introduction to blueprints](core_actors.md). - **Attributes:** - `age` (_String_) - `gender` (_String_) + - `generation` (_Int_) - `is_invincible` (_Bool_)_ – Modifiable_ - `role_name` (_String_)_ – Modifiable_ - `speed` (_Float_)_ – Modifiable_ @@ -958,6 +1068,7 @@ Check out the [introduction to blueprints](core_actors.md). - **Attributes:** - `age` (_String_) - `gender` (_String_) + - `generation` (_Int_) - `is_invincible` (_Bool_)_ – Modifiable_ - `role_name` (_String_)_ – Modifiable_ - `speed` (_Float_)_ – Modifiable_ @@ -965,6 +1076,7 @@ Check out the [introduction to blueprints](core_actors.md). - **Attributes:** - `age` (_String_) - `gender` (_String_) + - `generation` (_Int_) - `is_invincible` (_Bool_)_ – Modifiable_ - `role_name` (_String_)_ – Modifiable_ - `speed` (_Float_)_ – Modifiable_ @@ -972,6 +1084,7 @@ Check out the [introduction to blueprints](core_actors.md). - **Attributes:** - `age` (_String_) - `gender` (_String_) + - `generation` (_Int_) - `is_invincible` (_Bool_)_ – Modifiable_ - `role_name` (_String_)_ – Modifiable_ - `speed` (_Float_)_ – Modifiable_ @@ -979,6 +1092,7 @@ Check out the [introduction to blueprints](core_actors.md). - **Attributes:** - `age` (_String_) - `gender` (_String_) + - `generation` (_Int_) - `is_invincible` (_Bool_)_ – Modifiable_ - `role_name` (_String_)_ – Modifiable_ - `speed` (_Float_)_ – Modifiable_ @@ -986,6 +1100,7 @@ Check out the [introduction to blueprints](core_actors.md). - **Attributes:** - `age` (_String_) - `gender` (_String_) + - `generation` (_Int_) - `is_invincible` (_Bool_)_ – Modifiable_ - `role_name` (_String_)_ – Modifiable_ - `speed` (_Float_)_ – Modifiable_ @@ -993,6 +1108,127 @@ Check out the [introduction to blueprints](core_actors.md). - **Attributes:** - `age` (_String_) - `gender` (_String_) + - `generation` (_Int_) + - `is_invincible` (_Bool_)_ – Modifiable_ + - `role_name` (_String_)_ – Modifiable_ + - `speed` (_Float_)_ – Modifiable_ +- **walker.pedestrian.0027** + - **Attributes:** + - `age` (_String_) + - `gender` (_String_) + - `generation` (_Int_) + - `is_invincible` (_Bool_)_ – Modifiable_ + - `role_name` (_String_)_ – Modifiable_ + - `speed` (_Float_)_ – Modifiable_ +- **walker.pedestrian.0028** + - **Attributes:** + - `age` (_String_) + - `gender` (_String_) + - `generation` (_Int_) + - `is_invincible` (_Bool_)_ – Modifiable_ + - `role_name` (_String_)_ – Modifiable_ + - `speed` (_Float_)_ – Modifiable_ +- **walker.pedestrian.0029** + - **Attributes:** + - `age` (_String_) + - `gender` (_String_) + - `generation` (_Int_) + - `is_invincible` (_Bool_)_ – Modifiable_ + - `role_name` (_String_)_ – Modifiable_ + - `speed` (_Float_)_ – Modifiable_ +- **walker.pedestrian.0030** + - **Attributes:** + - `age` (_String_) + - `gender` (_String_) + - `generation` (_Int_) + - `is_invincible` (_Bool_)_ – Modifiable_ + - `role_name` (_String_)_ – Modifiable_ + - `speed` (_Float_)_ – Modifiable_ +- **walker.pedestrian.0031** + - **Attributes:** + - `age` (_String_) + - `gender` (_String_) + - `generation` (_Int_) + - `is_invincible` (_Bool_)_ – Modifiable_ + - `role_name` (_String_)_ – Modifiable_ + - `speed` (_Float_)_ – Modifiable_ +- **walker.pedestrian.0032** + - **Attributes:** + - `age` (_String_) + - `gender` (_String_) + - `generation` (_Int_) + - `is_invincible` (_Bool_)_ – Modifiable_ + - `role_name` (_String_)_ – Modifiable_ + - `speed` (_Float_)_ – Modifiable_ +- **walker.pedestrian.0033** + - **Attributes:** + - `age` (_String_) + - `gender` (_String_) + - `generation` (_Int_) + - `is_invincible` (_Bool_)_ – Modifiable_ + - `role_name` (_String_)_ – Modifiable_ + - `speed` (_Float_)_ – Modifiable_ +- **walker.pedestrian.0034** + - **Attributes:** + - `age` (_String_) + - `gender` (_String_) + - `generation` (_Int_) + - `is_invincible` (_Bool_)_ – Modifiable_ + - `role_name` (_String_)_ – Modifiable_ + - `speed` (_Float_)_ – Modifiable_ +- **walker.pedestrian.0035** + - **Attributes:** + - `age` (_String_) + - `gender` (_String_) + - `generation` (_Int_) + - `is_invincible` (_Bool_)_ – Modifiable_ + - `role_name` (_String_)_ – Modifiable_ + - `speed` (_Float_)_ – Modifiable_ +- **walker.pedestrian.0036** + - **Attributes:** + - `age` (_String_) + - `gender` (_String_) + - `generation` (_Int_) + - `is_invincible` (_Bool_)_ – Modifiable_ + - `role_name` (_String_)_ – Modifiable_ + - `speed` (_Float_)_ – Modifiable_ +- **walker.pedestrian.0037** + - **Attributes:** + - `age` (_String_) + - `gender` (_String_) + - `generation` (_Int_) + - `is_invincible` (_Bool_)_ – Modifiable_ + - `role_name` (_String_)_ – Modifiable_ + - `speed` (_Float_)_ – Modifiable_ +- **walker.pedestrian.0038** + - **Attributes:** + - `age` (_String_) + - `gender` (_String_) + - `generation` (_Int_) + - `is_invincible` (_Bool_)_ – Modifiable_ + - `role_name` (_String_)_ – Modifiable_ + - `speed` (_Float_)_ – Modifiable_ +- **walker.pedestrian.0039** + - **Attributes:** + - `age` (_String_) + - `gender` (_String_) + - `generation` (_Int_) + - `is_invincible` (_Bool_)_ – Modifiable_ + - `role_name` (_String_)_ – Modifiable_ + - `speed` (_Float_)_ – Modifiable_ +- **walker.pedestrian.0040** + - **Attributes:** + - `age` (_String_) + - `gender` (_String_) + - `generation` (_Int_) + - `is_invincible` (_Bool_)_ – Modifiable_ + - `role_name` (_String_)_ – Modifiable_ + - `speed` (_Float_)_ – Modifiable_ +- **walker.pedestrian.0041** + - **Attributes:** + - `age` (_String_) + - `gender` (_String_) + - `generation` (_Int_) - `is_invincible` (_Bool_)_ – Modifiable_ - `role_name` (_String_)_ – Modifiable_ - `speed` (_Float_)_ – Modifiable_ diff --git a/Docs/build_docker.md b/Docs/build_docker.md index 90552d2cb..a276f724a 100644 --- a/Docs/build_docker.md +++ b/Docs/build_docker.md @@ -1,66 +1,102 @@ -# Running CARLA in a Docker +# CARLA in Docker -* [__Docker installation__](#docker-installation) - * [Docker CE](#docker-ce) - * [NVIDIA-Docker2](#nvidia-docker2) -* [__Running CARLA container__](#running-carla-container) +Users can pull an image based on a CARLA release to run in a Docker container. This is useful for users who: -This tutorial is designed for: +- Want to run CARLA without needing to install all dependencies +- Run multiple CARLA servers and perform GPU mapping +- Run the CARLA server without a display -* People that want to run CARLA without needing to install all dependencies. -* Recommended solution to run multiple CARLA servers and perform GPU mapping. -* People who don't need to render the full simulation (the server is headless). - -This tutorial was tested in Ubuntu 16.04 and using NVIDIA 396.37 drivers. -This method requires a version of NVIDIA drivers >=390. +This tutorial explains the requirements to run the CARLA image and how to run the image with both OpenGL and Vulkan graphics APIs. +- [__Before you begin__](#before-you-begin) +- [__Running CARLA in a container__](#running-carla-in-a-container) +- [__Off-screen mode__](#off-screen-mode) --- -## Docker Installation +## Before you begin + +You will need to have installed: + +- __Docker:__ Follow the installation instructions [here](https://docs.docker.com/engine/install/). +- __NVIDIA Container Toolkit:__ The NVIDIA Container Toolkit is a library and toolset that exposes NVIDIA graphics devices to Linux containers. It is designed specifically for Linux containers running on Linux host systems or within Linux distributions under version 2 of the Windows Subsystem for Linux. Install the `nvidia-docker2` package by following the instructions [here](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/install-guide.html#installation-guide). !!! note - Docker requires sudo to run. Follow this guide to add users to the docker sudo - group - -### Docker CE - -For our tests we used the Docker CE version. -To install Docker CE we recommend using [this tutorial][tutoriallink] - -[tutoriallink]: https://docs.docker.com/install/linux/docker-ce/ubuntu/#extra-steps-for-aufs - -### NVIDIA-Docker2 - -To install nvidia-docker-2 we recommend using the "Quick Start" section from the [nvidia-dockers github](https://github.com/NVIDIA/nvidia-docker). + Docker requires sudo to run. Follow [this guide](https://docs.docker.com/install/linux/linux-postinstall/) to add users to the docker sudo group. --- -## Running CARLA container +## Running CARLA in a container -Pull the CARLA image. +__1. Pull the CARLA image.__ + +You can pull either the latest CARLA image or a specific release version. The latest image refers to the most [recent packaged release](https://github.com/carla-simulator/carla/releases). To pull the image, run one of the following commands: ```sh -docker pull carlasim/carla:version +# Pull the latest image +docker pull carlasim/carla:latest + +# Pull a specific version +docker pull carlasim/carla:0.9.12 ``` -For selecting a version, for instance, version 0.8.2 (stable), do: +__2. Run the CARLA container.__ + +Different versions of CARLA support different graphics APIs which can affect the conditions in which the Docker image can run: + +- 0.9.12 supports only Vulkan +- 0.9.7+ supports both Vulkan and OpenGL. + + +__CARLA 0.9.12__ + +To run CARLA with a display: + +``` +sudo docker run --privileged --gpus all --net=host -e DISPLAY=$DISPLAY carlasim/carla:0.9.12 /bin/bash ./CarlaUE4.sh +``` + +To run CARLA in off-screen mode: + +``` +sudo docker run --privileged --gpus all --net=host -v /tmp/.X11-unix:/tmp/.X11-unix:rw carlasim/carla:0.9.12 /bin/bash ./CarlaUE4.sh -RenderOffScreen +``` + +__CARLA 0.9.7 to 0.9.11__ + +To run CARLA using Vulkan: ```sh -docker pull carlasim/carla:0.8.2 +sudo docker run --privileged --gpus all --net=host -e DISPLAY=$DISPLAY -e SDL_VIDEODRIVER=x11 -v /tmp/.X11-unix:/tmp/.X11-unix:rw carlasim/carla:0.9.11 /bin/bash ./CarlaUE4.sh -vulkan <-additonal-carla-flags> ``` -Running CARLA under docker. +!!! Note + This command will allow you to run the CARLA image with Vulkan as long as your machine has a display. See the [rendering documentation](adv_rendering_options.md#off-screen-mode) for information on running with Vulkan in off-screen mode. + +To run CARLA using OpenGL: ```sh -docker run -p 2000-2002:2000-2002 --runtime=nvidia --gpus all carlasim/carla:0.8.4 +docker run -e DISPLAY=$DISPLAY --net=host --gpus all --runtime=nvidia carlasim/carla: /bin/bash CarlaUE4.sh -opengl <-additonal-carla-flags> ``` -The `-p 2000-2002:2000-2002` argument is to redirect host ports for the docker container. -Use `--gpus '"device=,"'` to specify which GPUs should run CARLA. Take a look at this [NVIDIA documentation](https://github.com/NVIDIA/nvidia-docker) to learn other syntax options. +__3. (Optional) Configure Docker flags.__ -You can also pass parameters to the CARLA executable. With this you can chose the town and select the port that is going to be used. +The above commands use some Docker flags that can be configured according to your needs: -```sh -docker run -p 2000-2002:2000-2002 --runtime=nvidia -e NVIDIA_VISIBLE_DEVICES=0 carlasim/carla:0.8.4 /bin/bash CarlaUE4.sh < Your list of parameters > -``` +- __Networking:__ The [`--net=host`](https://docs.docker.com/engine/reference/run/#network-settings) argument will allow the container to share the host's entire network. If you prefer to [map specific ports](https://docs.docker.com/engine/reference/run/#expose-incoming-ports) on the host machine to container ports, use the flag `-p :`. +- __GPUs:__ You can choose to use all GPUs with `--gpus all`, or target specific GPUs with `--gpus '"device=,"'`. See [here](https://docs.docker.com/config/containers/resource_constraints/#gpu) for more information. -At the list of parameters do not forget to add `-world-port=` so that CARLA runs on server mode listening to the ``. +--- + +## Off-screen mode + +OpenGL requires no configuration if you are running CARLA on a machine without a display, however you will need to perform some extra steps to do the same using Vulkan prior to CARLA 0.9.12. See the [rendering documentation](adv_rendering_options.md#off-screen-mode) for information. + +--- + +Any issues or doubts related with this topic can be posted in the CARLA forum. + + 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; } +