AICOR VRB: Cloud-Based Robot Research

• AICOR VRB is a cloud-based platform for virtual laboratories that enable bit-level reproducibility through deterministic simulations and semantic annotations.
• It deploys containerized environments with a robust robotics stack including CRAM 2.0, ROS, and simulation engines like MuJoCo, ensuring consistent experimental results.
• The platform logs robot task executions as Narrative Enabled Episodic Memories (NEEMs) for transparent validation, provenance tracking, and collaborative scientific inquiry.

The AICOR Virtual Research Building (VRB) is a cloud-based platform for hosting virtual laboratories that encapsulate complete procedural setups for robot-based experimentation, with the stated aims of bit-level reproducibility, collaborative reuse, and transparent validation. In the underlying architecture, VRB is coupled to a semantic execution tracing framework and to digital-twin-based execution: robot task executions are logged as semantically annotated traces, persisted as Narrative Enabled Episodic Memories (NEEMs), and replayed in deterministic simulation environments so that actions, sensor streams, and internal belief states can be inspected and reproduced. The authors explicitly position VRB as the first cloud platform linking containerized, deterministic robot simulations with semantically annotated execution traces, thereby combining deterministic execution, semantic memory, and open knowledge representation for robot-driven science (Alt et al., 15 Aug 2025).

1. Concept and scope

VRB is presented as a platform for “virtual laboratories” in a specifically operational sense: each laboratory packages code, dependencies, simulation environments, and experimental data into an individually deployable unit that can be instantiated in the cloud or downloaded for local execution. Its scope is therefore broader than executable notebooks or code-sharing services. It is designed to support the full cycle of sharing, replicating, replaying, inspecting, and validating robot task executions at scale, including access to the semantic and cognitive artifacts generated during execution rather than only the final outputs (Alt et al., 15 Aug 2025).

This positioning places VRB within the broader “Virtual Laboratory” literature, where virtual laboratories are defined as digital counterparts of physical laboratories that virtualize empirical research workflows rather than merely provide educational simulations or immersive user interfaces (Sevilla-Salcedo et al., 8 Jul 2025). Within that broader category, VRB is specialized for autonomous robotics and reproducible experimentation. A frequent misconception is to treat it as a generic web front end for robotics software. The platform is instead organized around reproducible execution states, deterministic replay, ontological annotation, and verifiable provenance. This suggests that VRB is intended not simply as a deployment substrate, but as an infrastructure for making robot-generated scientific evidence inspectable and contestable.

2. Cloud architecture and software stack

VRB deploys virtual laboratories as sandboxed, individually deployable Docker containers. Each lab container carries a pre-installed robotics and knowledge stack that can be extended with domain-specific software. Container construction and deployment are automated through BinderHub: committing code to a public Git repository triggers a rebuild from versioned Dockerfiles, producing immutable images with cryptographic hashes. These images are intended to run identically across heterogeneous hardware and can also be downloaded for local execution when tasks are resource-intensive or immersive (Alt et al., 15 Aug 2025).

Kubernetes provides orchestration, self-healing, and fault tolerance. Containers are automatically restarted and rescheduled on healthy nodes, while persistent volumes preserve data across failures and distributed storage provides redundancy and high availability. The platform’s architectural diagrams, as described in the paper, emphasize a separation between maintainers who share version-controlled code and environments, and researchers who reproduce and interact with those environments in isolated sandboxes.

Layer	Components	Function
Orchestration	Docker, BinderHub, Kubernetes	Build, deploy, isolate, and recover labs
Robotics stack	CRAM 2.0, ROS, Multiverse, PyCRAM, KnowRob	Execute robot tasks and reasoning
Data/knowledge layer	NEEMHub, MongoDB, SOMA, OWL, SWRL	Store traces, semantics, and validation rules

Within each container, the robotics stack consists of CRAM 2.0, ROS, the Multiverse multi-backend simulation environment, PyCRAM, and KnowRob, plus optional domain-specific packages. Multiverse supports MuJoCo, Bullet, NVIDIA Isaac Sim, and Gazebo, while maintaining consistent USD scene structures across simulators. For data access, VRB exposes a Python-native querying interface through PyCRAM with an ORM layer for MongoDB, lowering the barrier relative to earlier Prolog-based interfaces. This choice is significant because it aligns execution reproducibility with a query model usable in ordinary scientific data analysis workflows rather than confining inspection to robotics-specific tooling (Alt et al., 15 Aug 2025).

