STATERA Library · Series 07 · Volume 20 · Chapter 02 · EN
Source: https://github.com/Statera-Library/07_Vol_20_Quadruped_Electrical_Architecture/blob/main/Chapter_02_System_Level_Architecture/Chapter_02_System_Level_Architecture_EN.md

Volume 20. Quadruped Electrical Architecture

Chapter 02. System Level Architecture

02.01. Functional Block Diagram

A functional block diagram provides the system-level view of a quadruped robot by showing how major electrical and computational functions interact without immediately specifying detailed circuits or physical packaging. The diagram begins with the energy source, typically the battery system, and follows the power path through protection and distribution toward computing units, communication networks, sensors, and four leg actuator systems. This functional view establishes the major boundaries of the electrical architecture and provides the foundation for later detailed design.

At the center of the architecture, the power system supplies controlled electrical energy to the major loads while protection functions isolate abnormal conditions. The battery, battery management system, power distribution unit, DC/DC converters, and associated protection devices form the energy path. High-power loads such as motor drivers and actuators require a different electrical treatment from lower-power loads such as sensors and control electronics. Separating these functional domains makes it easier to evaluate voltage levels, current demand, protection requirements, and failure behavior before selecting individual components.

The quadruped\'s computing system forms another major functional block. A real-time controller is responsible for deterministic control functions such as actuator commands, feedback processing, state estimation, and low-level motion control. A higher-level computing platform can perform perception, localization, planning, artificial intelligence, and Physical AI functions. The functional architecture therefore separates high-level intelligence from real-time control while maintaining a defined interface between them. This separation allows computational workloads to evolve without fundamentally redesigning the actuator control architecture.

The sensor subsystem provides the robot with information about its internal state and surrounding environment. Internal sensing includes joint position, motor speed, torque, current, voltage, temperature, and foot-contact information. External sensing may include IMU, LiDAR, cameras, GNSS, and inspection sensors depending on the mission. These sensors do not simply connect directly to an AI computer; their information must pass through appropriate interfaces, synchronization mechanisms, preprocessing functions, and communication paths. The functional block diagram therefore treats sensing as an integrated information source for state estimation and perception.

The four legs represent repeated electromechanical functional units rather than four completely independent systems. Each leg contains multiple joint actuators, motor drivers, position or velocity feedback, and potentially torque or force sensing. The controller coordinates these actuators to generate locomotion, balance, posture control, and contact-force behavior. Because the same basic structure is repeated across the four legs, the functional architecture should emphasize common interfaces and reusable control concepts. This modularity supports scalable hardware development, diagnostics, manufacturing, and service.

Communication connects the functional blocks into a coordinated system. Low-level actuator and device communication may use deterministic networks or CAN-based interfaces, while higher-level computing and sensor communication may use Ethernet-based networks. Middleware such as DDS and ROS 2 can provide structured communication between software components. The architecture must distinguish between information that requires deterministic timing and information that primarily requires bandwidth and flexibility. This distinction becomes particularly important when perception, planning, and AI workloads coexist with high-frequency actuator control.

Time synchronization is an architectural function rather than merely a software feature. Sensor measurements, actuator feedback, controller states, and perception results must be associated with meaningful time references so that the robot can correctly interpret its physical state. PTP-based synchronization and hardware timestamping can support tighter temporal relationships between distributed computing and sensing elements. The functional architecture should therefore show time as a shared infrastructure connecting sensing, computing, communication, and control rather than treating timestamps as isolated metadata.

Safety functions form an independent but interacting layer across the system. Emergency stop, power isolation, fault detection, watchdog mechanisms, safe-state transitions, and redundancy can interrupt or constrain normal operation when dangerous conditions are detected. Safety should not depend entirely on the high-level AI computer because an AI or application processor may fail, become overloaded, or lose communication. The functional block diagram consequently provides a conceptual separation between normal intelligence and safety mechanisms while showing the interfaces through which safety can influence power, motion, and system operation.

The overall signal and energy flow can be understood as a closed physical loop. Electrical energy moves from the battery through protection and distribution to the actuators and computing system. Sensors observe the robot and its environment, controllers interpret these observations, and commands are generated for the actuators. The actuators then change the physical state of the robot, producing new sensor measurements and closing the loop. At the highest level, the quadruped electrical architecture therefore connects power, sensing, communication, computing, control, actuation, and safety into one integrated cyber-physical system.

