STATERA Library · Series 07 · Volume 20 · Chapter 09 · EN
Source: https://github.com/Statera-Library/07_Vol_20_Quadruped_Electrical_Architecture/blob/main/Chapter_09_Communication_Architecture/Chapter_09_Communication_Architecture_EN.md

Volume 20. Quadruped Electrical Architecture

Chapter 09. Communication Architecture

09.01. CAN FD

CAN FD is a communication protocol designed to extend the capabilities of Classical CAN while preserving its robust arbitration mechanism, fault confinement, and multi-master behavior. In a quadruped robot, it provides a practical network for distributed real-time controllers, joint modules, power electronics, battery systems, and safety-related devices. Its higher payload capacity and faster data phase are especially useful when many actuators must exchange state information at high rates.

A quadruped typically contains multiple electrically distributed subsystems connected through long and dynamically routed harnesses. Each leg may contain several motor drives, encoders, torque sensors, temperature sensors, and local controllers. CAN FD allows these devices to share a common differential bus rather than requiring dedicated point-to-point wiring, reducing harness complexity while maintaining deterministic priority-based access to critical control and diagnostic information.

CAN FD retains the arbitration concept of Classical CAN. Nodes monitor the bus while transmitting, and a dominant bit overrides a recessive bit. When multiple controllers begin transmission simultaneously, the frame containing the numerically lower identifier generally receives higher priority and continues without destructive collision. This mechanism is valuable for quadrupeds because emergency states, actuator faults, or high-priority motion-control information can be assigned precedence over lower-priority monitoring and maintenance traffic.

The major extension introduced by CAN FD is the ability to carry up to 64 data bytes in a frame, compared with the eight-byte payload limit of Classical CAN. This allows a robot controller to package multiple joint states, diagnostic values, or command parameters into fewer frames. Reduced protocol overhead becomes important when twelve or more joints continuously report position, velocity, torque, current, voltage, temperature, fault flags, and operating states.

CAN FD can also change the transmission rate after arbitration. Arbitration is performed at a nominal bit rate compatible with reliable shared-bus operation, while the data portion can use a higher bit rate when Bit Rate Switching is enabled. The network therefore preserves robust arbitration while increasing effective bandwidth. For quadruped control, this is useful when compact command messages coexist with larger telemetry, calibration, and diagnostic messages on the same physical network.

The physical layer normally uses a two-wire differential pair identified as CAN_H and CAN_L. Differential signaling provides strong immunity against common-mode electrical noise generated by motor phases, switching power converters, DC-DC converters, and high-current battery paths. This property is particularly important in quadrupeds because communication harnesses frequently pass close to actuator power cables, and repeated leg motion constrains the available separation between signal and power wiring.

Bus topology must be engineered carefully rather than treated as arbitrary wiring. A linear backbone with short stubs is generally preferred, and termination is placed at the two physical ends of the bus. Excessive stub length, unnecessary branches, connector discontinuities, and poorly controlled impedance can create reflections that become increasingly significant at higher CAN FD data rates. Harness topology must therefore be designed together with communication speed, cable characteristics, connector selection, and physical packaging.

The quadruped can partition CAN FD networks according to functional and physical boundaries. One bus may serve leg or actuator control, while another connects battery management, power distribution, thermal management, and auxiliary devices. Segmentation prevents noncritical traffic from consuming control bandwidth and limits the propagation of communication faults. A central real-time controller or gateway can then coordinate information between CAN FD segments and higher-bandwidth networks such as EtherCAT or Gigabit Ethernet.

Message architecture should reflect control criticality rather than simply the source device. Joint command and state messages require short periods, bounded latency, and carefully selected identifiers, whereas temperatures, lifetime counters, calibration information, and maintenance data can tolerate slower transmission. Assigning priorities and periods from functional requirements makes network behavior predictable under peak load and prevents diagnostic or monitoring traffic from interfering with time-sensitive actuator communication.

Joint modules are natural CAN FD nodes because they combine several local signals behind one communication interface. A joint controller can receive desired position, velocity, torque, operating mode, and limit information while returning measured motion states and health information. Local high-frequency current or motor-control loops can remain inside the drive, while CAN FD transports supervisory joint commands and states. This hierarchical arrangement avoids forcing every internal servo variable across the shared robot network.

The distinction between local servo control and network-level coordination is essential. A motor drive may execute current regulation at tens of kilohertz and position or torque loops at substantially higher frequencies than the CAN FD message cycle. The central controller therefore should not depend on the bus for every low-level switching decision. Instead, communication carries setpoints, synchronized state information, mode transitions, limits, and supervisory commands while deterministic local electronics maintain the fastest control loops.

Network utilization must be calculated for the worst operational condition rather than estimated from average traffic. Frame overhead, bit stuffing, arbitration, acknowledgement, retransmission, error frames, and different nominal and data bit rates all influence effective capacity. Engineers should reserve bandwidth for abnormal conditions because faults often increase diagnostic traffic precisely when reliable control communication is most important. A network operating near saturation during normal walking can become unstable during recovery or fault handling.

CAN FD includes mechanisms for detecting transmission errors and isolating malfunctioning nodes. Frame checking, acknowledgement monitoring, cyclic redundancy checks, error counters, and error states help prevent a defective controller from indefinitely corrupting communication. In a quadruped, these mechanisms should be integrated with system-level health monitoring so that repeated communication errors can trigger degraded locomotion, controlled stopping, actuator isolation, or transition into a defined safe operating state.

Communication timeout supervision is equally important because a syntactically valid network does not guarantee that every controller is functioning correctly. Joint controllers can monitor the arrival time of command frames, while the central controller monitors periodic joint-state messages. Missing, delayed, frozen, or implausible data should be interpreted using explicit fault logic. Sequence counters, alive counters, application-level CRCs, timestamps, and plausibility checks can provide additional end-to-end protection when required by the safety concept.

CAN FD also provides an effective path for diagnostics. Controllers can expose software versions, temperatures, supply conditions, error histories, communication statistics, actuator states, and internal diagnostic codes without requiring separate service wiring. This complements the dedicated diagnostics and OTA architecture of the quadruped platform, allowing maintenance software to identify failing joints or intermittent harness problems and correlate communication faults with mechanical load, temperature, vibration, or operating history.

Time synchronization requires special consideration because CAN FD arbitration provides prioritized access but does not by itself create a globally precise robot time base. Control messages may contain timestamps or synchronized counters, while a higher-level synchronization mechanism distributes reference time across the computing architecture. When the quadruped also uses Ethernet-based perception and compute networks, timestamp relationships between CAN FD actuator data, IMU measurements, cameras, LiDAR, and control outputs must be explicitly maintained.

