VxWorks

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.

Rodzina mikrokontrolerów STMicroelectronics STM32 oparta na rdzeniach ARM Cortex-M (M0, M0+, M3, M4F, M7, M33, M55) – dominująca platforma MCU w embedded firmware robotycznym. Nie uruchamia systemu operacyjnego Linux – oprogramowanie wykonywane bare-metal lub na RTOS (FreeRTOS, Zephyr, ChibiOS, Mbed OS). Zastosowania w robotyce: kontrolery silników BLDC/PMSM (FOC – Field Oriented Control) z pętlą regulacji prądu 10–100 kHz, sterowniki stawów robotów (Dynamixel SDK wewnętrznie używa STM32), interfejsy sensorów (IMU, enkodery absolutne, czujniki siły/momentu), kontrolery bezpieczeństwa (safety monitor, E-Stop), elektronika power management. Popularne serie: STM32F4 (Cortex-M4F, 168 MHz – standard w robotyce), STM32G4 (Cortex-M4F, 170 MHz, CAN FD – nowa generacja dla kontrolerów silników), STM32H7 (Cortex-M7, 480 MHz – wymagające aplikacje DSP/control), STM32U5 (Cortex-M33, ultra-low power – IoT robotics). Środowiska programistyczne: STM32CubeIDE, PlatformIO, Arduino framework dla STM32 (community). Integracja z ROS 2: micro-ROS na STM32 przez FreeRTOS (oficjalnie wspierane – STM32 jest platformą referencyjną micro-ROS), Zephyr RTOS + micro-ROS. Programowanie i debugging: ST-LINK/V3, J-Link przez SWD/JTAG.

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

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.

Joint Test Action Group (IEEE 1149.1) – interfejs do programowania i debugowania układów cyfrowych (MCU, FPGA, SoC). W robotyce stosowany do flashowania firmware kontrolerów silników i debugowania oprogramowania embedded.

Serial Wire Debug – dwuprzewodowy alternatywny interfejs debugowania dla procesorów ARM Cortex-M. Standard de facto w programowaniu i debugowaniu mikrokontrolerów ARM w robotyce: STM32, nRF52, RP2040.

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.