过去，复现一个无人机算法，往往是一件周期很长的事。读论文、看源码、理解算法架构、迁移编译、对接仿真、调试接口、再到真机验证，每一步都要反复排查问题。对于一个完整的无人机算法项目来说，从开始复现到真机跑通，花上3到6个月并不意外。
这一次，阿木实验室做了一个新的尝试：借助AI，把FUEL算法迁移到ROS2中，先在ProSim仿真中运行，再接入FlyCore真机系统，尝试实现对公司楼下车库场景的自动搜索与建图。
这是一次算法复现，也是一场工作方式的变化。我们希望通过这次实践，看看 AI 到底能在无人机研发中承担多少工作，开发者又该如何与 AI 协作，才能真正提升效率。
文末附有项目源码地址，方便您一键直达。 如果本文对您有所帮助，欢迎在文末三连：点赞、转发和推荐，支持我们继续创作更多优质内容！
01
FUEL算法
FUEL是一个相对成熟、适合复现的无人机室内搜索算法。
它面向的是无人机在未知空间中的自主探索与建图任务，不需要端到端训练，整体逻辑清晰，适合作为 AI 辅助算法开发的验证项目。
对于 FlyCore 来说，FUEL也具备较好的适配基础。FlyCore 的定位系统可以支持室内复杂空间运行，同时具备激光点云输出能力。也就是说，FUEL 所需要的核心输入数据，例如无人机位姿、状态信息和环境点云，都可以通过 FlyCore 系统进行对接。
这让整个复现目标变得更加明确：先完成ROS1到ROS2的迁移，
再在ProSim 仿真环境中验证算法，最后部署到 FlyCore 的3588 规划机载计算机上，让算法真正接入无人机飞行系统。
02
先准备好工程材料
如果只是写一段代码，直接向 AI 提需求可能就够了。
但要完成 FUEL 这种复杂项目，前期工程材料非常关键。AI 要想做对事情，首先要知道项目边界、接口规范、迁移目标和开发约束。我们给AI准备了一组MD文件，并放入AI建立的工程目录中。
用于整理论文阅读材料、算法原理、算法架构，以及可能遇到的风险点。比如地图覆盖大小、无人机飞行速度、激光雷达数据发布频率等。
用于说明复现目标和开发步骤。包括原版仿真复现、ROS2 迁移、ProSim 仿真运行、FlyCore 真机部署等。
用于说明 ProSim 仿真接口，包括激光雷达点云消息、仿真环境坐标系对齐方式，以及 PX4 飞控体系下的接口说明。
用于说明 FlyCore 的硬件系统、无人机控制接口、激光雷达点云接口、位置数据接口，以及真机部署时需要关注的输入输出关系。
用于约束 AI 的代码编写规范，减少版本错配、接口误用和风格混乱的问题。
这些文件的作用是让 AI 在一个明确的工程边界内工作。你的项目理解越清楚，材料准备越完整，AI 的输出就越稳定。尤其在无人机这类软硬件结合的项目里，接口、坐标系、消息类型、控制模式只要错一个，后面调试就会非常痛苦。
03
让 AI 读懂项目
项目材料准备好之后，我们把 FUEL 算法项目地址交给 AI，让它先学习项目结构。
这个阶段的重点，不是马上改代码，而是让 AI 读源码、理解模块关系、梳理执行流程，并结合我们提供的 MD 文件建立完整认知。
在交互过程中，我们会反复确认几个关键点：
-
优先遵循原版 FUEL 的算法逻辑
-
先保证迁移和运行成功，再考虑局部优化
-
所有接口对接都以 ProSim.MD 和 FlyCore.MD 为准
-
不要为了修一个局部问题，随意改动整体架构
-
这是 AI 辅助开发里很重要的一点
AI 很擅长解决局部问题，也很容易陷入局部问题。比如某个参数不对、某个模块报错，它会不断尝试修改当前代码。但如果没有人从全局把控方向，项目可能会越改越乱。
所以，在这次开发中，人负责判断方向，AI 负责高强度执行。
AI 可以帮我们读代码、改接口、写适配层、分析报错、生成脚本，但关键决策仍然需要开发者来把控。
04
迁移到ROS2
FUEL 原始项目需要先完成 ROS1 到 ROS2 的迁移。这一步的核心目标，是尽量按照原版算法思路，让项目在 ROS2 环境中先运行起来，验证迁移是否成功。
我们的本地开发环境是 WSL 下的 Ubuntu 22.04。先在开发主机上完成基础仿真运行，再逐步进入 ProSim 仿真环境，最后部署到 FlyCore 的 3588 规划机载计算机上。
这个过程看起来只是"迁移代码"，实际会遇到很多细节问题：
-
ROS 消息类型要适配
-
节点和话题关系要重新梳理
-
启动脚本要调整
-
仿真输入输出接口要对齐
-
原版算法逻辑要尽量保留
这些工作非常适合 AI 参与。AI 可以快速阅读源码、定位依赖、修改接口、生成适配代码，也可以根据报错信息持续迭代。但每一次关键修改，我们都会检查它是否符合原本的开发目标。
05
跑通ProSim仿真
ROS2 迁移完成后，下一步是在 ProSim 仿真器中运行。
ProSim 仿真环境使用 PX4 飞控体系。这里的重点，是把 FUEL 算法和 ProSim 输出的仿真传感器数据接起来。
在仿真中，传感器数据来自 ProSim / AirSim / PX4 SITL 这类模拟环境，我们通过 prosim_sensor_bridge 订阅相关数据。
这些数据进入算法后，FUEL 就可以进行建图、搜索和路径规划。
我们在 ProSim 中测试了多个场景，包括工厂、地下车库和复杂仓库。不同场景可以帮助我们观察算法在不同空间结构下的搜索效果，也能提前暴露地图大小、飞行速度、点云频率、坐标系对齐等问题。
这一步非常关键。在真机之前，ProSim 相当于一个中间验证层。它让我们可以先确认算法逻辑、ROS2 迁移、PX4 接口和控制流程是否跑通，再进入真实无人机调试。
06
部署到 FlyCore
仿真跑通后，项目进入真机接口对接。
真机和仿真的最大区别，在于数据来源变了。
仿真环境提供的是模拟传感器和模拟状态；真机环境面对的是雷达、SLAM、飞控、IMU、里程计和 PX4 DDS 等真实链路。
在 FlyCore 的 3588 真机链路中，核心流程是：
PX4相关：
在这个过程中，FUEL 算法需要读取真实激光雷达点云、SLAM / VIO / 定位信息、PX4 里程计和无人机状态，再输出飞控可以执行的控制指令。
最终，3588 上运行的 FUEL 算法会向无人机发送带速度、加速度前馈的三维位置轨迹点，无人机工作在 Offboard 模式下，由飞控执行对应轨迹。
这里的难点已经不只是算法本身，而是通信链路和工程细节。
-
真实数据会有噪声、延迟、丢包
-
真机坐标系可能和仿真不一致
-
时间戳可能不稳定
-
DDS、串口、MicroXRCEAgent
-
起飞、解锁、Offboard、失控保护
所以真机接口对接的关键，是把输入输出消息和控制指令对准。中间的算法逻辑和控制逻辑可以保持一致，但输入消息类型、输出消息类型、通信链路和安全流程都需要重新适配。
这也是 FlyCore 在开发中的价值。它提供了定位、点云、飞控控制和机载计算等基础能力，让算法开发者可以把更多精力放在算法迁移、仿真验证和真机运行上，而不是从零开始拼接底层系统。
06
人负责方向，AI 负责执行
这次实践里，一个非常明显的感受是：AI 确实可以大幅提高开发效率。
过去可能需要几个月的算法复现工作，借助 AI 可以缩短到两周左右。如果前期材料准备更充分、上下文管理更好，周期还有进一步压缩的空间。但效率提升并不来自一句简单的提示词。
真正起作用的是完整的工程准备、清晰的架构判断、准确的接口文档，以及开发过程中持续的人为监督。
我们在开发中也总结了几条经验：
-
先把项目结构想清楚，再让 AI 动手。
-
MD文件越完善，AI 越不容易跑偏。
-
重要接口必须明确指定，不能让 AI 自己到网上找版本。
-
每次关键修改都要提交 Commit，方便发现问题后及时回退。
-
人要持续判断 AI 的开发方向，不能完全放任。
AI 是一个执行力很强的工程助手，但它需要清晰的目标、可靠的上下文和正确的方向。
如果开发者对项目架构没有基本判断，只给AI一个模糊指令，很可能只是在消耗 token。
资源速递
项目地址：
https://gitee.com/amovlab/flycore-fuel-recreate.git（点击左下角阅读原文即可跳转）
从用AI写Web地面站，再到这次尝试用AI辅助复现FUEL算法，阿木实验室一直在探索 AI 如何进入真实的无人机研发流程。
后续，我们还将继续分享更多AI造无人机、AI辅助机器人开发的实战内容，请持续关注阿木实验室。
想了解更多产品信息、方案细节或合作方式，扫描下方二维码联系我们。
我们将为你提供产品选型、技术咨询与项目对接支持，助力无人机应用与开发更快落地。
如果您有感兴趣的技术话题，请在留言区告诉我们！关注阿木实验室，更多技术干货不断更新！
开发遇到棘手难题可以上阿木官方论坛：
有工程师亲自解答
10000+无人机开发者和你共同进步！
