AMR Battery Percentage Errors: Plan a Controlled Low-Energy Handoff

A changing percentage is not necessarily newly created energy

Battery state of charge is estimated, not directly observed as a quantity of remaining mission time. A reading can change as the estimator incorporates voltage response, current history and operating conditions. Analog Devices' ModelGauge discussion describes combining measurement approaches and notes that chemistry-specific models can matter. This is background for asking about the actual gauge; it is not evidence that any Jetray catalogue pack uses that algorithm or shares a published semiconductor accuracy result.

Distinguish a correction in the estimate from energy actually entering the battery. If a displayed percentage rises after rest, review measured current, estimator status and the operating history before declaring unexpected charging or a failed pack. Likewise, a stable display does not establish a trustworthy estimate. Ask the supplier which data and validity information the actual implementation provides, and evaluate that information against the robot mission rather than a generic display demonstration.

Build an error budget the software team can understand

A hypothetical current-measurement offset of 0.01A integrated over 24 hours corresponds to 0.24Ah. Against a hypothetical 24Ah reference, that is 1% of reference capacity. This arithmetic is not a forecast for a particular gauge. It isolates one possible accumulation mechanism while deliberately ignoring corrections, sleep behavior, calibration, gain error and interruptions. Those dependencies must be obtained for the actual measurement system.

The robot software team also needs to distinguish measurement uncertainty from an incorrect configuration. A wrong chemistry model, capacity baseline, sense-resistor setting or current sign is not simply ordinary estimation noise. Request the configuration and validation evidence that the supplier can appropriately disclose. Preserve the specific gauge and firmware identity in the interface baseline. Do not copy another product's reported error percentage into a robot specification without its operating conditions and applicability.

Separate task admission from the controlled handoff

The robot manufacturer should define what must happen before a new task is admitted and what must remain possible after a low-energy decision. Those requirements can include completing an approved stopping sequence, preserving required data or maintaining communications for a defined handoff. The appropriate behavior depends on the system risk assessment. This article does not set a universal battery percentage for stopping, authorize a motion restart or prescribe a safety-function architecture.

For a hypothetical budgeting example, a control load of 120W for 180 seconds requires 6Wh at that defined load boundary, before conversion losses and other allowances. It is not a recommended reserve. The real design must also consider available power, voltage limits and uncertainty, not only arithmetic energy. A pack may have remaining charge while being unable to support a demanded transient within approved limits. Record the separate power and energy requirements in the controller contract.

Validate transitions and missing information deliberately

Use engineering tests that distinguish a fresh estimate, a stale message, a missing message and a known restrictive battery state. The intended controller response should be specified before the test. Consider what the robot does when communications return after an interruption: a newly received percentage should not silently erase a latched service condition or authorize motion unless the released state machine says so.

TI's BQ76952 documentation illustrates that battery monitoring and protective behavior have their own states; a host display alone does not describe the complete power path. Analog Devices' LTC2952 illustrates supervised housekeeping before power-down as a separate design function. Neither example is a confirmed Jetray implementation. The practical engineering task is to identify which hardware and software functions the actual robot relies on, then obtain evidence for the transitions between them.

Keep investigation logs useful without treating them as proof

Record a synchronized time series of the relevant estimated values, raw measurements where available, task state, charger state and any validity flags. Mark sensor locations and units. If timestamps are not aligned, preserve that limitation rather than confidently ordering events that occurred closer together than the logs can resolve. A useful log supports a specific question, such as whether the controller admitted a task using stale data.

The robotics catalogue references support a supplier conversation, not a universal AMR control contract. Request the exact candidate's status interface, current limits and recovery conditions before writing host logic around assumed fields. Compare the approved configuration against the 18.5V reference and the 24V or 36V application evaluations only with explicit electrical and mechanical requirements. A similar nominal capacity or connector does not establish interchangeable gauge behavior.

Frequently asked questions