This functional representation also establishes the boundary between system-level architecture and detailed engineering. At this stage, the objective is not to select every connector, wire gauge, transceiver, processor, or motor driver. Instead, the objective is to define what functions must exist, how those functions exchange power and information, and where architectural boundaries should be placed. The following system-level topics can then refine this foundation into distributed control, zonal electrical architecture, computing architecture, and safety architecture. This progression keeps the design traceable from system functions to implementable electrical hardware.

02.02. Distributed Control Architecture

A distributed control architecture divides the control responsibilities of a quadruped robot among multiple computing and control nodes rather than placing all functions in a single central controller. The architecture typically separates high-level motion planning, body-state estimation, locomotion coordination, and low-level joint control into different functional layers. Each node performs a defined responsibility while exchanging commands, measurements, and status information through a communication network. This approach matches the modular nature of a quadruped, where four legs contain repeated actuator and sensing units.

At the highest level, the main computing system determines the robot's desired behavior. It can process perception results, localization information, mission commands, and terrain conditions to generate motion objectives such as walking direction, velocity, body posture, and gait selection. A real-time control layer then converts these objectives into coordinated leg and joint commands. The high-level computing platform does not need to directly execute every motor-control loop. Instead, it communicates the required motion targets to lower-level controllers that can perform deterministic control at much higher update rates.

Each leg can be treated as a semi-independent control domain containing multiple joint actuators, motor drivers, encoders, and optional torque or force sensors. A local actuator controller can execute position, velocity, or torque control using its own feedback signals without continuously depending on the main AI computer. This local autonomy reduces communication traffic and allows the actuator loop to remain stable even when higher-level computing workloads temporarily increase. The central controller remains responsible for coordinating the four legs so that their local actions produce stable whole-body motion.

The distributed structure creates a clear hierarchy between body-level coordination and joint-level execution. The body controller considers the robot as a complete mechanical system and determines desired leg trajectories, contact states, balance responses, and overall motion behavior. Local joint controllers then track the required commands using high-frequency feedback. This separation is especially important for quadruped locomotion because balance depends on the coordinated timing of multiple joints and legs. A delay or failure in one local controller should be detectable without requiring the entire control architecture to operate as a single tightly coupled software process.

Communication networks provide the interface between these distributed control nodes. CAN FD can be appropriate for compact actuator and device communication where robust and relatively simple messaging is required, while EtherCAT or other deterministic Ethernet technologies can support tightly synchronized multi-axis control. Gigabit Ethernet can connect higher-level computing, perception, and data-processing systems where bandwidth is more important. DDS and ROS 2 can provide structured software communication at the application level. The architecture should therefore assign communication technologies according to timing, bandwidth, determinism, reliability, and implementation requirements rather than treating every connection identically.

Timing is a fundamental requirement of distributed control. A quadruped cannot coordinate multiple legs reliably if sensor measurements, actuator commands, and controller states use inconsistent time references. Time synchronization allows distributed nodes to associate their measurements and commands with a common temporal basis. PTP-based synchronization, hardware timestamping, and deterministic communication can improve the relationship between sensing, estimation, planning, and actuation. The objective is not simply to make clocks display the same time, but to establish a reliable temporal framework for interpreting the physical state of the robot.

The distributed architecture also creates natural boundaries for fault containment. A failure in an individual actuator controller, communication link, or sensor should be detected and managed without automatically causing uncontrolled behavior across the entire robot. Local diagnostics can identify abnormal current, temperature, encoder feedback, communication loss, or actuator behavior and report the condition to higher-level controllers. Depending on the safety requirements, the system may isolate a failed component, reduce the commanded motion, modify the gait, or transition toward a controlled safe state. This relationship connects distributed control directly with the later safety architecture.

Power and control responsibilities should also remain conceptually separated. The distributed controllers require stable low-voltage electrical power, while actuators consume substantially higher power from the main power architecture. Local control nodes may therefore be placed close to actuator groups to reduce signal wiring and improve modularity, while power distribution remains managed through dedicated protection and distribution functions. This separation helps prevent high-current switching activity from unnecessarily affecting sensitive control and communication electronics and provides a clearer boundary between electrical power design and control-system design.

