MAVLink Battery Telemetry for UAV BMS

Start With the MAVLink Battery Data Path

Before choosing fields or refresh rates, define where MAVLink battery messages come from. In many UAV systems, the BMS does not speak MAVLink directly. The BMS may send data to the flight controller through DroneCAN, CAN, UART, SMBus, or RS485, and then the flight controller publishes MAVLink battery messages to the ground station. In other systems, a companion computer receives BMS data and converts it into MAVLink messages. Some smart battery modules can act as independent MAVLink components, but then they need correct system ID, component ID, heartbeat behavior, and battery instance handling.

The MAVLink Battery Protocol states that batteries connected to a flight controller through a non-MAVLink bus are treated as part of the flight-controller component. Batteries that are distinct MAVLink components should emit a HEARTBEAT and use a unique component ID. This distinction matters because it affects how the ground station identifies each battery and how the autopilot uses the data.

Which MAVLink Messages Should Carry Battery Data?

The main message for regular UAV battery reporting is BATTERY_STATUS. According to the official MAVLink common message set, this message updates the ground-control station with flight-controller battery status, and smart batteries may also use it. It is designed for values that change regularly, such as voltage, current, temperature, remaining battery, consumed energy, and fault state.

For static or infrequently changing battery information, MAVLink also defines BATTERY_INFO and older smart battery information messages. These can carry fields such as design capacity, full-charge capacity, battery name, serial number, cycle count, cell count, SOH, maximum discharge current, and manufacturer information. In practice, many UAV projects use BATTERY_STATUS for frequent telemetry and use a separate mechanism for configuration, maintenance, or pack identity.

Field Mapping for Voltage, Current, Temperature, and Capacity

Field mapping is where many MAVLink battery integration problems start. The BMS may use volts, millivolts, amps, milliamps, Celsius, centi-degrees Celsius, amp-hours, milliamp-hours, or percentage internally. MAVLink fields have specific units and invalid values, so engineering teams should create a mapping sheet before firmware integration.

For voltage, BATTERY_STATUS supports individual cell voltages through voltages and voltages_ext. If individual cell voltages are unknown, the total battery voltage can be placed in the first cell field according to the MAVLink definition. For high-voltage packs, the integration must handle the MAVLink field limits correctly.

For current, current_battery is reported in centi-amps. The MAVLink definition notes that very high currents may overflow this field above 327.67A. This is important for agricultural UAVs, heavy-lift drones, and high-current battery systems. If your BMS measures 400A or 600A peaks, confirm how the autopilot, GCS, and logs handle high current values.

How to Report SOC and SOH Correctly

SOC and SOH should not be treated as the same value. SOC describes remaining usable energy for the current mission. SOH describes long-term battery health compared with the pack's original or expected capacity. In MAVLink, BATTERY_STATUS commonly carries SOC-like information through battery_remaining. SOH belongs more naturally in static or infrequent battery information such as BATTERY_INFO.state_of_health, or in supplier-specific maintenance data if the autopilot stack does not consume that field.

For a UAV Smart BMS, SOC should come from a tested algorithm that combines current integration, voltage behavior, temperature compensation, and calibration. Voltage-only SOC can be misleading because drone packs experience voltage sag during takeoff, climb, wind correction, and payload operation. If SOC is sent to the flight controller or GCS through MAVLink, it should be stable enough for return and landing decisions.

SOH is usually slower-changing. It can be estimated from cycle count, full-charge capacity loss, internal resistance increase, cell imbalance trend, or manufacturer-specific aging logic. If SOH is not supported by the flight stack, it can still be useful in maintenance software, fleet dashboards, or post-flight battery reports.

How to Map Fault Flags and Charge State

The fault_bitmask field in BATTERY_STATUS uses the MAV_BATTERY_FAULT bitmask for smart battery health indication. MAVLink defines fault flags for deep discharge, voltage spikes, cell failure, over-current, over-temperature, under-temperature, incompatible voltage, incompatible firmware, and incompatible cell configuration.

The BMS should not set fault flags casually. Fault flags should represent conditions that the aircraft, ground station, or maintenance system needs to treat seriously. The charge_state field can report whether the battery is OK, low, critical, emergency, failed, unhealthy, or charging. If a battery reports failed or unhealthy status, the fault bitmask should explain why.

Refresh Rate: What Should Be Sent Frequently?

MAVLink battery telemetry should separate high-rate operational data from low-rate identity or health data. The official MAVLink Battery Protocol describes BATTERY_STATUS as the regular battery status message and notes a nominal emission rate around 0.5 Hz for each battery. In real UAV systems, the internal BMS sampling rate may be higher, while the MAVLink stream to the ground station may be lower due to telemetry bandwidth and autopilot configuration.

For engineering integration, define three rates: BMS internal sampling rate, autopilot battery update rate, and GCS telemetry display rate. The BMS may sample voltage and current quickly for protection. The autopilot may need battery status often enough for failsafe logic. The ground station may only need readable display updates. Sending too slowly can delay warnings; sending too quickly can waste bandwidth or create unnecessary logs.

