STATERA Library · Series 07 · Volume 22 · HRS-013 · EN
Source: https://github.com/Statera-Library/07_Vol_22_Robotics_Engineering_Standards/blob/main/HRS_013_Quadruped/HRS_013_Quadruped_EN.md

Volume 22. Hills Robotics Engineering Standards

Chapter 13. HRS-013 Quadruped

13.01. Quadruped EE Architecture Standard

A quadruped electrical and electronic architecture shall be designed as a distributed, real-time system that integrates power conversion, joint actuation, sensing, computing, communication, diagnostics, and safety functions into one coordinated platform. The architecture shall support stable locomotion under continuously changing mechanical loads while maintaining deterministic control behavior, electrical robustness, and fault containment across all four legs.

The system architecture shall separate energy distribution, real-time motion control, perception computing, safety supervision, and external communication into clearly defined functional domains. Interfaces between domains shall be standardized so that changes to actuators, batteries, sensors, or computing modules do not require uncontrolled redesign of the complete robot. Electrical boundaries shall also provide appropriate isolation and protection against faults propagating between subsystems.

The primary energy source shall supply a protected main power bus through battery management, contactor, pre-charge, fuse, and power distribution functions. High-current actuator power shall be separated from regulated low-voltage rails used by computers, sensors, communication devices, and safety controllers. DC/DC converters shall provide stable auxiliary voltages despite rapid current variations caused by acceleration, landing, stair climbing, recovery motions, or simultaneous joint operation.

Power distribution shall account for the highly dynamic nature of quadruped locomotion. Joint motors can generate large transient currents during stance, jumping, disturbance rejection, and recovery from loss of balance. Conductor sizing, connector ratings, fuse coordination, bus impedance, converter capacity, and battery discharge capability shall therefore be evaluated using both continuous and peak operating conditions rather than nominal power consumption alone.

Each leg shall form a modular electrical subsystem containing joint actuators, motor drives, position feedback, temperature monitoring, and associated harness interfaces. Hip, thigh, and knee joint modules shall use repeatable electrical interfaces wherever practical so that legs can be manufactured, tested, replaced, and serviced as standardized assemblies. Module identification and configuration information shall allow the central controller to verify installed hardware before enabling motion.

The actuator architecture shall provide deterministic command and feedback paths between the motion controller and every joint drive. Joint position, velocity, torque or current, drive status, temperature, voltage, and fault information shall be available at rates appropriate for dynamic locomotion control. Communication latency, jitter, synchronization, and packet loss shall be controlled because inconsistent actuator timing can directly degrade balance and whole-body stability.

The computing architecture shall distinguish hard real-time control from computationally intensive perception and Physical AI functions. A real-time controller shall execute joint control, state estimation interfaces, gait execution, balance functions, and safety-related motion supervision, while an AI computing platform may execute vision, terrain interpretation, semantic perception, navigation, mapping, behavior planning, and learned policies. Failure of higher-level AI functions shall not directly compromise basic actuator safety.

Sensor architecture shall combine proprioceptive and exteroceptive sensing. Joint encoders, motor current sensing, actuator temperature sensing, and inertial measurement provide information about internal robot state, while cameras, depth sensors, LiDAR, range sensors, or other environmental sensors support terrain understanding and navigation. Sensor placement, power supply, grounding, synchronization, calibration, and communication interfaces shall be defined as architectural requirements rather than treated as independent component details.

An IMU shall provide a high-rate reference for body orientation, angular velocity, and acceleration and shall be integrated closely with the real-time state-estimation path. Joint feedback and IMU measurements shall use a common or traceable time base whenever sensor fusion depends on precise temporal alignment. Additional body or foot sensing may be incorporated when required for contact estimation, load recognition, slip detection, or terrain interaction.

Communication networks shall be partitioned according to timing and bandwidth requirements. Deterministic industrial Ethernet, EtherCAT, CAN FD, or equivalent real-time networks may support actuator and low-level control traffic, while Gigabit Ethernet or higher-bandwidth links may serve cameras, LiDAR, AI computers, logging systems, and service interfaces. Network topology shall prevent high-bandwidth perception traffic from interfering with time-critical joint-control communication.

The grounding and EMC architecture shall recognize that high-frequency motor switching, rapidly changing actuator currents, long distributed harnesses, high-speed Ethernet, and sensitive inertial or perception sensors coexist within a compact moving structure. Power return paths, chassis bonding, shield termination, cable separation, common-mode suppression, and connector grounding shall therefore be coordinated at system level. EMC performance shall be verified under representative multi-joint dynamic operation.

