QNX Neutrino RTOS

Dystrybucja prekompilowanych binarnych plików wykonywalnych lub bibliotek przez bezpośrednie pobieranie (wget, curl, instalator .sh, .exe, .pkg) ze strony producenta, bez pośrednictwa menedżera pakietów. Stosowane dla: komercyjnych SDK robotów bez publicznego menedżera pakietów, własnościowych komponentów oprogramowania przemysłowego, narzędzi standalone nie wymagających zarządzania zależnościami. Przykłady w robotyce: pobieranie instalatora ze strony producenta robota, skrypt bootstrap.sh SDK, archiwum .tar.gz z bibliotekami. Wady: brak automatycznych aktualizacji, brak zarządzania zależnościami, konieczność ręcznej weryfikacji integralności (checksum SHA256), ryzyko rozbieżności wersji między różnymi komponentami, trudność w zarządzaniu na flocie wielu robotów. Zalety: prostota dla dostawcy (nie wymaga integracji z menedżerem pakietów), pełna kontrola nad tym co i kiedy jest aktualizowane. Stosowane gdy producent sprzętu udostępnia SDK wyłącznie w tej formie (firmware tools, calibration software, proprietary middleware).

Mechanizm zdalnej aktualizacji oprogramowania na robotach w terenie bez fizycznego dostępu do urządzenia, przez sieć (Wi-Fi, 5G, Ethernet). Kluczowy element infrastruktury floty robotów produkcyjnych. Implementacje: Mender.io (open source OTA dla Linux embedded, obsługuje Yocto i Ubuntu Core), balena.io (kontenerowy OTA oparty na Docker), SWUpdate (open source, powszechny w Yocto/OpenEmbedded), RAUC (robust update framework), Ubuntu Core Snap Store (automatyczne aktualizacje snaps), AWS IoT Greengrass (OTA dla urządzeń edge), Azure IoT Hub Device Update. Wymagania dla OTA w robotyce: atomic updates (aktualizacja albo się powiodła w całości, albo nie – brak stanu pośredniego), A/B partition scheme (aktualizacja na nieaktywnej partycji, przełączenie po sukcesie), automatic rollback przy błędzie startu, delta updates (przesyłanie tylko zmian – ważne przy ograniczonym paśmie 4G/5G), cryptographic signing (weryfikacja integralności aktualizacji). Integralny element systemów zarządzania flotą AMR i humanoidów deployowanych w dużej skali.

Framework do budowania własnych dystrybucji Linux dla systemów embedded i robotycznych od podstaw. Nie jest menedżerem pakietów w klasycznym sensie – jest systemem tworzenia kompletnego obrazu systemu operacyjnego (BSP + kernel + rootfs + aplikacje) skrojonym pod konkretny hardware. Warstwy (layers) Yocto: meta-ros (oficjalna warstwa ROS 2 dla Yocto – umożliwia budowanie obrazu z ROS 2 dla dowolnego embedded hardware), meta-openembedded (dodatkowe biblioteki), meta-raspberrypi, meta-tegra (NVIDIA Jetson). BitBake: system budowania Yocto analizujący przepisy (recipes .bb) i budujący pakiety w prawidłowej kolejności. Stosowany przez: producentów robotów tworzących własny locked-down OS dla urządzeń produkcyjnych (deterministyczna, audytowalna wersja wszystkich komponentów), firmy wymagające certyfikacji oprogramowania (IEC 61508, ISO 26262 – pełna kontrola stosu), systemy wymagające minimalnego footprintu OS. Alternatywy: Buildroot (prostszy, mniej elastyczny), Debian/Ubuntu Core (łatwiejszy dostęp do pakietów). meta-ros umożliwia deployment ROS 2 Humble/Jazzy na niestandardowych platformach ARM/RISC-V niedostępnych w oficjalnych apt repos.

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.

