From Your Hands to the Wheels

Motivation

As an FRC coach and mentor, I wanted one page that new students could read to see how the whole system connects, from the driver’s hands to the wheels and back again. Most of what goes wrong on a field is one of these links rather than your code, so it is worth being able to name them in order.

The guide is in four parts: getting your bearings, the robot as a machine, the link between the robot and your laptop, and working with all of it through a season. In the diagrams, solid dark lines are control (commands going out) and dashed teal lines are telemetry (data coming back). It is a companion to my guides on SystemCore and Commands V3.

What happens when you push the stick

Push forward on a gamepad at a competition and the signal crosses seven handoffs before a wheel moves. Click any box in the figure below to see what that link does, who controls it, and what it looks like when it breaks.

Behind the glass

The field owns this

On the robot

The driver

Link into it: —
Who controls it: your team
When it breaks: Practice time is the only fix.

Fig 1. The control path at a competition. Boxes with a dashed top edge also carry telemetry back. At home the middle zone disappears entirely, and that is the single biggest difference between a robot that works in the shop and one that works on a field.

Which machine is running what?

Your robot program does not run on your laptop. That one sentence clears up most early confusion: the laptop writes the code and watches the results, but the robot executes it. The exception is simulation, which runs everything on the laptop and needs no robot at all.

On your laptop

VS CodeWhere you write and build code. Also where the blocks editor lives, if you use blocks.

Driver station appEnables and disables the robot, picks the op mode, and shows battery, ping and alerts.

DashboardsElastic for the drivers during a match; AdvantageScope for digging through data afterwards.

SimulationRuns your actual robot program on the laptop, with no hardware. This is how you learn the 2027 changes before a SystemCore exists.

On the robot

Your robot programDeployed over the network, stored on the controller, and started when the robot powers on.

The command schedulerRuns every command you scheduled, roughly every 20 ms, and enforces which mechanism belongs to whom.

Vision pipelinesAprilTag processing on the controller itself, or on a separate co-processor if you use one.

Log filesWritten to a USB drive plugged into the controller, and collected after the match.

Web editors and dashboardsNew in 2027: the controller can serve VS Code, the blocks editor and web AdvantageScope to a browser, so a Chromebook is enough.

Fig 2. The split matters most when something is broken. A laptop problem and a robot problem look identical from the driver station, and knowing which side a tool lives on tells you where to look.

Of everything on that list, the last item is the one that surprised me most.

Where everyone actually stands

It is worth seeing the field once from above, because the arrangement explains several rules that otherwise sound arbitrary: why you cannot touch your robot, why your laptop is wired rather than wireless, and why the only thing crossing the field boundary is radio.

Fig 3. Six teams and six laptops, all wired to the same field management system, with one shared wireless link out to every robot. Your robot is the only part of your setup on the far side of that wireless hop, which is why a problem out there cannot be fixed by anything you do at the keyboard.

Everything hangs off one battery

Now for the robot as a machine: power in, sensors back, and what it does without anyone talking to it.

A robot has one battery, and every part of the chain that lives on the robot draws from it. That includes the controller, the radio, and the motors, which can pull hundreds of amps between them. Software people can ignore this right up until the moment they cannot, because the failure it produces looks exactly like a software bug.

When several motors pull hard at once, the battery voltage sags. If it sags far enough the controller resets: your code restarts mid-match, comms drop for a moment, and the robot goes limp and then comes back. That is a brownout, and no amount of reading your command code will explain it. The evidence is in the voltage trace in your log.

Fig 4. FRC robots use a power distribution board fed by the main breaker. In FTC the MotionCore hub does this job, taking the battery in and handing power out alongside CAN on the same connectors. Either way, log your battery voltage from day one, because it explains failures nothing else will.

Nothing moves open-loop for long

The chain above runs one way, but a robot is a circle. You command a motor, the mechanism moves, a sensor measures what actually happened, and your code uses that number to decide what to command next. That circle closes roughly every 20 milliseconds, and it is the reason a command can say “drive two meters” instead of “run the motor for 1.4 seconds and hope.”

It is also why logging is not an optional extra. The values coming back are the same values your code is steering by, so when the robot misbehaves you are reading the inputs to a decision as well as a status display.

