Evaluating Simulation Platforms for Modular Mobile Robotic Systems

Abstract

Modular Mobile Robotic Systems (MMRSs) require simulation tools capable of supporting distributed control architectures, dynamic reconfiguration, and scalable experimentation. This work evaluates three complementary simulation strategies for a homogeneous MMRS composed of autonomous Two-Wheel Inverted Pendulum (TWIP) modules: (i) Webots, selected for rapid prototyping through its integrated GUI; (ii) Pinocchio, paired with the Jiminy simulator to enable modern rigid-body dynamics and control-oriented modeling; and (iii) PyBullet, chosen for programmatic flexibility and reinforcement learning (RL) compatibility. A minimal and controlled benchmark scenario was implemented across all platforms to isolate core simulation characteristics: two differentially driven robots were coupled using the most appropriate mechanism available in each environment and simulated for 1000 steps in headless mode while monitoring CPU usage, memory consumption, and execution time. In addition, a feature-based analysis focused on MMRS-relevant requirements, including dynamic reconfiguration, multi-agent scalability, and suitability for RL workflows.

1. Introduction

Modular robots are composed of individual modules, each capable of performing tasks typically associated with complete robotic systems while maintaining the ability to connect physically and functionally with similar units [1,2]. Modular Mobile Robotic Systems (MMRSs) represent an emerging design paradigm in robotics, addressing the prevalent challenges faced by contemporary robots. These modules are expected to operate autonomously while cooperating with other units, thus exhibiting great flexibility in the types of actions they can perform. Altogether, MMRSs are a technologically interesting solution for a large number of scenarios, such as various types of exploration, and, in general, for activities in hostile environments. The potential advantages of such modular mobile systems are numerous and important. First, such a design approach facilitates the development of robotic systems in a shorter time frame, reducing the effort required in the design phase. Second, mass production becomes more scalable, as the same modular units can be reused as parts for a multitude of modular systems.

Simulations play a central role in the development of Modular Mobile Robotic Systems by providing a controlled environment for testing and optimization prior to physical implementation. They enable the creation of accurate kinematic and dynamic models for robots with differential or omnidirectional drive systems, allowing researchers to analyze system behavior under a wide range of operating conditions [3]. In addition, virtual environments facilitate the implementation and tuning of control strategies, including fuzzy inference systems and reinforcement learning approaches, in order to achieve robust and adaptive robot behavior [4]. Simulations are also essential for evaluating localization and navigation systems, which are critical for the autonomous operation of mobile robots [5]. Furthermore, they support modular design optimization by allowing different robot configurations to be tested and compared, so as to identify solutions best suited to the requirements of specific applications [6].

This paper is structured as follows: Section 2 reviews simulation frameworks and modeling approaches relevant to MMRS, including general-purpose simulators, digital twins, co-simulation, and MMRS-specific tools. Section 3 presents a comparative case study to identify a suitable platform for a homogeneous modular mobile robot. The paper concludes with a discussion of the limitations and future work.

Despite the growing interest in modular robotics, relatively limited work has focused on the comparative evaluation of simulation platforms specifically from the perspective of Modular Mobile Robotic Systems. In particular, challenges related to dynamic topology changes, runtime reconfiguration, scalability of distributed modular systems, and integration with modern reinforcement learning workflows remain insufficiently explored. These limitations motivate the need for a practical evaluation of simulation environments capable of supporting dynamically reconfigurable MMRS architectures.

The contributions of this paper are threefold. First, a constraint-based modular modeling strategy is identified and implemented across the evaluated platforms, in which each module is simulated as an independent rigid body and inter-module connections are created dynamically at runtime. Second, a quantitative comparison of three simulation platforms (Webots, Pinocchio, and PyBullet) is conducted in an MMRS-specific scenario, evaluating CPU usage, memory consumption, and real-time performance. The study highlights how naturally each simulation environment supports this approach and how suitable these platforms are for scalable decentralized control workflows. Third, a feature-based analysis is presented, focusing on requirements critical to modular robotics, including dynamic reconfiguration, multi-agent scalability, and compatibility with reinforcement learning workflows. The presented benchmark is intentionally simplified and does not attempt to fully characterize large-scale MMRS behavior or formal physics fidelity. The overall modeling approach is summarized in Algorithm 1.

Algorithm 1: MMRS simulation loop (constraint-based composition)

Initialize system: modules ← instantiate independent bodies constraints ← create fixed constraints between selected mating interfaces disable collision between connected modules Simulation loop: repeat   for each module do     read state     compute local control action     apply wheel velocities   end for     if docking condition is satisfied then     compute relative interface pose     create constraint     else if undocking condition is satisfied then     remove constraint   end if     step physics   end repeat

2. Simulation Frameworks and Modeling Approaches for MMRSs

MMRS simulation involves overcoming several technical challenges, some of which are specific to modular systems [7], while others are specific to robotics simulations. The objective is to reduce the development time of a complex system with possible dynamic topologies that is reliant on distributed control by using computer modeling tools. Since, by their nature, MMRSs consist of many modules that interact in complex ways, simulation tools come to the aid of researchers by abstracting some problems into more user-friendly applications [5]. This section will first cover general trends in robotic simulation, highlighting the opportunities as well as the challenges that each approach offers for MMRSs.

2.1. General-Purpose Robotic Simulators for Multi-Robot Systems