Specjalizowana platforma obliczeniowa NVIDIA Jetson oparta na architekturze AArch64 z zintegrowanym GPU NVIDIA (architektura Ampere w Orin, Maxwell/Pascal/Volta w starszych modułach) i akceleratorem DLA (Deep Learning Accelerator). JetPack SDK: kompletny stack software dla Jetson obejmujący L4T (Linux for Tegra – Ubuntu-based OS), CUDA, cuDNN, TensorRT, VPI (Vision Programming Interface), Multimedia API. Moduły Jetson Orin: AGX Orin (12-core Cortex-A78AE, Ampere GPU 2048 CUDA cores, 64 GB RAM, TDP 15–60W), Orin NX 16GB (8-core, 1024 CUDA cores, 16 GB RAM, TDP 10–25W – używany w Unitree G1), Orin Nano (6-core, 1024 CUDA cores, 8 GB RAM, TDP 7–15W). Isaac ROS: oficjalne GPU-accelerated pakiety ROS 2 dla Jetson, dystrybuowane przez NVIDIA NGC Container Registry. Wsparcie ROS 2: tier-1 dla aarch64 Ubuntu 22.04 (Humble) i Ubuntu 24.04 (Jazzy) na JetPack 5.x/6.x. Kluczowa platforma dla robotyki z wymaganiami AI: perception pipeline (stereo depth, object detection, pose estimation), SLAM, VLA inference na edge. Przykłady wdrożeń: Unitree G1 (Orin NX 16GB jako high-level compute), Boston Dynamics (wybrane produkty), drony autonomiczne (Skydio), roboty AMR wymagające edge AI.

Platforma obliczeniowa Qualcomm Snapdragon oparta na AArch64 (własne rdzenie Kryo lub licencjonowane Cortex-A) z zintegrowanym GPU Adreno i NPU (Neural Processing Unit) Hexagon DSP. Wysoka wydajność AI na watt – przewaga nad NVIDIA Jetson przy zastosowaniach bateryjnych. Platformy robotyczne Qualcomm: Qualcomm Robotics RB5 (Snapdragon 865, Hexagon 698 DSP, 8 GB RAM), RB6 (Snapdragon 888, Hexagon 780), RB3 Gen 2 (Snapdragon 6490). Boston Dynamics Spot: Snapdragon jako główny procesor mobilny. Drony DJI (wybrane modele). Wsparcie oprogramowania: Qualcomm AI Stack (QNN – Qualcomm Neural Network SDK, SNPE – Snapdragon Neural Processing Engine), ROS 2 na Ubuntu for Snapdragon, OpenCV z Hexagon DSP acceleration. Hexagon DSP umożliwia inference modeli ML z bardzo niskim poborem energii (idle: mW, active: 1–5W). Ograniczenia: mniejszy ekosystem narzędzi deweloperskich niż NVIDIA Jetson, SNPE mniej popularny niż TensorRT, ograniczone wsparcie dla CUDA-only bibliotek. Rosnące wsparcie przez Qualcomm AI Hub (gotowe modele zoptymalizowane pod Snapdragon). Preferowana platforma w robotyce mobilnej (drony, roboty kołowe) gdzie priorytetem jest autonomia baterii.

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.

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.

Jeden z najstarszych i najszerzej stosowanych protokołów przemysłowych (Modicon, 1979). Modbus RTU działa przez RS-485/RS-232, Modbus TCP przez Ethernet. Stosowany w robotyce do komunikacji z starszą infrastrukturą przemysłową.

Standard komunikacji przemysłowej oparty na Ethernet, opracowany przez Siemens i zarządzany przez organizację PROFIBUS International. Dominuje w europejskich instalacjach automatyki. Obsługuje tryb RT (cykl 1–10 ms) i IRT (cykl < 1 ms).

Standard komunikacyjny IEC 62541 stosowany powszechnie w automatyce przemysłowej i Industry 4.0 do integracji robotów z systemami SCADA, MES i ERP. Definiuje model informacyjny, serwisy i mechanizmy bezpieczeństwa (PKI, szyfrowanie, signing).

Lekki protokół komunikacyjny publish-subscribe oparty na TCP/IP, zaprojektowany dla urządzeń IoT i systemów o ograniczonych zasobach. Stosowany w robotyce fleetowej i cloud robotics do telemetrii, monitoringu stanu floty i zdalnego zarządzania robotami AMR. Broker centralny (np. Mosquitto, AWS IoT Core) zarządza routingiem wiadomości między wydawcami a subskrybentami. MQTT 5.0 wprowadza session expiry, payload format indicator i flow control.

Zestaw standardów IEEE 802.1 rozszerzający Ethernet o deterministyczną transmisję z gwarantowanymi opóźnieniami i pasmem (IEEE 802.1Qbv, 802.1Qbu, 802.1AS). Stosowany w przemysłowych robotach wymagających synchronizacji wielu osi przez standardową sieć Ethernet bez dedykowanego okablowania EtherCAT.

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.

