Power, Compute, Communication, and Motion

Robot architecture is the shape of responsibility inside the machine.

If every wire and class is drawn on one page, the diagram becomes useless. A better architecture starts with layers and asks what each layer is responsible for.

A four-layer model

For an FRC robot, begin with four broad layers:

1. Power supplies electrical energy.
2. Compute and control runs robot logic.
3. Communication carries commands, configuration, and telemetry.
4. Physical systems turn controlled energy into motion.

These layers overlap at devices such as motor controllers. A motor controller is electrically powered, receives control information, may publish telemetry, and regulates motor output.

That overlap is normal. The purpose of architecture is not to force every component into one box. It is to make dependencies understandable.

Walk the architecture

Imagine a driver requests 40% forward output.

Driver controller
      ↓ input
Driver Station computer
      ↓ network
robot controller / roboRIO
      ↓ control command
motor controller
      ↓ regulated electrical output
motor
      ↓ torque
gearbox + wheel
      ↓
robot motion

Power follows a different route.

battery
  ↓
main breaker
  ↓
power distribution
  ↓
branch protection
  ↓
motor controller
  ↓
motor

One action uses at least two architectures at once: the information path and the energy path.

Why separate the paths?

Suppose software reports that a motor controller is online, but the motor will not turn.

Communication may be healthy while the high-current power path is not.

Now reverse it: the controller may have power but disappear from the control network because a communication connection is broken.

Same visible symptom, different layer.

Architecture worksheet

Choose one mechanism and produce a layered diagram with these rows:

Do not write “works” as evidence. Use something observable: voltage, device status, log entry, sensor reading, command state, wheel motion, measured distance, or another specific result.

A useful architecture rule

Every important action should have a place to observe it.

If you cannot tell whether a command was received, whether a controller is online, or whether a mechanism reached its target, debugging becomes guesswork.

That does not mean adding a sensor to everything. It means designing enough observability into the system that failures can be isolated.

Failure mode: one giant diagram

Architecture diagrams fail when they attempt to show every detail at the same level.

A good diagram can be expanded.

Start with the four layers. Then zoom into the subsystem that needs detail. Your Unit 2 final diagram will use this approach so another person can understand the machine without reading every source file or tracing every wire by hand.