The architecture can scale from a relatively simple central controller with distributed motor drivers to a more advanced network of intelligent actuator modules. In a basic implementation, the main controller may perform most state estimation and locomotion control while individual motor controllers execute only local servo loops. In a more distributed implementation, actuator or leg controllers can perform additional estimation, diagnostics, contact detection, and local coordination. The appropriate degree of distribution depends on computational capability, network performance, safety requirements, cost, packaging constraints, and the desired level of modularity.

A key advantage of distributed control is that hardware and software development can proceed through well-defined interfaces. An actuator module can be developed and tested independently as long as it satisfies the required power, communication, timing, command, feedback, and diagnostic interfaces. Similarly, the main computing platform can evolve from conventional motion planning toward more advanced AI and Physical AI functions without requiring every actuator controller to change. This separation supports technology migration, component replacement, maintenance, and future expansion while preserving the fundamental system architecture.

For a quadruped, distributed control should ultimately be understood as a coordinated cyber-physical hierarchy rather than simply a collection of independent controllers. The AI and mission layer determines what the robot should accomplish, the body-level controller determines how the robot should move, the leg and joint controllers determine how individual mechanisms should execute that motion, and the electrical and communication infrastructure provides the energy, information, timing, and protection required by all layers. A well-designed architecture therefore combines centralized coordination with local autonomy, allowing the robot to achieve responsive locomotion while remaining modular, diagnosable, scalable, and suitable for future safety and Physical AI integration.

02.03. Zonal Electrical Architecture

:::

A zonal electrical architecture divides the quadruped robot into several physical or functional electrical zones and places power distribution, communication interfaces, and selected control functions close to the devices they serve. Instead of routing every wire back to a central electrical cabinet, each zone can collect local connections and communicate with the rest of the robot through a smaller number of trunk connections. This approach can reduce harness complexity while creating clearer boundaries for power, signals, control, diagnostics, and service.

For a quadruped, the body and four legs naturally provide a useful basis for defining electrical zones. The central body can contain the battery interface, main protection, PDU, computing platforms, primary communication interfaces, and other common functions. Each leg can then operate as a local electrical zone containing actuator power connections, motor drivers, encoder interfaces, torque or force sensing, temperature monitoring, and local diagnostics. The exact physical partition depends on packaging, power requirements, mechanical movement, environmental protection, and serviceability.

A central body zone normally acts as the main electrical distribution point. Battery power enters the central architecture through appropriate protection and switching functions and is distributed toward the actuator zones and lower-power electronic loads. Computing equipment and major communication interfaces can also be located in this area. The central zone therefore provides the common infrastructure required by all four legs while avoiding unnecessary duplication of large power-conversion and protection components.

Each leg zone should provide a clearly defined interface between the central system and the local electromechanical components. High-power actuator supply, communication, control commands, sensor feedback, and diagnostic information can be grouped into a local interface. The motor drivers and sensing elements remain physically close to the joints they control, reducing the length of sensitive signal wiring and simplifying the dynamic harness. This arrangement is particularly useful because quadruped legs experience repeated bending, rotation, vibration, and mechanical impact during normal operation.

Zonal architecture also changes the way the wire harness is designed. A conventional centralized architecture may require many individual cables extending from the body to every actuator and sensor. A zonal architecture can instead use a trunk connection between the central body and each zone, with shorter local branches inside the zone. This can reduce harness length, connector count, routing complexity, and assembly effort. However, the zone interface must be carefully designed so that power capacity, communication bandwidth, voltage drop, shielding, grounding, and environmental protection remain adequate.

Power distribution within a zone requires particular attention because actuator loads can change rapidly during locomotion. A local zone may need to distribute high-current power to several motor drivers while simultaneously supplying lower-power sensors and control electronics. Local fusing, electronic protection, current monitoring, and controlled power switching can provide additional fault isolation. The architecture should prevent a fault in one leg from unnecessarily removing power from the other legs or from essential body-level computing and safety functions.

