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

Typo fixes in TM docs and corrected default radius of set_hybrid_physics_radius

This commit is contained in:
corkyw10 2021-03-16 16:44:31 +01:00 committed by Corinne
parent 492b477ae0
commit 483107f7f6
3 changed files with 50 additions and 51 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

97
Docs/adv_traffic_manager.md
View File

@ -29,13 +29,13 @@
--- ---
## What is it? ## What is it?
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 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 accounts for the rest by considering them unregistered.
### Structured design ### 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. 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 stages. Information flows only in one direction.
### User customization ### 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 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.
--- ---
## Architecture ## Architecture
@ -45,22 +45,21 @@ Users must have some control over the traffic flow by setting parameters that al
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. 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 detail in the following sections. A simplified overview of the logic is as follows:
Nevertheless, the logic of it can be simplified as follows.
__1. Store and update the current state of the simulation.__ __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. First of all, the [ALSM](#alsm) (Agent Lifecycle & State Management) 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 then passed to the [stages](#stages). In such way, calls to the server are isolated in the ALSM, and this 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. Calculate the movement of every registered vehicle.__ __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. 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 separately. 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.1 - [Localization Stage](#stage-1-localization-stage).__
     __2.2 - [Collision Stage](#stage-2-collision-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 accessed easily 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. 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).__ >__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. 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).__ >__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. 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.
__3. Apply the commands in the simulation.__ __3. Apply the commands in the simulation.__
@ -94,8 +93,8 @@ __Related .cpp files:__ `TrafficManagerLocal.cpp`.
Manages the process of calculating the next command for all the registered vehicles, so that these are done in synchrony. 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. * 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. * Loops over said array, performing calculations per vehicle separately.
* These calculations are divided in a series of [stages](#stages). * These calculations are divided into 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. * 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. * 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. * 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.
@ -107,7 +106,7 @@ __Related .cpp files:__ `TrafficManagerLocal.cpp`.
Helper module contained by the [PBVT](#pbvt) and used during the [Localization Stage](#stage-1-localization-stage). 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. * 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... * Includes waypoints in a specific data structure with more information to connect waypoints and identify roads, junctions, etc.
* Identifies these structures with an ID that is used to quickly spot vehicles in nearby areas. * Identifies these structures with an ID that is used to quickly spot vehicles in nearby areas.
__Related .cpp files:__ `InMemoryMap.cpp` and `SimpleWaypoint.cpp`. __Related .cpp files:__ `InMemoryMap.cpp` and `SimpleWaypoint.cpp`.
@ -116,9 +115,9 @@ __Related .cpp files:__ `InMemoryMap.cpp` and `SimpleWaypoint.cpp`.
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). 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. * Contains a map of deque objects with one entry per vehicle.
* For each vehicle, contains a set of waypoints describing its current location and near-future path. * 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. * 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 ### PID controller
@ -131,9 +130,9 @@ __Related .cpp files:__ `PIDController.cpp`.
### Simulation state ### Simulation state
Stores information about the vehicles in the world so that it can be easily accessible during all the process. Stores information about the vehicles in the world so that it can be easily accessed during the whole 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. * 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 whether these vehicles are under the influence of a traffic light and what the current state of that traffic light is.
* Stores in cache all the information so that no additional calls to the server are needed during the [control loop](#control-loop). * 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`. __Related .cpp files:__ `SimulationState.cpp`, `SimulationState.h`.
@ -144,11 +143,11 @@ __Related .cpp files:__ `SimulationState.cpp`, `SimulationState.h`.
First stage in the [control loop](#control-loop). Defines a near-future path for registered vehicles. 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). * Obtains the position and velocity of all the vehicles from the [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. * 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 the list will be.
* The path is updated according to planning decisions such as lane changes, speed limit, distance to leading vehicle parameterization, etc. * 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. * 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). * These paths are compared with each other, in order to estimate possible collision situations. Results are passed to the Colllision Stage.
__Related .cpp files:__ `LocalizationStage.cpp` and `LocalizationUtils.cpp`. __Related .cpp files:__ `LocalizationStage.cpp` and `LocalizationUtils.cpp`.
@ -156,7 +155,7 @@ __Related .cpp files:__ `LocalizationStage.cpp` and `LocalizationUtils.cpp`.
Second stage in the [control loop](#control-loop). Triggers collision hazards. 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). * Receives a list of pairs of vehicles with possible overlapping paths from the 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. * 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. * Hazards for all the possible collisions will be sent to the [Motion Planner Stage](#stage-4-motion-planner-stage) to modify the path accordingly.
@ -166,8 +165,8 @@ __Related .cpp files:__ `CollisionStage.cpp`.
Third stage in the [control loop](#control-loop). Triggers hazards to follow traffic regulations such as traffic lights, stop signs, and priority at junctions. 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 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. * 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`. __Related .cpp files:__ `TrafficLightStage.cpp`.
@ -175,8 +174,8 @@ __Related .cpp files:__ `TrafficLightStage.cpp`.
Fourth and last stage in the [control loop](#control-loop). Generates the CARLA command that will be applied to the vehicle. 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)). * Gathers all the information so far: position and velocity of the vehicles ([simulation state](#simulation-state)), their path ([PBVT](#pbvt)) and 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. * Makes high-level decisions about how the 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) that can be applied to the vehicle. * 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). * Sends the resulting CARLA commands to the [command array](#command-array).
@ -198,17 +197,17 @@ __Related .cpp files:__ `MotionPlannerStage.cpp`.
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: 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:
* __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 are not goal-oriented,__ they follow a trajectory and whenever approaching a junction, choose a path randomly. Their path is endless and they will never stop roaming around the city.
* __Vehicles' target speed is 70% their current speed limit:__ unless any other value is set. * __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. * __Junction priority does not follow traffic regulations.__ The TM uses its own priority system 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.
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. 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). Here is a general summary of what the current possibilities are.
| Topic | Description | | Topic | Description |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **General:** | <br> **1\.** Use a carla.Client to create a TM instance connected to a port.<br> **2\.** Retrieve the port where a TM is connected. | | **General:** | <br> **1\.** Use a carla.Client to create a TM instance connected to a port.<br> **2\.** Retrieve the port where a TM is connected. |
| **Safety conditions:** | <br> **1\.** Set a minimum distance between stopped vehicles (for a vehicle or all of them). This will affect the minimum moving distance. <br> **2\.** Set an intended speed regarding current speed limitation (for a vehicle or all of them). <br> **3\.** Reset traffic lights. | | **Safety conditions:** | <br> **1\.** Set a minimum distance between stopped vehicles (for a single vehicle or for all of them). This will affect the minimum moving distance. <br> **2\.** Set an intended speed regarding current speed limitation (for a single vehicle or for all of them). <br> **3\.** Reset traffic lights. |
| **Collision managing:** | <br> **1\.** Enable/Disable collisions between a vehicle and a specific actor. <br> **2\.** Make a vehicle ignore all the other vehicles. <br> **3\.** Make a vehicle ignore all the walkers. <br>**4\.** Make a vehicle ignore all the traffic lights. | | **Collision managing:** | <br> **1\.** Enable/Disable collisions between a vehicle and a specific actor. <br> **2\.** Make a vehicle ignore all other vehicles. <br> **3\.** Make a vehicle ignore all walkers. <br>**4\.** Make a vehicle ignore all traffic lights. |
| **Lane changes:** | <br> **1\.** Force a lane change disregarding possible collisions. <br> **2\.** Enable/Disable lane changes for a vehicle. | | **Lane changes:** | <br> **1\.** Force a lane change disregarding possible collisions. <br> **2\.** Enable/Disable lane changes for a vehicle. |
| **Hybrid physics mode:** | <br> **1\.** Enable/Disable the hybrid physics mode. <br> **2\.** Change the radius where physics are enabled. | | **Hybrid physics mode:** | <br> **1\.** Enable/Disable the hybrid physics mode. <br> **2\.** Change the radius where physics are enabled. |
<br> <br>
@ -231,9 +230,9 @@ tm_port = tm.get_port()
v.set_autopilot(True,tm_port) v.set_autopilot(True,tm_port)
``` ```
!!! Note !!! 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. In multiclient situations, creating or connecting to a TM is not that straightforward. Take a look at the [*Running multiple Traffic Managers*](#running-multiple-traffic-managers) section to learn more about this.
The script `spawn_npc.py` in `/PythonAPI/examples` creates a TM instance in the port passed as argument and registers every vehicle spawned to it by setting the autopilot to True on a batch. The script `spawn_npc.py` in `/PythonAPI/examples` creates a TM instance in the port passed as an argument and registers every vehicle spawned to it by setting the autopilot to True on a batch.
```py ```py
traffic_manager = client.get_trafficmanager(args.tm-port) traffic_manager = client.get_trafficmanager(args.tm-port)
@ -274,8 +273,8 @@ for v in my_vehicles:
### Stopping a Traffic Manager ### 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. The TM is not an actor that needs to be destroyed, it will stop when the corresponding client stops. 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. However, it is important that when shutting down a TM, the vehicles registered to it are destroyed. Otherwise, they will stop in place, as no one will be conducting them. The script `spawn_npc.py` does this automatically.
!!! Warning !!! 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). 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).
@ -309,17 +308,17 @@ python3 spawn_npc.py -n 50 --sync --seed 9
--- ---
## Hybrid physics mode ## 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. 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. This guarantees that when a vehicle enables or disables its physics, the transition is fluid.
The hybrid mode is disabled by default. There are two ways to enable it. The hybrid mode is disabled by default. There are two ways 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. * [__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. * __Running `spawn_npc.py` with the flag `--hybrid`__ — The vehicles spawned will be registered to a Traffic Manager stated inside the script, and this will run with the hybrid physics on.
The are two parameters ruling the hybrid mode. One is the __radius__ that states the proximity area around any ego vehicle where physics are enabled. The other is the __vehicle__ with , that will act as center of this radius. There are two parameters ruling the hybrid mode:
* __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_physics_radius(r)](python_api.md#carla.TrafficManager.set_hybrid_physics_radius). * __Radius__ *(default = 50 meters)* — States the proximity area around the ego vehicle where physics are enabled. The value can be changed via [traffic_manager.set_hybrid_physics_radius(r)](python_api.md#carla.TrafficManager.set_hybrid_physics_radius).
* __Ego vehicle__ — A vehicle tagged with `role_name='hero'` that will act of the radius. * __Ego vehicle__ — A vehicle tagged with `role_name='hero'` that will act as the center of the radius.
* __If there is none,__ all the vehicles will disable physics. * __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. * __If there are many,__ the radius will be considered for all of them. That will create different areas of influence with physics enabled.
@ -333,9 +332,9 @@ The following example shows how the physics are enabled and disabled when hybrid
### Definitions ### Definitions
When working with different clients containing different TM, understanding inner implementation of the TM in the client-server architecture becomes specially relevant. There is one ruling these scenarios: __the port is the key__. When working with different clients containing different TMs, understanding the inner implementation of the TM in the client-server architecture becomes especially relevant. There is one key to ruling these scenarios: __the port__.
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`. A client creates a TM by communicating with the server and passing the intended port to be used for that purpose. The port can either be stated or not, using the default of `8000`.
* __TM-Server__ — The port is free. This type of TM is in charge of its own logic, managed in `TrafficManagerLocal.cpp`. The following code creates two TM-Servers. Each one connects to a different port, not previously used. * __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.
@ -347,7 +346,7 @@ tm01 = client01.get_trafficmanager() # tm01 --> tm01 (p=8000)
tm02 = client02.get_trafficmanager(5000) # tm02(p=5000) --> tm02 (p=5000) 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__ — The port is occupied by another TM. These instances are not in charge of their own logic. Instead, they ask for changes in the parameters of the __TM-Server__ they are connected to in `TrafficManagerRemote.cpp`. The following code creates two TM-Clients, that connect with the TM-Servers previously created.
```py ```py
tm03 = client03.get_trafficmanager() # tm03 --> tm01 (p=8000). tm03 = client03.get_trafficmanager() # tm03 --> tm01 (p=8000).
@ -359,7 +358,7 @@ tm04 = client04.get_trafficmanager(5000) # tm04(p=5000) --> tm02 (p=5000)
!!! Important !!! 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. 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 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__. The CARLA server keeps a register of all the TM instances internally by storing the port and 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__.
!!! Note !!! Note
The class `TrafficManager.cpp` acts as a central hub managing all the different TM instances. The class `TrafficManager.cpp` acts as a central hub managing all the different TM instances.
@ -395,13 +394,13 @@ terminal 4: python3 spawn_npc.py --port 5000 --tm-port 5050 # TM-Server B connec
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 multisimulation is independent from the Traffic Manager itself. The example above runs two CARLA simulations in parallel, A and B. In each of them, a TM-Server is created independently from the other. Simulation A could run a Multiclient TM while simulation B is running a MultiTM, or no TM at all.
The only possible issue arising from this is a client trying to connect to an already existing TM which is not running on the selected simulation. In case this happens, an error message will appear and the connection will be aborted, to prevent interferences between simulations. The only possible issue arising from this is a client trying to connect to an already existing TM which is not running on the selected simulation. In case this happens, an error message will appear and the connection will be aborted to prevent interferences between simulations.
--- ---
## Other considerations ## Other considerations
The TM is a module constantly evolving and trying to adapt the range of possibilities that it presents. For instance, in order to get more realistic behaviours we can have many clients with different TM in charge of sets of vehicles with specific and distinct behaviours. This range of possibilities also makes for a lot of different configurations that can get really complex and specific. For such reason, here are listed of considerations that should be taken into account when working with the TM as it is by the time of writing. 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 this reason, the following are considerations that should be taken into account when working with the TM:
### Synchronous mode ### Synchronous mode

2
Docs/python_api.md
View File

@ -2138,7 +2138,7 @@ Sets the minimum distance in meters that vehicles have to keep with the rest. Th
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. 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:** - **Parameters:**
- `enabled` (_bool_) – If __True__, enables the hybrid physics. - `enabled` (_bool_) – If __True__, enables the hybrid physics.
- <a name="carla.TrafficManager.set_hybrid_physics_radius"></a>**<font color="#7fb800">set_hybrid_physics_radius</font>**(<font color="#00a6ed">**self**</font>, <font color="#00a6ed">**r**=70.0</font>) - <a name="carla.TrafficManager.set_hybrid_physics_radius"></a>**<font color="#7fb800">set_hybrid_physics_radius</font>**(<font color="#00a6ed">**self**</font>, <font color="#00a6ed">**r**=50.0</font>)
With hybrid physics on, changes the radius of the area of influence where physics are enabled. With hybrid physics on, changes the radius of the area of influence where physics are enabled.
- **Parameters:** - **Parameters:**
- `r` (_float<small> – meters</small>_) – New radius where physics are enabled. - `r` (_float<small> – meters</small>_) – New radius where physics are enabled.

2
PythonAPI/docs/client.yml
View File

@ -471,7 +471,7 @@
params: params:
- param_name: r - param_name: r
type: float type: float
default: 70.0 default: 50.0
param_units: meters param_units: meters
doc: > doc: >
New radius where physics are enabled. New radius where physics are enabled.