其他分享
首页 > 其他分享> > Traffic Manager

Traffic Manager

作者：互联网

What is the Traffic Manager?

The Traffic Manager ™ 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.

在模拟环境中，交通管理器（Traffic Manager, TM）是控制自动驾驶模式下的车辆的模块。它的目标是模拟真实的城市交通状况。用户可以自定义一些行为，例如设置特定的学习环境（learning circumstances）

Structured design

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.

TM 建立在 CARLA 的客户端上，其执行流程被划分为多个阶段，每个阶段都有独立的操作和目标。这促进了与阶段相关（phase-related）的功能和数据结构的开发，同时提高了计算效率。每个阶段运行在不同的线程上。通过同步消息（synchronous messaging）传递管理与其他阶段的通信，其信息是单向流动的。

User customization

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.

用户可以通过设置参数来允许、强制或鼓励某些特定行为，从而对交通流量（traffic flow）进行一些控制。此外，用户可以在线或离线修改交通行为（如：汽车可以无视限速或强制换道）。在模拟现实场景时，能够自定义（play around with）交通行为是必不可少的。驾驶系统需要在特定和非典型情况下进行训练。

Architecture

Overview

在这里插入图片描述

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:

上图展示了 TM 的内部架构，每个组件的 C++ 代码可以在LibCarla/source/carla/trafficmanager（carla 源码中）中找到。以下部分将详细解释每个组件，一个简单的逻辑概述如下：

1. Store and update the current state of the simulation.

  • The Agent Lifecycle & State Management (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. The ALSM is the only component that makes calls to the server.
  • The 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 is a cache store of the position, velocity, and additional information of all the vehicles and pedestrians in the simulation.
  1. 存储和更新当前的模拟状态
    • 代理生命周期和状态管理（ALSM）扫描世界，跟踪所有出现的车辆和行人，并清理那些不再存在的实体。所有的数据来自服务器，这些数据会通过几个阶段进行传递。ALSM是唯一一个调用服务器的组件。
    • 车辆注册表（vehicle registry）包括自动驾驶车辆的数组（由 TM 控制）和不是自动控制的行人和车辆的列表（不由 TM 控制）。
    • 仿真状态（simulation state）是仿真中所有车辆和行人的位置、速度和附加信息的缓存存储。

2. Calculate the movement of every autopilot vehicle.

The TM generates viable commands for all vehicles in the vehicle registry according to the simulation state. Calculations for each vehicle are done separately. These calculations are divided into different stages. The 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. 计算每个自动驾驶车辆的运动

TM 根据仿真状态为车辆注册表（vehicle registry）中的所有车辆生成可行的命令，每辆车的计算是分开进行的，这些计算被分为多个不同的阶段。控制循环通过在阶段之间创建同步屏蔽（synchronization barriers） 来确保所有计算是一致的。在当前阶段的所有车辆计算完成之前，没有车辆会进入下一阶段。每辆车都要经过以下几个阶段:

2.1 - Localization Stage.

Paths are created dynamically using a list of nearby waypoints collected from the 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) component for easy access and modification in future stages.

3. Apply the commands in the simulation.

Commands generated in the previous step are collected into the 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.

  1. 在模拟中应用命令

将上一步生成的命令收集到命令数组（command array）中，批量发送到 CARLA 服务器，在同一帧中应用。下面的部分将更详细地解释上面描述的 TM 逻辑中的每个组件和阶段。

ALSM

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.

The ALSM component:

  • 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(). 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 component.
  • Updates the list of TM-controlled vehicles in the vehicle registry.
  • Updates entries in the control loop and PBVT components to match the vehicle registry.

Related .cpp files: ALSM.h, ALSM.cpp.

ALSM 代表代理生命周期和状态管理，它是 TM 逻辑循环（logic cycle）的第一步，提供了仿真环境当前状态的上下文。其具有以下特点：

相关 cpp 文件：ALSM.h, ALSM.cpp

Vehicle registry

The vehicle registry keeps track of all vehicles and pedestrians in the simulation.

