1. 项目概述：为什么场景构建是自动驾驶仿真的命门？

如果你正在做自动驾驶算法开发或者测试验证，那你一定对“仿真”这个词不陌生。无论是感知、规划还是控制模块，在实车路测之前，都得先在虚拟世界里“跑”个成千上万遍。而仿真效果好不好，能不能发现真问题，关键就看“场景”造得真不真。这就像拍电影，剧本和场景搭得不行，再好的演员也演不出好戏。今天，咱们不聊那些高深的算法理论，就聚焦在两个最主流的开源仿真平台——CARLA和LGSVL上，掰开揉碎了聊聊它们“搭场景”这件事。

简单说，CARLA和LGSVL都是为自动驾驶研发量身定做的仿真器，但它们背后的“出身”和设计哲学截然不同，这直接导致了它们在场景构建能力、上手难度和适用阶段上的巨大差异。CARLA脱胎于游戏引擎（Unreal Engine），画面逼真，场景细节丰富，更像一个“好莱坞大片制片厂”，擅长构建视觉上高度逼真、充满动态交互的复杂城市环境。而LGSVL（现在已更名为SVL Simulator）则源于科技公司（最初由LG电子美国研发中心发起，后由丰田研究院支持），它更注重与自动驾驶软件栈（如Autoware、百度Apollo、AutonomousStuff）的深度集成和传感器模型的精确性，像一个“专业的汽车测试场”，强调场景的可重复性、可控性和与真实数据流的对接。

所以，当你面临选择时，核心问题就变成了：你更需要一个视觉上极致逼真、能激发算法潜力的“开放世界”，还是一个流程标准、易于对接、能进行大规模回归测试的“标准化考场”？这次对比，我就结合自己在这两个平台上实际搭建测试场景的经验，从场景构成元素、构建工具链、工作流效率、以及与算法栈的集成度这几个核心维度，给你一个透彻的分析。

2. 核心场景构成元素拆解：从静态地图到动态逻辑

一个完整的自动驾驶仿真场景，远不止一条路和几辆车。我们可以把它拆解成几个层次，就像搭积木一样，从下往上理解。

2.1 静态环境：地图与道路网络

这是场景的骨架和皮肤。CARLA在这方面优势明显，因为它直接利用了Unreal Engine强大的渲染能力和资产库。CARLA官方提供了多个高度精细的城镇地图（如Town01到Town12），这些地图拥有复杂的道路结构（十字路口、环岛、匝道）、丰富的路边设施（建筑、树木、红绿灯、标志牌）以及逼真的材质和光照。你甚至可以利用UE的编辑器或第三方工具（如RoadRunner）制作自定义的高精地图（HD Map）并导入。CARLA的地图包含了详细的语义信息（车道线类型、道路边界、交通标志位置），这些信息通过API暴露给自动驾驶系统。

LGSVL的静态环境则更偏向“工程化”。它支持导入OpenDRIVE格式的道路网络文件，这是一种描述道路几何和逻辑关系的标准格式。这意味着你可以利用专业的道路设计软件（如RoadRunner、VectorZero）生成符合真实道路标准的OpenDRIVE地图，然后导入LGSVL。LGSVL的环境渲染基于Unity引擎，其视觉保真度在默认状态下通常不如CARLA的UE场景，但它更轻量，运行效率可能更高。LGSVL的一个亮点是它官方提供了基于真实激光雷达点云数据生成的、与Apollo等框架配套的高精地图，对于追求与真实数据一致性的研发团队来说，这点非常吸引人。

注意：视觉逼真度不等于仿真有效性。CARLA的漂亮画面对于依赖摄像头的感知算法训练是宝藏，但对于以激光雷达和定位为主的算法，过于复杂的纹理有时反而是干扰。LGSVL相对“干净”的环境，反而有利于聚焦在核心的逻辑测试上。

2.2 动态实体：车辆、行人与交通流

场景活起来，靠的是动态实体。两者都支持在场景中放置自动驾驶主车（Ego Vehicle）和NPC（非玩家角色）车辆、行人、自行车等。

CARLA的NPC行为由其内置的“交通管理器”控制。你可以定义全局的交通规则（如车速分布、闯红灯概率），也可以精细控制单个车辆或行人的轨迹（通过waypoint）。CARLA的车辆动力学模型相对基础，但对于大多数决策规划算法的测试已经足够。它的强大之处在于丰富的资产库和逼真的动画（如行人行走、自行车骑行），能营造出非常生动的交通环境。

