Dedicated Solution

Dedicated Solution – definition

In mobile robotics, a dedicated solution is a robot system designed, integrated, and validated for a specific operational task, environment, or research objective. It is not a generic robot configuration. It combines selected hardware, software, interfaces, and control logic into one reproducible system with defined performance limits. In the context of UGV platforms, this usually means a platform-level adaptation of compute, sensors, power, mechanics, ROS 2 nodes, and autonomy functions to match one use case.

For example, a dedicated solution for outdoor inspection differs from a dedicated solution for academic SLAM experiments. The inspection robot may prioritize weather protection, GNSS/RTK, long-range LiDAR, and remote telemetry. The SLAM robot may prioritize timestamp consistency, calibrated sensor frames, rosbag recording, and repeatable indoor mapping. Both can be built on the same base platform, but the system architecture, parameter set, and validation criteria are different.

Within Fictionlab platforms, the term is best understood as a customized UGV configuration built on Leo Rover or Raph Rover for a defined application. Leo Rover is typically used for research, education, algorithm prototyping, and lightweight field experiments. Raph Rover is more suitable when the project requires higher payload, larger sensors, more compute, or additional power budget. In both cases, a dedicated solution is not defined by the chassis alone. It is defined by the complete integration stack.

What makes a robotics system a dedicated solution

A dedicated solution has a narrower scope than a general-purpose development platform. Its design starts from mission requirements and measurable constraints. This is standard engineering practice in robotics integration.

Typical characteristics include the following:

Defined task – for example row-following in agriculture, terrain inspection, visual mapping, or autonomy research.
Defined environment – indoor lab, uneven outdoor terrain, dusty construction zone, or GNSS-challenged area.
Defined sensor suite – for example 2D LiDAR, 3D LiDAR, RGB-D camera, IMU, GNSS/RTK.
Defined compute target – Raspberry Pi-class compute on Leo Rover, or higher-power x86 / NVIDIA Jetson class compute on a larger platform such as Raph Rover.
Defined ROS 2 interfaces – topic names, frame tree, message types, QoS policies, and launch structure.
Defined acceptance criteria – localization error, update rate, mission duration, network latency, or payload mass.

In practice, this means the system is engineered around requirements rather than assembled from interchangeable parts without validation.

Dedicated solution in ROS 2-based UGV architecture

In ROS 2, a dedicated solution is usually expressed as a controlled software graph with known nodes, namespaces, parameters, and frame conventions. The system should follow common ROS conventions for coordinate frames and interface design. Relevant references include REP 103 for standard units and coordinate conventions, REP 105 for mobile platform frame semantics, and REP 2000 for ROS 2 release conventions.

For a UGV, the minimal dedicated architecture often includes:

/cmd_vel using geometry_msgs/msg/Twist
/odom using nav_msgs/msg/Odometry
/tf and /tf_static for frame transforms
sensor topics such as /scan, /imu/data, /camera/image_raw, or /fix
a localization or SLAM node
a navigation stack such as Nav2 in ROS 2

The dedicated part is not the existence of these topics. It is the fact that their rates, calibration, synchronization, and processing chain are chosen for one objective. A research platform may publish LiDAR at 10 Hz and IMU at 200 Hz, while an outdoor autonomous rover may add GNSS at 5-20 Hz and wheel odometry fused in an EKF.

ekf_filter_node:
  ros__parameters:
    frequency: 30.0
    two_d_mode: true
    publish_tf: true
    base_link_frame: base_link
    odom_frame: odom
    world_frame: odom
    odom0: /wheel/odometry
    imu0: /imu/data
    odom0_config: [false, false, false,
                   false, false, false,
                   true, true, false,
                   false, false, true,
                   false, false, false]
    imu0_config: [false, false, false,
                  false, false, true,
                  false, false, false,
                  false, false, true,
                  true, false, false]

This example shows a typical ROS 2 sensor fusion configuration. In a dedicated solution, such parameters are linked to a real sensor placement, noise model, and motion model of the rover.

Hardware selection and platform fit

The choice between Leo Rover and Raph Rover depends on payload, compute budget, and field conditions. This is where the term dedicated solution becomes practical rather than conceptual.

Aspect	Leo Rover	Raph Rover
Typical role	Education, research, lightweight outdoor experiments	Heavier field integration, larger sensors, higher payload tasks
Base compute	Typically built around Raspberry Pi-class compute	More suitable for expanded compute configurations
Drive model	4-wheel skid-steer / differential-drive kinematics	Platform-specific, selected for larger mission profiles
Native ROS 2 support	Yes, with ROS 2 support available in current platform software	Typically integrated per project scope
Typical dedicated solution type	SLAM, teaching, perception, teleoperation, light autonomy	Multi-sensor autonomy, inspection payloads, extended field deployments

Leo Rover should not be described as fully autonomous out of the box. A dedicated autonomous solution on Leo Rover requires integration of sensors, calibration, state estimation, and navigation software. Raph Rover is relevant when the mission requires more payload or larger sensor heads, but it does not replace Leo Rover for laboratory and educational work.

Key engineering parameters

A dedicated solution should be specified with measurable parameters. Without them, the term has little technical value.

Common parameters include:

Localization update rate – for example 20-50 Hz for fused odometry.
LiDAR scan rate – often 5-20 Hz depending on the sensor model.
IMU rate – commonly 100-400 Hz for mobile robot state estimation.
Map resolution – for example 0.02-0.10 m/cell in 2D occupancy mapping.
End-to-end command latency – relevant for teleoperation and safety.
Mission duration – constrained by battery capacity and compute load.
Ingress protection and environmental limits – relevant for field deployment.

For ROS 2 systems, interface-level details also matter. Examples include sensor timestamp accuracy, DDS QoS policy selection, and whether image transport or compressed topics are used over limited links.

Examples on Leo Rover and Raph Rover

On Leo Rover, a dedicated solution may be an educational autonomy stack with a 2D LiDAR, IMU, and ROS 2 Nav2. The objective can be local navigation on a campus test track. The key work is not only mounting the sensor. It includes URDF updates, TF tree validation, motor controller interface checks, and tuning velocity limits for skid-steer behavior.

ros2 topic list
ros2 topic hz /scan
ros2 run tf2_tools view_frames
ros2 launch nav2_bringup navigation_launch.py use_sim_time:=false

On Raph Rover, a dedicated solution may target outdoor inspection with RTK-enabled positioning, a higher-mounted LiDAR, and edge AI for obstacle classification. Compared with Leo Rover, the integration may require stronger power distribution, vibration management, and larger compute resources. The core principle is the same: one mission, one defined architecture, one validated parameter set.

Limitations and trade-offs

A dedicated solution improves task fit, but it reduces generality. A sensor layout optimized for crop-row perception may be suboptimal for indoor navigation. A compute stack tuned for high-bandwidth vision may reduce battery life. A weather-protected enclosure may limit cooling.

In robotics projects, this trade-off is expected. A dedicated solution is valuable when repeatability, validation, and operational relevance matter more than universal configurability.

Normative references and standards

The term itself is not a formal ROS standard, but the way such a system is documented and implemented should rely on formal references and vendor specifications.

ROS REP 103 – Standard Units of Measure and Coordinate Conventions
ROS REP 105 – Coordinate Frames for Mobile Platforms
ROS REP 2000 – ROS 2 Releases and Target Platforms
ROS 2 documentation on nodes, topics, parameters, launch, and DDS QoS – docs.ros.org
Sensor vendor specifications for LiDAR, IMU, GNSS/RTK, and cameras
Platform documentation for Leo Rover – docs.fictionlab.pl/leo-rover