Writing a robot narrative for FIRST Tech Challenge awards

A strong robot narrative gives FIRST Tech Challenge judges a clear account of how a team thinks, works and grows during the season. It is more than a list of mechanisms, programming languages or competition results. It connects the team’s goals, design choices, setbacks and community contribution into a story supported by specific evidence.

For Australian teams, this story may need to fit a busy school calendar, limited workshop access or a long journey between regional events. A team in Brisbane may have different resources from one in Hobart or Perth, yet judges can value both when the narrative explains how students used the opportunities available to them.

The best account sounds like students, not a marketing department. It should show curiosity, ownership and practical learning. Coaches can help with structure and editing, while students should supply the decisions, observations and reflections that make the submission credible.

Use the narrative alongside the engineering portfolio, interview preparation and outreach records. Each part should reinforce the others, giving judges a consistent picture of the robot, the people behind it and the way the team contributes to its school or wider community.

Award evidence	Useful material	Narrative emphasis
Robot design	Sketches, prototypes, test results	How a problem became a workable solution
Programming	Logs, match data, code changes	How testing improved reliability and strategy
Team development	Meeting records, role changes, reflections	How students gained responsibility
Outreach	Workshops, demonstrations, partnerships	How the team shared STEM learning
Season growth	Early mistakes and later results	What changed and why it mattered

Understand the story judges are seeking

Judges need to see a team that can explain its choices. A sentence such as “we built a fast intake” is incomplete until the team explains the game problem, the alternatives considered and the evidence that supported the final design. A short narrative can still contain technical depth when every detail serves a clear point.

Begin by identifying the central challenge of the season. Perhaps the robot struggled to collect game pieces consistently, the team had to design within a small parts budget, or new students needed to learn fabrication and Java quickly. That challenge becomes the thread linking design, programming and team development.

Avoid writing as though the robot succeeded without setbacks. A failed prototype, unreliable sensor or awkward driver-control layout can be valuable evidence. Explain what the team observed, what it changed and how the next test produced a better result. This shows engineering practice rather than presenting an unrealistic success story.

Shape a season-long narrative

A useful structure follows the team’s progress from intention to evidence. Start with the goals set during the first meetings, then describe the most important design decisions, testing milestones, competition lessons and later improvements. The sequence should be easy to follow even for a judge meeting the team for the first time.

Keep a shared season journal from the first build session. Record dates, photographs, test results, student reflections and decisions made at meetings. Teams working around Australian school terms can use a simple fortnightly entry so the task remains manageable during assessment periods, holidays and travel to events.

Community activity belongs in the same story when it connects to the team’s purpose. A scrimmage, school demonstration or beginner workshop can show how students practise communication and leadership. Teams can draw useful ideas from a successful FLL scrimmage, particularly the value of clear roles, welcoming event design and reflection after the activity.

Make engineering choices specific

Replace broad claims with measurable observations. Instead of saying that a lift became stronger, describe the load it handled, the failure that appeared during testing and the modification that solved it. Numbers do not need to be impressive; they need to be relevant and honestly recorded.

A design paragraph might explain that the first arm flexed during repeated cycles, causing inconsistent placement. Students then compared bracing options, adjusted the centre of mass and tested the revised arm over a set number of runs. The final decision was based on cycle consistency, repair time and driver confidence rather than appearance alone.

Photographs and diagrams should support the written account. Label the components that matter, show an early version beside the final mechanism and include a simple explanation of trade-offs. A compact robot may sacrifice maximum reach for easier manoeuvring, while a powerful lift may require extra weight and slower acceleration. Naming those trade-offs demonstrates thoughtful design.

Explain programming as problem solving

A programming section should reveal how software affected match performance. Describe the control strategy, sensor use, autonomous routines and driver feedback in language that a non-specialist judge can understand. Then include enough technical detail to show that students genuinely tested and maintained the code.

For example, the team might explain how encoder readings improved repeatable movement, why a distance sensor was filtered, or how a state machine prevented conflicting commands. Autonomous work should include the original objective, the failure observed on the field and the change made after reviewing logs or video. A helpful technical reference is this guide to programming autonomous routines, which can prompt teams to discuss sequencing, testing and reliability.

Do not claim that code is “fully autonomous” without explaining its limits. Judges will respond better to a precise account: the routine aligned reliably on a particular surface, required a known starting position and included a safe fallback when a sensor returned an unexpected value. Honest boundaries make the achievement more believable.

Show people, partnerships and impact

Awards recognise student learning, so make individual contributions visible. Explain how a novice moved from observing meetings to writing a subsystem, how a driver learned to use feedback, or how a build student became responsible for documentation. Use names sparingly, focusing on actions, decisions and growth rather than personal praise.

Teamwork should appear in practical details. Describe design reviews, code walkthroughs, shared build checklists or the way students resolved disagreement. A team does not need to claim perfect harmony. Showing respectful debate and a documented decision demonstrates maturity and gives judges a clearer picture of team culture.

Community impact should be specific and sustained. A one-off school assembly may introduce robotics, while a recurring lunchtime session can build a pathway for younger students. In a regional Australian setting, an online workshop with a school several hours away may be more realistic than frequent in-person visits. The important evidence is what participants did, what they learned and how the team measured follow-up.

A small project can still have meaningful reach. The reflection from a remote village book drive illustrates how logistics, local relationships and listening can shape community work. Apply that principle to robotics outreach: begin with a real need, work with local teachers or clubs and adapt the activity to the audience rather than delivering a generic presentation.

Edit for clarity and practise the interview

After drafting, remove repeated claims and technical detail that does not support the main story. Each paragraph should answer at least one useful question: What problem did the team face? What did students decide? What evidence guided the decision? What changed afterwards? If a sentence answers none of these, shorten it or remove it.

Use active language. “The team tested three intake rollers and selected the middle diameter after comparing jams” is stronger than “three options were considered.” Credit students directly for their work, while acknowledging mentors and sponsors accurately. If a local engineering business, university group or Bunnings community connection supplied materials or advice, explain the contribution without implying that adults completed the work.

Read the narrative aloud as a team. Students should be able to explain any diagram, metric or design decision without memorising a script. Practise answering follow-up questions about failure, iteration, sustainability and outreach. Teams in Sydney, Melbourne or regional Queensland can also rehearse online when travel makes extra meetings difficult, keeping the same evidence and speaking roles.

A final review should check consistency across the submission. Robot dimensions, competition results, programming claims and outreach numbers must match the portfolio and team records. Keep a version history so students can see how their thinking developed, and preserve photos, test sheets and reflections as evidence for future seasons.

Give judges a story they can remember: a real problem, a thoughtful response, student ownership and evidence of learning. Gather the team’s notes, select the strongest examples and shape them into a concise account before the next judging session. A well-prepared narrative can make technical work understandable while showing the confidence, creativity and collaboration that robotics education is meant to develop.