rs_driver to niskopoziomowa, przenośna biblioteka C++14 opracowana przez RoboSense Technology i udostępniona na licencji BSD-3-Clause. Stanowi rdzeń całego ekosystemu RoboSense SDK — na jej bazie zbudowany jest rslidar_sdk (wrapper ROS/ROS 2) oraz rs_perception i inne produkty percepcyjne firmy.
Biblioteka działa bez żadnych zależności zewnętrznych poza standardową biblioteką C++ i opcjonalnie libpcap (do odtwarzania plików .pcap). Odbiera pakiety MSOP i DIFOP przez UDP, dekoduje je do wewnętrznej reprezentacji chmury punktów (LidarPointCloudMsg) i przekazuje przez callback do warstwy wyższej. Obsługuje modele: RS-LiDAR-16, RS-LiDAR-32, RS-Helios-16P, RS-Helios-5515, RS-Bpearl, RS-Ruby, RS-Ruby Plus, RS-LiDAR-M1, RS-LiDAR-M2, RS-LiDAR-M3, RS-LiDAR-E1.
Konfiguracja odbywa się przez strukturę RSDriverParam przekazywaną w kodzie lub przez plik YAML (gdy używany jest rslidar_sdk). Parametry obejmują: adres IP/port czujnika, tryb powrotu (single/dual), kompensację ruchu, synchronizację czasu (GPS $GPRMC + 1PPS lub PTP IEEE 1588), kąty wykluczenia FOV oraz zewnętrzne pliki kalibracyjne.
rs_driver jest używany bezpośrednio w projektach bez warstwy ROS (autonomiczne pojazdy, systemy wbudowane, aplikacje C++ na Jetson). Może być dołączony przez CMake FetchContent lub jako git submodule. rslidar_sdk, rs_perception i inne pakiety RoboSense zależą od tej biblioteki jako od submodułu.
SDK (Software Development Kit) to zestaw bibliotek, interfejsów, narzędzi i dokumentacji przeznaczonych do tworzenia aplikacji oraz integracji z konkretnym sprzętem, platformą lub usługą. W robotyce SDK często udostępnia dostęp do sterowania urządzeniem, telemetrii, sensorów, konfiguracji i funkcji wykonawczych.
Driver to warstwa oprogramowania odpowiedzialna za komunikację z konkretnym urządzeniem lub komponentem sprzętowym. W robotyce sterowniki umożliwiają obsługę sensorów, kamer, manipulatorów, napędów i innych modułów na poziomie sprzętowym lub niskopoziomowym.
Perception oznacza rolę oprogramowania przetwarzającego dane z kamer, LiDAR-ów, IMU i innych sensorów w celu wykrywania obiektów, rozpoznawania sceny, lokalizacji, mapowania i interpretacji środowiska.
Device Integration oznacza rolę oprogramowania odpowiedzialnego za komunikację, konfigurację, inicjalizację i obsługę konkretnych urządzeń, sensorów, kontrolerów lub komponentów sprzętowych w systemie robotycznym.
GitHub: ~400+ gwiazdek (RoboSense-LiDAR/rs_driver); submoduł rslidar_sdk i rs_perception
C++ to język programowania szeroko wykorzystywany w robotyce, systemach embedded, middleware, sterowaniu i przetwarzaniu danych, szczególnie tam, gdzie istotna jest wydajność oraz bliska integracja ze sprzętem.
Ubuntu 20.04 LTS to długoterminowo wspierana wersja systemu Linux, szeroko wykorzystywana w robotyce, systemach embedded, AI i środowiskach developerskich. Jest popularna m.in. w środowiskach ROS oraz na platformach obliczeniowych takich jak NVIDIA Jetson.
Ubuntu 22.04 LTS to długoterminowo wspierana wersja systemu Linux wykorzystywana w robotyce, AI, systemach edge i środowiskach programistycznych. Stanowi popularną bazę dla nowszych stosów oprogramowania oraz dystrybucji ROS 2.
Ubuntu 24.04 LTS 'Noble Numbat' — wspierane do kwietnia 2029. Host dla ROS 2 Jazzy.
Debian to jedna z najbardziej stabilnych i powszechnie stosowanych dystrybucji Linux, wykorzystywana jako baza dla wielu systemów embedded, robotycznych i serwerowych.
JetPack Linux oznacza środowisko systemowe i software'owe dla platform NVIDIA Jetson, wykorzystywane do uruchamiania aplikacji AI, computer vision i robotyki edge. W praktyce bazuje na Linuxie i pakietach NVIDIA dla Jetson.
Windows to rodzina systemów operacyjnych Microsoft wykorzystywana w środowiskach desktopowych, developerskich i integracyjnych. W robotyce występuje głównie jako środowisko narzędziowe, konfiguracyjne lub developerskie.
macOS to system operacyjny Apple wykorzystywany głównie na stacjach roboczych i laptopach deweloperskich do budowy, testowania i integracji oprogramowania.
Karta sieciowa Ethernet 100 Mbps lub Gigabit; opcjonalnie libpcap do odtwarzania .pcap.
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).
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.
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.
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 synchronizacji czasu w sieci Ethernet (IEEE 1588-2008, PTPv2) zapewniający precyzję synchronizacji poniżej 1 µs w sieciach LAN. Niezbędny w systemach wielorobotowych i wielosensorycznych.
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.
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.
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.
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.
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.
Rodzina licencji: Licencja permisywna
Licencja BSD z trzema klauzulami – rozszerza BSD 2-Clause o trzeci warunek zakazujący używania nazwy organizacji ani nazwisk kontrybutorów do promocji produktów pochodnych bez pisemnej zgody (non-endorsement clause). Zwana też 'New BSD License' lub 'Modified BSD License'.
Oficjalna licencja Unitree SDK2 i Unitree Python SDK2. Powszechna w pakietach ROS 2 i bibliotekach robotycznych. Klauzula non-endorsement chroni reputację oryginalnych twórców przed nieuprawnioną asocjacją z produktami pochodnymi. Praktycznie identyczna z MIT pod względem swobody użytkowania.
