In the past, reproducing a drone algorithm was usually a long-cycle effort. Reading the paper, reviewing the source code, understanding the algorithm architecture, migrating and compiling the project, connecting it to simulation, debugging interfaces, and finally validating it on real hardware all required repeated troubleshooting at every step. For a complete drone algorithm project, spending three to six months from the first reproduction attempt to a successful real-flight run was not unusual.

This time, AMOVLAB tried a new approach: using AI to migrate the FUEL algorithm to ROS2, run it first in ProSim simulation, and then connect it to the FlyCore real-machine system to attempt autonomous search and mapping in the garage area below the company office.

This was both an algorithm reproduction project and a change in working method. Through this practice, we wanted to see how much work AI can actually take on in drone R&D, and how developers should collaborate with AI to achieve a real efficiency gain.

01

FUEL Algorithm

FUEL is a relatively mature indoor-search algorithm for drones and is well suited for reproduction. It targets autonomous exploration and mapping in unknown spaces. It does not require end-to-end training, and its overall logic is clear, making it a suitable validation project for AI-assisted algorithm development.

For FlyCore, FUEL also has a good adaptation foundation. FlyCore's positioning system can support operation in complex indoor spaces and can also provide LiDAR point-cloud output. In other words, the core input data required by FUEL, such as drone pose, status information, and environmental point clouds, can all be connected through the FlyCore system.

This makes the reproduction target much clearer: first complete the migration from ROS1 to ROS2, then validate the algorithm in the ProSim simulation environment, and finally deploy it to FlyCore's RK3588 onboard planning computer so the algorithm can truly connect to the drone flight system.

02

Prepare the Engineering Materials

If the task is only to write a short piece of code, it may be enough to give AI a direct requirement. But for a complex project such as FUEL, upfront engineering materials are critical. For AI to do the right thing, it must first understand the project boundaries, interface specifications, migration objectives, and development constraints.

We prepared a set of Markdown files for the AI and placed them in the engineering directory created by AI.

Summary.MD

organizes the paper-reading notes, algorithm principles, algorithm architecture, and potential risk points such as map coverage, drone flight speed, and LiDAR publishing frequency.

STEP.MD

explains the reproduction targets and development steps, including original simulation reproduction, ROS2 migration, ProSim simulation, and FlyCore real-machine deployment.

ProSim.MD

describes the ProSim simulation interfaces, including LiDAR point-cloud messages, simulation coordinate-system alignment, and interface notes under the PX4 flight-control stack.

FlyCore.MD

describes FlyCore's hardware system, drone control interface, LiDAR point-cloud interface, position-data interface, and the input/output relationships that require attention during real-machine deployment.

AGENTS.MD

constrains AI's coding standards to reduce version mismatches, interface misuse, and inconsistent coding style.

These files allow AI to work within a clear engineering boundary. The clearer your understanding of the project and the more complete your materials, the more stable AI's output becomes. This is especially important in drone projects that combine software and hardware: if any interface, coordinate system, message type, or control mode is wrong, later debugging becomes extremely painful.

03

Let AI Understand the Project

After the project materials were ready, we gave AI the FUEL algorithm repository and asked it to study the project structure first. The focus at this stage was not to modify code immediately, but to let AI read the source code, understand module relationships, sort out the execution flow, and build a complete understanding based on the Markdown files we provided.

During the interaction, we repeatedly confirmed several key points: prioritize the original FUEL algorithm logic; ensure migration and execution succeed before considering local optimization; align all interfaces with ProSim.MD and FlyCore.MD; and avoid changing the overall architecture casually just to fix a local problem.

This is a very important point in AI-assisted development. AI is good at solving local problems, but it can also easily get trapped in them. For example, when a parameter is incorrect or a module reports an error, AI may repeatedly try to modify the current code. Without someone controlling the overall direction, the project can become increasingly messy.

In this development process, humans were responsible for directional judgment, while AI handled high-intensity execution. AI helped read code, modify interfaces, write adaptation layers, analyze errors, and generate scripts, but key decisions still needed to be controlled by developers.

04

Migrating to ROS2

The original FUEL project first needed to be migrated from ROS1 to ROS2. The core objective of this step was to follow the original algorithm idea as much as possible, get the project running in a ROS2 environment first, and then verify whether the migration was successful.

Our local development environment was Ubuntu 22.04 under WSL. We first completed basic simulation on the development host, then gradually moved into the ProSim simulation environment, and finally deployed to FlyCore's RK3588 onboard planning computer.