The interface between CAN FD and the real-time controller forms an important architectural boundary. The controller may contain one or more CAN FD channels connected through integrated controllers, external transceivers, or isolated interfaces. Receive queues, transmit scheduling, interrupt behavior, DMA support, driver latency, and operating-system scheduling all influence end-to-end timing. Network determinism therefore depends not only on bus arbitration but also on software architecture and controller implementation.

Electrical robustness must be considered together with protocol design. Ground offsets, transient disturbances, electrostatic discharge, connector intermittency, shielding strategy, and electromagnetic coupling can affect communication even when message scheduling is correct. Transceiver selection should match the intended voltage environment, data rate, temperature range, and EMC requirements. Protection components must be chosen so that they suppress damaging transients without introducing excessive capacitance or degrading high-speed signal integrity.

Dynamic leg harnesses create additional challenges that are less severe in conventional stationary CAN installations. Continuous flexing can alter conductor geometry, damage shielding, increase contact resistance, or produce intermittent open circuits. CAN FD wiring should therefore follow the quadruped\'s flex-harness and serviceability strategy, with controlled bend radius, strain relief, appropriate twisted-pair construction, secure connector retention, and routing that avoids high-stress joint regions wherever possible.

Commissioning should include both protocol-level and physical-layer verification. Engineers should inspect bus load, identifier distribution, message periods, arbitration delays, error counters, and timeout behavior while also measuring differential waveforms and checking termination, reflections, dominant and recessive levels, and signal quality at representative nodes. Testing should cover standing, walking, running, high-torque maneuvers, battery transitions, fault injection, and environmental conditions that can expose marginal communication behavior.

CAN FD should ultimately be treated as one layer of the quadruped communication architecture rather than as a universal network. It is well suited to robust distributed control, actuator supervision, power electronics, and diagnostics, while EtherCAT may serve tightly synchronized motion functions and Gigabit Ethernet can transport perception and high-volume computing data. The architecture defined for this volume therefore places CAN FD alongside EtherCAT, Ethernet, DDS/ROS 2, MQTT, and time synchronization as complementary communication technologies.

09.02. EtherCAT

EtherCAT is a high-performance industrial Ethernet technology designed for deterministic, low-latency communication between controllers, drives, sensors, and distributed I/O devices. Within a quadruped robot communication architecture, EtherCAT is particularly suitable for tightly coordinated motion functions where multiple joint controllers must exchange commands and feedback with predictable timing. It complements CAN FD and Gigabit Ethernet rather than replacing them.

The fundamental advantage of EtherCAT comes from its processing principle. Instead of receiving a complete Ethernet frame, processing it, and then retransmitting a new frame at every node, EtherCAT slave devices process relevant data while the frame passes through them. Each device can read its assigned output data and insert input data into the same traveling frame, significantly reducing communication overhead and enabling efficient cyclic exchange across many distributed nodes.

A quadruped robot creates a demanding distributed-control problem because several joints must operate as one coordinated mechanical system. Hip, upper-leg, knee, and other actuator modules continuously interact through the robot body and the ground. Small timing differences between joint commands can influence balance, contact forces, gait stability, and dynamic response. EtherCAT provides a communication foundation capable of supporting these synchronized multi-axis control requirements.

The EtherCAT master is normally located in the robot\'s real-time computing domain. It generates cyclic communication frames according to the motion-control schedule and exchanges process data with distributed slave devices. Depending on the electrical architecture, slaves may include servo drives, joint controllers, force/torque interfaces, distributed I/O modules, or dedicated leg controllers. This creates a clear hierarchy between centralized motion coordination and distributed actuator execution.

Process Data Objects, commonly represented as PDOs, carry cyclic real-time information between the master and slave devices. In a quadruped, this information may include target position, velocity, torque, control mode, status words, measured joint position, actual velocity, torque feedback, current, and selected diagnostic states. Mapping only information required by the real-time control loop helps maintain efficient bandwidth utilization and predictable cycle execution.

Service Data Objects and mailbox-based communication support configuration, parameter access, diagnostics, and other non-cyclic functions. These mechanisms allow engineering software or the controller to access device parameters without treating every configuration value as cyclic process data. Separating time-critical motion information from lower-priority configuration and diagnostic exchanges is important for maintaining deterministic behavior during demanding locomotion.

Distributed Clocks are one of EtherCAT\'s most important capabilities for quadruped motion control. Individual slave devices contain local clocks that can be synchronized to a common reference with very small relative timing errors. This enables multiple actuator controllers to sample feedback or apply commands at closely aligned moments. Such synchronization is valuable when coordinating several legs during walking, trotting, running, stair traversal, or disturbance recovery.

Time synchronization should be considered across the complete robot rather than only within the EtherCAT network. Joint states may need to be correlated with IMU measurements, foot-force information, cameras, LiDAR, and higher-level state estimation. EtherCAT Distributed Clocks can provide precise timing within the motion network, while the computing architecture may use PTP or another synchronization mechanism to establish relationships with Ethernet-based perception and AI subsystems.

The communication cycle must be selected according to the control architecture. Faster cycles reduce the delay between command generation and actuator feedback but increase computational and network demands. The appropriate period depends on the number of axes, payload size, drive capabilities, controller execution time, and required motion bandwidth. The complete control loop should therefore be analyzed from sensor sampling through communication, computation, command transmission, and actuator response.

EtherCAT does not eliminate the need for local high-frequency servo loops. Motor current regulation and other fast inner-loop functions are normally executed directly inside the servo drive or joint controller. EtherCAT provides synchronized setpoints and feedback between these local controllers and the central real-time controller. This hierarchical approach allows the network to coordinate whole-body motion without requiring individual PWM or commutation operations to traverse the communication bus.

Topology flexibility is another useful characteristic. EtherCAT can support line, tree, star, and combinations of these structures using appropriate devices and interfaces. A quadruped architecture can therefore organize communication around the physical robot structure, such as a trunk network branching toward four leg assemblies. Nevertheless, topology should be designed deliberately because connectors, cable routing, redundancy strategy, serviceability, and failure propagation remain important system-level considerations.

The physical implementation typically uses industrial Ethernet cabling and compatible PHY interfaces. In a quadruped, however, conventional stationary-machine cabling assumptions are insufficient because leg movement creates continuous bending, torsion, vibration, and connector loading. Dynamic cable sections require appropriate flex-rated construction, controlled bend radius, strain relief, secure connector retention, and routing that minimizes repeated mechanical stress while preserving high-speed signal integrity.