3. Semantic execution traces and episodic memory

The central data structure underlying VRB is the NEEM. NEEMs capture complete robot execution episodes as timestamped MongoDB documents with microsecond-level timestamp resolution. Each episode includes multimodal raw sensor streams such as RGB-D camera feeds, joint positions, and force-torque readings; symbolic state representations such as object poses, robot configurations, and task execution states encoded with SOMA concepts; and semantic annotations in OWL and SWRL describing procedural events, goals, and outcomes (Alt et al., 15 Aug 2025).

Logging is automatic. PyCRAM records robot actions, belief states, and object interactions during execution, thereby supporting tracking, debugging, and reproducibility without requiring separate manual instrumentation. These traces are then served through NEEMHub, which VRB uses for replay and inspection. In replay, users can inspect synchronized sensor data, state trajectories, and belief state timelines, rather than only visualizing external robot behavior.

The semantic layer is not limited to passive annotation. SOMA provides concepts for manipulation and task structure, including object relations, spatial configurations, failures, and recovery strategies. OWL and SWRL support semantic validation and rule-based reasoning over those traces. Automated comparison of NEEM episodes is performed through graph isomorphism over task execution trees, enabling outcome equivalence checks even when minor low-level variations occur. SWRL rules can encode domain-specific checks such as thresholds for grasp contact forces or minimum clearances in navigation. Description logic inference engines can then formulate hypotheses as logical queries over NEEM databases for systematic testing and meta-analysis.

The paper is explicit about what it does not formalize. It does not define a formal execution-trace tuple, belief-state update equations, or POMDP-style formulations. The absence of such equations is itself technically relevant: VRB’s trace model is operational and ontological rather than axiomatized in the paper’s presentation (Alt et al., 15 Aug 2025).

4. Deterministic execution and digital-twin coupling

A distinguishing property of VRB is its insistence on deterministic replay. Deterministic motion and planning are supplied through components such as the Giskard motion planner, which uses sequential quadratic programming with fixed random seeds, and the PyCRAM plan executive, which uses deterministic symbolic planning with reproducible search strategies and tie-breaking. At the simulation layer, Multiverse allows backend selection according to determinism requirements: MuJoCo for deterministic forward dynamics in continuous control, Bullet for deterministic rigid-body dynamics with configurable solver parameters, and Gazebo for deterministic discrete-time simulations with controllable integration schemes. VRB preserves temporal fidelity in replay through MongoDB timestamp ordering and deterministic event scheduling (Alt et al., 15 Aug 2025).

These deterministic components are coupled to digital-twin-based execution. In the paper’s formulation, high-fidelity semantic simulations mirror the real laboratory environment and are enriched with detailed object models and physics through NaivPhys4RP. Task protocols are encoded as socio-physical knowledge graphs, while instructions are grounded via an Abstract Context Description Language (ACDL). The execution cycle comprises hypothesis generation in the twin before acting, action synchronization with real-time replication of movements, outcome comparison using pixel-level and semantic similarity metrics, and discrepancy analysis producing causal explanations for mismatches.

The resulting traces are therefore multi-layered. They include not only low-level sensor logs and semantic state changes, but also cognitive traces documenting hypotheses, predictions, decision steps, visual comparisons, causal explanations, and object interaction analyses grounded in SOMA and domain ontologies. This architecture makes VRB a replay system for both behavior and reasoning. A plausible implication is that reproducibility here is meant to cover the epistemic path of the robot system—why it acted as it did—not only the externally observed sequence of motions.

As with execution traces, the paper does not provide explicit mathematical mappings between physical and virtual states, explicit alignment error metrics, or formal error bounds for the digital twin. Time synchronization is treated operationally via high-resolution timestamps and deterministic scheduling rather than through a formal mapping such as $\phi: S_{\mathrm{phys}} \to S_{\mathrm{virt}}$ (Alt et al., 15 Aug 2025).

