我做了一个 CARLA 自动驾驶仿真测试平台——项目复盘与技术架构作者chuyue-setsnua | 项目地址carla-adas-test-platform项目背景我是智能车辆工程专业大三学生目标岗位是台架测试开发工程师自动驾驶仿真方向。这个岗位的核心要求就几个Python/C 自动化测试、CAN 总线、HIL/SIL 测试框架、至少一个仿真平台CARLA 或 CarMaker。网上能找到的 CARLA 教程基本是怎么 spawn 一辆车然后按 WASD 开跟台架测试完全不搭边。真实台架测试要的是自动化运行场景 → 采集传感器 CAN 数据 → 批量回归测试 → 生成测试报告。所以我决定从零搭一个完整的 ADAS 仿真测试平台既能练技术又能写进简历。系统架构整个平台围绕 CARLA Client-Server 架构搭建核心分层如下┌─────────────────────────────────────────┐ │ Pygame UI Layer │ │ Camera View | HUD Panel | Live Charts │ ├─────────────────────────────────────────┤ │ Scenario Controller │ │ State Machine (IDLE → RUNNING → DONE) │ │ Keyboard Input (SPACE/R/Q) │ ├──────────────────┬──────────────────────┤ │ AEB Controller │ CAN Bus Logger │ │ - TTC Graded │ - 7 CAN IDs 20Hz │ │ - Persistent │ - Vector .asc format │ │ - Lane Keeping │ - CANalyzer compat │ ├──────────────────┴──────────────────────┤ │ CARLA Client API │ │ world.tick() | spawn_actor | sensors │ ├──────────────────────────────────────────┤ │ CARLA Server (CarlaUE4.exe) │ │ Unreal Engine 4 | Physics | Rendering │ └──────────────────────────────────────────┘每一层做了一件事且只做一件事场景控制器管状态机和用户输入AEB 控制器只管跟车和制动逻辑CAN 日志只负责数据编码和落盘。这种分层的好处是你换一个场景比如从跟车 AEB 变成行人 AEB只需要改场景控制器层AEB 和 CAN 层完全不用动。三个核心场景1. AEB 跟车场景scenario_aeb_test.py两车场景。Ego 以巡航速度跟随 LeadLead 在某个时刻踩死刹车。评估 ego 能否在碰撞前刹停。这是 Euro NCAP 的 Car-to-Car AEB 基础测试项。2. Cut-in 切入场景scenario_cutin.py三车场景复杂度大幅提升。Ego 在自己的车道巡航前方有 Lead相邻车道有一辆 Cut-in 车比 ego 稍快在设定的时间点变道切入 ego 前方。这个场景要同时跟踪两个目标Lead 和 Cut-inAEB 要判断哪个更近、哪个更危险。三车放置是个技术难点——不是直接取三个 spawn_point 就行的。我的方案ego 占 spawn_pointLead 用几何投影在 ego 前方同车道Cut-in 从 spawn_points 中根据 road_id 和 lane_id 动态筛选相邻车道的点。3. 行人横穿 AEBscenario_pedestrian.pyCARLA 里行人和车辆是不同的 actor 类型。行人 spawn 需要 walker blueprint 和 WalkerController。这个场景最大的坑是AEB 制动后 ACC 重新加速——后面会详细讲。所有场景都集成了 CAN 日志输出每个 tick 记录 7 帧 CAN 报文到 .asc 文件。CAN 总线设计思路面试官大概率会问为什么选这 7 个 CAN ID提前准备一下我的设计逻辑0x0C0 车速 0x1A4 油门 0x1A0 制动这三者构成纵向控制闭环任何一个场景都能据此评估控制质量0x0C4 转向角 0x200 横摆角速度横向控制的输入和输出评估车道保持能力0x220 纵向加速度二重导数能捕捉制动的瞬态响应刹车踩下到实际减速之间的延迟0x300 雷达目标AEB 的核心感知数据记录 ego 前方最近目标的距离和相对速度选择 Vector .asc 格式是因为它是汽车电子行业的事实标准——CANalyzer/CANoe 不认 csv 和 json只认 .asc/.blf。这也意味着你的测试数据可以直接交给标定工程师做进一步分析这正是台架测试开发的日常工作流。关键数据指标以行人 AEB 场景为例一次通过的测试结果指标数值触发 TTC2.8 s最小距离4.2 m最大制动力1.0满刹场景耗时12.3 sCAN 帧数~1720 帧测试结论PASS无碰撞批量测试框架跑 80 组参数可以直接生成热力图一眼看出哪些速度 间距 减速度组合会触发碰撞FAIL哪些安全通过PASS。这对调参和系统安全边界分析非常有用。项目收获做完这个项目我对台架测试开发的理解从大概知道变成了亲手做过仿真 ≠ 点一下 Play。自动化场景运行要考虑状态机、重置逻辑、异常处理以及 headless 模式下没有 UI 时怎么验证结果。CAN 总线是仿真和真实台架的桥梁。理解 CAN ID 设计、信号分辨率、报文周期这些知识在 HIL 测试中直接复用。踩坑是最快的学习方式。spawn_actor 的 (0,0,0) 问题、AEB 制动后重新加速、CARLA server 损坏——每一个坑都让我对引擎机制的理解深了一层。代码和完整文档都在 GitHubgithub.com/chuyue-setsnua/carla-adas-test-platform。下一篇我会专门写这个项目里踩过的坑和修复过程那些才是面试时最能让面试官点头的内容。