Robots Are Distributed Computers

A modern robot may contain several processors.

One device handles motor control. Another runs a camera pipeline. Another performs navigation. A laptop provides the operator interface. Sensors and motor controllers may have their own embedded processors.

The robot is therefore also a distributed computer system.

Draw the computing nodes

Example:

camera computer ─────┐
                     │ network
navigation computer ─┼──────── operator laptop
                     │
main controller ─────┘
      │
      ├── motor bus ── drive controllers
      └── sensor bus ─ IMU / encoders

Each connection has:

• data;
• timing;
• bandwidth;
• failure behavior.

Why split the work?

Different devices may exist because of:

• processing load;
• physical wiring;
• specialized hardware;
• reliability boundaries;
• vendor interfaces;
• real-time requirements.

More computers can improve architecture. They also create more interfaces to understand.

Local correctness is not system correctness

A camera process can correctly detect an object and publish the result.

The navigation process can still receive it too late.

Both components are "working." The system fails because the interface timing is wrong.

This is why distributed robotics requires thinking about communication, not just algorithms.

Architecture inventory

For a robot you know or invent, identify at least four computing/device nodes.

For each, record:

• responsibility;
• data produced;
• data consumed;
• communication link;
• consequence if the node disappears.

You are preparing for a deeper ROS 2 course later. Here, the target is the architecture underneath it.

Interfaces become part of the robot

Once responsibilities are split across processors, the connections between them become architectural components.

Suppose navigation publishes a velocity target to a motor-control computer.

The interface must define more than a topic or variable name:

value: linear and angular velocity
units: m/s and rad/s
rate: 50 Hz
maximum age: 100 ms
invalid behavior: command zero
ownership: navigation produces, drive control consumes

If the motor controller receives a perfectly formatted command that is 800 ms old, format validation alone will not protect the robot.

Distributed failure can be partial

A single-process program often appears either running or crashed. Distributed systems can fail in subtler ways:

• one node stops;
• network packets are delayed;
• messages arrive out of order;
• clocks disagree;
• one processor restarts;
• a sensor publisher continues sending stale values;
• bandwidth becomes saturated.

The robot may keep moving while part of its computing system is unhealthy.

That is why architecture diagrams should show communication paths and failure behavior, not only boxes with processor names.

For each device in your architecture inventory, add one heartbeat, timeout, freshness, or fallback mechanism that could reveal its failure.