Currently, the simulation of robotic systems incorporates several trends like the use of advanced robotic simulators, such as CoppeliaSim [8], Webots [9], Gazebo [10,11], Issac Sim [12], and MuJoCo [13]. All these platforms provide users with specific programming interfaces (APIs) as well as support for ROS (Robot Operating System) integration.

Simulating multi-robot systems requires platforms capable of accurately modeling both the physical and digital interactions between multiple autonomous units. These simulators must support dynamic physical environments, such as uneven terrain and obstacles, while enabling realistic inter-robot interactions. Equally important is the ability to simulate distributed communication systems. Additionally, simulations must scale efficiently to support tens or even hundreds of robots without incurring prohibitive computational costs. These requirements are especially critical in the context of multi-module robotic systems, which inherently involve complex, multi-robot coordination. Accurate simulation of such systems demands tools that can effectively capture the unique challenges of distributed, modular robotics. The following table (Table 1) shows the main features of these simulation tools.

Table 1. Comparison of the presented simulation tools.

Feature	Gazebo	Webots	CoppeliaSim (V-REP)	NVIDIA Isaac Sim	MuJoCo
Type	Commercial (open source).	Commercial (open source).	Commercial (mostly open source).	Commercial.	Commercial (open source).
Main use	General, industrial, and mobile robotics.	General, industrial, and mobile robotics.	General, industrial, and mobile robotics.	General, industrial, and mobile robotics.	Robotics, RL, biomechanics.
Physics backend	ODE, Bullet, Simbody, DART.	Proprietary engine, derived from ODE.	Proprietary engine.	PhysX.	MuJoCo engine.
Supported sensors	Cameras, LiDAR, contact sensors, IMU.	Cameras, LiDAR, contact sensors, IMU.	Cameras, LiDAR, contact sensors.	Cameras, LiDAR, contact sensors.	Cameras, contact sensors.
Programming languages	C++ 17, Python 3, ROS 2	Python 3, C 99, C++ 17, MATLAB 2015b and above	Lua 5, Python 3, C++ 17, Java 8 or above, ROS 2	Python 3, C 99, C++ 17	Python 3, C 99, C++ 17
Integration with ROS	Yes	Yes	Yes	Yes	Yes
Strengths	Realistic physics, ROS integration, multi-robot support.	Easy to use, intuitive interface, multi-language support.	Asynchronous simulations, multi-language support.	Realistic environment, lighting simulation, AI training.	Fast simulation, strong RL adoption, efficient contact dynamics.

Each simulator offers distinct advantages and limitations. For example, Gazebo is well-integrated with ROS and widely used in academic settings, but may struggle with scalability in large-scale multi-robot systems [14]. Conversely, Isaac Sim offers high-fidelity physics and photorealistic rendering but may require more computational resources and is more complex to set up. Therefore, the selection of a simulator often depends on the specific needs of the robotic system being studied. Most existing simulators were not explicitly designed to support the dynamic topology and interconnectivity requirements of MMRSs, where modules can dock, undock, or reconfigure themselves in real time. This introduces unique simulation challenges, such as handling dynamic constraints, real-time control adaptation, and inter-module communication. It can be seen that most of these programs do not focus on modular robots and offer only limited features for them, with the exception of Webots.

Looking at Gazebo in particular, prior studies have also reported that this integration introduces challenges for real-time control, including high computational overhead, timing synchronization issues, and message latency when managing multiple robots [14]. These limitations make this approach less suitable for modular robots, particularly due to the need for complex communication mechanisms and strict synchronization between control, communication, and physics simulation during docking and undocking events. In scenarios where precise timing and dynamic reconfiguration are critical, such as in MMRSs, these delays can significantly impact performance and reliability, motivating the exploration of alternative platforms that allow simpler and more deterministic integration.

Other modern simulation environments have also gained significant popularity in robotics and reinforcement learning research. MuJoCo, for example, is commonly used in robot learning applications due to its efficient physics simulation and suitability for reinforcement learning workflows [13]. However, the simulator is primarily oriented toward predefined articulated system models, while runtime modification of the constraints and dynamically reconfigurable modular topologies may introduce additional implementation complexity in MMRS-oriented workflows. Similarly, recent developments in NVIDIA Isaac Sim have emphasized GPU-accelerated simulation, synthetic data generation, and integration with modern robotic learning pipelines [12]. While these capabilities are valuable for large-scale learning-oriented applications, effective deployment often requires high-performance GPU hardware or access to GPU-accelerated cloud infrastructure, potentially increasing deployment complexity and limiting accessibility for smaller-scale experimental workflows. For these reasons, and due to the scope limitations of the present study, these platforms were not included in the comparative evaluation.

2.2. Digital Twins in Robotic System Simulation

Another emerging trend in simulation is the creation of digital twins, which are highly detailed virtual models of physical systems used for monitoring, testing, and optimization. In the field of robotics, digital twins facilitate an in-depth understanding of the behavior of robots and their interactions with the environment, providing a bridge between simulation and real-world implementation. They are being used in a variety of applications, from industrial robot development to autonomous vehicle testing, with the potential to significantly impact design, maintenance, and optimization processes [15].

