Glossary

Fictionlab > Glossary > Digital Twin

Digital Twin

Digital Twin – definition

A digital twin is a software representation of a physical system that stays linked to the real asset through data, models, and state updates. In mobile robotics, a digital twin of a UGV includes the robot kinematics, geometry, mass distribution, sensors, actuators, computing stack, and the operating environment or its map. The purpose is not only visualization. A proper digital twin supports simulation, monitoring, validation, diagnostics, and prediction based on live or recorded robot data.

For ROS 2-based UGV platforms, the term usually means a combination of: a robot description model such as URDF, a physics or sensor simulation environment, a ROS graph compatible with the real robot, and synchronized telemetry. This interpretation aligns with common engineering use in robotics and cyber-physical systems. In practice, the twin is useful when the same ROS 2 nodes, topics, transforms, and parameters can operate on both the physical rover and its virtual counterpart with minimal changes.

On Fictionlab platforms, a digital twin for Leo Rover or Raph Rover is typically built around ROS 2 Humble or newer, a differential drive model, sensor plugins for LiDAR, IMU, cameras, and a map or terrain model. It is not a full substitute for field testing. It is a controlled environment for repeatable experiments, navigation stack tuning, and regression testing before deployment on hardware.

Core components of a digital twin in mobile robotics

In UGV engineering, a digital twin is only useful if it captures the interfaces that matter for autonomy and system integration. The minimum scope is broader than a 3D mesh in a simulator. It must reproduce robot behavior at the level where software decisions are made.

A practical digital twin usually includes the following components:

  • Robot model – links, joints, inertias, collision geometry, wheel radius, wheel separation, and sensor mounting frames, often defined in URDF.
  • Coordinate frames – a transform tree consistent with ROS conventions, typically map, odom, base_link, and sensor frames, published through tf2.
  • Dynamics and kinematics – differential drive behavior, motor limits, friction, acceleration, and slip assumptions.
  • Sensor models – LiDAR scan rate, IMU noise, camera intrinsics, depth range, GPS or RTK update rate, and time stamps.
  • Environment model – indoor map, outdoor terrain, obstacles, traversability assumptions, and optionally weather or illumination effects.
  • Data link to the real robot – telemetry, logged rosbag data, or live topic synchronization.

For Leo Rover, this often means a lightweight simulation and telemetry setup because the onboard compute is typically Raspberry Pi based. High-fidelity simulation is commonly executed on an external workstation, while the physical rover publishes state and sensor data over ROS 2. For Raph Rover, the larger payload budget may allow richer sensor suites and more demanding onboard processing, so the twin can include heavier perception pipelines and larger map representations.

How a digital twin works in ROS 2

ROS 2 provides the integration layer that makes a digital twin practical. The main requirement is interface compatibility. If the simulated robot publishes the same message types, topic names, frame IDs, and control interfaces as the real UGV, the navigation and perception stack can be moved between both systems.

The most relevant ROS interfaces are usually:

  • sensor_msgs/msg/LaserScan for 2D LiDAR
  • sensor_msgs/msg/Imu for inertial data
  • sensor_msgs/msg/Image and sensor_msgs/msg/CameraInfo for cameras
  • nav_msgs/msg/Odometry for wheel or fused odometry
  • nav_msgs/msg/OccupancyGrid for 2D maps
  • geometry_msgs/msg/Twist for velocity commands
  • tf2 transforms for frame consistency

Frame conventions matter. REP 103 defines standard units and chirality for ROS coordinate frames. REP 105 defines the relationship between mobile platform frames such as base_link, odom, and map. A digital twin that violates these conventions can still run, but it becomes unreliable for Nav2, SLAM, and sensor fusion.

from launch import LaunchDescription
from launch_ros.actions import Node

def generate_launch_description():
    return LaunchDescription([
        Node(
            package="robot_state_publisher",
            executable="robot_state_publisher",
            parameters=[{"robot_description": "<urdf content or xacro output>"}],
        ),
        Node(
            package="gazebo_ros",
            executable="spawn_entity.py",
            arguments=["-topic", "robot_description", "-entity", "leo_rover_twin"],
        ),
    ])

