In UAV development, reproducing a complete autonomous exploration algorithm is rarely just a matter of compiling open-source code. The real workload usually comes from understanding the paper, reading the source code, migrating dependencies, adapting ROS interfaces, connecting simulation data, aligning coordinate frames, and finally validating the algorithm on a real aircraft.
Recently, I tried to reproduce the FUEL autonomous exploration algorithm with the help of AI. The target was not only to make the algorithm run, but also to push it through a complete engineering workflow:
- Understand the original FUEL architecture.
- Migrate the project from ROS 1 to ROS 2.
- Connect the algorithm to a PX4-based simulation environment.
- Validate mapping and exploration behavior in several indoor scenes.
- Deploy the adapted system to a real UAV platform for indoor exploration testing.
The real test platform in this case was FlyCore, but the main focus of this post is not the hardware platform itself. I want to share the technical process of how AI was used in the reproduction workflow, especially around ROS 2 migration, PX4 topic adaptation, simulation validation, and real-flight interface integration.
1. Why I Chose FUEL as the Reproduction Target
FUEL is a representative autonomous exploration algorithm for UAVs in unknown indoor environments. Compared with learning-based end-to-end methods, its engineering structure is relatively clear. It mainly relies on mapping, frontier/exploration planning, trajectory generation, and motion execution.
This made it a suitable target for an AI-assisted reproduction experiment.
The goal was not to rewrite the algorithm from scratch. Instead, the technical objective was:
Keep the original FUEL logic as much as possible,
migrate the project to ROS 2,
connect it to simulation,
then adapt it to real UAV input/output interfaces.
For this type of project, AI can be useful, but only if the engineering boundary is clearly defined. If the prompt is too vague, AI may modify code locally without understanding the global architecture, which can easily break the original algorithm logic.
2. Preparing Engineering Context Before Asking AI to Code
Before letting AI modify the FUEL project, I first prepared several Markdown documents as engineering context.
The purpose was to make AI understand the system boundary before touching the code.
The documents included:
Summary.md
- FUEL paper notes
- Algorithm structure
- Mapping and planning pipeline
- Possible risk points, such as map resolution, flight speed, point-cloud frequency
STEP.md
- Reproduction steps
- ROS 1 baseline reproduction
- ROS 2 migration plan
- Simulation validation plan
- Real UAV deployment plan
ProSim.md
- Simulation-side topics
- LiDAR point-cloud interface
- Odometry interface
- PX4-related interface notes
- Coordinate-frame assumptions
FlyCore.md
- Real UAV-side input/output relationship
- LiDAR topic
- SLAM/VIO/positioning topic
- PX4 DDS topic mapping
- Onboard computer deployment notes
AGENTS.md
- Coding rules for AI
- Interface constraints
- Naming conventions
- Rules for avoiding unnecessary architecture changes
This step was more important than expected.
For a UAV algorithm project, many bugs are not caused by complex algorithm logic, but by small engineering mismatches:
Wrong message type
Wrong topic name
Wrong frame convention
Wrong timestamp source
Wrong launch sequence
Wrong Offboard command format
By giving AI structured engineering context, its output became more stable. Instead of randomly guessing interfaces, it could follow the documents and modify the project within a defined scope.
3. Letting AI Read the Project Before Modifying It
The first AI task was not coding.
I asked AI to read the original FUEL repository and summarize:
- Main modules
- Node relationships
- Topic dependencies
- Mapping pipeline
- Planning pipeline
- Trajectory output format
- Launch structure
- External dependencies
This helped build a common understanding between the developer and AI.
During this stage, I kept several rules:
1. Preserve the original FUEL algorithm logic.
2. Make the project run first before doing local optimization.
3. Treat the prepared interface documents as the authority.
4. Do not change the global architecture only to fix a local compile error.
5. Every important change must be reviewable and reversible.
This matters because AI is very strong at local code generation and local debugging, but it does not automatically understand the engineering priority of a UAV system.
For example, if a message conversion fails, AI may try to change the planner’s internal data structure. That may fix one compile error but damage the original algorithm design.
So in this workflow, the human developer was responsible for architectural direction, while AI handled high-frequency execution tasks such as:
- Reading source code
- Locating dependencies
- Updating message definitions
- Rewriting ROS 1 APIs into ROS 2 APIs
- Generating adapter nodes
- Updating CMakeLists.txt and package.xml
- Creating launch files
- Analyzing build errors
- Iterating based on runtime logs
4. ROS 1 to ROS 2 Migration
The first major engineering step was migrating the original FUEL project from ROS 1 to ROS 2.
This was not only a syntax migration. Several layers had to be changed:
ROS 1 NodeHandle -> ROS 2 rclcpp::Node
ros::Publisher -> rclcpp::Publisher
ros::Subscriber -> rclcpp::Subscription
ros::Timer -> rclcpp timers
catkin package -> ament_cmake package
ROS 1 launch files -> ROS 2 launch.py files
ROS message includes -> ROS 2 message namespaces
At the same time, the algorithm structure had to remain consistent.
The migration work mainly included:
- Updating node initialization
- Replacing publishers and subscribers
- Updating callback binding
- Adapting parameters
- Updating message type namespaces
- Rebuilding CMakeLists.txt
- Rewriting launch scripts
- Checking topic names and remapping rules
One useful approach was to migrate the project module by module instead of asking AI to convert the whole repository at once.
A typical prompt pattern was:
Read this ROS 1 node.
Identify its publishers, subscribers, timers, parameters, and message types.
Convert it to ROS 2 rclcpp style.
Do not change the algorithm logic.
Only modify ROS interface code.
This reduced unnecessary changes.
5. Simulation Validation with PX4-Based Interfaces
After the ROS 2 migration compiled successfully, the next step was simulation validation.
The simulation environment provided UAV state and sensor data. The key task was to connect FUEL to the simulated LiDAR and odometry streams, then verify whether the algorithm could build a map, select exploration targets, and generate feasible trajectories.
The main simulation-side inputs were similar to:
/airsim_node_fixed/uav1/lidarpointcloud2/LidarSensor1
Type: sensor_msgs/msg/PointCloud2
Role: simulated LiDAR point cloud
/airsim_node_fixed/uav1/odom_local
Type: nav_msgs/msg/Odometry
Role: local odometry from simulation
/uav1/fmu/out/vehicle_odometry
Type: px4_msgs/msg/VehicleOdometry
Role: PX4 simulated odometry
At this stage, the technical focus was interface alignment.
The core questions were:
1. Is the point cloud in the expected frame?
2. Is odometry expressed in the same coordinate convention as the map?
3. Are timestamps valid and monotonic?
4. Is the point-cloud frequency high enough for mapping?
5. Is the map resolution suitable for the simulated environment?
6. Does the planner generate trajectories within safe speed and acceleration limits?
The simulation test was run in multiple indoor-like scenes, including garage-like and warehouse-like environments. Different environments exposed different issues.
For example:
- Large open areas may require different exploration gain parameters.
- Narrow corridors are sensitive to map resolution and inflation radius.
- Point-cloud frequency affects map update stability.
- Coordinate-frame mismatch can make the planner select incorrect frontier points.
- Excessive velocity can make the simulated UAV overshoot planned trajectories.
This step was essential before real testing. Without simulation validation, directly moving to a real UAV would make debugging much more difficult, because algorithm bugs, interface bugs, frame bugs, and flight-control bugs would all appear at the same time.
6. Connecting the Algorithm to PX4 Offboard Control
After mapping and planning worked in simulation, the next issue was trajectory execution.
For PX4-based systems, the adapted algorithm needed to output setpoints that could be consumed by the flight controller in Offboard mode.
The PX4-related topics were organized around this structure:
/fmu/out/vehicle_odometry
/fmu/out/vehicle_status
/fmu/in/trajectory_setpoint
/fmu/in/offboard_control_mode
/fmu/in/vehicle_command
The planner output was converted into 3D trajectory setpoints with position, velocity, and acceleration feedforward where applicable.
A simplified control flow looked like this:
FUEL planner
↓
trajectory / waypoint output
↓
trajectory adapter
↓
px4_msgs/msg/TrajectorySetpoint
↓
PX4 Offboard mode
↓
flight controller execution
The important part was not just publishing setpoints. PX4 Offboard control also requires a correct command sequence and continuous setpoint stream.
The real control-side logic had to handle:
- Vehicle arming
- Switching to Offboard mode
- Publishing OffboardControlMode
- Publishing TrajectorySetpoint continuously
- Monitoring VehicleStatus
- Handling failsafe conditions
- Stopping or landing safely when data becomes invalid
This is where AI was useful for generating boilerplate ROS 2 nodes and checking topic definitions, but the actual safety logic still required human review.
7. Moving from Simulation to Real UAV Data
The biggest difference between simulation and real deployment is the data source.
In simulation, data streams are usually clean and stable. In real UAV testing, the algorithm must deal with actual sensor behavior:
- LiDAR noise
- SLAM drift
- VIO instability
- Timestamp jitter
- Packet delay
- DDS communication issues
- Frame convention mismatch
- Flight-control mode changes
The real system integration used this type of input structure:
Real LiDAR point cloud
Real SLAM / VIO / positioning
PX4 odometry
PX4 vehicle status
Flight mode, arming state, battery state, safety state
The real-data bridge converted these inputs into the format expected by FUEL:
LiDAR / SLAM
↓
fuel_real_bridge
↓
/uav1/world_points
/uav1/prometheus/odom_slam
↓
FUEL mapping and exploration
This bridge layer was very important.
Instead of modifying FUEL everywhere, the adapter layer absorbed most platform-specific differences:
- Topic name conversion
- Message type conversion
- Coordinate-frame alignment
- Timestamp handling
- Point-cloud filtering
- Odometry conversion
This made the project cleaner because the algorithm layer remained closer to the original FUEL design.
8. Key Technical Problems Found During Integration
Several problems appeared during the reproduction process.
8.1 Coordinate Frames
This was one of the most sensitive parts.
Simulation, SLAM, ROS, and PX4 may not use the same convention. Common issues include:
ENU vs NED
map vs odom
base_link vs body
LiDAR frame vs UAV body frame
PX4 vehicle odometry frame vs ROS planning frame
If these frames are not aligned, the planner may appear to run normally, but the UAV may move in the wrong direction.
The practical solution was to define one planning frame and force all inputs into it before entering FUEL.
8.2 Point-Cloud Frequency and Map Update
FUEL depends heavily on map quality. If the LiDAR point cloud is too sparse or published at an unstable frequency, the exploration behavior becomes unstable.
Important parameters included:
- Point-cloud publish rate
- Voxel size
- Map resolution
- Local map range
- Obstacle inflation radius
- Maximum exploration velocity
Simulation was useful for tuning these values before real testing.
8.3 Timestamp Consistency
Real UAV systems often have multiple time sources:
- ROS time
- PX4 timestamp
- LiDAR driver timestamp
- SLAM timestamp
- onboard computer system time
If timestamps are inconsistent, mapping and odometry synchronization may fail silently.
In this project, timestamp handling was checked carefully in the bridge layer instead of leaving it to the planner.
8.4 DDS and MicroXRCEAgent Stability
PX4 ROS 2 integration depends on the DDS communication chain.
During real testing, the following parts needed attention:
- px4_msgs version
- PX4 firmware message compatibility
- MicroXRCEAgent connection
- DDS domain configuration
- Topic publish frequency
- Network or serial-link stability
AI could help inspect interface definitions and generate diagnostic scripts, but actual communication stability still required manual testing.
9. How AI Helped Most
AI was most useful in repetitive but context-heavy engineering work.
For example:
- Reading unfamiliar source code
- Summarizing module dependencies
- Locating ROS 1 APIs
- Converting code to ROS 2 style
- Writing bridge nodes
- Generating launch files
- Explaining build errors
- Comparing message definitions
- Creating small diagnostic tools
- Producing documentation during development
The most effective workflow was not “ask AI to reproduce the whole project.”
A better workflow was:
Human defines architecture and constraints.
AI reads the current module.
AI proposes changes.
Human reviews the direction.
AI modifies code.
Build and run.
Feed logs back to AI.
Repeat.
This kept AI inside a controlled engineering loop.
10. Lessons Learned
Several lessons were clear after this experiment:
1. AI can speed up algorithm reproduction, but it cannot replace system-level engineering judgment.
2. Context preparation is more important than prompt wording alone.
3. For UAV systems, interface documentation must be explicit.
4. The original algorithm logic should be protected during migration.
5. Adapter layers are better than modifying the algorithm everywhere.
6. Simulation should be used as an intermediate validation layer before real UAV testing.
7. Coordinate frames, timestamps, and PX4 control mode are often more difficult than the algorithm code itself.
8. Every major change should be committed so that unstable modifications can be rolled back.
In this case, AI helped compress the reproduction cycle significantly. But the result depended on structured documentation, clear engineering boundaries, and continuous human review.
Conclusion
This experiment showed that AI can be a practical engineering assistant for UAV algorithm reproduction, especially when the work involves large amounts of code reading, migration, interface adaptation, and iterative debugging.
However, the difficult part of UAV development is not only writing code. The real challenge is connecting algorithm logic to a complete robotics system:
sensor input
mapping
planning
trajectory generation
PX4 Offboard control
simulation validation
real UAV safety handling
For me, the most valuable result was not simply that FUEL could run on a real UAV platform. The more important takeaway was that AI-assisted development can become a usable workflow for robotics engineering, as long as the developer keeps control of the system architecture and validation process.