[Feature]: ArduPilot/PX4 SITL bridge for the `Drone` entity

[qvelard]

What feature or enhancement are you proposing?

Hi! I'd like to contribute a bridge that lets an ArduPilot autopilot running in SITL (and PX4 later) control the existing Drone entity, with Genesis providing the physics.

The autopilot keeps its own state estimator (EKF) and control loops, Genesis steps the dynamics and returns ground-truth state each frame.

Starting with ArduPilot via its JSON SITL interface (plain UDP,), shipped as examples/drone/sitl_ardupilot.py + a short doc page. PX4 (Simulator MAVLink API) would follow as a separate PR.

Motivation

As a drone developer, I want to test real autopilot firmware (ArduPilot/PX4) against Genesis physics, so that I can validate flight-controller behaviour in Genesis instead of Gazebo, IsaacSim or AirSim.

Concrete user story: "I run sim_vehicle.py -v ArduCopter -f JSON:127.0.0.1, launch this example, type mode guided / arm throttle / takeoff 5 in MAVProxy, and watch the Drone entity take off and hold altitude inside Genesis."

Today Genesis has a Drone entity and set_propellers_rpm, but no way to close the loop with a real autopilot, you can only fly pre-scripted trajectories or a custom controller. This bridge turns Genesis into a drop-in physics backend for autopilot-in-the-loop testing.

Potential Benefit

• Positions Genesis as a fast alternative physics backend for the large ArduPilot/PX4 SITL user base (SITL_Models, CI pipelines, research labs).
• ArduPilot-first keeps the dependency footprint minimal: the JSON interface is plain UDP + JSON, so the example relies only on the Python stdlib (socket, struct, json).
• Establishes a reusable pattern (PWM in to RPM to step to state out) that PX4 and other autopilots can plug into later.

What is the expected outcome of the implementation work?

• examples/drone/sitl_ardupilot.py connects to ArduCopter SITL over the ArduPilot JSON interface (UDP 9002).
• Each frame: parse the SITL binary output (magic, frame_rate, frame_count, pwm[16]), map PWM → rotor RPM via Drone.set_propellers_rpm, step the scene, reply with the mandatory JSON state (timestamp, body-frame gyro + accel, NED position + velocity).
• A CF2X drone arms and completes a takeoff to a target altitude and holds a stable hover in GUIDED mode.
• Coordinate-frame conversion (Genesis Z-up / w-x-y-z quaternion → ArduPilot NED) and the specific-force accelerometer convention are handled and documented.
• A short doc/README section covers setup and how to reproduce the takeoff test.
• Example runs on the existing CPU CI ("Examples (CPU)") without new required dependencies.
• pre-commit passes.

Additional information

Reference documentation:

• ArduPilot JSON SITL interface (physics backend, UDP 9002, binary PWM out / JSON state in): https://ardupilot.org/dev/docs/sitl-with-JSON.html
• PX4 simulation / Simulator MAVLink API (TCP 4560), for the follow-up PR: https://docs.px4.io/main/en/simulation/

Open questions for maintainers:

1. Do you want this in-tree (examples/drone/sitl_ardupilot.py + doc) or as a companion repo?
2. Any constraint on new dependencies? Plan is stdlib-only for ArduPilot; PX4 later would need a MAVLink library (e.g. pymavlink) is that acceptable in-tree, or should PX4 live elsewhere?
3. Any prior art / work-in-progress on autopilot integration I should coordinate with (didn't find anything)?

cc @duburcqa @YilingQiao

[Milotrince]

Hi, we appreciate your effort to contribute! We'd like to keep genesis-world to be core physics and rendering only, and avoid hardware specific support and extensions. I would recommend you create a new repo with genesis-world as a dependency with your drone work! There are already some existing and upcoming frameworks built on top of genesis-world, you could also consider contributing there instead.