Sim-to-real gap when deploying to PX4 SITL (Gazebo Garden, X500)

[user246059]

Dear authors,

First of all, thank you for this outstanding work and for making the code
publicly available. The paper is truly impressive, and the training pipeline
works flawlessly on our side.

We are currently attempting to deploy the pretrained model (checkpoint0004)
to a PX4 SITL simulation with an X500 drone in Gazebo Garden, and have been
encountering a persistent sim-to-real gap. We would be very grateful for any
guidance or suggestions you might have.

gz_px4_diff.mp4

What we have done

Environment:

• Gazebo Garden 7 + PX4 1.14 SITL (x500_depth airframe, OakD-Lite depth camera)
• ROS2 Humble bridge: depth → DiffPhysModel.forward() → acc_cmd (NED)
• Model output is decoded exactly as in main_cuda.py:
  a_pred - v_pred in body heading frame → world net acceleration → NED

Verification of the visual pipeline:

• Depth preprocessing matches training: 3/depth.clamp(0.3, 24) - 0.6,
  MaxPool2d(4,4) to 16×12, plus randn(0.02) noise
• State vector: local_v(3) + target_v_local(3) + body_up(3) + margin(1) = 10 dims
• GRU hidden state and coordinate transforms (heading frame → world → NED)
  are all verified to match main_cuda.py exactly

CUDA environment evaluation (native, no PX4):

• checkpoint0004: ~87% success rate, ~5.7 m/s average speed in the
  single-agent training configuration
• The model clearly knows how to navigate and avoid obstacles in CUDA

What we tried (none resolved the gap):

1. Velocity setpoint with full integrator (v += a·dt, damping=1.0)
2. Direct acceleration setpoint (OffboardControlMode.acceleration = True,
   TrajectorySetpoint.acceleration = acc_cmd)
3. Training with a 2nd-order Butterworth low-pass filter (fc=3–4 Hz,
   ~105–135 ms step response) on the action before CUDA dynamics
4. PPO fine-tuning in CUDA with reward = speed − collision penalty

In all cases, the model either cannot track the reference stably, or collides
with obstacles that it should be avoiding in the CUDA environment.

Our analysis:
We believe the root cause is that CUDA training assumes instant force
application (act is applied directly as acceleration, v += a·dt,
p += v·dt), whereas PX4 has a cascaded control chain
(position → velocity → attitude → motor) with ~150–250 ms total response
delay. The pretrained model has no way to compensate for this actuation lag.

We also noticed from Section F and Appendix of the paper that the real-world
flights used a custom 365g quadrotor with BetaFlight, and PX4 was only
mentioned as one of the comparison platforms. This might explain why we
are struggling with PX4 specifically.

Questions

1. On the BetaFlight platform used in the paper, what was the control
   interface between the model and the flight controller? Was it direct
   motor commands, attitude rate setpoints, or something else?

2. Was the model ever tested on a PX4-based platform (e.g., the 1.2 kg
   drone mentioned in the appendix)? If so, could you share any details on
   how the model output was bridged to PX4's offboard interface?

3. Do you have any plans or suggestions for deploying to PX4/ArduPilot SITL
   (Gazebo)? A reference configuration—even a rough one—would be immensely
   valuable for the community.

Thank you very much for your time, and again for the excellent research.

Best regards

[Kanan99]

Thank you for your question!
I am looking for the similar answers

[HenryHuYu]

Dear authors,

First of all, thank you for this outstanding work and for making the code publicly available. The paper is truly impressive, and the training pipeline works flawlessly on our side.

We are currently attempting to deploy the pretrained model (checkpoint0004) to a PX4 SITL simulation with an X500 drone in Gazebo Garden, and have been encountering a persistent sim-to-real gap. We would be very grateful for any guidance or suggestions you might have.

gz_px4_diff.mp4

What we have done

Environment:

• Gazebo Garden 7 + PX4 1.14 SITL (x500_depth airframe, OakD-Lite depth camera)
• ROS2 Humble bridge: depth → DiffPhysModel.forward() → acc_cmd (NED)
• Model output is decoded exactly as in main_cuda.py:
  a_pred - v_pred in body heading frame → world net acceleration → NED