Communication can also be organized around the zones. A central communication backbone can connect the main controller with the four leg zones, while local networks connect the devices inside each zone. CAN FD can provide robust actuator and device communication, while EtherCAT or another deterministic Ethernet technology may be considered when synchronized multi-axis control is required. Gigabit Ethernet can support higher-bandwidth computing and perception functions. DDS and ROS 2 can provide higher-level software communication across the physical electrical architecture.

A zonal architecture must preserve the timing relationships required for quadruped motion. Local actuator controllers can execute high-frequency servo loops using locally available encoder and torque feedback, while the central controller provides coordinated body-level commands. Time synchronization becomes increasingly important when measurements from different zones must be combined for state estimation, balance control, contact detection, and locomotion. PTP and hardware timestamping can establish a common temporal reference across distributed computing, sensing, and control nodes.

Zonal separation also provides a useful foundation for fault containment and diagnostics. Each zone can monitor its own voltage, current, temperature, communication status, actuator feedback, and local controller health. When an abnormal condition is detected, the system can identify the affected zone and determine an appropriate response rather than treating the entire robot as one undifferentiated electrical system. Depending on the safety architecture, a failed zone may be isolated, its motion capability reduced, or the robot transitioned into a controlled safe state while other essential functions remain available.

Environmental protection is particularly important for leg zones because they are exposed to dust, water, mud, vibration, shock, and repeated mechanical movement. Local connectors and harnesses therefore need appropriate sealing, strain relief, shielding, and mechanical protection. The zonal boundary should be positioned so that serviceable components can be replaced without requiring unnecessary disassembly of the complete robot. This connects zonal architecture directly with the later harness, connector, IP67/IP68, and serviceability engineering topics defined for the quadruped electrical system.

The main value of zonal electrical architecture is not simply reducing the number of wires. It establishes a scalable physical organization in which power, communication, control, sensing, diagnostics, and protection can be grouped according to the robot\'s mechanical structure. The central body provides shared infrastructure, while the four leg zones provide localized electromechanical functionality. This creates a practical bridge between the system-level functional architecture and the detailed actuator, harness, sensor, computing, communication, and safety designs that follow in the subsequent chapters.

02.04. Computing Architecture

The computing architecture of a quadruped robot defines how computational resources are organized across high-level intelligence, real-time control, sensor processing, and distributed actuator control. Because locomotion requires both high computational capability and deterministic response, a single processor is generally not sufficient for all workloads. The architecture therefore separates computing functions according to timing, processing requirements, power consumption, and safety relevance. The structure defined for this chapter includes Jetson architecture, Edge GPU Server, Real-Time Controller, AI Acceleration, PTP Time Synchronization, and Compute Redundancy.

The Jetson platform can serve as an important edge computing node for a quadruped because it combines CPU, GPU, memory, interfaces, and embedded software capabilities within a compact platform. It can execute perception, localization, sensor fusion, navigation, planning, and AI inference close to the robot. Its role should remain distinct from high-frequency actuator control. This separation allows computationally intensive AI workloads to operate on the edge platform while deterministic control remains within an appropriate real-time controller or actuator-level controller.

An Edge GPU Server can provide substantially greater computational capacity when the robot requires larger AI models, multiple perception pipelines, simulation-assisted development, or advanced Physical AI workloads. The server can process high-resolution camera and LiDAR data, perform multimodal inference, support world-model or foundation-model applications, and accelerate development workloads that exceed the capabilities of a compact embedded computer. Depending on the system configuration, the Edge GPU Server may operate onboard the robot or as a nearby computing resource connected through a high-bandwidth network.

The Real-Time Controller provides the deterministic control foundation of the computing architecture. Its primary responsibility is to execute functions that require predictable timing, including state estimation, motion control, gait coordination, trajectory tracking, and actuator command generation. These functions should not depend directly on the variable execution time of large AI models. The real-time controller receives motion objectives from higher-level computing and converts them into time-critical control commands, while collecting feedback from encoders, torque sensors, current sensors, and other actuator interfaces.

AI acceleration separates general-purpose computation from specialized operations required by modern perception and Physical AI workloads. GPU or other AI acceleration resources can execute neural-network inference, image processing, point-cloud processing, sensor fusion, and multimodal models more efficiently than a conventional CPU alone. The architecture should allocate acceleration according to workload characteristics rather than simply maximizing available compute. Memory capacity, bandwidth, thermal limits, latency, power consumption, and model deployment requirements must all be considered when selecting the appropriate accelerator.