A notable example in robotics is NVIDIA DRIVE Sim, built on the Omniverse platform underlying Isaac Sim, where digital twins of vehicles and environments are used to train and validate autonomous driving algorithms under diverse and repeatable conditions. Such platforms enable large-scale scenario generation and high-fidelity sensor simulation while maintaining a tight coupling to real-world system models. A specific example is NVIDIA’s collaboration with automotive industry partners to test pedestrian detection and collision avoidance algorithms, significantly reducing the risk associated with testing in real-world environments [16].

Another example of the use of digital twins in robotics is the Siemens Tecnomatix platform, which provides a complete environment for simulating and optimizing industrial processes. It is used to model entire factories, including robots handling parts or assembling components [17]. Similarly, PTC ThingWorx integrates real-time data from a physical robot’s sensors with its virtual model, enabling continuous performance monitoring and predictive maintenance [18].

Digital twins are also essential in the field of mobile robotics. For example, it can simulate a drone flight in variable wind conditions or in confined spaces, such as warehouses, to optimize trajectories and energy consumption [19].

Digital twins are also increasingly used to generate synthetic data for machine learning, allowing perception and control algorithms to be trained in controlled virtual environments before deployment on physical robots [20].

Despite these advantages, the application of digital twin methodologies to Modular Mobile Robotic Systems remains limited. The dynamic reconfiguration of MMRSs, involving frequent changes in topology, constraints, and communication patterns, makes the creation of accurate and continuously synchronized virtual replicas particularly challenging. Maintaining real-time data consistency across multiple modules requires complex communication infrastructures and standardized interfaces, which are largely absent in current modular robotics platforms.

2.3. Co-Simulation

Co-simulation is a collaborative simulation methodology that integrates multiple software tools or environments to simultaneously model and analyze different subsystems of a complex system. Typically, mechanical dynamics, control systems, and electronic components are simulated in separate tools that exchange data at runtime or at predefined synchronization steps, enabling a more comprehensive system-level analysis [21].

A common approach involves coupling multibody dynamics simulators with control design environments. For example, the integration of ADAMS and MATLAB enables simultaneous simulation of mechanical behavior and control algorithms for robotic systems [22]. In such setups, the physics engine computes system dynamics, while the control environment generates actuator commands and processes feedback signals, such as joint positions and velocities. This division allows accurate modeling of both physical interactions and control performance, while reducing reliance on physical prototyping.

Another direction is the development of holistic simulation environments that combine multiple domains within a single framework. HoRoSim, for instance, integrates microcontroller code, electronic circuits, and multibody physics to support robotics education [23]. By combining low-level programming with physics-based simulation, such tools aim to provide a more complete representation of real robotic systems, although they are primarily oriented toward educational use and remain under active development.

Despite these advances, existing co-simulation frameworks are not yet well-suited for Modular Mobile Robotic Systems. The dynamic reconfiguration of MMRSs, requiring frequent changes in topology, constraints, and inter-module communication, introduces significant synchronization and integration challenges across multiple simulation domains. Current solutions typically rely on tightly coupled interfaces or predefined communication structures, limiting their ability to handle large numbers of dynamically interacting modules. As a result, co-simulation remains an open research area for scalable and flexible MMRS simulation.

2.4. Simulation of Modular Mobile Robotic Systems

Simulation of MMRSs remains a niche research area, and many tools are developed alongside specific robotic platforms rather than as general-purpose environments. MMRS simulation is challenging due to the number of interacting modules, distributed control, and dynamically changing topologies, which impose high computational requirements and demand accurate physical modeling [24].

Several dedicated simulation frameworks have been proposed to address these challenges.

USSR (Unified Simulator for Self-Reconfigurable Robot) is an open-source framework that simplifies the process of experimenting with modular robots by providing support for simulating physical interactions and self-reconfiguration in a precise virtual environment [25]. The USSR simulator is based on a physics engine and is built on a layered architecture, which includes layers for robot modeling, physics simulation, and visualization. It enables the simulation of complex dynamics, including friction, stability, and object manipulation. Its flexibility is highlighted by its support for many modular robots and the possibility of quickly integrating new robot types by reusing existing components. USSR is implemented in Java and uses the JMonkey Engine [26] for graphical simulation, providing support for controllers written in Java or C or for a remote controller using sockets.

The simulator has been used in multiple scenarios, including the transformation and locomotion of an ATRON robot [27], which goes through multiple configurations to overcome obstacles and navigate different terrains. USSR has also been used to investigate communication and locomotion strategies of Odin robots [28], and to simulate interactions between different robots (ATRON, Odin, and M-TRAN [29]). These examples demonstrate the capability of the simulator to support advanced research and rapid prototyping in robotics.

VisibleSim is one of the most comprehensive simulation tools available today. This simulator for robotics and multi-agent systems is designed to enable efficient simulation of complex interactions between robots, agents, and dynamic environments. It is mainly used for research and development studies in areas such as artificial intelligence, social robotics, and emergent behaviors [30]. It is designed for the simulation of communications between modules, with limited abilities in physics simulation, robot modeling, and robot control simulation. Additionally, limited documentation and tooling reduce its accessibility for complex experimental setups.

Robot3D is a simulator developed for the self-reconfigurable modular robots of the SYMBRION and REPLICATOR projects [31]. Written in C++, it uses Open Dynamics Engine (ODE) for physics simulation and Open Scene Graph (OSG) for visualization. The simulator includes geometric and physical models of robots (Backbone, Active Wheel, and Scout), sensors, actuators, and connectors that allow the formation of robotic bodies. Through a hardware abstraction layer (HAL), the algorithms developed in the simulation can be implemented directly on real robots, which significantly reduces the gap between simulation and reality.

