Every robot command crosses six or seven pieces of hardware before a motor turns. Here is the whole path, what owns each link, and what you actually do with it on a build night and on a match day.
Companion to the SystemCore guide and the Commands V3 guide.
The pieces, what each one is for, and where they physically sit.
Push forward on a gamepad at a competition and the signal crosses seven handoffs before a wheel moves. Most of what goes wrong on a field is one of these links, not your code — so it is worth being able to name them in order. Click any box.
Everything starts as a human decision. Worth stating plainly because it is the part teams tune last: a robot that is technically faster but harder to aim loses to one the driver can place confidently.
Fig. 1The control path at a competition. At home the middle zone disappears entirely — which is the single biggest difference between a robot that works in the shop and one that works on a field.
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.
Fig. 2The 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.
Worth seeing 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. 3Six teams, six laptops, all wired to the same field management system; 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.
Power in, sensors back: what the robot 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 — the controller, the radio, and the motors that 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. Sag far enough and 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. 4FRC 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.
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 — when the robot misbehaves, you are reading the inputs to a decision, not just a status display.
Fig. 5The 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.
Two computers, one network connection, and four conversations across it.
Start here, because everything else on this page depends on it: 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. 6One 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 not the same failure and they do not have the same fix.
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, and if those packets stop arriving — radio drops, laptop sleeps, cable pulled — the controller disables the motors on its own within a fraction of a second. This is why “we lost comms” and “the robot went limp” are the same sentence, and it is deliberate: a robot that 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.
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; 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 — a name on the left, 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 — the “subtables” you see mentioned elsewhere.
If the name makes you think of network configuration — routing tables, firewall rules, anything in that family — set that aside. NetworkTables configures nothing and filters nothing. It carries your robot’s numbers, and that is all it does.
Fig. 7The robot holds the table; every tool is a client watching it. Several can watch at once, and each sees the same values change in real time.
Three consequences worth carrying around:
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 same robot, the same laptop, and two completely different arrangements. Nearly every "it worked in the shop" story lives in the gap between these two diagrams.
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.
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. 8FTC 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.
The cycle you repeat all season, what match day looks like, and what to check when it breaks.
Fig. 9Steps one to four push outward; five and six come back. Getting the return half working early — logging real values from day one — is what makes the rest of the season debuggable.
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.
Fig. 10Period 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.
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. |
Anyone can call for a robot to be disabled, and on a field the emergency stop is always available at the player station — 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.
| 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. |