Frontier-based exploration

Frontier-based exploration – definition

Frontier-based exploration is an autonomous navigation method for mobile robots that incrementally builds a map of an unknown environment and selects new navigation targets at the boundary between known free space and unknown space. In occupancy-grid mapping, a frontier is commonly defined as a set of free cells adjacent to at least one unknown cell.

The method is used by unmanned ground vehicles (UGVs) operating without a complete prior map. A robot first estimates its pose, creates or updates an occupancy grid with SLAM, detects frontier cells, groups them into candidate regions, and navigates towards a selected target. The objective is to expand the known map while maintaining collision avoidance.

For a Leo Rover or Raph Rover, frontier-based exploration is not a single ROS 2 feature. It is a system-level behaviour built from localisation or SLAM, a costmap, a global planner, a local controller, sensor drivers, and an exploration node. The platform must have sufficient perception coverage and an operational navigation stack before it can explore autonomously.

How a frontier is identified

An occupancy grid divides the environment into cells. Each cell represents an estimated state such as free, occupied, or unknown. In ROS, nav_msgs/msg/OccupancyGrid stores the map as a two-dimensional grid with signed 8-bit cell values. The interpretation of values is application-specific, while common ROS map conventions use -1 for unknown cells and values from 0 to 100 for occupancy estimates.

Let M(c) denote the state of a grid cell c. A basic frontier condition can be expressed as:

c is a frontier cell if:
M(c) = free
and at least one neighbour n of c satisfies M(n) = unknown

Neighbourhoods are normally evaluated using either four-connected or eight-connected grid adjacency. Eight-connected adjacency reduces diagonal gaps but can merge regions that only touch at corners. The implementation should use the same grid frame, map resolution, and coordinate conventions as the navigation stack.

After detection, adjacent frontier cells are clustered. A cluster can be represented by its centroid, by the closest reachable cell, or by a viewpoint offset from the unknown boundary. Sending a navigation goal directly into an unknown cell is generally unsuitable because the global planner requires traversable free space.

Frontier selection and utility scoring

Not every frontier is a useful destination. A small region behind an obstacle may provide little map growth, while a distant region may be expensive or unreachable. Exploration nodes therefore rank frontier clusters with a utility function.

A common form is:

U(f) = w_gain * I(f) - w_cost * C(f) - w_risk * R(f)

In this expression, I(f) is expected information gain, C(f) is path cost, R(f) is a risk or clearance penalty, and w values are configurable weights. Information gain may be approximated by the number of unknown cells visible from a candidate viewpoint. Path cost should be calculated from the planner output rather than Euclidean distance when obstacles, inflation zones, slopes, or narrow passages affect reachability.

Useful evaluation criteria include the following:

Map coverage: percentage of cells classified as known free or occupied.
Frontier size: number of connected frontier cells in a cluster.
Path length and estimated travel time to the candidate goal.
Obstacle clearance from the local and global costmaps.
Goal completion rate and the number of failed navigation attempts.
Map update latency between sensor acquisition, SLAM output, and costmap updates.

ROS 2 architecture for UGV exploration

In ROS 2, frontier exploration usually consumes a map published by a SLAM or localisation component and sends goals to Nav2. Nav2 provides lifecycle-managed navigation servers, costmaps, planners, controllers, recovery behaviours, and the NavigateToPose action interface. The exploration node remains responsible for frontier detection, ranking, and task completion logic.

A typical data path contains the following interfaces:

Function	Typical ROS 2 interface	Purpose
SLAM map	`/map`, `nav_msgs/msg/OccupancyGrid`	Provides free, occupied, and unknown cells.
Robot pose	`map -> odom -> base_link` TF chain	Places the robot and sensor data in a consistent frame tree.
Navigation goal	`nav2_msgs/action/NavigateToPose`	Requests navigation to a reachable frontier viewpoint.
Obstacle sensing	`sensor_msgs/msg/LaserScan` or `sensor_msgs/msg/PointCloud2`	Updates obstacle and voxel layers in costmaps.

Frame naming should follow REP 105, which defines the conventional mobile-robot frames map, odom, and base_link. A discontinuous global correction belongs in the map -> odom transform, while odometry provides the continuous local motion estimate.

# Example exploration parameters
frontier_explorer:
  ros__parameters:
    map_topic: /map
    global_frame: map
    robot_base_frame: base_link
    minimum_frontier_cells: 12
    goal_offset_m: 0.40
    blacklist_failed_goals: true
    navigation_action: navigate_to_pose

These values are implementation-specific examples, not ROS 2 defaults. The minimum cluster size must be related to map resolution. For example, a threshold of 12 cells has a different physical meaning on maps with 0.05 m and 0.20 m cell resolution.

Sensor integration on Leo Rover and Raph Rover

Frontier detection depends on map quality. A 2D LiDAR is commonly used for indoor planar exploration because it directly supplies range observations for 2D SLAM and obstacle layers. RGB-D cameras can contribute point clouds at short range, but their depth quality may degrade in direct sunlight, low-texture scenes, reflective surfaces, or beyond the sensor’s specified range. IMU and wheel odometry improve short-term motion estimation. GNSS/RTK can provide global positioning outdoors but does not replace local obstacle perception.

Leo Rover uses a four-wheel skid-steering base and a Raspberry Pi-based compute unit. It can run ROS 2 Humble or newer, but autonomous exploration requires integration of the required sensors, TF transforms, SLAM configuration, Nav2 configuration, and safety behaviour. Compute load must be measured on the selected onboard computer because SLAM, depth processing, costmaps, and frontier scoring compete for CPU and memory resources.

Raph Rover is better suited when a larger sensor payload, additional compute hardware, or outdoor instrumentation is required. The same exploration logic applies, but its footprint, turning behaviour, sensor mounting height, and costmap footprint parameters must match the physical platform.

Limitations and operational controls

Frontier-based exploration assumes that unknown space is potentially traversable. This assumption fails near glass, vegetation, stairs, drops, mud, deep water, or sensor blind zones. A frontier also does not guarantee a valid route. The planner may reject the goal because of inflation, footprint collisions, incomplete observations, or an inaccessible map region.

Robust implementations should cancel or blacklist repeatedly failed goals, detect lack of map progress, and terminate when no reachable frontier remains. For outdoor UGV deployments, geofencing, emergency stop behaviour, velocity limits, and remote supervision should be implemented independently from the exploration algorithm.

Normative references and technical sources

The following sources define the ROS interfaces and coordinate conventions commonly used in frontier-based exploration systems.

Frontier-based exploration