Context
The campaign branch (feature/rfc-modular-airstack) deleted the stale px4_interface stub and its px4_msgs dependency (224 files, 216 IDL interfaces whose rosidl codegen ran on every clean build to serve one unloadable plugin — its selection parameter was hardcoded-over until recently). Deletion is not a verdict against uXRCE-DDS: this issue tracks doing it properly.
Why uXRCE-DDS
- PX4's recommended ROS 2 integration (stable since v1.14): uORB topics bridged directly into DDS — no MAVLink serialization, no double translation.
- Lower setpoint latency; high-rate odometry/setpoint streams that MAVLink rate limits constrain today.
Why it is a design, not a plugin swap
Trunk's stack is MAVROS-shaped end to end: EV fusion publishes vision_pose through MAVROS, the takeoff/land task server arms via MAVROS command services, airstack ready gates poll MAVROS state topics, and the asm_optitrack module sets EKF2 params via the MAVROS param plugin. A migration must decide, per surface: uXRCE (setpoints, odometry — the latency win), a thin MAVLink side-channel (params, missions), or reimplementation against PX4 service uORB topics (arming/commands).
Recommended home
RFC #380 Part 2's platform-module refactor — the interface/controller/safety layer gets extracted into the px4_multirotor platform module there, which is exactly where 'which PX4 transport' belongs as a capability. The interface plugin parameter on robot_interface_node is now honored (fixed on the campaign branch), so a clean implementation can slot in as a plugin or as an alternative platform bringup.
Sim compatibility notes (verified reasoning, untested)
Both Isaac (Pegasus) and AirSim run real PX4 SITL; uXRCE is a PX4 property independent of the simulator's MAVLink/HIL channel. Multi-vehicle needs PX4's per-instance px4_N namespacing reconciled with AirStack's domain-per-robot scheme.
Acceptance sketch
- A stack selecting the uXRCE interface flies
takeoff_hover_land in Isaac
ready gates and the safety monitor work without MAVROS topics- Decision recorded for params/commands path
px4_msgs returns as a dependency of the new module only
Refs: RFC #379 §4 safety floor, RFC #380 §6-8 platform modules; deleted code recoverable at branch history (pre-deletion: 832e2fa).
Context
The campaign branch (
feature/rfc-modular-airstack) deleted the stalepx4_interfacestub and itspx4_msgsdependency (224 files, 216 IDL interfaces whose rosidl codegen ran on every clean build to serve one unloadable plugin — its selection parameter was hardcoded-over until recently). Deletion is not a verdict against uXRCE-DDS: this issue tracks doing it properly.Why uXRCE-DDS
Why it is a design, not a plugin swap
Trunk's stack is MAVROS-shaped end to end: EV fusion publishes
vision_posethrough MAVROS, the takeoff/land task server arms via MAVROS command services,airstack readygates poll MAVROS state topics, and the asm_optitrack module sets EKF2 params via the MAVROS param plugin. A migration must decide, per surface: uXRCE (setpoints, odometry — the latency win), a thin MAVLink side-channel (params, missions), or reimplementation against PX4 service uORB topics (arming/commands).Recommended home
RFC #380 Part 2's platform-module refactor — the interface/controller/safety layer gets extracted into the
px4_multirotorplatform module there, which is exactly where 'which PX4 transport' belongs as a capability. Theinterfaceplugin parameter onrobot_interface_nodeis now honored (fixed on the campaign branch), so a clean implementation can slot in as a plugin or as an alternative platform bringup.Sim compatibility notes (verified reasoning, untested)
Both Isaac (Pegasus) and AirSim run real PX4 SITL; uXRCE is a PX4 property independent of the simulator's MAVLink/HIL channel. Multi-vehicle needs PX4's per-instance
px4_Nnamespacing reconciled with AirStack's domain-per-robot scheme.Acceptance sketch
takeoff_hover_landin Isaacreadygates and the safety monitor work without MAVROS topicspx4_msgsreturns as a dependency of the new module onlyRefs: RFC #379 §4 safety floor, RFC #380 §6-8 platform modules; deleted code recoverable at branch history (pre-deletion: 832e2fa).