Robot3D was used to simulate the following robotic systems:

• The AHHS (Artificial Homeostatic Hormone System): A bio-inspired system for decentralized control of locomotion and training of robotic organisms.
• Offline Evolution: Developing and testing evolutionary algorithms that allow robots to form complex organisms.
• Modular Assembly: Development of algorithms for decentralized self-assembly of robotic modules. The simulator has been used for various experiments, including complex challenges such as “100 days–100 robots”, which require long-term stable simulations with numerous robots and modules [32].

Overall, existing MMRS simulators provide valuable capabilities in areas such as self-reconfiguration, communication, and hardware integration. However, they share key limitations, including reliance on outdated software stacks, limited scalability, lack of integration with modern machine learning workflows, and insufficient flexibility for runtime reconfiguration. These limitations hinder their applicability to large-scale, learning-based MMRS scenarios.

Based on these challenges, three platforms—Webots, Pinocchio, and PyBullet—were selected for further evaluation due to their complementary strengths.

3. From Concept to Simulation: Modeling and Evaluating Simulation Strategies for Modular Mobile Robots

This section presents three distinct simulation strategies. These approaches were selected following extensive practical experimentation, with the goal of identifying a simulation framework suitable for scalable MMRS development. The evaluation scenario was intentionally designed to be minimal and controlled, allowing consistent comparison of core performance characteristics and general ease of use. The first approach is based on Webots [32], chosen for its ease of use and graphical interface; the second approach uses the Pinocchio library [33], offering more advanced dynamics modeling at the cost of increased complexity; the third approach is based on PyBullet [34], aiming to balance flexibility and performance. These options will then be compared based on the following criteria:

• Ease of use (environment setup and import of robot model);
• Real-time performance (including the ability to run multiple instances of the simulation concurrently);
• Suitability for modeling Modular Mobile Robotic Systems, focusing on available methods of modeling modular robots.

These three specific criteria have been chosen based on future research goals. Specifically, the use of the simulations will be to help with the development of control algorithms for a homogeneous mobile modular robot, built around autonomous hexagonal modules. Each module will have a dedicated SoC, sensors, and communication capabilities to other connected modules. In terms of movement, each module will be equipped with two differentially driven wheels, effectively turning each module into a Two-Wheel Inverted Pendulum (TWIP) [35]. A similar model has been used for all programs to test their performance.

All simulations were executed on the same hardware platform to maintain comparable testing conditions. Webots and PyBullet were executed natively under Windows, while Pinocchio and Jiminy were evaluated under Ubuntu 22.04 running through WSL2 due to software compatibility requirements. The benchmark focused on relative computational behavior and practical workflow evaluation rather than strict platform-independent performance characterization. The simulation setup was intentionally simplified in order to isolate core constraint handling and runtime performance characteristics. Additional implementation details, including simulator versions, Python environment configuration, and benchmark scripts, are provided in the associated project repository. The specifics of this approach are outside the scope of the current work.

The presented benchmark does not include large-scale module count scalability analysis, complex multi-module reconfiguration sequences, or distributed synchronization stress testing. Instead, the objective of the evaluation was to provide a controlled baseline comparison of simulation workflows, constraint handling approaches, and computational behavior relevant to the early-stage development of MMRS control architectures. Figure 1 presents the schematic and possible configurations of the MMRS considered.

Figure 1. (Left): Schematic representation of a Two-Wheel Inverted Pendulum. (Right): Two possible configurations of hexagonal-body TWIPs forming a modular mobile robot (schematic, top view).

3.1. Simulation Method Based on Webots

Webots is an open-source 3D robot simulator used for modeling, programming, and simulating mobile robots. It provides an integrated environment with a physics engine (ODE-based), graphical interface, and support for multiple programming languages. Robots are defined through a hierarchy of components, including rigid bodies, joints, sensors, and actuators, and each robot can be controlled independently through dedicated scripts.

In Webots, connector nodes are used to simulate docking mechanisms that can create or break physical links between two robots at runtime. Unlike most devices, a connector does not need to be placed strictly inside a robot node. This flexibility allows, for example, one robot with an active connector to dock with a passive fixture in the environment, or with another robot equipped with a compatible connector. Each connection always involves exactly two connector nodes, and these links can be locked or unlocked through the robot controller using the appropriate API. Connector nodes are particularly valuable because they directly support dynamic reconfiguration: modules can dock, undock, and reassemble during simulation without requiring the scene to be rebuilt. An example of such an interaction is given as a sample project inside Webots, showing how YaMoR works inside a virtual environment [36].

In this case, to create an MMRS consisting of two identical modules connected by a rotating coupler, two identical robots were defined. Each of the two modules will have its own control script. In order to create the coupling between the two modules, each one was equipped with two connector elements, one on each side. Figure 2 presents the two modules with the connector elements, as seen in the Webots interface.

Figure 2. Two solids with connector nodes shown in Webots [37].