The vehicle registry:

  • Is passed an updated list of vehicles and pedestrians from the ALSM.
  • Stores vehicles registered to the TM in a separate array for iteration during the control loop.

Related .cpp files: MotionPlannerStage.cpp.

车辆注册表（vehicle registry）记录了模拟中的所有车辆和行人。其具有以下特点：

相关 cpp 文件：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 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.

Related .cpp files: SimulationState.cpp, SimulationState.h.

仿真状态（simulation state）存储关于仿真中所有车辆的信息，以便在后期方便地访问和修改。其具有以下特点：

相关 cpp 文件：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 five different stages; localization, collision, traffic light, motion planner and vehicle lights.

The control loop:

  • Receives an array of TM-controlled vehicles from the vehicle registry.
  • Performs calculations for each vehicle separately by looping over the array.
  • Divides calculations into a series of stages.
  • 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 so all calculations are done in sync.
  • Sends the command array to the server when the last stages (Motion Planner Stage and Vehicle Lights Stage) finishes so there are no frame delays between the command calculations and the command application.

Related .cpp files: TrafficManagerLocal.cpp.

控制循环（control loop）管理所有自动驾驶车辆的下一个命令的计算，因此它们是同步执行的。其由定位，碰撞，交通灯，运动规划和车灯这五个不同的阶段组成。其具有以下特点：

相关 cpp 文件：TrafficManagerLocal.cpp

In-Memory Map

The In-Memory Map is a helper module contained within the PBVT and is used during the 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.

In-Memory Map 是 PBVT 中包含的一个辅助模块，其在定位阶段（Localization stage）使用。具有如下特点：

相关 cpp 文件：InMemoryMap.cpp和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.

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 used by the Localization Stage to relate every vehicle to the nearest waypoint and possible overlapping paths.

PBVT 代表路径缓冲和车辆跟踪，它也是一种数据结构，包含了每辆车的预期路径，并允许在控制循环（control loop）中轻松访问数据。其具有以下特点：

PID controller

The PID controller is a helper module that performs calculations during the 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.
  • Makes adjustments depending on the specific parameterization of the controller. Parameters can be modified if desired. Read more about PID controllers to learn how to make modifications.

Related .cpp files: PIDController.cpp.

PID 控制器是一个辅助模块，其在运动规划阶段执行计算。具有以下特点：

相关 cpp 文件：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’s from the 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 depending on whether the simulation is running in asynchronous or synchronous mode, respectively.

Related .cpp files: TrafficManagerLocal.cpp

命令数列（command array）是 TM 逻辑周期的最后一步，它接收所有注册车辆的命令并应用它们。其具有如下特点：

相关 cpp 文件：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.
  • Uses the 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 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.

定位阶段定义了由 TM 控制的车辆的短期路径规划，其具有如下特点：

相关 cpp 文件：LocalizationStage.cpp and LocalizationUtils.cpp

Stage 2- Collision Stage

The Collision Stage triggers collision hazards.

The Collision Stage:

  • Receives from the 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 to modify the path accordingly.

Related .cpp files: CollisionStage.cpp.

碰撞阶段触发碰撞危险，其具有如下特点：

相关 cpp 文件：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.

由于交通监管（如：交通灯，停止标志，优先路口），交通灯阶段会引发危险。其具有如下特点：

相关 cpp 文件：TrafficLightStage.cpp

Stage 4- Motion Planner Stage

The Motion Planner Stage generates the CARLA commands to be applied to vehicles.

The Motion Planner Stage:

Related .cpp files: MotionPlannerStage.cpp.

运动规划阶段产生应用于车辆的 CARLA 命令，其具有以下特点：

相关 cpp 文件：MotionPlannerStage.cpp

Stage 5- Vehicle Lights Stage

The Vehicle Lights Stage activates the lights based on the condition of the vehicle and the surrounding environment.