Fig 5. The same sensor reading does two jobs: it steers the next command, and it is what you read afterwards to understand the match. Solid lines are commands going out; dashed lines are measurements coming back.

What the robot and your laptop say to each other

Everything else on this page depends on one fact: your laptop and your robot are two computers on a network. Nothing is plugged into the robot in the sense of a cable carrying joystick movement. They find each other by network address (the controller’s own screen shows you its address), and then they exchange small packets, many times a second, for as long as the robot is on.

There are four separate conversations happening over that one connection, and it helps to keep them apart, because they fail independently.

Fig 6. One network connection, four independent conversations. A dashboard that stops updating means channel three broke; a robot that stops moving means channel one did. They are different failures, with different fixes.

Enable is a bit in a packet

This is the part that explains the most. Enable is not a switch on the robot. It is a bit inside that first packet, arriving fifty times a second. So the robot is not waiting to be told to stop; it is running because something keeps telling it to keep going. If those packets stop arriving, because the radio drops, the laptop sleeps or a cable is pulled, the controller disables the motors on its own within a fraction of a second. That is why “we lost comms” and “the robot went limp” are the same sentence, and it is deliberate: a robot that has lost contact with its drivers should not keep driving.

At a competition the shape stays the same, with one change of authority: the enable bit is no longer yours. Your joystick values still travel to your robot the same way, but FMS decides whether that enable bit is set, and your driver station follows the field’s instructions about which mode to run.

NetworkTables is a shared whiteboard

This name turns up everywhere, so it is worth pinning down. NetworkTables is a set of named values that lives on the robot and stays in sync with every program watching it. Your code writes arm/angle = 42.7, and a dashboard on your laptop sees 42.7 a few milliseconds later. Nobody asked for it and nobody sent a request; the value simply changed in a place both sides can see.

The name is literal, and slightly unfortunate. The tables are two-column tables of data, with a name on the left and a value on the right, and network only describes how those values travel between machines. Names are written like file paths, so arm/angle and arm/setpoint sit together in an arm table. Those are the “subtables” you see mentioned elsewhere.

If the name makes you think of network configuration, such as routing tables or firewall rules, set that aside. NetworkTables configures nothing and filters nothing. It carries your robot’s numbers, and that is all it does.

Fig 7. The robot holds the table and every tool is a client watching it. Several can watch at once, and each sees the same values change in real time.

Three consequences are worth carrying around:

It is not a recording. Each value is overwritten by the next one, so if you look away the moment is gone. That is exactly why DataLog writes a file alongside it. NetworkTables is the “watch it now” half, and the log is the “read it later” half.
Everything you publish crosses the radio. On a field that link is shared with five other robots, so publishing a hundred values because you might want them is not free. Log generously to the file, and stream sparingly over the network.
It runs both ways. Mostly the robot writes and dashboards read, but a dashboard can write too. That is how a tuning value gets changed while the robot sits on blocks, without a rebuild and redeploy.

So when you meet NetworkTables in the telemetry API, in a dashboard’s setup screen, or in a list of what a tool connects to, it is always this same whiteboard being read or written from a different seat.

The shop network and the field network

The same robot and the same laptop end up in two completely different arrangements. Nearly every “it worked in the shop” story lives in the gap between these two.

In the shop

LaptopUSB-C, ethernet, or the robot’s own Wi-Fi SystemCoreCAN and smart IO Motors and sensors

You are in charge. You deploy new code whenever you like, you enable and disable the robot yourself from the driver station app, and you can leave a laptop tethered while it runs on blocks.

At a competition

Laptopfield ethernet at the player station FMSthe event’s own wireless network Robot radio → SystemCoreCAN and smart IO Motors and sensors

The field is in charge. FMS decides when your robot is enabled, which mode it is in, and when the match ends. You cannot enable your own robot on the field, and you do not deploy code out there; code changes happen in the pit.

Fig 8. FTC differs here: matches run without an FMS, so the driver station’s own match mode steps through autonomous and driver control on a timer. The rest of the chain is the same.

Write, deploy, enable, look at the data