Harness design shall accommodate repeated articulation, vibration, shock, torsion, bending, and mechanical impact throughout the expected service life. Leg harnesses shall provide controlled bend radii, strain relief, abrasion protection, secure retention, and sufficient service loops without creating interference with joint motion. Connectors located in exposed areas shall provide environmental protection appropriate to dust, moisture, contamination, and field operation while remaining maintainable.

Safety architecture shall provide an independent mechanism for detecting conditions that require torque inhibition, controlled stop, or complete power removal. Emergency stop, actuator enable, watchdog supervision, communication timeout, overcurrent, overtemperature, battery faults, and critical controller failures shall transition the robot toward a defined safe state. Safety actions shall not depend solely on application software running on the main AI computer.

Fault containment shall be applied so that a single joint, leg, sensor, communication segment, or auxiliary device failure does not unnecessarily disable unrelated electrical functions or create uncontrolled motion. The architecture shall support selective isolation where technically feasible and shall report sufficient diagnostic information to identify the failed subsystem. Critical faults shall be latched or recorded with timestamps and operating context to support root-cause analysis.

Startup and shutdown sequencing shall prevent uncontrolled actuator energization. After power application, the system shall verify battery condition, power rails, controller health, communication links, actuator identity, sensor availability, safety circuits, and essential calibration status before enabling torque. Shutdown shall place joints into an appropriate controlled condition before removing actuator power and shall preserve diagnostic and operational records needed for subsequent service.

The quadruped shall provide a unified diagnostic architecture covering the battery, PDU, DC/DC converters, joint drives, sensors, computing modules, communication networks, and safety devices. Diagnostic information shall include fault codes, warnings, operating counters, voltage and current measurements, thermal conditions, communication statistics, and software or firmware versions. Service interfaces shall support efficient troubleshooting without requiring unnecessary disassembly of the robot.

Software and firmware configuration shall remain traceable to the installed electrical hardware. Each controller, actuator drive, sensor module, and configurable electrical device should expose identification and version information so that compatibility can be checked automatically. Firmware update and OTA mechanisms shall include integrity verification, controlled activation, rollback capability where required, and protection against incomplete updates that could leave the robot in an unsafe configuration.

Thermal design shall consider simultaneous operation of motors, drives, converters, processors, and AI accelerators within a compact enclosure. Temperature sensing shall be provided at critical components, and thermal limits shall be coordinated with software derating and shutdown strategies. Cooling performance shall be evaluated during demanding locomotion scenarios because electrical losses and processor loads can differ substantially from stationary laboratory conditions.

The architecture shall support maintainability through modular replacement of batteries, legs, actuator modules, computing units, sensors, and communication components. Electrical interfaces shall minimize opportunities for incorrect assembly through connector keying, labeling, pin assignment control, and documented mating rules. Replacement procedures shall define any required calibration, configuration verification, functional checks, and safety validation before the robot is returned to operation.

Verification of the architecture shall include static electrical tests and dynamic robot-level tests. Power integrity, voltage drop, protection coordination, grounding, insulation, communication timing, synchronization, EMC behavior, thermal performance, fault injection, emergency stopping, startup sequencing, and diagnostic coverage shall be evaluated under representative locomotion loads. Testing shall include walking, turning, slopes, disturbances, high-torque maneuvers, and other conditions that expose realistic electrical transients.

The approved quadruped EE architecture shall be maintained as a controlled engineering baseline covering block diagrams, power trees, network topology, harness interfaces, connector definitions, grounding strategy, protection devices, controller assignments, safety paths, and diagnostic interfaces. Any architectural change affecting these elements shall undergo documented impact analysis and verification before release, preserving consistency with the broader Hills Robotics electrical, communication, calibration, and safety standards.

13.02. Actuator Network Standard

The quadruped actuator network shall provide a deterministic, synchronized, and fault-tolerant communication infrastructure between the real-time motion controller and all joint actuator modules. The network shall support high-frequency command and feedback exchange required for dynamic locomotion while maintaining predictable latency and bounded jitter. Network design shall be treated as part of the motion-control architecture rather than as a general-purpose communication interface.