Verification of the visual pipeline:

• Depth preprocessing matches training: 3/depth.clamp(0.3, 24) - 0.6,
  MaxPool2d(4,4) to 16×12, plus randn(0.02) noise
• State vector: local_v(3) + target_v_local(3) + body_up(3) + margin(1) = 10 dims
• GRU hidden state and coordinate transforms (heading frame → world → NED)
  are all verified to match main_cuda.py exactly

CUDA environment evaluation (native, no PX4):

• checkpoint0004: ~87% success rate, ~5.7 m/s average speed in the
  single-agent training configuration
• The model clearly knows how to navigate and avoid obstacles in CUDA

What we tried (none resolved the gap):

1. Velocity setpoint with full integrator (v += a·dt, damping=1.0)
2. Direct acceleration setpoint (OffboardControlMode.acceleration = True,
   TrajectorySetpoint.acceleration = acc_cmd)
3. Training with a 2nd-order Butterworth low-pass filter (fc=3–4 Hz,
   ~105–135 ms step response) on the action before CUDA dynamics
4. PPO fine-tuning in CUDA with reward = speed − collision penalty

In all cases, the model either cannot track the reference stably, or collides with obstacles that it should be avoiding in the CUDA environment.

Our analysis: We believe the root cause is that CUDA training assumes instant force application (act is applied directly as acceleration, v += a·dt, p += v·dt), whereas PX4 has a cascaded control chain (position → velocity → attitude → motor) with ~150–250 ms total response delay. The pretrained model has no way to compensate for this actuation lag.

We also noticed from Section F and Appendix of the paper that the real-world flights used a custom 365g quadrotor with BetaFlight, and PX4 was only mentioned as one of the comparison platforms. This might explain why we are struggling with PX4 specifically.

Questions

1. On the BetaFlight platform used in the paper, what was the control
   interface between the model and the flight controller? Was it direct
   motor commands, attitude rate setpoints, or something else?
2. Was the model ever tested on a PX4-based platform (e.g., the 1.2 kg
   drone mentioned in the appendix)? If so, could you share any details on
   how the model output was bridged to PX4's offboard interface?
3. Do you have any plans or suggestions for deploying to PX4/ArduPilot SITL
   (Gazebo)? A reference configuration—even a rough one—would be immensely
   valuable for the community.

Thank you very much for your time, and again for the excellent research.

Best regards

1. Control interface on BetaFlight
   We sent reference attitude angles and thrust to BF, and internally, they are transfered to body-rate setpoints + normalized thrust.

2. PX4 testing (1.2 kg drone)
   The key was system identification: we replayed real flight logs (actions + odometry) in the training environment to fit first-order response parameters and latency. The model must be kind of accurate, since training gradients come from it.

3. PX4/ArduPilot SITL (Gazebo)
   No current plans for a full reference config. But a simple parameter sweep (step responses per axis, fit first-order-plus-delay) works well.

Two minor tips for single-drone training:
https://github.com/HenryHuYu/DiffPhysDrone/tree/master/src/quadsim_kernel.cu line 206

    // balls
    for (int i = 0; i < balls.size(1); i++) {
        scalar_t cx = balls[batch_base][i][0];
        scalar_t cy = balls[batch_base][i][1];
        scalar_t cz = balls[batch_base][i][2];
        scalar_t r = balls[batch_base][i][3];
        scalar_t dist = (ox - cx) * (ox - cx) + (oy - cy) * (oy - cy) + (oz - cz) * (oz - cz);
        dist = max(1e-3f, sqrt(dist) - r);
        if (dist < min_dist) {
            min_dist = dist;
            nearest_ptx = ox + dist * (cx - ox);
            nearest_pty = oy + dist * (cy - oy);
            nearest_ptz = oz + dist * (cz - oz);
        }
    }

Obstacle distance bug: it should be normalized the direction vector when computing nearest point – the original code missed this, but impact was small.

Random velocity: increase the range significantly (e.g., 1.5–10 m/s) for better robustness.

[HenryHuYu]

Thank you for your question! I am looking for the similar answers

You can refer to the response above.