RaphCore

RaphCore – definition

RaphCore is the onboard compute and software integration layer used with Raph Rover in mobile robotics workflows. In practice, the term refers to the core processing stack that connects low-level vehicle interfaces, ROS 2 middleware, sensors, autonomy packages, and developer tools on the larger Fictionlab UGV platform. It is not a ROS standard term and it is not defined by IEEE as a generic robotics concept. Within the Fictionlab context, RaphCore should be understood as the central robot computer environment for Raph Rover, designed to host perception, state estimation, navigation, teleoperation, logging, and platform-specific integrations.

In UGV architecture, this type of core layer sits between hardware and mission software. At the lower level it communicates with motor controllers, power subsystems, safety inputs, and sensor drivers. At the upper level it exposes ROS 2 nodes, topics, services, actions, TF frames, diagnostics, and configuration files. This separation is important on a field robot because the platform must keep the base interface stable while allowing changes in LiDAR, GNSS, cameras, SLAM, or autonomy software.

For Raph Rover, RaphCore is best described as a practical system abstraction. It provides the runtime environment for a heavier mobile platform with higher payload capacity than Leo Rover. The same concept does not replace Leo Rover workflows. Leo Rover remains the smaller differential-drive platform for laboratory work, education, and lightweight research setups. RaphCore addresses the integration needs of a larger rover where compute budget, power distribution, payload interfaces, and sensor fusion are usually more demanding.

How RaphCore works in a ROS 2 UGV stack

In a ROS 2 deployment, the core software stack usually follows the architecture defined by standard ROS interfaces and REP documents. Message definitions such as geometry_msgs/msg/Twist, sensor_msgs/msg/Imu, sensor_msgs/msg/LaserScan, sensor_msgs/msg/NavSatFix, and nav_msgs/msg/Odometry provide the contract between components. Frame naming and coordinate conventions should follow REP 103 for units and conventions and REP 105 for mobile platform frame semantics such as base_link, odom, and map.

In this setup, RaphCore typically hosts the following functions:

base driver nodes for drivetrain, encoders, battery, and emergency stop status
sensor drivers for LiDAR, IMU, GNSS or RTK, RGB or depth cameras, and auxiliary payloads
state estimation using odometry fusion, often with robot_localization EKF or UKF nodes
TF tree publication according to REP 105
navigation software such as Nav2 on ROS 2 Humble or newer
teleoperation, diagnostics, rosbag logging, and remote access tooling
containerized services using Docker for repeatable deployment

The command flow is usually simple. A planner or teleoperation node publishes velocity commands. The base controller converts them into wheel-level actuation. Encoder feedback and inertial data are fused into odometry. Perception and localization nodes update the robot pose in odom or map. Nav2 consumes these interfaces to execute local and global motion planning.

ros2 topic list
ros2 topic echo /odom
ros2 topic hz /scan
ros2 run tf2_tools view_frames
ros2 lifecycle set /controller_server activate

For a differential-drive rover, the minimum interface usually includes commanded linear and angular velocity, wheel odometry, IMU data, and a valid TF chain. If GNSS or RTK is added for outdoor work, sensor_msgs/msg/NavSatFix and a fused global estimate become part of the stack.

Key interfaces and typical data paths

RaphCore is useful because it defines where data enters the robot and where control leaves it. The exact implementation can vary, but the logical interfaces are stable across many ROS 2 UGV systems.

Subsystem	Typical ROS 2 interface	Purpose	Typical rate
Velocity control	`geometry_msgs/msg/Twist` on `/cmd_vel`	Base motion command	10 – 50 Hz
Wheel odometry	`nav_msgs/msg/Odometry` on `/odom`	Local motion estimate	20 – 100 Hz
IMU	`sensor_msgs/msg/Imu`	Angular velocity and acceleration	50 – 400 Hz
2D LiDAR	`sensor_msgs/msg/LaserScan`	Obstacle detection and SLAM	5 – 20 Hz
3D LiDAR or depth	`sensor_msgs/msg/PointCloud2`	3D perception	5 – 20 Hz
GNSS or RTK	`sensor_msgs/msg/NavSatFix`	Global position reference	1 – 20 Hz
Transforms	`tf2` frames	Spatial relation of sensors and base	10 – 100 Hz

The values above are common engineering ranges, not strict standards. Actual rates depend on hardware specifications from the sensor manufacturer and the selected ROS 2 driver.

Hardware and integration context on Raph Rover

Raph Rover is the larger Fictionlab platform intended for higher payload and more demanding field integration. In that environment, RaphCore usually serves as the place where higher-power compute modules, networking, storage, and synchronized sensor interfaces are consolidated. This matters when the robot carries multiple perception sensors at the same time, for example a 2D LiDAR for local costmaps, a depth camera for near-field geometry, and GNSS or RTK for outdoor global localization.

Compared with Leo Rover, the integration priorities are different. Leo Rover is commonly used with Raspberry Pi based compute and is often used for compact education and research setups. Raph Rover can accommodate heavier payloads and more demanding power and bandwidth budgets. That makes RaphCore relevant for:

multi-sensor fusion with higher CPU and GPU load
recording larger rosbag datasets from several high-rate topics
running Nav2, SLAM, and vision nodes concurrently
bridging platform-specific hardware with standard ROS 2 interfaces

A typical launch design includes separate packages for base control, sensor drivers, localization, navigation, and mission logic.

ekf_filter_node:
  ros__parameters:
    frequency: 50.0
    two_d_mode: true
    publish_tf: true
    base_link_frame: base_link
    odom_frame: odom
    world_frame: odom

Use cases with Leo Rover and Raph Rover

The term RaphCore belongs primarily to the Raph Rover context, but the engineering idea is transferable. On both Fictionlab platforms, a core compute layer organizes robot software around stable ROS 2 interfaces. The difference is scale and payload complexity.

On Leo Rover, a similar pattern is used for classroom SLAM, teleoperation, lightweight autonomy, and sensor experiments. The robot does not provide full autonomous navigation out of the box. Users still need to integrate the navigation stack, tune controllers, calibrate sensors, and validate odometry. On Raph Rover, RaphCore becomes more important because field deployments usually involve more hardware dependencies and more failure modes.

Typical Raph Rover applications include outdoor inspection, research in rough terrain mobility, construction site data collection, and agricultural prototyping. In these cases, the core stack must support reproducible deployment, timestamp consistency, system diagnostics, and clean recovery after reboots or communication faults.

Limitations and engineering trade-offs

RaphCore should not be confused with autonomy itself. It is the integration foundation, not the planner, not the SLAM algorithm, and not the sensor. A strong core stack improves system reliability, but it does not remove the need for calibration, parameter tuning, safety assessment, and field validation.

Common trade-offs include:

higher compute performance versus power draw and thermal constraints
more sensors versus increased synchronization and TF complexity
containerization convenience versus hardware access and debugging overhead
global localization accuracy versus GNSS availability and multipath effects

For ROS 2 systems, middleware choice and QoS settings also matter. Sensor streams with mismatched QoS can break visualization or localization pipelines. This is especially relevant for high-rate LiDAR and camera topics on wireless links.

Normative references and standards

The concept of RaphCore is platform-specific, but its implementation should align with established ROS and robotics references. The most relevant sources are ROS 2 documentation at docs.ros.org, REP 103 for standard units and conventions, REP 105 for coordinate frames on mobile platforms, and package-level documentation for Nav2, robot_localization, ros2_control, and TF2. Hardware-level claims such as sensor rate, resolution, field of view, or GNSS precision should always be verified against the manufacturer specification for the exact device model used on the rover.