The Vehicle Lights Stage:

  • Retrieves the planned waypoints for the vehicle, information about vehicle lights (eg. light state and the planned command to be applied) and the weather conditions.
  • Determines the new state of the vehicle lights:
    • Turns on the blinkers if the vehicle is planning to turn left/right at the next junction.
    • Turns on the stop lights if the applied command is asking the vehicle to brake.
    • Turns on the low beams and the position lights from sunset to dawn, or under heavy rain.
    • Turns on the fog lights under heavy fog conditions.
  • Update the vehicle lights state if it has changed.

Related .cpp files: VehicleLightStage.cpp.

车灯阶段根据车辆的状况和周围环境激活车灯，其具有如下特点：

相关 cpp 文件：VehicleLightStage.cpp

Using the Traffic Manager

Vehicle behavior considerations

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 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. Below is a general summary of what is possible through the API:

当您将车辆设置为自动驾驶时，TM 实现了必须考虑的一般行为模式：

TM 的行为可以通过 Python API 进行调整。有关具体方法，请参阅 Python API 文档的 TM 部分。以下是通过API可以实现的一些功能：

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

Creating a Traffic Manager

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.

A TM instance is created by a carla.Client, passing the port to be used. The default port is 8000.

To create a TM instance:

tm = client.get_trafficmanager(port)

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:

tm_port = tm.get_port()
for v in vehicles_list:
  v.set_autopilot(True,tm_port)

TM 被设计成在同步模式下工作，在异步模式下使用 TM 可能会导致意想不到的不良结果。一个 TM 实例由 carla.Client 创建，传递要使用的端口，默认端口为 8000。可通过以下代码创建 TM 实例：

tm = client.get_trafficmanager(port)

要为一组车辆启用自动驾驶（autopilot）模式，需要获取 TM 实例的端口，并将 set_autopilot 设置为 True，同时通过 TM 端口。如果没有提供端口，它将尝试连接到默认端口 8000。如果TM不存在，它将创建一个：

tm_port = tm.get_port()
 for v in vehicles_list:
     v.set_autopilot(True,tm_port)

Note: 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.

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:

traffic_manager = client.get_trafficmanager(args.tm-port)
tm_port = traffic_manager.get_port()
...
batch.append(SpawnActor(blueprint, transform).then(SetAutopilot(FutureActor, True,tm_port)))
...
traffic_manager.global_percentage_speed_difference(30.0)

在多客户端情况下创建或连接到 TM 与上面的示例不同。/PythonAPI/examples 中的 generate_traffic.py 脚本提供了一个例子，展示如何使用一个作为脚本参数的端口创建一个 TM 实例，并通过批量设置autopilot为 True 来注册每一辆生成的车辆：

traffic_manager = client.get_trafficmanager(args.tm-port)
tm_port = traffic_manager.get_port()
...
batch.append(SpawnActor(blueprint, transform).then(SetAutopilot(FutureActor, True,tm_port)))
...
traffic_manager.global_percentage_speed_difference(30.0)

Configuring autopilot behavior

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:

tm = client.get_trafficmanager(port)
tm_port = tm.get_port()
for v in my_vehicles:
  v.set_autopilot(True,tm_port)
danger_car = my_vehicles[0]
tm.ignore_lights_percentage(danger_car,100)
tm.distance_to_leading_vehicle(danger_car,0)
tm.vehicle_percentage_speed_difference(danger_car,-20)

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:

tm = client.get_trafficmanager(port)
tm_port = tm.get_port()
for v in my_vehicles:
  v.set_autopilot(True,tm_port)
danger_car = my_vehicles[0]
tm.global_distance_to_leading_vehicle(5)
tm.global_percentage_speed_difference(80)
for v in my_vehicles: 
  tm.auto_lane_change(v,False)

下面的例子创建了一个 TM 实例，并为特定的车辆配置危险行为，这样它就会忽略所有的交通灯，不与其他车辆保持安全距离，并以比当前限速快 20% 的速度行驶：

tm = client.get_trafficmanager(port)
tm_port = tm.get_port()
for v in my_vehicles:
  v.set_autopilot(True,tm_port)
danger_car = my_vehicles[0]
tm.ignore_lights_percentage(danger_car,100)
tm.distance_to_leading_vehicle(danger_car,0)
tm.vehicle_percentage_speed_difference(danger_car,-20)

