LCM (Lightweight Communications and Marshalling)

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

Dystrybucja wyłącznie przez kod źródłowy z systemem budowania CMake lub ament_cmake (ROS 2 extension CMake). Użytkownik pobiera kod źródłowy (git clone lub tarball) i kompiluje lokalnie przez: 'cmake -B build && cmake --build build' (CMake) lub 'colcon build' (ament_cmake w workspace ROS 2). Stosowana gdy: pakiet nie jest dostępny w żadnym rejestrze binarnym, wymagana jest custom konfiguracja kompilacji (specyficzne flagi kompilatora, opcje cmake), oprogramowanie targetuje niestandardową platformę sprzętową (exotic embedded SoC), deweloper chce modyfikować kod źródłowy. Typowy workflow w ROS 2: vcstool importuje źródła do workspace/src, colcon build kompiluje. Wymaga zainstalowania wszystkich build dependencies (compilery, biblioteki systemowe) – rosdep automatyzuje instalację dependencies. Najdłuższy czas instalacji (kompilacja może trwać dziesiątki minut na embedded hardware), ale maksymalna kontrola i konfigurowalność. Standard dla pakietów ROS 2 niedostępnych jeszcze w apt lub wymagających niestandardowej kompilacji.

Oficjalny menedżer pakietów języka Python i rejestr PyPI (Python Package Index – pypi.org). Pakiety instalowane przez narzędzie pip ('pip install <package>') lub pip3 dla Pythona 3. Szeroko stosowany w ekosystemie robotycznym dla: bibliotek Pythona do komunikacji z SDK (Unitree Python SDK2 dostępne przez pip), wrapperów Pythona dla algorytmów (OpenCV Python: 'pip install opencv-python'), narzędzi deweloperskich (colcon, rosdep, vcstool instalowane przez pip). Obsługuje wirtualne środowiska (venv, virtualenv, conda) izolujące zależności między projektami. Format pakietów: wheel (.whl, binarne) i sdist (.tar.gz, source distribution wymagająca kompilacji). PyPI zawiera ponad 500,000 pakietów – największy ekosystem pakietów Python. Integracja z ROS 2: pakiety Python ROS 2 mogą być instalowane zarówno przez apt (ros-humble-rclpy) jak i pip, przy czym apt jest preferowany dla pakietów ROS 2 core. Wsparcie dla pinowania wersji przez requirements.txt i Pipfile. Ograniczenie: brak native obsługi zależności systemowych (C libraries) – rosdep uzupełnia tę lukę w ekosystemie ROS.

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

Wielojęzykowy menedżer pakietów i środowisk wirtualnych (Anaconda, Miniconda) obsługujący pakiety Python, R, C/C++ i inne. Pakiety conda zawierają prekompilowane binaria dla wielu platform (linux-64, linux-aarch64, osx-arm64, win-64). mamba: szybki reimplementacja conda w C++ z dramatycznie szybszym resolverem zależności. Rejestry: conda-forge (community-maintained, największy), defaults (Anaconda Inc.), bioconda, nvidia (pakiety CUDA przez conda). Zastosowania w robotyce AI/ML: środowiska dla trenowania modeli (PyTorch, TensorFlow, JAX z obsługą CUDA przez conda-forge), narzędzia analizy danych z robotów (pandas, numpy, matplotlib), Jupyter notebooks dla eksploracji danych sensorycznych. RoboStack: projekt dystrybuujący pakiety ROS 2 przez conda-forge (ros-humble-desktop przez 'conda install -c conda-forge ros-humble-desktop') – umożliwia instalację ROS 2 na macOS i Windows bez VM. Conda environments pozwalają na równoległe instalacje różnych wersji ROS i bibliotek ML bez konfliktów. Stosowany przy integracji stacku robotycznego z narzędziami data science.

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.

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.

Procesory Apple Silicon (M1, M2, M3, M4 i warianty Pro/Max/Ultra) oparte na architekturze AArch64 (ARMv8.5-A+), stosowane w MacBook, Mac mini, Mac Studio i Mac Pro od 2020 r. Platforma deweloperska rosnącego znaczenia w ekosystemie robotycznym – wielu deweloperów ROS 2 używa MacBooków z Apple Silicon. Wsparcie ROS 2: tier-3 (community supported) dla macOS, ROS 2 Humble i Jazzy można zainstalować przez: Homebrew ('brew install ros-humble' przez tap), RoboStack (conda-forge – najwygodniejsza metoda: 'conda install -c conda-forge ros-humble-desktop'), budowanie ze źródeł przez colcon. RoboStack/conda-forge jest rekomendowaną metodą instalacji ROS 2 na Apple Silicon macOS. Apple Silicon: unified memory architecture (CPU, GPU i Neural Engine współdzielą pamięć), Metal GPU API (brak CUDA – wymaga PyTorch z Metal Performance Shaders backend), Core ML / Apple Neural Engine dla inference. Ograniczenia: brak wsparcia CUDA (biblioteki NVIDIA CUDA-only nie działają natywnie), Rosetta 2 umożliwia uruchomienie x86_64 binary ale bez pełnej wydajności, niektóre pakiety ROS 2 wymagają patchowania dla macOS. Gazebo/Ignition: dostępne na macOS ARM64. Zastosowanie: deweloperzy piszący i testujący kod ROS 2, symulacje, narzędzia CLI – nie deployment na robot.

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.

Biblioteka komunikacyjna i serializacji danych opracowana przez MIT CSAIL, zaprojektowana dla robotyki wymagającej wysokiej wydajności przy niskiej latencji. Stosowany przez Boston Dynamics (Spot, Atlas).

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

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.

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

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.

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.

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.

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.

Specjalna klasa deterministyczna – latencja i jitter ściśle zdefiniowane przez protokół komunikacyjny, niezależnie od wartości bezwzględnej. Kluczowa jest przewidywalność (predictability) i brak losowych skoków latencji. Protokoły: EtherCAT (jitter < 1 µs), PROFINET IRT (jitter < 1 µs), TSN IEEE 802.1Qbv (jitter < 100 ns), CAN bus (deterministyczny arbitraż). Stosowany gdy ważniejsza jest powtarzalność timingu niż minimalna latencja – np. synchronizacja wielu osi w manipulatorze.

Local Workstation oznacza typ wdrożenia, w którym software działa na komputerze lokalnym użytkownika, dewelopera lub operatora, np. laptopie, desktopie lub stacji roboczej.

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.