PREEMPT_RT

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

Oficjalny menedżer pakietów systemu Debian i jego pochodnych (Ubuntu, Linux Mint, Raspberry Pi OS, NVIDIA JetPack OS). Pakiety w formacie .deb instalowane przez narzędzia apt, apt-get lub dpkg. Dominujący sposób dystrybucji oprogramowania robotycznego w ekosystemie ROS – wszystkie oficjalne pakiety ROS 1 i ROS 2 są dystrybucowane przez apt z repozytorium packages.ros.org. Instalacja pakietu ROS 2: 'sudo apt install ros-humble-<package-name>'. Zarządzanie zależnościami automatyczne przez rosdep (ROS dependency manager) korzystający z apt jako backend dla platform Ubuntu/Debian. Pakiety binarne prekompilowane dla konkretnej architektury (x86_64, aarch64, arm32) i wersji Ubuntu – brak konieczności kompilacji ze źródeł. Repozytoria PPA (Personal Package Archive) umożliwiają dystrybucję własnych pakietów deb przez Launchpad (Ubuntu) bez konieczności włączenia do oficjalnego rejestru. Stosowany na NVIDIA Jetson (JetPack oparty na Ubuntu), Raspberry Pi OS i większości platform Linux używanych w robotyce. Wymaga systemu operacyjnego z rodziny Debian.

Dostępne wyłącznie jako kod źródłowy do 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.

Otwarta architektura zestawu instrukcji (ISA) RISC-V w wersji 64-bitowej z rozszerzeniami G (IMAFD – Integer, Multiply, Atomic, Float, Double) i C (Compressed instructions). Pierwsza w pełni otwarta architektura ISA bez opłat licencyjnych, rozwijana przez RISC-V International. Rosnące znaczenie w robotyce jako alternatywa dla ARM i x86 wolna od opłat licencyjnych i ograniczeń eksportowych. Platformy RISC-V w robotyce: SiFive HiFive Unmatched (FU740, quad-core RV64GC), StarFive VisionFive 2 (JH7110, quad-core RV64GC z GPU IMG BXE-4-32 – pierwsza przystępna cenowo płyta RISC-V z GPU), Milk-V Pioneer/Mars, Kendryte K210 (dual-core RV64 – popularny w edge AI). Wsparcie oprogramowania: Ubuntu 23.10+ oficjalnie wspiera riscv64, Debian wspiera riscv64, ROS 2 nie ma oficjalnych tier-1 buildów dla riscv64 (community builds dostępne). Wsparcie Rust dla riscv64gc-unknown-linux-gnu jest tier-2. Rosnące wsparcie toolchainów: GCC, LLVM/Clang, OpenCV, TensorFlow Lite. Bariery adopcji w robotyce: brak wydajnych SoC z wbudowanym NPU dla edge AI, ograniczona dostępność sterowników dla sensorów robotycznych, malejące ale nadal istniejące luki ekosystemowe. Perspektywa: RISC-V może stać się istotną architekturą w robotyce w latach 2025–2030 przy rosnącym wsparciu Linuksa i kluczowych bibliotek.

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.

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.

Standard synchronizacji czasu w sieci Ethernet (IEEE 1588-2008, PTPv2) zapewniający precyzję synchronizacji poniżej 1 µs w sieciach LAN. Niezbędny w systemach wielorobotowych i wielosensorycznych.

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.

Universal Asynchronous Receiver-Transmitter w standardzie różnicowym RS-485 (EIA-485). Obsługuje magistralę wielopunktową do 32 urządzeń, zasięg do 1200 m, prędkości do 10 Mbit/s. W robotyce stosowany do sieci czujników rozproszonych i komunikacji Dynamixel Protocol 2.0.

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.