Each actuator node shall represent a clearly identifiable joint module with a unique logical address, hardware identity, firmware version, and configuration record. Hip, thigh, and knee actuator modules should use standardized communication interfaces wherever practical. Node identification shall prevent duplicate addressing and incorrect joint assignment, and the controller shall verify the expected actuator topology before torque or motion commands are enabled.

The preferred actuator network shall use a deterministic real-time communication technology such as EtherCAT, CAN FD, or an equivalent protocol selected according to control frequency, actuator count, payload size, synchronization accuracy, wiring complexity, and safety requirements. General-purpose Ethernet traffic shall not share an uncontrolled communication path with time-critical actuator commands when such sharing could introduce variable latency or congestion.

The network topology shall support the physical arrangement of the quadruped while minimizing harness length, connector count, and communication failure points. A centralized topology may connect all joint drives directly to the primary controller, while a distributed topology may organize communication by leg or actuator group. The selected topology shall provide sufficient bandwidth and deterministic timing under simultaneous operation of every joint at the maximum specified control rate.

Joint command messages shall contain the information required by the selected control mode, which may include target position, velocity, torque, current, gain parameters, operating mode, and enable state. Feedback messages shall provide measured position, velocity, estimated or measured torque, motor current, drive temperature, supply voltage, operating state, and diagnostic status. Signal definitions, units, scaling, limits, and update rates shall be controlled configuration data.

The actuator network shall support cyclic communication suitable for closed-loop locomotion control. Command transmission and feedback acquisition shall occur according to a defined control cycle so that the motion controller receives a coherent representation of the robot state. Communication scheduling shall prevent individual nodes or asynchronous service messages from delaying critical cyclic traffic beyond the timing limits established for balance and gait control.

Time synchronization shall maintain a consistent temporal relationship among actuator commands, joint feedback, IMU measurements, and state-estimation data. Where distributed clocks or equivalent synchronization mechanisms are available, they should be used to establish a common time reference across actuator nodes. Synchronization accuracy shall be specified and verified according to the requirements of whole-body control, contact estimation, and sensor fusion.

Communication latency shall be bounded from command generation at the real-time controller to command acceptance at each actuator drive and from joint measurement acquisition to availability at the controller. Maximum allowable latency and jitter shall be defined for the selected control architecture. Performance shall be evaluated during simultaneous multi-joint motion because network behavior under light laboratory traffic may not represent demanding locomotion conditions.

The actuator network shall define explicit operating states such as initialization, pre-operational, ready, enabled, active control, degraded operation, fault, and shutdown where supported by the selected drive architecture. State transitions shall follow controlled sequences and shall prevent unexpected torque generation. An actuator shall not enter an enabled state until communication, configuration, safety status, and essential feedback signals have been validated.

Communication timeout monitoring shall be implemented at both controller and actuator levels where technically supported. Loss of cyclic commands, invalid message sequences, synchronization failure, or communication interruption beyond the specified timeout shall cause the affected actuator or actuator group to transition toward a defined safe behavior. The response shall be coordinated with the quadruped safety architecture to avoid uncontrolled collapse or unexpected motion.

Network fault handling shall distinguish transient communication errors from persistent failures. Error counters, frame errors, dropped packets, synchronization deviations, node resets, bus-off conditions, link interruptions, and topology changes shall be monitored when supported by the protocol. Repeated or safety-relevant communication faults shall generate diagnostic events with timestamps and sufficient context to support field troubleshooting and root-cause analysis.

Fault containment shall prevent a malfunctioning actuator node from continuously disrupting communication with healthy joints. Network architecture, protocol mechanisms, controller supervision, and electrical protection shall be coordinated to isolate or disable a failed node where feasible. A single communication failure shall not result in uncontrolled commands being accepted by other actuators, and stale commands shall never be interpreted as valid continuing motion requests.

The actuator communication interface shall incorporate data-integrity mechanisms appropriate to the selected protocol. Frame checking, sequence monitoring, timeout detection, plausibility checks, command-range validation, and state-dependent message acceptance shall be applied as required. Safety-related actuator commands shall receive additional protection where necessary so that corrupted, duplicated, delayed, or unintended messages cannot directly produce hazardous joint behavior.

Physical-layer design shall consider the severe electrical environment produced by high-current motors, inverter switching, DC/DC converters, and rapidly changing joint loads. Communication cables shall be routed and shielded to minimize coupling from actuator power conductors. Cable impedance, termination, grounding, connector shielding, bend radius, and branch length shall comply with the selected network technology and remain valid throughout repeated leg articulation.

