1. 为什么“设置”环节决定了整个仿真的成败很多人第一次接触 AirSim 做自动驾驶仿真注意力几乎全放在“怎么把车跑起来”“怎么接感知算法”上结果真正卡住的地方往往不是算法而是设置。我见过太多情况场景加载出来了车却不动动了之后传感器数据全是空的好不容易有数据了时间戳又对不上回放的时候轨迹飘得离谱。这些问题九成以上都出在设置环节而不是代码逻辑。AirSim 的“设置”本质上是一套配置文件驱动的初始化系统。它不像很多仿真工具那样把参数散落在代码里而是集中放在一个settings.json文件里仿真启动时读取这个文件决定加载哪个场景、车辆初始位姿、用哪些传感器、物理引擎怎么跑、时钟走真实时间还是仿真时间。理解这一点很关键你改的不是某个函数的参数而是整个仿真世界的初始条件。改错一个字段可能整个仿真行为都变了。这篇文章面向的是已经跑通过 AirSim 基础示例、准备认真做自动驾驶仿真验证的人。我会把设置拆成几个层次文件放哪、场景怎么选、车辆怎么配、传感器怎么调、时钟和物理怎么权衡最后讲排查问题的思路。全程按我实际踩坑的顺序来不按官方文档的目录顺序因为官方文档是“查阅型”的而实际干活是“问题驱动型”的。先说一个最容易被忽略的前提AirSim 的设置文件位置和你用的平台强相关。Windows 下通常在文档\AirSim\settings.jsonLinux 下在~/Documents/AirSim/settings.json。如果你用的是 Unreal 或 Unity 插件形式它读的就是这个路径而不是你项目目录里的文件。我早期把 settings.json 放在工程目录里改了半天空载后来才发现根本没被读取。确认文件被正确加载是所有设置工作的第零步后面所有内容都建立在这个前提上。2. 设置文件的整体结构与加载逻辑2.1 settings.json 的顶层字段划分一个完整的 settings.json 大致可以分成四块全局设置、场景/环境设置、载具设置、传感器设置。它们不是平级的而是有嵌套关系的。顶层常见字段包括SettingsVersion、SimMode、ClockType、Vehicles、SubWindows等。其中Vehicles是个字典每个键是一辆车的名字值里再嵌套传感器配置。我建议新手先把结构理清楚再动手不然很容易把传感器配置写到错误的层级。比如相机是挂在某辆车下面的你写到顶层就完全无效。下面这张表是我整理的常见顶层字段和它们的作用方便对照字段作用常见取值是否必填SettingsVersion配置格式版本1.2建议填SimMode仿真模式Car / Multirotor / ComputerVision必填ClockType时钟类型SteppableClock / ScalableClock建议填Vehicles载具及其传感器字典做车必填SubWindows多视角窗口数组可选OriginGeopoint地理原点经纬度可选SimMode是最关键的字段之一。做自动驾驶就填Car它决定了 API 暴露哪些控制接口。如果你填成Multirotor那car_controls这类接口根本不存在调用会直接报错。我见过有人复制别人的配置模式没改折腾半天以为 API 坏了。2.2 配置加载的优先级与覆盖规则AirSim 读取设置时有一个容易踩的坑它不会合并多个文件而是只读一个。如果你同时存在用户目录下的 settings.json 和工程目录下的它按固定优先级选一个不会把两者拼起来。所以不要指望“在工程里放一份覆盖用户目录的”要么统一放一处要么用启动参数显式指定路径。另外字段是“缺省即默认”的逻辑。你没写的字段会用内置默认值而不是报错。这看起来友好实际很危险——比如你没配ClockType它用默认时钟仿真跑起来和你预期的时间尺度可能完全不一样而你根本不知道问题出在哪。我的习惯是关键字段全部显式写出来哪怕值和默认一样这样配置本身就是一份文档换台机器也不会因为默认值差异出问题。提示改完 settings.json 必须重启仿真才生效热加载是不支持的。很多人改完直接调 API发现没变化其实是没重启。3. 场景与载具设置让车出现在正确的位置3.1 场景选择与初始位姿设定场景决定了物理世界的几何和碰撞体。AirSim 自带一些示例场景你也可以用自己搭建的。设置里和场景相关的字段主要是初始位置和朝向。车辆初始位姿用X、Y、Z和Yaw、Pitch、Roll描述单位是米和度。这里有个坐标系问题必须讲清楚AirSim 用的是NED 坐标系北-东-地也就是说 Z 轴向下为正。你把车放在Z -2表示离地 2 米而不是地下 2 米。这个和很多图形学里的 Y 轴向上完全相反第一次配的时候我直接把车埋进地里了。初始位姿设错会导致两种典型现象一是车悬空或陷地物理引擎一启动就弹飞二是车朝向不对你发前进指令它往侧面跑。我的经验是先在场景里手动把车摆到理想位置记下坐标再写进配置比凭空猜坐标靠谱得多。如果场景有坡度还要注意初始 Z 要匹配地面高度否则车会自由落体一段再稳定。3.2 载具类型与物理参数Vehicles下面每辆车的配置里除了传感器还有一些物理相关字段。比如车辆的质量、轮胎摩擦等部分版本支持通过配置微调。这些参数直接影响操控手感摩擦太小车会打滑漂移质量太大加速迟钝。做控制算法验证时我建议先用默认物理参数把流程跑通再逐步调参不要一上来就大改物理否则你分不清是算法问题还是物理问题。还有一点多车仿真时每辆车要有独立的键名传感器也要各自配置。我做过一个两车交互的场景一开始两辆车共用了同一份传感器配置的引用结果数据串了。后来改成每辆车完整独立配置才正常。多车场景下配置的独立性比复用更重要。4. 传感器设置数据质量的源头4.1 相机与激光雷达的关键参数传感器是自动驾驶仿真的眼睛配置错了后面全白搭。相机常见参数有分辨率、FOV、位置、朝向。分辨率越高越清晰但帧率和传输开销也越大。我一般先用 640x480 跑通确认数据正常后再提到 1280x720 或更高。FOV 决定视野范围太小看不全太大边缘畸变明显通常 90 度是个不错的起点。激光雷达的参数更敏感。NumberOfChannels线数、Range探测距离、PointsPerSecond点频、HorizontalFOV这几个直接决定点云密度和覆盖。线数越高点云越密但计算量也越大。我实测下来做感知验证 32 线基本够用做高精度建图才需要 64 线以上。下面这张表是我常用的几组配置对比用途线数探测距离点频备注快速验证1650m约 30 万轻量帧率高感知算法32100m约 60 万平衡之选高精建图64120m约 120 万重需好显卡4.2 传感器位姿与外参标定传感器装在车上的位置和朝向就是外参。这个必须和真实车辆的安装位置对应否则你拿仿真数据训出来的模型换到真车上会因为视角差异而失效。配置里每个传感器都有自己的X、Y、Z和旋转。我习惯把车中心作为原点相机装在车顶前方激光雷达装在车顶正中这样和大多数真实方案接近。注意传感器位姿的坐标系同样是 NED朝向用四元数或欧拉角表示时要特别小心符号。我踩过的坑是 Yaw 方向反了 180 度结果相机一直朝后看还以为是渲染问题。5. 时钟与物理设置时间尺度的隐形陷阱5.1 ClockType 的选择逻辑ClockType是我认为最容易被低估的设置。它有两个主要选项SteppableClock和ScalableClock。前者让仿真时间由你手动步进适合做确定性、可复现的算法验证后者让仿真时间按比例缩放跟随真实时间适合做实时性相关的测试。做控制算法时我强烈建议用SteppableClock因为你可以精确控制每一步的时间结果可复现。做感知实时性评估时才用ScalableClock。选错时钟的后果很隐蔽用真实时钟跑控制算法因为计算耗时波动每步时间不一致你的控制器参数在仿真里调好了换台机器就崩。确定性是仿真验证的生命线这一点怎么强调都不过分。5.2 物理步长与稳定性权衡物理步长决定了仿真的精度和稳定性。步长太大碰撞检测会漏车辆运动不连续步长太小计算量暴涨跑不动。常见取值在 1ms 到 5ms 之间。我一般从 2ms 起步如果发现车辆抖动或穿透再往小调。这里有个经验公式步长应小于车辆最高速度下移动一个车身长度所需时间的十分之一这样基本不会漏碰撞。物理引擎的选择也会影响行为不同版本默认引擎不同。做车辆动力学验证时要确认引擎支持你要的轮胎模型和悬挂模型否则调出来的参数没有物理意义。6. 常见问题与排查技巧实录设置环节的问题往往表现为“现象诡异但报错很少”排查起来靠的是系统化思路。我整理了一张速查表覆盖我遇到过的绝大多数情况现象可能原因排查方向车不动SimMode 错 / API 没连上确认 Car 模式检查连接端口传感器无数据配置层级错 / 未重启确认挂在 Vehicles 下重启仿真时间戳跳变ClockType 不当改用 SteppableClock车陷地或弹飞Z 轴符号错检查 NED 坐标系Z 向下为正点云稀疏线数/点频太低提高 NumberOfChannels多车数据串配置未独立每辆车单独完整配置排查的核心原则是二分法先确认最基础的能不能跑单车、单传感器、默认参数再逐步加复杂度。我见过有人一上来就配八个传感器加多车出问题后完全无从下手。把变量一个个加上去问题自然定位。还有一个独家技巧把 settings.json 纳入版本管理。每次改配置都提交一次出问题时可以快速回滚对比。我靠这个办法定位过好几次“明明没改什么却坏了”的诡异问题最后发现是某次顺手改了一个字段。7. 我实际配置时的一些体会配置这件事官方文档给的是“有什么字段”但“该怎么组合”得靠自己趟。我的习惯是维护几套模板一套最小验证配置只放一辆车一个相机用来快速确认环境正常一套完整感知配置多传感器齐全用来跑算法一套多车交互配置用来做协同验证。切换场景时直接换文件比每次手改字段可靠得多。另外参数不要一次调太多。我早期喜欢一口气把分辨率、线数、时钟全改了结果出问题根本不知道是哪个引起的。后来改成每次只动一个变量记录现象再动下一个效率反而高很多。仿真配置是个系统工程稳扎稳打比追求一步到位划算。最后分享一个小技巧把常用的传感器配置写成片段用的时候复制粘贴再微调比从零写快得多也不容易漏字段。配置写多了你会发现真正需要改的往往就那么几个值其余都是固定套路。