OpenPLX: Declarative Robotic Prototyping

• OpenPLX is a declarative language that unifies CAD models, control systems, and real-time 3D simulation into a single-source workflow.
• It enables rapid variant generation and system integration through customizable templates, tight AGX Dynamics coupling, and built-in signal interfaces.
• The framework supports advanced autonomous design with ROS2 and Python API bindings, as demonstrated by a lunar rover case study achieving over 90% task success.

Searching arXiv for the specified paper to ground the article in the current record. OpenPLX is an open-source, human- and machine-readable declarative language designed to serve as a single-source-of-truth for virtual prototyping of robots, vehicles, and construction equipment. It is embedded in a cloud-enabled framework with the AGX Dynamics physics engine and is presented as a technical framework for an integrated process in which physical design and control are explored in parallel. In that framework, OpenPLX links CAD-models and autonomous systems to high-fidelity, real-time 3D simulations of contacting multibody dynamics, machine regolith interaction forces, and non-ideal sensors, with a stated emphasis on lunar construction equipment and space robotics (Lindmark et al., 15 Sep 2025).

1. Definition and architectural objectives

OpenPLX is characterized as a readable/writable declarative language whose central architectural role is to close the loop between CAD, control software, and real-time 3D simulation. Its stated purpose is to avoid fragmented model specifications by replacing workflows that stitch together URDF, SDF, USD, and custom JSON with a single file tree composed from high-level bundles such as Physics3D, Vehicle, and Robotics (Lindmark et al., 15 Sep 2025).

The design goals are explicitly organized around declarative, single-source modeling; readable/writable syntax; tight CAD–Simulation coupling; declarative control interfaces; and reuse, specialization, and composition. In this formulation, OpenPLX allows engineers or AI-assisted agents to inspect, diff, and generate variations of machine designs, sensor configs, and scenario descriptions. A key structural property is that actuators and sensors are declared in the same language as the physical model, and “signals” are bound to simulation ports or external middleware, including ROS 2 and a Python API, so that changes in the physical model propagate to control without manual rewiring (Lindmark et al., 15 Sep 2025).

The language is also described as supporting single inheritance plus traits. This enables customizable templates such as a “six-wheel rover” to be specialized into variants with different wheel geometries, motor torques, or sensor suites. This suggests that OpenPLX is intended not merely as a static scene description format but as a configurable modeling substrate for rapid variant generation and domain randomization.

2. Core LLM and syntax

The core syntax is summarized through bundle declarations, component definitions, mate constraints, signal interfaces, and arithmetic and cross-reference expressions. The bundle mechanism is hierarchical, as in bundle Physics3D { … } and bundle LunarRobotics inherits Physics3D { … }, while component definitions include declarations such as component RigidBody { mass: Float; inertia: Matrix3x3; mesh: FilePath; } (Lindmark et al., 15 Sep 2025).

Assembly semantics are expressed through mate constraints. The example mate WheelAxleMate { parent: Chassis; child: Wheel; type: revolute; axis: [0,1,0]; } illustrates how automatic assembly is represented declaratively rather than procedurally. Signal interfaces are similarly first-class: signal camera.rgb: Image(width=128, height=128, fov=70°) and actuator wheel.motor: TorqueCommand(range=[-200,200]Nm) show that observations and commands are part of the same LLM as bodies and constraints (Lindmark et al., 15 Sep 2025).

Arithmetic expressions and cross-file references are explicitly supported. The examples wheel.radius = base_wheel.radius * 1.05 and

$$\text{center\_of\_mass} = \frac{\text{link1.CoM} \cdot \text{link1.mass} + \text{link2.CoM} \cdot \text{link2.mass}}{\text{link1.mass} + \text{link2.mass}}$$

demonstrate parametric specification and derived-property computation within the language. Data types listed in the summary are Int, Float, Bool, Vector3, Matrix3×3, FilePath, Image, PointCloud, and user-defined enums, with names following C-style conventions and dot-separated namespaces (Lindmark et al., 15 Sep 2025).