LGSVL在动态实体管理上提供了不同的思路。它有一个强大的“场景编辑器”和“Python API”。你可以在编辑器中以“关键帧”的方式，直观地编排车辆、行人的运动路径、触发条件（如到达某个位置后变道）。这种方式对于构建复杂的、有精确时序要求的测试场景（如cut-in， 行人鬼探头）非常高效。LGSVL也支持通过API以编程方式生成和控制实体，灵活性很高。

关键差异点：CARLA的交通流更像是“模拟人生”，基于规则产生一种看似随机的、连续的车流。而LGSVL的场景更像“电影分镜”，你可以精确导演每一台车、每一个行人在什么时间点、做什么动作。前者适合做大规模、长尾分布的随机测试；后者适合做标准化的、针对特定Corner Case的回归测试。

2.3 传感器模型：仿真世界的“眼睛”和“耳朵”

传感器仿真是连接虚拟场景与自动驾驶算法的桥梁。两者都提供了主流的传感器模型：摄像头（RGB， 深度， 语义分割）、激光雷达、毫米波雷达、IMU、GPS等。

CARLA的传感器渲染质量极高，尤其是摄像头。它可以模拟不同的镜头畸变、动态模糊、HDR和噪声，对于训练和测试基于摄像头的感知算法是绝佳选择。其激光雷达点云也包含了丰富的语义信息。但CARLA的传感器数据生成完全依赖于游戏引擎的渲染管线，计算开销大，要跑高帧率、多传感器配置，对硬件（尤其是GPU）要求很高。

LGSVL的传感器模型在物理特性模拟上可能更深入。例如，它的激光雷达模型可以配置具体的线数、旋转频率、垂直视场角、距离精度和噪声模型，更贴近真实传感器的数据表。它的毫米波雷达模型也尝试模拟多径效应、噪点等特性。LGSVL支持将传感器数据通过ROS/ROS2或Cyber RT等中间件直接发布，与Autoware、Apollo等框架“开箱即用”地集成，这大大降低了系统集成的工作量。

选择建议：如果你的研究重点是计算机视觉、端到端感知，或者需要极其逼真的视觉输入，CARLA是首选。如果你的重点是整个自动驾驶栈的集成测试，特别是使用激光雷达和毫米波雷达，且需要与Apollo等框架无缝对接，LGSVL的传感器模型和接口设计可能更“趁手”。

2.4 场景逻辑与天气系统

除了静态和动态元素，场景的逻辑（如交通灯时序、触发事件）和环境影响（天气、光照）也至关重要。

CARLA提供了强大的天气和光照参数动态调整API，可以模拟一天中的不同时间、以及雨、雪、雾等不同天气条件，并且这些变化能实时影响传感器数据（如摄像头画面变暗、激光雷达在雨雾中衰减），这对于测试算法的鲁棒性非常有价值。

LGSVL同样支持天气和时间变化，但可能不如CARLA的参数那么精细和直观。在场景逻辑方面，LGSVL的“场景编辑器”允许你以流程图或脚本的方式定义复杂的事件链，例如：“当主车行驶到A点时，在B点生成一个横穿马路的行人；如果主车没有减速，则记录一次测试失败”。这种基于事件触发的场景描述方式，非常符合功能安全测试（如ISO 21448 SOTIF）的需求。

3. 场景构建工作流与工具链深度对比

知道了有什么“积木”，下一步就是看怎么“搭”。两者的构建工作流和工具链差异巨大，直接决定了开发效率。

3.1 CARLA：基于Python API与蓝图编辑器的“编程+设计”模式

CARLA的核心控制接口是Python API。几乎所有场景构建工作都可以通过编写Python脚本来完成：

import carla # 连接客户端，加载世界 client = carla.Client('localhost', 2000) world = client.get_world() # 设置天气 weather = carla.WeatherParameters(cloudiness=80.0, precipitation=30.0, wetness=40.0) world.set_weather(weather) # 生成车辆和传感器 blueprint_library = world.get_blueprint_library() vehicle_bp = blueprint_library.filter('model3')[0] spawn_point = world.get_map().get_spawn_points()[0] vehicle = world.spawn_actor(vehicle_bp, spawn_point) # 添加一个摄像头 camera_bp = blueprint_library.find('sensor.camera.rgb') camera_transform = carla.Transform(carla.Location(x=1.5, z=2.4)) camera = world.spawn_actor(camera_bp, camera_transform, attach_to=vehicle)

