Many users who are new to PX4 + ROS drone development run into a typical problem: everything works smoothly in simulation, but the real drone will not fly.

Many also assume that porting from simulation to a real drone simply means copying the code onto the onboard computer. In reality, the core of moving from simulation to real hardware is engineering adaptation of ROS nodes, data flows, and hardware interfaces. Once you understand this, it becomes immediately clear:

• why some functions can be deployed to the aircraft quickly;

• why some systems can never be fully debugged on the real drone;

• why many of the truly difficult parts are not algorithms, but engineering.

01

Many people focus on PX4, Gazebo, flight controllers, ORIN NX, LiDAR, cameras, and so on. But the system that actually connects them is ROS, because in ROS:

• Functions are split into Nodes

• Nodes communicate through Topics

• Data structures are defined consistently

This means that whether you are in a Gazebo simulation environment or on a real drone, as long as the Topic names, message types, and data rates are consistent,

the upper-level algorithms may not need to be changed at all. This is why ROS is, in essence, a "system interface standard".

02

For example, in Gazebo:

• The camera is a virtual plugin

• The IMU is simulated data

• The GPS is simulated data

On the real drone:

• The camera comes from RealSense

• The IMU comes from the flight controller

• The GPS comes from RTK

Although the underlying hardware is completely different, as long as the ROS Topics remain consistent, the upper-level algorithm can continue to work.

04

In the simulation environment:

• There is almost no latency

• There is no communication packet loss

• There is no electromagnetic interference

• Time synchronization is always correct

• Sensor error is extremely low

But a real drone is completely different. In a real environment, you may encounter:

• WiFi latency

• Topic backlog

• Excessive CPU usage

• Serial-port blocking

• Insufficient MAVLink bandwidth

• Time synchronization errors

• GPS drift

• Sensor noise

These issues are almost never exposed in simulation. But on a real drone, they can be magnified dramatically. For example:

• In simulation: visual positioning latency may be only 20 ms.

• On the real drone: it may become 150 ms directly.

As a result, the controller starts to oscillate. Many people think it is an algorithm problem. In most cases, however, it is a systems engineering problem.

05

• Topic: Do key Topics such as images, IMU, positioning, flight-controller status, and control commands exist, and are their names consistent with what the algorithm subscribes to?

• Frequency: Use rostopic hz to check whether key data streams are stable and whether long-term frequency drops, stalls, or backlogs occur.

• Timestamp: Check whether header.stamp is continuous, and whether there are significant offsets among sensor time, ROS time, and flight-controller time.

• Coordinate Frames: Confirm that the directions, origins, and units of the camera frame, body frame, and world frame are consistent.

• Control Link: Confirm whether MAVROS is stably connected, whether Offboard mode can be entered, and whether control commands are being sent continuously.

• Safety Logic: After positioning loss, communication interruption, battery abnormality, or control timeout, does the system have protection such as hovering, landing, or mode switching?

After the static checks pass, it is still not recommended to take off immediately. A safer approach is to start all nodes without arming the aircraft, and observe on the ground whether the data changes as expected.

For example, check whether the positioning direction is correct when the drone is moved; whether the attitude display is consistent when the airframe is rotated; and whether MAVROS keeps publishing and the flight controller receives the corresponding setpoints when control commands are sent.

This step may look slow, but it can reveal many problems in advance. Compared with backtracking from logs after a test flight, ground integration is safer and makes issues easier to locate.

From simulation to real-drone deployment, a large amount of "invisible" work is often hidden underneath: communication interface alignment, sensor coordinate-frame conversion, PX4 parameter tuning, onboard computing resource adaptation, safety mechanism rewriting... Any one of these can drag an already-verified algorithm back into debugging.

From the start, Prometheus connects the complete workflow from Gazebo/Prosimsimulation to real onboard systems. All functional modules run under the same code framework: path planning, target tracking, swarm coordination, and other algorithms implemented in simulation can be deployed directly to P230/P450/P600 and other real drones, without rewriting drivers, re-adapting communication protocols, or reconfiguring safety logic. Chinese comments and complete user manuals further reduce the time required to understand the underlying design during system porting.

Prometheus minimizes the workload of system adaptation, allowing developers to focus more on algorithm innovation.