Genie Sim 3.0 to wysokowierna platforma symulacyjna od AgiBot Innovation (Shanghai) Technology Co., Ltd. dla embodied AI. Stanowi kompletny toolchain do rekonstrukcji środowisk, generalizacji scen, zbierania danych i automatycznej ewaluacji modeli robotyki. Centralnym modułem jest Genie Sim Benchmark — standaryzowane narzędzie do najbardziej autorytatywnej ewaluacji embodied intelligence.
Platforma integruje rekonstrukcję 3D (3D Gaussian Splatting, 3DGS) z generatywnym modelem wizualnym, tworząc wysokowierne środowisko symulacyjne z precyzyjnymi siatkami (meshes). Pionierska technologia oparta na LLM pozwala wygenerować w ciągu minut ogromne ilości scen symulacyjnych i konfiguracji ewaluacyjnych. System ewaluacji obejmuje ponad 200 zadań w ponad 100 000 scenariuszy, tworząc kompleksowy profil zdolności modeli. Genie Sim udostępnia także dataset syntetyczny obejmujący ponad 10 000 godzin operacji robotycznych w środowisku zbliżonym do rzeczywistego.
Wersja 3.0 (7 stycznia 2026) wprowadziła: aktualizację Isaac Sim do v5.1.0 i wsparcie kart graficznych RTX serii 50, pliki USD i URDF dla robota AgiBot Genie G2 z whole body control, rekonstrukcję scen opartą na 3DGS z konwersją do formatu USD dla Isaac Sim, syntetyczny dataset wraz z pipelinem zbierania danych, oraz funkcje oparte na LLM do generowania scenariuszy, instrukcji zadań i konfiguracji ewaluacyjnych. Update v3.1 (8 kwietnia 2026) dodał Genie Sim World — multimodalny model przestrzenny generujący foto-realistyczne światy 3D z różnych typów wejścia w ciągu minut, nowe benchmarki dla podążania za instrukcjami i rozumienia przestrzennego, oraz integrację z RLinf (human-in-the-loop + distributed RL).
Genie Sim 3.0 zawiera cztery rodziny benchmarków: GenieSim-Instruction (10 zadań podążania za instrukcjami), GenieSim-Robust (12 wymiarów generalizacji — oświetlenie, tło, szum kamery, opóźnienie sterowania), GenieSim-Manipulation (10 zadań manipulacyjnych), GenieSim-Sim2Real (8 zadań porównujących wydajność sim-to-sim, real-to-sim, sim-to-real, real-to-real). Modele referencyjne testowane na platformie: π0.5 (lider), GR00T-N1.6, π0. Rozbieżność między wynikami symulacji a rzeczywistości jest mniejsza niż 10%.
Cała platforma — assety symulacyjne, dataset oraz kod źródłowy — jest w pełni open-source. Kod w katalogach source/geniesim oraz source/data_collection jest dostępny na licencji Mozilla Public License 2.0. Repozytorium AgibotTech/genie_sim w GitHub ma 1000+ gwiazdek i 92+ forków. Datasety są hostowane na HuggingFace (agibot-world/GenieSimAssets) i ModelScope (agibot_world/GenieSim3.0-Dataset). Model wytrenowany na danych syntetycznych z Genie Sim wykazuje zero-shot sim-to-real transfer z wyższym wskaźnikiem sukcesu niż modele trenowane na danych rzeczywistych.
Simulation obejmuje oprogramowanie używane do modelowania, testowania i walidacji zachowań robotów, sensorów, środowisk oraz algorytmów bez konieczności użycia fizycznego sprzętu.
Developer Tool to oprogramowanie przeznaczone do wspierania pracy deweloperskiej, w tym konfiguracji, debugowania, testowania, monitorowania, walidacji lub integracji systemów robotycznych i embedded.
Rola symulacji opisuje oprogramowanie odtwarzające w środowisku komputerowym fizyczne zachowanie robota i otoczenia. Komponent symulacyjny realizuje: deterministyczną integrację dynamiki sztywnych i miękkich ciał (zazwyczaj poprzez silniki PhysX, Bullet, MuJoCo, Newton), foto-realistyczne renderowanie sceny (RTX, ray-tracing), modele sensorów (kamery RGB/D, LiDAR, IMU, F/T), generację danych syntetycznych do treningu polityk uczenia maszynowego, ewaluację porównawczą wielu wariantów rozwiązań w identycznych warunkach. Symulacja umożliwia masowo zrównoleglony trening RL bez fizycznego hardware i jest podstawą workflowu sim-to-real.
Rola benchmarkingu i ewaluacji opisuje oprogramowanie odpowiedzialne za standaryzowane mierzenie zdolności robotów i modeli AI. Komponent benchmarkowy zawiera: zbiór zdefiniowanych zadań (manipulacja, lokomocja, percepcja, instrukcja), automatyczne metryki sukcesu i jakości wykonania, scenariusze testowe pokrywające wymiary generalizacji (oświetlenie, tło, szum kamery, opóźnienie sterowania), procesy odtwarzalne uruchamiania wielokrotnych prób z agregacją wyników, leaderboardy modeli (np. π0.5, GR00T, π0). Współcześnie wykorzystuje VLM (Vision-Language Models) do auto-ewaluacji złożonych kryteriów jakościowych niedostępnych dla prostych metryk numerycznych.
Rola generowania danych syntetycznych opisuje oprogramowanie służące do automatycznej produkcji dużych zbiorów danych treningowych dla modeli percepcji i sterowania robotów. Komponent realizuje: programowane scenariusze symulacyjne z parametryzowanymi obiektami i ruchami, automatyczne etykietowanie ground-truth (segmentacja, bounding boxes, pozy 6-DoF, mapy głębi), zbieranie trajektorii demonstracji metodą teleoperacji w symulacji lub przez automatyczne polityki ekspertów, augmentację domenową (lighting, tekstury, materiały) dla domain randomization, mechanizmy error-recovery do tworzenia poprawnych prób mimo niepowodzeń. Generuje skalę danych nieosiągalną w fizycznym świecie — typowo 10,000+ godzin trajektorii.
Rola uczenia robotów opisuje oprogramowanie służące do trenowania polityk sterowania i umiejętności manipulacyjnych/lokomocyjnych robota metodami uczenia maszynowego. Obejmuje: uczenie ze wzmocnieniem (reinforcement learning) w symulacji z transferem sim-to-real, uczenie imitacyjne (imitation learning) i uczenie z demonstracji (learning from demonstration), trening modeli Vision-Language-Action (VLA), oraz fine-tuning foundation models robotyki. Typowo wykorzystuje masowo zrównoleglone środowiska symulacyjne (Isaac Lab, MuJoCo) do generowania danych treningowych, a następnie wdraża wytrenowane polityki na fizycznym robocie.
Teleoperation oznacza rolę oprogramowania umożliwiającego zdalne sterowanie robotem, jego ruchem, manipulatorami, kamerami lub zadaniami przez człowieka za pośrednictwem interfejsu operatorskiego.
Developer Enablement oznacza rolę oprogramowania wspierającego deweloperów w integracji, debugowaniu, walidacji, konfiguracji, testowaniu i uruchamianiu systemów robotycznych oraz ich komponentów.
Motion Planning oznacza rolę oprogramowania odpowiedzialnego za planowanie trajektorii, ruchu, kolejności działań oraz wyznaczanie bezpiecznych i wykonalnych ścieżek dla robota lub manipulatora.
Rodzina oprogramowania AgiBot Genie dla embodied AI: Genie Studio (one-stop development platform), Genie Sim (symulator), Genie Operator (GO-1 foundation model), Genie Envisioner (GE-1 world model).
AgiBot Genie G2 (humanoid produkcyjny z USD+URDF w v3.0 + whole body control), AgiBot World Challenge 2025/2026, ekosystem akademicki testujący modele π0.5 / GR00T-N1.6 / π0 na benchmarkach GenieSim. Genie Sim ukazał się w artykule arXiv 2601.02078 (Yin et al., 2026).
Repozytorium GitHub AgibotTech/genie_sim: ponad 1000 gwiazdek i 92 forki (06.2026). Datasety na HuggingFace (agibot-world/GenieSimAssets) i ModelScope (agibot_world/GenieSim3.0-Dataset).
Python to wysokopoziomowy język programowania szeroko stosowany w robotyce, AI, computer vision, automatyzacji, testach i szybkiej integracji komponentów sprzętowych oraz software'owych.
C to język programowania powszechnie wykorzystywany w firmware, sterownikach, mikrokontrolerach i systemach embedded, gdzie wymagana jest bezpośrednia kontrola nad zasobami sprzętowymi.
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.
Pełna instalacja z assetami i datasetem wymaga 200+ GB. Genie Sim bazuje na NVIDIA Isaac Sim 5.1.0 (Omniverse) i dziedziczy jego wymogi sprzętowe (RTX-capable GPU dla ray-tracingu, Linux jako preferowany OS przez Docker).
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.
Standardowy mechanizm Pythona do reproducible installation zależności przez plik requirements.txt definiujący dokładne wersje pakietów. Format: '<package>==<version>' dla pinowanych wersji lub '<package>>=<version>' dla minimalnych wymagań. Instalacja: 'pip install -r requirements.txt'. Stosowany w projektach robotycznych opartych na Pythonie gdzie ważna jest reprodukowalność środowiska: skrypty ML dla robotów (trenowanie, ewaluacja), narzędzia analityczne dla danych z floty, automation scripts dla CI/CD. Rozszerzenia: pip-tools (pip-compile generuje requirements.txt z requirements.in z pinowanymi subdependencies), Poetry (nowoczesny alternatywny menedżer z lockfile), PDM, Hatch. Wirtualne środowiska: venv (stdlib), virtualenv, conda environments – izolują zależności projektu od systemu. Ograniczenie: brak obsługi zależności binarnych i systemowych – pip instaluje wyłącznie pakiety Python. Komplementarny z rosdep w ekosystemie ROS.
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.
Architektura obliczeniowa NVIDIA CUDA (Compute Unified Device Architecture) na platformie x86_64 – GPU NVIDIA jako koprocesor dla równoległych obliczeń. Nie jest samodzielną architekturą CPU, lecz dodatkowym wymaganiem sprzętowym dla oprogramowania korzystającego z akceleracji GPU. W robotyce kluczowa dla: trenowania modeli foundation i VLA (NVIDIA A100, H100, RTX 4090 na x86_64 serwerach/stacjach), inference modeli AI w symulatora (Isaac Sim wymaga CUDA GPU na x86_64), perception pipeline z akceleracją GPU (CUDA-accelerated stereo depth, optical flow, object detection), generowania syntetycznych datasetów (Omniverse Replicator). Wymagania: CUDA Toolkit (12.x dla najnowszych modeli), cuDNN, TensorRT dla optymalizowanego inference. NVIDIA Isaac ROS na x86_64 wymaga GPU NVIDIA z CUDA 12.x. Frameworki ML: PyTorch (CUDA backend), TensorFlow (CUDA/cuDNN), JAX (XLA + CUDA). Specyficzne wersje CUDA wymagane przez konkretne oprogramowanie – np. Isaac Sim 4.x wymaga CUDA 12.3+. Ograniczenia: wysokie wymagania energetyczne (GPU klasy datacenter: 300–700W), koszty sprzętu, brak mobilności. Środowisko deweloperskie i treningowe, nie deployment na robocie.
Klasa przetwarzania wsadowego lub offline – operacje trwające od kilku minut do godzin lub dni. Brak wymogów latencji – liczy się throughput i poprawność wyniku. Zastosowania: trenowanie modeli foundation (VLA, world models), przetwarzanie dużych zbiorów danych z sensorów, symulacje Monte Carlo, rendering syntetycznych datasetów w Isaac Sim, analiza długoterminowych logów, certyfikacja i walidacja oprogramowania.
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.
Rodzina licencji: Słaby copyleft
Słaba licencja copyleft na poziomie pliku (file-level copyleft) – copyleft dotyczy wyłącznie zmodyfikowanych plików MPL, nie całego projektu. Zawiera jawną klauzulę patentową i mechanizm retaliation. Kompatybilna z GPL v2, GPL v3 i LGPL. Umożliwia łączenie kodu MPL z kodem proprietary w różnych plikach.
Stosowana przez niektóre biblioteki middleware i narzędzia deweloperskie w ekosystemie robotycznym. File-level copyleft jest przyjazny dla integratorów – modyfikacje plików MPL muszą być ujawnione, ale reszta projektu może pozostać zamknięta. Wygodna alternatywa dla LGPL przy bibliotekach C++.