Actuator connectors shall provide reliable communication under vibration, shock, repeated movement, contamination, and maintenance operations. Power and communication contacts may share a connector only when electrical separation, EMC performance, current capacity, creepage, clearance, and serviceability requirements are satisfied. Connector keying and pin assignment shall prevent incorrect mating, polarity reversal, and unintended connection between actuator modules.

The actuator network shall provide sufficient diagnostic access without compromising deterministic control performance. Service tools shall be capable of reading node identity, firmware version, communication state, fault history, voltage, current, temperature, encoder status, operating counters, and relevant network statistics. Diagnostic traffic shall be scheduled or rate-limited so that maintenance operations cannot consume bandwidth reserved for real-time joint control.

Configuration parameters shall be managed as controlled engineering data. Network address, joint assignment, direction convention, gear ratio, encoder offset, torque constant, current limit, thermal limit, communication period, timeout, and control parameters shall be traceable to the corresponding actuator hardware and software version. Unauthorized or incompatible configuration changes shall be detected before the actuator is permitted to enter active operation.

Firmware update mechanisms shall preserve actuator-network integrity throughout maintenance and OTA operations. Updates shall verify actuator identity, firmware compatibility, image integrity, and successful programming before activation. Where practical, recovery or rollback mechanisms shall be provided for interrupted updates. Firmware transfer shall not occur during normal dynamic operation when it could interfere with deterministic communication or actuator safety.

Startup verification shall discover or confirm all required actuator nodes and compare the detected topology with the approved robot configuration. Missing, duplicated, unexpected, or incompatible nodes shall generate a diagnostic condition and prevent normal motion when the discrepancy affects safe control. Joint feedback plausibility and communication health shall be checked before torque enable so that wiring or configuration errors are detected before locomotion begins.

Network performance verification shall include bandwidth utilization, cyclic timing, end-to-end latency, jitter, synchronization accuracy, packet or frame errors, timeout behavior, node recovery, cable disturbance, and simultaneous maximum-rate communication. Testing shall be performed with all joints active under representative walking, turning, slope, disturbance-rejection, and high-torque conditions to reproduce electrical noise and processor loads encountered during actual robot operation.

Fault-injection testing shall verify network behavior during cable disconnection, connector intermittency, actuator reset, corrupted or missing communication, delayed feedback, synchronization loss, controller restart, and individual node failure. The resulting actuator response, safety transition, diagnostic record, and system recovery shall conform to defined requirements. Recovery shall never automatically restore hazardous torque without the required state and safety checks.

The released actuator network shall be maintained as a controlled engineering baseline containing topology, protocol selection, node assignments, message definitions, control periods, synchronization requirements, timeout values, connector pinouts, cable specifications, termination rules, diagnostic definitions, and firmware compatibility information. Any change affecting real-time communication behavior shall undergo documented impact analysis and regression verification before release.

13.03. Quadruped Sensor Standard

The quadruped sensor architecture shall provide reliable, synchronized, and sufficiently redundant information for locomotion control, state estimation, terrain perception, navigation, diagnostics, and safety supervision. Sensor selection and integration shall consider the highly dynamic motion of a legged platform, including vibration, impact, rapid attitude changes, repeated foot contact, and changing environmental conditions. Sensor interfaces shall be standardized as part of the overall quadruped EE architecture.

The sensor system shall distinguish between proprioceptive sensors that measure the internal state of the robot and exteroceptive sensors that observe the surrounding environment. Proprioceptive sensing shall include joint position, actuator current or torque, temperature, and inertial measurements. Exteroceptive sensing may include RGB cameras, stereo or depth cameras, LiDAR, range sensors, and other perception devices required by the intended operating environment.

Every joint shall provide position feedback with resolution, accuracy, update rate, and latency appropriate to the specified motion-control performance. Absolute position sensing is preferred where initialization without uncontrolled joint movement is required. Where incremental encoders are used, the architecture shall provide a reliable reference procedure. Encoder direction, zero position, scaling, joint assignment, and calibration values shall be maintained as controlled configuration data.

Actuator current or torque-related sensing shall support joint control, load estimation, contact interpretation, diagnostics, and protection functions. Measurement range shall accommodate both continuous locomotion loads and short-duration peak loads associated with acceleration, impact, disturbance rejection, and recovery behavior. Current and torque signals used for control shall have defined accuracy, bandwidth, filtering, saturation behavior, and diagnostic limits.