这种方式极其灵活，你可以用代码生成任何你能想到的场景逻辑。但对于复杂的、需要大量手动摆放物体的静态场景，纯代码就不太方便了。这时，你可以使用Unreal Editor直接编辑CARLA的地图。你可以像开发游戏一样，用鼠标拖拽建筑、树木、交通标志到场景中，调整材质和光照。不过，这需要你具备一定的Unreal Engine使用基础，学习曲线较陡。

CARLA场景构建的典型流程：

1. 地图选择/制作：使用现有Town地图，或利用RoadRunner+UE插件制作自定义HD Map。
2. 静态布景（可选）：在Unreal Editor中精细化调整场景资产。
3. 动态脚本编写：使用Python API编写脚本，定义主车行为、NPC行为流、天气变化、测试逻辑等。
4. 运行与数据收集：运行脚本，通过API接收传感器数据，并记录日志。

优点：极限灵活，视觉保真度高，社区活跃，资源丰富。缺点：工具链复杂（涉及UE、Python），硬件要求高，构建标准化测试场景需要较多的编程工作。

3.2 LGSVL：基于场景编辑器与开放标准的“可视化+配置”模式

LGSVL提供了一个基于Web的“场景编辑器”界面，这是它与CARLA最显著的区别。你可以在浏览器中打开编辑器，以可视化的方式：

• 拖放车辆、行人到地图上。
• 绘制路径：直接在地图上点击设置路径点，为NPC定义运动轨迹。
• 设置触发器：在特定位置设置区域触发器，用于触发后续事件（如生成障碍物、改变交通灯）。
• 编排行为树：通过简单的逻辑节点（序列、选择、并行）组合成复杂的行为。

所有这些操作最终都会保存为一个JSON或YAML格式的场景描述文件。这种文件是声明式的，易于版本管理、分享和复用。

LGSVL场景构建的典型流程：

1. 地图准备：准备或下载OpenDRIVE格式地图文件，导入模拟器。
2. 可视化编辑：在Web编辑器中，摆放静态障碍物（可选），放置主车和NPC，为NPC绘制路径。
3. 事件编排：使用编辑器的事件面板，创建触发器（如区域触发器、时间触发器）和对应的动作（如NPC加速、行人出现、测试结束判断）。
4. 保存与运行：保存场景文件。通过Python API或ROS启动模拟器，加载该场景文件运行。
5. 与自动驾驶栈集成：传感器数据通过ROS Topic或Cyber RT Channel直接发送给你的感知、定位、规划模块。

优点：上手快，可视化操作直观，场景文件易于管理和复用，与Apollo/Autoware集成度极高，对硬件要求相对友好。缺点：视觉逼真度默认不及CARLA，高度依赖OpenDRIVE地图的质量，复杂逻辑编排可能不如直接编程灵活。

4. 实操指南：从零构建一个Cut-in测试场景

理论说再多，不如动手做一遍。我们以构建一个经典的“高速公路Cut-in（加塞）”测试场景为例，分别在CARLA和LGSVL上实现，感受一下两者的具体操作。

4.1 在CARLA中实现Cut-in场景

假设我们在CARLA的Town04（高速公路地图）上实现。我们需要：一条高速车道，主车（Ego）在中间车道匀速行驶，一辆NPC车辆从右侧车道加速并切入主车前方。

