简介基于UE4与AirSim开发的无人机强化学习自主导航系统源码面向计算机科学、电子信息、智能科学与技术、控制工程等专业方向的师生及技术人员解决虚拟环境中无人机自主路径规划与动态目标追踪等智能控制问题。压缩包共775个文件以Python脚本、C头文件/源文件为核心辅以Markdown文档、PDF论文、示意图与构建脚本整体约149.52MB目录结构清晰便于分模块学习。已有60人学习。内容包含完整算法实现代码、毕业设计论文并附带构建脚本与参考文献程序均通过完整性测试该成果在毕业答辩中获得98分具备较高学术参考价值既可用于课程实践与毕设课题开发也可作为科研项目前期验证框架支持后续在决策模型、传感器融合与轨迹规划等方向深化拓展。1. 从仿真到飞控UE4与AirSim在无人机强化学习里到底扮演什么角色基于UE4与AirSim的无人机强化学习自主导航系统最常被低估的一环不是深度强化学习算法而是仿真环境本身的正确性。目标点在几十米外途经障碍物无人机要从图像或激光数据里学会“该往哪飞”AirSim负责把电机响应、重力、碰撞和传感器噪声翻译成状态流UE4负责让这个状态流里出现真实世界中的光影和纹理。这个方案适合刚好要做视觉导航、又不希望一开始就在真机上反复炸机的团队或者已经在用PX4飞控、想用硬件在环仿真先把策略验证一遍的人。下面按从搭建、封装环境、训练到迁移的顺序把能真正落地的那条路径完整走一遍。2. 搭一套能跑强化学习的UE4AirSim环境版本、工程结构与连接验证2.1 为什么是AirSim而不是Gazebo或凤凰无人机模拟器网上常有人问Gazebo生态不是更成熟吗Gazebo的优势在动力学和传感器插件但视觉渲染偏弱做端到端的视觉导航训练出来的策略一遇到真实光照就失效。凤凰无人机模拟器适合飞手练手感玩法很好但它的内核不对外暴露Python API更别提在训练循环里重置环境、设置目标点、读传感器。AirSim作为UE4插件提供多旋翼动力学、双目相机、深度图、激光雷达、GPS和IMU仿真而且Python API足够干净一个循环里可以完成“设置任务、跑几步、收观测、下发新指令”。这套搭配把“仿真环境”和“强化学习环境”之间的接口成本降得很低。如果你已经维护着一套ROS生态AirSim也有ros2接口但我的建议是训练阶段不要绕一层ROS桥直接在Python里消费API。绕行的代价是控制周期被拉长训练一小时后你会发现rosbridge的队列积压比算法收敛还让人头疼。2.2 最小工程结构地图、Settings.json与无人机参数我一般不会直接拿AirSim自带的小地图跑导航因为地图太小无人机一加速就到边界。常见做法是新建一个UE4工程用Block类地面铺一块足够大的区域再摆上一些立方体或静态网格体作为障碍物。为了让强化学习后期不过拟合障碍物位置不要贴死留出随机摆放的空间。提示UE4工程版本与AirSim插件版本务必匹配。不要用UE4.26搭配过老的AirSim插件否则编译通过的插件在打包后会出现连接失败这类奇怪问题。工程目录按下面这样组织UAVNavSim/ ├─ UAVNav.uproject ├─ Config/ │ └─ DefaultEngine.ini ├─ Content/ │ ├─ Maps/ │ │ └─ TrainingMap.umap │ └─ (障碍物模型、地面材质) └─ Plugins/ └─ AirSim/这个结构里最关键的是Settings.json。AirSim默认读取Documents/AirSim/settings.json但开发中我建议用环境变量AirSimSettingsFile指定到仓库内方便多人协作时同步无人机参数也避免改完配置找不到源头。Settings.json里的无人机部分我通常写成这样{ SettingsVersion: 1.2, SimMode: Multirotor, ClockSpeed: 1, Vehicles: { UAV: { VehicleType: SimpleFlight, UseSerial: false, DefaultCamera: { Pitch: 0, Roll: 0, Yaw: 0 }, Sensors: { Lidar: { SensorType: 6, Enabled: true, NumberOfChannels: 16, PointsPerSecond: 100000, Range: 40, HorizontalFOVStart: -90, HorizontalFOVEnd: 90, VerticalFOVStart: -15, VerticalFOVEnd: 15, RotationsPerSec: 10 } } } } }这个配置里SimMode: Multirotor决定飞的是多旋翼模型ClockSpeed: 1表示仿真时间与真实时间1:1训练时如果想让数据收集得更快可以调到2或4但动作时间步也会被加速需要同步调整控制频率。Lidar的16通道、40米量程是室内外通用的一组值通道越多点云越密但训练耗时也会明显上涨如果你的导航策略以视觉为主Lidar这一块可以先关掉用深度图做避障已经足够。地图上有一个常被忽略的点静态光照。UE4默认构建光照后场景里会有一层真实感很足的光影对视觉类强化学习来说光源角度不同会导致同一位置的图像差异很大。环境搭建阶段就把阳光角度、天光强度固定下来并做好lightmass相关配置后面训练时图像帧之间才不会出现整体亮度的漂移。2.3 用Python客户端验证连接起飞、悬停、收数据一条龙环境搭好后先用一个最小脚本验证端到端通信这一步能排掉80%的环境故障。脚本做的事是连接AirSim仿真器、解锁电机、起飞、悬停、读取一次相机图像和IMU数据。import airsim import numpy as np import time client airsim.MultirotorClient() client.confirmConnection() client.enableApiControl(True, UAV) client.armDisarm(True, UAV) client.takeoffAsync(timeout_sec10, vehicle_nameUAV).join() time.sleep(1) client.hoverAsync(vehicle_nameUAV).join() responses client.simGetImages([ airsim.ImageRequest(0, airsim.ImageType.DepthVis, False, False) ], vehicle_nameUAV) if responses and responses[0].width 0: depth_bytes np.frombuffer(responses[0].image_data_uint8, dtypenp.uint8) print(depth image size:, responses[0].width, x, responses[0].height, bytes:, len(depth_bytes)) imu_data client.getImuData(imu, vehicle_nameUAV) print(imu acc:, imu_data.linear_acceleration)这里confirmConnection()会持续尝试与UE4里的AirSim网络通信直到握手成功。enableApiControl(True)把无人机控制权从简单飞控切换到APIarmDisarm(True)模拟解锁takeoffAsync后面必须join()等待动作完成否则后续指令会挤在同一个时间片里导致异常。读取深度图时ImageType.DepthVis返回的是用像素灰度编码的深度不是直接的距离值转成以米为单位的深度需要额外的解码步骤否则奖励函数里算距离会产生肉眼不容易发现的偏差。连接验证通过后再在UE4编辑器里跑一遍PIE模拟确认地图中障碍物的碰撞体确实挂上了。若没有碰撞体无人机可能会直接穿过墙壁训练出来的避障策略就完全失真了。这个位置也是一线项目里最常翻车的地方不要因为代码跑起来了就默认物理世界是对的。3. 把自主导航包装成强化学习环境观测、动作、奖励与通信瓶颈3.1 观测空间RGB还是深度图或者两者都上导航策略的观测空间直接决定网络结构有多复杂。只给RGB图像网络要同时学会识别地面、墙壁、天空和距离在UE4的固定场景里很容易过拟合到纹理只给深度图避障信息很干净但没有颜色和纹理信息遇到透明物体或低纹理墙面时会吃亏。我一般把深度图作为第一优先因为导航任务的本质是空间感知而非语义识别深度图把“前面有没有东西、多远”直接编码出来网络学起来最快。深度图在AirSim里返回的是视差或欧几里得深度推荐使用ImageType.DepthPlanar或DepthVis。DepthPlanar给出的是平面深度类似相机坐标系下的Z值DepthVis是可视化编码后的8位灰度方便人眼调试但不适合直接作为网络输入。做训练时我通常请求DepthPlanar再归一化到[0,1]同时把IMU的加速度和角速度拼接进向量。还有一套更稳的输入组合是“深度图自身速度目标相对方位”这相当于给策略补了一部分状态信息比单纯堆图像更容易收敛。def get_observation(client): # 深度图 depth_resp client.simGetImages([ airsim.ImageRequest(0, airsim.ImageType.DepthPlanar, True, False) ], vehicle_nameUAV)[0] depth_img np.frombuffer(depth_resp.image_data_float, dtypenp.float32) depth_img depth_img.reshape(depth_resp.height, depth_resp.width) # 无人机状态 state client.getMultirotorState(vehicle_nameUAV) vel state.kinematics_estimated.linear_velocity ang_vel state.kinematics_estimated.angular_velocity # 目标相对位置在NED系下的分量 target_rel current_target_pos - state.kinematics_estimated.position obs { depth: depth_img / 100.0, # 归一化到 0~1 velocity: np.array([vel.x_val, vel.y_val, vel.z_val]), target_rel: np.array([target_rel.x_val, target_rel.y_val, target_rel.z_val]) } return obs这段代码里两个关键点一是DepthPlanar返回的是float32数组不能用image_data_uint8去解析否则图像全是错位的二是目标相对位置一定要转成无人机坐标系下的分量怎么转放到3.4节讲。深度除以100是经验值AirSim的深度单位是厘米但不同UE4工程可能因为单位缩放出现差异训练前先打印一帧深度图的最大值确认一下。3.2 动作空间速度指令比姿态指令更好学原因是什么无人机底层控制有两种常见方式给姿态角或给速度指令。直接用姿态角做动作空间策略要额外学习“多大俯仰角会产生多大加速度、多久才能变成期望速度”这一层动力学映射训练难度会明显增加。速度指令则不同AirSim内置的SimpleFlight飞控已经帮你做了姿态内环策略只需要输出“我想往哪边飞、飞多快”相当于把学习目标从“动力学控制”降维到“运动规划”。我常用的动作定义是四维向量[vx, vy, vz, yaw_rate]前三个范围在-1到1对应最大速度比例最后一个控制转向角速度。比如vx0.5代表以最大前向速度的一半向前飞。用moveByVelocityAsync下发指令def apply_action(client, action, max_speed5.0, duration0.5): vx float(action[0]) * max_speed vy float(action[1]) * max_speed vz float(action[2]) * max_speed yaw_rate float(action[3]) * 60.0 # 度/秒 client.moveByVelocityAsync( vx, vy, vz, duration, yaw_modeairsim.YawMode(True, yaw_rate), vehicle_nameUAV ).join()这里的duration就是决策周期同时也是强化学习的时间步长。0.5秒是一个兼顾密度和控制精度的值太短会导致环境交互太频繁、训练速度下降太长则避障反应迟钝无人机在高速靠近障碍时来不及转向。max_speed需要结合地图尺寸设定我一般先设成3到5米每秒训练稳定后再调大看策略上限。注意moveByVelocityAsync是非阻塞接口但.join()会等待指令完成强化学习循环里必须等它执行完再采集下一帧状态否则你拿到的观测和动作之间有时间差策略会学到一种“迟缓”的感觉。3.3 奖励函数稀疏奖励为什么会让训练直接翻车第一次跑无人机导航的人最容易把奖励设计成“到达目标点给1撞到障碍物给-1其他时候给0”。这种稀疏奖励在简单二维网格里可行但放到连续控制的多旋翼里无人机随机探索几百步都摸不到目标一次梯度信号几乎为零训练结果基本是原地打转。想让这个系统真正跑起来必须把奖励铺成一个连续的“地势图”让无人机每一步都能感受到自己在变好还是变坏。我常用的奖励函数是一个加权组合r 1.0 * delta_distance # 靠向目标的正向奖励 0.3 * exp(-distance / 5) # 距离目标越近额外给一份平滑奖励 - 0.02 * |v| # 轻微的速度惩罚防止高空乱冲 - 0.5 * (collision 1) # 碰撞大惩罚 - 0.05 # 每步时间惩罚推动策略走最短路径delta_distance是这一步执行后“无人机到目标点的欧氏距离”的减少量。这样即使没有到达目标无人机也能从距离缩短中获得正向反馈。exp(-distance/5)的作用是解决距离很远时梯度过小的问题相当于在目标附近放了一个引力井。速度惩罚不能太大否则无人机学成“龟速巡航”看起来避障很稳但效率极低0.02这个量级配合5米每秒的最大速度既不影响机动性又能压住原地画圈的坏习惯。还有一个容易被忽略的点EP回合长度的设限。我一般把单回合最长时间设为30秒到60秒的仿真时间到时间还没到达目标就强制结束并给一个负奖励。否则无人机卡在墙边时它会反复试探、累积一堆无意义的小奖励让价值估计出现偏差。3.4 环境交互循环坐标对齐、数据缓存与单步延迟把观测、动作、奖励串起来就成了一个标准的Gym式环境。我第一次写这个循环时踩过最深的坑是坐标系的混用。AirSim内部使用NED坐标系X朝北、Y朝东、Z朝下而UE4世界的坐标是Z朝上如果你直接拿UE4里的目标点位置减去AirSim读出的位置算出来的距离会差一个Z轴符号奖励时正时负训练完全无法收敛。在环境初始化时就要统一约定所有计算都在NED系下做UE4坐标只在放置目标点时做一次转换。import gym from gym import spaces import airsim import numpy as np class AirSimNavEnv(gym.Env): def __init__(self, target_ue4_pos): super().__init__() self.client airsim.MultirotorClient() self.client.confirmConnection() # 将UE4坐标转为NED坐标 self.target_ned self._ue4_to_ned(target_ue4_pos) self.action_space spaces.Box(low-1.0, high1.0, shape(4,), dtypenp.float32) self.observation_space spaces.Dict({ depth: spaces.Box(low0, high1.0, shape(84, 84), dtypenp.float32), velocity: spaces.Box(low-np.inf, highnp.inf, shape(3,), dtypenp.float32), target_rel: spaces.Box(low-np.inf, highnp.inf, shape(3,), dtypenp.float32) }) def _ue4_to_ned(self, p): # UE4: X,Y,Z - AirSim NED: X, Y, -Z return airsim.Vector3r(p[0], p[1], -p[2])target_rel在3.1节已经减过但那里用的是世界系下的目标位置。更稳的做法是把这个相对向量旋转到无人机机体坐标系用getMultirotorState读到的四元数做旋转得到一个“目标在我的前方多少米、左侧多少米”的表示。这个变换对策略来说至关重要因为策略要学的是“左转右转”不是“朝世界的东边飞”。旋转四元数可以直接用scipy.spatial.transform.Rotation每次step里做一次旋转的计算量很小但收敛速度的差异非常明显。环境循环里另一个痛点是数据缓存。AirSim的图像请求在训练中如果每个step都实时渲染、实时压缩传输交互频率会被拖到5Hz以下。我一般会调低图像分辨率到84x84或64x64同时把ImageRequest的compressFalse设为false直接取原始float数据减少CPU在解压上的开销。单步延迟控制在0.2到0.5秒是一个合理区间如果低于这个值优先怀疑是不是启用了垂直同步或渲染分辨率过高。4. 训练自主导航策略PPO、超参、网络结构与飞行指标4.1 策略网络与价值网络的结构选择PPO为什么是默认起点无人机自主导航是一个典型的高维连续控制问题深度强化学习算法里PPO是最稳的起点。TRPO的理论更漂亮但实现复杂DDPG和TD3对超参敏感reward scale稍微一变就容易发散PPO用clip限制策略更新幅度稳定性和样本效率之间的平衡在仿真环境里表现得最省心。如果你已经把David Silver那套强化学习基础吃透了PPO的loss公式理解成本也很低。网络结构上图像输入先过一个轻量CNN三层卷积加ReLU把84x84深度图压成256维特征然后和速度向量、目标相对位置拼接再送入两个共享的MLP层最后分别输出动作均值、价值估计。为什么不单独做两个网络因为导航任务的图像特征和状态价值高度相关共享底层可以加速特征提取的收敛训练显存也更省。import torch import torch.nn as nn class NavPolicy(nn.Module): def __init__(self, img_size84, state_dim6, action_dim4): super().__init__() self.cnn nn.Sequential( nn.Conv2d(1, 16, kernel_size8, stride4), nn.ReLU(), nn.Conv2d(16, 32, kernel_size4, stride2), nn.ReLU(), nn.Conv2d(32, 32, kernel_size3, stride1), nn.ReLU(), nn.Flatten(), ) # 卷积输出维度需要根据输入尺寸调试确定 self.feature_dim 32 * 4 * 4 state_dim self.common nn.Sequential( nn.Linear(self.feature_dim, 256), nn.ReLU(), ) self.mean_head nn.Linear(256, action_dim) self.log_std_head nn.Parameter(torch.zeros(action_dim)) self.value_head nn.Linear(256, 1) def forward(self, depth, state): feat self.cnn(depth) x torch.cat([feat, state], dim1) x self.common(x) mean torch.tanh(self.mean_head(x)) value self.value_head(x) return mean, valuelog_std_head是PPO里学习到的动作标准差初始全0意味着分布的标准差为1配合tanh的输出层动作范围被限制在-1到1正好匹配Gym环境里action_space的边界。这里有个细节标准差不通过共用的common层而是单独一个参数这样策略网络更新时梯度更新标准差的方式更稳定不容易因为特征层的抖动导致探索噪声剧烈变化。4.2 一套能直接起步的超参数表超参这个东西不同环境会不一样但我有一套在AirSim导航场景里能直接起步的默认值。这里的数值不是硬编码的最优方案而是给把你从“跑不起来”带到“能看曲线变化”的基准。参数推荐值说明learning_rate3e-4Adam优化器不需要线性衰减n_steps2048每轮采样步数约对应17分钟仿真数据batch_size128小批量更新防止单批图像过于相关n_epochs10每次都把采样数据过模型10遍gamma0.99折扣因子适配30秒回合的长度gae_lambda0.95平衡偏差和方差值越大越偏向长期优势clip_range0.2PPO剪裁范围开头训练不用调小ent_coef0.01熵系数保持探索压制策略过早固化max_grad_norm0.5梯度裁剪防止奖励尖峰带来参数爆震训练时建议先关掉随机障碍物在一个固定地图上跑通全流程模型学会一条路线以后再开Domain Randomization随机化障碍物位置、光照强度和起点方向。这个递进方式的成功率比一开始就全随机高出很多因为导航策略要先建立“目标相对位置深度图像→速度指令”的基本映射而不是同时面对多个维度变化。4.3 训练中的飞行指标怎么看导航是否学到还是死记硬背训练日志里最骗人的是“episode mean reward不断上升”因为奖励函数里包含距离减少量无人机只要学会向前飞就能拿正奖励不一定真的在避障。我一般会额外记录三个核心导航指标成功率、平均到达时间、碰撞率。成功率是回合结束时距离目标小于1.5米才判定为成功平均碰撞率则按“本回合是否发生过碰撞”统计因为一次碰撞就足以让策略在实机时失控。我习惯在每个评估节点里把无人机重置到固定起点目标点放在一个从未出现在训练数据里的位置跑20个回合看统计。如果成功率不错但碰撞率很高说明策略学会了直线飞行但不擅长避障需要把障碍物相关奖励加大或者在奖励里加一个“近障减速”的引导项。还有一个判断策略是否“学死”的土办法把深度图输入随机遮挡下半部分再跑同一个回合。如果策略表现骤降说明它把大量注意力放在地面纹理上而不是空间结构上这种情况在真实场景迁移时一定要警惕。正常训练下策略应该对地面纹理变化不敏感主要依赖深度轮廓。4.4 传统路径规划与强化学习端到端之间的取舍团队里通常会有人质疑这个问题用A*或RRT加一个避障控制器就能解决为什么还要上强化学习这个质疑是对的。如果任务是静态环境下的最短路径无人机三维路径规划用传统算法成熟且可解释但如果你希望无人机在未知环境中根据传感器输入实时反应并且环境结构会在飞行中发生变化强化学习策略的价值就体现出来了。端到端训练的模型可以做到“所见即所得”从深度图直接映射到期望速度省去SLAM建图、路径重规划、轨迹跟踪中间那一大串模块。从工程成本看我建议采用“先传统后强化”的路线。第一步用A*做全局路径输出一串路径点第二步用强化学习学一个小型避障控制器跟踪路径点同时避开临时出现的障碍。这样全局规划保证方向正确局部策略负责反应速度整套系统的成功率要比纯端到端高很多也更容易定位是哪个环节出了问题。5. 避坑手册UE4构建发黑、AirSim连不上、奖励不收敛的排查思路5.1 UE4构建光照后发黑现象在UE4编辑器里按下构建光照场景模型正常但画面整体发黑无人机相机图像在AirSim里看过去像夜里没开灯。原因有两类一类是场景里没有有效的Lightmass重要体积或者光源没有开启静态光照另一类是AirSim飞行时摄像机处于某个没有光照构建体积覆盖的区域。解决先检查UE4的Build Lighting是否报错重点看Lightmass日志里有没有“Zero lightmap”一类提示。然后把地面和墙壁的材质LightingMode设为静态或固定重新搭建光照。如果只是某个区域黑把Lightmass Importance Volume放大到覆盖整个飞行区域。这个坑在训练前不解决深度图会整体偏暗归一化之后噪声占比大大增加策略学到的全是像素噪声。5.2 AirSim连接超时或直接崩溃现象Python脚本执行到confirmConnection()就卡住或者UE4运行时直接弹窗闪退。原因最常见的三个AirSim插件没有正确加载、端口被占用、设置文件路径没被读到。解决先看UE4的Output Log里有没有“AirSim initialized successfully”字样再检查防火墙是不是拦截了UDP 14251端口的进程最后确认环境变量AirSimSettingsFile指向的路径真实存在。如果都不行把UE4工程从中文路径移动到纯英文路径下这个看似无关的步骤能解决一大批插件加载失败问题。开发这类仿真系统我遇到崩溃的第一反应就是看日志而不是反复重启工程。5.3 训练loss下降但无人机原地打转现象PPO的critic loss和actor loss都在下降平均reward也在涨但可视化无人机在起点附近画圈从来到不了目标点。原因通常是奖励设计里距离奖励和角速度奖励互相冲突或者目标相对坐标没有转到机体坐标系。解决先在环境里做一次“最短路测试”即把目标放到无人机正前方3米让策略网络输出一个全为0的动作看无人机是否直飞目标。如果发现它在原地转大概率是target_rel方向反了或坐标轴顺序错了。我当初就踩过这个坑NED坐标系下Y轴向右但机体坐标系里偏航顺时针为正直接把Y分量塞进yaw_rate会让无人机朝目标的反方向转向。修正方法是把target_rel用机体四元数旋转时注意偏航角和向量旋转的左手右手关系。如果排除了坐标问题再把时间惩罚0.05调大一点比如0.08强制策略不要在原地磨蹭。5.4 仿真飞得好实机就失灵现象仿真成功率95%换到真实无人机带光流或视觉定位时策略频繁撞墙或者抖动剧烈。本质是Sim-to-Real的域差异包括相机畸变、动态模糊、光照条件、甚至电机响应延迟。解决在训练时加入域随机化把深度图加一点高斯噪声随机化地面材质颜色和光照角度把无人机的质量参数在10%范围内扰动。AirSim支持通过Settings.json改重力、阻力系数和最大推力开一个随机炮台跑训练。另一个重要措施是做硬件在环仿真测试把训练好的策略接到PX4的硬件在环仿真里跑验证控制器接口的输出频率和飞控协议匹配后再上真机。上真机之前还要注意动作频率不能太高把策略输出用一阶低通滤波器平滑一下否则飞控收到的指令频繁跳变电调会发出尖锐的噪声并很快发热。5.5 训练到一半仿真器崩溃怎么留后悔药现象训练跑到第40个小时UE4编辑器突然崩溃之前训练的权重还没保存只能从头再来。这个问题在长时间训练里几乎是必然发生的所以环境里一定要有检查点机制。解决在训练循环的每个step里检测进程状态同时模型权重每1000步保存一次到本地并在另一个线程里记录训练的reward曲线。对UE4崩溃的场景建议用AirSim的simPause接口做定时快照把障碍物位置、无人机坐标和当前回合进度写入JSON重新启动时直接从最近一次快照恢复环境。没有后悔药的设计长训练就是一场赌运气的游戏。6. 验证与迁移一张检查表和一个把策略搬上真机的习惯6.1 在仿真里验证导航策略的三级检查表第一级是静态验证固定起始点、固定目标点跑50回合记录成功率和平均飞行时间。这一级通过只代表策略在特定场景下有效。第二级是随机化验证每次回合随机化起始点、目标点和障碍物位置跑200回合统计成功率、平均碰撞次数、平均路径长度与最短路径长度的比值。若比值超过1.5说明策略绕了远路需要增大距离奖励权重。第三级是鲁棒性验证在深度图中注入5%到15%的随机椒盐噪声同时把Lidar数据丢给策略做对比确认策略在传感器部分失效时不会直接撞墙。三级全部通过之后这个策略才算有了上真机的资格。6.2 把策略搬上真机前先过一遍“传感器替身”测试我的习惯是在真机测试前先做一轮“传感器替身”测试把仿真中使用的深度图输入格式、动作频率、动作范围原样映射到真机的视觉感知模块上用真机采集一段离线数据在笔记本上实时跑策略推理观察输出指令是否平滑。如果输出抖动剧烈就先加滤波器而不是急着起飞。这个习惯帮我避开了很多“仿真一个样、实机另一个样”的尴尬。导航策略上线真机时第一架次不要直接跑自动避障先把垂直速度限制在0.2米每秒、水平速度限制在1米每秒遥控器常驻急停给策略划定一个足够空旷的场地。不要相信仿真里的成功率数字真机的风场、视觉延迟和电机响应差异都会让策略的“手感”完全不同。我个人的教训是迁移永远要比仿真多留出一倍的冗余空间。希望帮到你。本文还有配套的精品资源点击获取