The final localization subsystem gives the robot a reliable outdoor pose estimate for navigation and planting. It starts with GNSS-RTK for global position, Warthog wheel odometry for short-term motion, and IMU data for orientation and rotation. These inputs allow the robot to know where it is relative to the generated seedling locations and when it has reached a planting waypoint.

For Spring, the active path was GPS-only. The custom GPS interface converted latitude and longitude into local Cartesian coordinates using the Flagstaff Hill map origin. It also published GPS-derived odometry and yaw, which the navigation stack used to route toward planting targets and trigger planting once the robot reached the waypoint threshold. This was reliable enough for SVD, so deeper EKF tuning was deferred.

For the final system, the localization stack uses navsat_transform_node and ekf_localization_node from robot_localization. The navsat_transform_node converts GNSS fixes into an odometry-compatible frame, while ekf_localization_node fuses GNSS, wheel odometry, and IMU data into a single filtered pose estimate.

This fusion is needed because each sensor has different strengths. GNSS provides global position but can be jumpy. Wheel odometry is smoother over short distances but drifts over time. The IMU improves heading and turning behavior. The EKF combines these signals so the robot gets a smoother and more stable pose for route planning, cost map updates, trajectory control, and planting-mode transitions.

In Fall, the main work is to make the EKF output the active pose used by navigation. That means tuning covariances, verifying the map, odom, and base_link TF chain, and testing the fused pose during longer multi-seedling missions with obstacle avoidance and repeated planting transitions.

Subsystem Progress

Week of January 19

Localization work kicked off by locking in the technical direction: FAST-LIO2 as the core SLAM approach, using LiDAR–IMU odometry as the main state estimate, with GNSS RTK positioned as the global reference to keep drift in check outdoors. Early effort went into bringing up the Swift Navigation GNSS RTK system so it could become a real input to the stack.

Week of January 26

LiDAR setup got underway, and the GNSS path started taking form through hands-on work to get RTX GNSS configured and behaving. A key decision point also surfaced around IMU strategy, weighing whether to commit to an expensive unit immediately or de-risk FAST-LIO with a cheaper option first.

Week of February 2

GNSS work moved from configuration into integration and physical readiness. GPS was set up to publish into ROS, which made it possible to log, replay, and analyze runs using the same workflows as the rest of the robot stack. Hardware setup also advanced with the GNSS RTK unit mounted onto a fixture so data collection could be done more cleanly.

Week of February 9

Initial GNSS testing outside produced real traces to inspect, and a ROS2 test script was developed to make those sessions repeatable by logging raw GNSS data while also publishing ROS topics that can be recorded and replayed later. The RTK correction path was also clarified through discussion with our sponsor, aligning on using AirLab base stations and pulling corrections over NTRIP via rtk2go. In parallel, the GNSS RTX sensor mount was developed in CAD, turning the mounting plan into something concrete and buildable.

Week of February 16

Effort centered on getting corrected positioning working. RTK reached a state where it was working and integrating with GNSS readings, which is a major step toward making GNSS a dependable global reference rather than a noisy hint.

Week of February 23

Built on the corrected positioning progress from the previous week by validating RTK-backed GNSS performance across multiple outdoor conditions. Also mapped the ROS2 localization pipeline end to end so implementation could move forward in a clear and testable way.

Week of March 2

Focused on turning the planned localization architecture into an implementable stack by defining the GNSS corrections path, GNSS driver path, NavSat transform, and global EKF flow. Also confirmed that Warthog odometry and IMU were available only through ROS1, making the ROS1-to-ROS2 integration path a key dependency for localization.

Week of March 9

Worked on bringing up the ROS2 localization stack and resolving the data path needed to get Warthog odometry and IMU into the ROS2 environment. This was the stage where localization work became tightly tied to the ROS bridge and overall system integration.

Week of March 16

Completed the main ROS2 localization modules and verified the bridge path needed to move Warthog ROS1 topics into ROS2. By the end of the week, the GNSS bring-up path, NavSat transform, and global EKF were set up well enough to support full localization testing.

Week of March 23

Shifted from stack bring-up to outdoor validation by testing GPS odometry on the robot and checking whether it was reliable enough to support navigation. GPS odometry performed well outdoors, while EKF tuning remained more difficult and time-consuming than expected.

Week of March 30

Continued localization validation during outdoor integration with planning and concluded that GPS odometry was reliable enough for SVD. Based on that result, deeper EKF tuning was deprioritized so effort could shift to higher-impact integration work elsewhere in the system.

Week of April 6

Added the GPS-only localization path through the custom GPS interface node. This converted GNSS latitude and longitude into the local map frame, published GPS-based odometry and yaw, and gave navigation a usable robot pose without depending on the full EKF stack.

Week of April 13

Focused on SVD preparation and localization integration with navigation. Verified that the GPS-only pose output could be used by the route planner, cost map, trajectory planner, and plan manager so the robot could navigate to planting targets in the same local coordinate frame.

Week of April 20

Supported SVD Encore and tested navigation integration outdoors. Confirmed that the robot could use GPS-based localization to drive toward planting locations, update target progress, and transition into the planting sequence when it reached the waypoint threshold.