Robot architecture and responsibility
Partition sensing, estimation, decision, actuation, power, and safety so a desk robot’s behavior and failure boundaries stay inspectable.
- Draw a robot’s energy and information paths, assign responsibilities to components, and justify one interface boundary from rate and failure behavior.
Related study — optional context
Understand
The working idea
A robot is not defined by having a motor or a computer. It closes a loop between sensing the world, estimating what that evidence means, choosing an action, and applying energy through an actuator. A toy car that measures wheel motion, decides how to steer, and drives motors has this loop. Power distribution and safety supervision run alongside it; they are not afterthoughts.
Architecture assigns responsibilities and interfaces. A useful decomposition is sensing → estimation → planning/control → actuation, with logging and supervision observing each boundary. The arrows carry named data at named rates: wheel_ticks at 100 Hz, pose estimates at 20 Hz, velocity commands at 20 Hz, and motor PWM at 1 kHz. Energy follows a different path from battery through protection and drivers to motors. Mixing those diagrams can hide the fact that a tiny logic signal commands a much larger power flow.
Interface rates and failure semantics shape the build. If a high-level computer sends velocity commands to a microcontroller, a watchdog can require a fresh command every 100 ms; expiry commands zero output locally even if the high-level process freezes. That boundary keeps the fast motor loop and immediate stop behavior close to hardware, while mapping or screen UI can run elsewhere. A single processor may implement every block, but the conceptual contracts still matter.
A common misconception is that a layered diagram proves the system is modular. If two blocks share undocumented global state, units, or timing assumptions, the boundary is only decorative. Another failure is placing “safety” in one box while every other block can bypass it. Trace one command from user intent to motor voltage and one fault back to a safe response. Architecture is a set of testable responsibilities: who owns time, coordinate frames, limits, stale data, and recovery.
Follow the reasoning
Worked example
A controller expects a 20 Hz velocity command and must stop within 150 ms after communication fails. Choose a watchdog timeout and estimate missed commands before stopping.
- 1
Command period = 1/20 Hz = 50 ms.
- 2
A 100 ms timeout tolerates the missing arrival at 50 ms and expires around the second expected arrival at 100 ms.
- 3
Allow 10 ms for local detection/output update, giving about 110 ms command-to-zero latency, below the 150 ms requirement before mechanical coast is considered.
Use a 100 ms freshness timeout with local zero-output handling; test physical stopping separately because the watchdog bounds command removal, not coast distance.
Sanity checkA 150 ms timeout alone would consume the whole requirement before detection and actuation, so it cannot meet the stated bound with any overhead.
Try it yourself
Independent check
Move to the bench
Create and exercise an architecture contract for a low-voltage desk robot mock-up.
- Microcontroller
- two LEDs with resistors or a safely driven small motor
- button
- serial console
- paper or diagram tool
Experiment
- Draw separate energy and information paths for command input, supervisor, controller, output, and feedback.
- Define message names, units, nominal rates, owner, stale threshold, and safe value at each software boundary.
- Implement serial velocity commands as an LED duty request plus a 100 ms watchdog that forces zero.
- Introduce a deliberate fault by stopping command transmission; record the last receive and zero-output timestamps.
- Repeat with malformed but checksummed-out commands and confirm they are rejected without refreshing freshness.
Observe
- Expected: continuous valid commands maintain output; silence causes local output to become zero near the watchdog threshold.
- Record actual timeout and update latency separately from the 100 ms configured value.
- Expected fault signature: communication stops upstream while the supervisor and output path continue long enough to enforce the safe state.
Partition a camera-guided toy car into blocks and justify whether image processing, steering control, and motor cutoff belong on one processor or across a documented interface.
- Prove watchdog behavior with LEDs or wheels raised and restrained before any floor test; keep all work at protected low voltage.
Keep evidence
Bench note
Record what you expected, what you actually measured or observed, and one difference worth investigating. This is self-reported evidence, not a certification.