micro-ROS

Oficjalne narzędzie budowania (build tool) ekosystemu ROS 2 zastępujące catkin_make i catkin_tools z ROS 1. colcon (COLlective CONstruction) buduje workspace zawierający wiele pakietów ROS 2 w prawidłowej kolejności zależności. Instalacja przez pip: 'pip install colcon-common-extensions'. Komendy: 'colcon build' (budowanie workspace), 'colcon test' (uruchomienie testów), 'colcon build --packages-select <pkg>' (budowanie wybranego pakietu), 'colcon build --symlink-install' (szybszy development – symlinki zamiast kopiowania). Obsługuje pakiety CMake (ament_cmake), Python (ament_python) i inne systemy budowania. Integracja z CI/CD: GitHub Actions, GitLab CI używają colcon do budowania i testowania pakietów ROS 2. Nie jest menedżerem pakietów w sensie dystrybucji – jest narzędziem kompilacji lokalnego workspace. Kluczowe rozszerzenia: colcon-mixin (predefiniowane konfiguracje build), colcon-cd (nawigacja do pakietu), colcon-argcomplete (autocomplete). Wymagany do budowania pakietów ROS 2 ze źródeł gdy apt nie zawiera potrzebnej wersji.

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.

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.

Rodzina mikrokontrolerów STMicroelectronics STM32 oparta na rdzeniach ARM Cortex-M (M0, M0+, M3, M4F, M7, M33, M55) – dominująca platforma MCU w embedded firmware robotycznym. Nie uruchamia systemu operacyjnego Linux – oprogramowanie wykonywane bare-metal lub na RTOS (FreeRTOS, Zephyr, ChibiOS, Mbed OS). Zastosowania w robotyce: kontrolery silników BLDC/PMSM (FOC – Field Oriented Control) z pętlą regulacji prądu 10–100 kHz, sterowniki stawów robotów (Dynamixel SDK wewnętrznie używa STM32), interfejsy sensorów (IMU, enkodery absolutne, czujniki siły/momentu), kontrolery bezpieczeństwa (safety monitor, E-Stop), elektronika power management. Popularne serie: STM32F4 (Cortex-M4F, 168 MHz – standard w robotyce), STM32G4 (Cortex-M4F, 170 MHz, CAN FD – nowa generacja dla kontrolerów silników), STM32H7 (Cortex-M7, 480 MHz – wymagające aplikacje DSP/control), STM32U5 (Cortex-M33, ultra-low power – IoT robotics). Środowiska programistyczne: STM32CubeIDE, PlatformIO, Arduino framework dla STM32 (community). Integracja z ROS 2: micro-ROS na STM32 przez FreeRTOS (oficjalnie wspierane – STM32 jest platformą referencyjną micro-ROS), Zephyr RTOS + micro-ROS. Programowanie i debugging: ST-LINK/V3, J-Link przez SWD/JTAG.

Rodzina mikrokontrolerów Espressif Systems ESP32 z wbudowanym Wi-Fi i Bluetooth – najpopularniejsza platforma embedded w projektach robotycznych hobby, edukacyjnych i niskokosztowych wdrożeniach produkcyjnych. Warianty architektury: ESP32 oryginalne (Xtensa LX6, dual-core 240 MHz), ESP32-S2/S3 (Xtensa LX7 – S3: dual-core 240 MHz z AI accelerator), ESP32-C3/C6/H2 (RISC-V single-core – tańsza alternatywa z Wi-Fi 6). ESP32-S3 z AI accelerator: wsparcie dla TensorFlow Lite Micro (inference prostych modeli ML bezpośrednio na MCU). Wi-Fi/Bluetooth wbudowane: ESP32 jest standardową platformą dla bezprzewodowych węzłów sensorycznych i aktuatorowych w robotyce. Zastosowania w robotyce: tanie kontrolery robotów mobilnych (ESP32 + TB6612FNG do sterowania silnikami DC), węzły IoT telemetrii (wysyłanie danych sensorycznych przez MQTT/Wi-Fi), kontrolery peryferiów robotów (oświetlenie RGB, serwomechanizmy, małe DC motors), prototypy robotów hobby. Integracja z ROS 2: micro-ROS na ESP32 przez FreeRTOS – oficjalnie wspierane, aktywne community. Programowanie: ESP-IDF (native SDK), Arduino framework (espressif32 platform), PlatformIO, MicroPython, CircuitPython. Ograniczenia: brak FPU hardware w ESP32 original i C3 (S3 i nowsze mają FPU), ograniczona pamięć RAM (520 KB SRAM w oryginale, 512 KB w C3, 512 KB + 8 MB PSRAM w S3 WROOM-2).

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.

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.

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.

Standard OMG definiujący protokół komunikacyjny DDS dla urządzeń embedded o bardzo ograniczonych zasobach, działający w architekturze klient-agent. Używany przez micro-ROS jako warstwa transportowa.

Framework umożliwiający uruchamianie węzłów ROS 2 bezpośrednio na mikrokontrolerach (STM32, ESP32, Raspberry Pi Pico, Renesas RA) z użyciem RTOS (FreeRTOS, Zephyr, NuttX). Używa micro-XRCE-DDS jako warstwy komunikacyjnej przez micro-ROS Agent działający na hoście Linux.

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.

Prosty asynchroniczny protokół komunikacji szeregowej punkt-punkt, powszechnie stosowany do komunikacji między mikrocontrollerami a modułami peryferyjnymi: IMU, GPS, moduły radiowe, konwertery. Typowe prędkości: 9600 – 921600 baud.

Szeregowy protokół komunikacyjny opracowany przez Bosch, powszechnie stosowany w robotyce mobilnej, quadrupedach i dronach do komunikacji między kontrolerami silników, ESC i MCU. Obsługuje prędkości do 1 Mbit/s (CAN 2.0) lub do 5+ Mbit/s (CAN FD). Cechuje go bardzo niska latencja, odporność na zakłócenia elektromagnetyczne i deterministyczny arbitraż wiadomości. Używany m.in. w robotach Unitree (G1, H1) do komunikacji z modułami stawowymi w trybie low-level.

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

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.

Universal Asynchronous Receiver-Transmitter w standardzie logicznym TTL (3.3V lub 5V) – najprostszy wariant UART, komunikacja punkt-punkt. Stosowany powszechnie w robotyce embedded: komunikacja MCU z modułami GPS, Bluetooth, modułami radiowymi i debug console.

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

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.

Controller Area Network Flexible Data-Rate – rozszerzenie CAN 2.0 zachowujące arbitraż przy 1 Mbit/s i zwiększające prędkość transmisji danych do 8 Mbit/s oraz rozmiar ramki do 64 bajtów. W robotyce humanoidalnej stosowany do szybkiej komunikacji między kontrolerem głównym a modułami stawowymi.

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.

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.

Najwyższa klasa latencji – deterministyczne czasy odpowiedzi poniżej 1 ms z gwarancją dotrzymania deadline'ów bez żadnych wyjątków. Przekroczenie terminu jest traktowane jako błąd krytyczny systemu (system failure). Realizowane wyłącznie na dedykowanych systemach operacyjnych czasu rzeczywistego (RTOS): VxWorks, QNX Neutrino, LynxOS, RTEMS, Zephyr RTOS lub jądrze Linux z łatką RT-PREEMPT. Typowe zastosowania: kontrola prądów silników BLDC/PMSM (10–100 kHz), synchronizacja enkoderów absolutnych, safety-critical E-Stop. Odpowiednik TRL 9 w deterministyczności.

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.

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.