Webots

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

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

Platforma konteneryzacji Docker i publiczny rejestr obrazów Docker Hub (hub.docker.com). Kontenery Docker zapewniają izolację środowiska uruchomieniowego – oprogramowanie i wszystkie jego zależności spakowane w przenośny obraz działający identycznie na dowolnym hoście Linux z Docker Engine. Kluczowe zastosowania w robotyce: dystrybucja gotowych środowisk ROS 2 (oficjalne obrazy: ros:humble, ros:jazzy na Docker Hub, utrzymywane przez Open Robotics), NVIDIA NGC Container Registry (nvcr.io) z obrazami NVIDIA Isaac ROS zawierającymi prekompilowane pakiety GPU-accelerated dla Jetson, dystrybucja złożonych stosów oprogramowania z wieloma zależnościami bez ryzyka konfliktów, CI/CD pipeline'y testujące oprogramowanie robotyczne w izolowanym środowisku. Oficjalne obrazy ROS: 'docker pull ros:humble-ros-base' (minimalny), 'ros:humble-desktop' (pełny z RViz2). NVIDIA Isaac ROS: 'nvcr.io/nvidia/isaac/ros' z obsługą GPU na Jetson AGX Orin. Docker Compose umożliwia orkiestrację wielu kontenerów (robot controller + navigation stack + perception pipeline). Ograniczenia w robotyce: dostęp do hardware (GPIO, CAN, EtherCAT) wymaga konfiguracji '--device' lub '--privileged', real-time scheduling wymaga specjalnej konfiguracji host kernel, GUI (RViz2, Gazebo) wymaga przekazania X11 lub Wayland.

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

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.

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.

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.

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.

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

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.

Klasa latencji zmiennej, silnie zależnej od obciążenia systemu i złożoności zadania. Brak deterministyczności – latencja może się różnić rzędami wielkości. Typowa dla systemów AI: VLA (czas zależy od złożoności sceny), LLM-based task planners (zależy od długości kontekstu), object detection z dynamicznym rozmiarem obrazu, SLAM z adaptacyjną rozdzielczością. Wymaga architektury tolerującej zmienność (async, kolejki, graceful degradation).

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.

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.

Cloud oznacza typ wdrożenia, w którym oprogramowanie działa w infrastrukturze chmurowej, np. jako usługa backendowa, narzędzie orkiestracyjne, system analityczny lub zdalna warstwa zarządzająca.