An OpenPLX-like pseudocode example defines a LunarRover bundle inheriting VehicleBundle, with a Chassis, a WheelTemplate, a loop that instantiates six wheels, a WheelAxleMate, a wheel.motor actuator, and an RGBD camera sensor. Although presented as pseudocode rather than a full grammar, it illustrates the intended compositional style: component templates, repeated instantiation, assembly constraints, and co-declaration of actuation and sensing. A plausible implication is that model structure, sensor topology, and control attachment points are meant to be versioned and manipulated as a single declarative artifact.

3. CAD import, parsing, and runtime mapping

The integration flow is described as a pipeline from CAD import through parsing and runtime instantiation to control binding and simulation. At the import stage, meshes in .stl and .obj formats and kinematic descriptions in URDF are brought into an OpenPLX bundle and automatically converted into RigidBody and Constraint components (Lindmark et al., 15 Sep 2025).

During model parsing, the OpenPLX parser validates files, resolves arithmetic expressions, inheritance, and mates, and produces a hierarchical model tree. This intermediate representation is then consumed by the runtime mapping stage, in which the Physics3D bundle drives an API that instantiates bodies, constraints, motors, and contacts in AGX Dynamics. Sensors declared in OpenPLX are bound to AGX sensor modules, including LiDAR, RGB-D, IMU, and encoders, with configurable noise models (Lindmark et al., 15 Sep 2025).

Control binding is organized through the “signal interface,” which connects OpenPLX signals to Python callbacks, ROS 2 topics, or direct C++ API calls. The simulation loop then proceeds with AGX stepping the multibody and terrain solver at fixed timesteps, sensor data emitted over signals, and control commands consumed each step. Data logging, scenario events, and domain-randomization triggers are managed by the framework’s batch scheduler (Lindmark et al., 15 Sep 2025).

This arrangement places model specification, simulator instantiation, and control-system connectivity inside a single declarative and versioned workflow. The paper’s framing suggests that OpenPLX is designed to reduce manual translation layers between CAD assets, simulation assets, and autonomy interfaces.

4. Physics, sensing, and control capabilities

The framework’s simulation layer includes contacting multibody dynamics, terrain deformation and regolith interaction, drivetrain and hydraulic components, sensor non-idealities, domain randomization, motion control support, and extensibility. Contacting multibody dynamics are described as using a maximal-coordinate formulation with complementarity for frictional contacts and joints, attributed to Lacoursière 2007. Terrain deformation and regolith interaction are described through a multiscale continuum-particle model attributed to Servin 2021 and stated to reproduce excavation forces at real-time rates (Lindmark et al., 15 Sep 2025).

The built-in component library includes shafts, gears, motors, differentials, crawler links, and digging tools. For sensing, predefined models are listed for Ouster LiDAR, generic RGB-D, IMU, and encoders, with tunable noise, drift, and occlusion parameters. Domain randomization is enabled by arithmetic expressions and parameter ranges that allow sampling of link lengths, soil friction, cohesion, and lighting conditions at scenario startup (Lindmark et al., 15 Sep 2025).

Motion-control support includes automatic forward/inverse kinematics and computed-force controllers generated from the declared kinematic tree. Extensibility is framed in terms of new physics modules such as fluid dynamics and flexible bodies, which can be added by extending the Physics3D bundle and providing a mapping to AGX or other runtimes. This suggests that the declarative layer is intended to remain stable while backend physics capabilities can be diversified through runtime mappings rather than language redesign.

5. Autonomous lunar rover case study

One case study centers on an autonomous lunar rover. The scenario is specified as a single OpenPLX scenario file containing a flat regolith environment, small craters, static obstacles, and a six-wheeled rocker-bogie rover, with LDEM height maps and regolith properties imported into the scene definition (Lindmark et al., 15 Sep 2025).

The autonomy stack is divided into a Vision-LLM, a skill library, and a low-level controller. The Vision-LLM is identified as OpenAI o4-mini, used to interpret high-level commands such as “Drive to the rock” and to select skills. The skill library exposes Rotate(target) and Drive(target) as Python functions bound to OpenPLX signals for wheel steering and speed, together with Finish() and MoreInformation() as meta-skills. The low-level controller is a PPO-trained “Drive” policy that takes (128×128 RGB, wheel angles, velocity, previous actions) and outputs Ackermann radius and speed (Lindmark et al., 15 Sep 2025).