Temperature sensing shall monitor components whose thermal condition can affect actuator performance, reliability, or safety. Sensors should be located at representative motor, drive, power-electronics, battery, and computing locations as required by the product architecture. Temperature information shall support warning, derating, shutdown, diagnostics, and lifetime assessment, with thresholds coordinated with the corresponding component specifications.

At least one primary inertial measurement unit shall provide body acceleration and angular-rate information at a rate suitable for state estimation and balance control. The IMU installation location and orientation shall be mechanically defined and traceable to the robot coordinate system. Mounting shall minimize unwanted structural vibration while preserving the dynamic response needed for locomotion, and the transformation between sensor and body coordinates shall be maintained as calibrated configuration data.

Where higher integrity or availability is required, an additional IMU or independent attitude-related sensing path may be incorporated. Redundant measurements shall not simply be averaged without fault evaluation. The control architecture should perform plausibility comparison, bias monitoring, signal-quality assessment, and failure detection so that disagreement between sensors can be identified before corrupted inertial information significantly affects balance or locomotion control.

Foot contact sensing may use force sensors, load cells, joint torque estimation, motor current, dedicated contact switches, or combinations of these methods according to mechanical design and performance requirements. The sensing method shall provide sufficient information to distinguish expected stance and swing conditions. Contact information used by gait control shall have defined detection thresholds, hysteresis, filtering, timing characteristics, and failure behavior.

Perception sensors shall provide environmental information required for terrain understanding, obstacle detection, localization, mapping, and autonomous navigation. Camera, depth, and LiDAR configurations shall be selected according to required field of view, operating distance, minimum detectable obstacle, terrain geometry, lighting conditions, and environmental exposure. Sensor placement shall minimize occlusion by the robot body and legs throughout representative gait configurations.

Camera systems shall define resolution, frame rate, exposure behavior, interface bandwidth, field of view, mounting orientation, and calibration requirements. Stereo and depth systems shall additionally specify useful depth range and accuracy appropriate to navigation and terrain assessment. Where multiple cameras are used, their relative mounting geometry shall be mechanically controlled so that calibration remains stable under vibration, transportation, service, and repeated locomotion.

LiDAR or equivalent ranging sensors shall be selected according to detection range, angular coverage, resolution, update rate, environmental rating, and interface requirements. Mounting shall provide the intended obstacle and terrain coverage without unacceptable self-occlusion. The architecture shall consider motion distortion during dynamic locomotion and shall provide sufficiently accurate timestamps and body-motion information when compensation is required by perception or mapping algorithms.

All sensor measurements used together for state estimation, control, or sensor fusion shall use a common or traceable time reference. Hardware synchronization, trigger signals, distributed clocks, Precision Time Protocol, or equivalent mechanisms should be used when software timestamps cannot provide the required accuracy. Timestamp definition shall identify the measurement event represented by the timestamp rather than merely the time at which data arrives at the receiving computer.

Sensor latency and jitter shall be characterized from the physical measurement event to data availability at the consuming controller or computing process. Maximum latency shall be specified for sensors participating in balance, state estimation, contact detection, and other time-critical functions. Variable processing delays from cameras, network switches, middleware, or AI pipelines shall not be allowed to silently degrade synchronization assumptions used by control algorithms.

Sensor communication shall be partitioned according to bandwidth and timing requirements. Joint sensors and other real-time feedback may be transported through the actuator network, while cameras and LiDAR may use Ethernet or dedicated high-bandwidth interfaces. Network capacity shall include peak sensor traffic, protocol overhead, diagnostics, and synchronization messages. Perception traffic shall not interfere with deterministic actuator communication required for stable locomotion.

Sensor power supplies shall be selected according to voltage tolerance, startup current, transient behavior, noise sensitivity, and fault characteristics. Sensitive sensors shall not share poorly controlled power paths with high-current actuators when motor switching or voltage transients could degrade measurement quality. Power distribution shall provide appropriate filtering, protection, grounding, and local decoupling, and a failed sensor shall not cause loss of unrelated critical sensor functions.