The last part is about working with all of this: the cycle you repeat all season, what match day looks like, and what to check when it breaks. The cycle itself has six steps.

WriteEdit code on the laptop in VS Code, or in the browser served from the robot.
BuildCompiles on your machine. The compiler plugin catches missing yields and unnamed commands here.
DeploySends the program over USB-C, ethernet or Wi-Fi to the controller, where it restarts.
EnableFrom the driver station: pick an op mode, choose teleop or autonomous, and enable.
WatchLive values stream back over NetworkTables to your dashboard while it runs.
AnalyzePull the log afterwards and scrub through it in AdvantageScope. Then back to step one.

Fig 9. Steps one to four push outward; five and six come back. Getting the return half working early, by logging real values from day one, is what makes the rest of the season debuggable.

Who is in control, minute by minute

The handover of control is the part nobody explains to a rookie programmer. You own the robot completely right up until it is on the field, and then you own almost none of it until the match ends.

Stage	You do	Field does
In the pit	Deploy code, run utility op modes, check systems, charge a battery.	—
Queue	Pick your autonomous op mode. Last chance for changes.	—
On the field	Plug into the player station, confirm comms and code are green.	FMS takes over your driver station and locks the mode.
Autonomous	Nothing. Hands off the sticks.	Enables every robot at once, runs the autonomous timer.
Driver control	Drive. Watch the dashboard, not the laptop.	Switches to teleop and starts the clock.
After	Collect the robot, pull the log, find out what actually happened.	Disables everything and releases the field.

Fig 10. Period lengths are set by each year’s game manual and are not assumed here. The important part is the shape: your control ends at the field edge, and the only thing you carry away is the log.

Map the symptom to the link

The value of knowing the chain is that most failures announce which link they are. These are the common ones, and where they sit on the chain in Fig 1.

What you see	Which link	Where to look
No communication at all	radio ↔ field	The wireless link or the robot radio, not your code. Check radio power and lights before touching anything software.
Comms good, no code	SystemCore	The program crashed or was never deployed. The controller’s own screen and the driver station console tell you which.
Robot enabled, one mechanism dead	CAN or power	A device missing from the CAN bus, a blown fuse, or a loose connector. The rest of the robot working is the clue.
Everything works, wrong behavior	your code	Now it is yours. Pull the log and read which commands actually ran and when; this is what the scheduler telemetry is for.
Works tethered, fails on the field	the field network	Bandwidth, latency, or something that only exists on your bench. Stream less over the network and log more to the file.
Fine in autonomous, dead in teleop	op mode / bindings	The teleop op mode you selected, or its bindings. Different mode, different class, different defaults.

Two safety habits

Anyone can call for a robot to be disabled, and on a field the emergency stop is always available at the player station, so know where it is before you need it. In the shop, put the robot on blocks before enabling it, and say “enabling” out loud so nobody has a hand in a mechanism when it moves.

The vocabulary, in one place

Term	Lives	What it actually is
Driver station	laptop	The application that enables the robot and shows its status. Also the physical spot behind the glass where drivers stand.
FMS	the event	Field Management System. Runs the match, controls every robot’s enable state, and reports what happened.
SystemCore	robot	The controller running your program, required in FRC from 2027 and arriving in FTC a season later.
Op mode	your code	A selectable program (one autonomous routine, one teleop layout, one test routine) chosen from the driver station.
Command	your code	One piece of robot behavior the scheduler runs, owning the mechanisms it needs while it runs.
NetworkTables	the link	The live data channel between robot and dashboards. Bandwidth-limited on a field.
DataLog	robot	The recorded log file, written on the robot, read afterwards in AdvantageScope.
CAN bus	robot	The daisy-chained wiring that carries commands to motor controllers and readings back from devices.

Notes

This describes the 2027 control system as presented by the WPILib team during the alpha period, combined with standard FRC event practice. Details of the new hardware may change before kickoff, and anything game-specific, such as period lengths and field dimensions, comes from each season’s manual rather than from here. The diagrams are schematic.

Companion guides: SystemCore and the 2027 transition, Commands V3 and coroutines, and Fifteen seconds (autonomous and Choreo for beginners).