Autonomous Navigation

Autonomous Navigation – definition

Autonomous navigation is the capability of a mobile robot to move from its current pose to a target pose or along a route without continuous manual control, while maintaining safety and task-relevant accuracy. In UGV practice, this capability combines perception, localization, mapping, path planning, motion control, and obstacle avoidance. The robot must estimate where it is, represent free and occupied space, compute a feasible trajectory, and execute that trajectory under kinematic and environmental constraints.

In ROS and ROS 2, autonomous navigation is usually implemented as a modular software stack rather than a single algorithm. For ground robots this stack commonly includes TF transforms, odometry, sensor drivers, localization or SLAM, costmaps, global planning, local planning, behavior management, and low-level velocity control. On ROS 2, the standard reference implementation is Navigation2, also called Nav2. It uses standard message types such as nav_msgs/Odometry, sensor_msgs/LaserScan, sensor_msgs/PointCloud2, geometry_msgs/Twist, and nav_msgs/OccupancyGrid.

For Fictionlab platforms, autonomous navigation should be understood as an integration problem. Leo Rover and Raph Rover are mobile UGV platforms, but autonomy is not a single factory feature. Leo Rover has a differential-drive base, four wheels, ROS 2 support, and an onboard Raspberry Pi-class compute unit. It can run parts of the navigation stack locally, but sensor selection and compute budgeting matter. Raph Rover provides more payload capacity and is better suited to heavier sensor sets and higher-performance compute modules used in field robotics.

How autonomous navigation works in ROS 2

In ROS 2, autonomous navigation is usually organized around a map frame hierarchy and a set of nodes with clearly defined interfaces. The minimum requirement is consistent state estimation and a valid transform tree. REP 105 defines standard coordinate frames for mobile platforms, including base_link, odom, and map. REP 103 defines standard units and coordinate conventions used by ROS.

A typical ROS 2 navigation pipeline on a UGV contains the following stages.

State estimation – wheel odometry, IMU, and optionally GNSS or visual odometry are fused, often with robot_localization, to publish robot pose and velocity.
Localization or SLAM – the robot estimates pose in a known map with AMCL, or builds a map online with SLAM Toolbox or another SLAM system.
Environment representation – 2D occupancy grids or layered costmaps are built from LiDAR, depth cameras, or point clouds.
Global planning – a planner computes a route from the start pose to the goal pose.
Local planning and control – a controller tracks the route while reacting to local obstacles and respecting robot kinematics.
Recovery and behavior logic – behaviors handle blocked paths, oscillation, or navigation failure.

Navigation2 supports planner, controller, smoother, behavior, and route plugins. In practice, a differential-drive rover often uses a 2D LiDAR for obstacle sensing, wheel odometry for short-term motion, and an IMU for better heading stability. If outdoor drift is unacceptable, GNSS or GNSS-RTK can be fused into the localization pipeline.

ros2 launch nav2_bringup navigation_launch.py \
  use_sim_time:=false \
  map:=/data/maps/test_area.yaml

Key parameters and metrics

Navigation quality is determined by measurable system parameters. These should be verified against the selected sensors, compute platform, and terrain model. On small UGVs, poor parameter tuning is a common cause of unstable behavior even when all nodes run correctly.

Parameter	Typical range	Why it matters
Odometry update rate	30-100 Hz	Improves short-horizon control stability and TF consistency
IMU rate	50-400 Hz	Supports heading and motion estimation during slip or vibration
2D LiDAR scan rate	5-20 Hz	Defines obstacle update frequency for costmaps
Local costmap update rate	5-20 Hz	Affects responsiveness to dynamic obstacles
Global costmap update rate	0.5-2 Hz	Usually sufficient for route replanning
Pose covariance	Application-specific	Determines trust in localization sources
Goal tolerance	0.05-0.30 m, 0.05-0.20 rad	Balances precision and controller robustness

For a differential-drive rover, planner feasibility depends on kinematic assumptions, maximum velocity, acceleration limits, wheel slip, and surface type. On loose soil, grass, or gravel, wheel odometry degrades faster than on indoor floors. That directly affects localization error, path tracking error, and goal convergence time.

A simple control error metric is the Euclidean position error:

e = sqrt((x_goal - x)^2 + (y_goal - y)^2)

