Xenomai

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.

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.

32-bitowa architektura ARM w wersji ARMv7-A z rozszerzeniem Thumb-2 i sprzętową jednostką zmiennoprzecinkową (Hard Float – stąd oznaczenie armhf w dystrybucjach Debian/Ubuntu). Dominowała w embedded Linux i robotyce mobilnej przed upowszechnieniem się ARM64. Stosowana w: starszych Raspberry Pi (Pi 2 Model B: ARMv7, Pi 3 32-bit OS), BeagleBone Black (AM335x Cortex-A8), STM32MP1 (Cortex-A7 + Cortex-M4), starszych platformach robotycznych (TurtleBot 2, kobuki). Ograniczenia: maksymalnie 4 GB RAM adresowalnej, brak nowoczesnych rozszerzeń SIMD porównywalnych z AArch64 (NEON 64-bit vs NEON 128-bit w AArch64), malejące wsparcie w nowszych pakietach. ROS 2 Humble: armhf jest tier-3 (best-effort, bez gwarancji oficjalnych buildów). Większość nowoczesnych SDK robotycznych (Unitree SDK2, Isaac ROS) nie wspiera armhf. Relevantna dla: utrzymania starszych platform robotycznych (legacy support), bardzo ograniczone embedded SBC gdzie ARM64 niedostępne, mikrokontrolerów z Linux (Cortex-A klasy niskiej). Nowe projekty powinny targetować ARM64 zamiast ARMv7.

32-bitowa architektura Intel x86 (IA-32), historycznie dominująca w PC i embedded PC. W robotyce praktycznie wycofana z aktywnego wsparcia – ROS 2 nie dostarcza oficjalnych buildów dla i386, Ubuntu 23.04+ porzuciło wsparcie i386 jako architekturę hostową. Relevantna wyłącznie w kontekście: legacy industrial PC (IPC) z procesorami Atom N270/Z510 stosowanymi w starszych robotach przemysłowych, urządzeń SCADA i HMI z systemami Windows XP/7 32-bit w środowiskach przemysłowych wymagających integracji z nowszym oprogramowaniem robotycznym, symulatorów i emulatorów QEMU do testowania oprogramowania embedded na hostach 32-bit. ROS 1 Melodic był ostatnią dystrybucją z częściowym wsparciem i386. Praktycznie żaden nowoczesny SDK robotyczny (Unitree, Boston Dynamics, NVIDIA Isaac) nie wspiera x86 32-bit. Jeśli platforma wymaga obsługi 32-bitowych zasobów, nowoczesne x86_64 CPU obsługują kod 32-bit przez compatibility mode.

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.

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.

Rozszerzenie standardu CAN 2.0 zwiększające przepustowość do 8 Mbit/s i rozmiar ramki danych do 64 bajtów (vs 8 bajtów w CAN 2.0). Zachowuje wsteczną kompatybilność z CAN 2.0 na poziomie arbitrażu. Stosowany w nowoczesnych robotach humanoidalnych i manipulatorach wymagających szybkiej transmisji danych telemetrycznych z wielu stawów jednocześnie.

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).

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.

Controller Area Network Flexible Data-Rate – rozszerzenie CAN 2.0 zachowujące arbitraż przy 1 Mbit/s i zwiększające prędkość transmisji danych do 8 Mbit/s oraz rozmiar ramki do 64 bajtów. W robotyce humanoidalnej stosowany do szybkiej komunikacji między kontrolerem głównym a modułami stawowymi.

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.