Webots also provides supervisor scripts, which have access to the entire simulation scene and can control any object within it. Unlike individual robot controllers, supervisor scripts can monitor the position, orientation, and state of all entities; modify simulation parameters at runtime (including adding or removing objects); and directly influence robot behavior by adjusting joints, speeds, or trajectories. This functionality enables centralized data collection and control, making it suitable for tasks such as trajectory optimization, motion planning, and the tuning of control parameters using machine learning or reinforcement learning techniques. Additionally, Webots supports integration with ROS, facilitating distributed simulations, interaction with real robotic systems, and the validation of algorithms prior to deployment on physical hardware.

For modular robot modeling, Webots provides flexibility in defining the mechanical structure and joints, while also possessing certain limitations, such as the difficulty of dynamically reconfiguring modules in real time. However, the use of supervising scripts opens opportunities for optimal control, optimization, and large-scale automation, allowing the simultaneous management of multiple robots and data collection for learning algorithms.

As the number of modules increases, managing connections and synchronization between individual controllers becomes increasingly complex. While connectors allow runtime reconfiguration, coordinating multiple modules through independent scripts and optional supervisor control introduces additional overhead and reduces transparency of the system architecture. This makes it difficult to maintain a clean decentralized control structure when scaling to larger MMRS configurations.

In larger MMRS deployments, this complexity may further increase due to the growing number of communication paths, synchronization dependencies, and dynamically changing constraint relationships between modules. While Webots provides a powerful integrated simulation environment, maintaining deterministic coordination across many independently controlled modules may require additional supervisory logic and communication management strategies. Figure 3 presents a MMRS created in WeBots.

Figure 3. Images with the three modules associated inside the same solid in Webots (simplified URDF model).

3.2. Simulation Method Based on Pinocchio

Pinocchio is a kinematic and dynamic computing library for robots, optimized for speed and accuracy. Developed by LAAS-CNRS and Aalto University, it allows the simulation and analysis of robotic models based on URDF (Unified Robot Description Format) and SRDF (Semantic Robot Description Format) descriptions [33].

Written in C++ with Python bindings, Pinocchio simulates poly-articulated robotic systems using Featherstone’s algorithms [38]. It is widely used in robotic software stacks, including TSID and Crocoddyl [39].

To enable full dynamic simulation, Pinocchio is typically used together with external simulation environments such as Jiminy. Jiminy is a robotics simulator that is based on Pinocchio, providing a robust environment for the dynamic simulation of poly-articulated systems [40]. Developed with a focus on flexibility and performance, Jiminy is intended for optimization studies in robotics. It is used for motion analysis and validation of control algorithms for humanoid robots, exoskeletons, and other complex systems. Jiminy is built on a modular architecture, allowing users to incorporate various physical models and customize their simulations according to specific needs. Figure 4 presents a MMRS running in Jiminy.

Figure 4. Two connected modules in Jiminy (simplified URDF model).

In the context of Modular Mobile Robotic Systems, inter-module connections must be implemented using constraint-based approaches. These constraints can be defined between different robot instances to simulate docking behavior, but require manual implementation and a detailed understanding of the underlying mechanics. Unlike environments with built-in support for modular connections, there is no native abstraction for dynamic reconfiguration, making the modeling process more complex.

Pinocchio-based workflows are widely used in control-oriented robotics applications due to their strong support for analytical rigid-body dynamics, optimization, and state estimation. The framework integrates well with reinforcement learning pipelines and allows fine-grained control over system dynamics, including the ability to introduce noise, delays, and custom physical effects for more realistic simulations.

However, this flexibility comes at the cost of usability. The absence of a graphical interface means that all aspects of the simulation must be configured programmatically, which significantly increases setup complexity. Additionally, the limited availability of documentation and examples, particularly for modular or reconfigurable systems, makes the development process more challenging. While constraint-based modeling is theoretically powerful, it is not well-suited for rapidly prototyping or scaling modular robotic systems with dynamic topologies.

In practice, implementing even simple multi-module interactions required defining custom constraints and carefully managing reference frames, significantly increasing development time compared to higher-level simulation environments. This overhead becomes more pronounced as the number of modules increases, limiting rapid experimentation.

At the same time, the rigid-body dynamics formulation used by Pinocchio may provide advantages for control-oriented robotics applications requiring accurate analytical modeling and state estimation [33,39]. This can be particularly relevant for Two-Wheel Inverted Pendulum (TWIP) systems, where small variations in constraint behavior, contact dynamics, and inertial modeling may significantly influence control stability and overall system behavior. However, these potential advantages come at the cost of increased implementation complexity for dynamically reconfigurable MMRS workflows.

Overall, while Pinocchio provides a highly accurate and flexible framework for robotics simulation and control, its complexity and lack of native support for dynamic modularity limit its practicality for MMRS applications. Additionally, the lack of native Windows support for the evaluated Jiminy workflow introduces additional setup and deployment complexity compared to the other evaluated platforms.

3.3. Simulation Method Based on PyBullet

PyBullet is an open-source Python module built around the Bullet Physics SDK, designed for real-time physics simulation and robotics research. Originally developed for computer graphics and gaming, Bullet has since been adapted for robotics and AI research due to its balance between simulation fidelity and computational performance [34]. PyBullet has become widely adopted for developing and testing control algorithms, particularly in reinforcement learning (RL) environments, and has support for platforms such as OpenAI Gym [41].