Electromagnetic compatibility is particularly important because EtherCAT communication operates near high-power actuator electronics. Motor phase cables, inverters, switching converters, battery conductors, and braking currents can introduce significant electromagnetic disturbances. Cable shielding, grounding, connector termination, physical separation, return-current paths, and enclosure design should therefore be engineered as part of the communication system rather than treated as independent packaging details.

The EtherCAT master implementation must also be deterministic. A fast physical network cannot compensate for unpredictable software scheduling inside the controller. Real-time operating-system behavior, task priorities, interrupt handling, network driver architecture, CPU affinity, memory behavior, and motion-control execution time can all contribute to cycle jitter. Consequently, communication performance should be evaluated as an end-to-end real-time control path rather than solely by nominal network speed.

Working Counter mechanisms provide an important method for supervising whether expected EtherCAT operations have been successfully processed. The master can detect inconsistencies between expected and actual communication behavior and use this information as part of network health monitoring. In a quadruped, communication supervision should be connected to higher-level fault management so that missing or malfunctioning actuator nodes are recognized before they create uncontrolled mechanical behavior.

EtherCAT device state management provides controlled transitions through initialization and operational stages. This allows the system to verify communication and configuration before enabling full cyclic operation. For a quadruped, startup sequencing can coordinate power availability, controller initialization, drive configuration, sensor readiness, network synchronization, and actuator enable conditions. Motion should begin only after required communication participants have reached valid and explicitly verified operating states.

Failure handling must consider the mechanical consequences of losing a node or network segment. A communication failure affecting one joint can immediately influence the load distribution of an entire leg and potentially destabilize the robot. The controller therefore requires defined responses for communication timeout, invalid state, synchronization loss, or drive failure. Depending on the operating condition, the response may involve torque limitation, gait degradation, controlled posture transition, or safe stopping.

Safety-related communication should remain architecturally distinct from ordinary motion performance. EtherCAT can coexist with safety mechanisms and safety-oriented extensions, but the safety concept must define which functions require independent monitoring, safe-state transitions, emergency stopping, or redundant channels. Communication availability alone must never be interpreted as proof of safe actuator behavior. Safety supervision must consider command validity, actuator state, electrical isolation, and mechanical consequences together.

Diagnostics are essential because intermittent communication faults can be difficult to reproduce in a dynamically moving robot. Engineers should record link states, device states, cycle timing, synchronization errors, Working Counter behavior, lost frames, controller load, and relevant actuator faults. Correlating these records with gait phase, joint torque, vibration, temperature, and battery conditions can reveal whether a problem originates from software timing, electrical noise, connectors, or dynamic harness degradation.

Commissioning should verify both communication timing and physical implementation. Engineers can evaluate cyclic latency, jitter, synchronization accuracy, device-state transitions, fault recovery, and maximum network load while simultaneously inspecting cable integrity and signal quality. Validation should include static standing, repeated walking, rapid gait changes, high-torque maneuvers, external disturbances, connector movement, power transitions, and fault injection to expose weaknesses that may remain invisible during laboratory idle testing.

EtherCAT and CAN FD can serve complementary roles within the same quadruped. EtherCAT is particularly attractive for tightly synchronized multi-axis motion control, while CAN FD provides robust communication for power management, auxiliary controllers, diagnostics, and other distributed functions. Gigabit Ethernet can independently handle cameras, LiDAR, AI computing, and high-volume data. Gateways and the real-time computing architecture integrate these communication domains without forcing every subsystem onto one network.

This layered communication strategy follows the broader structure of the quadruped electrical architecture, where CAN FD, EtherCAT, Gigabit Ethernet, DDS/ROS 2, MQTT, and time synchronization are treated as separate but cooperating technologies. EtherCAT occupies the deterministic motion-network role, connecting real-time computation with distributed actuator control while higher-level networks support perception, Physical AI, fleet communication, diagnostics, and remote operation.

09.03. Gigabit Ethernet

Gigabit Ethernet provides a high-bandwidth communication backbone for quadruped robots, supporting data rates far beyond those normally required by actuator-oriented field buses. Within the communication architecture, it is primarily suited to perception sensors, AI computers, high-level controllers, data loggers, and gateways. Its role complements EtherCAT for deterministic motion control and CAN FD for robust distributed device communication.

Modern quadrupeds generate large amounts of information from cameras, LiDAR, depth sensors, navigation modules, and onboard computing systems. A single perception pipeline may continuously transfer images, point clouds, maps, localization results, and learned feature representations. Gigabit Ethernet provides sufficient bandwidth for these data flows while allowing multiple heterogeneous devices to communicate through a standardized networking infrastructure.

The nominal 1 Gbit/s link capacity of Gigabit Ethernet provides a useful foundation for robot sensor aggregation, although actual application throughput is lower because Ethernet, IP, transport protocols, and application messages introduce overhead. Network design should therefore be based on measured or worst-case traffic rather than nominal link speed alone. Simultaneous camera streams, LiDAR packets, logging traffic, and AI outputs can create significant transient bandwidth demand.

Unlike a shared CAN bus, switched Ethernet normally provides dedicated full-duplex links between endpoints and an Ethernet switch. A device can transmit and receive simultaneously without classical bus arbitration. This architecture improves aggregate bandwidth and allows traffic from several sensors or computers to coexist efficiently. For a quadruped, a central or distributed Ethernet switch can connect the perception computer, real-time controller, sensor modules, diagnostics interface, and external communication gateway.

Ethernet switching introduces an important architectural design point. Traffic from several input ports may converge on one output port, creating queueing and congestion even when individual links operate at 1 Gbit/s. Engineers must therefore examine traffic paths through the switch rather than simply counting device link speeds. High-volume camera or LiDAR streams should not unexpectedly compete with control, synchronization, diagnostics, or safety-related supervisory traffic.

Quality of Service, commonly called QoS, can classify and prioritize Ethernet traffic according to system requirements. Time-sensitive control or synchronization packets can receive higher priority than bulk logging, file transfer, or maintenance data. QoS does not automatically make conventional Ethernet deterministic, but careful traffic classification, switch configuration, queue management, and bandwidth reservation can substantially improve latency behavior under heavily loaded operating conditions.

The physical topology of a quadruped Ethernet network is commonly based on a star or hierarchical switched structure. A central switch in the trunk can connect major computing and perception devices, while additional local switches may serve distributed sensor groups when necessary. The topology should balance bandwidth, cable mass, connector count, fault containment, serviceability, and packaging constraints rather than simply minimizing the number of network components.