In field deployments, navigation is usually validated with repeatability, cross-track error, replan latency, and mission completion rate, not only with visual inspection in RViz.

Supported sensors and integration for UGV platforms

Autonomous navigation on UGVs depends on sensor redundancy and calibration quality. A single sensing modality is rarely enough outside controlled indoor environments. Sensor fusion is therefore standard practice.

The most common sensor combinations are listed below.

Wheel encoders + IMU – minimum base for dead reckoning and short-range autonomy.
2D LiDAR + odometry + IMU – common indoor and mixed-environment setup for Nav2 and 2D SLAM.
Depth camera + IMU – useful for near-field obstacle detection, but more sensitive to lighting and weather.
GNSS/RTK + IMU + wheel odometry – useful outdoors where a global frame is required.
3D LiDAR + GNSS/RTK + IMU – higher-cost configuration for uneven terrain and larger UGVs.

On Leo Rover, a practical navigation stack often starts with wheel odometry, IMU, and a lightweight 2D LiDAR. This aligns with its onboard compute limits and educational or research use. Because Leo Rover is not autonomous out of the box, the integrator must provide sensor drivers, TF tree, calibration, Nav2 configuration, and test procedures. On Raph Rover, larger payload and power budgets make it more suitable for dual-LiDAR setups, higher-grade IMUs, RTK receivers, or GPU-enabled perception nodes.

controller_server:
  ros__parameters:
    use_sim_time: false
    controller_frequency: 10.0
    min_x_velocity_threshold: 0.001
    FollowPath:
      plugin: "dwb_core::DWBLocalPlanner"
      max_vel_x: 0.4
      max_speed_xy: 0.4
      acc_lim_x: 0.8
      decel_lim_x: -0.8
      max_vel_theta: 1.2

Use cases with Leo Rover and Raph Rover

Autonomous navigation on Fictionlab platforms should be matched to the mission profile. The same software architecture can be used on both rovers, but payload, runtime, and terrain assumptions are different.

Leo Rover fits laboratory research, education, algorithm prototyping, and controlled outdoor experiments. Typical tasks include waypoint navigation, obstacle avoidance, indoor mapping, and dataset collection. A realistic setup is ROS 2 Humble, Nav2, SLAM Toolbox, IMU, wheel odometry, and a 2D LiDAR. For more advanced perception, external compute or careful containerized deployment may be required.

Raph Rover is better suited to applications with larger sensors, longer missions, and rougher terrain. Examples include construction-site inspection, agricultural row navigation, and outdoor perception experiments where RTK, multi-sensor fusion, or 3D perception are needed. It does not replace Leo Rover in education or low-cost laboratory workflows, but it supports heavier autonomous navigation stacks.

Limitations and trade-offs

Autonomous navigation is constrained by sensing conditions, map quality, compute performance, and robot mechanics. ROS 2 integration alone does not guarantee robust field autonomy.

The main trade-offs are straightforward.

2D simplicity vs 3D awareness – 2D LiDAR navigation is efficient, but it can miss overhanging or negative obstacles.
Local compute vs perception richness – small onboard computers limit map resolution, planner complexity, and camera-based algorithms.
Relative vs absolute positioning – wheel odometry and IMU drift over time; GNSS improves global accuracy but depends on sky visibility.
Indoor vs outdoor assumptions – algorithms tuned for flat floors often fail on deformable terrain, slopes, and vibration.

For Leo Rover in particular, autonomy should be treated as a configured system, not a default platform property. Sensor mounting rigidity, timestamp synchronization, wheel slip characterization, and TF correctness are often more important than the choice of planner plugin.

Normative references and standards

The following references define the terminology and interfaces most often used when implementing autonomous navigation on ROS-based UGVs.

REP 103 – Standard Units of Measure and Coordinate Conventions for ROS
REP 105 – Coordinate Frames for Mobile Platforms
ROS 2 documentation – node, topic, TF2, lifecycle, QoS, and launch semantics
Navigation2 documentation – ROS 2 reference stack for navigation
robot_localization documentation – state estimation and sensor fusion in ROS
IEEE vocabulary and mobile robotics literature – standard terminology for localization, path planning, and autonomy levels in robotics research

Autonomous Navigation