Signals, Networks, and the Control Path

FRC robots move information through several communication systems. Treating all of them as “the network” hides important differences.

A driver command, a motor-controller configuration message, a camera stream, and an encoder value may travel through different paths and at different rates.

Three questions for any signal

When you see data moving through the robot, ask:

Who produces it?
A controller, sensor, robot program, motor controller, camera, or field system.

Who consumes it?
A command, subsystem, dashboard, motor controller, driver, or log.

What happens if it disappears or arrives late?
Nothing, degraded behavior, loss of control, or an unsafe condition.

Those questions matter more than memorizing connector names.

CAN as a shared bus

Many FRC devices communicate over a Controller Area Network, usually shortened to CAN. Devices share the bus and are addressed/configured as individual nodes.

The key idea is shared communication.

roboRIO ── device A ── device B ── device C ── ...

This is not the same as every device having a dedicated data cable back to the controller.

A broken connection in a shared path can affect more than one device. Duplicate device identifiers can also create configuration problems because software needs an unambiguous way to address hardware.

Ethernet and the broader control network

The Driver Station communicates with the robot over the FRC control network. Ethernet is also commonly used for devices that need higher-bandwidth communication, such as some cameras or coprocessors.

Do not mix bandwidth with importance. A small CAN message that tells a motor controller what to do may be more important to immediate mechanism behavior than a much larger camera stream.

Completed reasoning example

Symptom:

The drivetrain works, but several devices on one mechanism appear offline.

Possible explanations include:

• the mechanism has lost electrical power;
• a shared CAN segment is open;
• a connector is poorly seated;
• the devices were assigned incorrect or conflicting IDs;
• software configuration does not match the physical device IDs.

What would narrow the search?

If every device after one physical CAN connector is missing, the topology becomes evidence. That pattern is stronger than “CAN is acting weird.”

If only one device is missing while later devices remain online, the hypothesis changes.

Draw the control path

Extend your architecture diagram with labeled signal types.

Use different arrow labels such as:

• driver input;
• robot network traffic;
• CAN command;
• sensor measurement;
• status/telemetry;
• video;
• configuration.

Then add a small failure domain around each shared dependency. A failure domain is the set of functions that could be affected by one fault.

Example:

CAN branch fault
    ├─ intake controller missing
    ├─ indexer controller missing
    └─ elevator controller missing

That is a more useful description than “three motors broke at once.”

Limitation to remember

A device appearing online does not prove the mechanism is healthy. Communication is one layer.

Likewise, a mechanism moving does not prove the architecture is correct. Intermittent connectors and overloaded systems can appear fine during a short test and fail under match conditions.

Architecture gives you where to look. Evidence still decides what is true.