Robots in PyBullet are typically defined using URDF or similar formats and instantiated as independent bodies within the simulation. A key advantage of this approach is the ability to create and modify constraints dynamically at runtime. For Modular Mobile Robotic Systems, this enables individual modules to be simulated as separate entities that can be connected or disconnected through programmatically defined constraints, effectively modeling docking and reconfiguration without requiring changes to the underlying robot description.

In this work, each module was implemented as an independent simulated body, with inter-module connections defined through runtime constraints. This approach allows flexible composition of different robot topologies and supports dynamic reconfiguration during simulation. Unlike environments with predefined modular abstractions, PyBullet enables full control over how connections are created, modified, and removed, which is essential for modeling decentralized modular systems. In practice, defining and managing constraints between modules was straightforward and required significantly less effort compared to the Pinocchio-based approach.

Another significant advantage is PyBullet’s support for headless execution and parallel simulation. The simulation can run without a graphical interface, allowing multiple instances to be executed simultaneously, which is particularly important for reinforcement learning workflows that require large amounts of training data. Its integration with Python-based numerical and machine learning libraries further simplifies the implementation of closed-loop controllers and learning algorithms [42].

From a usability perspective, setting up simulations in PyBullet is relatively straightforward once the programmatic structure is established. However, unlike Webots, controller logic and system architecture must be implemented explicitly by the user, which increases development effort. This includes managing constraints, enforcing joint limits, and structuring the interaction between modules.

Despite these limitations, PyBullet offers a strong balance between flexibility, performance, and scalability. Compared to specialized analytical rigid-body dynamics frameworks such as Pinocchio [33], PyBullet prioritizes flexibility, runtime constraint management, and ease of integration with reinforcement learning workflows [41,42]. As a general-purpose real-time physics engine, the resulting trade-offs between computational efficiency, flexibility, and physical fidelity may vary depending on the specific application and modeling requirements.

An additional advantage of the Bullet physics engine is its flexibility in handling runtime constraint creation and multi-contact interactions between rigid bodies. These capabilities are particularly relevant for modular robotic systems involving repeated docking, undocking, and changing physical topologies. While formal validation of contact fidelity was outside the scope of the present work, the practical implementation workflow in PyBullet allowed comparatively simple experimentation with dynamically changing module configurations and decentralized control structure. Figure 5 presents a MMRS simulation running in PyBullet.

Figure 5. Three connected modules in PyBullet (simplified URDF model).

3.4. Comparison Between the Three Simulation Options

The evaluation highlights clear trade-offs between usability, performance, and suitability for Modular Mobile Robotic Systems. Webots prioritizes ease of use and rapid prototyping through its graphical interface and integrated toolchain, but offers limited flexibility for non-standard or highly dynamic applications. Pinocchio provides highly accurate dynamics modeling and strong support for control and optimization, but its purely programmatic interface and limited ecosystem make it difficult to apply in modular robotics scenarios. PyBullet offers a balanced approach, combining flexibility, scalability, and compatibility with reinforcement learning workflows.

To create a quantitative comparison between platforms for this particular use case, two benchmark scenarios were implemented across all evaluated environments. The first scenario, referred to as fixed coupling, consisted of two differentially driven robots connected together throughout the entire simulation and driven forward at a constant speed. The second scenario, referred to as dynamic coupling, evaluated the ability of the simulation environment to support runtime topology modifications by creating and later removing an inter-module connection during the active simulation loop. In this scenario, the two modules initially move independently. When the distance between them falls below a predefined threshold, a connection is established and maintained for a fixed period while the modules move as a coupled system. After this interval, the connection is removed, and the modules continue moving independently. The entire docking and undocking sequence is performed within a 10-s simulation interval. All simulations were executed in headless mode, so as to ensure rendering overhead is removed, using timestep values selected according to recommended practices for each platform. Depending on the timestep configuration, the corresponding number of simulation steps varied between environments. Table 2 presents a comparison of the three simulation environments based on available features and ease of use. The CPU usage, memory consumption, execution time, and real-time factor were recorded, with the results summarized in Table 3. The fixed-coupling scenario was chosen to evaluate computational performance under a constant topology, while the dynamic-coupling scenario assessed the overhead and practical implementation complexity associated with runtime reconfiguration, a key requirement for Modular Mobile Robotic Systems.

Table 2. Comparison of the presented simulation environments in terms of features and ease of use.

Feature	Webots	Pinocchio	PyBullet
Ease of Use	Easiest to use due to GUI Intuitive environment setup and import. High-quality documentation.	Most difficult, no GUI, programmatic setup only. Targeted at advanced users. Sparse tutorials and documentation.	Moderate; programmatic but straightforward. Extensive Python support. Requires programming skills. Good documentation.
Suitability for Modular Mobile Robot Systems	Dynamic reconfiguration built-in. Supports multiple independent control and supervisor scripts.	Constraint-based modeling possible but complex. Supports RL and control optimization.	High flexibility for docking, reconfiguration, cooperative manipulation. Strong for reinforcement learning and control.
External Robot Model Import	Robots are defined as PROTO. Third-party tool allows URDF conversion to PROTO. Primitives available.	Native URDF support. Primitives available.	Native URDF, SDF, MJCF (limited MJCF support). Primitives available.
ROS support	Strong built-in support.	ROS supported.	ROS supported by third-party packages.

Table 3. Comparison of the presented simulation environments in terms of performance.

	Platform	Webots *		Pinocchio *, **		PyBullet *
