Ubuntu Core

System pakietów snap opracowany przez Canonical (twórca Ubuntu) – samodzielne, skompresowane pakiety zawierające aplikację i wszystkie jej zależności w izolowanym środowisku (sandbox). Instalacja przez snapd: 'snap install <package>'. Działają na wielu dystrybucjach Linux (Ubuntu, Debian, Fedora, Arch) bez modyfikacji. Automatyczne aktualizacje w tle z rollback w przypadku problemów. Zastosowania w robotyce: dystrybucja narzędzi deweloperskich i aplikacji desktopowych (RViz2, Gazebo mogłyby być dystrybuowane jako snap), oprogramowanie dla robotów edge działających na Ubuntu Core (minimalne Ubuntu dla embedded). Ubuntu Core (IoT/embedded wariant Ubuntu) używa wyłącznie snaps – potencjalnie ważny dla robotów produkcyjnych opartych na Ubuntu Core z aktualizacjami OTA przez Snap Store. Canonical Snapcraft Store obsługuje kanały (stable, candidate, beta, edge) umożliwiając stopniowe rollout aktualizacji na flotę robotów. Ograniczenia: izolacja sandbox może utrudniać dostęp do hardware i komunikację między procesami – wymaga explict plugs/slots konfiguracji.

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.

Mechanizm dystrybucji oprogramowania przez GitHub Releases – binarne artefakty (skompilowane pliki wykonywalne, biblioteki, archiwia .tar.gz, .zip, pakiety .deb, .rpm, obrazy Docker) dołączane do tagowanych wydań GitHub. GitHub Actions Artifacts: tymczasowe artefakty budowania przechowywane przez ograniczony czas (90 dni domyślnie). Stosowane w robotyce dla: SDK robotów bez własnej infrastruktury dystrybucji (pobranie .deb lub tarball z GitHub Releases), gotowych binarnych buildów dla konkretnych platform (ROS 2 pre-built dla Raspberry Pi aarch64 przez GitHub Actions), narzędzi CLI i aplikacji standalone. GitHub Container Registry (ghcr.io): hosting obrazów Docker w ramach GitHub – alternatywa dla Docker Hub zintegrowana z GitHub Actions. Automatyzacja: GitHub Actions workflow budujący i publikujący release przy każdym tagu (np. 'on: push: tags: v*'). Ograniczenia: brak zarządzania zależnościami (użytkownik musi samodzielnie zainstalować dependencies), brak automatycznych aktualizacji, wymaga ręcznego pobierania nowych wersji (chyba że używany instalator lub package manager pobiera z GitHub Releases API).

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.

Platforma Raspberry Pi oparta na procesorach Broadcom (BCM) z architekturą AArch64: Raspberry Pi 4 Model B (BCM2711, quad-core Cortex-A72, do 8 GB RAM), Raspberry Pi 5 (BCM2712, quad-core Cortex-A76, do 8 GB RAM, 2–3× szybszy niż Pi 4), Raspberry Pi Compute Module 4/5 (wersje do integracji w custom hardware robotycznym). Raspberry Pi OS (64-bit) oparty na Debian Bookworm dla AArch64. Wsparcie ROS 2: tier-3 (community supported) dla Raspberry Pi OS, tier-1 dla Ubuntu 22.04/24.04 zainstalowanego na Raspberry Pi 4/5. Powszechnie stosowane w: edukacyjnych robotach mobilnych (TurtleBot 4 używa Raspberry Pi 4 jako komputer pokładowy), prototypach robotów AMR, robotach kroczących hobby (PicoBot, Hexapod na Pi), drone autopilots (ArduPilot na Pi), systemach wizyjnych (Pi Camera Module 3, HQ Camera przez MIPI CSI-2). Raspberry Pi 5 z PCIe 2.0 przez HAT+ connector umożliwia podłączenie M.2 NVMe SSD i akceleratorów AI (Hailo-8L – 13 TOPS). Ograniczenia wobec Jetson: brak dedykowanego GPU dla CUDA, brak wbudowanego NPU (poza Hailo zewnętrznym), 4K video processing bez sprzętowej akceleracji AI. Idealny dla: prototypowania, edukacji, robotów mobilnych niższej klasy, aplikacji niewymagających ciężkiego inference AI.

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

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.

Wariant protokołu MQTT zoptymalizowany dla sieci sensorowych bez TCP/IP, działający bezpośrednio na UDP, Zigbee lub Bluetooth LE. Stosowany w embedded węzłach robotycznych o bardzo niskim poborze energii. Obsługuje tryb uśpienia (sleep mode) dla urządzeń bateryjnych i skrócone identyfikatory tematów (topic aliases).