5. Reproducibility workflows, replay, and validation

The VRB workflow begins with authoring and versioning. A laboratory maintainer keeps code and the environment in a Git repository, with a Dockerfile specifying dependencies and configurations. BinderHub rebuilds the image on commit, and Kubernetes deploys the containerized laboratory with sandboxing and fault tolerance. Robot tasks are then executed in that lab, while PyCRAM automatically logs actions, belief states, and object interactions into NEEMs stored in NEEMHub together with timestamps and cryptographic hashes (Alt et al., 15 Aug 2025).

Once the repository and NEEMs are published, other researchers can instantiate identical containers through the VRB web interface or download the images for local execution. Stored NEEM episodes can be replayed in VRB, where users inspect synchronized sensor data, state trajectories, and semantic annotations. Validation can then proceed along several routes. One route is semantic validation by graph isomorphism over task execution trees. Another is rule-based validation through OWL and SWRL. A third route uses RobAuditor, which implements context-adaptive verification, recovery, and audit.

RobAuditor interprets execution traces and context—NEEMs, SOMA, and digital-twin information—into a comprehensive story, then dispatches verification queries to a distributed pipeline of verifiers. Each verifier, as well as the metareasoner, returns a quadruplet $(Ds, Cf, Ed, Er)$: decision, confidence, explanation, and optional recovery plan. The audit trail produced from these outputs serves as concise documentation of robot activities. This workflow is notable because validation is not reduced to a binary pass/fail outcome; it is organized as an explanation-bearing reasoning pipeline.

For analysis, NEEMs are queried through the Python ORM in PyCRAM, and logical queries can be formulated over NEEM databases for hypothesis testing and meta-analysis. The paper also provides concrete access points, including the VRB portal at https://vrb.ease-crc.org/ and an example NEEM replay notebook served through Binder. At the same time, it states that concrete REST endpoints, CLI commands, and SDK class interfaces are not specified in the text (Alt et al., 15 Aug 2025).

6. Trustworthiness, comparative position, and limitations

VRB’s trust model is built around immutability, provenance, and auditability. NEEMHub uses content-addressable storage with cryptographic hashes for NEEM documents, so that any alteration changes the hash and tampering becomes detectable. This provides verifiable provenance, but the paper does not specify more elaborate cryptographic constructions such as hash chains or Merkle trees. Trust is therefore established through tamper-evident storage and replayable semantic traces rather than through formally specified ledger mechanisms (Alt et al., 15 Aug 2025).

In comparisons to adjacent systems, the authors distinguish VRB from LiveDocs, MyBinder, repo2docker, and BinderHub by arguing that those systems typically provide executable environments and reproducible code but lack semantically structured data and fine-grained provenance. They distinguish it from cloud robotics systems such as Rapyuta by emphasizing that VRB adds semantic memory through NEEMs, ontological validation through SOMA, OWL, and SWRL, and deterministic simulation. The platform’s stated unique contributions are the integration of containerized deterministic robot simulations with semantically annotated execution traces at scale, semantic validation via graph isomorphism over task execution trees and rule-based assessment, and open access to code, simulation environments, and data in alignment with FAIR principles (Alt et al., 15 Aug 2025).

The limitations are equally explicit. Floating-point arithmetic can diverge across platforms because of CPU, compiler, and math-library differences; IEEE 754 consistency holds only within hardware classes, so cross-platform validation may still be required. Non-deterministic algorithms such as machine learning methods, genetic algorithms, and simulated annealing require explicit control of randomness; VRB provides deterministic PRNG facilities, but users must manage randomness within their own code. Real-time constraints can induce timing-dependent behavior; deterministic scheduling and configurable time steps are provided, but robustness to small timing variations remains something users must validate for themselves. The paper also notes that it reports architecture and integration rather than quantitative throughput, latency, storage footprint, or statistical benchmark results.

Future work is framed around imagination-enabled traces for automated formal verification of task execution, with the aim of detecting protocol deviations or unexpected outcomes in real time. In the broader virtual laboratory discourse, this points toward a convergence between workflow reproducibility, semantic memory, and runtime verification in autonomous scientific systems (Sevilla-Salcedo et al., 8 Jul 2025).