Grounding, shielding, and cable routing shall protect low-level sensor signals and high-speed digital interfaces from motor-drive and power-conversion interference. Sensor cables shall be separated from high-current conductors where practical, and shield termination shall follow the defined quadruped grounding architecture. EMC performance shall be evaluated while multiple joints operate dynamically because stationary sensor testing may not reproduce representative electromagnetic disturbances.

Sensor connectors and harnesses shall tolerate vibration, impact, repeated leg movement, flexing, abrasion, contamination, and service operations expected during the robot lifetime. Connectors shall provide suitable environmental protection and mechanical retention. Harness routing shall avoid joint pinch points, excessive bending, tensile loading, and collision with moving structures while maintaining sufficient service loops for assembly and module replacement.

Each sensor shall provide identification and configuration information sufficient to verify compatibility with the installed robot configuration. Relevant information may include sensor type, serial number, hardware revision, firmware version, logical assignment, coordinate frame, calibration version, and communication parameters. Unexpected, duplicated, incompatible, or incorrectly assigned sensors shall be detected during startup when they could affect control, perception, or safety.

Calibration shall establish the relationships required to convert raw measurements into physically meaningful robot data. Calibration records shall include applicable offsets, scale factors, alignment parameters, intrinsic parameters, extrinsic transformations, and relevant environmental compensation. Calibration values shall be version-controlled and traceable to the sensor and robot configuration, consistent with the broader calibration engineering requirements of the robotics platform.

Recalibration shall be required when defined events could invalidate existing sensor relationships. Such events may include sensor replacement, mechanical impact, mounting adjustment, structural repair, repeated calibration failure, abnormal diagnostic trends, or modification of the sensor mounting structure. The system should provide automated or guided calibration procedures where practical to reduce service variability and improve configuration consistency.

Sensor diagnostics shall detect conditions such as missing data, frozen values, excessive noise, out-of-range measurements, implausible changes, communication errors, synchronization loss, temperature excursions, calibration mismatch, and internal sensor faults. Diagnostic logic shall distinguish temporary disturbances from persistent failures where possible. Safety- or control-relevant faults shall be communicated to the appropriate supervisor with timestamps and operating context.

Degraded operation shall be explicitly defined for sensor failures that do not require immediate shutdown. Loss of a noncritical perception sensor may permit restricted locomotion, reduced speed, teleoperation, or controlled return, while loss of a sensor essential to balance or safe motion may require stopping or torque-state transition. The permitted response shall depend on sensor criticality and available independent information rather than on sensor type alone.

Sensor verification shall include accuracy, repeatability, resolution, bandwidth, latency, jitter, synchronization, temperature behavior, vibration resistance, communication robustness, power disturbances, EMC susceptibility, and fault detection. Robot-level testing shall evaluate sensor performance during walking, turning, slopes, impacts, rapid body motion, high actuator loads, and representative environmental conditions rather than relying exclusively on static component-level tests.

The released quadruped sensor configuration shall be maintained as a controlled engineering baseline containing sensor types, approved part numbers, mounting locations, coordinate frames, power interfaces, communication interfaces, update rates, synchronization requirements, calibration data, diagnostic thresholds, connector definitions, and software compatibility. Any change affecting measurement quality, timing, geometry, or safety shall undergo documented impact analysis and appropriate regression verification before release.

13.04. Quadruped Safety Requirement

The quadruped safety architecture shall protect people, equipment, the environment, and the robot from hazards arising from high-torque joints, dynamic locomotion, electrical energy, autonomous behavior, communication failures, sensor faults, and unexpected environmental interactions. Safety requirements shall be integrated with the electrical, actuator, sensor, communication, and computing architectures rather than implemented as an independent software feature.

Safety engineering shall begin with systematic identification of hazards associated with normal operation, foreseeable misuse, maintenance, transportation, charging, startup, shutdown, and fault conditions. Hazard analysis shall consider crushing, trapping, collision, falling, uncontrolled joint motion, unexpected startup, electrical faults, thermal events, battery hazards, loss of stability, and autonomous navigation into unsafe areas.

Each identified hazard shall be evaluated according to its potential severity, exposure or operational likelihood, and controllability using the safety assessment method adopted for the product. Safety requirements and risk-reduction measures shall be traceable to the corresponding hazards. Residual risks that cannot reasonably be eliminated through design shall be documented and addressed through operational restrictions, warnings, procedures, or protective measures.