The reinforcement-learning setup is specified concretely. The learning algorithm is PPO implemented with stable-baselines3, with hyperparameters $$r_t = \begin{cases} c_d \Delta d + c_a (1 - 40\theta^2) - c_t - c_s (a_t - a_{t-1})^2, & \text{step reward} \ 1, & \text{if stopped within 4 m of target} \ -0.5, & \text{if heading error } \theta > 30^\circ \end{cases}$$0 The reward function is given as

$$r_t = \begin{cases} c_d \Delta d + c_a (1 - 40\theta^2) - c_t - c_s (a_t - a_{t-1})^2, & \text{step reward} \ 1, & \text{if stopped within 4 m of target} \ -0.5, & \text{if heading error } \theta > 30^\circ \end{cases}$$

where $\Delta d$ is change in distance, $\theta$ is heading error, and $a_t$ is normalized action, with constants $c_d=1.0$, $c_a=0.02$, $c_t=0.01$, and $c_s=0.01$ (Lindmark et al., 15 Sep 2025).

Reported performance metrics are likewise explicit. Success rate on single-target tasks such as “Drive to the large rock” reached greater than 90 percent after $1.5\times 10^7$ timesteps. Multi-target sequences such as antenna → rover → astronaut were solved without intervention in greater than 80 percent of trials. Average cycle time and smoothness metrics were logged automatically via OpenPLX signals (Lindmark et al., 15 Sep 2025).

6. Runtime characteristics, extensibility, and limitations

Implementation notes include a concrete runtime-performance statement: AGX + OpenPLX achieves 1 kHz multibody steps with approximately 100 bodies and approximately 50 k particles for terrain on a 16-core workstation in real-time (Lindmark et al., 15 Sep 2025). The framework also includes a versioned data store in which every OpenPLX bundle, scenario, and control script is stored with git-style versioning, enabling rollbacks and dependency tracking.

The extension path to new hardware or physics is specified as a sequence: define a new bundle inheriting Physics3D, add component templates for brackets, actuators, or sensors, implement a C++ or Python plugin that maps to an AGX or external solver API, and declare the new signals. This preserves the overall declarative pattern while allowing backend specialization (Lindmark et al., 15 Sep 2025).

The limitations are also stated explicitly. There is no native support yet for flexible-body FEM; integration must occur via custom Physics3D extensions. LDEM import resolution is capped at 5 m/pixel, and high-resolution TLS maps require manual upscaling scripts (Lindmark et al., 15 Sep 2025). These constraints delimit the current scope of the framework: high-fidelity rigid-body and regolith-centered simulation are central, while some classes of deformable or high-resolution terrain modeling require additional engineering.

7. Position within integrated robotic design workflows

OpenPLX is presented as part of an integrated process for developing lunar construction equipment in which physical design and control are explored in parallel rather than sequentially. Its unifying mechanism is the preservation of a single source of truth for both bodies and signals, so that CAD-derived geometry, material and regolith properties, sensor declarations, actuator interfaces, control bindings, scenario logic, and logging are coordinated within one declarative framework (Lindmark et al., 15 Sep 2025).

Within that framing, the significance of OpenPLX lies less in any single simulator feature than in the combined workflow: native import of STL/OBJ meshes and URDF kinematics; augmentation with contact, material, and regolith properties; automatic mapping into AGX Dynamics; and direct exposure of observations and commands to scripted modules, ROS 2 nodes, and Python-embedded AI agents. The lunar rover case study, which combines vision-language steering with PPO-trained locomotion, is used to demonstrate that this coupling can support both high-level skill selection and low-level policy execution in a shared simulation environment (Lindmark et al., 15 Sep 2025).

A common misconception would be to treat OpenPLX as only a scene-description format or only a control-interface layer. The description in the source instead places it at the intersection of model declaration, simulator instantiation, and autonomy integration. A plausible implication is that its principal contribution is methodological: it organizes co-design, variant generation, and reproducible virtual testing around a readable/writable, versioned declarative representation rather than around disconnected file formats and ad hoc interface code.