Perception sensors are natural Gigabit Ethernet endpoints. High-resolution cameras may transmit compressed or uncompressed image streams, while 3D LiDAR devices generate continuous point-cloud packets and associated metadata. Inspection payloads can introduce additional thermal, acoustic, visual, or specialized sensing data. Ethernet allows these devices to maintain independent data streams while the perception computer receives and combines them for localization, mapping, obstacle detection, and environment understanding.

The onboard AI computer also relies on Ethernet to exchange information with other computational domains. Perception results, object lists, terrain representations, local maps, trajectories, robot states, and mission commands can move between AI processing and real-time control without exposing every internal tensor or intermediate model representation to the network. Interface design should define compact and stable data contracts appropriate to each subsystem boundary.

DDS and ROS 2 can operate above the Ethernet infrastructure to provide software-level data distribution between robot applications. Gigabit Ethernet supplies the underlying packet transport, while DDS defines discovery, publication, subscription, reliability, durability, and other communication behavior. This separation is important because Ethernet itself does not define the semantic meaning of robot messages. Network engineering and middleware architecture must therefore be designed as related but distinct layers.

UDP is frequently attractive for high-rate sensor or real-time data because it introduces relatively low transport overhead and does not wait for retransmission of lost packets. TCP can be more appropriate for configuration, file transfer, software management, or information where reliable ordered delivery is more important than minimum latency. The protocol should be selected according to the behavior required by each data flow rather than applying one transport mechanism to every interface.

Packet loss must be interpreted differently according to application type. Losing an occasional camera or LiDAR packet may be manageable if the next measurement arrives immediately, whereas losing a configuration command or software package segment may require reliable retransmission. Robot communication design should explicitly define acceptable loss, latency, jitter, ordering, and recovery behavior for each interface so that application software does not depend on unspecified network assumptions.

Time synchronization is a critical function when Gigabit Ethernet connects multiple sensors and computers. Camera images, LiDAR scans, IMU measurements, actuator states, and state-estimation results must often be correlated to a common time reference. Precision Time Protocol, or PTP, can distribute time across compatible Ethernet devices, while hardware timestamping can reduce uncertainty introduced by software stacks and operating-system scheduling.

Accurate timestamps are particularly important during dynamic locomotion. A quadruped can rotate, translate, and experience rapid body motion while sensors acquire data at different locations and frequencies. Even small timing errors can appear as spatial errors when combining measurements. The communication architecture should therefore preserve timestamp provenance from sensor acquisition through transport and processing rather than simply assigning a new timestamp when a packet reaches the AI computer.

Gigabit Ethernet can also provide the communication path between the robot and service equipment during development and maintenance. Engineers can retrieve logs, inspect network states, configure software, access diagnostics, or transfer recorded datasets through a standard Ethernet interface. Separating maintenance traffic from operationally critical communication, either logically or physically, helps prevent large file transfers or debugging sessions from disturbing robot behavior.

Physical-layer engineering remains important despite Ethernet\'s widespread use in commercial computing. Quadrupeds expose cables and connectors to vibration, repeated mechanical movement, impact, contamination, and electromagnetic interference. Industrial or automotive-grade components may therefore be required depending on the operating environment. Connector retention, shielding, strain relief, cable flexibility, grounding, and ingress protection should be selected according to the robot\'s actual mechanical and environmental conditions.

Electromagnetic compatibility can become challenging when Gigabit Ethernet cables run near motor drives, phase conductors, DC-DC converters, battery wiring, and switching power electronics. Proper twisted-pair construction, shield termination, chassis bonding, connector design, cable separation, and routing help maintain signal integrity. EMC design should be verified under high actuator load because electrical noise can differ significantly between stationary laboratory operation and aggressive locomotion.

Network fault containment should be considered at both link and system levels. A disconnected sensor cable should not unnecessarily disable unrelated communication, while a malfunctioning device generating excessive traffic should not be allowed to congest the entire robot network. Managed switches can provide useful capabilities such as port statistics, VLAN segmentation, traffic monitoring, and fault isolation, depending on the complexity and reliability requirements of the platform.

Virtual LANs, or VLANs, can logically separate traffic classes while using shared physical switching infrastructure. Perception, control, diagnostics, maintenance, and external communication can be placed into defined network domains where appropriate. VLAN separation alone is not a safety mechanism, but it can improve network organization, reduce unintended traffic propagation, and support clearer interface boundaries between subsystems with different performance and operational requirements.

Redundancy may be introduced where communication availability justifies the additional switches, interfaces, cables, power consumption, and software complexity. Critical computing nodes can use multiple Ethernet interfaces or alternative paths, but redundancy must be analyzed as a complete architecture. Two network links provide limited benefit if both depend on the same switch, connector, power rail, or vulnerable harness section that represents a common point of failure.

Cybersecurity becomes increasingly relevant because Ethernet connects general-purpose computers, maintenance interfaces, wireless gateways, and potentially external networks. Network segmentation, authenticated services, restricted ports, secure update mechanisms, access control, and software hardening should prevent an external interface from providing unrestricted access to motion or safety-critical systems. The communication architecture should define trust boundaries between onboard control, service, fleet, cloud, and external devices.

Performance validation should measure actual throughput, end-to-end latency, jitter, packet loss, queue occupancy, switch behavior, and CPU/network-interface load under representative robot operation. Tests should combine multiple camera streams, LiDAR traffic, AI processing, logging, diagnostics, and external communication rather than evaluating each device independently. Stress testing can reveal congestion or scheduling interactions that remain hidden when individual interfaces are tested in isolation.

Gigabit Ethernet therefore occupies the high-bandwidth data-network role within the quadruped communication architecture. EtherCAT can provide tightly synchronized deterministic actuator communication, CAN FD can support power, auxiliary control, and diagnostics, while Gigabit Ethernet carries perception and computing traffic. DDS/ROS 2 and other middleware operate above these physical networks, and dedicated time synchronization establishes consistent temporal relationships across the complete robotic system.

09.04. DDS/ROS2

DDS and ROS 2 form the software communication layer that connects distributed applications across a quadruped robot's computing architecture. While CAN FD and EtherCAT primarily support embedded devices and deterministic actuator communication, and Gigabit Ethernet provides high-bandwidth transport, DDS and ROS 2 organize how software components discover each other, exchange typed data, and coordinate perception, control, planning, diagnostics, and system management.

ROS 2 uses a distributed communication model in which software functions are typically separated into nodes. A quadruped may contain nodes for cameras, LiDAR processing, IMU handling, state estimation, localization, terrain analysis, gait generation, motion planning, diagnostics, and mission execution. These nodes can execute on one computer or across multiple computers while communicating through standardized ROS 2 interfaces.