Protokół middleware stosowany w systemach automotive (AUTOSAR) do komunikacji usługowej (service-oriented) przez IP. Coraz częściej pojawia się w robotach przemysłowych i mobilnych wywodzących się ze środowisk automotive.

Standard middleware OMG (Object Management Group) oparty o model publish-subscribe, zaprojektowany dla systemów rozproszonych czasu rzeczywistego. Definiuje warstwę komunikacyjną DCPS (Data-Centric Publish-Subscribe) oraz protokół przewodowy RTPS (Real-Time Publish-Subscribe). Stosowany jako domyślna warstwa komunikacyjna w ROS 2 – każda implementacja ROS 2 opiera się na jednej z implementacji DDS (CycloneDDS, Fast DDS, Connext DDS). Obsługuje discovery, QoS, reliability, durability i liveliness.

Otwartoźródłowa implementacja DDS firmy eProsima, napisana w C++. Była domyślną implementacją DDS w ROS 2 przed dystrybucją Humble. Obsługuje RTPS, shared memory transport, security (DDS-Security), XML profile configuration. Szeroko stosowana w systemach robotycznych i automotive. Licencja Apache 2.0.

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.

Standard IEEE 802.3an – Ethernet 10 Gbit/s przez skrętkę Cat6a/Cat7, złącze RJ-45 lub SFP+. W robotyce stosowany w stacjach bazowych floty, serwerach edge computing i systemach wymagających przesyłu dużych map 3D.

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.

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

Universal Asynchronous Receiver-Transmitter w standardzie napięciowym RS-232 (±3V–±15V logika odwrócona). Standard fizycznej warstwy komunikacji szeregowej stosowany historycznie w robotyce przemysłowej. Typowe prędkości: 9600 – 115200 baud. Zasięg kabla do 15 m przy 9600 baud.

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.

Serial Peripheral Interface w klasycznej konfiguracji 4-przewodowej: MOSI, MISO, SCLK, CS (Chip Select). Synchroniczny, full-duplex protokół Master-Slave o prędkościach do 80 MHz. Stosowany do enkoderów absolutnych, przetworników ADC/DAC, wyświetlaczy OLED/TFT i modułów IMU.

Inter-Integrated Circuit – dwuprzewodowy synchroniczny protokół (SDA + SCL) w trybach Standard (100 kbit/s) i Fast (400 kbit/s). Magistrala wielomaster, wieloslave z adresowaniem 7-bit (128 adresów) lub 10-bit. Stosowany do czujników IMU, magnetometrów, barometrów i ekspanderów I/O.

General Purpose Input/Output – cyfrowe piny I/O w standardzie logicznym 3.3V LVTTL (Low-Voltage TTL). Dominujący standard GPIO w nowoczesnych SBC i modułach embedded (Raspberry Pi, NVIDIA Jetson, BeagleBone). Stosowany w robotyce do odczytu sygnałów cyfrowych z sensorów, sterowania przekaźnikami i sygnalizacji E-Stop.

Peripheral Component Interconnect Express 3.0 – standard magistrali wewnętrznej o przepustowości 8 GT/s na tor (lane): x1 = 985 MB/s, x4 = 3.94 GB/s, x16 = 15.75 GB/s. Stosowany w NVIDIA Jetson Orin NX (PCIe Gen3 x4 i x1) do podłączania M.2 NVMe SSD, kart Wi-Fi/5G i akceleratorów AI (Hailo-8).

Peripheral Component Interconnect Express 4.0 – przepustowość 16 GT/s na tor: x16 = 31.5 GB/s (dwukrotność PCIe 3.0). Dostępny w NVIDIA Jetson AGX Orin (PCIe Gen4 x8 i x16 przez złącze M.2 Key-M i PCIe slot). Stosowany do podłączania GPU inference, szybkich NVMe SSD i kart capture dla kamer przemysł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.

On Robot oznacza typ wdrożenia, w którym oprogramowanie działa bezpośrednio na robocie lub na jego pokładowym module obliczeniowym, np. komputerze przemysłowym, SBC lub platformie edge AI.

Edge oznacza typ wdrożenia, w którym oprogramowanie działa na lokalnym urządzeniu obliczeniowym, bramce, komputerze przemysłowym lub innym zasobie blisko robota i sensorów, bez konieczności przetwarzania w chmurze.

Hybrid oznacza typ wdrożenia łączący lokalne lub pokładowe uruchamianie komponentów z dodatkowymi usługami działającymi na edge lub w chmurze.