Occupancy grid

Occupancy grid – definition

An occupancy grid is a discrete map representation used in mobile robotics to describe which parts of the environment are free, occupied, or unknown. The space is divided into cells of fixed size. Each cell stores an occupancy estimate derived from sensor observations such as LiDAR, depth cameras, sonar, or fused perception outputs. In ROS and ROS 2, the standard 2D representation is the nav_msgs/OccupancyGrid message. It contains map metadata, resolution in meters per cell, map origin, and a row-major array of cell values.

In practice, occupancy grids are a core building block for UGV navigation. They are used by SLAM systems to build a map, by localization systems to match sensor data against a known map, and by path planners to avoid obstacles. On differential-drive platforms such as Leo Rover and larger payload-oriented platforms such as Raph Rover, an occupancy grid is typically the map consumed by the ROS 2 Navigation stack. It is not a geometric model of every object. It is a probabilistic approximation of occupancy in a bounded area.

ROS documentation defines nav_msgs/OccupancyGrid as a message for a 2D grid map where each cell represents occupancy information, commonly encoded as 0 to 100, with -1 meaning unknown. This convention is widely used by map_server, slam_toolbox, and Nav2 in ROS 2. For UGV work, this matters because planners usually treat high occupancy values as obstacles and unknown areas according to a configurable policy.

How occupancy grids work in ROS 2

In ROS 2, occupancy grids are usually produced by SLAM or mapping nodes and then published on the /map topic. The message type is nav_msgs/msg/OccupancyGrid. The map is linked to the robot frame tree through TF2, typically with the chain map -> odom -> base_link, consistent with REP 105 for mobile platforms. A planner then combines the static map with a local costmap generated from real-time sensor data, or uses rolling local costmaps for dynamic obstacle avoidance.

The most common ROS 2 workflow uses one of two patterns. The first is online SLAM, where a node such as slam_toolbox creates and updates the occupancy grid while the rover moves. The second is localization on a prebuilt map, where map_server loads a saved occupancy grid and AMCL estimates robot pose against it.

Component	ROS 2 role	Typical topic / interface
SLAM node	Builds occupancy grid from scans and odometry	`/map`, `/tf`
map_server	Loads saved map from YAML + image	`/map`
AMCL	Localizes robot in occupancy grid map	`/amcl_pose`
Nav2 costmaps	Inflates obstacles and supports planning	`/global_costmap/costmap`, `/local_costmap/costmap`

A minimal example of inspecting the map topic in ROS 2 is shown below.

ros2 topic info /map
ros2 topic echo /map --once
ros2 run tf2_tools view_frames

Key parameters and metrics

Occupancy grids are simple in structure, but their quality depends on several measurable parameters. These parameters directly affect memory use, planner performance, and map accuracy on UGV platforms.

Resolution – size of one cell in meters per cell, for example 0.05 m or 0.10 m. Lower values give more detail but increase memory and CPU load.
Width and height – number of cells in x and y. Total cell count is width x height.
Update rate – how often the map is republished. This depends on the SLAM node and sensor rate. A 2D LiDAR often publishes scans at about 5 to 15 Hz, while map updates may be slower.
Cell encoding – standard ROS occupancy values are -1 unknown, 0 free, and 100 occupied, with intermediate values also allowed.
Origin – pose of the map’s cell (0,0) in the reference frame.

The physical size represented by a map is computed as:

map_width_m  = width  x resolution
map_height_m = height x resolution

For example, a 400 x 400 map at 0.05 m/cell covers 20 m x 20 m. On a compact platform such as Leo Rover, this is often enough for indoor labs, greenhouses, or short outdoor inspection routes. On Raph Rover, larger work areas may require rolling maps, submaps, or larger static maps due to the larger operational footprint.

Sensor sources and integration

An occupancy grid is not a sensor by itself. It is generated from observations. In UGV systems, the most reliable source for 2D occupancy mapping is a planar LiDAR. Depth cameras can also contribute, but they require projection from 3D depth into a 2D traversability or obstacle layer. IMU and wheel odometry do not directly mark occupancy. They stabilize pose estimation so that sensor hits are inserted into the correct cells.

Typical sensor combinations for Leo Rover and Raph Rover include the following:

2D LiDAR + wheel odometry + IMU – standard setup for indoor or semi-structured outdoor SLAM.
3D LiDAR or depth camera + odometry – useful when low obstacles, slopes, or uneven terrain must be represented before projecting to 2D planning layers.
GPS/RTK + local obstacle sensing – useful outdoors where a global frame is needed, but not sufficient alone to create a dense local occupancy map.

On Leo Rover, the default compute platform is typically Raspberry Pi-based, so map resolution and SLAM complexity must match available CPU and memory. A lightweight 2D LiDAR pipeline with Nav2 is usually more realistic than dense 3D mapping. On Raph Rover, a higher payload budget allows stronger compute, additional sensors, and larger local maps.

Example ROS 2 map configuration

A saved occupancy grid in ROS 2 is commonly described by a YAML file and an image file. The YAML file contains metadata used by map_server. This format is standard in ROS navigation workflows.

image: warehouse_map.pgm
resolution: 0.05
origin: [-10.0, -10.0, 0.0]
negate: 0
occupied_thresh: 0.65
free_thresh: 0.25
mode: trinary

A typical ROS 2 command to load such a map is:

ros2 run nav2_map_server map_server --ros-args -p yaml_filename:=/data/warehouse_map.yaml

Use cases with Leo Rover and Raph Rover

For Leo Rover, occupancy grids are most often used in education, research, and prototyping. A common setup is a 2D LiDAR mounted on the chassis, ROS 2 Humble, slam_toolbox for mapping, and Nav2 for autonomous waypoint following. This allows students and researchers to inspect map quality, tune resolution, and test local planners on a differential-drive base. Because Leo Rover is not autonomous out of the box, the full mapping and navigation stack must be integrated, calibrated, and validated on the target terrain.

For Raph Rover, the same occupancy grid concept applies, but practical requirements differ. The platform can carry heavier sensors and compute modules, which makes multi-sensor fusion and larger-area mapping more feasible. This is relevant in construction, field inspection, or agricultural experiments, where obstacle density, terrain variation, and GNSS availability can change over the route.

Limitations and trade-offs

Occupancy grids are widely used because they are simple and compatible with standard ROS tooling. They also have clear limitations. A 2D grid loses height information. It can misrepresent overhanging obstacles, negative obstacles, tall vegetation, or traversability on rough terrain. Grid quality also degrades when odometry is poor, wheel slip is high, or the environment contains repetitive structures.

The main engineering trade-offs are straightforward:

Higher resolution improves obstacle detail but increases computation and map size.
Larger maps support wider missions but consume more memory.
Unknown space can be treated conservatively or optimistically, depending on the planner and safety requirements.
2D grids are efficient for Nav2, but 3D voxel or elevation maps may be better for uneven outdoor terrain.

Normative references and standards

The term and its ROS implementation should be interpreted using official interfaces and frame conventions. The primary references are the ROS message definition for nav_msgs/OccupancyGrid, REP 105 for coordinate frames in mobile platforms, and Nav2 or slam_toolbox documentation for ROS 2 mapping and navigation behavior. For research context, occupancy grids are classically associated with probabilistic mapping methods formalized in the robotics literature and widely adopted in IEEE publications.

ROS / ROS 2 – nav_msgs/OccupancyGrid message definition
REP 105 – Coordinate Frames for Mobile Platforms
Nav2 – map server, costmaps, planning interfaces in ROS 2
slam_toolbox – practical ROS 2 SLAM implementation publishing occupancy grids