This process looks like simply 'migrating code,' but in practice it involves many details: ROS message types must be adapted, node and topic relationships must be reorganized, launch scripts must be adjusted, simulation input/output interfaces must be aligned, and the original algorithm logic should be preserved as much as possible.

These tasks are highly suitable for AI involvement. AI can quickly read source code, locate dependencies, modify interfaces, generate adaptation code, and iterate based on error messages. However, for every key modification, we checked whether it still matched the original development goal.

05

Running the ProSim Simulation

After the ROS2 migration was complete, the next step was to run the algorithm in the ProSim simulator. The ProSim simulation environment uses the PX4 flight-control stack. The key task here was to connect the FUEL algorithm with the simulated sensor data output by ProSim.

In simulation, sensor data comes from environments such as ProSim, AirSim, and PX4 SITL. We subscribe to the relevant data through prosim_sensor_bridge. After the data enters the algorithm, FUEL can perform mapping, search, and path planning.

We tested multiple scenarios in ProSim, including a factory, an underground garage, and a complex warehouse. Different scenarios helped us observe the algorithm's search performance under different spatial structures and also exposed issues such as map size, flight speed, point-cloud frequency, and coordinate-system alignment in advance.

This step is critical. Before real-machine testing, ProSim serves as an intermediate validation layer. It allows us to confirm that the algorithm logic, ROS2 migration, PX4 interfaces, and control flow can all run successfully before entering real-drone debugging.

06

Deployment to FlyCore

After the simulation ran successfully, the project entered real-machine interface integration. The biggest difference between the real machine and simulation is the data source. The simulation environment provides simulated sensors and simulated states; the real-machine environment faces real links such as LiDAR, SLAM, flight control, IMU, odometry, and PX4 DDS.

In FlyCore’s 3588 real-hardware pipeline, the core workflow is:

PX4-Related:

In FlyCore's RK3588 real-machine link, the FUEL algorithm needs to read real LiDAR point clouds, SLAM / VIO / localization information, PX4 odometry, and drone status, then output control commands that the flight controller can execute.

Eventually, the FUEL algorithm running on the RK3588 sends three-dimensional position trajectory points with velocity and acceleration feedforward to the drone. The drone operates in Offboard mode, and the flight controller executes the corresponding trajectory.

At this point, the difficulty is no longer only the algorithm itself, but also the communication links and engineering details. Real data may have noise, delay, and packet loss; real-machine coordinate systems may differ from simulation; timestamps may be unstable; and DDS, serial links, MicroXRCEAgent, takeoff, arming, Offboard control, and failsafe procedures all need to be handled correctly.

Therefore, the key to real-machine interface integration is aligning input/output messages and control commands. The algorithm logic and control logic in the middle can remain consistent, but input message types, output message types, communication links, and safety procedures all need to be adapted.

This is also where FlyCore brings value during development. It provides foundational capabilities such as positioning, point clouds, flight-control integration, and onboard computing, allowing algorithm developers to focus more on algorithm migration, simulation validation, and real-machine operation instead of assembling the underlying system from scratch.

07

Humans Set the Direction, AI Executes

One very clear feeling from this practice is that AI can indeed significantly improve development efficiency. Algorithm reproduction work that might previously have taken months can be shortened to around two weeks with AI support. If the upfront materials are more complete and context management is better, the cycle still has room to be further compressed.

However, the efficiency gain does not come from a single simple prompt. What truly works is complete engineering preparation, clear architectural judgment, accurate interface documentation, and continuous human supervision throughout development.

We also summarized several lessons during development: clarify the project structure before asking AI to act; the more complete the Markdown files are, the less likely AI is to drift; important interfaces must be specified explicitly rather than letting AI search online for a version; every key modification should be committed so issues can be rolled back quickly; and humans must continuously judge AI's development direction instead of leaving it completely unattended.

AI is an engineering assistant with strong execution ability, but it needs clear goals, reliable context, and the right direction. If developers do not have a basic architectural understanding of the project and only give AI a vague instruction, they may simply be consuming tokens.

Resource Link

Project repository: https://gitee.com/amovlab/flycore-fuel-recreate.git

From using AI to build a web ground station to this attempt at using AI to reproduce the FUEL algorithm, AMOVLAB has been exploring how AI can enter real drone R&D workflows. In the future, we will continue sharing more practical content about AI-built drones and AI-assisted robot development.