DDS, or Data Distribution Service, provides the data-centric publish-subscribe foundation commonly used beneath ROS 2. Instead of requiring every application to establish explicit point-to-point connections, publishers provide data associated with defined topics and subscribers receive the topics they require. This approach reduces direct software dependencies and makes it easier to distribute robot functions across heterogeneous computing resources.

The publish-subscribe model is particularly suitable for perception and robot-state information. A state-estimation node can publish the robot pose and velocity while locomotion, navigation, visualization, and logging nodes independently subscribe to the same information. Similarly, a perception pipeline can publish detected obstacles or terrain properties without needing detailed knowledge of every application that will consume those results.

ROS 2 topics provide asynchronous data streams for information that is continuously produced. Typical quadruped topics can include joint states, IMU measurements, point clouds, camera images, odometry, localization results, terrain maps, actuator temperatures, battery conditions, and diagnostic information. Message definitions establish a typed interface so that producers and consumers share a consistent representation of the transmitted information.

Services support request-response interactions where a node requests a specific operation and waits for a corresponding response. They are useful for operations such as retrieving configuration information, resetting a subsystem, requesting a diagnostic result, or changing a parameter when continuous streaming is unnecessary. Services should generally not replace cyclic control communication because their interaction model is different from continuous real-time data exchange.

ROS 2 actions support longer-running operations that require feedback, progress monitoring, and cancellation. A quadruped mission manager might use an action for navigation to a target location, autonomous docking, inspection execution, or a controlled posture transition. The action interface allows the requester to receive intermediate feedback and eventually determine whether the commanded operation succeeded, failed, or was canceled.

Quality of Service, or QoS, is one of the most important DDS capabilities exposed through ROS 2. Different robot data flows have different communication requirements, so reliability, history depth, durability, deadline, lifespan, and other policies can be configured according to the interface. Selecting QoS intentionally prevents every data stream from being treated as though it has identical timing, reliability, and storage requirements.

Reliable delivery can be appropriate for information that should not be silently lost, while best-effort communication may be preferable for high-frequency sensor streams where old data quickly loses value. For example, retransmitting an outdated perception sample can sometimes be less useful than receiving the newest measurement immediately. QoS should therefore reflect the physical meaning and timing requirements of each message rather than being selected only from software convenience.

DDS discovery allows distributed participants to identify publishers, subscribers, and compatible communication endpoints dynamically. This reduces the need for manually configured point-to-point connections and supports modular robot software. However, discovery itself creates network traffic and startup behavior that must be understood, especially when the quadruped contains multiple computers, numerous nodes, or constrained communication links.

The ROS Middleware interface, commonly called RMW, separates ROS 2 APIs from the underlying middleware implementation. This abstraction allows ROS 2 systems to use supported DDS or other compatible middleware implementations without rewriting application-level nodes. For a production quadruped, middleware selection should consider latency, resource consumption, discovery behavior, interoperability, tooling, platform support, and operational stability.

DDS/ROS 2 communication usually operates over the robot\'s Ethernet infrastructure. Gigabit Ethernet can transport high-volume perception and application traffic, while DDS defines how distributed software exchanges that information. This distinction is fundamental: Ethernet provides network connectivity and packet transport, whereas DDS/ROS 2 provides software-level communication semantics, interfaces, discovery, and configurable delivery behavior.

A quadruped should not use ROS 2 messaging as a substitute for every low-level actuator interface. Fast motor-current loops, commutation, and other tightly bounded servo functions belong inside local drives or deterministic control domains. EtherCAT can provide synchronized motion-network communication, while ROS 2 distributes higher-level states, commands, trajectories, planning results, and coordination information between computational applications.

This separation creates a hierarchical control architecture. Local motor controllers execute the fastest electrical and servo functions, the real-time controller coordinates joint and whole-body motion, and ROS 2 connects this control domain with perception, localization, planning, AI, diagnostics, and mission-level software. Clear boundaries prevent nondeterministic high-level software behavior from directly entering control loops that require strict timing guarantees.

ROS 2 executors influence when callbacks are processed inside each node or process. Subscription callbacks, timers, services, and other events may compete for CPU execution, so executor configuration can affect latency and jitter even when network communication is fast. Critical applications should therefore consider callback organization, thread allocation, priorities, CPU affinity, and interaction with the underlying operating system.

Large perception messages require special attention because serialization, memory copying, and transport can consume substantial CPU and memory bandwidth. High-resolution images and point clouds may move between multiple perception processes at high rates. Composition, shared-memory mechanisms, loaned messages, or other optimized transport techniques can reduce unnecessary copies where supported, but their behavior must be validated on the selected hardware and middleware stack.

Message architecture should avoid publishing raw data merely because network bandwidth is available. Interfaces between perception, AI, and control domains should expose information appropriate to the receiving subsystem. A motion controller may require terrain geometry, contact estimates, obstacle boundaries, or target trajectories rather than every intermediate neural-network feature. Stable semantic interfaces reduce coupling and make software evolution easier.

Namespaces and topic organization become increasingly important as the number of components grows. Consistent naming can distinguish sensors, legs, controllers, diagnostics, and robot-level information. In multi-robot deployments, namespaces can also separate individual quadrupeds while preserving common software structures. Interface conventions should be defined as part of the system architecture rather than independently by each development team.

Time information must remain consistent across DDS/ROS 2 applications. Messages from cameras, LiDAR, IMUs, joint controllers, and state estimators should carry meaningful timestamps tied to an understood time source. Ethernet-based PTP and hardware timestamping can provide the underlying synchronized time infrastructure, while ROS 2 messages preserve timestamps so software can correctly associate measurements originating from different devices and computational domains.

Diagnostics can be distributed through the same software architecture. Hardware drivers and application nodes can publish temperatures, communication states, resource utilization, sensor health, actuator conditions, software status, and fault information. A system-health component can aggregate these observations and determine whether the robot should continue normal operation, enter a degraded mode, request maintenance, or initiate an appropriate controlled response.

Lifecycle management is useful for coordinating complex robot startup and shutdown behavior. Components may need to be configured, activated, deactivated, cleaned up, or restarted in a controlled sequence. A quadruped should not begin autonomous locomotion simply because processes exist. Sensor readiness, localization validity, communication status, controller availability, synchronization, and safety conditions should be verified before operational functions are enabled.