下面的示例将相同的车辆列表设置为自动驾驶，并为它们配置适当的驾驶行为。车辆以低于当前限速 80% 的速度行驶，与其他车辆之间至少保持 5 米的距离，且不进行换道：

tm = client.get_trafficmanager(port)
tm_port = tm.get_port()
for v in my_vehicles:
  v.set_autopilot(True,tm_port)
danger_car = my_vehicles[0]
tm.global_distance_to_leading_vehicle(5)
tm.global_percentage_speed_difference(80)
for v in my_vehicles: 
  tm.auto_lane_change(v,False)

Delegating the Traffic Manager to automatically update vehicle lights

By default, vehicle lights (brake, turn indicators, etc…) of the vehicles managed by the TM are never updated. It is possible to delegate the TM to update the vehicle lights of a given vehicle actor:

tm = client.get_trafficmanager(port)
for actor in my_vehicles:
  tm.update_vehicle_lights(actor, True)

Vehicle lights management has to be specified on a per-vehicle basis, and there could be at any given time both vehicles with and without the automatic light management.

默认情况下，TM 管理的车辆的车灯（刹车、转弯指示灯等）永远不会更新。可以委托 TM 更新给定车辆的车灯：

tm = client.get_trafficmanager(port)
for actor in my_vehicles:
  tm.update_vehicle_lights(actor, True)

车辆的灯光管理必须在每辆车的基础上指定，在任何给定的时间，车辆都可以存在或不存在自动灯光管理。

Stopping a Traffic Manager

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:

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.

TM 不是一个需要被摧毁的 actor；当创建它的客户端关闭时，它也会关闭。这是由 API 自动管理的，用户不需要做任何事情。然而，当关闭一个 TM 时，用户必须摧毁它所控制的车辆，否则他们将在地图上保持静止。脚本 generate_traffic.py 会自动完成这个操作：

client.apply_batch([carla.command.DestroyActor(x) for x in vehicles_list])

注：关闭一个 TM-Server 将关闭连接到它的 TM-Clients

Deterministic mode

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 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" before starting.

在确定模式（deterministic mode）下，TM 在相同条件下将会产生相同的结果和行为。不要把 determinism 和 recorder 混为一谈。recorder 允许存储模拟的日志以进行回放，而 determinism 则是确保只要保持相同的条件，TM 在不同的脚本执行过程中始终具有相同的输出。

确定模式（deterministic mode）仅在同步模式下可用。在异步模式下，对仿真的控制更少，无法实现 determinism 。

To enable deterministic mode, use the following method:

my_tm.set_random_device_seed(seed_value)

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.

要启用确定模式（deterministic mode），请使用以下方法：

my_tm.set_random_device_seed(seed_value)

seed_value 是一个整数，将根据它生成随机数。值本身是不相关的，但是相同的值总是会产生相同的输出。在相同的条件下，使用相同种子值的两个模拟将是确定的（deterministic）。

To maintain determinism over multiple simulation runs, the seed must be set for every simulation. For example, each time the world is reloaded, the seed must be set again:

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:

cd PythonAPI/examples
python3 generate_traffic.py -n 50 --seed 9

Warning: The CARLA server and the TM must be in synchronous mode before enabling deterministic mode. Read more here about synchronous mode in TM.

为了在多次模拟运行中保持确定性（determinism），必须为每个模拟设置种子。例如，每当玩家重新加载游戏世界时，他们便需要重新设置种子：

client.reload_world()
my_tm.set_random_device_seed(seed_value)

确定模式（deterministic mode）可以在 generate_traffic.py 示例脚本中通过传递一个种子值作为参数来测试。下面的例子在同步模式下设置一个带有 50 个自动驾驶角色（actors）的地图，并将 seed 设置为任意值 9：

cd PythonAPI/examples
python3 generate_traffic.py -n 50 --seed 9

注：在启用确定性模式（deterministic mode）之前，CARLA 服务器和 TM 必须处于同步模式。

Hybrid physics mode

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.