In this pattern, the same Nav2 stack can target either the digital twin or the physical rover, provided the command and localization interfaces are equivalent.

Key parameters and metrics

The quality of a digital twin depends on how closely it matches the physical platform in the parameters that affect autonomy. Not every parameter needs high fidelity. The important part is to model the variables that drive navigation, localization, and perception errors.

Parameter Why it matters Typical ROS representation
Wheel radius and wheel separation Affects differential drive odometry and motion prediction Controller config, URDF, odometry node
LiDAR scan rate and angular resolution Affects SLAM update rate and obstacle detection density sensor_msgs/msg/LaserScan
IMU rate and noise density Affects EKF stability and heading estimate sensor_msgs/msg/Imu
Camera field of view and depth range Affects perception coverage and visual odometry sensor_msgs/msg/Image, sensor_msgs/msg/CameraInfo
Localization latency Affects closed-loop navigation performance Topic time stamps, QoS settings
Map resolution Affects memory use, planning precision, and obstacle inflation nav_msgs/msg/OccupancyGrid

In many UGV projects, the useful performance metric is not visual realism. It is error between predicted and observed behavior. For example, pose error over time, wheel slip mismatch on loose ground, CPU load of the deployed ROS 2 graph, or divergence between simulated and real sensor time stamps. This is especially important outdoors, where terrain and lighting are hard to model exactly.

Use cases with Leo Rover and Raph Rover

For Leo Rover, a digital twin is often used in education, algorithm development, and reproducible lab experiments. The platform uses differential drive and supports ROS 2, but autonomous navigation is not available out of the box. A twin helps configure Nav2, SLAM, and sensor fusion before hardware testing. It also reduces risk when integrating accessories from fictionlab.pl/shop/ or custom payloads documented in docs.fictionlab.pl/leo-rover.

Typical Leo Rover digital twin tasks include:

  • testing a 2D LiDAR-based SLAM pipeline before mounting the sensor on the rover,
  • validating URDF frame placement for a depth camera or IMU,
  • tuning Nav2 costmaps and controller parameters for indoor or campus-scale operation,
  • running rosbag replay to compare real and simulated trajectories.

For Raph Rover, the digital twin is often more relevant to field robotics and heavier payload integration. Because the platform is intended for larger payloads, the twin may include 3D LiDAR, RTK-capable GNSS, multi-camera perception, and terrain-aware planning. This does not make it a replacement for Leo Rover in laboratory work. The engineering objective is different: larger maps, higher energy demands, and stronger coupling between payload mass and mobility behavior.

Limitations and trade-offs

A digital twin is never exact. The largest errors in UGV applications usually come from terrain interaction, wheel slip, vibration, sensor occlusion, and network timing. These effects are difficult to capture with the same fidelity across different test sites. For that reason, a digital twin should be treated as a validation layer, not as proof that autonomy will work in every real environment.

There is also a cost trade-off. High-fidelity simulation increases compute requirements and development time. For many ROS 2 workflows, a medium-fidelity twin is enough if the interfaces, frame tree, and timing behavior are correct. This is often the most efficient setup for Leo Rover. For Raph Rover, higher fidelity may be justified when payload cost, field time, or terrain risk is significant.

Normative references and standards

The term digital twin is broader than ROS, but in robotics its implementation should follow interface and frame standards used by the software stack. The most relevant references are:

  • REP 103 – Standard Units of Measure and Coordinate Conventions for ROS.
  • REP 105 – Coordinate Frames for Mobile Platforms.
  • URDF – Unified Robot Description Format, used for robot structure and kinematics in ROS ecosystems.
  • ROS 2 documentation – for node interfaces, parameters, QoS, rosbag, and tf2 behavior.
  • IEEE digital twin literature – for the system-level concept of linked physical and virtual assets in cyber-physical systems.

If a project mixes ROS 1 and ROS 2, the digital twin should explicitly document version differences. Message definitions are often compatible, but middleware behavior, launch systems, and parameter handling differ. For Fictionlab platforms, ROS 2 Humble or newer is the baseline context.

See also