What is Mobile Robot Navigation Data?

The core streams are lidar scans, wheel odometry, IMU readings and camera frames, each with its own timestamp. Rates are modest next to manipulation: a 2D lidar typically scans at 5 to 15 Hz and a 3D lidar at 10 to 20 Hz, while cameras run at 30. What a navigation stack actually consumes is usually an occupancy grid or costmap built from those scans, not the raw data.

Recording is straightforward (a ROS bag on the robot, driving the route), which is exactly why the hard part is route design. Two corridors that look identical to a lidar are the classic failure: scan matching aliases and the robot localizes itself in the wrong aisle. Glass walls and mirrors return nothing, wheel slip drifts odometry, and a robot that is lifted and set down elsewhere loses its pose entirely.

Most navigation policies are trained in simulation first, on scene sets such as Habitat-Matterport 3D, which contains 1,000 building-scale reconstructions, then evaluated on real runs. Capture for a specific building, sensor rig or failure case can be commissioned to order; the specification is the floor plan, the sensor and the conditions the robot has to survive.

Kinds of navigation data

Navigation data sorts by the task the robot is doing. Point-goal navigation asks the robot to reach a coordinate; the labels are the poses along the route and whether the goal was reached. Coverage and exploration ask it to see everything, and there the map is the deliverable. Social navigation adds people, so the labels include encounters and how the robot behaved around them.

The sensor configuration is the second split. A 2D lidar on a flat indoor floor, a 3D lidar for the full surroundings, a camera-only rig for cost, or a fused set. What most stacks consume is not the raw stream but the map built from it (an occupancy grid or costmap), so the deliverable usually pairs the map with the trajectory rather than raw logs alone.

The environment is the third variation, and the one that decides difficulty. Structured indoor space, warehouse aisles, outdoor paths and open plazas each break navigation in their own way. Simulated scene sets are the fourth source. They give scale and variety no single building can match, and their weakness is exactly where the real building is strong: sensor noise, reflections and the mess of a working space.

What to specify when buying

Specify the environment, not the hours. The floor plan and the route belong in the brief, along with the conditions the robot has to survive. Two questions expose most weak briefs: which parts of the building make localization hard, and what moves besides the robot. The answers decide the route, and a route designed without them is usually re-run.

The sensor rig is the second specification: which lidars and cameras, where they are mounted, at what rates, and how the clocks are synchronized. Mounting height changes what a lidar sees, and an unsynchronized rig produces trajectories that drift when fused. If the deliverable includes maps, say what form they take and in which coordinate frame, because a convention mismatch costs integration time at the other end.

Pose accuracy deserves its own line. Trajectory labels are only as good as the reference they were measured against, whether a survey of the building, a motion-capture volume or a carefully closed loop. Ask how the ground truth was established, because two datasets with the same sensor list can differ sharply in label quality, and the difference does not show up in the file listing.