Skip to main content

AI Assistant

Physical AI & Humanoid Robotics

Hello! I'm your AI assistant for the AI-Native Guide to Physical AI & Humanoid Robotics. How can I help you today?

04:57 AM

Topic 2 — System Architecture & Design Blueprint

With a clear project brief in hand, the next step is to design an architecture that connects all major subsystems—from perception and planning to control, simulation, and user interfaces. This topic guides you through creating diagrams, defining ROS 2 node graphs, and specifying interfaces so that implementation becomes a matter of filling in well-understood components.

2.1 From Brief to Block Diagram​

Begin with a high-level block diagram that shows:

  • Inputs:
    • Sensors (camera, LiDAR, IMU, microphones).
    • Human inputs (CLI, GUI, natural language, scripts).
  • Core processing layers:
    • Perception (Chapter 4).
    • Localization, mapping, and world modeling (Chapters 3–4).
    • Planning and decision-making (Chapter 5, plus Chapter 6 if multi-agent).
    • Control and actuation (Chapters 2 & 5).
  • Outputs:
    • Robot motion in simulation (and hardware, if used).
    • Status updates, logs, and visualizations (RViz, dashboards).

Keep the diagram simple but complete enough that another engineer could understand “how information flows” through your system.

2.2 ROS 2 Node Graph & Interfaces​

Translate the block diagram into a ROS 2 node graph:

  • List key nodes (perception, planner, controller, user interface, logging, etc.).
  • For each node, specify:
    • Subscribed topics, published topics, services, and actions.
    • Message types (sensor_msgs/Image, geometry_msgs/Twist, etc.).
    • Namespaces (e.g., /robot1/, /robot2/) if you include multi-agent elements.

Example (simplified, single-robot):

voice_cmd_node  →  nl_intent_node  →  task_planner_node  →  nav2_stack  →  low_level_controller
        |                                                          ^
        v                                                          |
   status_publisher  ←---------------- perception_node  ←  sensors (RGB-D, IMU)

Document this graph in your repository as a diagram and a short text description.

2.3 Data Models, APIs & Internal Contracts​

Clearly defined data contracts make your system easier to debug and extend:

  • Define internal data structures where ROS 2 messages aren’t enough:
    • Task descriptors (e.g., task_id, type, target_pose, object_id).
    • World state summaries (e.g., active goals, obstacles of interest).
    • Logs/metrics payloads.
  • If you use an LLM/VLM or external service:
    • Describe the request/response schema.
    • Specify how you encode observations and how responses map back into ROS 2 commands.

Keep these definitions in a single place (e.g., docs/architecture.md or a data-model file) and reference them from your code.

2.4 Safety, Failure Modes & Fallback Paths​

Even in simulation, you should design for safe failure:

  • Identify critical failure modes:
    • Planner fails to find a path.
    • Perception node crashes or produces no detections.
    • Navigation oscillates or times out.
  • For each, define a fallback:
    • Stop and wait for human intervention.
    • Re-plan from a safe pose.
    • Reset specific nodes (using lifecycle nodes or launch file restarts).

Add these behaviors to your architecture as explicit states or behavior-tree branches, not afterthoughts.

2.5 Mini-Lab: Architecture Review​

Goal: Produce a complete architecture blueprint and validate it with peers or instructors.

Tasks​

  1. Create:
    • A high-level block diagram.
    • A ROS 2 node graph with topics, services, and actions.
    • A short text document describing key data models and failure modes.
  2. Conduct a 15–20 minute architecture review:
    • Walk a peer or mentor through your diagrams.
    • Ask them to “follow a command” from human input to robot action and back to status output.
    • Capture questions and concerns for later refinement.

Deliverables​

  • Architecture diagrams stored in version control (ideally as text-based diagrams or images).
  • An architecture notes document with decisions, trade-offs, and open questions.

Summary​

A solid architecture blueprint turns your capstone into a set of implementable components rather than a vague idea. In the next topic, you will convert this design into an implementation roadmap and milestone plan that you can actually execute within the remaining time.