OpenRTM-aist

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

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.

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.

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

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.

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.

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.

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.

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.

Deterministyczna klasa latencji 5–20 ms – twardy real-time dla pętli zewnętrznych sterowania robotycznego. Cykle 5–20 ms (50–200 Hz). Możliwy na Linux RT-PREEMPT bez pełnego RTOS. Zastosowania: pętla pozycji i impedancji w cobotach (Universal Robots e-Series), sterowanie trajectoriami w manipulatorach (ros2_control JointTrajectoryController przy 100 Hz), pętla równowagi w robotach humanoidalnych. Wystarczający dla większości zastosowań sterowania ruchem.

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.

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.

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.