Autonomous docking

Autonomous docking – definition

Autonomous docking is the ability of a mobile robot to navigate to a defined docking station, align its chassis with the station, complete a final low-speed approach, and verify a successful physical or electrical connection without continuous human control. For a UGV, docking commonly supports battery charging, data transfer, sheltered parking, repeatable sensor calibration, or deployment of a payload.

Docking is not equivalent to ordinary waypoint navigation. A navigation stack can bring a robot near a charging station, but docking requires a controlled terminal manoeuvre with tighter position and heading tolerances. The robot must also detect contact or charging state and handle failure states, such as an occupied dock, missed alignment, wheel slip, sensor occlusion, or a blocked approach path.

In ROS 2 mobile robotics, autonomous docking is usually implemented as a state machine or an action-driven behaviour connected to localization, perception, motion control, battery monitoring, and safety supervision. The coordinate-frame conventions used by this system should follow REP 105, which defines commonly used frames including map, odom, and base_link.

Docking sequence for a differential-drive UGV

Leo Rover and Raph Rover use mobile-base architectures where the robot approaches the dock on a planar surface. A practical docking sequence separates global navigation from final alignment. This reduces the effect of global localization drift close to the charging contacts.

Navigate to a staging pose. The robot reaches a collision-free pose in front of the dock using a map-based navigation stack, such as Nav2.
Acquire dock-relative observations. A camera marker, LiDAR reflector pattern, depth geometry, UWB anchor, or other dock-local reference is detected.
Estimate relative pose. The system estimates the dock pose relative to base_link, typically as planar position (x, y) and yaw θ.
Perform final alignment. A low-speed controller corrects lateral offset and heading error while preserving a clear escape path.
Confirm engagement. The robot validates mechanical contact, charging current, a dock switch, or a battery-state transition.
Recover on failure. If confirmation is absent, the robot reverses to a safe pose and retries only when retry limits and safety conditions allow it.

Coordinate frames and relative-pose estimation

The final approach should be controlled in a dock-relative frame rather than solely in the global map frame. Global localization can be adequate for reaching a staging pose but may not provide the repeatability required by mechanical charging contacts.

A docking controller can use the relative error vector:

e = [x_dock, y_dock, theta_dock]T

where x_dock is longitudinal distance to the dock, y_dock is lateral displacement, and theta_dock is yaw error. For a differential-drive base, the controller produces linear velocity v and angular velocity ω. The resulting command is generally published as geometry_msgs/msg/Twist on a velocity-command interface such as /cmd_vel.

ROS coordinate conventions should also follow REP 103. In particular, ROS uses right-handed coordinate frames, with x forward, y left, and z upward for body-fixed mobile-base frames.

ROS 2 architecture for docking

ROS 2 systems commonly combine Nav2 for navigation with a docking-specific server or behaviour tree. Nav2 provides a documented docking framework through its Dock Robot functionality. The implementation still requires a robot-specific dock model, sensor interface, and verification method.

Function	Typical ROS 2 interface	Purpose during docking
Global robot pose	`tf2`, `map -> odom`	Navigation to the staging pose
Robot odometry	`nav_msgs/msg/Odometry`	Short-range motion estimate and velocity feedback
Dock observation	`geometry_msgs/msg/PoseStamped`	Relative dock pose from perception
Range sensing	`sensor_msgs/msg/LaserScan` or `sensor_msgs/msg/PointCloud2`	Obstacle detection and final distance estimation
Charging status	`sensor_msgs/msg/BatteryState`	Verification of charging or power-source state

The message definitions above are maintained in the ROS 2 common interface packages and should be checked against the target distribution documentation. The robot must expose a reliable transform chain from sensor frames to base_link. Incorrect camera or LiDAR extrinsics can produce systematic lateral docking errors.

Dock perception methods

The choice of perception method depends on lighting, dock geometry, surface conditions, and required repeatability. A robust implementation often uses two independent signals: one for pose estimation and one for engagement confirmation.

Fiducial markers: AprilTag or ArUco markers provide an identifiable dock reference for an RGB or depth camera. They require controlled marker placement and sufficient image quality.
LiDAR geometry: Reflectors, corner structures, or fitted line segments can support operation in low-light environments. Performance depends on scan density and the dock’s observable geometry.
Depth cameras: A depth image can estimate dock geometry at short range, but reflective surfaces and sunlight may reduce depth quality.
Contact and electrical sensing: Limit switches, charge-controller telemetry, and battery voltage or current measurements verify that docking succeeded.

Use on Leo Rover and Raph Rover

Leo Rover is a four-wheel, differential-drive UGV with an onboard Raspberry Pi and ROS 2 support. It is suitable for laboratory docking experiments, teaching navigation, and validation of perception-driven final approach. Autonomous docking is not provided by the base platform alone. It requires a dock, compatible charging hardware, sensor integration, and a configured navigation and safety stack.

For Leo Rover, a common architecture is to run base control and basic ROS 2 nodes on the onboard computer, then add a camera, 2D LiDAR, or depth sensor according to the docking method. Compute-intensive perception can require an external computer or a higher-performance companion computer. Hardware interfaces, frame names, and available ROS packages should be verified against Leo Rover technical documentation.

Raph Rover can use the same logical workflow, but its Ackermann steering cannot correct heading in place, so the staging pose must leave enough straight approach distance for final alignment. It is also intended for heavier payloads and larger field deployments. Its dock design must account for chassis mass, wheel-terrain interaction, charging connector mechanics, and the clearance required by installed payloads. A dock validated for Leo Rover should not be assumed to fit Raph Rover without mechanical and electrical verification.

Key metrics and validation criteria

Docking performance should be measured during repeated trials instead of inferred from successful single runs. The acceptance criteria must be derived from the dock connector geometry and the operational safety case.

Final lateral error and yaw error at the contact point.
Docking success rate across repeated autonomous attempts.
Time from docking goal acceptance to verified charge state.
Number of recovery manoeuvres per successful docking cycle.
False-positive charge confirmations and missed contact detections.
Behaviour under degraded localization, partial marker occlusion, and obstacle appearance.

Safety and failure handling

Docking controllers should command conservative motion near the station and stop when perception confidence is lost. The system should not treat geometric proximity as proof of charging. Confirmation should come from a hardware-level signal, charge-controller telemetry, or another independently observable state.

Recovery logic should include a bounded number of retries, a reverse trajectory, collision monitoring, and fault reporting. If the robot operates near people or shared equipment, emergency-stop behaviour and power-system protection must be designed at the platform level rather than delegated to a ROS 2 application node.

Autonomous docking