SimLab: Multi-Domain Simulation Workbenches
- SimLab is a polysemous label for distinct simulation environments spanning robotics, conversational information access, and laminate robotic mechanisms.
- The MATLAB/Simulink variant achieves two orders of magnitude speedup with code-generation-ready blocks and dynamic mask subsystems for realistic rigid-body simulations.
- The conversational and laminate variants deploy cloud-native and symbolic dynamics pipelines, respectively, enabling flexible evaluation and automated design processes.
SimLab is a recurrent software name in recent arXiv literature rather than a single research artifact. In the sources considered here, it denotes three unrelated systems: an open-source MATLAB/Simulink simulator for rigid-body articulated robots in contact with the ground, a cloud-based platform for simulation-based evaluation of conversational information access systems, and an integrated companion to popupCAD for dynamic modeling and simulation of laminate robotic mechanisms (Guedelha et al., 2022, Bernard et al., 7 Jul 2025, Khodambashi et al., 2018). The commonality is infrastructural rather than disciplinary: each system treats simulation as an editable experimental environment, but the operational meaning of “simulation” ranges from multibody forward dynamics to managed user–agent interaction and symbolic mechanism analysis.
1. Disambiguation and scope
The primary encyclopedic issue is terminological. “SimLab” is used for distinct platforms with no stated shared codebase, governance structure, or technical lineage. The name therefore functions as a polysemous label across robotics, conversational information access, and laminate-mechanism prototyping (Guedelha et al., 2022, Bernard et al., 7 Jul 2025, Khodambashi et al., 2018).
| Variant | Domain | Defining description |
|---|---|---|
| SimLab | Robotics simulation | open-source MATLAB/Simulink simulator for rigid-body articulated systems in ground contact |
| SimLab | Conversational information access | cloud-based platform for simulation-based evaluation of conversational information access systems |
| SimLab | Laminate robotics | integrated design-and-simulation environment for laminate robotic mechanisms |
This ambiguity is not merely lexical. The three systems differ in ontology, interface contract, validation methodology, and target workload. In one case the core objects are rigid bodies, contacts, Jacobians, inertia matrices, and generalized bias forces; in another they are conversational agents, user simulators, information needs, and evaluation metrics; in the third they are rigid bodies, flexure hinges, symbolic joint coordinates, and closed-loop constraints. A plausible implication is that references to “SimLab” require explicit domain qualification in scholarly communication.
2. MATLAB/Simulink SimLab for rigid-body robots
In robotics, SimLab is presented as an open-source MATLAB/Simulink simulator for rigid-body articulated systems, including manipulators and floating-base robots. Its architecture is hybrid: “three main blocks, namely two MATLAB System blocks and a set of Simulink Function blocks redefined as Dynamic Mask Subsystems.” One MATLAB System block performs state evolution, a second handles visualization, and the state-evolution block depends on three MATLAB classes—Robot, Contact, and State. The Robot class computes forward dynamics, the Contact class computes reaction forces, and the State class computes system state evolution. Kinematic and dynamic quantities such as link Jacobians, the inertia matrix, Coriolis and centrifugal terms, generalized bias forces, and world-to-feet transformations are computed via Simulink Functions that call the Whole-Body Toolbox, which wraps iDynTree; the visualization block also uses iDynTree (Guedelha et al., 2022).
A central design decision is the replacement of direct MATLAB-to-MEX bindings with code-generation-ready Simulink blocks. The earlier binding-based design “significantly slowed down the simulation, lowering the real-time factor,” because execution passed through the MATLAB interpreter. The refactored approach preserves programmatic access from MATLAB System classes while moving dynamics and optimization calls into self-contained Simulink blocks, including simFunc_qpOASES, which wraps a Whole-Body Toolbox block for a QP solver from qpOASES. Data exchange is structured through bus signals, notably the kynDynOut bus, and flexibility is further extended by Simulink Dynamic Mask Subsystems so that subsystems can be redefined for robots with open-chain or closed-chain kinematics and “any desired number of links interacting with the ground.”
The supported modeling envelope is broad within rigid-body legged and manipulation robotics. The framework is intended for “rigid body robots including manipulators and free-floating robots,” supports robots with rectangular or spherical feet, and “can also integrate second-order actuator dynamics.” The paper explicitly describes editability of contact modeling by showing how a simulator originally developed for free-floating base robots with rectangular feet was extended to spherical feet by changing the hard-coded number of contact vertices to a user input, adding contact-point feature functions, adding a foot-shape input, and selecting appropriate computations according to foot shape.
Performance claims are concrete. After the refactor to Simulink Functions, critical Robot-class methods exhibited execution-time reductions “by two orders of magnitude.” In a closed-loop experiment with a momentum-based whole-body torque controller for the iCub balancing on one foot while moving an arm and free leg, the simulator ran at 1000 Hz, the controller at 100 Hz, and the visualizer at 20 Hz; on an Intel Core i9 machine with 64 GB RAM in MATLAB R2020b, a 45-second simulation took 46.5 seconds, giving a real-time factor of 0.97. In comparison with Gazebo on an Intel Core i7-10750H machine with 32 GB RAM in MATLAB R2020b, a 20-second knee-bending experiment took about 23 seconds in Gazebo and about 32 seconds in the MATLAB/Simulink simulator, corresponding to real-time factors of 0.87 and 0.63 respectively; reducing visualization frequency or removing the visualizer lowered execution time to 18 seconds and increased the real-time factor to 1.11 (Guedelha et al., 2022).
3. Cloud-based SimLab for conversational information access
In conversational information access, SimLab is introduced as “the first cloud-based platform to provide a centralized general solution for the community to benchmark both conversational systems and user simulators in a controlled and reproducible environment.” The target systems include conversational search engines, recommender systems, and conversational assistants. The stated motivation is that offline metrics are insufficient for multi-turn interaction, human-centered evaluation is expensive and difficult to reproduce, existing benchmark campaigns often simplify interaction, and existing simulation toolkits are narrow in scope (Bernard et al., 7 Jul 2025).
The platform is organized around five requirements: online evaluation support, flexibility, scalability and portability, intuitive use, and extensibility. Its core component is an Evaluation Framework that defines tasks, metrics, a communication protocol between conversational agent and user simulator, and orchestration of the simulation process. The protocol is HTTP-based and uses the endpoints POST /configure, POST /receive_utterance, POST /set_information_need, and POST /get_information_need. Evaluation proceeds in four stages: environment configuration, evaluation, result storage, and environment cleaning. The broader infrastructure includes a Systems Registry storing systems as Docker images, a Virtual Machine Cluster, a Virtual Machine Manager, storage for configurations and results, monitoring and logging, and a Web Application with GUI and API.
The initial implementation is containerized and cloud-native. The evaluation framework is written in Python with DialogueKit as a foundation; communication is via HTTP requests; the web backend uses Python and Flask; the frontend uses React; the database is MongoDB; the systems registry is a Docker registry; VM management uses Jenkins; monitoring and logging use Grafana and Prometheus; and deployment is on Google Cloud Platform. The initial public task is conversational movie recommendation based on the MovieLens 32M dataset, with information needs defined from movie attributes such as genre, keywords, and actors.
The demonstration setup uploads ten conversational recommender agents adapted from the iEvaLM repository, based on CRB-CRS, KBRD, BARCOR, UniCRS, and ChatCRS, using or trained on OpenDialKG and ReDial. It also uploads naive user simulators implemented with a LLM through Hugging Face Transformers, using SmolLM2-135M-Instruct in versions 1.0 and 2.0. The evaluation measures for the movie recommendation task are utility, measured by success rate as determined by a zero-shot classifier, and dialogue capabilities, measured using the understanding and consistency dimensions of FED. The paper is explicit that the demonstration is not a full comparative benchmark and does not claim a ranked winner. It is equally explicit that simulation is not presented as a replacement for human evaluation; instead, simulation is positioned as a way to scale evaluation, screen weak systems earlier, and use human evaluation more efficiently as a final step (Bernard et al., 7 Jul 2025).
4. SimLab for laminate robotic mechanisms
In laminate robotics, SimLab is an integrated design-and-simulation environment implemented as a companion to popupCAD. Its purpose is to let a user design a laminate mechanism in popupCAD, export geometry and material information to YAML, import that representation into Pynamics, derive equations of motion symbolically, solve the resulting dynamics, and render plots and videos without hand-deriving the system equations (Khodambashi et al., 2018).
The workflow is explicit. popupCAD provides the design environment and exports a YAML file containing rigid-body structure, joints, a Newtonian base frame, and material properties. Pynamics then constructs the symbolic model using reduced coordinates in which the state variables are joint rotations. The dynamics are derived with Kane’s method. Closed-loop mechanisms are handled by introducing additional constraints and a dummy body; the paper gives the constraint expression
Because laminate mechanisms are often manufactured flat and then erected into three-dimensional shapes, the initial state is singular or nearly singular. SimLab therefore uses a two-stage process in which Baumgarte stabilization first settles the mechanism into a valid non-singular configuration and a second stage integrates the main simulation without Baumgarte terms. About 300 time steps were needed for the six-bar case to bring the constraint error within tolerance.
The environment also includes hinge characterization. For a laminate pendulum, the hinge is modeled as
and the parameters and are identified by least-squares fitting. The materials study used flexible polyester of thickness 0.127 mm, tensile tests following ASTM D882-12, and 11 specimens, with average Young’s modulus 4383.27 MPa and yield stress 42.84 MPa. Motion capture employed two OptiTrack Prime 17W cameras at 360 fps with 18 markers for the six rigid bodies. To suppress differentiation noise, the oscillation data were fit with a Fourier series and then analytically differentiated to obtain velocity and acceleration. The reported mean absolute errors for the empirical parameter models were , or 4.01%, for damping and , or 1.39%, for stiffness.
Validation covered a simple pendulum, a triple pendulum, a four-bar closed-loop mechanism, and a six-bar closed-loop mechanism, all as five-layer designs. The paper reports comparison of simulated and experimentally measured position, velocity, and acceleration, and gives equilibrium values for the six-bar case for joints through . It also records several limitations: only serial chains and one closed loop are fully addressed; Baumgarte stabilization requires manual tuning of and ; and the method still struggles with singular initial configurations, material nonlinearity, creep, viscoelasticity, and contact with ground. The system is not presented as a replacement for commercial dynamics packages (Khodambashi et al., 2018).
5. Shared architectural themes
Despite the absence of a common lineage, the SimLab systems share a recognizable architectural pattern: each externalizes experimental structure so that the underlying engine remains editable at a higher level of abstraction. In the MATLAB/Simulink robotics system, this appears as MATLAB System classes, Simulink Functions, bus-based data organization, and Dynamic Mask Subsystems; in the conversational platform, as containerized systems behind a small HTTP protocol, plus explicit task and metric configuration; and in the laminate environment, as a popupCAD-to-YAML-to-Pynamics pipeline that separates geometry authoring from symbolic dynamics generation (Guedelha et al., 2022, Bernard et al., 7 Jul 2025, Khodambashi et al., 2018).
The meaning of simulation, however, is sharply domain-specific. The robotics SimLab simulates forward dynamics and robot–ground interaction under controller closure. The conversational SimLab simulates interaction between a conversational agent and a user simulator under managed evaluation. The laminate SimLab simulates mechanism motion generated from symbolic equations and experimentally identified hinge parameters. This suggests that “SimLab” is best understood not as a canonical platform family but as a recurring designation for a simulation workbench in which model construction, execution, and inspection are intentionally exposed to the researcher.
6. Limitations, misconceptions, and scholarly use
A common misconception is to treat SimLab as a single cross-domain platform. The literature considered here does not support that reading. The three systems have unrelated implementation stacks—MATLAB/Simulink with iDynTree and Whole-Body Toolbox; Python/Flask/React/MongoDB/Jenkins on Google Cloud Platform; and popupCAD, YAML, Pynamics, and motion-capture-based identification—and they answer different research problems (Guedelha et al., 2022, Bernard et al., 7 Jul 2025, Khodambashi et al., 2018).
The limitations are likewise specific. In the robotics simulator, real-time behavior depends on configuration, especially visualization frequency, and the reported excerpt does not provide the full optimization problem used in the contact model. In the conversational platform, the authors emphasize that simulator realism is imperfect, that validation methods for user simulators remain underdeveloped, and that operational costs, security risks, and multi-cloud complexity are open issues. In the laminate environment, support is limited to serial chains and one closed loop, with manual Baumgarte tuning and acknowledged difficulty in handling creep, viscoelasticity, and other nonideal material effects. For scholarly usage, the practical consequence is straightforward: citations to “SimLab” should always be accompanied by domain and arXiv identifier, because the name alone is insufficiently specific.