Developer Kit

Developer Kit – definition

A Developer Kit is a pre-defined hardware and software package used to accelerate prototyping, integration, and validation of robotic functions. In mobile robotics, a Developer Kit usually combines a compute unit, interfaces, power distribution, reference software, and documentation needed to connect sensors, run middleware, and test autonomy components on a UGV. The term is broader than a single dev board. It includes the integration layer that makes the components usable as a robotics platform.

In a ROS 2 context, a Developer Kit typically provides a supported operating system image, device drivers, middleware configuration, example nodes, launch files, and mechanical or electrical interfaces. The practical goal is repeatability. An engineer should be able to install the stack, connect a LiDAR, camera, IMU, or GNSS receiver, and publish valid ROS topics without first designing a custom carrier board or low-level firmware.

For Fictionlab platforms, a Developer Kit is understood as an engineering starting point for Leo Rover or Raph Rover extensions. It is not equivalent to full autonomy. Leo Rover supports ROS and can be integrated with ROS 2, typically on a Raspberry Pi-based onboard computer, but autonomous navigation still requires integration of localization, mapping, obstacle sensing, and control software. On Raph Rover, the same term usually refers to a more expandable package oriented toward higher payload, additional compute, and field sensor integration.

What a Developer Kit contains in mobile robotics

A useful Developer Kit for a UGV must expose the interfaces required by the robotics stack. In practice, this means physical connectivity, timing, and software compatibility. A generic electronics starter kit is not sufficient if it does not support robot kinematics, sensor timestamping, and ROS message transport.

The typical elements are listed below.

Compute platform – for example Raspberry Pi, NVIDIA Jetson, or x86 SBC.
Operating system – usually Ubuntu Linux with a supported ROS 2 distribution such as Humble or newer.
Robot interface – motor controller access, wheel odometry, battery telemetry, GPIO, USB, Ethernet, CAN, UART, I2C, SPI.
Reference drivers – ROS 2 nodes for sensors and base control.
Mechanical mounting – brackets, rails, payload plate, cable routing points.
Power subsystem – regulated rails such as 5 V and 12 V, connector ratings, current budget.
Documentation – pinout, topic list, URDF, TF tree, calibration instructions.

For a UGV, the minimum useful output of the kit is a valid robot state in ROS 2. This usually includes /tf, /joint_states, /odom, and a command interface such as /cmd_vel with geometry_msgs/msg/Twist. Without these interfaces, higher-level packages such as Nav2, SLAM Toolbox, or robot_localization cannot be integrated cleanly.

How a Developer Kit works in ROS 2

In ROS 2, the kit acts as the integration baseline between hardware and the computational graph. Its role is to provide deterministic enough sensor and actuator data flow for development, not to define a final product architecture. This distinction matters in research and field robotics, where payloads change often.

A ROS 2-oriented Developer Kit should align with standard message types and frame conventions. In practice this means:

odometry on nav_msgs/msg/Odometry
laser scans on sensor_msgs/msg/LaserScan
point clouds on sensor_msgs/msg/PointCloud2
camera images on sensor_msgs/msg/Image
IMU data on sensor_msgs/msg/Imu

Frame naming should follow common ROS practice, with links such as base_link, odom, map, and sensor-specific frames. URDF is usually used to define geometry and sensor placement. REP-103 defines standard units and coordinate conventions in ROS, including SI units and right-handed frames. REP-105 defines the relationship between base_link, odom, map, and earth, which is directly relevant for mobile robots with odometry and global localization.

ros2 topic list
ros2 topic echo /odom
ros2 topic hz /scan
ros2 run tf2_tools view_frames

A small ROS 2 launch structure for a Developer Kit may look like this:

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 here>'}]
        ),
        Node(
            package='leo_base',
            executable='base_driver'
        ),
        Node(
            package='rplidar_ros',
            executable='rplidar_composition'
        ),
        Node(
            package='robot_localization',
            executable='ekf_node',
            name='ekf_filter_node',
            parameters=['ekf.yaml']
        )
    ])

