ROS 2 + PX4 Autonomous UAV

Mission and scope

Build and verify a stack in which a ROS 2 mission node flies a square waypoint mission in PX4 SITL using offboard control, while position comes from a simulated external odometry source through EKF2 (GNSS fusion disabled). Provide a flight-log analysis that demonstrates that vision fusion was active and quantifies the tracking error.

Everything in this capstone runs on your own machine: the site cannot check it for you. The acceptance criteria below are what you verify and report.

What you will implement

• PX4 SITL with a Gazebo vehicle and QGroundControl connected (lessons M6-T1, M6-T12, M6-T14).
• ROS 2 workspace with px4_msgs matching the firmware version and the XRCE Agent (lessons M6-T8, M6-T9).
• Odometry bridge converting ENU/FLU to NED/FRD with correct timestamps and variances (lesson M6-T10).
• Offboard mission node with a dedicated fixed-rate setpoint publisher, arming and mode handshake, and status monitoring (lesson M6-T11).
• An autonomous square mission with waypoint acceptance logic and a return-and-land at the end.
• Log analysis with ULog tools: estimator fusion flags, innovations, setpoint tracking and failure events (lesson M6-T13).

System architecture

Requirements

Bring-up checklist

1. Start PX4 SITL and confirm the vehicle arms and flies in position mode from QGroundControl.
2. Start the XRCE Agent and verify /fmu/out/vehicle_status and /fmu/out/vehicle_odometry arrive at a steady rate with the right QoS.
3. Run the offboard demo (hover at 5 m), then the square.
4. Disable GNSS fusion with the EKF2 parameters of your PX4 version, enable external vision, run the odometry bridge, and verify fusion in the log.

Log analysis tasks

• Plot setpoint against local position for the square; compute RMS and maximum error.
• Plot EKF2 innovations for the external vision source and the fusion flags to show vision is accepted.
• Mark the mode changes (position, offboard, return, land) on the timeline.
• Find the cause of any oscillation or overshoot and propose a parameter or software change.

Use PX4’s flight-log analysis tools (Flight Review, PlotJuggler with ULog support, or pyulog).

Break it on purpose

Run these experiments and record the observed behaviour: (1) stop the setpoint stream; (2) publish odometry with a 100 ms stale timestamp; (3) publish ENU positions without conversion; (4) mismatched px4_msgs version. Each is a real failure mode from the lessons; record how it manifests in the log.

Deliverables

1. A repository with launch files and a README that brings up the whole stack from a clean machine.
2. The odometry bridge node with unit tests for frame conversion (lesson M6-T10).
3. A log-analysis notebook or script that produces every figure in the report.
4. A report with: architecture diagram, topic and frame table, the acceptance criteria results and the break-it experiments.
5. A list of PX4 parameters changed from default with the reason for each.

Acceptance criteria and grading rubric

Common failure points

• px4_msgs and firmware versions differ: topics exist but are empty.
• Setpoints published from inside a slow callback; offboard drops out.
• EKF2 parameter names from an older tutorial do not exist in your version: use the PX4 documentation for your release.
• Sim time and wall time confusion when stamping messages.
• Declaring success from the vehicle moving, without checking in the log that vision (not GNSS) was fused.

References

• PX4: ROS 2 user guide
• PX4: ROS 2 offboard control example
• PX4: external position estimation
• PX4: flight log analysis
• PX4: simulation

Record your progress