Helix 02

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.

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

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.

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.

Architektura obliczeniowa NVIDIA CUDA (Compute Unified Device Architecture) na platformie x86_64 – GPU NVIDIA jako koprocesor dla równoległych obliczeń. Nie jest samodzielną architekturą CPU, lecz dodatkowym wymaganiem sprzętowym dla oprogramowania korzystającego z akceleracji GPU. W robotyce kluczowa dla: trenowania modeli foundation i VLA (NVIDIA A100, H100, RTX 4090 na x86_64 serwerach/stacjach), inference modeli AI w symulatora (Isaac Sim wymaga CUDA GPU na x86_64), perception pipeline z akceleracją GPU (CUDA-accelerated stereo depth, optical flow, object detection), generowania syntetycznych datasetów (Omniverse Replicator). Wymagania: CUDA Toolkit (12.x dla najnowszych modeli), cuDNN, TensorRT dla optymalizowanego inference. NVIDIA Isaac ROS na x86_64 wymaga GPU NVIDIA z CUDA 12.x. Frameworki ML: PyTorch (CUDA backend), TensorFlow (CUDA/cuDNN), JAX (XLA + CUDA). Specyficzne wersje CUDA wymagane przez konkretne oprogramowanie – np. Isaac Sim 4.x wymaga CUDA 12.3+. Ograniczenia: wysokie wymagania energetyczne (GPU klasy datacenter: 300–700W), koszty sprzętu, brak mobilności. Środowisko deweloperskie i treningowe, nie deployment na robocie.

Mechanizm asynchronicznej komunikacji publish-subscribe w ROS 2, zbudowany na warstwie DDS/RTPS. Węzły publikują wiadomości na nazwanych topicach (np. /joint_states, /cmd_vel, /camera/image_raw), a inne węzły subskrybują te topici bez wiedzy o nadawcy. Obsługuje QoS policies (reliability, durability, history, deadline, lifespan). Podstawowy mechanizm wymiany danych sensorycznych, stanu robota i komend sterowania w ekosystemie ROS 2.

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.

Mechanizm IPC oparty na współdzielonym obszarze pamięci między procesami na tym samym hoście. Stosowany w robotyce jako ultra-low-latency transport dla dużych danych. Latencje poniżej 1 µs.

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.

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.

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.

Klasa miękkiego czasu rzeczywistego 20–100 ms – deadline'y wymagane statystycznie, sporadyczne przekroczenia akceptowalne. Realizowany na standardowym Linux z priorytetem SCHED_FIFO. Komunikacja przez Ethernet GbE, DDS/RTPS, ROS 2 topics. Zastosowania: nawigacja AMR (Nav2: 20–50 Hz), high-level sterowanie humanoidów (Unitree SDK2: 50 Hz), planowanie trajektorii (MoveIt 2 servo), integracja sensorów (LiDAR SLAM: 10–20 Hz). Wystarczający dla większości algorytmów nawigacyjnych i SLAM.

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.