CoppeliaSim (dawniej V-REP)

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

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.

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.

Biblioteka asynchronicznej komunikacji sieciowej oferująca wysokopoziomowe wzorce komunikacyjne (pub-sub, push-pull, req-rep, dealer-router) bez centralnego brokera. Stosowana jako lekka alternatywa dla ROS.

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

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.

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.