The relationship between the Jetson platform, Edge GPU Server, and Real-Time Controller should be defined through clear functional boundaries. The Jetson or similar embedded computer can provide the main onboard perception and AI processing layer, while an Edge GPU Server can provide additional computational capacity when required. The Real-Time Controller maintains deterministic motion execution independently of these higher-level workloads. Communication between the layers should therefore transfer well-defined state, trajectory, command, and status information rather than exposing every internal computational process to every node.

PTP-based time synchronization provides the temporal foundation for distributed computing. A quadruped combines measurements from IMU, cameras, LiDAR, GNSS, joint encoders, torque sensors, and other devices, and these measurements may originate from physically separated computing nodes. A common time reference allows the system to associate observations, controller states, and actuator feedback with consistent timestamps. PTP and hardware timestamping can therefore improve sensor fusion, state estimation, motion coordination, and diagnostic analysis, particularly when multiple computing nodes operate concurrently.

Compute redundancy can improve availability and fault tolerance when loss of a computing node could create an unacceptable operational condition. Redundancy does not necessarily require every processor to be duplicated. Critical functions should first be identified, followed by an assessment of whether they require standby computing, active-active operation, degraded-mode operation, or independent fallback control. For example, high-level AI processing may tolerate temporary loss or reduced capability, while essential real-time control and safety-related functions may require a much stronger continuity mechanism.

The computing architecture should also consider the electrical and thermal characteristics of each computing tier. High-performance GPU computing can impose substantial power consumption and heat generation, while embedded platforms provide a more favorable balance between capability, size, and energy use. The physical placement of computing hardware must therefore consider cooling, vibration, electromagnetic compatibility, connector access, serviceability, and power distribution. These considerations connect computing architecture directly with the power, harness, grounding, communication, and mechanical packaging architectures of the quadruped.

A scalable computing architecture should allow the robot to evolve from conventional autonomous control toward more advanced AI and Physical AI functions. A basic configuration may use an embedded Jetson-class computer together with a dedicated real-time controller, while a more capable configuration can add an Edge GPU Server or additional AI accelerators. The same functional interfaces should remain stable as computational resources increase. This allows perception models, planning algorithms, foundation models, and embodied AI applications to evolve without requiring fundamental changes to the low-level control architecture.

The resulting architecture should be understood as a layered computing system rather than a collection of independent processors. High-level computing determines perception, reasoning, planning, and AI behavior; edge acceleration provides the computational resources required for demanding models; the real-time controller guarantees deterministic motion execution; distributed actuator controllers perform local servo functions; and synchronized communication connects these layers into one coherent system. PTP establishes the common temporal reference, while compute redundancy and fault-management mechanisms provide resilience. This organization creates a practical computing foundation for quadruped locomotion, autonomous operation, and future Physical AI integration.

02.05. Safety Architecture

Safety architecture in a quadruped robot defines the mechanisms that prevent electrical, computational, and motion failures from developing into hazardous physical behavior. Because the robot contains multiple high-power actuators and can move dynamically around people, equipment, and terrain, safety must operate across power, control, communication, sensing, and computing domains. It should therefore be designed as an independent system-level function rather than as a software feature added only to the main AI or motion controller.

The safety architecture begins with systematic identification of hazardous operating conditions. Examples include uncontrolled joint motion, loss of balance, unexpected acceleration, excessive actuator torque, communication failure, sensor malfunction, battery or power faults, overheating, and loss of critical computing functions. The architecture must determine which failures can be detected, how quickly they must be detected, and what response is required. Risk assessment therefore provides the foundation for defining safety functions, diagnostic coverage, redundancy, and safe-state behavior.

Emergency stop is one of the most fundamental safety functions. An E-Stop request should not depend solely on normal application software or an AI computer that may itself be malfunctioning. A dedicated safety path can detect an emergency-stop command and initiate predefined actions such as disabling actuator torque, opening power contactors, inhibiting motion commands, or transitioning the robot toward a controlled state. The detailed response must consider whether immediate power removal or controlled motion termination produces the lower physical risk for the particular operating condition.