混合模式（Hybrid mode）允许用户禁用所有自动驾驶车辆的大多数物理计算，或将在标记为hero的车辆的一定半径外的自动驾驶车辆禁用物理计算？这消除了模拟中的车辆物理瓶颈（bottleneck）。物理失效的车辆将通过瞬间移动来移动。保持基本的线性加速度计算，以确保位置更新和车辆速度保持现实，车辆物理计算的切换是流动的。

Hybrid mode uses the 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) — 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.

混合模式（Hybrid mode）使用 Actor.set_simulate_physics() 方法来切换物理计算。默认禁用，有两个选项来启用它:

To modify the behavior of hybrid mode, use the following two parameters:

  • 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).
  • 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 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.

下面的剪辑显示了当混合模式激活时，物理是如何启用和禁用的。英雄的车辆标有一个红色方块，物理失效的车辆被标记为蓝色方块。在英雄车的影响范围内，物理效果被激活，标签变成绿色。
在这里插入图片描述

Running multiple Traffic Managers

Traffic Manager servers and clients

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.

CARLA 客户端通过向服务器指定要使用的端口来创建 TM。如果未指定端口，则使用默认的 8000。如果在同一端口上创建更多的 TM，它们将成为 TM-Clients，而原来的 TM 将成为 TM-Server。

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.

The following code creates two TM-Servers. Each one connects to a different, unused port:

tm01 = client01.get_trafficmanager()     # tm01 --> tm01 (p=8000)
tm02 = client02.get_trafficmanager(5000) # tm02(p=5000) --> tm02 (p=5000)

TM-Server 是第一个连接到空闲端口的 TM，然后其他 TM （TM-Clients）连接到运行 TM-Server 的相同端口。TM-Server 将指示所有 TM-Clients 的行为，例如，如果 TM-Server 停止时，所有 TM-Clients 将停止。

下面的代码创建两个 TM-Server。每个都连接到一个不同的、未使用的端口：

tm01 = client01.get_trafficmanager()     # tm01 --> tm01 (p=8000)
tm02 = client02.get_trafficmanager(5000) # tm02(p=5000) --> tm02 (p=5000)

TM-Client

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.

tm03 = client03.get_trafficmanager()     # tm03 --> tm01 (p=8000). 
tm04 = client04.get_trafficmanager(5000) # tm04(p=5000) --> tm02 (p=5000)

当一个 TM 连接到另一个 TM（TM-Server）所占用的端口时，将会创建 TM-Client，TM-Client 行为将由 TM-Server 决定。下面的代码将创建两个 TM-Client，每个都连接上一节中创建的 TM-Server：

tm03 = client03.get_trafficmanager()     # tm03 --> tm01 (p=8000). 
tm04 = client04.get_trafficmanager(5000) # tm04(p=5000) --> tm02 (p=5000)

Multi-client simulations

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:

terminal 1: ./CarlaUE4.sh -carla-rpc-port=4000
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

在多客户端模拟中，在同一个端口上创建多个 TM。第一个创建的 TM 将作为一个 TM-Server，后面再连接到该端口的作为 TM-Clients。TM-Server 将指定所有 TM 实例的行为：

terminal 1: ./CarlaUE4.sh -carla-rpc-port=4000
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

Multi-TM simulations

In a multi-TM simulation, multiple TM instances are created on distinct ports. Each TM instance will control its own behavior:

terminal 1: ./CarlaUE4.sh -carla-rpc-port=4000
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

在多 TM 模拟中，在不同的端口上创建多个 TM 实例。每个 TM 实例将控制它自己的行为：

terminal 1: ./CarlaUE4.sh -carla-rpc-port=4000
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

Multi-simulation

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:

terminal 1: ./CarlaUE4.sh -carla-rpc-port=4000 # simulation A 
terminal 2: ./CarlaUE4.sh -carla-rpc-port=5000 # 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

多仿真（Multi-simulation）是指同时运行多个 CARLA 服务器。TM 需要连接到相关的 CARLA 服务器端口，只要计算能力允许，TM 可以在同一时间运行多个模拟：

