BMS (Battery Management System)

BMS (Battery Management System) – definition

A BMS, or Battery Management System, is an embedded electronic subsystem that monitors, protects, and in many designs actively controls a rechargeable battery pack. In mobile robotics, a BMS is not the battery itself and not only a charger interface. It is the layer responsible for keeping the pack within safe electrical and thermal limits during charge, discharge, storage, and fault conditions.

For a UGV, the BMS is part of the power architecture. It typically measures individual cell voltages, pack voltage, charge and discharge current, and temperature. It may also estimate state of charge (SoC), state of health (SoH), remaining capacity, and available power. In practical terms, the BMS decides whether the battery can safely power the compute stack, motor drivers, sensors, radios, and payloads.

On platforms such as Leo Rover and Raptor Rover, the BMS matters because mobile robots operate under variable loads. Current draw changes with terrain resistance, acceleration, payload mass, CPU or GPU load, and added peripherals such as LiDAR or depth cameras. A BMS reduces the risk of undervoltage, overcurrent, overtemperature, or cell imbalance. It also provides the telemetry needed for higher-level software to make decisions such as mission abort, return-to-base, or payload shutdown.

What a BMS does in a mobile robot

In a UGV, the BMS is part of the low-level power safety chain. It works below ROS 2, but its outputs are often exposed to ROS topics, diagnostics, or vendor-specific APIs. The goal is predictable and safe energy usage.

The core BMS functions are usually the following:

Cell voltage monitoring – protects each series cell from overcharge and overdischarge.
Current monitoring – detects excessive discharge current, charge current, and short-circuit events.
Temperature monitoring – limits operation outside the allowed battery temperature range.
Cell balancing – reduces voltage spread between cells, usually near full charge.
Contactor or MOSFET control – disconnects the pack under fault conditions.
Fuel gauging – estimates SoC and sometimes SoH using coulomb counting and voltage models.
Telemetry – exposes battery data over SMBus, I2C, CAN, UART, or proprietary interfaces.

For lithium-ion and lithium iron phosphate packs used in robotics, these protections are not optional. Cell chemistry determines safe voltage windows, charge profiles, and thermal behavior. Exact thresholds come from the cell manufacturer and the BMS vendor. They must be treated as hardware-level constraints, not as software preferences.

Key parameters and metrics

Engineers integrating a BMS into a rover should verify measurable parameters, not just nominal battery capacity. The same nominal pack can behave differently depending on discharge rate, balancing strategy, and protection thresholds.

Parameter	Meaning in UGV integration	Typical unit
Series / parallel configuration	Defines pack voltage and current capability, for example 4S, 6S, 8S	S / P
Nominal pack voltage	Used to size motor drivers, DC-DC converters, and compute power rails	V
Capacity	Charge storage under specified discharge conditions	Ah
Energy	More useful than Ah when comparing packs of different voltages	Wh
Continuous discharge current	Must exceed expected traction plus payload current	A
Peak discharge current	Relevant during startup, wheel slip, slope climbing, or stalls	A
Cell balancing current	Affects how quickly the pack can be equalized near full charge	mA
SoC update rate	Determines how often autonomy software sees fresh energy data	Hz
Measurement accuracy	Important for mission planning and low-battery thresholds	% / mV / A

A simple energy estimate is:

Energy [Wh] = Nominal Voltage [V] × Capacity [Ah]

Runtime then depends on average power draw:

Runtime [h] = Energy [Wh] / Average Load [W]

In a rover, average load is not constant. Motor current increases on soft ground, ramps, and during aggressive turns. Compute load rises when running SLAM, Nav2, recording rosbag data, or AI inference.

BMS telemetry in ROS 2

ROS 2 does not define a single mandatory battery driver for all robots, but battery state is commonly published using sensor_msgs/msg/BatteryState. This message is available in ROS 2 and includes fields such as voltage, temperature, current, charge, capacity, percentage, power_supply_status, and power_supply_health.

In a rover stack, a hardware interface node reads the BMS over a physical bus and republishes normalized values to ROS 2. The message can then be consumed by diagnostics, mission logic, or a user interface.

battery_publisher:
  ros__parameters:
    poll_rate_hz: 5.0
    warn_percentage: 0.20
    critical_percentage: 0.10
    interface: can
    frame_id: battery_link

ros2 topic echo /battery_state
ros2 topic hz /battery_state
ros2 interface show sensor_msgs/msg/BatteryState

For field robots, a telemetry rate of 1-10 Hz is usually sufficient for supervision. Faster rates may be useful for logging current spikes, but high-rate battery topics are rarely needed by navigation loops. The BMS itself may sample internally much faster than the ROS 2 topic rate.

Integration on Leo Rover and Raptor Rover

On Leo Rover, the BMS is especially important because the default compute platform is Raspberry Pi-based and the robot is often extended with USB peripherals, extra radios, depth cameras, or small LiDAR units. These additions can change the power budget enough to affect runtime and brownout behavior. Leo Rover supports ROS 2, commonly through user-provided software stacks and integrations, so battery telemetry can be integrated into standard ROS 2 diagnostics and mission nodes.

Leo Rover is a differential-drive, 4-wheel UGV with IP54 protection. It is not an autonomous platform out of the box. When a navigation stack is added, battery awareness should be part of the system design. A common rule is to define:

a warning threshold for operator notification,
a critical threshold for stopping non-essential payloads,
an emergency threshold above the BMS cutoff margin.

On Raptor Rover, the power architecture becomes more demanding because payloads are larger and peak currents can be higher. This makes continuous current rating, peak current handling, thermal derating, and connector selection more critical than on a smaller educational rover. A larger UGV may also use a distributed power design with separate rails for traction, compute, and payload, while the BMS still supervises the main pack.

Failure modes and design trade-offs

A BMS improves safety, but it also introduces system-level constraints. If the cutoff threshold is too conservative, the rover may stop while there is still usable energy left. If it is too permissive, cells may be stressed or damaged. SoC estimation is also imperfect, especially under dynamic loads and low temperatures.

Typical engineering trade-offs include:

Passive vs active balancing – passive is simpler, active can be more efficient but is more complex.
Low-side vs high-side switching – affects grounding and fault behavior.
Pack-level vs cell-level observability – more detailed telemetry improves diagnosis.
Smart battery interface vs custom protocol bridge – easier integration versus flexibility.

For outdoor UGVs, low temperature is a major source of error. Internal resistance rises, available capacity drops, and loaded voltage sags earlier. The BMS may report a lower usable SoC than at room temperature even if the nominal pack capacity is unchanged.

Normative references and standards

The precise implementation of a BMS depends on chemistry, pack design, and vendor hardware. Still, several references are directly relevant in robotics integration:

ROS 2 message definition: sensor_msgs/msg/BatteryState – standard battery telemetry representation in ROS 2.
REP-2000 – ROS 2 Releases and Target Platforms, useful when specifying supported ROS 2 distributions in a robot stack.
Manufacturer battery and BMS datasheets – required for charge limits, discharge limits, balancing behavior, and temperature range.
IEEE literature on battery state estimation and battery management – commonly used for SoC and SoH modeling methods.

In practice, the authoritative source for voltage thresholds, charge current, discharge current, and operating temperature is always the battery cell and BMS manufacturer documentation. ROS 2 only standardizes how telemetry may be represented in software, not the electrochemical limits.

BMS (Battery Management System)