ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

基于UE4+AirSim的多旋翼飞行仿真平台设计与实现

基于UE4+AirSim的多旋翼飞行仿真平台设计与实现 简介无人机仿真技术是低成本验证飞行控制与视觉感知算法的关键手段。通过虚拟环境复现多旋翼动力学、传感器噪声及光照变化可支撑目标检测、避障与路径规划等算法的快速迭代。UE4引擎提供高逼真渲染AirSim则内置完整的飞控模型与IMU、GPS、LiDAR等传感器接口两者结合构建的仿真平台既能输出带标注的视觉数据集又能通过API实现自主飞行控制与PX4/ROS2软硬件在环扩展。该方案适用于科研毕设与实验室预研尤其适合缺乏实机条件的场景可大幅降低实验成本并提升算法验证效率。从需求分析到传感器配置从数据采集到算法验证完整呈现了一套可复现的工程实践路径。 我见过太多人把毕设题目定成无人机仿真平台最后交出来的东西却是个空壳子——能起飞、能拍图、能看个画面然后就没了。评审老师问一句你的传感器数据能导出来做目标检测吗避障算法验证了吗就答不上来。所以当我自己做这个基于UE4AirSim的多旋翼飞行模拟仿真平台时定的底线很明确它必须是一个能支撑完整科研闭环的仿真环境而不是一个花架子演示。项目源码的定位是毕业设计但最终沉淀下来的东西比单纯交差要扎实得多——包括场景建模、传感器仿真、视觉数据采集、自主飞行控制以及一套可以切换的飞控通信接口。这篇博文我就把这个项目的完整拆解过程、选型逻辑、架构设计、关键实现和踩过的坑一次性讲清楚。适合正在做相关毕设、或者想给课题组搭一套无人机仿真环境的同学参考尤其是那些手里只有一块显卡、没有实机条件的实验室。1. 为什么选UE4AirSim做无人机仿真需求分析与方案权衡1.1 毕设题目的演化过程与选型逻辑我最初的题目其实不是仿真平台而是基于深度学习的无人机目标检测系统。但真正开题之后发现一个现实问题没有无人机实机也没有专门的数据采集场地全靠开源数据集训练模型最后只能跑跑实验、看看指标连一段自己采集的无人机视角视频都没有。这个软肋在答辩时非常致命。然后我开始想怎么造一套环境出来。当时可选的路线有三条。第一条是 Gazebo PX4 的经典仿真组合。这条路线社区活跃、资料多而且能直接跑PX4固件和实飞逻辑几乎一致。但Gazebo的画面渲染能力太弱了光照、纹理、天气变化都不真实做视觉类任务时模型在仿真里训练完迁移到真实场景泛化能力堪忧。第二条是 Unity 下的无人机仿真方案。Unity的渲染效果好C#写脚本也快但问题在于和飞控生态的耦合度官方没有一套像AirSim那样完整的多旋翼动力学模型和传感器噪声模型很多底层物理都要自己补工程量直接起飞。第三条就是 UE4 AirSim。AirSim是微软开源的无人机/汽车仿真平台基于虚幻引擎动力学模型、IMU、GPS、气压计、相机、激光雷达这些传感器一应俱全而且支持通过API直接控制无人机、读取图像和状态还可以配合PX4做硬件在环。渲染真实度方面UE4本身有完整的光照系统配合AirSim的场景编辑能模拟不同时间段、不同天气下的视觉环境。最后选的当然是第三条。理由很朴素我需要一个好用的视觉仿真器同时又要保证飞控逻辑的真实性不能只在画面上好看。AirSim在这两点上恰好都有比较成熟的解决方案。1.2 UE4与Unity、Webots、Gazebo等方案的对比取舍关于选型我后来给师弟师妹讲的时候喜欢用一张表来对比这样最直观维度UE4AirSimUnity自研/商业插件GazeboPX4Webots渲染真实度高高低低飞控兼容性好支持PX4硬件在环中好官方支持中传感器仿真丰富度高相机、LiDAR、IMU、GPS等中高中二次开发成本中有完整C/Python API高物理模型需自建中中资料与社区好一般很好一般科研论文认可度高中高中从这张表能看出Gazebo在飞控生态上是最强的但视觉表现是硬伤Unity画面够好但物理和传感器生态需要大量自建Webots定位是教学和基础机器人仿真对无人机多旋翼的支持没有AirSim细致。AirSim的优势在于视觉与物理的平衡。它内置了多旋翼的动力学模型包括桨叶响应、惯量、空气阻力模型虽然不是完全精确的CFD级仿真但用于验证控制算法和视觉感知算法绰绰有余。而且它有丰富的传感器API意味着你可以程序化地控制相机开关、读取捕捉到的图像数据、获取IMU和GPS的带噪声数据这些对于做深度学习数据集和感知算法验证是非常重要的。2. 环境搭建与版本选型从零跑通AirSim Demo这一部分是最容易被忽略、但又最容易劝退的。AirSim的编译对版本匹配极其敏感我当时在搭建环境上就花了两天。这里直接把版本对应关系写出来能帮读者省掉大量时间。2.1 UE4版本与AirSim分支的对应关系AirSim每个版本对UE4的版本有明确的对应关系。我用的是AirSim v1.8.1对应UE4 4.27。这个组合比较经典——UE4 4.27是4代引擎的最终版本很稳定AirSim v1.8.1修复了此前版本中大量的传感器和物理问题。安装流程大致是这个样子从Epic Games Launcher安装UE4 4.27。这里有个坑必须安装完整版而不仅仅安装引擎因为AirSim需要基于源码编译自定义的Unreal Engine插件。克隆AirSim源码git clone gitgithub.com:microsoft/AirSim.git切换到对应的release分支v1.8.1。进入AirSim/Unreal/Environments/Blocks目录运行update_to_git.bat脚本生成UE4工程文件。用Visual Studio 2019或者2022打开生成的.uproject文件对应的Blocks.sln等待编译完成。这一步里最容易出的问题是UE4的构建工具版本和VS版本不兼容。我建议使用VS2019如果电脑里只装了VS2022可以安装使用C的游戏开发工作负载然后确保安装了 .NET Framework 4.8 SDK。UE4 4.27中对VS2022的支持不如VS2019顺滑容易在链接阶段报一堆莫名错误。编译过程通常需要40到60分钟取决于CPU性能期间会编译整个UE4编辑器插件这是正常的。完成之后打开Blocks.uproject如果编辑器能正常加载AirSim的设置面板就说明基础环境通了。2.2 settings.json关键参数配置解析AirSim启动后会读取Documents/AirSim/settings.json这个文件是整个仿真环境的配置核心。我在这里贴上我实际使用的配置片段并对关键参数做注释说明{ SettingsVersion: 1.2, SimMode: Multirotor, ClockSpeed: 1, PhysicsEngine: FastPhysics, Vehicles: { Drone1: { VehicleType: SimpleFlight, DefaultVehicleState: Armed, EnableCollisionPassthru: false, EnableCollisions: true, RC: { RemoteControlID: 0, AllowAPIWhenDisconnected: true }, Sensors: { imu: { SensorType: 2, Enabled: true }, gps: { SensorType: 3, Enabled: true, Eph: 1.5, Epv: 1.5 }, barometer: { SensorType: 1, Enabled: true }, lidar: { SensorType: 6, Enabled: true, NumberOfChannels: 16, PointsPerSecond: 100000, Range: 30.0 }, front_center_custom: { SensorType: 0, Enabled: true, CaptureSettings: [ { ImageType: 0, Width: 640, Height: 480, FOV_Degrees: 90, AutoExposureMethod: 1, AutoExposureSpeed: 0.5 }, { ImageType: 3, Width: 640, Height: 480, FOV_Degrees: 90 } ] } }, Cameras: { down_follow: { CaptureSettings: [ { ImageType: 0, Width: 1280, Height: 720, FOV_Degrees: 80, X: 0, Y: 0, Z: -1, Pitch: -90, Roll: 0, Yaw: 0 } ] } } } }, Recording: { RecordOnMove: true, RecordInterval: 0.05, Cameras: [front_center_custom, down_follow] }, CameraDefaults: { CaptureSettings: [ { ImageType: 0, Width: 640, Height: 480, FOV_Degrees: 90 } ] } }说几个容易踩的细节。PhysicsEngine: FastPhysics是AirSim自己实现的一套简化物理引擎速度比PhysX更快适合视觉和数据采集任务但如果你要特别精确的动力学建模考虑用PhysX模式。对于大多数毕设级别的控制算法验证FastPhysics足够了。默认情况下AirSim控制台的输出会有一堆调试信息如果要做数据采集可以把Recording: { RecordOnMove: true }打开这样无人机在移动时自动记录传感器数据而悬停时不记录避免录入大量无意义重复帧。AllowAPIWhenDisconnected我记得设为true非常重要——它能让你在没有连接遥控器的情况下也能通过Python API控制无人机。很多人在室内测试时连不上遥控器然后发现无人机不响应API根源就在这里。2.3 编译与启动流程编译成功后启动流程也有讲究。常规流程是打开Blocks.uproject等待编辑器加载完成。点击编辑器顶部的 Play 按钮进入游戏模式。此时会出现AirSim的设置窗口和无人机模型通过键盘、遥控器或API控制。但真正做自动化实验的时候每次手动点击Play非常痛苦。我后来写了一个批处理脚本直接用UnrealEditor-Cmd.exe的无头模式启动仿真环境C:\Program Files\Epic Games\UE_4.27\Engine\Binaries\Win64\UnrealEditor-Cmd.exe D:\Projects\AirSim\Unreal\Environments\Blocks\Blocks.uproject -game -ResX1280 -ResY720 -Windowed -NoSplash用-game参数可以跳过编辑器直接进入游戏模式这样Python脚本就能直接连接API实现全自动仿真。另外-NoSplash可以避免启动动画阻塞进程这在批量跑实验时很关键。启动之后在Python一端import airsim client airsim.MultirotorClient() client.confirmConnection() client.enableApiControl(True) client.armDisarm(True) client.takeoffAsync().join() client.moveToPositionAsync(10, 0, -5, 5).join()这套API基本上所有接触过AirSim的人都用过但值得注意的一点是客户端连接之前必须确认UE4工程已经启动完成否则confirmConnection()会一直阻塞等待。所以脚本里建议加一个超时重试机制而不是让训练任务卡死。3. 仿真平台整体架构设计与源码组织3.1 基于AirSim的二次开发模块划分AirSim功能再全终究是微软的通用平台不是为你的毕设量身定制的。拿到源码之后最重要的一步是理解它的模块结构然后决定哪些保留、哪些改、哪些新增。AirSim的代码结构大致如下AirLib独立于UE4的库包含无人机/汽车的核心动力学模型、传感器模型和控制逻辑。Unreal/Plugins/AirSimUE4插件层负责把AirLib和Unreal Engine渲染/物理引擎对接起来。PythonClientPython API客户端通过RPC协议和AirSim进程通信。MavLinkComMavLink通信组件用于连接真实飞控PX4等。我自己的项目源码在这个基础上做了三层架构第一层是基础环境层直接复用AirSim的动力学和传感器不修改底层物理保证稳定性。第二层是业务控制层封装了无人机任务控制模块包括起降流程、航点飞行、悬停、路径跟踪、避障策略切换等都在这一层实现。这一层是项目源码中我自己写的部分所有核心逻辑都在这里。第三层是算法集成层把目标检测模型、路径规划算法、视觉避障算法包装成独立模块通过接口和数据控制层交互方便替换和扩展。这种分层的最大好处是算法层写坏了不会影响底层仿真控制层调参不需要动传感器配置每个模块都能独立测试。3.2 无人机动力学模型与多旋翼控制接口AirSim的SimpleFlight模型虽然比真实PX4要简化但它的API设计思路和真实飞控非常接近。我基于这个模型实现了完整的多旋翼控制接口包括姿态控制setRollPitchYawrateThrottleAsync用于直接控制角速度和油门前馈位置控制moveToPositionAsync实现航点定位速度控制moveByVelocityAsync用于直线匀速飞行轨迹追踪moveOnPathAsync按照路径点序列飞行。在实现自主飞行任务时我大量使用的是moveToPositionAsync和moveOnPathAsync的组合。一个典型的巡检任务代码逻辑如下# 定义巡检路径点 waypoints [ airsim.Vector3r(0, 0, -10), airsim.Vector3r(5, 0, -10), airsim.Vector3r(5, 5, -10), airsim.Vector3r(0, 5, -10), ] # 按路径点飞行 for wp in waypoints: client.moveToPositionAsync(wp.x_val, wp.y_val, wp.z_val, 5).join() # 悬停并采集数据 time.sleep(2)这里有一个关键点AirSim的坐标是NED坐标系Z轴向下所以高度是负数。很多新手第一次用这个API时想着飞到10米高度写成了z10结果无人机直接钻进地下。这个坑在答辩演示的时候如果发生场面会非常尴尬。3.3 环境场景建模与传感器配置场景建模方面AirSim自带的Blocks环境是一堆积木块视觉太单调做目标检测训练效果非常受限。后来我在UE4里用一个最简单的建筑场景作为主场景给无人机布置了类似园区巡飞的任务。这里其实不用自己从零搭建模型。UE4商城有大量免费和付费场景资源我选了一个现代城市风格的小型场景大致80米乘80米范围包含建筑物、地面、柱子等障碍物足够无人机进行路径规划和避障测试。场景搭建时要注意一个物理细节UE4场景中的碰撞体必须正确设置否则AirSim的碰撞检测会失效无人机会直接穿墙而过。这个在检查时最好通过AirSim的碰撞检测接口来验证collision_info client.getCollisionInfo(Drone1) if collision_info.has_collided: print(无人机发生碰撞碰撞点, collision_info.position)传感器配置我在2.2节已经给了完整的settings.json示例。这里再补充一点关于相机的建议如果你要做目标检测建议至少配置两个相机一个前视广角一个下视这样数据多样性能更好。前视相机用于水平目标识别比如行人、车辆下视相机用于地面目标搜索比如二维码、地面标记两种数据结合起来训练出的模型鲁棒性会好很多。4. 核心功能实现视觉感知、数据采集与自主飞行控制4.1 相机传感器配置与图像数据采集流程视觉数据采集是整个平台里最耗时间、也最容易出问题的一环。AirSim的图像采集接口返回的是airsim.ImageResponse对象里面包含像素数据和元数据。关键要理解的是图像格式的问题AirSim的图像类型定义中ImageType.Scene类型0返回的是场景图也就是RGB图像ImageType.DepthPlanar类型3返回的是深度图ImageType.Segmentation类型4返回的是语义分割图。我用得最多的是场景图和深度图前者做目标检测后者做避障深度估计。采集数据的核心代码def capture_data(client, vehicle_name, save_dir, frame_id): responses client.simGetImages([ airsim.ImageRequest(front_center_custom, airsim.ImageType.Scene, False, False), airsim.ImageRequest(front_center_custom, airsim.ImageType.DepthPlanar, True, False) ], vehicle_namevehicle_name) for response in responses: if response.image_type_uint airsim.ImageType.Scene: img np.frombuffer(response.image_data_uint8, dtypenp.uint8) img img.reshape(response.height, response.width, 3) cv2.imwrite(f{save_dir}/rgb_{frame_id:06d}.png, img) elif response.image_type_uint airsim.ImageType.DepthPlanar: depth np.array(response.image_data_float, dtypenp.float32) depth depth.reshape(response.height, response.width) np.save(f{save_dir}/depth_{frame_id:06d}.npy, depth)这里有个细节simGetImages的第二个参数是pixels_as_float只有深度图才需要设为TrueRGB图设为False返回uint8否则你会拿到一堆花屏的乱码数据。这个参数写错是数据采集阶段最常见的错误之一。另外图像保存时要注意无人机飞行速度和数据采集频率的匹配。如果飞行速度太快、采集频率太低会造成轨迹上数据点稀疏如果飞行速度太慢、采集频率过高前后帧差异又太小训练出来的模型容易过拟合到局部特征。我实测下来飞行速度3米/秒、采集频率10Hz是比较合理的一组参数覆盖面积和帧间差异性相对均衡。4.2 目标检测与视觉回传链路项目里我做了两个视觉任务一个是地表目标检测另一个是简单场景下的障碍物定位。地表目标检测的思路是给无人机设定一条航线让它飞过一个实验区域下视相机持续采集图像然后把图像序列交给一个预训练的检测模型我用了YOLOv5s作为基线检测地面上预先布置的目标。仿真环境里布置目标的方式是直接在UE4场景中放置静态网格体Static Mesh可以是盒子、圆柱、球体等。对应地在语义分割模式下这些物体会以不同颜色显示可以直接跑语义分割算法也可以作为标注数据来源。这里我特别推荐一个数据采集技巧用AirSim的语义分割图像做自动化标注。在场景中给每个目标设置唯一的SegmentationId这样在语义分割模式下每个目标都有独立的颜色标签直接通过颜色阈值就能从语义分割图生成实例级标注框不需要手工标注成本极低。# 从语义分割图生成目标检测的BBox标注 def seg_to_bbox(seg_img, target_seg_id): mask np.all(seg_img target_color, axis-1) contours, _ cv2.findContours(mask.astype(np.uint8), cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_SIMPLE) bboxes [] for cnt in contours: x, y, w, h cv2.boundingRect(cnt) if w 20 and h 20: # 过滤过小目标 bboxes.append([x, y, x w, y h]) return bboxes这样处理下来我一周内就生成了一套2000多张带标注的仿真巡检图像数据集然后拿这套数据微调了YOLOv5模型。用同样的模型在真实校园场景拍摄的图像上做测试mAP能达到真实数据训练版的70%左右对于毕设级别的验证完全足够了。4.3 路径规划与避障算法的仿真验证路径规划和避障是仿真平台的主要验证对象之一。在项目里我实现了两种避障策略一种基于激光雷达数据另一种基于深度相机数据。激光雷达方案比较直接。AirSim的LiDAR传感器返回点云数据通过client.getLidarData()获取点云数据包含位置、强度、时间戳等信息。我用了一个简单的障碍物检测算法把点云投影到水平面计算当前飞行方向上的最近障碍物距离如果小于安全距离阈值就触发绕行。深度相机方案更有挑战性也更贴近实际部署。我用前视深度相机获取深度图然后通过深度阈值判断前方是否有障碍物def obstacle_avoidance(client, safety_distance2.0): responses client.simGetImages([ airsim.ImageRequest(front_center_custom, airsim.ImageType.DepthPlanar, True, False) ]) depth np.array(responses[0].image_data_float, dtypenp.float32) depth depth.reshape(responses[0].height, responses[0].width) center_depth depth[depth.shape[0]//3:2*depth.shape[0]//3, :depth.shape[1]//2] min_depth np.min(center_depth) if min_depth safety_distance: return obstacle else: return clear当检测到障碍物时控制逻辑会暂停当前路径跟踪切换到绕行模式绕过去后再回到原路径点继续执行。实测在场景中布置几个障碍物后无人机能够自动绕开并继续完成任务整个链条跑通后答辩演示效果非常好。4.4 基于PX4/ROS2的软硬件在环扩展这个平台的一个核心卖点是不仅能跑AirSim自带的SimpleFlight还能对接PX4和ROS2。AirSim对PX4的支持是通过MavLink通信实现的。配置流程大致是在本地或虚拟机上运行PX4 SITL固件AirSim通过UDP和PX4通信。AirSim中车辆类型设为PX4并配置MavLink的通信参数。运行ROS2环境中连接AirSim的桥接节点实现话题订阅和发布。我在项目中做了一个额外的ROS2接口层把AirSim的图像数据和位姿数据发布到ROS2话题上同时订阅ROS2中的控制命令转发给AirSim中的无人机。这样整个仿真环境就变成了一个标准的ROS2机器人开发环境可以方便地和课题组已有的算法栈对接。需要特别说明的是PX4AirSim联调涉及UDP端口配置、MavLink消息频率适配、时延处理等多层问题是整个项目中最难调试的部分。我建议首次尝试时先不要开启PX4用SimpleFlight模型完成算法验证等流程跑通了再切换PX4否则很容易陷入多层调试的泥潭。这也是我项目源码里保留了SimpleFlight和PX4两种车辆类型配置的原因方便不同阶段按需切换。5. 项目调试过程中踩过的坑5.1 UE4版本升级与场景加载崩溃问题我在开发中期踩过一个很恶心的问题场景加载到一半就崩溃没有任何有效日志。排查了很久最后发现是场景中有个模型使用了不兼容的材质资源导致UE4的渲染管线崩溃。这种问题的排查思路是二分法先把场景中的所有物体逐个删除每删一个跑一次加载看能不能正常启动。找到问题物体后检查其材质是否用了MaterialInstanceDynamic或MaterialParameterCollection等动态资源如果有改为静态材质就能解决。另外UE4的崩溃日志默认位置在Saved/Logs/目录下文件名类似UE4-YYYY-MM-DD-HH-MM-SS.log。崩溃前几行常常会有关键的断言信息排查时要先看这里不要盲改代码。5.2 AirSim与PX4/ROS2联调的经典错误PX4联调时最容易犯的错是坐标系理解偏差。PX4使用的是NED坐标系ROS2通常使用ENU坐标系两点之间的转换如果少了一步无人机会朝完全错误的方向飞。我一开始就因为这个把无人机飞出了场景边界API控制返回报错。还有一个高频错误是UDP端口冲突。PX4默认端口号是14540AirSim和PX4通信要用另一个端口。如果端口配置不正确AirSim的连接会一直超时。这时候用Wireshark抓包看一下UDP流就能快速确认问题。ROS2和AirSim桥接时消息类型和时间戳必须对齐。如果订阅的图像话题类型定义不一致即使能接收到图像时间戳对不上运行的SLAM或检测算法也会出问题。建议在桥接层做一次时间戳统一以AirSim的仿真时间为基准避免两个系统的墙钟差异带来问题。5.3 数据集的后期处理与标注数据采集完成后后期处理也是个体力活。AirSim采集的原始图像是单张PNG如果需要生成视频可以用OpenCV拼接import cv2 import glob frame_files sorted(glob.glob(rgb_*.png)) video_writer cv2.VideoWriter(output_video.avi, cv2.VideoWriter_fourcc(*MJPG), 10, (640, 480)) for frame_file in frame_files: frame cv2.imread(frame_file) video_writer.write(frame) video_writer.release()但更花时间的是标注。我建议大部分标注工作都依靠语义分割图的自动转换完成人工标注只处理边缘情况比如遮挡、模糊、小目标。这样既能保证标注质量又能把人力成本控制在可接受范围内。6. 平台实测效果与数据质量评估6.1 仿真数据与真实场景的对比分析仿真平台到底能不能用关键要看仿真数据与真实数据的差距有多大。我拿了一套真实无人机拍摄的校园场景图像和AirSim中相同视角下生成的仿真图像做了对比。定性上看AirSim的渲染真实度在UE4的光照系统加持下已经相当接近真实相机效果尤其是白天、晴天条件下光线和阴影都比较自然。但真机图像的纹理细节更丰富、噪声更明显仿真图像相对干净边缘更锐利。如果要做域适应相关的研究这个差异就是很好的切入点。定量上我在仿真数据集和真实数据集上分别训练了YOLOv5s然后用一组合集的真实测试集做评测。结果是真实数据训练的模型mAP比仿真数据训练的模型高约18个百分点。这个差距确实存在但考虑到零标注成本的优势对于算法预研和可行性验证意义仍然很大。这也说明仿真平台适合做早期验证最终部署还是需要少量真实数据做微调。6.2 平台性能指标与运行时长性能方面我测试用的配置是i7-12700K RTX 3070 16GB内存。在这个配置下AirSim场景在1080p分辨率下运行稳定在60FPS左右。如果开启复杂光照和抗锯齿能跑到45FPS对视觉算法验证完全够用。数据采集效率方面以10Hz频率采集640x480像素的RGB深度图单次巡航10分钟可以采集约6000帧图像磁盘占用约1.5GB完全在可控范围内。如果需要更大规模的数据集可以并行开多个UE4实例每个实例跑不同的天气或光照条件我在项目里实现了这个批量采集功能单机最多并行开过4个实例数据采集速度直接翻了四倍。6.3 后续还能怎么扩展项目源码交付之后我梳理了几个可以继续扩展的方向。第一个方向是多机协同仿真。AirSim支持同场景多无人机可以扩展成编队飞行和集群控制算法的验证平台。这个方向对研究型毕设特别有价值因为实机集群实验成本高、风险大仿真环境几乎是唯一可行的验证手段。第二个方向是更真实的传感器建模。当前AirSim的IMU噪声模型相对简单可以叠加低通滤波、随机游走等噪声模型使IMU数据的统计特性更接近真实传感器这一步对后续做状态估计算法尤其重要。第三个方向是域随机化。通过在UE4中自动调整光照强度、天气条件、纹理贴图生成多样化的训练数据提升模型从仿真迁移到现实的泛化能力这是目前仿真领域的主流研究方向。我在实际使用中最大的体会是仿真平台的核心价值不在于像不像真的而在于能不能用低实验成本覆盖尽可能多的算法验证需求。用这个平台我一个学期跑完了目标检测、避障、路径规划、数据集制作、PX4联调五类实验这在只有一块显卡和一台电脑的实验室条件下是不敢想象的效率。如果你也在做类似的课题先把基础环境跑通然后把精力集中在算法怎么在仿真里验证上而不是纠结于仿真环境本身的参数调优这样才能真正做出有科研价值的工作。本文还有配套的精品资源点击获取
返回列表