IgH EtherCAT Master

Menedżer pakietów Debian/Ubuntu – apt-get install.

Dystrybucja wyłącznie przez kod źródłowy z systemem budowania CMake lub ament_cmake (ROS 2 extension CMake). Użytkownik pobiera kod źródłowy (git clone lub tarball) i kompiluje lokalnie przez: 'cmake -B build && cmake --build build' (CMake) lub 'colcon build' (ament_cmake w workspace ROS 2). Stosowana gdy: pakiet nie jest dostępny w żadnym rejestrze binarnym, wymagana jest custom konfiguracja kompilacji (specyficzne flagi kompilatora, opcje cmake), oprogramowanie targetuje niestandardową platformę sprzętową (exotic embedded SoC), deweloper chce modyfikować kod źródłowy. Typowy workflow w ROS 2: vcstool importuje źródła do workspace/src, colcon build kompiluje. Wymaga zainstalowania wszystkich build dependencies (compilery, biblioteki systemowe) – rosdep automatyzuje instalację dependencies. Najdłuższy czas instalacji (kompilacja może trwać dziesiątki minut na embedded hardware), ale maksymalna kontrola i konfigurowalność. Standard dla pakietów ROS 2 niedostępnych jeszcze w apt lub wymagających niestandardowej kompilacji.

Mechanizm dystrybucji oprogramowania przez GitHub Releases – binarne artefakty (skompilowane pliki wykonywalne, biblioteki, archiwia .tar.gz, .zip, pakiety .deb, .rpm, obrazy Docker) dołączane do tagowanych wydań GitHub. GitHub Actions Artifacts: tymczasowe artefakty budowania przechowywane przez ograniczony czas (90 dni domyślnie). Stosowane w robotyce dla: SDK robotów bez własnej infrastruktury dystrybucji (pobranie .deb lub tarball z GitHub Releases), gotowych binarnych buildów dla konkretnych platform (ROS 2 pre-built dla Raspberry Pi aarch64 przez GitHub Actions), narzędzi CLI i aplikacji standalone. GitHub Container Registry (ghcr.io): hosting obrazów Docker w ramach GitHub – alternatywa dla Docker Hub zintegrowana z GitHub Actions. Automatyzacja: GitHub Actions workflow budujący i publikujący release przy każdym tagu (np. 'on: push: tags: v*'). Ograniczenia: brak zarządzania zależnościami (użytkownik musi samodzielnie zainstalować dependencies), brak automatycznych aktualizacji, wymaga ręcznego pobierania nowych wersji (chyba że używany instalator lub package manager pobiera z GitHub Releases API).

64-bitowa architektura procesora wywodząca się z rodziny x86, opracowana przez AMD (jako AMD64) i zaadoptowana przez Intel (jako Intel 64 / EM64T). Dominująca architektura w komputerach osobistych, serwerach, stacjach roboczych i komputerach przemysłowych. W robotyce stosowana jako główna platforma obliczeniowa dla: stacji operatorskich i komputerów deweloperskich (Ubuntu 22.04/24.04 x86_64), serwerów fleet management i cloud robotics, symulatorów (Gazebo, Isaac Sim wymagają x86_64 z GPU NVIDIA dla pełnej wydajności), komputerów pokładowych robotów mobilnych wyższej klasy (Intel NUC, mini-PC przemysłowe jak Nuvo, OnLogic). Oficjalne wsparcie ROS 2 dla x86_64 jest tier-1 – wszystkie dystrybucje ROS 2 (Humble, Jazzy, Kilted) są w pełni wspierane i testowane. Pakiety apt dostępne przez packages.ros.org dla Ubuntu x86_64. Dominuje w środowiskach deweloperskich i symulacyjnych. Na robotach mobilnych i humanoidach x86_64 jest stosowane gdy wymagana jest wysoka moc obliczeniowa (np. Intel Core Ultra, AMD Ryzen Embedded) bez ograniczeń energetycznych typowych dla ARM. Przykłady hardware: Intel NUC 13 Pro, AMD Ryzen Embedded V2000, Advantech MIC-770.

64-bitowa architektura ARM (Advanced RISC Machine) w wersji ARMv8-A i nowszych – dominująca architektura w embedded computing, robotyce mobilnej i edge AI. Dwie nazwy oznaczają to samo: ARM64 (nazwa stosowana przez Apple i w kontekście macOS/iOS), AArch64 (oficjalna nazwa architektury ARM, używana w Linuksie i ekosystemie embedded). Absolutnie dominująca architektura w nowoczesnej robotyce mobilnej i humanoidalnej: NVIDIA Jetson (Orin NX, AGX Orin – Cortex-A78AE), Raspberry Pi 4/5 (Cortex-A72/A76), Qualcomm Robotics RB5/RB6 (Kryo), Apple M1/M2/M3 (dla stacji deweloperskich macOS), procesory w smartfonach używanych jako moduły robotyczne. Oficjalne wsparcie ROS 2 tier-1 dla aarch64 od dystrybucji Humble – pakiety apt dostępne przez packages.ros.org dla Ubuntu 22.04/24.04 aarch64. Unitree SDK2 dostępne dla aarch64 (target: Jetson Orin NX w G1). Boston Dynamics Spot: Qualcomm aarch64. Zalety wobec x86_64: znacznie niższy pobór energii (TDP 5–65W vs 45–125W), lepsza wydajność na wat, wbudowane NPU/GPU dla edge AI, mniejszy footprint fizyczny. Ograniczenia: historycznie mniejsza dostępność prebuildowanych pakietów (szybko zmniejsza się), niektóre biblioteki x86-only nie są portowane.

