Custom Robotics Services

Custom Robotics Services – definition

Custom Robotics Services are engineering services used to design, integrate, adapt, and validate a robotic system for a specific operational requirement. In mobile robotics, this usually means building or modifying a UGV platform, its sensing stack, onboard compute, power architecture, software nodes, and deployment workflow so that the robot can perform a defined task under defined constraints.

In a ROS 2 context, custom robotics services are not a product category but a system engineering process. The scope can include mechanical adaptation, sensor selection, driver integration, ROS 2 package development, URDF modeling, navigation stack tuning, simulation, test procedures, and field validation. The result is typically a reproducible robot configuration with documented interfaces, known performance limits, and maintainable software artifacts.

For Fictionlab platforms, this term is most relevant when Leo Rover or Raph Rover must be adapted beyond the default configuration. Leo Rover is a compact differential-drive UGV with ROS support, typically based on a Raspberry Pi compute unit and intended for research and education. Raph Rover is a larger platform for higher payload and more demanding field setups. In both cases, custom work often concerns sensor payloads, edge compute, communication, localization, and mission-specific autonomy. It does not mean generic automation consulting. It means robot-specific engineering tied to the kinematics, interfaces, power budget, and software architecture of a mobile platform.

What custom robotics services include in mobile UGV projects

In practice, these services are organized around subsystems. The exact boundary depends on whether the customer needs a prototype, a research platform, or a deployable field robot.

A typical custom scope for a ROS 2 UGV includes the following areas:

Mechanical integration – brackets, mast design, payload mounting, cable routing, enclosure changes, vibration isolation.
Electrical integration – power rails, DC-DC conversion, connector selection, fuse sizing, EMI considerations, battery runtime estimation.
Sensor integration – LiDAR, IMU, RGB or depth cameras, GNSS, RTK receivers, wheel encoders, and time synchronization.
Compute integration – Raspberry Pi, x86, or NVIDIA Jetson selection based on CPU, GPU, memory, and thermal limits.
ROS 2 software – drivers, topic remapping, tf2 tree design, lifecycle nodes, launch files, parameters, logging, bagging, and diagnostics.
Autonomy stack – SLAM, localization, Nav2 configuration, waypoint execution, obstacle detection, and safety behaviors.
Simulation and CI – URDF, Gazebo or Gazebo Sim simulation, Docker images, package tests, and CI/CD pipelines.
Validation – topic-level checks, latency measurement, calibration procedures, repeatable test scenarios, and acceptance criteria.

For technical teams, the core value is that interfaces become explicit. Each device has a driver, message contract, frame definition, update rate, and failure mode documented before field use.

How custom robotics services map to ROS 2 system architecture

In ROS 2, custom engineering work is usually expressed as a graph of nodes, topics, services, actions, and transforms. This is governed by standard message definitions and by ROS conventions such as frame naming and package structure. For transforms, REP 105 defines standard coordinate frames such as base_link, odom, and map. For mobile robots, these frames are central to localization and navigation interoperability.

A custom UGV deployment often needs a defined interface matrix like this:

Subsystem	ROS 2 interface	Typical message / standard	Typical rate
2D LiDAR	Topic	sensor_msgs/LaserScan	5 – 15 Hz
IMU	Topic	sensor_msgs/Imu	50 – 400 Hz
Wheel odometry	Topic	nav_msgs/Odometry	20 – 100 Hz
Depth camera	Topic	sensor_msgs/Image, sensor_msgs/CameraInfo, sensor_msgs/PointCloud2	15 – 30 Hz
Navigation goal	Action	nav2_msgs/action/NavigateToPose	Event-driven
Robot model	Parameter / file	URDF, xacro	Static

The numerical ranges above are common engineering values for UGV systems. The exact operating rate must follow the relevant hardware specification and the selected ROS 2 driver implementation.

Typical deliverables

For an engineering buyer or research lab, the output of custom robotics work should be inspectable and version-controlled. Deliverables are more important than general descriptions because they define what can be reproduced and maintained later.

A well-scoped project usually includes:

ROS 2 workspace with package sources and dependency manifest.
Launch files for hardware startup, teleoperation, localization, and navigation.
Parameter files in YAML for drivers, filters, and Nav2.
URDF or xacro model with sensor frames and physical placement.
Calibration artifacts – camera intrinsics, LiDAR extrinsics, IMU alignment, wheel radius and wheelbase parameters.
Container or image definition – for example Dockerfile and compose configuration.
Interface documentation with topic names, frame tree, rates, and QoS settings.
Test report with bag files, benchmark conditions, and known limitations.