Wysokowydajny framework RPC oparty na HTTP/2 i Protocol Buffers, opracowany przez Google. Stosowany w cloud robotics i mikroserwisowej architekturze systemów zarządzania flotami (fleet management). Obsługuje dwukierunkowe streaming, flow control i multipleksowanie połączeń. Używany m.in. w ekosystemie NVIDIA Isaac jako interfejs między serwisami AI a kontrolerem robota oraz w niektórych implementacjach ROS 2 bridge do zewnętrznych serwisów chmurowych.

Architektura komunikacji usługowej oparta na protokole HTTP z semantyką zasobów (GET, POST, PUT, DELETE, PATCH). Stosowana w cloud robotics i fleet management. Nie nadaje się do sterowania real-time.

Protokół komunikacyjny full-duplex oparty na TCP, standaryzowany przez IETF (RFC 6455). Stosowany w robotyce do integracji przeglądarek i aplikacji webowych z systemami robotycznymi: rosbridge_suite implementuje protokół rosbridge v2.0 przez WebSocket.

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.

Standard bezprzewodowej komunikacji sieciowej IEEE 802.11. W robotyce mobilnej (AMR, humanoidalny) używany jako główny kanał komunikacji bezprzewodowej. Latencja typowo 5–30 ms, co wyklucza zastosowania hard real-time.

Standard bezprzewodowej komunikacji krótkiego zasięgu. Bluetooth Classic do 3 Mbit/s, BLE do 2 Mbit/s przy bardzo niskim poborze energii. W robotyce stosowany do kontrolerów ręcznych, konfiguracji i debugowania urządzeń embedded.

Standard radiowy 5G New Radio (3GPP Release 15+) oferujący latencję poniżej 10 ms (URLLC), przepustowość do kilku Gbit/s i masową łączność urządzeń. W robotyce stosowany do teleoperacji i fleet management.

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.3bz – Ethernet 2.5 Gbit/s przez skrętkę Cat5e/Cat6, złącze RJ-45. Stosowany w nowoczesnych robotach wymagających wyższego pasma niż 1 GbE przy zachowaniu kompatybilności z istniejącym okablowaniem Cat5e. Spotykany w modułach NVIDIA Jetson Orin NX i AGX Orin.

Universal Serial Bus 2.0 – standard połączeń peryferyjnych o przepustowości do 480 Mbit/s (High-Speed). W robotyce używany do podłączania kamer RGB (webcams), prostych IMU, modułów GPS, konwerterów USB-UART i urządzeń HID (kontrolery, joysticki). Zasilanie przez magistralę: 5V / 500 mA (USB 2.0). Obsługiwany przez praktycznie wszystkie SBC i moduły obliczeniowe stosowane w robotyce. Sterowniki dostępne natywnie w Linux kernel (usbcore, usb-storage, cdc_acm).

Universal Serial Bus 3.0 (przemianowany na USB 3.1 Gen 1) – standard o przepustowości do 5 Gbit/s (SuperSpeed). Powszechnie stosowany w robotyce do kamer głębi (Intel RealSense D435i, D455), kamer stereo i skanerów 3D wymagających wysokiego pasma dla strumieni depth + RGB. Zasilanie: 5V / 900 mA. Złącza: Type-A, Type-B, Micro-B, Type-C. NVIDIA Jetson AGX Orin posiada 4 porty USB 3.1 Gen 1.

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.

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.

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.

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.

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.

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.

Mobile Industry Processor Interface Camera Serial Interface 2 – dedykowany interfejs kamer stosowany w modułach embedded (NVIDIA Jetson: 6 portów CSI-2). Obsługuje prędkości do 4.5 Gbit/s na tor. Dominujący interfejs kamer w robotach korzystających z modułów Jetson.

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.

Klasa miękkiego czasu rzeczywistego 100–500 ms – odpowiedź w granicach setek milisekund wymagana dla płynnej pracy, ale przekroczenia nie powodują awarii. Zastosowania: task planning (Nav2 planner: 100–300 ms), rozpoznawanie gestów i mowy dla HRI, przetwarzanie obrazów (YOLO na GPU: 20–100 ms), feedback wizualny. Większość oprogramowania komercyjnego dla AMR i robotów usługowych operuje w tej klasie.

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.

Containerized oznacza typ wdrożenia, w którym oprogramowanie jest pakowane i uruchamiane w kontenerach, np. Docker lub innych technologiach konteneryzacji, co ułatwia przenoszenie, replikację i zarządzanie zależnościami.

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.