import carla import random import time # 1. 连接并加载世界 client = carla.Client('localhost', 2000) client.set_timeout(10.0) world = client.get_world() # 使用Town04 world = client.load_world('Town04') # 2. 生成主车 bp_lib = world.get_blueprint_library() vehicle_bp = bp_lib.filter('tesla')[0] # 选择特斯拉模型 spawn_points = world.get_map().get_spawn_points() # 找一个在高速中道的出生点（需要根据地图实际情况调整索引） ego_spawn_point = spawn_points[30] # 示例索引，需实际查看 ego_vehicle = world.spawn_actor(vehicle_bp, ego_spawn_point) # 设置主车为自动驾驶模式（由模拟器控制，或后续接入你的算法） ego_vehicle.set_autopilot(True) # 3. 生成NPC车辆（Cut-in车辆） npc_bp = bp_lib.filter('audi')[0] # 我们需要让NPC在主车右侧车道，稍靠前的位置生成 # 这里使用航点系统来寻找特定车道的点 map = world.get_map() # 获取主车当前位置的航点 ego_location = ego_spawn_point.location waypoint = map.get_waypoint(ego_location, project_to_road=True) # 获取右侧车道的航点（lane_id为负表示右侧） right_lane_wp = waypoint.get_right_lane() if right_lane_wp is not None: # 在右侧车道，主车前20米处生成NPC npc_transform = right_lane_wp.transform npc_transform.location.x += 20.0 # 放在主车前方 npc_vehicle = world.spawn_actor(npc_bp, npc_transform) # 4. 控制NPC行为：先并行，然后Cut-in # 获取目标车道（主车所在车道）的航点 target_lane_wp = waypoint # 计算一个切入点（例如，主车前10米处） cut_in_distance = 10.0 target_location = target_lane_wp.transform.location target_location.x += cut_in_distance # 简单实现：让NPC先加速到与主车并行，然后朝目标点移动 # 这里使用CARLA的交通管理器简化控制 traffic_manager = client.get_trafficmanager() traffic_manager.ignore_lights_percentage(npc_vehicle, 100) traffic_manager.vehicle_percentage_speed_difference(npc_vehicle, -30) # NPC更快 # 更精确的轨迹控制需要自己计算路径点序列，这里仅为示意 # 一种方法是设置一系列航点，让NPC依次通过 print("NPC车辆已生成，即将执行Cut-in行为。") # 5. 运行一段时间 try: time.sleep(30) finally: # 销毁车辆 if 'ego_vehicle' in locals(): ego_vehicle.destroy() if 'npc_vehicle' in locals(): npc_vehicle.destroy()

实操心得：在CARLA中精确控制车辆轨迹是一个难点。上面的代码利用了交通管理器进行简单控制，但要做精准的Cut-in，通常需要自己计算一条从起始车道到目标车道的平滑轨迹（使用样条曲线），然后通过vehicle.apply_control()逐帧控制转向和油门。这需要较强的数学和编程能力。对于复杂的交互场景，社区有一些高级行为模型库（如carla_agents），但学习和集成也需要成本。

4.2 在LGSVL中实现Cut-in场景

在LGSVL中，我们可以完全通过可视化编辑器完成这个场景，几乎不用写代码。

1. 打开场景编辑器：启动LGSVL模拟器，在浏览器中打开Web UI，进入“Simulations” -> “Scenarios” -> “Create New”。
2. 选择地图：加载一个包含高速公路的OpenDRIVE地图（例如LGSVL自带的“BorregasAve”或“SanFrancisco”）。
3. 放置主车：从资产列表中拖拽一辆车辆到高速中间车道，将其设置为“Ego”车辆。在右侧属性面板中，可以设置其初始速度。
4. 放置NPC并绘制路径：
   • 拖拽另一辆车到右侧车道，放在主车前方一段距离。
   • 选中这辆NPC车，点击“Add Waypoint”工具。
   • 在地图上点击创建路径点：第一个点放在NPC初始位置，第二个点放在与主车平行的位置，第三个点放在主车所在车道、主车前方不远处。这样就定义了一条从右车道切入中间车道的路径。
   • 在路径点属性中，可以为每个点设置目标速度（例如，第二个点加速，第三个点保持）。
5. 设置触发条件（可选）：如果我们希望Cut-in动作在特定条件下触发（如主车接近某个区域），可以使用“Triggers”。
   • 在主车路径上放置一个“Region Trigger”（区域触发器）。
   • 当主车进入该区域时，触发一个“事件”。
   • 该事件可以设置为“启用”之前定义好路径的NPC车辆。
6. 保存场景：给场景命名并保存。你会得到一个.json或.xosc（OpenSCENARIO标准）文件。
7. 运行场景：在“Simulations”界面选择该场景文件，选择你的自动驾驶软件栈（如Apollo），点击运行。模拟器会自动加载场景，主车和NPC将按照设定行为运动。

实操心得：LGSVL编辑器的可视化路径绘制和触发器系统，让构建这种有精确时空关系的场景变得非常直观和快速。整个过程中，你不需要关心车辆动力学方程的细节，只需要关注“在哪儿”、“什么时候”、“做什么”。这对于测试工程师快速构建大量标准测试用例极其友好。生成的场景文件可以直接放入CI/CD流水线进行自动化测试。

5. 选型决策与常见问题排查

5.1 我该如何选择？决策矩阵

为了帮你更直观地做决定，我整理了一个简单的决策矩阵：