The safety architecture shall apply a layered approach in which hazard prevention, fault detection, controlled degradation, safe stopping, and energy isolation provide complementary protection. No single software process running on the primary AI computer should constitute the only protection against a hazardous actuator condition. Safety-critical functions shall use sufficiently independent monitoring and shutdown paths appropriate to the assessed risk.

An emergency stop function shall provide a direct and clearly defined means of stopping hazardous robot behavior. Emergency stop activation shall override normal locomotion and autonomous commands and shall initiate the specified safe response without depending on cloud communication or high-level AI decision making. Resetting an emergency stop shall not automatically restart locomotion or re-enable hazardous torque.

The actuator safety architecture shall provide controlled mechanisms for torque enable, torque inhibition, and power removal. Joint drives shall remain disabled during initialization until required controller, communication, sensor, and safety conditions have been verified. Loss of actuator commands, invalid state transitions, critical drive faults, or safety-controller requests shall cause affected joints to enter a predefined safe torque or power state.

Safe stopping behavior shall account for the fact that immediate torque removal may cause a quadruped robot to collapse. Depending on the detected hazard and available system integrity, the preferred response may include controlled deceleration, transition to a stable stance, controlled lowering of the body, torque limitation, or final actuator power removal. The selected response shall minimize overall risk rather than assume that instantaneous de-energization is always safest.

The system shall monitor robot stability using information from the IMU, joint feedback, contact estimation, actuator status, and other available state information. Excessive body attitude, unexpected angular motion, loss of required ground contacts, severe slip, abnormal joint deviation, or state-estimation failure shall trigger an appropriate safety response. Thresholds shall avoid unnecessary intervention while remaining effective under representative dynamic operation.

Fall detection shall identify conditions in which the robot has fallen or is undergoing an unrecoverable loss of balance. Following a detected fall, actuator behavior shall prevent uncontrolled thrashing, repeated high-torque recovery attempts, or hazardous automatic motion near people. Recovery procedures shall require defined state checks and may require operator authorization depending on the operating environment and risk assessment.

Joint-level safety limits shall constrain position, velocity, torque, current, temperature, and other parameters that can produce mechanical or electrical hazards. Limits shall account for mechanical stops, transmission capability, motor ratings, thermal capacity, expected impact loads, and operating mode. Software command limits should be complemented by drive-level or independent protection where required by the safety analysis.

Collision risk shall be reduced through appropriate perception, motion planning, speed control, and protective stopping behavior. The robot shall maintain operating limits consistent with sensor coverage, braking or stopping capability, terrain, payload, and proximity to people. Loss or degradation of perception that reduces reliable obstacle detection shall result in an appropriate reduction of operating capability rather than unrestricted autonomous movement.

Sensor safety monitoring shall detect missing, frozen, implausible, delayed, unsynchronized, or out-of-range measurements when those measurements affect safe motion. Redundant sensors, analytical redundancy, cross-checking, or independent physical information should be used where required by risk. A sensor shall not be considered healthy solely because communication remains active; measurement plausibility and timing shall also be evaluated.

Communication safety shall address interruption, excessive latency, packet loss, corrupted information, stale commands, synchronization failure, and unexpected node behavior. Time-critical actuator commands shall have defined timeout mechanisms, and expired commands shall not remain active indefinitely. Safety-relevant messages shall include appropriate integrity checks, sequence monitoring, state validation, or equivalent protection supported by the communication architecture.

The real-time motion controller shall supervise high-level commands before they are applied to the actuator network. Commands generated by navigation, behavior planning, teleoperation, or AI policies shall be constrained by applicable velocity, acceleration, joint, stability, workspace, and safety limits. Invalid or physically unreasonable requests shall be rejected or modified before they can produce hazardous actuator behavior.

AI and Physical AI functions shall operate within a defined safety envelope. Learned policies, perception models, or adaptive algorithms shall not independently override hardware protection, emergency stop, actuator limits, or safety-controller decisions. Where AI confidence or environmental understanding is insufficient for the requested autonomous behavior, the system shall transition to an appropriate degraded, stopped, or operator-supervised operating mode.

Remote and teleoperation functions shall include communication-health supervision and clearly defined behavior following loss of the remote link. A communication interruption shall not cause the robot to continue indefinitely using stale operator commands. Depending on the operating scenario, link loss may initiate controlled stopping, stable stance, restricted autonomous return, or another validated safe behavior defined by the product safety concept.