Measurement	Scenario	Fixed Coupling	Dynamic Coupling	Fixed Coupling	Dynamic Coupling	Fixed Coupling	Dynamic Coupling
Average CPU Usage (% of a single core)		99.5 ± 0.5	99.6 ± 0.5	95.05 ± 10.21	-	97.11 ± 3.86	92.42 ± 2.71
Average RAM Usage (MegaBytes)		213.73 ± 2.39	221.46 ± 2.97	181.86 ± 0.27	-	72.03 ± 0.05	72.83 ± 0.08
Simulation Steps		312	313	1000	-	1000	1000
Average Runtime (seconds)		0.168 ± 0.009	0.386 ± 0.02	0.12 ± 0.0016	-	0.206 ± 0.009	0.216 ± 0.001
Average Real-Time Factor (Simulated Time/Average Runtime)		59.53 ± 2.91	25.89 ± 1.22	83.05 ± 1.16	-	48.5 ± 2.04	46.09 ± 0.25

* Values were obtained on an ASUS FA507-NUR laptop equipped with an AMD Ryzen 7 7435 CPU and 16 GB dual-channel DDR4 RAM at 4800 MHz, running Windows 10 (Webots and PyBullet natively). ** Pinocchio was tested under WSL2 (Ubuntu 22.04).

It is important to note that the presented benchmarks were intentionally simplified and do not fully evaluate several characteristics that are highly relevant to Modular Mobile Robotic Systems, such as large-scale scalability, complex multi-module reconfiguration sequences, distributed control architectures, or communication overhead in large modular assemblies. Nevertheless, the benchmark suite includes both fixed-coupling and dynamic-coupling scenarios, allowing a practical evaluation of runtime connection creation and removal within the simulation environments. As such, the presented results should be interpreted as a controlled comparison of practical simulation workflows and fundamental reconfiguration capabilities rather than a complete evaluation of MMRS performance under all possible operating conditions.

The presented results should be interpreted primarily as a practical comparison of simulation workflows under realistic development conditions rather than as a strictly homogeneous low-level benchmark. Pinocchio/Jiminy was evaluated under WSL2 (Ubuntu 22.04) due to limited native support on Windows, while Webots and PyBullet were executed natively on Windows. This configuration may have influenced the measured performance; however, it reflects the actual development workflow required to use each platform in this study. Consequently, the benchmark evaluates not only computational performance, but also the practical implications associated with deployment, configuration, and day-to-day use.

The results indicate that all evaluated platforms operated within a similar CPU utilization range, generally approaching full utilization of a single processing core. While minor differences were observed, CPU usage alone does not appear to be a decisive factor for platform selection in this application. Memory consumption also remained relatively modest across all tested environments. PyBullet exhibited the lowest memory footprint, requiring approximately 72 MB in both benchmark scenarios, while Pinocchio/Jiminy required approximately 182 MB during the fixed-coupling benchmark. Webots showed the highest memory usage, ranging from approximately 214 MB in the fixed-coupling scenario to 221 MB in the dynamic-coupling scenario. However, all measured memory requirements remained well within the capabilities of modern development systems.

More significant differences were observed in the dynamic-coupling benchmark. PyBullet exhibited only a minor reduction in real-time factor and a negligible increase in memory consumption when runtime connection creation and removal were introduced. In contrast, Webots experienced a noticeable increase in execution time and reduction in real-time factor during dynamic coupling. Dynamic coupling results are not reported for Pinocchio/Jiminy because runtime topology modification is not directly supported within the evaluated workflow. While constraint-based interactions can be modeled in Jiminy, adding or removing constraints between robot bodies during an active simulation is not allowed at this time. Modifying the system topology requires stopping the simulation, updating the robot model and associated constraints, and subsequently restarting the simulation. As a result, runtime docking and undocking events cannot be represented in the same manner as in Webots or PyBullet, where connections can be created and removed while the simulation remains active. These results indicate that, although all evaluated platforms are capable of simulating modular robotic systems, their support for runtime reconfiguration differs considerably and should be considered when selecting a simulation environment for Modular Mobile Robotic System research.

The observed differences are likely influenced by the architectural design choices of each framework. Since all benchmarks were executed in headless mode, the measured resource usage cannot be attributed solely to graphical rendering overhead. The differences are, therefore, more likely related to each simulator’s internal architecture, physics backend, controller execution model, constraint handling mechanisms, scripting interface, and runtime management overhead. Webots benefits from a highly integrated simulation environment with optimized tooling and built-in support for common robotics workflows. PyBullet, while more programmatic in nature, appears to benefit from relatively lightweight runtime abstractions and efficient handling of rigid-body constraints, particularly in the dynamic-coupling benchmark. In contrast, the Pinocchio/Jiminy workflow is centered around analytical rigid-body dynamics and low-level model manipulation, providing strong computational performance in the fixed-coupling benchmark but requiring substantially greater implementation effort for runtime topology modification. These architectural differences highlight the trade-offs between computational performance, ease of use, and support for dynamic reconfiguration when selecting a simulation environment for Modular Mobile Robotic System research.

