Hot-swappable Batteries

Hot-swappable Batteries – definition

Hot-swappable batteries are battery modules that can be removed and replaced without shutting down the robot’s critical electronics or rebooting the compute stack. In mobile robotics, this usually means the power architecture contains at least two energy paths: the main removable battery and a temporary hold-up source such as a secondary battery, supercapacitor bank, or redundant power rail. The goal is continuity of operation during battery exchange.

For UGV platforms, hot swapping is a power-system feature, not just a mechanical battery tray. A battery is not truly hot-swappable if removing it causes loss of power on the single-board computer, motor controller, network switch, safety I/O, or sensor time base. In ROS 2 terms, a valid hot-swap design should preserve node execution, logging, and state estimation pipelines during the swap window; middleware session continuity may depend on network and driver behavior.

On platforms such as Leo Rover and Raph Rover, hot-swappable batteries are relevant when the robot is used in field tests, research experiments, long mapping sessions, or inspection routes where downtime from full shutdown and reboot is undesirable. The practical benefit is not only longer mission availability. It also reduces disruption to localization, wireless links, containerized applications, and sensor warm-up cycles.

How hot swapping works in mobile robotics

A hot-swap battery system requires electrical isolation, controlled power-path switching, and sufficient energy buffering. The core problem is simple: if the main battery is disconnected, bus voltage must remain within the allowable range of the computer, motor drivers, and sensors until a new pack is connected.

In practice, the following elements are commonly used in UGV power systems:

ideal-diode or OR-ing controllers for seamless source switching
a backup battery or supercapacitor hold-up stage
battery management system (BMS) with overcurrent, undervoltage, and temperature protection
DC-DC converters with input voltage ranges wide enough to tolerate pack transitions
inrush-current limiting to avoid connector arcing and bus dips
telemetry for battery voltage, current, state of charge, and fault status

The required hold-up time depends on the battery exchange procedure. If the operator can remove and insert a pack within 2 to 10 s, the backup source must keep all protected rails above their minimum voltage for that duration. The energy budget can be estimated from a basic relation:

E = P x t

where E is required energy in joules, P is protected load power in watts, and t is hold-up time in seconds. For example, a 25 W protected compute-and-sensor rail held for 5 s needs at least 125 J, excluding converter losses and safety margin.

Key parameters and metrics

For a robotics engineer, hot swapping is evaluated through measurable electrical and system-level parameters. These values determine whether the feature is useful for a ROS-based UGV rather than only nominally supported.

Parameter	Why it matters	Typical engineering concern
Hold-up time	Maximum battery exchange duration without reboot	Must exceed real operator swap time with margin
Bus voltage droop	Prevents SBC, MCU, LiDAR, and camera brownout	Transient dips can reset USB or Ethernet devices
Switchover time	Defines continuity between power sources	Microseconds to milliseconds depending on topology
Peak current capability	Supports motor startup and compute bursts	Backup path may power only logic rails, not traction
BMS telemetry rate	Enables ROS diagnostics and mission decisions	Often 1-10 Hz over CAN, SMBus, I2C, or UART
Connector cycle life	Affects field reliability	Important in research fleets with frequent swaps

For ROS 2 integration, battery telemetry is often published through sensor_msgs/msg/BatteryState. This message includes voltage, temperature, current, charge, capacity, design capacity, percentage, power supply status, health, and technology. It is a standard message type used in both ROS 1 and ROS 2 for battery reporting, as documented on docs.ros.org.

ROS 2 integration and diagnostics

In ROS 2, hot-swappable batteries affect power monitoring, mission logic, and fault handling more than motion control itself. The compute unit should continue running during a swap, while application nodes observe a temporary change in battery source state.

A common implementation publishes battery and power-path information on dedicated topics:

/battery_state
/power_source
/power_events
/diagnostics

The most important message is usually sensor_msgs/msg/BatteryState. Additional custom topics may expose pack presence, backup rail activation, or BMS alarm bits. Diagnostic aggregation can then convert these signals into warnings for the operator or autonomy stack.

battery_monitor:
  ros__parameters:
    publish_rate_hz: 2.0
    low_battery_threshold: 0.20
    critical_battery_threshold: 0.10
    enable_hot_swap_events: true
    battery_state_topic: /battery_state
    diagnostics_topic: /diagnostics

On ROS 2 Humble or newer, this data can be consumed by lifecycle nodes, mission managers, or Nav2-related supervision logic. During battery replacement, the robot may remain in a safe idle state, preserve localization if compute stays alive, and resume operation when the new pack is validated.

Use on Leo Rover and Raph Rover

On Leo Rover, hot swapping is most relevant in educational labs and outdoor experiments where the onboard Raspberry Pi runs ROS and where repeated reboot cycles slow down testing. Because Leo Rover is a differential-drive UGV and not an autonomous platform out of the box, users typically add their own navigation stack, sensors, and power accessories. In such setups, preserving the compute session during battery replacement can save time and reduce failure modes in custom integrations.

Typical Leo Rover use cases include:

continuous ROS 2 development with Docker containers and remote SSH sessions
long SLAM experiments where map-building software should not restart
field classes where multiple battery packs are rotated across robots

On Raph Rover, the same concept matters even more when payloads draw more power or require longer deployment windows. A larger UGV may carry heavier compute, additional LiDARs, RTK receivers, or edge AI hardware. In that case, hot swapping can keep high-value payload electronics alive while the main traction battery is exchanged. The engineering constraint is stricter, because payload current, inrush, and backup energy requirements are higher.

Limitations and trade-offs

Hot swapping does not mean the robot can always continue driving normally during battery exchange. Many systems only protect logic rails and compute, not traction power. If the motor bus drops during the swap, the robot must stop safely even if ROS 2 nodes remain active.

The main trade-offs are:

higher electrical complexity than a single-pack design
extra mass and cost for backup energy storage
more failure points in connectors, controllers, and BMS logic
need for validation under real peak loads, not only bench tests

Another practical issue is state consistency. If USB cameras, Ethernet switches, or GNSS receivers are on unprotected rails, they may reset independently of the main computer. The system then remains partially alive but loses sensor streams. For SLAM, visual odometry, or RTK fusion, this can be as disruptive as a full reboot. A correct design therefore defines exactly which rails are protected and what operational state is guaranteed during swap.

Normative references and standards

The term itself is mostly used in hardware and embedded power design rather than in a single robotics standard. In ROS-based systems, the closest normative reference for software representation of battery data is sensor_msgs/msg/BatteryState in ROS documentation. For coordinate frames and robot description, related integration often follows REP 103 for standard units and conventions, REP 105 for mobile platform frames, and URDF conventions from the ROS ecosystem. These do not define hot swapping, but they define how a mobile robot should expose consistent telemetry and physical configuration around the power subsystem.

For battery hardware, authoritative references are manufacturer specifications for the battery chemistry, BMS, DC-DC converters, and power-path controllers. Engineering validation should include undervoltage thresholds, connector ratings, thermal limits, charge and discharge current, and protection behavior under transient load.

Hot-swappable Batteries