Laboratory floors are level and routes are clear, so robots usually move smoothly. But once they enter an industrial park, mining area, or field, conditions quickly become more complex.

How steep is the slope? Will the robot slip on gravel? How far is the edge of a step from the wheels? These details are difficult to infer from a 2D map. If a robot knows only whether an obstacle lies ahead, it may hesitate on complex terrain or even choose the wrong route.

2D occupancy grid maps are excellent for marking obstacles and traversable areas, but they are essentially top-down views. In outdoor or unstructured environments, terrain undulations, slopes, and edge hazards can easily be flattened or overlooked.

Mesh Navigation uses a triangular mesh directly as a computable terrain surface. The robot can plan routes over the terrain's actual contours while comparing traversal costs at different locations, allowing it to better understand the terrain as it moves.

This article introduces the open-source project mesh_navigation, covering mesh-map management, terrain-cost evaluation, path planning, and motion control. Using a real project as an example, we will see how these components fit together.

01

What Does a Mesh Map Tell a Robot?

Figure 1 | Mesh-map navigation over rugged terrain

mesh_navigation plans and controls motion directly on the surface of a 3D triangular mesh. The map preserves the terrain's spatial structure, allowing the planner to search for routes along its undulating surface.

Traditional navigation mainly relies on a top-down view; Mesh Navigation works with a computable 3D surface. In addition to obstacle locations, slope, roughness, edge risk, and traversal cost can all be incorporated into the planning process.

Figure 2 | A computable surface composed of triangular meshes

From a system architecture perspective, Mesh Navigation consists of the mesh map, terrain cost layers, a global planner, and a local controller, while reusing the planning, control, and recovery-behavior interfaces of Move Base Flex (MBF).

Because chassis capabilities, sensor configurations, and operating scenarios vary, developers can extend cost layers, planners, or controllers as needed. The project is essentially a modular 3D navigation framework that can be assembled and adapted.

Next, we will follow the project's actual workflow: collect data, reconstruct the mesh, and finally plan and drive the robot over the 3D surface.

02

Collecting Environmental Data

To enable a robot to find a route over 3D terrain, the first step is to record the surrounding environment as faithfully as possible.

Consider the following simulation environment:

Figure 3 | Simulation environment for data collection and validation

Figure 4 | Workflows for generating mesh maps with different SLAM approaches

During data collection, we use rosbag to record key data such as LiDAR, IMU, TF, and odometry. Once recorded, the same dataset can be replayed repeatedly to compare SLAM algorithms, filter parameters, mesh-reconstruction methods, and navigation strategies, reducing the variability of a single online run.

After data collection, the workflow moves to SLAM. The system first estimates the robot's trajectory, then registers the consecutive point clouds into a common coordinate frame. This project can integrate LiDAR SLAM solutions such as FAST-LIO, GLIM, and LIO-SAM.

Each approach has its strengths: some prioritize real-time performance, while others excel at global optimization. The selection should consider sensor frequency, scene scale, loop-closure conditions, computational budget, and final map quality.

This project ultimately uses GLIM and retains each LiDAR scan together with its corresponding pose, facilitating subsequent estimation of surface normals and spatial structure.

Figure 5 | Point-cloud map after acquisition and registration

03

Reconstructing a Navigable Mesh Map

Once the point cloud is available, it must be converted into a mesh map that the planner can use. The process can be divided into three main stages:

Standardizing the Point-Cloud Format

First, read the 3D coordinates and relevant attributes from the PCD file, then save them as a PLY file. The geometry remains unchanged at this stage and no triangular faces are generated; the purpose is to standardize the input format in preparation for surface reconstruction.

Figure 6 | Bremen City: original point cloud and reconstruction at 5 cm resolution

Reconstructing the Triangular Mesh

Next comes surface reconstruction. According to the mesh_navigation mapping guide, LVR2's lvr2_reconstruct tool can generate a triangular mesh from an unordered point cloud. Its surface-generation pipeline uses methods such as Marching Cubes to convert the PLY point cloud into a mesh that can be processed further.

Figure 7 | Raw mesh map reconstructed with LVR2

Cleaning the Mesh for Navigation

After the mesh is generated, it needs a health check. Surfaces reconstructed from point clouds often contain duplicate vertices, duplicate faces, isolated fragments, non-manifold edges, holes, or noisy protrusions.

To the eye, these issues may look like minor unevenness. But once passed to a path planner, they can directly cause:

• Unexpected breaks in the path

• Abnormal local traversal costs

• Continuous surfaces to be classified as non-traversable

• Traversable areas to be misclassified as keep-out zones

• Detours, jumps, or unreasonable routes in the planning result

Therefore, before deployment, tools such as MeshLab should be used to remove duplicate vertices and faces and repair topological problems such as non-manifold edges and vertices. Only when mesh connectivity is reliable do cost computation and path planning have a stable geometric foundation.

04

Planning and Control on the Mesh

During navigation, the system constructs multiple cost layers on the triangular mesh, including elevation difference, edge risk, roughness, static obstacles, dynamic obstacles, and their inflation layers. The planner combines these costs to find safer, more traversable routes over the 3D surface.

The CVP Planner generates a global path and vector field on the mesh surface. The Mesh Controller then uses the robot's position, target direction, and surface normal to output velocity commands, allowing the robot to track the path over 3D terrain.

The vector-field-based Mesh Controller is well suited to path tracking over 3D surfaces, but a new dynamic-obstacle layer does not automatically change its control direction. If fast-moving obstacles are present, a controller that reads the dynamic cost layer (such as MeshMPPI) is required, or a dedicated integration pipeline must be designed. Conventional 2D DWA, TEB, and MPPI controllers cannot be substituted directly.

Figure 8 | Path generated by the CVP Planner on the mesh surface

Navigation Results

05

Where Is This Approach Most Useful?

Mesh Navigation is most valuable because it connects terrain geometry, traversability assessment, and motion control. On slopes in industrial parks, multi-level structures, gravel in mining areas, and ditches in farmland, the robot considers both whether a route exists and whether that route is suitable for it.

This approach also demands a stronger engineering foundation. Sensor-data quality, global SLAM consistency, mesh topology, cost-layer parameters, localization accuracy, and chassis dynamics all affect the final navigation performance. When the terrain is mostly flat and compute is limited, mature 2D navigation is usually simpler. Mesh Navigation shows its real value when the environment has pronounced 3D elevation changes.