Telemetry in the Arena: Turning Robot Logs into Better Pit Decisions

After a fight, a team needs to know why a machine stopped behaving as expected. A burnt component is evidence, but it may not identify the first fault in the chain.

Onboard logging can provide the missing timeline. A voltage drop, controller fault or rising temperature recorded before a loss of movement can help a pit crew decide where to investigate.

That connects directly with the repeat-fight maintenance problem in our BattleBots Pro League strategy guide. Better data can shorten diagnosis, but only if it is reliable and interpreted in context.

Begin with a question

Useful telemetry is designed around decisions. If the question is whether a drive controller is overheating, record the relevant temperature, commanded drive activity and fault flags. If the concern is a power interruption, record voltage and the state of the system around the interruption.

Collecting every available signal can consume storage and processing time without improving diagnosis. A small, well-understood set of measurements is often more useful than a dashboard full of poorly documented numbers.

CAN is not a wireless link

A Controller Area Network can let onboard devices exchange messages. It does not, by itself, send data through the arena or into a cloud service.

A logger can record bus messages locally. Sending them elsewhere requires a separate communications path, with its own radio, reliability and regulatory considerations. These layers should not be conflated.

Local recording also preserves evidence when a wireless link is unavailable. In a metal enclosure surrounded by electrical noise and moving equipment, uninterrupted streaming should never be assumed.

Timestamp quality determines diagnostic value

A fault investigation needs to establish what happened first. Signals collected by different devices may use different clocks or update intervals. Without alignment, a dashboard can suggest a causal sequence that never occurred.

Record the sampling interval, timestamp convention and any gaps. A dropped data segment should appear as missing information, not as a misleading flat line.

Sensors also need appropriate ranges. An accelerometer that saturates during an impact cannot measure the full impact accurately. A temperature sensor mounted away from a winding does not directly report the winding's temperature.

A sensible component checklist

• Acquisition: supported controller messages or appropriately rated sensors.
• Logging: local storage with a documented data format.
• Timing: a clear clock and synchronisation method.
• Protection: mounting and wiring that remain safe under vibration and impact.
• Analysis: plots tied to configuration, match and inspection records.
• Communications: an organiser-approved radio arrangement, if wireless telemetry is permitted.

This is a functional checklist rather than a claim that every team uses a specific microcontroller, cloud provider or sampling rate.

Cloud analysis can help after collection

Offboard analysis can compare repeated runs or identify unusual patterns. But an anomaly flag is a prompt to investigate, not proof that a part is damaged.

A sponsorship announcement also does not establish that a league's robots stream live diagnostic data through that sponsor's infrastructure. Such a deployment requires its own evidence.

The practical priority is dependable collection and a repeatable inspection process. Cloud tools become useful after those foundations exist.

Reporting basis

This is a general systems-design explainer, not a report of a verified league-wide telemetry deployment. Teams should check the BattleBots rules and design documents and obtain approval for any communications arrangement. No live radio channel should compromise control or safety.

Cover photograph: Team Witch Doctor with its robot, BattleBots Pro League 2026; illustrative team photograph, not a live telemetry installation.