The fixed-coupling benchmark revealed notable differences in computational performance between the evaluated platforms. Pinocchio/Jiminy achieved the shortest average execution time and highest real-time factor in this scenario, indicating strong computational efficiency for fixed-topology simulations. Webots also demonstrated strong performance, while benefiting from a highly integrated simulation workflow and built-in support for modular robotics applications. PyBullet achieved a lower real-time factor than the other evaluated platforms, although it remained capable of executing the benchmark significantly faster than real time. Given the relatively small execution times observed across all platforms, the performance differences should be considered alongside other factors, such as ease of use, support for runtime reconfiguration, available tooling, and integration with external software frameworks.

The results obtained in this study reinforce the notion that no single simulation environment is universally optimal for all robotics applications. Previous comparative studies similarly concluded that simulator selection is highly application-dependent, with Webots often favored for usability and resource efficiency, while PyBullet is frequently adopted in scalable and learning-oriented workflows [43,44,45] where different frameworks are often selected based on the requirements of a particular task. Hybrid simulation architectures integrating PyBullet-based physics simulation with external kinematic and dynamic computation frameworks have been explored in the literature [46], highlighting the complementary strengths of these tools.

The dynamic-coupling benchmark further highlighted the advantages of simulation environments that support runtime creation and removal of constraints. In this regard, PyBullet and Webots provided practical mechanisms for dynamic reconfiguration, whereas implementing equivalent functionality in the Pinocchio/Jiminy workflow proved considerably more challenging.

Previous studies comparing robotics physics engines have identified significant differences in contact handling, constraint satisfaction, and numerical stability between engines such as ODE and Bullet. Erez et al. [47] reported that simulation accuracy and stability are strongly dependent on the specific task and contact conditions being modeled, with no single physics engine consistently outperforming all others across the evaluated benchmarks. Pinocchio-based workflows are widely adopted in robotics due to their efficient implementation of rigid-body dynamics algorithms and analytical derivatives, making them particularly suitable for optimization, state estimation, and control-oriented applications. Consequently, the present work does not attempt to draw conclusions regarding absolute physics fidelity and instead focuses on practical MMRS-oriented workflow considerations.

Within the evaluated workflow, Webots achieved stronger results for several quantitative metrics, particularly the real-time factor. However, PyBullet provided greater flexibility for runtime constraint management, dynamic reconfiguration, and integration with reinforcement learning workflows. Considering the requirements of the targeted Modular Mobile Robotic System, the additional flexibility offered by PyBullet was considered more important than the observed differences in computational performance.

4. Conclusions

This work set out to evaluate several simulation strategies for Modular Mobile Robotic Systems, with the goal of identifying a platform suitable for the development and evaluation of dynamically reconfigurable MMRS control architectures. Three approaches were investigated, based on Webots, Pinocchio (with Jiminy), and PyBullet, each representing a different trade-off between usability, accuracy and flexibility.

The results highlight that no single platform is universally optimal. Webots provides a highly accessible environment with strong integration and low resource usage, making it well-suited for rapid prototyping. Pinocchio offers advanced dynamic modeling capabilities and high accuracy, but requires significant effort to configure and lacks direct support for modular and reconfigurable systems. PyBullet, while requiring more implementation effort compared to Webots, offers a flexible and scalable framework that supports dynamic reconfiguration, parallel simulation, and integration with reinforcement learning workflows.

The multi-criteria evaluation, supported by both quantitative benchmarks and qualitative assessment, indicates that PyBullet provides a suitable and flexible solution for the targeted application within the scope of this study. Its support for independently defined modules connected through runtime constraints aligns well with the proposed MMRS modeling strategy and enables straightforward implementation of modular robotic structures. Although the implementation used in this work is not fully optimized, the performance results remain competitive, while the platform provides a high degree of flexibility for the evaluated workflow. Based on the presented results and within the scope of the evaluated benchmarks, PyBullet emerged as the most suitable platform among the evaluated options for further development of the proposed MMRS simulation framework.

It is important to note that the evaluation scenario was intentionally simplified in order to isolate core simulation characteristics. As a result, the presented benchmarks should be interpreted as indicative rather than definitive. The implemented benchmark did not include large-scale multi-module configurations or complex topology reconfiguration sequences. Consequently, conclusions regarding large-scale MMRS behavior, dynamic reconfiguration performance, and scalability should be considered preliminary and require further experimental validation. Additionally, the work focused primarily on computational performance and usability considerations and did not include a quantitative validation of simulation accuracy against analytical models or physical hardware. Moreover, the Pinocchio-based approach was evaluated under WSL2, which may have influenced performance results. A more controlled comparison across identical environments represents a direction for future work.

Beyond the comparison of simulation platforms, an important outcome of this work is the identification of a practical modeling strategy for Modular Mobile Robotic Systems. By representing each module as an independent simulated body and managing inter-module connections through runtime constraints, the overall system can be modeled as a dynamically reconfigurable structure. This approach avoids the limitations of monolithic kinematic trees and enables flexible topology changes without requiring reconstruction of the robot model. Furthermore, such a representation naturally aligns with decentralized control architectures and learning-based methods, which are central to future developments in modular robotics.

Building on these findings, future research will focus on extending the benchmark methodology to include larger-scale modular assemblies, more complex reconfiguration sequences, scalability evaluations, and experimental validation against physical robotic hardware. Additional work will also focus on leveraging the PyBullet-based framework for the development and evaluation of control strategies for modular mobile robots, including reinforcement learning approaches and decentralized control architectures.