A quadruped presents an important distinction between fail-safe and fail-operational behavior. Simply removing actuator power can cause the robot to collapse, which may itself create a hazard on stairs, uneven terrain, near personnel, or while carrying a payload. Some failures may therefore require the robot to retain limited control long enough to stop walking, stabilize its posture, lower its body, or enter another defined safe condition. Fail-operational capability does not imply unrestricted continued operation; it means preserving only the functions necessary to reach or maintain an acceptably safe state.

Fail-safe architecture addresses conditions where continued operation would create greater risk than stopping the affected function. The safety system can inhibit motion, isolate a faulty actuator or power branch, disable selected commands, or remove energy from hazardous components. Safe-state behavior should be explicitly defined for different fault categories because a single response is not appropriate for every failure. A communication fault, actuator overcurrent, thermal fault, sensor disagreement, and battery fault can require different combinations of controlled stopping, isolation, degraded operation, or power shutdown.

Redundancy improves tolerance to faults when a single failure must not immediately remove a critical capability. Redundant elements may include computing resources, communication paths, power monitoring, state sensing, or selected control functions. However, duplication alone does not guarantee safety because identical components can fail from the same cause. The architecture should therefore consider independence, diversity, physical separation, diagnostic comparison, and common-cause failures when deciding where redundancy provides meaningful improvement rather than unnecessary complexity.

Safety monitoring should operate continuously across the distributed electrical architecture. Local controllers can monitor actuator current, voltage, temperature, encoder behavior, torque feedback, communication status, and internal health, while body-level controllers evaluate consistency across multiple legs and sensors. A dedicated safety controller or safety-monitoring function can supervise critical conditions independently of high-level AI workloads. This layered monitoring allows faults to be detected close to their source while still supporting system-level interpretation of their effect on robot stability and motion.

Communication safety is especially important because motion commands and feedback travel between distributed controllers. The architecture should detect missing, delayed, corrupted, duplicated, or implausible information before it can generate unsafe actuator behavior. Sequence monitoring, timeout supervision, plausibility checking, network diagnostics, and synchronized timestamps can contribute to communication integrity. Deterministic networks and PTP-based synchronization can further support predictable timing, although time synchronization itself does not replace the need for explicit safety supervision and fault handling.

Power safety connects the safety architecture directly with the battery, PDU, contactors, DC/DC converters, and actuator power branches. The system should detect abnormal voltage, current, temperature, insulation or distribution conditions according to the applicable electrical design. Power isolation can be organized so that hazardous energy is removed from a failed section without unnecessarily disabling every low-voltage controller or diagnostic function. Maintaining selected control and monitoring power during a fault can be valuable when the robot must record the event or execute a controlled transition before shutdown.

The safety architecture must remain separated from advanced AI decision making where deterministic safety behavior is required. Perception models, VLMs, agents, foundation models, and other Physical AI functions can provide valuable environmental understanding and operational intelligence, but their outputs should not constitute the only protection against hazardous motion. Safety-critical limits and shutdown paths should remain enforceable even when AI processing becomes unavailable, delayed, or incorrect. This establishes a clear authority boundary between intelligent behavior generation and independent safety enforcement.

Field safety validation is necessary because laboratory verification alone cannot represent every interaction among locomotion, terrain, payload, communication, power, and environmental conditions. Tests should intentionally exercise relevant fault conditions and verify detection, reaction time, degraded operation, isolation, emergency stopping, and safe-state transitions. Event logging and diagnostic records should capture the sequence of conditions surrounding each event so that failures can be reconstructed. Repeated field testing can then confirm that safety mechanisms remain effective under realistic dynamic operation.

At the system level, quadruped safety architecture integrates risk assessment, emergency stop, fail-operational behavior, fail-safe mechanisms, redundancy, monitoring, power isolation, communication supervision, and field validation into one coordinated protection framework. Normal computing and AI functions determine what the robot should do, while the safety architecture defines what the robot must never be allowed to do and how it responds when assumptions fail. This separation provides the basis for later detailed work on risk assessment, E-Stop design, fail-operational control, fail-safe architecture, redundancy, and field safety validation.

---

Author: Richard Minsoo Go

LinkedIn: Richard Minsoo Go