Pathfinder

Outdoor autonomy stacks tend to be written for one robot. The kinematics, the sensor set and the tuning end up braided through the navigation code, and moving to a second platform means rewriting rather than reconfiguring.

Pathfinder is the opposite exercise. One ROS 2 autonomy architecture — dual-EKF RTK localization, Nav2 waypoint navigation and a micro-ROS motor interface — is carried across three physically different ground vehicles: a tracked skid-steer UGV, a 4×4 differential rover, and an Ackermann RC crawler with no wheel encoders at all.

Each vehicle is maintained on its own branch with its own kinematics, sensor set and field-validated tuning. What has to stay identical is everything above the motor interface. What is allowed to change is configuration.

Every vehicle runs a Raspberry Pi 5 with ROS 2 Humble in Docker, an RTK GNSS receiver providing position and dual-antenna heading, a BNO055 IMU over UART, and an ESP32-S3 running micro-ROS behind the motor interface.

Localization is a dual EKF from robot_localization. A local filter fuses wheel odometry and gyro to publish a smooth, continuous odom → base_link. A global filter fuses RTK position and absolute GNSS heading to publish map → odom, anchoring everything to real-world coordinates. navsat_transform converts latitude and longitude into the map frame between them.

Nav2 plans with NavFn and tracks with a Regulated Pure Pursuit controller, retuned per vehicle. twist_mux arbitrates between navigation, the operator joystick and the emergency stop, and publishes the result on /cmd_vel_out.

The autonomy stack, the localization configuration and the operator tooling, carried across all three platforms:

• A custom ROS 2 driver for the dual-antenna RTK GNSS receiver — binary protocol parsing, position and absolute heading, and an integrated NTRIP client injecting RTK corrections in real time.
• Dual-EKF localization in robot_localization: separating relative gyro yaw from absolute GNSS heading across the local and global filters, and configuring navsat_transform so the map frame is anchored correctly.
• A datum node that waits for several consistent RTK-fixed positions and a valid heading before fixing the map origin, so one bad fix during acquisition cannot offset the entire map.
• Nav2 bring-up and per-vehicle tuning — planner and controller configuration, costmap footprints, kinematic limits, and behaviour-tree selection.
• The /cmd_vel_out and /odom_esp boundary to the ESP32-S3 micro-ROS motor interface, plus a yaw-priority velocity budget enforced in firmware.
• A browser-based mission console: a FastAPI and WebSocket backend bridging ROS 2 to a Leaflet map front end for waypoint missions, live telemetry and emergency stop.
• Field tooling — wheel-odometry scale calibrated against pure RTK displacement, and JSONL mission recording so tuning changes are argued from logs rather than impressions.

Three physical vehicles, three drive geometries, one autonomy architecture. All three run outdoors on real hardware, navigating GPS waypoint missions with RTK-corrected GNSS and dual-antenna heading.

The evidence is the footage above: every clip on this page is a physical vehicle outdoors, not a simulator. Wheel-odometry scale was calibrated against pure RTK displacement rather than estimated, and missions are recorded to JSONL — waypoints, plan, pose, commands and RTK status — so tuning is argued from logs.