PX4 Bridge
Module Role¶
driver/venom_px4_bridge is not a single ROS package. It is the PX4 integration project root inside VNV.
It currently contains:
px4_msgs/: vendored PX4 ROS 2 message definitionsvenom_px4_bridge/: the VNV-owned bridge package
The goal is to keep PX4 message pinning, DDS probing, and state translation inside the bridge layer instead of leaking raw PX4 details upward.
Current Scope¶
The first slice currently includes:
px4_agent_monitorpx4_status_adapterpx4_external_pose_bridgepx4_agent_probe.launch.pypx4_external_pose_bridge.launch.py
Current bridge outputs:
/px4_bridge/agent_status/px4_bridge/state/px4_bridge/odom/px4_bridge/health/fmu/in/vehicle_visual_odometry
Recommended Entry¶
For a basic DDS Agent and PX4 link check:
For a focused build of PX4-related packages:
source /opt/ros/humble/setup.bash
cd ~/venom_ws
colcon build --symlink-install --packages-up-to px4_msgs venom_px4_bridge venom_bringup
External Pose Bridge¶
px4_external_pose_bridge converts upper-layer nav_msgs/Odometry from LIO / VPS algorithms into PX4-facing px4_msgs/VehicleOdometry.
Default data flow:
/lio/vps/odometry
-> px4_external_pose_bridge
-> /fmu/in/vehicle_visual_odometry
-> PX4 EKF2 external vision / visual odometry fusion
Default entry point in the main workspace:
Common launch arguments:
| Argument | Meaning | Default |
|---|---|---|
fmu_prefix |
PX4 DDS topic namespace prefix. | "/fmu" |
input_odom_topic |
Upstream LIO / VPS nav_msgs/Odometry topic. |
"/lio/vps/odometry" |
Override input_odom_topic when the upstream localization output uses another topic:
cd ~/venom_ws
source install/setup.bash
ros2 launch venom_bringup px4_vps_bridge.launch.py input_odom_topic:=/lio/odom
PX4-side fusion still depends on EKF2 parameters, timestamps, frames, and covariance settings.
Why This Is a Project Root¶
This layout isolates:
- upstream
px4_msgsversion changes - DDS Agent probing and availability checks
- VNV-owned bridge interfaces
Upper layers should depend on the bridge-facing outputs, not raw PX4 topic details.