PX4 and ArduPilot Integration Notes

PX4 and ArduPilot may both display MAVLink battery telemetry in a ground station, but the data path can be different. In many PX4 projects, a smart battery may enter the flight controller through DroneCAN, and PX4 then publishes battery status through MAVLink to QGroundControl. In ArduPilot projects, battery data may come from DroneCAN BatteryInfo, SMBus, analog monitor, or another battery monitor source before being displayed in Mission Planner or MAVLink telemetry.

For this reason, a supplier saying “MAVLink battery support” is not enough. The engineering team should ask whether the BMS sends MAVLink directly, whether the flight controller converts another protocol into MAVLink, or whether a companion computer performs the conversion. The answer affects wiring, firmware, message ownership, failsafe behavior, and field validation.

For PX4-specific battery setup, see PX4 Battery Integration Guide for UAV Smart BMS. For ArduPilot setup, see ArduPilot Battery Integration Guide for UAV Smart BMS. For protocol and SOC reporting basics, see AYAA FAQ Q11 on communication protocols.

Bench Test Checklist Before Flight

Before using MAVLink battery telemetry for flight decisions, test the complete data path. A value that looks correct in a desktop tool may still be wrong in the autopilot log or ground station display if scaling, sign convention, battery ID, or message source is incorrect.

1. Confirm message ownership. Decide whether BATTERY_STATUS is sent by the flight controller, companion computer, or battery component.
2. Check battery ID. Use a consistent id value for each pack in multi-battery systems.
3. Verify voltage scaling. Compare MAVLink voltage values against BMS software and a calibrated meter.
4. Verify current sign and unit. Confirm charge/discharge direction and centi-amp conversion.
5. Test SOC under load. Compare battery_remaining during takeoff-like current, hover-like current, and landing reserve.
6. Check temperature source. Define whether MAVLink temperature represents cell, MOS, or pack temperature.
7. Trigger safe fault tests. Verify warning and fault mapping without creating dangerous pack conditions.
8. Review logs. Check MAVLink logs for update rate, missing fields, jumps, dropouts, and duplicated battery instances.

Technical References

The official MAVLink Battery Protocol explains BATTERY_STATUS, BATTERY_INFO, battery component identity, multi-battery handling, and why SYS_STATUS should not be relied on for multi-battery systems. The official MAVLink BATTERY_STATUS message definition lists fields for temperature, cell voltages, current, consumed capacity, remaining percentage, charge state, mode, and fault bitmask. The MAV_BATTERY_FAULT enum defines fault flags used for smart battery health reporting.

For AYAA protocol support context, see FAQ Q11. For broader MAVLink and UAV battery communication route selection, use the related MAVLink battery telemetry article and the PX4/ArduPilot integration pages linked above.

FAQ

1. Which MAVLink message should a UAV BMS use for battery telemetry?

Use BATTERY_STATUS for frequent battery telemetry such as voltage, current, temperature, remaining percentage, charge state, and fault flags. Use BATTERY_INFO or a smart battery information message for slower-changing data such as SOH, cycle count, serial number, and design capacity.

2. Can a BMS send MAVLink directly?

Yes, but it must behave as a proper MAVLink component with correct system/component identity, heartbeat behavior, battery ID, message rate, and field mapping. Many systems instead let the flight controller or companion computer convert BMS data into MAVLink telemetry.

3. How should SOC be reported in MAVLink?

SOC is commonly reported through battery_remaining in BATTERY_STATUS. The value should be validated under real UAV loads because voltage sag and current spikes can make simple voltage-based SOC inaccurate.

4. How should SOH be reported?

SOH is not part of the basic high-rate BATTERY_STATUS fields. It can be reported through BATTERY_INFO.state_of_health where supported, or through maintenance software, vendor-specific messages, or static battery information paths.

5. What refresh rate should MAVLink battery data use?

MAVLink documentation describes BATTERY_STATUS as a regular battery update and notes a nominal rate around 0.5 Hz for each battery. In real projects, the best rate depends on autopilot settings, telemetry bandwidth, BMS sampling, and whether the data is for display, logging, or failsafe logic.

6. What fault flags should be mapped from the BMS?

Common mappings include over-current, over-temperature, under-temperature, deep discharge, voltage spikes, cell failure, incompatible voltage, and incompatible cell configuration. These correspond to MAV_BATTERY_FAULT bitmask values.

7. Why does the ground station show voltage but no fault data?

The system may be using a legacy or basic battery path, such as SYS_STATUS or analog voltage/current data, instead of full BATTERY_STATUS with fault_bitmask. Check the message source and field mapping.

8. What should procurement teams ask before requesting MAVLink battery integration?

Ask whether the BMS sends MAVLink directly or through the flight controller, which fields are mapped, what refresh rate is supported, how SOC/SOH are calculated, how fault flags are encoded, and whether PX4 or ArduPilot validation has been performed.