Example integration on Leo Rover

Leo Rover is often used where compact size, ROS support, and educational or research accessibility matter more than payload capacity. A custom service on Leo Rover usually starts with a defined task such as indoor mapping, autonomous corridor navigation, crop-row inspection, or outdoor teleoperation with GNSS-assisted localization.

Because Leo Rover uses differential drive, a custom autonomy setup must account for non-holonomic motion constraints. It is also important to note that Leo Rover is not an autonomous vehicle out-of-the-box. A navigation stack, sensor fusion configuration, and safety logic must be integrated explicitly.

An example ROS 2 launch pattern can look like this:

ros2 launch leo_bringup base.launch.py
ros2 launch sllidar_ros2 sllidar_a2m8_launch.py
ros2 launch realsense2_camera rs_launch.py enable_depth:=true
ros2 launch nav2_bringup navigation_launch.py use_sim_time:=false

In this setup, custom engineering usually covers:

Selection of a LiDAR with suitable range and scan rate for the expected environment.
Compute sizing if depth perception or visual SLAM exceeds Raspberry Pi resources.
Extrinsic calibration so the LiDAR, camera, and IMU align correctly in the tf2 tree.
Nav2 tuning for footprint, inflation radius, controller frequency, and velocity limits.

Example integration on Raph Rover

Raph Rover is relevant when the application needs more payload, larger batteries, heavier sensors, or more powerful compute. Typical examples include multi-sensor field inspection, RTK-enabled outdoor navigation, or terrain experiments with a larger sensor mast and industrial communication peripherals.

Custom work on Raph Rover often shifts from minimal integration to full subsystem engineering. The payload can include a 3D LiDAR, dual GNSS antennas, an industrial IMU, and an NVIDIA Jetson computer. This increases capability, but it also increases thermal load, power draw, synchronization complexity, and mechanical vibration issues.

For outdoor deployments, a custom stack may combine wheel odometry, IMU, and GNSS in robot_localization, with local planning from Nav2 and global positioning from RTK-capable hardware. In such systems, the engineering task is not only to make nodes run, but to ensure frame consistency, timestamp quality, and stable behavior when GNSS quality changes.

Key engineering parameters

Custom robotics services are usually specified against measurable criteria. Without metrics, it is difficult to verify whether the integrated robot meets its intended use.

Parameter	Why it matters	Typical verification method
Localization error	Determines navigation accuracy	Ground-truth comparison or loop-closure test
End-to-end latency	Affects control stability and teleoperation	Timestamped topic measurement
Compute load	Limits node concurrency and model complexity	CPU, RAM, GPU profiling
Power consumption	Determines mission duration	Battery discharge logging
Sensor update rate	Impacts estimator and planner performance	`ros2 topic hz` and driver logs
Frame consistency	Required for fusion and navigation	`tf2_tools`, RViz inspection

Standards, references, and version-specific notes

In ROS-based mobile robotics, custom engineering should reference stable conventions and official documentation. REP 105 is the main coordinate frame convention used in navigation and localization. URDF is the standard XML robot description format used across ROS for kinematics and visualization. ROS 2 distributions differ in package maturity and API stability, so a project should state the target distribution explicitly, for example Humble Hawksbill or newer if the deployment stack supports it.

When custom services involve hardware, source material should come from the relevant vendor specification. Examples include LiDAR scan frequency and range from the device datasheet, Intel RealSense depth modes from Intel documentation, and GNSS or RTK update rates from the receiver manufacturer. For compute planning, Jetson performance and power envelopes should be taken from NVIDIA documentation, not from informal benchmarks alone.

Limitations and trade-offs

Custom robotics services do not remove platform constraints. They work within them. On Leo Rover, the main constraints are usually compute budget, payload, and environmental assumptions. On Raph Rover, the challenge is often integration complexity rather than minimum capability.

Typical trade-offs include:

Higher perception quality versus higher compute and power consumption.
More sensors versus more calibration and synchronization effort.
Outdoor GNSS capability versus reduced performance near buildings, trees, or occlusions.
Fast prototype delivery versus long-term maintainability and test coverage.

Custom Robotics Services