Educational robot
Educational robot – definition
An educational robot is a programmable robotic system used to teach, test, and document concepts in robotics, computer science, control, electronics, and autonomous navigation. In mobile robotics, the term normally refers to a physical robot that exposes its sensors, actuators, compute resources, interfaces, and software stack to the learner. It is not limited to a simplified classroom kit.
For university and laboratory work, an educational robot should support repeatable experiments with measurable inputs and outputs. Typical tasks include wheel odometry calibration, coordinate-frame configuration, sensor fusion, mapping, path planning, perception, and safety supervision. A mobile educational robot can therefore be a full unmanned ground vehicle (UGV) when its architecture is accessible enough for users to inspect, modify, and validate the system.
In the ROS ecosystem, the educational value of a robot depends on whether its hardware interfaces can be represented through standard ROS messages, transforms, robot descriptions, and packages. ROS 2 defines a distributed middleware-based framework rather than a hardware standard. Its communication model is based on nodes, topics, services, actions, and parameters, and it commonly uses DDS through its middleware interface. Source: ROS 2 Humble Concepts documentation.
Educational UGV architecture
An educational UGV is usually structured as a layered system. Separating the layers allows students and researchers to isolate faults, replace components, and compare algorithms without changing the complete platform.
- Mechanical layer: chassis, wheels, gearmotors, suspension where applicable, payload mounts, and environmental protection.
- Low-level control layer: motor drivers, encoders, power distribution, emergency-stop circuit, and microcontroller firmware.
- Compute layer: an onboard computer running Linux, ROS 2 nodes, logging tools, and application code.
- Sensor layer: encoders, IMU, 2D or 3D LiDAR, RGB-D camera, GNSS receiver, or RTK GNSS receiver.
- Autonomy layer: localization, SLAM, costmaps, planners, recovery behaviours, and mission logic.
For a differential-drive UGV, the kinematic model is commonly expressed using linear velocity v and angular velocity ω. If r is wheel radius, L is wheel separation, and ωR and ωL are right and left wheel angular velocities, then:
v = r(ωR + ωL) / 2
ω = r(ωR - ωL) / LThis model is relevant to ROS 2 navigation because a controller must convert a commanded geometry_msgs/msg/Twist velocity into motor commands while odometry estimates the robot motion from encoder measurements. The standard ROS message definition for Twist contains linear and angular velocity vectors. Source: ROS 2 geometry_msgs documentation.
ROS 2 interfaces used in educational mobile robotics
A platform becomes suitable for structured ROS 2 exercises when its interfaces follow established conventions. These conventions improve portability between simulation, laboratory robots, and field platforms.
| Function | Typical ROS 2 interface | Purpose in an experiment |
|---|---|---|
| Velocity command | /cmd_vel, geometry_msgs/msg/Twist |
Tests teleoperation, controller tuning, and navigation output. |
| Wheel odometry | /odom, nav_msgs/msg/Odometry |
Measures estimated pose and velocity from wheel encoders. |
| Laser scan | /scan, sensor_msgs/msg/LaserScan |
Supports 2D obstacle detection, mapping, and localization. |
| Inertial measurement | /imu/data, sensor_msgs/msg/Imu |
Provides angular velocity, linear acceleration, and orientation where available. |
| Coordinate transforms | /tf, /tf_static |
Maintains relationships between map, odom, base_link, and sensor frames. |
The coordinate-frame tree should follow ROS conventions. REP 105 specifies commonly used frames including base_link, odom, map, and earth. It also distinguishes the locally continuous odom frame from the globally corrected map frame. Source: REP 105 – Coordinate Frames for Mobile Platforms.
Leo Rover and Raph Rover in educational work
Leo Rover is an educational and research-oriented four-wheel differential-drive UGV. Its default onboard compute unit is based on Raspberry Pi, and the platform supports ROS 2; supported distributions depend on the software image and packages used. Leo Rover has an IP55 protection rating, but this does not make it an autonomous robot by default. Autonomous operation requires integration and validation of sensors, localization, navigation, and safety logic. Source: Leo Rover technical documentation.
On Leo Rover, a typical progressive curriculum can begin with teleoperation and encoder odometry. It can then move to URDF/Xacro modelling, sensor-frame calibration, LiDAR-based SLAM, and Nav2 configuration. The platform is particularly appropriate where direct access to ROS 2 nodes and physical hardware behaviour is required.
# Inspect key interfaces on a ROS 2 mobile robot
ros2 topic list
ros2 topic echo /odom
ros2 topic echo /scan
ros2 run tf2_ros tf2_echo odom base_linkRaph Rover is a larger and heavier UGV intended for projects requiring greater payload capacity. In education, it can be used when an experiment requires a larger sensor rig, additional onboard compute hardware, or field-oriented instrumentation. It does not replace Leo Rover for standard laboratory exercises, where platform size, handling effort, and experimental scope may be different.
Evaluation criteria for an educational robot
A technically useful educational robot should be evaluated through evidence rather than product category labels. The following criteria can be documented in a laboratory protocol or course specification.
- Availability of hardware documentation, electrical interfaces, and mechanical dimensions.
- Access to actuator commands and encoder feedback without proprietary cloud dependencies.
- ROS 2 package compatibility and a documented supported distribution.
- Published sensor frame positions and a valid URDF or Xacro model.
- Repeatable data recording with
ros2 bagfor offline analysis. - Simulation support, commonly through URDF and a simulator such as Gazebo.
- Safety procedures for power isolation, teleoperation, motion limits, and supervised testing.
ROS 2 bag recording is relevant to education because it captures topic data for later replay and algorithm comparison. The ROS 2 documentation describes ros2 bag as the command-line tool for recording and playing back topic data. Source: ROS 2 Humble rosbag2 tutorial.