terminal 1: ./CarlaUE4.sh -carla-rpc-port=4000 # simulation A 
terminal 2: ./CarlaUE4.sh -carla-rpc-port=5000 # 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 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 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.

多仿真的概念独立于 TM 本身。上面的例子并行地运行了两个 CARLA 模拟，在每个模拟中，一个 TM-Server 是独立于另一个创建的。模拟 A 可以运行一个多客户端（multi-client）的 TM，而模拟 B 运行多个 TM 或者根本不运行 TM。

上述设置最可能产生的问题是，客户端试图连接到一个已经存在的 TM，而 TM 没有运行在选定的模拟上。如果发生这种情况，连接将会被中止，以防止模拟之间的干扰。

Synchronous mode

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.

TM 被设计成在同步模式下工作，为了正常工作，CARLA 服务器和 TM 都应该设置为同步。在异步模式下使用TM可能会导致意想不到的结果。但如果需要异步模式，模拟至少应该以 20-30fps 的速度运行。

下面的脚本演示了如何将服务器和 TM 设置为同步模式：

...
# Set the simulation to sync mode
init_settings = world.get_settings()
settings = world.get_settings()
settings.synchronous_mode = True
# After that, set the TM to sync mode
my_tm.set_synchronous_mode(True)
...
# Tick the world in the same client
world.apply_settings(init_settings)
world.tick()
...
# 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)

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:

cd PythonAPI/examples
python3 generate_traffic.py -n 50

If asynchronous mode is required, use the --async flag when running the above command.

generate_traffic.py示例脚本启动一个 TM，并用车辆和行人填充地图。它自动将 TM 和 CARLA 服务器设置为同步模式：

cd PythonAPI/examples
python3 generate_traffic.py -n 50

如果需要异步模式，在运行上述命令时使用--async标志

If more than one TM is set to synchronous mode, synchrony will fail. Follow these guidelines to avoid issues:

  • In a multiclient situation, only the TM-Server should be set to synchronous mode.
  • In a multiTM situation, only one TM-Server should be set to synchronous mode.
  • The ScenarioRunner module runs a TM automatically. The TM inside ScenarioRunner will automatically be the one set to sync mode.

Warning: 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.

如果多个 TM 被设置为同步模式，同步将会失败。请遵循以下指引以避免该问题：

Traffic manager in large maps

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.

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.

所有自动驾驶车辆都将被视为休眠角色（ dormant actors）。在混合模式下，休眠的自动驾车辆会在地图上移动。车辆将不会被渲染，因为没有hero vehicle触发地图贴图流（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:

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:

my_tm.set_respawn_dormant_vehicles(True)
my_tm.set_boundaries_respawn_dormant_vehicles(25,700)

当自动驾驶车辆超过了定义的actor_active_distance的值时，它们将休眠（dormant）。要设置此值，可使用以下 Python API：

settings = world.get_settings()

# Actors will become dormant 2km away from the ego vehicle
settings.actor_active_distance = 2000

world.apply_settings(settings)

在 TM 中，休眠角色可以被设置为在 hero vehicle周围持续重生，而不是在地图的其他地方保持休眠状态。这个选项可以在 Python API 中使用 set_respawn_dormant_vehicles方法配置。车辆将在hero vehicle周围重生，其距离是在用户指定距离内。respawnable 距离的上下边界可以使用set_boundaries_respawn_dormant_vehicles方法设置。注意，最大距离不会大于大地图的贴图流距离，最小距离是20米。

在hero vehicle25 米和 700 米范围内，休眠车辆可以重生：

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.

如果碰撞阻止了休眠角色（dormant actor）被重生，TM 将在下一个模拟步骤中重试。

如果休眠车辆没有重生，它们的行为将取决于混合模式是否启用。如果混合模式已经启用，那么休眠的角色将被传送到地图上。如果不启用混合模式，那么休眠者的物理状态将不会被计算出来，它们将保持在原来的位置，直到它们不再休眠。

标签：tm,vehicles,Manager,TM,Traffic,mode,vehicle,port
来源： https://blog.csdn.net/steven_ysh/article/details/122653952