ARM 64-bit – NVIDIA Jetson, Raspberry Pi 4/5, Apple Silicon.

Deterministyczny protokół komunikacji przemysłowej oparty na Ethernet, opracowany przez Beckhoff Automation, zarządzany przez organizację ETG (EtherCAT Technology Group). Używa standardowych ramek Ethernet przetwarzanych w locie przez węzły slave (on-the-fly processing), co zapewnia cykle komunikacyjne poniżej 100 µs przy synchronizacji rozproszonych osi. Stosowany powszechnie w napędach stawowych robotów humanoidalnych (np. Boston Dynamics, Agility Robotics), manipulatorach przemysłowych i systemach motion control wymagających hard real-time.

Standardowy protokół sieciowy IEEE 802.3 z TCP/IP jako warstwą transportową. Stosowany jako główny interfejs komunikacji między komputerem nadrzędnym (host PC) a robotem w SDK takich jak Unitree SDK2, Boston Dynamics API, Universal Robots URScript. Nie zapewnia deterministyczności (best-effort delivery).

Szeregowy protokół komunikacyjny opracowany przez Bosch, powszechnie stosowany w robotyce mobilnej, quadrupedach i dronach do komunikacji między kontrolerami silników, ESC i MCU. Obsługuje prędkości do 1 Mbit/s (CAN 2.0) lub do 5+ Mbit/s (CAN FD). Cechuje go bardzo niska latencja, odporność na zakłócenia elektromagnetyczne i deterministyczny arbitraż wiadomości. Używany m.in. w robotach Unitree (G1, H1) do komunikacji z modułami stawowymi w trybie low-level.

Standard IEEE 802.3ab – Ethernet 1 Gbit/s przez skrętkę Cat5e/Cat6, złącze RJ-45. Dominujący interfejs sieciowy w robotyce: komunikacja SDK-robot (Unitree SDK2, Boston Dynamics API, UR e-Series), przesyłanie obrazów z kamer IP, integracja z ROS 2 przez DDS/RTPS.

Standard IEEE 802.3u – Ethernet 100 Mbit/s przez skrętkę (Cat5 i wyżej), złącze RJ-45. W robotyce stosowany jako legacy interfejs w starszych robotach przemysłowych (KUKA KR C2, Fanuc R-J3), PLC i urządzeniach embedded niskiej klasy.

Interfejs EtherCAT po stronie urządzenia slave – każdy slave zawiera dedykowany ASIC ESC (EtherCAT Slave Controller), np. ET1100 (Beckhoff), LAN9252 (Microchip). ESC przetwarza ramki Ethernet w locie (on-the-fly) bez buforowania – minimalna latencja ~300 ns na węzeł.

Controller Area Network 2.0 – standardowy protokół CAN zdefiniowany przez Bosch (1991). CAN 2.0A obsługuje 11-bitowe identyfikatory ramek, CAN 2.0B (Extended) – 29-bitowe. Prędkości do 1 Mbit/s. Standard de facto w robotach kroczących i kołowych.

Najwyższa klasa latencji – deterministyczne czasy odpowiedzi poniżej 1 ms z gwarancją dotrzymania deadline'ów bez żadnych wyjątków. Przekroczenie terminu jest traktowane jako błąd krytyczny systemu (system failure). Realizowane wyłącznie na dedykowanych systemach operacyjnych czasu rzeczywistego (RTOS): VxWorks, QNX Neutrino, LynxOS, RTEMS, Zephyr RTOS lub jądrze Linux z łatką RT-PREEMPT. Typowe zastosowania: kontrola prądów silników BLDC/PMSM (10–100 kHz), synchronizacja enkoderów absolutnych, safety-critical E-Stop. Odpowiednik TRL 9 w deterministyczności.

Deterministyczna klasa latencji 1–5 ms z twardą gwarancją dotrzymania deadline'ów. Realizowane na RTOS lub Linux RT-PREEMPT z izolacją CPU. Typowe cykle: 1 ms (1 kHz) dla pętli prędkości silników, 2 ms (500 Hz) dla pętli pozycji stawów, 5 ms (200 Hz) dla pętli sił i momentów. Komunikacja przez EtherCAT, CAN FD. Zastosowania: pętle regulacji prędkości w manipulatorach przemysłowych, sterowanie stawami robotów humanoidalnych w trybie low-level.