Electrical safety shall protect against overcurrent, short circuits, abnormal voltage, insulation failures, connector faults, unintended energization, and hazardous thermal conditions. Battery, PDU, DC/DC converters, actuator branches, and auxiliary loads shall use coordinated protection appropriate to their energy levels. Critical power faults shall be detected and isolated without allowing uncontrolled energy release or unsafe actuator operation.

Battery safety monitoring shall supervise voltage, current, temperature, state information, communication health, and critical BMS faults. Conditions associated with overcharge, excessive discharge, overcurrent, overheating, or internal battery protection activation shall produce defined system responses. Charging shall be interlocked with robot operating states where necessary to prevent unintended locomotion or unsafe maintenance conditions.

Thermal safety shall monitor motors, actuator drives, power electronics, batteries, processors, and other components capable of reaching hazardous or damaging temperatures. Warning and derating thresholds should permit controlled reduction of performance before shutdown becomes necessary. Critical thermal limits shall cause a defined safe transition, and repeated overheating events shall be recorded for diagnostic and reliability analysis.

Startup safety checks shall verify the required safety devices, actuator states, communication links, critical sensors, controller health, configuration compatibility, and emergency stop status before locomotion is enabled. The robot shall not generate unexpected torque during booting, firmware initialization, network discovery, or calibration. Any critical discrepancy shall inhibit normal motion until the required condition has been corrected and verified.

Restart and recovery behavior shall prevent automatic resumption of hazardous motion after emergency stop, power interruption, controller reset, communication recovery, fall detection, or critical fault clearance. Re-enabling motion shall require confirmation that the robot is in an appropriate physical state and that required safety conditions are satisfied. Stored commands from before the interruption shall not be automatically executed after recovery.

Safety diagnostics shall record safety-relevant faults, emergency stop events, protective stops, actuator shutdowns, sensor failures, communication timeouts, thermal events, battery faults, and abnormal recovery attempts. Records shall include timestamps, operating state, relevant measurements, and configuration information where available. Diagnostic data shall support root-cause analysis without allowing service functions to bypass required safety mechanisms.

Degraded operation shall be explicitly defined for failures where continued limited operation produces less risk than immediate shutdown. Examples may include reduced speed, restricted gait, limited workspace, teleoperation-only mode, controlled return, or prohibition of autonomous navigation. Entry and exit conditions for degraded modes shall be deterministic, diagnosable, and validated against the hazards they are intended to control.

Safety validation shall include normal operation, foreseeable misuse, boundary conditions, and representative fault injection. Testing shall evaluate emergency stop, communication loss, sensor faults, actuator faults, excessive commands, overheating, low battery conditions, controller resets, loss of localization, unstable terrain, slipping, falling, and recovery behavior. Tests shall be conducted under realistic dynamic loads rather than exclusively in stationary conditions.

The released quadruped safety configuration shall be maintained as a controlled engineering baseline containing identified hazards, safety requirements, safe states, actuator limits, emergency-stop behavior, fault responses, degraded modes, diagnostic thresholds, safety interfaces, validation evidence, and approved hardware and software configurations. Any change that can affect hazard exposure or safety behavior shall undergo documented impact analysis and appropriate safety regression verification before release.

13.05. Quadruped Test Requirement

Quadruped testing shall verify that the complete robot satisfies its electrical, actuator, sensor, communication, computing, safety, and functional requirements under representative operating conditions. Verification shall progress from component and subsystem tests to integrated robot-level validation. Testing shall address both nominal performance and fault behavior because dynamic interaction among multiple joints, sensors, power systems, and controllers can expose failures that are not observable during isolated bench testing.

A controlled test plan shall define the requirement being verified, test configuration, equipment, environmental conditions, operating sequence, measurement channels, acceptance criteria, and required records. Every safety- or performance-related requirement shall be traceable to one or more verification activities. Test results shall identify hardware, software, firmware, calibration, and configuration versions so that evidence remains reproducible after design changes.

Electrical testing shall verify battery interfaces, power distribution, DC/DC conversion, voltage rails, current capacity, protection devices, grounding, insulation, startup behavior, and shutdown sequencing. Measurements shall include steady-state and transient voltage behavior under representative actuator loads. Tests shall confirm that high-current joint operation does not cause unacceptable voltage drop, controller reset, sensor malfunction, communication disturbance, or unintended protection activation.

Power testing shall reproduce dynamic load conditions associated with walking, turning, acceleration, slope operation, disturbance rejection, body-height ...