AirSim仿真环境配置详解：从settings.json到多传感器与多车仿真

1. 仿真环境设置到底在设什么很多人第一次打开 AirSim 的配置文件看到那一长串 JSON 就懵了。车辆参数、传感器参数、天气参数、时钟参数全挤在一个文件里改错一个括号整个仿真就起不来。我刚开始接触的时候也是这样改完settings.json启动仿真结果车直接掉到地图外面去了排查了半天才发现是VehicleType写错了。AirSim 的设置体系本质上是一套声明式的配置系统。你不需要写代码去创建传感器、去设置车辆动力学参数只需要在一个 JSON 文件里把这些东西“声明”出来仿真器启动的时候会自动根据你的声明去构建整个仿真世界。这个设计思路和现在流行的基础设施即代码很像把环境定义和运行逻辑分离改配置就能改行为不用动一行代码。这套设置系统能控制的东西比大多数人想象的要多得多。除了最基本的车辆类型和传感器配置你还能控制仿真时钟的步进方式、物理引擎的更新频率、天气系统的参数、甚至每个传感器的具体安装位置和朝向。换句话说AirSim 的设置文件就是你整个仿真实验的“总控面板”所有实验条件的定义都在这里完成。适合谁来参考这篇内容呢如果你已经在电脑上跑通了 AirSim 的基本示例能启动仿真看到车辆在场景里跑起来但想进一步定制自己的实验环境那这篇就是写给你的。如果你还没装好 AirSim建议先把基础环境搭起来再回来看设置部分不然容易一头雾水。2. 设置文件的整体结构与加载逻辑2.1 文件位置与加载优先级AirSim 的设置文件叫settings.json它的存放位置直接决定了哪些仿真项目能读到这份配置。在 Windows 系统下它通常放在C:\Users\你的用户名\Documents\AirSim\这个目录里Linux 系统下则是~/Documents/AirSim/。这个位置是 AirSim 默认查找配置的路径不管你从哪个项目启动仿真它都会先来这里找。但这里有个很多人踩过的坑如果你在项目目录下也放了一份settings.json那情况就变得复杂了。AirSim 的加载逻辑是优先读取项目目录下的配置如果项目目录下没有才会去读用户文档目录下的那份。这个优先级顺序意味着你可以在不同项目里放不同的配置文件互不干扰。我自己的习惯是把通用的基础配置放在用户目录下作为默认值然后在具体项目目录里放一份覆盖特定参数的配置这样既保证了通用性又保留了灵活性。还有一种情况是通过命令行参数指定配置文件路径。这种方式在自动化测试或者批量实验的时候特别有用你可以准备多份配置用脚本依次加载运行不用手动去改文件。具体做法是在启动仿真的时候加上-settings参数后面跟上配置文件的完整路径。注意配置文件的文件名必须是settings.json不能改成别的名字。AirSim 只认这个文件名改名字它就直接用默认配置了你写的所有参数都不会生效。2.2 JSON 结构的基本骨架一份完整的设置文件从结构上看分成几个大的区块。最外层是一个 JSON 对象里面包含SettingsVersion、SimMode、ClockType、Vehicles、SubWindows、CameraDefaults等顶层字段。其中Vehicles是最核心的部分所有和车辆相关的配置都挂在这个字段下面。SettingsVersion这个字段很多人会忽略但它其实挺重要的。它标记了这份配置文件遵循的格式版本AirSim 在加载的时候会根据这个版本号来决定怎么解析后面的内容。版本号不对的话轻则部分参数被忽略重则整个配置加载失败。目前常用的版本号是 1.2如果你不确定该写多少直接写 1.2 基本不会出问题。SimMode决定了仿真的类型可选值有Car、Multirotor、ComputerVision等。这个字段设错了后面所有配置都可能对不上。比如你设成Multirotor却配了一堆车辆参数仿真启动后会发现根本没有车辆出现。我建议在改任何其他参数之前先确认这个字段和你实际要仿真的对象类型一致。ClockType控制仿真时钟的推进方式有SteppableClock和ScalableClock两种。前者需要外部主动调用步进命令才会推进适合需要精确控制仿真节奏的场景后者按照真实时间比例自动推进适合大多数常规仿真。选哪种取决于你的实验需求如果要做强化学习训练通常用SteppableClock更合适因为你可以精确控制每一步的时间间隔。2.3 车辆配置的嵌套结构Vehicles字段下面是一个以车辆名称为键的对象。你可以只配一辆车也可以配多辆车同时仿真。每辆车下面又有VehicleType、AutoCreate、PawnPath、X、Y、Z、Yaw、Cameras、Sensors等字段。VehicleType指定车辆的类型常见的有Car、Multirotor、SimpleFlight等。这个字段和顶层的SimMode要配合使用两者不一致的话会出现各种奇怪的问题。AutoCreate决定仿真启动时是否自动创建这辆车设成true的话你不需要在代码里手动调用创建接口仿真一启动车就在场景里了。X、Y、Z是车辆的初始位置单位是米。这里有个容易搞混的地方AirSim 使用的坐标系和常见的游戏引擎坐标系不完全一样NED 坐标系下 X 朝北、Y 朝东、Z 朝下。所以 Z 值是正数的时候车辆反而在地面以下要让它在地面上方Z 得设成负数。这个坑我踩过不止一次每次隔一段时间不用 AirSim 再回来都会搞反。Yaw是车辆的初始朝向角单位是度0 度表示朝北90 度表示朝东以此类推。这个参数在多车仿真的时候特别重要不设置的话所有车都朝同一个方向看起来很奇怪。3. 传感器配置的细节与参数计算3.1 相机传感器的配置要点相机是自动驾驶仿真里最常用的传感器AirSim 支持配置多个相机每个相机可以有不同的分辨率、视场角、安装位置和朝向。相机的配置挂在车辆下面的Cameras字段里每个相机用一个自定义的名称作为键。相机的核心参数包括CaptureSettings和X、Y、Z、Pitch、Roll、Yaw。CaptureSettings里面又包含ImageType、Width、Height、FOV_Degrees等。ImageType决定了相机输出什么类型的图像常见的有Scene彩色图像、DepthPlanar深度图、DepthPerspective透视深度图、Segmentation分割图等。分辨率的选择需要权衡。高分辨率能提供更多细节但渲染开销也更大。我一般先用 640x480 跑通流程确认没问题后再根据实际需要提高到 1280x720 或更高。如果做目标检测训练通常 640x480 到 1280x720 之间就够用了再高的话收益递减明显但帧率下降很快。FOV_Degrees是视场角默认值通常是 90 度。这个值直接影响相机的可视范围视场角越大看到的范围越广但图像边缘的畸变也越明显。做车道线检测的时候视场角可以适当大一些保证能同时看到左右车道线做交通标志识别的时候视场角可以小一些让标志在图像中占更多像素。相机安装位置的计算需要一点空间想象力。假设你要在车辆前挡风玻璃后面装一个前视相机车辆本身的高度大概是 1.5 米挡风玻璃中心大概在车辆中心上方 0.5 米的位置那相机的 Z 值大概就是 -1.0注意 Z 轴朝下所以是负数。X 值取决于挡风玻璃到车辆中心的水平距离一般轿车这个距离在 1.0 到 1.5 米之间。这些数值不是绝对的需要根据你使用的具体车辆模型来调整。3.2 激光雷达与毫米波雷达配置激光雷达的配置比相机复杂一些因为它的参数更多。核心参数包括NumberOfChannels通道数、Range探测距离、PointsPerSecond每秒点数、RotationsPerSecond每秒旋转圈数、VerticalFOVUpper和VerticalFOVLower垂直视场角上下限。通道数决定了激光雷达的垂直分辨率。常见的 16 线、32 线、64 线激光雷达对应的就是NumberOfChannels分别为 16、32、64。通道数越多点云越密集但计算开销也越大。做算法验证的话16 线通常够用了如果要模拟高精度地图构建可能需要 64 线甚至更高。Range设置探测距离单位是米。这个值要根据你的仿真场景来定。如果是城市道路场景100 米左右的探测距离基本够用如果是高速公路场景可能需要设置到 200 米甚至更远。设置得太大的话远处那些点其实对算法没什么帮助反而增加了数据处理负担。PointsPerSecond和RotationsPerSecond这两个参数需要配合计算。假设你设置每秒旋转 10 圈每秒点数 100000那每圈就是 10000 个点。如果水平视场角是 360 度那水平角分辨率就是 360/10000 0.036 度。这个分辨率已经相当高了实际使用中可以根据需要适当降低减少计算量。毫米波雷达的配置相对简单一些主要参数包括探测距离、视场角、距离分辨率、速度分辨率等。AirSim 对毫米波雷达的支持不如相机和激光雷达那么完善但基本功能还是有的。配置的时候注意雷达的安装位置和朝向毫米波雷达通常安装在车辆前保险杠位置稍微向下倾斜一点这样能更好地探测前方路面情况。3.3 传感器安装位置的计算方法传感器安装位置的计算是很多人觉得头疼的地方。其实只要理解了坐标系剩下的就是简单的几何运算。AirSim 使用 NED 坐标系原点在车辆中心X 轴指向车辆正前方Y 轴指向车辆右侧Z 轴指向车辆正下方。假设你要在车辆顶部安装一个激光雷达车辆高度 1.5 米激光雷达安装在车顶中心稍微靠前一点的位置。那这个激光雷达的坐标大概是 X0.5靠前 0.5 米Y0左右居中Z-1.6车顶上方 0.1 米因为 Z 轴朝下所以是负数。这个计算过程不复杂关键是要记住 Z 轴的方向。相机的朝向用Pitch、Roll、Yaw三个角度来控制。Pitch是俯仰角正数表示向上看负数表示向下看Roll是横滚角正数表示向右倾斜Yaw是偏航角正数表示向右转。这三个角度的单位都是度。前视相机通常Pitch设为 0 或者稍微向下一点比如 -5 度Roll和Yaw都设为 0。实操心得配置完传感器后不要急着跑复杂算法。先写一个最简单的脚本把传感器数据取出来显示一下确认安装位置和朝向符合预期。我见过太多人传感器配置错了跑了好几天实验才发现数据完全不对白白浪费了大量时间。4. 仿真时钟与物理参数的调优4.1 时钟类型的选择与影响AirSim 的时钟系统控制着仿真世界的时间推进方式这个设置直接影响你的实验能不能复现。ClockType有两个可选值SteppableClock和ScalableClock。ScalableClock按照真实时间的比例推进仿真。比如你设置SpeedFactor为 1.0那仿真时间和真实时间基本同步设置成 2.0 的话仿真时间流速是真实时间的两倍。这种时钟适合做演示或者对时间精度要求不高的场景。但它的缺点是仿真步长不固定每一步实际经过的时间可能略有差异做需要精确时间控制的实验时会有问题。SteppableClock需要外部主动调用步进命令才会推进仿真。每次调用simContinueForTime或者simPause之类的接口仿真才会往前走一步。这种时钟的好处是每一步的时间间隔完全由你控制实验结果可复现性非常好。做强化学习训练的时候基本都用这种时钟因为你需要精确控制每一步的时间保证不同轮次的实验条件完全一致。选择时钟类型的时候还要考虑SteppableClock下的StepSize参数。这个参数决定了每次步进仿真推进多少秒。设得太大的话物理模拟的精度会下降车辆运动看起来会一跳一跳的设得太小的话仿真推进速度会很慢跑完一个实验要等很久。我一般从 0.01 秒开始试如果发现车辆运动不够平滑就减小到 0.005 秒如果觉得太慢就适当增大到 0.02 秒找到一个平衡点。4.2 物理引擎参数与更新频率AirSim 底层用的是 Unreal Engine 的物理引擎物理参数的配置会影响车辆运动的真实感。PhysicsEngineName字段可以指定使用哪个物理引擎常见的有FastPhysicsEngine和ExternalPhysicsEngine。前者是 AirSim 自带的简化物理引擎计算速度快但精度一般后者允许你接入外部物理引擎精度更高但配置更复杂。UpdateRate参数控制物理引擎的更新频率单位是赫兹。这个值设得越高物理模拟越精细但计算开销也越大。默认值通常是 60 赫兹对于大多数场景已经够用了。如果你做的是高速碰撞或者精细操控相关的实验可以适当提高到 120 赫兹甚至更高。但要注意提高更新频率的同时也要相应减小仿真步长不然两者不匹配反而会出问题。车辆动力学参数方面Mass、DragCoefficient、RollingResistance这些参数会影响车辆的加速、刹车和转向特性。这些参数通常不需要改用默认值就行。但如果你发现车辆运动明显不符合预期比如加速太慢或者转弯太飘可以适当调整这些参数。调整的时候要一次只改一个参数改完跑一下看看效果不要一次改好几个不然出了问题都不知道是哪个参数导致的。4.3 天气与光照条件的配置天气和光照条件对视觉算法的影响很大AirSim 允许你在设置文件里配置这些参数。Weather字段下面可以设置Rain、Snow、Fog、Dust等天气效果的强度取值范围通常是 0 到 1 之间。雾天效果对视觉算法的影响特别明显。Fog参数设成 0.3 左右的时候能见度大概降到几百米远处的物体会变得模糊。这个效果可以用来测试算法在低能见度条件下的鲁棒性。但要注意雾天效果会显著降低图像对比度如果你的算法没有针对这种情况做处理性能下降会很明显。光照条件通过TimeOfDay参数来控制可以设置从 0 到 24 的小时数。不同时间点的光照角度和强度都不一样对视觉算法的影响也很大。我一般会在几个典型时间点分别测试算法性能正午 12 点光照最强傍晚 18 点左右光照角度低且偏暖色夜间 22 点则需要开启车灯才能看清道路。注意天气和光照参数会显著影响渲染性能。开启雾天效果后帧率可能会下降 20% 到 30%如果同时开启多种天气效果性能下降会更明显。做实时性要求高的实验时要权衡视觉效果和运行速度。5. 多车仿真与场景配置5.1 多车配置的写法与注意事项多车仿真在车队协同、交通流模拟等场景下很有用。配置多辆车的方法是在Vehicles字段下添加多个车辆条目每辆车有独立的名称和参数。比如你可以配一辆叫Car1的车和一辆叫Car2的车分别设置不同的初始位置和朝向。多车配置最容易出问题的地方是车辆初始位置重叠。如果两辆车的 X、Y、Z 坐标设得太近仿真启动后它们会撞在一起物理引擎会尝试把它们推开结果就是两辆车都在那里抖动。我一般让车辆之间至少保持 5 米以上的距离具体取决于车辆模型的尺寸。每辆车的传感器配置是独立的你可以给 Car1 配一个前视相机给 Car2 配一个激光雷达互不影响。这个特性在做异构传感器融合实验的时候特别有用。但要注意传感器数量增加会成倍增加计算开销如果同时开好几辆车的多个传感器对硬件的要求会比较高。多车仿真时还需要注意AutoCreate参数的设置。如果所有车都设成AutoCreate: true仿真启动时所有车都会自动出现在场景里。如果你希望某些车在特定条件下才出现可以设成false然后在代码里手动调用创建接口。5.2 场景子窗口与多视角显示SubWindows字段允许你在仿真窗口里同时显示多个视角的画面。每个子窗口可以绑定到不同的相机上这样你就能在一个屏幕上同时看到前视、后视、俯视等多个视角的画面。子窗口的配置包括WindowID、CameraName、ImageType、VehicleName等字段。WindowID是子窗口的编号从 0 开始CameraName指定这个子窗口显示哪个相机的画面VehicleName指定相机挂在哪辆车上。多车仿真的时候这个字段特别重要不指定的话子窗口可能显示的是错误车辆的画面。子窗口的布局可以通过Position和Size参数来控制。Position是子窗口左上角在仿真窗口中的坐标Size是子窗口的宽高。这些参数的单位都是像素。我一般把主视角放在左上角占大半个屏幕其他辅助视角放在右侧或者底部这样既能看清主画面又能随时参考其他视角的信息。实操心得子窗口数量不要太多一般 3 到 4 个就够了。开太多子窗口会显著增加渲染负担而且屏幕就那么大窗口太多每个都看不清。我试过开 6 个子窗口结果帧率直接掉到 20 以下完全没法做实时控制实验。5.3 录制与回放功能的配置AirSim 支持录制仿真过程并回放这个功能在调试算法和展示结果的时候很有用。录制相关的配置主要在Recording字段下面包括RecordOnStart、OutputFolder、RecordInterval等参数。RecordOnStart设成true的话仿真一启动就开始录制不用手动触发。OutputFolder指定录制文件的保存路径默认是用户文档目录下的AirSim/Recordings文件夹。RecordInterval控制录制的时间间隔单位是秒设得越小录制的帧越密集文件也越大。录制的内容包括车辆的位置、姿态、速度等状态信息以及各个传感器的数据。回放的时候可以按照时间轴查看任意时刻的仿真状态对分析算法行为很有帮助。但要注意录制文件可能会很大长时间录制的话要确保磁盘空间充足。我做过一个测试录制 10 分钟的多传感器数据文件大小超过了 2GB。回放功能通过simReplay接口来调用可以指定回放的起始时间和速度倍率。回放的时候仿真世界会按照录制时的状态重新呈现但你不能在回放过程中控制车辆只能观察。这个限制在做交互式调试的时候有点不方便但用来做结果展示和问题复现还是很实用的。6. 常见配置问题与排查方法6.1 配置加载失败的典型原因配置加载失败是最常见的问题表现是仿真启动后所有参数都是默认值你写的配置完全没生效。造成这个问题的原因通常有几个文件位置不对、文件名不对、JSON 格式错误、字段名拼写错误。文件位置和文件名的问题前面已经说过了这里重点说 JSON 格式错误。JSON 对格式要求很严格多一个逗号、少一个引号、括号不匹配都会导致解析失败。而且 AirSim 在解析失败的时候往往不会给出明确的错误提示只是默默地用默认配置这就让人很难排查。我的经验是每次改完配置文件后先用一个在线的 JSON 校验工具检查一下格式是否正确。这个步骤花不了几秒钟但能避免很多无谓的调试时间。另外改配置的时候尽量小步修改改几个参数就启动仿真验证一下不要一次性改一大堆不然出了问题都不知道是哪个改动导致的。字段名拼写错误也很常见。AirSim 的配置字段名是大小写敏感的VehicleType和vehicletype是两个不同的东西。我建议直接复制官方文档或者示例配置里的字段名不要自己手打避免拼写错误。6.2 传感器数据异常的排查思路传感器配置好了但数据不对这个问题比配置加载失败更隐蔽。常见表现包括图像全黑、深度图数值异常、激光雷达点云稀疏等。图像全黑通常是因为相机朝向不对镜头对着墙壁或者地面了。排查方法是把相机的Pitch、Roll、Yaw都设成 0看看能不能看到正常画面。如果还是全黑检查一下相机的安装位置是不是在车辆模型内部被车体挡住了。深度图数值异常可能是ImageType设错了。深度图要用DepthPlanar或者DepthPerspective如果用Scene类型去取深度数据拿到的就是彩色图像的像素值完全不是深度信息。这个错误很常见因为Scene是默认值很多人忘了改。激光雷达点云稀疏可能是PointsPerSecond设得太小或者NumberOfChannels太少。先检查这两个参数如果都正常再看看Range是不是设得太小导致很多点被截断了。6.3 性能问题的定位与优化仿真跑起来很卡帧率很低这个问题在配置了多个传感器或者复杂场景时经常出现。定位性能问题首先要确定瓶颈在哪里是渲染慢、物理计算慢、还是数据传输慢。一个简单的判断方法是逐个关闭传感器看帧率变化。如果关掉某个传感器后帧率明显提升那瓶颈就在这个传感器上。相机的渲染开销通常最大特别是高分辨率相机激光雷达的点云生成也很耗计算资源毫米波雷达相对轻量一些。优化性能的手段包括降低相机分辨率、减少激光雷达通道数、降低物理引擎更新频率、减少同时显示的传感器数量等。这些手段都会在一定程度上牺牲仿真精度需要根据实验需求来权衡。我的原则是先用最低配置跑通流程确认算法逻辑没问题后再逐步提高配置到满足实验要求的水平。还有一个容易被忽略的性能问题是磁盘 I/O。如果开启了录制功能而且录制频率很高磁盘写入可能会成为瓶颈。这种情况下可以降低录制频率或者把录制文件保存到更快的磁盘上。常见问题可能原因排查方法解决方式配置不生效文件位置或名称错误检查文件是否在正确目录且名为 settings.json移动到正确位置并重命名仿真启动崩溃JSON 格式错误用 JSON 校验工具检查修复格式错误图像全黑相机朝向或位置错误重置相机角度和位置调整 Pitch/Roll/Yaw 和坐标深度图异常ImageType 设置错误检查相机配置中的 ImageType改为 DepthPlanar 或 DepthPerspective帧率过低传感器配置过重逐个关闭传感器观察帧率变化降低分辨率或减少传感器数量车辆位置异常坐标系理解错误检查 X/Y/Z 值是否符合 NED 坐标系注意 Z 轴朝下地面以上为负值7. 配置文件的版本管理与复用策略7.1 用版本控制管理配置文件配置文件改来改去时间长了很容易忘记哪个版本对应哪个实验。我现在的做法是把settings.json纳入版本控制每次做重要实验之前先提交一个版本commit message 里写清楚这次实验的目的和主要配置变化。这样做的好处是实验可追溯。过了一个月回头看某个实验结果能准确知道当时用的是什么配置。如果发现某个配置有问题也能方便地回退到之前的版本。Git 这类工具对 JSON 文件的支持很好可以清晰地看到每次改动的具体内容。但要注意配置文件中可能包含一些本地路径信息比如录制文件的保存路径。这些路径在不同机器上可能不一样直接提交到版本库的话在其他机器上拉取后需要修改。我的做法是把这些机器相关的配置单独放在一个文件里用 Git 的 ignore 功能排除掉只提交通用的配置部分。7.2 配置模板化与参数化如果经常需要做不同条件的对比实验每次都手动改配置文件很麻烦而且容易出错。更好的做法是把配置文件模板化把需要变化的参数抽出来用脚本生成具体的配置文件。比如你可以写一个 Python 脚本接受天气条件、传感器配置、车辆数量等参数然后根据这些参数生成对应的settings.json。这样做对比实验的时候只需要改脚本的输入参数不用手动去改 JSON 文件。脚本还能保证生成的配置文件格式正确避免手写出错。参数化的另一个好处是实验条件可以精确记录。脚本的输入参数就是实验条件把这些参数和实验结果一起保存以后复现实验的时候直接重新运行脚本就行。这个做法在需要大量重复实验的场景下特别有用能节省很多时间。7.3 不同实验场景的配置切换做多个不同方向的实验时每个实验可能需要不同的配置。如果每次都手动改配置文件不仅麻烦还容易把之前实验的配置改乱。我的做法是为每个实验方向维护一份独立的配置文件放在不同的项目目录下。AirSim 的配置加载优先级正好支持这种做法。每个项目目录下放一份settings.json启动仿真的时候会自动读取当前项目目录下的配置。这样不同项目之间互不干扰切换项目就相当于切换了配置。如果有些配置是所有项目共用的可以放在用户文档目录下的settings.json里作为默认值。项目目录下的配置只需要写和默认值不同的部分相同的部分会自动继承。这个机制和 CSS 的层叠样式有点像能减少重复配置让每个项目的配置文件更简洁。实操心得我习惯在配置文件的注释里写清楚这份配置的用途和修改记录。JSON 标准不支持注释但 AirSim 实际上能容忍//开头的单行注释。利用这个特性可以在配置文件里加一些说明文字方便以后回顾。不过要注意加了注释的 JSON 文件用标准 JSON 工具校验会报错这是正常的不用管它。8. 写在最后配置文件的调整是个细活急不来。我刚开始用 AirSim 的时候总想一次性把所有参数都配好结果改了半天仿真都跑不起来。后来学乖了每次只改一两个参数改完就启动仿真验证确认没问题再继续改下一个。这样虽然看起来慢但实际上比一次性改一大堆然后花大量时间排查要快得多。还有一点体会是配置文件里的每个参数都有它存在的理由不要随便乱改。特别是物理引擎相关的参数改错了可能导致仿真结果完全不可信。如果确实需要调整先查清楚这个参数的含义和取值范围改完之后做对比实验验证效果确认符合预期再继续用。传感器配置这块我的建议是先用最简单的配置跑通整个流程确认数据采集、处理、算法、评估各个环节都正常然后再逐步增加传感器的复杂度和数量。一上来就配一堆传感器出了问题很难定位是哪个环节的毛病。