Key parameters and metrics

A Developer Kit is evaluated by integration quality, not only by CPU model or RAM size. For robotics work, the important parameters affect timing, bandwidth, and deployability on a moving platform.

Parameter	Why it matters	Typical range or example
CPU/GPU resources	Determines whether SLAM, perception, and simulation can run onboard	Raspberry Pi class for basic ROS 2 tasks, Jetson class for vision inference
Sensor bandwidth	Affects USB/Ethernet bus saturation and packet loss	2D LiDAR at 5-15 Hz, depth camera at 30 FPS
Time synchronization	Required for sensor fusion and accurate TF alignment	NTP/PTP or hardware timestamps where available
Power budget	Limits payload combinations and compute upgrades	Must cover compute, sensors, and startup current
Ingress protection	Determines field suitability	Depends on the base platform and added payload enclosure
Driver maturity	Reduces integration risk	ROS 2 packages with maintained documentation and active releases

For sensor fusion, update rate and latency matter more than peak resolution alone. An IMU at 100-200 Hz and wheel odometry at tens of Hz are often sufficient for a compact UGV. A 2D LiDAR for local navigation commonly publishes at 5-15 Hz, depending on the sensor model. Exact values depend on the manufacturer specification and selected scan mode.

Use on Leo Rover and Raph Rover

On Leo Rover, the Developer Kit concept is closely tied to rapid experimentation. The platform already provides mobile base functionality, differential drive, onboard compute based on Raspberry Pi, and ROS support. This makes it suitable for integrating a research payload without redesigning the whole rover. Typical kit extensions include a 2D LiDAR, Intel RealSense depth camera, external IMU, GNSS receiver, and a custom ROS 2 package set. Technical documentation is available at docs.fictionlab.pl/leo-rover.

On Leo Rover, a practical Developer Kit setup often targets these tasks:

teleoperation and base control over ROS 2
odometry validation and EKF fusion
small-scale SLAM and Nav2 tests
camera-based perception or AprilTag experiments

Raph Rover addresses a different part of the design space. Its larger chassis and payload capacity make it more suitable when the Developer Kit must include heavier sensors, higher power compute, or field instrumentation. Examples include multi-LiDAR layouts, industrial GNSS/RTK units, ruggedized networking, or larger battery-backed compute modules. This does not make it a replacement for Leo Rover in lab education. It is a better fit where payload mass, power, and terrain margin are higher priorities.

Limitations and trade-offs

A Developer Kit reduces setup time, but it does not eliminate system engineering. In mobile robotics, the main trade-off is between convenience and final-system optimization. Predefined kits are usually less optimized for weight, thermals, EMI, and connector ruggedness than a custom design.

For example, a ROS 2 kit that works well indoors may still need substantial work for outdoor autonomy:

sensor calibration and extrinsics refinement
clock synchronization under multi-sensor load
weather and dust protection beyond the base platform
CPU and memory profiling for long missions
navigation tuning for differential drive on uneven terrain

This is relevant for Leo Rover because ROS support does not imply autonomous operation out of the box. A navigation stack must still be integrated and validated. On Raph Rover, the main limitation is often system complexity. As payload count increases, power distribution, thermal design, and TF consistency become harder than the initial hardware assembly.

Normative references and standards

The term Developer Kit itself is not defined by a single robotics standard, so its meaning should be anchored in the standards and documentation of the components it exposes. In ROS-based UGV work, the following references are the most relevant:

REP-103 – Standard Units of Measure and Coordinate Conventions.
REP-105 – Coordinate Frames for Mobile Platforms.
URDF – robot model description used by ROS tooling.
ROS 2 documentation – middleware, launch, lifecycle, parameters, QoS behavior.
Manufacturer specifications – sensor rate, range, accuracy, power draw, interface type.

When evaluating or specifying a Developer Kit for a rover, the verification criteria should be concrete: supported ROS 2 distribution, message interfaces, frame conventions, electrical interfaces, power limits, and documented integration examples. This makes the term useful in engineering practice rather than promotional language.