Glossary

Fictionlab > Glossary > Mining robot

Mining robot

Mining robot – definition

In this article, a mining robot is a mobile robotic system designed to collect data, inspect infrastructure, transport instruments, or execute limited task-specific operations in mine environments. In the context of mobile robotics, it is usually an unmanned ground vehicle (UGV) operating in underground tunnels, open-pit areas, processing facilities, or test drifts. This definition focuses on mobile systems rather than stationary industrial robots or road autonomous vehicles.

A mining UGV combines a mobile base, onboard compute unit, sensors, communications hardware, and mission software. Its main engineering problem is reliable operation where visibility, GNSS availability, lighting, terrain, dust, moisture, and wireless connectivity may be limited. A robot can support inspection and mapping, but autonomy must be designed, validated, and supervised for the specific mine site.

On ROS 2 platforms, a mining robot commonly uses a differential-drive or skid-steer base, LiDAR-based localization, inertial sensing, wheel odometry, and a navigation stack. Leo Rover can serve as a compact research platform for indoor mine mock-ups, tunnels, laboratory testbeds, and sensor integration. Raph Rover is more suitable when the sensor payload, battery capacity, enclosure, or terrain capability exceeds the practical limits of a smaller platform.

Core functions of a mining UGV

A mining robot does not require a single fixed architecture. Its functions depend on the mission, required sensor coverage, environmental hazards, and available communications infrastructure. In research and field deployments, the system is usually divided into perception, state estimation, navigation, mission control, and data logging layers.

  • Inspection: visual, thermal, LiDAR, acoustic, or gas-sensor data collection near tunnels, conveyors, walls, voids, and equipment.
  • Mapping: production of 2D occupancy maps, 3D point clouds, meshes, or georeferenced survey datasets.
  • Localization: estimation of the robot pose in a local map, often without GNSS underground.
  • Navigation: waypoint following, obstacle avoidance, recovery behaviors, and teleoperation fallback.
  • Monitoring: recording of environmental measurements with location and timestamp metadata.

In ROS terminology, the robot pose is normally represented through the tf2 transform tree. REP 105 defines common mobile-robot coordinate frames, including map, odom, and base_link. REP 103 defines standard coordinate conventions and recommends SI units for ROS systems. These conventions are important when combining wheel encoders, IMU data, LiDAR SLAM, and external positioning systems.

Localization and navigation in mine-like environments

GNSS receivers are useful in open-pit mining and outdoor staging areas, but satellite positioning is normally unavailable inside underground workings. A mining robot therefore needs local state estimation. LiDAR SLAM, visual-inertial odometry, wheel odometry, and IMU fusion are common approaches. Their output must be checked against wheel slip, repetitive tunnel geometry, dust-related returns, and sensor occlusion.

Subsystem Typical ROS 2 interface Purpose
Wheel odometry nav_msgs/msg/Odometry Short-term motion estimate from encoders
2D LiDAR sensor_msgs/msg/LaserScan Obstacle detection and 2D SLAM input
3D LiDAR or depth camera sensor_msgs/msg/PointCloud2 3D mapping and terrain perception
IMU sensor_msgs/msg/Imu Angular velocity, acceleration, and orientation data when provided
Velocity command geometry_msgs/msg/Twist Linear and angular motion command

The ROS 2 Navigation Stack, Nav2, uses behavior trees, planners, controllers, costmaps, recovery behaviors, and lifecycle-managed nodes. A differential-drive UGV such as Leo Rover can use Nav2 when its base controller accepts velocity commands and publishes valid odometry and transforms. Navigation is not provided automatically by the mobile base. It requires calibrated sensors, a collision model, map or localization input, and conservative velocity limits selected for the operating area.

Key parameters for mining robot integration

Engineering specifications should be documented before deploying a robot near mine infrastructure. Parameters should be treated as measurable acceptance criteria rather than nominal assumptions. The required values depend on the mission and site risk assessment.

  • Localization error: compare estimated pose with surveyed reference points or repeatable markers.
  • Map update rate: record the rate of occupancy-grid or point-cloud publication, together with CPU load and message latency.
  • Obstacle detection range: validate the usable range in dust, low light, reflective surfaces, and tunnel geometry.
  • Wheel slip: compare encoder-derived odometry with LiDAR, visual, or inertial estimates on loose material.
  • Communication loss behavior: define whether the robot stops, returns to a known point, or waits for operator intervention.
  • Ingress protection: verify enclosure suitability against the expected exposure. Leo Rover is specified with an IP55 rating by Fictionlab documentation.

A simple odometry consistency check can be expressed as:

position_error = || p_reference - p_estimated ||

For a differential-drive robot, commanded linear velocity v and angular velocity ω should remain within limits validated for traction, payload, braking distance, and sensor latency. These limits are deployment-specific and should not be copied from a simulation without field testing.

Leo Rover and Raph Rover in mining robotics research

Leo Rover is a four-wheel differential-drive platform with a built-in Raspberry Pi compute unit and ROS 2 compatibility. The supported ROS 2 distribution depends on the installed software image and available packages. It is appropriate for prototyping sensor mounts, ROS 2 nodes, SLAM pipelines, teleoperation interfaces, and navigation experiments in controlled mine-like environments. Additional compute hardware may be required for dense 3D mapping, neural perception, or multi-sensor fusion workloads.

Raph Rover provides a larger mobile platform for projects that require a higher payload capacity or a larger sensor and power envelope. Typical payloads can include multi-layer LiDAR, stereo or depth cameras, an industrial IMU, environmental probes, an edge computer, and protected data storage. The selection between Leo Rover and Raph Rover should follow payload mass, mechanical volume, terrain, runtime, and compute requirements. Raph Rover is not a replacement for Leo Rover in compact laboratory and educational work.

ROS 2 configuration example

The following example shows a partial parameter structure for a 2D LiDAR-based mining test environment. The values are examples only and must be validated against the actual sensor, map resolution, and vehicle stopping distance.

local_costmap:
  local_costmap:
    ros__parameters:
      global_frame: odom
      robot_base_frame: base_link
      rolling_window: true
      resolution: 0.05
      obstacle_layer:
        observation_sources: scan
        scan:
          topic: /scan
          data_type: LaserScan
          marking: true
          clearing: true

Normative references and technical sources

The following sources define the ROS conventions and interfaces relevant to mining UGV integration. Hardware-specific values must always be verified in the current manufacturer documentation for the installed model and firmware version.

See also