Maryland FIRST Robotics logo mark on transparent background Maryland FIRST Robotics

Data logging for stronger FTC robots

Using data logging to improve robot performance in FTC starts with turning scattered symptoms into a measurable performance history. A lane drifts by a few centimetres, an arm reaches late, or a mecanum chassis loses alignment after contact, making the match difficult to explain. The resulting record gives teams a faster route from guesswork to targeted changes.

Teams running FIRST Tech Challenge (FTC) can find program-specific guidance through Maryland FIRST Tech Challenge. A useful log answers three questions: what did the robot intend to do, what did its sensors report, and where did the response diverge? These records make tuning more disciplined and give every driver, coder and mentor a shared account of the robot.

Australian teams should account for local conditions from the outset. A chassis may travel to Melbourne, Brisbane or Adelaide for an event, while regional teams face long freight journeys and extra setup time. Budgets are in Australian dollars, sponsors often need GST details, and overseas purchases can add customs paperwork, import charges and exchange-rate risk. Simple, repeatable tests produce evidence a small team can review quickly.

Choose signals that explain behaviour

Start with the decision you want to improve. If the concern is path accuracy, log target pose, wheel encoder counts, gyro heading and estimated position. For an arm or intake, add motor position, commanded output, measured current and relevant limit-switch states. More channels are not automatically better; select a compact set that distinguishes a control problem from a mechanical or power problem.

Record all channels on a common timeline and use a stable sample rate, commonly 20–100 Hz for motion analysis. Timestamp files with the run identifier, robot configuration and battery state. Name fields consistently so a spreadsheet or analysis script can compare a baseline with a later change. During competition, keep the same core channels enabled so match logs remain comparable with practice evidence.

Signal Main insight What to check
Encoder position Wheel rotation and distance Reset errors, slip and saturation
Gyro or IMU Heading and rotation Drift, vibration and interference
Motor current Torque demand Jams, payload and bearing drag
Pose estimate Position on the field Odometry error and wheel slip
Battery voltage Available power Load-related sag and loose connections

The channels should form a causal chain. A pose error becomes useful when the log shows whether encoders moved as commanded, the gyro rotated as expected and motors had enough voltage. This sequence helps the team choose between control gains, a sensor adjustment or a drivetrain inspection.

Build a dependable logging workflow

The FTC software development kit can capture selected robot values, while supported driver-station and Control Hub workflows can export them. Decide what the team will examine before adding code: excessive logging can slow a control loop or fill storage when many channels are sampled at a high rate.

Store each run as CSV, JSON or another format the team can open with familiar tools. A clear filename such as run-17_auto_v3.csv prevents evidence from being separated from its context. Include a small text note with the date, event or venue, field number, robot build and any load carried. Photographs of the robot configuration can resolve disputes that numbers alone cannot.

Check that timestamps remain monotonic and values from different sensors refer to the same control cycle. Synchronise recording with the start of an autonomous routine or driver command, then mark completed goals. These markers isolate a bad interval rather than requiring the team to inspect an entire match.

Tune motion from recorded errors

For a PID-controlled drive or lift, log the setpoint, measured position, error, controller output and saturation state on every update. If the motor command remains at its limit while the error persists, more gain may not help. The log can reveal slow response, overshoot, steady-state offset or a noisy feedback signal, each of which calls for a different correction.

Add feedforward only after the feedback loop is stable. Compare the output required to hold a known load with the output required at rest; the difference suggests gravity, friction or resistance that can be modelled directly. Test on the actual robot because drivetrain flex, floor variation and Australian event surfaces can change the result. Save the baseline trace before each adjustment.

Odometry and pose estimation deserve attention on a mecanum chassis. Compare commanded wheel speeds with measured speeds, then compare integrated position with a surveyed marker or tape measure. A consistent corner error often points to alignment or wheel slip, while a random error suggests sensor noise. Correct the physical cause before adding complexity to the estimator.

Diagnose mechanisms and power faults

Current traces often reveal problems that sound alike but require different repairs. A sharp rise during an intake cycle may mean a jammed game piece, while steadily high current at rest can indicate bearing drag, cable tension or an over-tightened mechanism. Pair motor current with position and limit-switch events to distinguish a collision from a control fault.

Voltage logs expose another layer. A battery that looks healthy at rest can sag when several mechanisms start together, delaying resets or reducing available torque. Compare voltage with motor output, then check connectors, wiring and battery age. In warm Australian conditions, record ambient temperature and let batteries cool between repeated runs, since heat changes battery performance and inspection time.

A repeatable test and debrief routine

Use a short baseline sequence before changing code or geometry. Warm the robot, place it in a marked test area, and record the starting battery level, floor surface and ambient conditions.

Before each run:

After the run, compare like with like before discussing solutions. A chart with the commanded and measured values side by side is usually more useful than a single number such as final position error.

During the debrief:

Keep each cycle small: change one variable, rerun the same sequence and archive the result. Over a season, this record shows which modifications improved repeatability and which merely moved the problem. The evidence can settle disagreements between a driver’s observation and a programmer’s theory.

Share evidence with the wider team

A concise performance summary is often more useful to mentors and sponsors than a folder of raw files. Select two or three charts showing a clear goal, the measured baseline and the result of an improvement. Explain the engineering challenge plainly and connect it to the team’s learning rather than listing features.

Teams building a budget case can adapt the sponsorship proposal template, replacing its context with Australian suppliers, local grants and sponsorship tiers expressed in Australian dollars. When approaching a company, show how reliable data supports claims such as reduced cycle time, improved build consistency or better energy use. The request becomes credible when the proposed budget supports a measurable engineering goal.

Local sponsorship can come from manufacturers, engineering consultancies, universities, hardware stores and community groups, but the offer should suit the supporter’s interests. A regional Australian team may find that shipping, travel and spare-parts costs matter more to a local business than a prominent logo. Offer workshops, technical demonstrations or mentoring where appropriate, and record commitments for the next meeting.

Create a cycle that improves each season

Community relationships can support outreach and specialist advice. Before approaching an organisation such as the Avalokitesvara Trust, check whether its current priorities match the team’s project and offer a specific, modest role. A partnership works best when both sides know what will be delivered, who owns the equipment and how students benefit.

Archive logs alongside code versions, mechanical drawings and test notes. A new student should reproduce a benchmark, change one parameter and explain the outcome using evidence. Share selected findings at a workshop or school event, while keeping match data and personal information secure. Logging then becomes an organisational habit that survives changes in team members.

Choose one measurable objective for the next practice session, define the signals needed to evaluate it, and run a matched baseline and test before making further changes. Start with the routine now, keep each record labelled, and review the first results at the next team meeting.