个人建议：

• 如果你的核心工作是训练或测试深度学习感知模型（特别是视觉相关），或者你在研究需要高度逼真环境交互的新算法（如强化学习），CARLA几乎是必选项。
• 如果你在做自动驾驶全栈的集成、测试和验证，特别是基于百度Apollo、Autoware等开源框架，或者需要快速构建大量符合行业标准（OpenSCENARIO）的测试用例，LGSVL能让你事半功倍。
• 折中方案：两者并不完全互斥。有些团队会使用CARLA生成逼真的传感器数据用于感知模型训练，同时使用LGSVL进行系统级的集成和逻辑测试。也有研究尝试将两者结合，例如用CARLA渲染，用LGSVL的接口与Apollo通信。

5.2 常见问题与排查技巧实录

在实际使用中，你肯定会遇到各种坑。这里分享一些我踩过的雷和解决方法。

CARLA 常见问题：

1. 问题：模拟器运行卡顿，帧率极低。

   • 排查：首先在运行CARLA时加上-quality-level=Low或-quality-level=Epic参数调整渲染质量。在脚本中，检查是否生成了过多传感器（尤其是摄像头和激光雷达），每个传感器都是性能杀手。
   • 技巧：对于不需要视觉的训练，可以使用-RenderOffScreen模式运行无头服务器。在Python API中，通过world.tick()控制步长，避免循环空转。升级显卡驱动，确保CUDA版本兼容。

2. 问题：车辆控制不精准，总是偏离预定路径。

   • 排查：CARLA默认的车辆物理模型为了性能做了简化。检查是否使用了set_autopilot，它内置的控制器可能不够好。如果自己控制，确保控制频率（每秒发送控制命令的次数）足够高（如20Hz）。
   • 技巧：对于路径跟踪，建议使用PID控制器或更高级的模型预测控制器（MPC）。CARLA的vehicle.apply_control()接收的是油门/刹车和转向值，需要根据当前车速和期望轨迹实时计算。可以先用简单的waypoint跟随算法测试。

3. 问题：自定义地图导入后，车辆陷入地面或漂浮。

   • 排查：这通常是OpenDRIVE地图与UE场景网格（Mesh）的高度（Z轴）不匹配导致的。
   • 技巧：在RoadRunner中导出时，确保选择正确的坐标轴朝向和单位。在UE中导入后，使用CARLA提供的Recast工具重新生成导航网格（NavMesh），并检查生成的地面碰撞体是否准确。

LGSVL 常见问题：

1. 问题：与Apollo的Cyber RT连接失败，收不到传感器数据。

   • 排查：这是最常见的集成问题。首先确保LGSVL模拟器和Apollo的Bridge组件使用的是相同的ROS版本或Cyber RT版本。检查网络配置，localhost或IP地址是否正确。
   • 技巧：在LGSVL的Web UI中，“Simulations”配置页面，仔细检查“Autonomous System”的设置。对于Apollo，通常选择“Apollo 5.0+”之类的模板。查看Apollo的dreamview前端和cyber_monitor工具，确认是否有对应的Channel在收发数据。

2. 问题：在场景编辑器中绘制的车辆路径，运行时车辆不按路径走。

   • 排查：检查NPC车辆的“Initial Speed”是否设置为0？如果为0，车辆需要时间加速，可能看起来没动。检查路径点是否设置了“Idle”行为（如Stop），这会让车辆停止。
   • 技巧：为路径的第一个点也设置一个速度值（如5 m/s）。确保路径点之间的连接是平滑的，避免急弯。使用“播放”功能在编辑器中预览路径。

3. 问题：模拟器启动后黑屏或地图加载不出来。

   • 排查：可能是图形驱动问题，或者是Unity渲染设置不兼容。
   • 技巧：尝试以命令行方式启动模拟器，并添加-screen-fullscreen 0 -screen-quality Fantastic等参数调整窗口和画质。查看日志文件（通常在~/.config/unity3d/LGElectronics/SVL Simulator/Player.log），里面常有具体的错误信息。

最后，无论选择哪个平台，文档和社区都是你最好的朋友。CARLA的官方文档和论坛非常活跃，LGSVL的GitHub仓库和文档也在持续更新。遇到问题时，先搜一下Issues和Discussions，大概率已经有人遇到过并给出了解决方案。仿真环境的搭建和调试本身就是一个系统工程，耐心和细致是唯一的捷径。