Fault containment requires preventing a failed software component from destabilizing unrelated functions. A perception node crash, excessive publisher rate, malformed message, or overloaded logging process should not automatically compromise motion control. Process separation, resource limits, communication boundaries, watchdogs, health monitoring, and defined degraded modes help maintain system behavior when individual software components become unavailable.

Cybersecurity is important because DDS/ROS 2 may connect many applications across Ethernet and potentially through gateways to external networks. Authentication, access control, encrypted communication where appropriate, secure configuration, and network segmentation can restrict which participants are allowed to discover, publish, subscribe, or invoke services. Security design should follow the robot\'s trust boundaries rather than assuming every network participant is equally trusted.

Performance validation must evaluate the complete software communication path under realistic load. Engineers should measure message latency, jitter, throughput, packet loss, callback delay, CPU consumption, memory usage, discovery behavior, and recovery after node or network failures. Tests should combine perception streams, state estimation, planning, visualization, diagnostics, and logging because resource contention often appears only when the complete system operates simultaneously.

In the quadruped communication architecture, DDS/ROS 2 therefore provides the distributed software integration layer above the underlying communication networks. EtherCAT supports synchronized motion, CAN FD serves robust embedded and diagnostic communication, Gigabit Ethernet provides high-bandwidth transport, and DDS/ROS 2 connects perception, AI, planning, control, diagnostics, and mission applications through structured interfaces. Time synchronization then establishes a consistent temporal foundation across these layers.

09.05. MQTT

MQTT is a lightweight publish-subscribe messaging protocol designed for efficient communication between distributed devices, applications, gateways, and remote services. Within a quadruped communication architecture, MQTT is most appropriate above the real-time motion and embedded control layers, providing a practical interface for telemetry, fleet management, remote diagnostics, mission information, maintenance, and cloud connectivity.

Unlike EtherCAT or CAN FD, MQTT is not intended to execute deterministic joint control or high-frequency servo communication. It operates at a higher system level where information can tolerate network-dependent latency. A quadruped can therefore continue its local perception and motion functions independently while MQTT exchanges operational status, mission progress, health information, alerts, and management commands with external systems.

MQTT uses a broker-centered publish-subscribe architecture. Publishers send messages to named topics without needing to know which applications will consume them, while subscribers register interest in selected topics and receive matching messages through the broker. This decouples data producers from consumers in location, implementation, and timing, which is valuable when robots, fleet servers, maintenance tools, and cloud applications evolve independently.

The broker becomes the logical communication hub for MQTT traffic. A quadruped may connect to a broker through an onboard gateway, facility network, Wi-Fi, private wireless network, or another external communication path. The broker receives published messages, applies topic and session rules, and distributes them to appropriate subscribers. Broker placement should therefore reflect availability, cybersecurity, network reachability, and fleet architecture requirements.

Topics provide the hierarchical addressing structure used to organize MQTT information. A robot deployment can define topic paths that identify a robot, subsystem, and data category, allowing telemetry, battery information, diagnostics, mission status, environmental measurements, and maintenance events to remain logically separated. A consistent topic namespace becomes increasingly important when the system grows from one quadruped to an entire fleet.

Wildcards allow subscribers to receive groups of related topics without explicitly registering every individual path. A fleet monitoring service can subscribe to health information from multiple robots, while a maintenance application can focus on diagnostic topics associated with a specific robot or subsystem. Topic organization should nevertheless be controlled carefully because overly broad subscriptions can generate unnecessary traffic and increase processing load.

MQTT provides multiple Quality of Service levels to trade communication overhead against delivery assurance. QoS 0 attempts delivery without acknowledgement, QoS 1 provides at-least-once delivery, and QoS 2 provides exactly-once delivery through additional protocol exchanges. The appropriate level should be selected according to message meaning because increasing delivery assurance also increases communication traffic, processing, state management, and latency.

High-rate telemetry that is continuously refreshed may tolerate QoS 0 because a newer sample can quickly replace a lost message. Important alarms, maintenance events, or mission-state transitions may justify QoS 1 when delivery should be confirmed even if duplicate handling is required. QoS 2 should be reserved for cases where its stronger delivery semantics are genuinely necessary, rather than applying maximum reliability indiscriminately to all robot traffic.

Retained messages allow the broker to store the most recent retained value for a topic and immediately provide it to a new subscriber. This can be useful for information such as robot availability, operating mode, current mission state, or selected configuration indicators. However, retained data should represent state that remains meaningful over time; transient sensor samples or momentary events can become misleading if presented later as though they were current.

Persistent sessions can help clients maintain subscription and delivery state across temporary disconnections. This capability is useful for mobile robots because wireless connectivity may vary as a quadruped moves through buildings, industrial facilities, tunnels, outdoor areas, or infrastructure sites. The system should define which information must survive communication interruption and which high-rate data can simply resume from the newest value after reconnection.

The Last Will and Testament mechanism provides a useful indication of unexpected client disconnection. Before normal operation, a robot can configure a broker message that is published if its MQTT connection terminates abnormally. Fleet or monitoring software can use this information as one indication that communication with the robot has been lost, although connectivity loss should not automatically be interpreted as a robot hardware failure.

MQTT communication should remain separated from safety-critical local behavior. If connectivity to the broker, fleet server, or cloud disappears, the quadruped must still maintain the local functions necessary for safe operation. Motion stabilization, actuator control, obstacle response, emergency stopping, and essential health supervision should not depend on continuous MQTT connectivity. External communication loss should instead trigger a defined degraded or autonomous operating policy.

A gateway is often the appropriate boundary between MQTT and the internal robot networks. Internal CAN FD devices, EtherCAT actuator systems, sensors, and ROS 2 applications do not all need direct MQTT connections. A gateway or supervisory application can select relevant internal information, transform it into stable external messages, and publish it to the broker while converting authorized incoming MQTT commands into controlled internal requests.

This gateway boundary prevents external interfaces from exposing unnecessary internal implementation details. For example, a fleet system may need robot position, battery state, mission status, health summary, and availability rather than raw joint currents or every ROS 2 topic. Defining compact external data contracts reduces bandwidth consumption, limits coupling, simplifies version management, and protects internal software architecture from changes in remote applications.

ROS 2 and MQTT therefore serve different communication scopes. ROS 2 and DDS are suitable for distributed software interaction within the robot or a tightly integrated robotic system, whereas MQTT is particularly useful for loosely coupled communication with fleet, facility, service, and cloud applications. A bridge can selectively translate ROS 2 information into MQTT topics without treating MQTT as a replacement for the robot\'s internal software middleware.

