Echo 1 — Architecture overview

Echo 1 boots from a single entry point that loads configuration, then a supervisor spawns one isolated subprocess per service and runs a ZeroMQ event-bus broker. Services never share memory — they communicate only over the bus.

Services & ownership

Each hardware resource has exactly one owner, so two processes can never fight over a serial port or the camera:

• safety_service — owns the camera + LiDAR; capture → YOLO → hazard evaluator → alerts.
• audio_service — owns the speaker; priority arbitration and a record-time duck.
• assistant_service — owns the mic + push-to-talk button; STT → intent → tool → reply.
• navigation_service — owns the GPS; route state machine and clock-direction cues.
• vision_service — owns nothing; requests frames from safety over the bus.
• dashboard_service — read-only observer; subscribes one-way to the bus.

Audio priority

All speech flows through the Audio Manager as a prioritized request. Safety (100) outranks Navigation (50) outranks Assistant (10); a higher priority preempts a lower one.

Two-layer resilience

The supervisor restarts an individual service if it crashes. If a critical service (safety or audio) gives up entirely, the process exits non-zero and systemd performs a clean full-stack restart. Assistant, navigation or vision crashes never affect safety.