New iteration on Jacopo comments.
This commit is contained in:
sergi-e
Marc Garcia Puig
parent
807c20d3df
commit
db0e95cc1e
|
|
@ -339,11 +339,11 @@ Executes a list of commands on a single simulation step and retrieves no informa
|
|||
[ApplyImpulse](#command.ApplyImpulse)
|
||||
[SetSimulatePhysics](#command.SetSimulatePhysics)
|
||||
[SetAutopilot](#command.SetAutopilot).
|
||||
- <a name="carla.Client.apply_batch_sync"></a>**<font color="#7fb800">apply_batch_sync</font>**(<font color="#00a6ed">**self**</font>, <font color="#00a6ed">**commands**</font>, <font color="#00a6ed">**due_tick_cue**</font>)
|
||||
- <a name="carla.Client.apply_batch_sync"></a>**<font color="#7fb800">apply_batch_sync</font>**(<font color="#00a6ed">**self**</font>, <font color="#00a6ed">**commands**</font>, <font color="#00a6ed">**due_tick_cue**=False</font>)
|
||||
Executes a list of commands on a single simulation step, blocks until the commands are linked, and returns a list of <b>command.Response</b> 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.
|
||||
- **Parameters:**
|
||||
- `commands` (_list_) – A list of commands to execute in batch. The commands available are listed right above, in the function **<font color="#7fb800">apply_batch()</font>**.
|
||||
- `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_.
|
||||
- `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.
|
||||
- **Return:** _list(command.Response)_
|
||||
- <a name="carla.Client.get_available_maps"></a>**<font color="#7fb800">get_available_maps</font>**(<font color="#00a6ed">**self**</font>)
|
||||
Returns a list of strings containing the paths of the maps available on server. These paths are dynamic, they will be created during the simulation and so you will not find them when looking up in your files. One of the possible returns for this method would be:
|
||||
|
|
@ -1314,57 +1314,54 @@ Forces a vehicle to change either to the lane on its left or right, if existing,
|
|||
- **Parameters:**
|
||||
- `actor` (_[carla.Actor](#carla.Actor)_) – Vehicle being forced to change lanes.
|
||||
- `direction` (_bool_) – Destination lane. __True__ is the one on the left and __False__ is the right one.
|
||||
- <a name="carla.TrafficManager.ignore_actors_percentage"></a>**<font color="#7fb800">ignore_actors_percentage</font>**(<font color="#00a6ed">**self**</font>, <font color="#00a6ed">**actor**</font>, <font color="#00a6ed">**perc**</font>)
|
||||
During the collision detection stage, which runs every frame, this method sets a percent chance that collisions will be ignored for a vehicle.
|
||||
- <a name="carla.TrafficManager.ignore_vehicles_percentage"></a>**<font color="#7fb800">ignore_vehicles_percentage</font>**(<font color="#00a6ed">**self**</font>, <font color="#00a6ed">**actor**</font>, <font color="#00a6ed">**perc**</font>)
|
||||
During the collision detection stage, which runs every frame, this method sets a percent chance that collisions with another vehicle will be ignored for a vehicle.
|
||||
- **Parameters:**
|
||||
- `actor` (_[carla.Actor](#carla.Actor)_) – The vehicle that is going to ignore others.
|
||||
- `actor` (_[carla.Actor](#carla.Actor)_) – The vehicle that is going to ignore other vehicles.
|
||||
- `perc` (_float_) – Between 0 and 100. Amount of times collisions will be ignored.
|
||||
- <a name="carla.TrafficManager.ignore_walkers_percentage"></a>**<font color="#7fb800">ignore_walkers_percentage</font>**(<font color="#00a6ed">**self**</font>, <font color="#00a6ed">**actor**</font>, <font color="#00a6ed">**perc**</font>)
|
||||
During the collision detection stage, which runs every frame, this method sets a percent chance that collisions with walkers will be ignored for a vehicle.
|
||||
- **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.
|
||||
- <a name="carla.TrafficManager.ignore_lights_percentage"></a>**<font color="#7fb800">ignore_lights_percentage</font>**(<font color="#00a6ed">**self**</font>, <font color="#00a6ed">**actor**</font>, <font color="#00a6ed">**perc**</font>)
|
||||
During the traffic light stage, which runs every frame, this method sets the percent chance that traffic lights will be ignored for a vehicle.
|
||||
- **Parameters:**
|
||||
- `actor` (_[carla.Actor](#carla.Actor)_) – The actor that is going to ignore traffic lights.
|
||||
- `perc` (_float_) – Between 0 and 100. Amount of times traffic lights will be ignored.
|
||||
- <a name="carla.TrafficManager.register_vehicles"></a>**<font color="#7fb800">register_vehicles</font>**(<font color="#00a6ed">**self**</font>, <font color="#00a6ed">**actor_list**</font>)
|
||||
Registers a series of vehicles to a traffic manager that will conduct them.
|
||||
- **Parameters:**
|
||||
- `actor_list` (_list([carla.Actor](#carla.Actor))_) – List of vehicles to register.
|
||||
- <a name="carla.TrafficManager.reset_traffic_lights"></a>**<font color="#7fb800">reset_traffic_lights</font>**(<font color="#00a6ed">**self**</font>)
|
||||
Resets every traffic light in the map to its initial state.
|
||||
- <a name="carla.TrafficManager.set_auto_lane_change"></a>**<font color="#7fb800">set_auto_lane_change</font>**(<font color="#00a6ed">**self**</font>, <font color="#00a6ed">**actor**</font>, <font color="#00a6ed">**enable**</font>)
|
||||
- <a name="carla.TrafficManager.auto_lane_change"></a>**<font color="#7fb800">auto_lane_change</font>**(<font color="#00a6ed">**self**</font>, <font color="#00a6ed">**actor**</font>, <font color="#00a6ed">**enable**</font>)
|
||||
Turns on or off lane changing behaviour for a vehicle.
|
||||
- **Parameters:**
|
||||
- `actor` (_[carla.Actor](#carla.Actor)_) – The vehicle whose settings are changed.
|
||||
- `enable` (_bool_) – __True__ is default and enables lane changes. __False__ will disable them.
|
||||
- <a name="carla.TrafficManager.set_distance_to_leading_vehicle"></a>**<font color="#7fb800">set_distance_to_leading_vehicle</font>**(<font color="#00a6ed">**self**</font>, <font color="#00a6ed">**actor**</font>, <font color="#00a6ed">**distance**</font>)
|
||||
- <a name="carla.TrafficManager.distance_to_leading_vehicle"></a>**<font color="#7fb800">distance_to_leading_vehicle</font>**(<font color="#00a6ed">**self**</font>, <font color="#00a6ed">**actor**</font>, <font color="#00a6ed">**distance**</font>)
|
||||
Sets the minimum distance in meters that a vehicle has to keep with the others. The distance is in meters and will affect the minimum moving distance. It is computed from front to back of the vehicle objects.
|
||||
- **Parameters:**
|
||||
- `actor` (_[carla.Actor](#carla.Actor)_) – Vehicle whose minimum distance is being changed.
|
||||
- `distance` (_float_) – Meters between both vehicles.
|
||||
- <a name="carla.TrafficManager.set_collision_detection"></a>**<font color="#7fb800">set_collision_detection</font>**(<font color="#00a6ed">**self**</font>, <font color="#00a6ed">**reference_actor**</font>, <font color="#00a6ed">**other_actor**</font>, <font color="#00a6ed">**detect_collision**</font>)
|
||||
- <a name="carla.TrafficManager.collision_detection"></a>**<font color="#7fb800">collision_detection</font>**(<font color="#00a6ed">**self**</font>, <font color="#00a6ed">**reference_actor**</font>, <font color="#00a6ed">**other_actor**</font>, <font color="#00a6ed">**detect_collision**</font>)
|
||||
Tunes on/off collisions between a vehicle and another specific actor. In order to ignore all other vehicles, traffic lights or walkers, use the specific __ignore__ methods described in this same section.
|
||||
- **Parameters:**
|
||||
- `reference_actor` (_[carla.Actor](#carla.Actor)_) – Vehicle that is going to ignore collisions.
|
||||
- `other_actor` (_[carla.Actor](#carla.Actor)_) – The actor that `reference_actor` is going to ignore collisions with.
|
||||
- `detect_collision` (_bool_) – __True__ is default and enables collisions. __False will disable them.
|
||||
- <a name="carla.TrafficManager.set_global_max_speed_difference"></a>**<font color="#7fb800">set_global_max_speed_difference</font>**(<font color="#00a6ed">**self**</font>, <font color="#00a6ed">**percentage**</font>)
|
||||
- <a name="carla.TrafficManager.global_percentage_speed_difference"></a>**<font color="#7fb800">global_percentage_speed_difference</font>**(<font color="#00a6ed">**self**</font>, <font color="#00a6ed">**percentage**</font>)
|
||||
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.
|
||||
- **Parameters:**
|
||||
- `percentage` (_float_) – Percentage difference between intended speed and the current limit.
|
||||
- <a name="carla.TrafficManager.set_global_distance_to_leading_vehicle"></a>**<font color="#7fb800">set_global_distance_to_leading_vehicle</font>**(<font color="#00a6ed">**self**</font>, <font color="#00a6ed">**distance**</font>)
|
||||
- <a name="carla.TrafficManager.global_distance_to_leading_vehicle"></a>**<font color="#7fb800">global_distance_to_leading_vehicle</font>**(<font color="#00a6ed">**self**</font>, <font color="#00a6ed">**distance**</font>)
|
||||
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 between vehicles.
|
||||
- <a name="carla.TrafficManager.set_vehicle_max_speed_difference"></a>**<font color="#7fb800">set_vehicle_max_speed_difference</font>**(<font color="#00a6ed">**self**</font>, <font color="#00a6ed">**actor**</font>, <font color="#00a6ed">**percentage**</font>)
|
||||
- <a name="carla.TrafficManager.vehicle_percentage_speed_difference"></a>**<font color="#7fb800">vehicle_percentage_speed_difference</font>**(<font color="#00a6ed">**self**</font>, <font color="#00a6ed">**actor**</font>, <font color="#00a6ed">**percentage**</font>)
|
||||
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.
|
||||
- **Parameters:**
|
||||
- `actor` (_[carla.Actor](#carla.Actor)_) – Vehicle whose speed behaviour is being changed.
|
||||
- `percentage` (_float_) – Percentage difference between intended speed and the current limit.
|
||||
- <a name="carla.TrafficManager.unregister_vehicles"></a>**<font color="#7fb800">unregister_vehicles</font>**(<font color="#00a6ed">**self**</font>, <font color="#00a6ed">**actor_list**</font>)
|
||||
Deletes a series of vehicles from the traffic manager's registered list to stop conducting them.
|
||||
- **Parameters:**
|
||||
- `actor_list` (_list([carla.Actor](#carla.Actor))_) – List of vehicles to be unregistered.
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,69 +1,78 @@
|
|||
<h1>Traffic manager</h1>
|
||||
# Traffic Manager
|
||||
* [__What is it?__](#what-is-it)
|
||||
* [__How does it work?__](#how-does-it-work)
|
||||
* Architecture
|
||||
* Stages
|
||||
* [__Using the traffic manager__](#using-the-traffic-manager)
|
||||
* [__Using the Traffic Manager__](#using-the-traffic-manager)
|
||||
* Parameters
|
||||
* Creating a traffic manager
|
||||
* Setting the traffic manager
|
||||
* Creating a Traffic Manager
|
||||
* Setting the Traffic Manager
|
||||
* [__Other considerations__](#other-considerations)
|
||||
* FPS limitations
|
||||
* Multiclient management
|
||||
* [__Summary__](#summary)
|
||||
|
||||
---------------
|
||||
##What is it?
|
||||
---
|
||||
## What is it?
|
||||
|
||||
The traffic manager is a module built on top of the CARLA API in C++ that handles any group of vehicles set to autopilot mode. The goal is to populate the simulation with realistic urban traffic conditions and give the chance to user to customize some behaviours to set specific learning circumstances. To do so, every traffic manager has two lists, one for registered and another for unregistered vehicles, that make it aware of the current traffic state. When a client sets a vehicle to autopilot, it is added to the registered list of the traffic manager said client is connected to.
|
||||
The traffic manager is based on two ground principles:
|
||||
The Traffic Manager (TM for short) is a module built on top of the CARLA API in C++ that handles any group of vehicles set to autopilot mode. The goal is to populate the simulation with realistic urban traffic conditions and give the chance to user to customize some behaviours, for example to set specific learning circumstances. To do so, 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 is based on two ground principles:
|
||||
|
||||
<h4>Structured design</h4>
|
||||
The traffic manager is built on the client-side of the CARLA architecture, in order to save the server some work and not interfere with the simulation performance. For said reason, the flow of execution is divided in __stages__ that help improving computational efficiency and provide stage-related data structures that vehicles can share to communicate. This clear distintion between different sub-modules inside the traffic manager that are accessed independently is central to the whole manager. It avoids potential bottlenecks in managing collisions and allows negotiation between cars.
|
||||
#### Structured design
|
||||
The TM is built on the client-side of the CARLA architecture, in order to save the server some work and not interfere with the simulation performance. For said reason, the flow of execution is divided in __stages__ that help improving computational efficiency and provide stage-related data structures that vehicles can share to communicate. This clear distintion between different sub-modules inside the TM that are accessed independently is central to the whole manager. It avoids potential bottlenecks in managing collisions and allows negotiation between cars.
|
||||
|
||||
<h4>User customization</h4>
|
||||
#### User customization
|
||||
Users need to be granted some control by setting parameters that allow, force or encourage certain behaviours. Thus, 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, specially to train driving systems under specific and atypical circumstances.
|
||||
|
||||
---------------
|
||||
##How does it work?
|
||||
---
|
||||
## How does it work?
|
||||
|
||||
<h4>Architecture</h4>
|
||||
The inner structure is divided in stages can be somehow visualized through code, they have their equivalent in the c++ code (.cpp files) foun inside `/libcarla`. There are other inner parts of the traffic manager, such as as setting up the map, but they are managed internally and mostly only done once, so these are not as fundamental to understand the whole.
|
||||
#### Architecture
|
||||
The inner structure is divided in stages can be somehow visualized through code, they have their equivalent in the c++ code (.cpp files) foun inside `/libcarla`. There are other inner parts of the TM, such as as setting up the map, but they are managed internally and mostly only done once, so these are not as fundamental to understand the whole.
|
||||
Each stage class runs on a different thread and has its independent operations and goals. Communication with the rest is managed through messages facilitating synchronous messaging between the different stages. The information flows only in one direction. In this way, for each stage or class there are methods and tools that can be located in one or many stages with a very specific structure and purpose.
|
||||
The following diagram is a summary of the internal architecture of the traffic manager. Main bodies are the different stages, blue arrows represent messenger classes that facilitate __asynchronous communication?__, __black arrows represent non-concurrent data flow__.
|
||||
The following diagram is a summary of the internal architecture of the Traffic Manager. Main bodies are the different stages, blue arrows represent messenger classes that facilitate __asynchronous communication?__, __black arrows represent non-concurrent data flow__.
|
||||
|
||||
<div style="text-align:center">
|
||||
<img src="../img/traffic_manager_diagram.png">
|
||||
</div>
|
||||
|
||||
<h4>Stages</h4>
|
||||
#### Stages
|
||||
|
||||
1. __Localization Stage:__ For each vehicle registered to the traffic manager, maintains a list of waypoints ahead it to follow. The buffer list of waypoints is not created every iteration but updated. The buffer is deleted though when lane changes are applied to create a new one with the corresponding trajectory. The amount of waypoints contained in said list varies depending on the vehicle's speed, being greater the faster it goes. The localization stage contains a __spacial hashing__ which summarizes the position for every car __registered to the traffic manager in a world grid__. This is a way to roughly predict possible collisions and create a list of overlapping actors that will be later used by the next stage.
|
||||
__1. Localization Stage:__ For each vehicle registered to the TM, maintains a list of waypoints ahead it to follow. The buffer list of waypoints is not created every iteration but updated. The buffer is deleted though when lane changes are applied to create a new one with the corresponding trajectory. The amount of waypoints contained in said list varies depending on the vehicle's speed, being greater the faster it goes. The localization stage contains a __spacial hashing__ which summarizes the position for every car __registered to the Traffic Manager in a world grid__. This is a way to roughly predict possible collisions and create a list of overlapping actors for every vehicle that will be later used by the next stage.
|
||||
|
||||
2. __Collision Stage:__ Checks possible collisions for every vehicle. For each pairs of overlapping actors in the list contained by the localization stage, it extends a __geodesic boundary__. These are extended bounding bodies that represent the vehicle along its trajectory. Collisions between two geodesic boundaries are communicated to the __Motion planner stage__ that will manage them.
|
||||
* __Related .cpp files:__ `LocalizationStage.cpp`.
|
||||
|
||||
3. __Traffic Light Stage:__ Manages some general traffic regulations, mainly priority at junctions. Whenever there is a traffic light, if red, a __traffic hazard__ is set to true. Non signaled junctions are managed with a ticket system. When coming closer to these, a __geodesic boundary__ is extended through the intersection along the vehicle's trajectory. If there is another vehicle inside of it, the parent waits for the junction to be free.
|
||||
__2. Collision Stage:__ Checks possible collisions for every vehicle. For each pairs of overlapping actors in the list contained by the localization stage, it extends a __geodesic boundary__. These are extended bounding bodies that represent the vehicle along its trajectory. Collisions between two geodesic boundaries are communicated to the __Motion planner stage__ that will manage them.
|
||||
|
||||
4. __Motion Planner Stage:__ Aggregates all the information gathered through the previous stages. Their guidance is adjusted with actuation signals provided by a PID controller, this stage makes decisions on how to move the vehicles. It computes all the commands needed for every vehicle and then send these to the final stage. For example, when facing a __traffic hazard__, this stage will compute the brake needed for said vehicle and communicate it to the apply control stage.
|
||||
* __Related .cpp files:__ `CollisionStage.cpp`.
|
||||
|
||||
5. __Apply Control Stage:__ Receives actuation signals (such as throttle, brake, steer) from the Motion planner stage and commands these to the simulator in batches to control every vehicles' movement. It mainly uses the __apply_batch()__ method in [carla.Client](../python_api/#carla.Client) and different [carla.VehicleControl](../python_api/#carla.Client) for the registered vehicles.
|
||||
__3. Traffic Light Stage:__ Manages some general traffic regulations, mainly priority at junctions. Whenever there is a traffic light, if red, a __traffic hazard__ is set to true. Non signaled junctions are managed with a ticket system. When coming closer to these, a __geodesic boundary__ is extended through the intersection along the vehicle's trajectory. If there is another vehicle inside of it, the parent waits for the junction to be free.
|
||||
|
||||
---------------
|
||||
##Using the traffic manager
|
||||
* __Related .cpp files:__ `TrafficLightStage.cpp`.
|
||||
|
||||
First of all there are some general behaviour patterns the traffic manager will generate that should be understood beforehand. These statements inherent to the way the traffic manager is implemented:
|
||||
__4. Motion Planner Stage:__ Aggregates all the information gathered through the previous stages. Their guidance is adjusted with actuation signals provided by a PID controller, this stage makes decisions on how to move the vehicles. It computes all the commands needed for every vehicle and then send these to the final stage. For example, when facing a __traffic hazard__, this stage will compute the brake needed for said vehicle and communicate it to the apply control stage.
|
||||
|
||||
* __Vehicles are not goal-oriented__ They follow a road and whenever a junction appears, choose a path randomly. Their path is endless and thus, will never stop roaming around the city.
|
||||
* __Vehicles' intended speed is 70% their current speed limit:__ Unless any other behaviour is set.
|
||||
* __Lane change is currently disabled:__ It can be enabled through the API, though right now some issues may happen. Disabling lane changes will also ban overtakings between vehicles in the same lane.
|
||||
* __Junction priority does not follow traffic regulations:__ The traffic manager has a ticket 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.
|
||||
* __Related .cpp files:__ `MotionPlannerStage.cpp`.
|
||||
|
||||
The traffic manager provides with a set of possibilities that can interfere with how the traffic is conducted or set specific rules for a vehicle. Thus, the user can aim for different behaviours in both a general and specific sense. 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.
|
||||
__5. Apply Control Stage:__ Receives actuation signals (such as throttle, brake, steer) from the Motion planner stage and commands these to the simulator in batches to control every vehicles' movement. It mainly uses the __apply_batch()__ method in [carla.Client](../python_api/#carla.Client) and different [carla.VehicleControl](../python_api/#carla.Client) for the registered vehicles.
|
||||
|
||||
__Traffic manager fundamental methods:__
|
||||
* __Related .cpp files:__ `BatchControlStage.cpp`.
|
||||
|
||||
* Get a traffic manager instance from a client.
|
||||
* Register/Unregister vehicles from the traffic manager's lists.
|
||||
## Using the Traffic Manager
|
||||
|
||||
First of all there are some general behaviour patterns the TM will generate that should be understood beforehand. These statements inherent to the way the TM is implemented:
|
||||
|
||||
* __Vehicles are not goal-oriented__ they follow a road and whenever a junction appears, choose a path randomly. Their path is endless and thus, will never stop roaming around the city.
|
||||
* __Vehicles' intended speed is 70% their current speed limit:__ unless any other behaviour is set.
|
||||
* __Lane change is currently disabled:__ it can be enabled through the API, though right now some issues may happen. Disabling lane changes will also ban overtakings between vehicles in the same lane.
|
||||
* __Junction priority does not follow traffic regulations:__ the TM has a ticket 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.
|
||||
|
||||
The Traffic Manager provides with a set of possibilities that can interfere with how the traffic is conducted or set specific rules for a vehicle. Thus, the user can aim for different behaviours in both a general and specific sense. 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.
|
||||
|
||||
__Traffic Manager fundamental methods:__
|
||||
|
||||
* Get a TM instance from a client.
|
||||
* Register/Unregister vehicles from the TM's lists.
|
||||
|
||||
__Safety conditions:__
|
||||
|
||||
|
|
@ -86,104 +95,97 @@ __Lane changes:__
|
|||
By default, vehicles will not ignore any Actor, drive at their current speed limit and leave 1 meter of safety distance between them.
|
||||
All of these properties can be easily managed as any other _set()_ method would.
|
||||
|
||||
<h4>Creating a traffic manager</h4>
|
||||
#### Creating a Traffic Manager
|
||||
|
||||
Traffic manager is contained inside the libcarla, so an instance of it can be received to then be accessed and configured. The traffic manager needs a client to run on, so when getting an instance, two elements are needed: the container client and the port that will be used to connect with it. Default port is `8000`.
|
||||
A TM instance can be created in any [carla.Client](python_api.md#carla.Client). To get it, two elements are needed: the container client and the port that will be used to connect with it. Default port is `8000`.
|
||||
|
||||
```python
|
||||
tm = client.GetTrafficManager(port)
|
||||
tm = client.get_trafficmanager(port)
|
||||
```
|
||||
|
||||
Now the traffic manager needs some vehicles to be in charge of. In order to do so, register a specific list of actors that should be conducted. Once registered, vehicles will automatically start their way:
|
||||
|
||||
```python
|
||||
tm.register_vehicles(vehicles_list)
|
||||
```
|
||||
Alternatively, if the autopilot is turned on for any vehicle, it will be automatically registered. In case the client is not connected to any traffic manager, an instance will be created with default presets.
|
||||
Now the TM needs some vehicles to be in charge of. In order to do so, enable the autopilot mode for every vehicle it is in charge of. In case the client is not connected to any TM, an instance will be created with default presets.
|
||||
|
||||
```python
|
||||
for v in vehicles_list:
|
||||
v.set_autopilot(True)
|
||||
```
|
||||
!!! Note
|
||||
In multiclient situations, creating or connecting to a traffic manager is not that straightforward. Take a look into the [other considerations](#other-considerations) section to learn more about this.
|
||||
In multiclient situations, creating or connecting to a TM is not that straightforward. Take a look into the [other considerations](#other-considerations) section to learn more about this.
|
||||
|
||||
There are two scripts in `/PythonAPI/examples` named as `spawn_npc` and `tm_spawn_npc` that connect to the traffic manager in different ways. Let's take a look at them for the sake of clarity:
|
||||
There is a script in `/PythonAPI/examples` named as `spawn_npc` that connects to the TM automatically when spawning vehicles:
|
||||
|
||||
* `spawn_npc`: Does not allow the user access to the traffic manager and so, it runs with default conditions. There is no explicit attempt to create an instance of the traffic manager with a specific port, so when the autopilot is set to __True__, it tries to connect with a traffic manager in default port `8000` and creates it in said client if it does not exist.
|
||||
* `spawn_npc`: does not allow the user access to the TM and so, runs it with default conditions. There is no explicit attempt to create an instance of the TM with a specific port, so when the autopilot is set to __True__, it tries to connect with a TM in default port `8000` and creates it in said client if it does not exist.
|
||||
```sh
|
||||
...
|
||||
batch.append(SpawnActor(blueprint, transform).then(SetAutopilot(FutureActor, True)))
|
||||
```
|
||||
* `tm_spawn_npc`: Allows complete access to the traffic manager object and its methods, as the instance is created explicitly. The drawback is that vehicles are spawned and set to autopilot serially, though this is fast enough to not be a major inconvenient.
|
||||
```sh
|
||||
...
|
||||
```
|
||||
|
||||
Right now there is no way to check which traffic managers have been created so far. A connection will be attempted when trying to get the instance and if there is no traffic manager using
|
||||
Right now there is no way to check which Traffic Managers have been created so far. A connection will be attempted when trying to get the instance and if there is no TM using
|
||||
|
||||
<h4>Setting a traffic manager</h4>
|
||||
#### Setting a Traffic Manager
|
||||
|
||||
The following example creates an instance of the traffic manager 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 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.
|
||||
|
||||
```python
|
||||
tm = client.GetTrafficManager(port)
|
||||
tm.register_vehicles(my_vehicles)
|
||||
tm = client.get_trafficmanager(port)
|
||||
for v in my_vehicles:
|
||||
v.set_autopilot(True)
|
||||
danger_car = my_vehicles[0]
|
||||
tm.ignore_lights_perc(danger_car,100)
|
||||
tm.set_distance_to_leading_vehicle(danger_car,0)
|
||||
tm.set_vehicle_max_speed_difference(danger_car,-20)
|
||||
tm.ignore_lights_percentage(danger_car,100)
|
||||
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.
|
||||
```python
|
||||
tm = client.GetTrafficManager(port)
|
||||
tm.register_vehicles(my_vehicles)
|
||||
tm = client.get_trafficmanager(port)
|
||||
for v in my_vehicles:
|
||||
v.set_autopilot(True)
|
||||
danger_car = my_vehicles[0]
|
||||
tm.set_global_distance_to_leading_vehicle(5)
|
||||
tm.set_global_max_speed_difference(80)
|
||||
tm.global_distance_to_leading_vehicle(5)
|
||||
tm.global_percentage_speed_difference(80)
|
||||
for v in my_vehicles:
|
||||
tm.set_auto_lane_change(v,False)
|
||||
tm.auto_lane_change(v,False)
|
||||
```
|
||||
|
||||
!!! Important
|
||||
Lane changes are currently disabled in the traffic manager due to unintended collisions causing jams. As long as this issues are not fixed, vehicles will remain in the lane they are spawned and the methods to set lane changes will be disabled.
|
||||
Lane changes are currently disabled in the TM due to unintended collisions causing jams. As long as this issues are not fixed, vehicles will remain in the lane they are spawned and the methods to set lane changes will be disabled.
|
||||
|
||||
|
||||
<h4>Stopping a traffic manager</h4>
|
||||
#### Stopping a Traffic Manager
|
||||
|
||||
> Destroy?
|
||||
> What happens?
|
||||
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.
|
||||
|
||||
---------------
|
||||
##Other considerations
|
||||
---
|
||||
## Other considerations
|
||||
|
||||
The traffic manager is a module constantly envolving 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 traffic managers 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 traffic manager as it is by the time CARLA 0.9.8 is released:
|
||||
The TM is a module constantly envolving and trying to adapt the range of possibilities that it presents. For instance, in order to get more realistic behaviours we can have many clients with different TM in charge of sets of vehicles with specific and distinct behaviours. This range of possibilities also makes for a lot of different configurations that can get really complex and specific. For such reason, here are listed of considerations that should be taken into account when working with the TM as it is by the time CARLA 0.9.8 is released:
|
||||
|
||||
<h4>FPS limitations</h4>
|
||||
#### FPS limitations
|
||||
|
||||
The traffic manager stops working properly when the simulation is under 20fps. Below that rate, the server is going much faster than the client containing the traffic manager and behaviours cannot be simulated properly. This is specially relevant when working in the night mode __table with relation between cars+night mode+city to fps?__
|
||||
The TM stops working properly in asynchronous mode when the simulation is under 20fps. Below that rate, the server is going much faster than the client containing the TM and behaviours cannot be simulated properly. This is specially relevant when working in the night mode __table with relation between cars+night mode+city to fps?__
|
||||
For said reason, under these circumstances it is recommended to work in __synchronous mode__.
|
||||
|
||||
!!! Warning
|
||||
Right now there is an issue when different clients work in __synchronous mode__ with the server, as the simulation waits for a tick that could come from any client, thus breaking the synchrony with the rest. This issue is specially relevant when working in synchronous with the __scenario runner__, which runs a traffic manager. For said reason, right know the traffic manager will be subordinated to the scenario runner and wait for it.
|
||||
> how to run it in synchronous mode.
|
||||
|
||||
<h4>Multiclient management</h4>
|
||||
When different clients work in __synchronous mode__ with the server, the server waits for a tick that may come from any client. If more than one client ticks, the synchrony will fail, as the server will move forward on every tick. For said reason, it is important to have one leading client while the rest remain silent. This is specially relevant when working in sync. with the __scenario runner__, which runs a TM. In this case, the TM will be subordinated to the scenario runner and wait for it.
|
||||
|
||||
When working with different clients containing different traffic managers, understanding inner implementation of the traffic manager in the client-server architecture becomes specially relevant. There is one ruling these scenarios: __the port is the key__.
|
||||
#### Multiclient management
|
||||
|
||||
A client (cl) creates a traffic manager (tm) by communicating with the server (s) and passing the intended port to be used for said purpose. The port can either be stated or not, using the default as `8000`.
|
||||
When working with different clients containing different TM, understanding inner implementation of the TM in the client-server architecture becomes specially relevant. There is one ruling these scenarios: __the port is the key__.
|
||||
|
||||
A client (cl) creates a Traffic Manager (tm) by communicating with the server (s) and passing the intended port to be used for said purpose. The port can either be stated or not, using the default as `8000`.
|
||||
|
||||
`cl_01 --> s --> tm_01 (p=8000)`
|
||||
`cl_02(p=5000) --> s --> tm_02 (p=5000)`
|
||||
|
||||
If a client tries to create a traffic manager using a port that is already assigned to another traffic manager, it will not create its own but connect to the one already existing. The reason for this is that __there cannot be two traffic managers sharing the same port__. This is specially relevant when using the default creation, as this will only create a traffic manager in the client if port `8000` has not been assigned yet. Otherwise, it will connect with the traffic manager created (in this case) by `cl_01` in port `8000`.
|
||||
If a client tries to create a TM using a port that is already assigned to another TM, it will not create its own but connect to the one already existing. The reason for this is that __there cannot be two Traffic Managers sharing the same port__. This is specially relevant when using the default creation, as this will only create a TM in the client if port `8000` has not been assigned yet. Otherwise, it will connect with the TM created (in this case) by `cl_01` in port `8000`.
|
||||
|
||||
`cl_03 --> s --> tm_01 (p=8000)`
|
||||
`cl_04(p=5000) --> s --> tm_02 (p=5000)`
|
||||
`cl_05(p=6000) --> s --> tm_03 (p=6000)`
|
||||
|
||||
The omniscient server keeps register of all these things internally and everytime a traffic manager is created, it stores the port and also the client ip that links to it. For said reason, traffic managers are also accessible using both the ip and the port, but this case will return an error in case any of the pair is wrong.
|
||||
The omniscient server keeps register of all these things internally and everytime a TM is created, it stores the port and also the client ip that links to it. For said reason, Traffic Managers are also accessible using both the ip and the port, but this case will return an error in case any of the pair is wrong.
|
||||
|
||||
`cl_06(ip=cl_02,p=6000) --> s --> ERROR`
|
||||
`cl_07(ip=cl02,p=5000) --> s --> tm_02 (p=5000)`
|
||||
|
|
@ -191,12 +193,11 @@ The omniscient server keeps register of all these things internally and everytim
|
|||
|
||||
__Anything else worth mentioning?? Other ways to break it??__
|
||||
|
||||
|
||||
---------------
|
||||
---
|
||||
## Summary
|
||||
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
<div class="build-buttons">
|
||||
<!-- Latest release button -->
|
||||
|
|
|
|||
|
|
@ -63,8 +63,9 @@
|
|||
A list of commands to execute in batch. The commands available are listed right above, in the function **<font color="#7fb800">apply_batch()</font>**.
|
||||
- param_name: due_tick_cue
|
||||
type: bool
|
||||
default: false
|
||||
doc: >
|
||||
A boolean parameter to specify whether or not to perform a carla.World.tick after applying the batch in _synchronous mode_.
|
||||
A boolean parameter to specify whether or not to perform a carla.World.tick after applying the batch in _synchronous mode_. It is __False__ by default.
|
||||
return: list(command.Response)
|
||||
doc: >
|
||||
Executes a list of commands on a single simulation step, blocks until the commands are linked, and returns a list of <b>command.Response</b> 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.
|
||||
|
|
@ -275,18 +276,31 @@
|
|||
doc: >
|
||||
Forces a vehicle to change either to the lane on its left or right, if existing, as indicated in `direction`. This method applies the lane change no matter what, disregarding possible collisions.
|
||||
# --------------------------------------
|
||||
- def_name: ignore_actors_percentage
|
||||
- def_name: ignore_vehicles_percentage
|
||||
params:
|
||||
- param_name: actor
|
||||
type: carla.Actor
|
||||
doc: >
|
||||
The vehicle that is going to ignore others.
|
||||
The vehicle that is going to ignore other vehicles.
|
||||
- param_name: perc
|
||||
type: float
|
||||
doc: >
|
||||
Between 0 and 100. Amount of times collisions will be ignored.
|
||||
doc: >
|
||||
During the collision detection stage, which runs every frame, this method sets a percent chance that collisions will be ignored for a vehicle.
|
||||
During the collision detection stage, which runs every frame, this method sets a percent chance that collisions with another vehicle will be ignored for a vehicle.
|
||||
# --------------------------------------
|
||||
- def_name: ignore_walkers_percentage
|
||||
params:
|
||||
- param_name: actor
|
||||
type: carla.Actor
|
||||
doc: >
|
||||
The vehicle that is going to ignore walkers on scene.
|
||||
- param_name: perc
|
||||
type: float
|
||||
doc: >
|
||||
Between 0 and 100. Amount of times collisions will be ignored.
|
||||
doc: >
|
||||
During the collision detection stage, which runs every frame, this method sets a percent chance that collisions with walkers will be ignored for a vehicle.
|
||||
# --------------------------------------
|
||||
- def_name: ignore_lights_percentage
|
||||
params:
|
||||
|
|
@ -301,20 +315,11 @@
|
|||
doc: >
|
||||
During the traffic light stage, which runs every frame, this method sets the percent chance that traffic lights will be ignored for a vehicle.
|
||||
# --------------------------------------
|
||||
- def_name: register_vehicles
|
||||
params:
|
||||
- param_name: actor_list
|
||||
type: list(carla.Actor)
|
||||
doc: >
|
||||
List of vehicles to register.
|
||||
doc: >
|
||||
Registers a series of vehicles to a traffic manager that will conduct them.
|
||||
# --------------------------------------
|
||||
- def_name: reset_traffic_lights
|
||||
doc: >
|
||||
Resets every traffic light in the map to its initial state.
|
||||
# --------------------------------------
|
||||
- def_name: set_auto_lane_change
|
||||
- def_name: auto_lane_change
|
||||
params:
|
||||
- param_name: actor
|
||||
type: carla.Actor
|
||||
|
|
@ -327,7 +332,7 @@
|
|||
doc: >
|
||||
Turns on or off lane changing behaviour for a vehicle.
|
||||
# --------------------------------------
|
||||
- def_name: set_distance_to_leading_vehicle
|
||||
- def_name: distance_to_leading_vehicle
|
||||
params:
|
||||
- param_name: actor
|
||||
type: carla.Actor
|
||||
|
|
@ -340,7 +345,7 @@
|
|||
doc: >
|
||||
Sets the minimum distance in meters that a vehicle has to keep with the others. The distance is in meters and will affect the minimum moving distance. It is computed from front to back of the vehicle objects.
|
||||
# --------------------------------------
|
||||
- def_name: set_collision_detection
|
||||
- def_name: collision_detection
|
||||
params:
|
||||
- param_name: reference_actor
|
||||
type: carla.Actor
|
||||
|
|
@ -357,7 +362,7 @@
|
|||
doc: >
|
||||
Tunes on/off collisions between a vehicle and another specific actor. In order to ignore all other vehicles, traffic lights or walkers, use the specific __ignore__ methods described in this same section.
|
||||
# --------------------------------------
|
||||
- def_name: set_global_max_speed_difference
|
||||
- def_name: global_percentage_speed_difference
|
||||
params:
|
||||
- param_name: percentage
|
||||
type: float
|
||||
|
|
@ -368,7 +373,7 @@
|
|||
|
||||
Default is 30. Exceeding a speed limit can be done using negative percentages.
|
||||
# --------------------------------------
|
||||
- def_name: set_global_distance_to_leading_vehicle
|
||||
- def_name: global_distance_to_leading_vehicle
|
||||
params:
|
||||
- param_name: distance
|
||||
type: float
|
||||
|
|
@ -377,7 +382,7 @@
|
|||
doc: >
|
||||
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.
|
||||
# --------------------------------------
|
||||
- def_name: set_vehicle_max_speed_difference
|
||||
- def_name: vehicle_percentage_speed_difference
|
||||
params:
|
||||
- param_name: actor
|
||||
type: carla.Actor
|
||||
|
|
@ -391,14 +396,4 @@
|
|||
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.
|
||||
# --------------------------------------
|
||||
- def_name: unregister_vehicles
|
||||
params:
|
||||
- param_name: actor_list
|
||||
type: list(carla.Actor)
|
||||
doc: >
|
||||
List of vehicles to be unregistered.
|
||||
doc: >
|
||||
Deletes a series of vehicles from the traffic manager's registered list to stop conducting them.
|
||||
# --------------------------------------
|
||||
...
|
||||
# --------------------------------------
|
||||
|
|
@ -27,7 +27,7 @@ nav:
|
|||
- 'Recorder': 'adv_recorder.md'
|
||||
- 'Rendering options': 'adv_rendering_options.md'
|
||||
- 'Synchrony and time-step': 'adv_synchrony_timestep.md'
|
||||
- 'Traffic manager': 'traffic_manager.md'
|
||||
- 'Traffic Manager': 'traffic_manager.md'
|
||||
- References:
|
||||
- 'Python API reference': 'python_api.md'
|
||||
- 'Code recipes': 'ref_code_recipes.md'
|
||||
|
|
|
|||
Loading…
Reference in New Issue