Telemetry is one of the most natural MQTT applications. The quadruped can periodically publish battery state of charge, temperatures, network health, compute utilization, mission progress, localization quality, operating mode, and summarized actuator conditions. Remote systems can aggregate this information over time for dashboards, maintenance analysis, fleet supervision, operational statistics, and identification of developing reliability problems.

Event communication should be distinguished from periodic telemetry. A sudden actuator fault, thermal warning, localization failure, inspection detection, or mission transition may need to be published immediately rather than waiting for the next periodic status message. Event topics can therefore complement slower health summaries, allowing remote systems to respond quickly while avoiding continuous transmission of unnecessarily detailed internal information.

Mission-level communication can use MQTT for exchanging high-level requests and status when the architecture permits remote operation. A fleet system may assign an inspection destination, task identifier, or mission objective, while the robot publishes acceptance, execution state, progress, completion, or failure information. Detailed trajectory generation and balance control should remain onboard rather than being continuously commanded through a potentially variable external MQTT connection.

Payload representation should be selected according to interoperability, bandwidth, processing cost, and maintainability. Human-readable formats can simplify development and debugging, while compact binary representations may reduce message size for large fleets or constrained wireless links. Whatever representation is chosen, message schemas should be versioned and documented so that robot software, gateways, fleet systems, and cloud services can evolve without ambiguous interpretation.

Wireless communication introduces conditions very different from an internal wired robot network. Latency, available bandwidth, packet loss, roaming, temporary disconnection, and signal quality can change as the quadruped moves. MQTT\'s asynchronous messaging model is useful under these conditions, but application behavior must still explicitly handle stale information, delayed commands, duplicate messages, reconnection, and periods when no remote communication is available.

Cybersecurity is essential because MQTT may cross the boundary between the robot and external infrastructure. Transport encryption such as TLS, authenticated clients, broker authorization, certificate or credential management, and topic-level access policies can restrict communication to approved participants. A monitoring client that only requires telemetry should not automatically receive permission to publish commands capable of changing robot behavior.

Network segmentation should reinforce these trust boundaries. The external MQTT path can terminate at a gateway or controlled computing domain rather than directly exposing actuator or safety networks. Firewall policies, restricted ports, authenticated services, logging, and controlled routing can reduce the possibility that compromise of a cloud, wireless, or maintenance interface propagates directly into deterministic motion-control systems.

Fleet scalability should be considered from the beginning. As the number of robots increases, telemetry frequency, topic count, broker load, retained state, client connections, storage, and analytics traffic can grow rapidly. Publishing every internal signal from every robot is rarely efficient. Aggregation, event-driven reporting, adaptive rates, health summaries, and carefully selected telemetry can preserve useful fleet visibility without overwhelming communication and backend infrastructure.

Monitoring should include the MQTT communication system itself. Connection state, reconnect frequency, message rate, acknowledgement delay, queued messages, broker availability, rejected authentication attempts, and communication errors can reveal network or infrastructure problems. These observations should be correlated with robot operational logs so engineers can distinguish an onboard failure from a wireless, broker, gateway, or remote-service problem.

Validation should reproduce realistic connectivity conditions rather than testing only on a stable laboratory network. Engineers should evaluate normal operation, bandwidth reduction, latency variation, packet loss, broker restart, client restart, authentication failure, prolonged disconnection, reconnection, and duplicate delivery. The robot\'s behavior must remain predictable when MQTT becomes slow or unavailable, and queued information must not create unsafe or obsolete commands after connectivity returns.

Within the quadruped communication architecture, MQTT therefore occupies the fleet, remote-service, and cloud messaging layer. EtherCAT handles synchronized motion, CAN FD supports robust embedded communication, Gigabit Ethernet carries high-bandwidth onboard data, and DDS/ROS 2 integrates distributed robot software. MQTT extends selected information beyond these onboard domains, providing loosely coupled telemetry, fleet coordination, diagnostics, maintenance, and remote system integration.

09.06. Time Synchronization

Time synchronization establishes a common temporal reference across the distributed sensors, controllers, computers, and communication networks of a quadruped robot. Accurate timing is essential because perception, state estimation, locomotion, and diagnostics depend on measurements generated by different devices at different rates. Without a consistent time base, individually correct data can represent different physical moments and produce incorrect system-level interpretation.

A quadruped is particularly sensitive to timing because its body is continuously translating, rotating, accelerating, and interacting with the ground. Cameras, LiDAR, IMUs, joint encoders, torque sensors, and foot-force sensors observe this dynamic system from different locations. Even relatively small timestamp errors can become spatial, velocity, or contact-state errors when measurements are fused for localization, balance estimation, terrain understanding, or whole-body control.

The synchronization architecture should distinguish clock synchronization from data synchronization. Clock synchronization aligns the time bases maintained by distributed devices, while data synchronization associates measurements that correspond to compatible physical times. Accurate clocks make data association possible, but software must still account for sensor sampling periods, transport delay, processing latency, buffering, and different measurement frequencies when constructing synchronized datasets.

A common reference clock provides the temporal foundation of the robot. Other clocks are adjusted or interpreted relative to this reference so that timestamps from separate subsystems can be compared meaningfully. The reference should be selected according to system architecture, required accuracy, startup behavior, holdover requirements, and failure strategy. A change or loss of the reference clock must not silently create discontinuities that invalidate control or sensor-fusion calculations.

Precision Time Protocol, or PTP, is well suited to distributing precise time through the quadruped\'s Ethernet infrastructure. PTP exchanges timing messages between participating clocks and estimates the relationship between their local time bases. When supported by appropriate network hardware and timestamping mechanisms, it can provide significantly more precise synchronization than software-only clock adjustment methods intended primarily for general-purpose computing networks.

Hardware timestamping improves synchronization by recording packet timing close to the network interface rather than after the packet has passed through variable software processing. Operating-system scheduling, driver queues, interrupts, and application execution can introduce nondeterministic delays. Moving timestamp generation toward the Ethernet MAC or PHY reduces these uncertainties and provides a more stable basis for correlating measurements from multiple high-rate sensors and computers.

PTP-capable switches can support accurate time distribution through a switched Ethernet topology. Depending on the selected synchronization architecture, network elements can account for residence time or participate in clock distribution so that switch processing does not become an uncontrolled timing error. The synchronization capability of switches should therefore be treated as an architectural requirement when precise multi-device timing is required rather than assumed from ordinary Ethernet connectivity.

EtherCAT provides its own precise synchronization mechanism through Distributed Clocks. Slave devices can align local clocks and coordinate process-data timing across the deterministic motion network. This is particularly valuable for joint controllers because position, velocity, torque, and force information from multiple axes should correspond to closely aligned control instants. Coordinated timing improves the consistency of multi-leg motion and whole-body control calculations.

