Telemetry as Instrumentation

Use telemetry as a structured debugging interface instead of random printouts.

Module 2: FTC SDK FoundationsCore

In this lesson, you will:

01Choose telemetry that answers a question.
02Label values clearly.
03Remove event-noise before competition.

Concept narrative

Telemetry is the robot's voice. It should not be a junk drawer of every variable; it should be instrumentation that answers the question the team is currently testing.

This lesson should be read as a robotics lesson first and a programming lesson second. The code matters because it lets the team create repeatable behavior under match pressure. Students should slow down long enough to name the inputs, outputs, assumptions, and safety limits before they touch the robot.

Robot mental model

For any behavior, telemetry should reveal the path from driver input to robot output. A drive bug needs axes and powers. A lift bug needs state, target, position, and output. A vision bug needs raw scores and selected result.

A good mental model gives the team a shared language. When a driver, builder, and programmer can point to the same behavior and use the same words, debugging gets calmer and code review becomes useful instead of personal.

Implementation walkthrough

Write telemetry in groups. Use prefixes such as drive/, arm/, vision/, or auto/. During practice, print more detail. Before competition, keep the values the drive team can actually use.

Keep the implementation staged. First create the smallest version that compiles. Then add telemetry that proves it is running. Then connect one hardware device or one decision. Finally, repeat the test from a cold init so the team knows it was not a lucky hot reload.

StructuredTelemetry.javaJava

telemetry.addData("arm/input/a", gamepad2.a);
telemetry.addData("arm/state", armState);
telemetry.addData("arm/target ticks", targetTicks);
telemetry.addData("arm/position ticks", armMotor.getCurrentPosition());
telemetry.addData("arm/output", lastOutput);
telemetry.update();

Common mistakes and debugging

Telemetry can lie by omission. If only the output is printed, the team cannot tell whether the input, state, or target was wrong. If too many values are printed, nobody reads them under pressure.

Use the five-value debugging habit: input, state, target, measurement, output. If one of those values is missing, add it before rewriting logic. The goal is to make the robot tell the truth about what it thinks is happening.

Checkpoint

Telemetry labels identify subsystem and units.
Values answer a debugging question.
Driver-facing telemetry is not overloaded.

Reflection check

Check your understanding before moving on.

What makes telemetry useful?

0 of 1 answered

References

FIRST FTC DocsOfficial SDK, Robot Controller, and programming reference.Learn Java for FTCFTC-focused Java book and exercises by Alan G. Smith.Game Manual 0FTC community reference for programming, controls, and robot design.