The robot may therefore contain more than one synchronization domain. EtherCAT Distributed Clocks can establish precise timing within the actuator network, while PTP distributes time across Ethernet-connected sensors and computers. The system architecture must define the relationship between these domains so that motion data and perception data can be correlated. Simply having two individually synchronized networks does not guarantee that their timestamps represent the same global time reference.

CAN FD devices also require a defined timing relationship even though CAN FD does not inherently provide the same clock-distribution capability as PTP or EtherCAT Distributed Clocks. Application messages can contain timestamps, counters, or synchronization information, and gateways can relate CAN FD data to the robot\'s common time domain. The required accuracy depends on whether the information represents slow diagnostics, power status, or time-sensitive actuator and sensor states.

Sensor timestamp provenance should be preserved from the instant of measurement. A timestamp created when a camera frame or LiDAR packet reaches the AI computer represents arrival time rather than acquisition time and may include variable transport delay. Whenever hardware permits, timestamps should be generated near the actual sensing event and carried through drivers, middleware, processing pipelines, logging systems, and downstream applications without losing their original temporal meaning.

Camera synchronization becomes important when multiple cameras observe a rapidly moving robot environment. Hardware triggering can align exposure times more accurately than independent software commands, while synchronized timestamps identify the acquisition instant of each image. Stereo vision, visual-inertial estimation, multi-camera perception, and high-speed inspection can all degrade when image exposures are separated by uncontrolled timing offsets despite otherwise accurate camera calibration.

LiDAR timing must similarly represent when individual scans or measurements were acquired. During rapid body rotation or translation, a point cloud can contain measurements collected over a finite scan interval rather than at one instantaneous pose. Motion compensation and sensor fusion therefore require accurate measurement timing together with robot pose estimates. Incorrect timestamps can distort reconstructed geometry even when range measurements themselves are accurate.

IMU timing is especially critical because inertial measurements are commonly used at relatively high rates and directly influence state estimation and stabilization. Gyroscope and accelerometer samples must be associated with accurate acquisition times so that integration and fusion with cameras, LiDAR, joint states, or GNSS remain consistent. Timing jitter or an unknown fixed offset can appear as estimation error and become more visible during aggressive locomotion.

Joint and foot-contact information also depends on timing consistency. Joint position, velocity, torque, and foot-force measurements describe the mechanical configuration and interaction state of the robot at specific instants. If these measurements are temporally misaligned, the controller or estimator can infer an incorrect body configuration or contact condition. This becomes particularly important during touchdown, liftoff, slipping, impact, or rapid gait transitions.

ROS 2 and DDS applications should preserve the synchronized timing established by the lower infrastructure. Messages can carry timestamps associated with their source measurements, allowing perception, state-estimation, planning, visualization, diagnostics, and logging applications to reconstruct temporal relationships. Middleware transport should not replace valid acquisition timestamps merely because a message passes through another node or computer.

The real-time controller must also maintain a clear relationship between communication time and control-cycle time. Sensor acquisition, state estimation, trajectory generation, EtherCAT exchange, and actuator application occur at different points within a control cycle. Deterministic scheduling and synchronized clocks allow engineers to define these timing relationships explicitly and measure end-to-end delay rather than treating all information received during one software iteration as simultaneous.

Synchronization accuracy and synchronization stability are separate engineering concerns. A system may temporarily achieve a very small clock offset while still exhibiting excessive jitter or drift over time. Performance should therefore be characterized using offset, jitter, drift, convergence time, and behavior during network disturbances. Requirements should be derived from the most timing-sensitive functions rather than selecting an arbitrary synchronization target for every subsystem.

Startup behavior must be defined because clocks may require time to discover a reference and converge to the required synchronization accuracy. Perception or locomotion functions that depend on synchronized data should not automatically become operational before timing validity has been established. System initialization can include synchronization status as an explicit readiness condition together with sensor availability, controller state, localization validity, and safety checks.

Loss of synchronization must be detectable. Devices or supervisory software should monitor clock offset, synchronization state, message timing, and other available health indicators. If timing quality exceeds defined limits, the system can reject affected sensor fusion, degrade autonomy, reduce motion performance, or transition to another controlled operating mode. Continuing to process precisely timestamped-looking data after synchronization has failed can be more dangerous than clearly declaring it invalid.

Clock discontinuities require special handling because a sudden time jump can violate assumptions made by filters, controllers, loggers, and timeout mechanisms. Synchronization algorithms should avoid uncontrolled changes where possible, and applications should be designed to recognize invalid or discontinuous time. Monotonic timing may be appropriate for measuring local durations, while synchronized system time is used for correlating events across distributed devices.

Diagnostics and event logging depend strongly on a common time base. Faults in a quadruped can propagate rapidly from electrical or communication events into mechanical behavior. Synchronizing logs from motor drives, controllers, sensors, AI computers, power systems, and gateways allows engineers to reconstruct the actual sequence of events. Without synchronized timestamps, determining whether a communication fault preceded or followed an actuator disturbance can become difficult.

Time synchronization also improves validation and performance analysis. Engineers can compare command generation, network transmission, sensor acquisition, state estimation, actuator response, and physical motion on one temporal axis. This enables accurate measurement of end-to-end latency and helps identify whether performance limitations originate in sensors, communication, software scheduling, computation, or actuator execution rather than relying only on average processing rates.

Redundancy and failure strategy should be considered when synchronization is critical to continued operation. A robot may require a defined response if its preferred reference clock disappears or a network path is interrupted. Depending on the architecture, another qualified clock may become the reference, local clocks may temporarily operate in holdover, or affected functions may enter a degraded mode. Reference transitions must be controlled and observable.

The complete synchronization design therefore spans hardware, networks, middleware, and applications. PTP and hardware timestamping can align Ethernet-connected computers and sensors, EtherCAT Distributed Clocks synchronize the motion-control domain, CAN FD information can be related through timestamps and gateways, and ROS 2 preserves temporal metadata across software components. These mechanisms together establish a coherent time architecture rather than independent device clocks.

Within the quadruped communication architecture, time synchronization consequently acts as a cross-cutting infrastructure connecting CAN FD, EtherCAT, Gigabit Ethernet, DDS/ROS 2, and higher-level communication functions. Its purpose is not merely to make clocks display the same value, but to ensure that sensing, computation, communication, control, diagnostics, and recorded events can all be interpreted on a consistent physical timeline across the complete robot.

---

Author: Richard Minsoo Go

LinkedIn: Richard Minsoo Go