Toward Digital Twin of Off-Road Vehicles Using Robot Simulation Frameworks

Received 28 October 2024, accepted 25 November 2024, date of publication 29 November 2024, date of current version 9 December 2024. Digital Object Identifier 10.1109/ACCESS.2024.3509226 Toward Digital Twin of Off-Road Vehicles Using Robot Simulation Frameworks ARIANNA RANA 1,2, ANTONIO PETITTI 1, ANGELO UGENTI 2, ROCCO GALATI 2, GIULIO REINA 2, AND ANNALISA MILELLA 1 1Institute of Intelligent Industrial Technologies and Systems for Advanced Manufacturing (STIIMA), National Research Council of Italy (CNR), 70126 Bari, Italy 2Department of Mechanics, Mathematics, and Management, Polytechnic University of Bari, 70126 Bari, Italy Corresponding author: Antonio Petitti ([email protected].it) This work was partially funded by the following projects: AgRibot-Harnessing Robotics, XR/AR, and 5G for a New Era of Safe, Sustainable, and Smart Agriculture, European Union’s Horizon Europe research and innovation programme under grant agreement (No.101183158); giving Smell sense To Agricultural Robotics (STAR), ERA-NET COFUND ICT AGRI-FOOD (Grant No. 45207); CNR Dipartimento di Ingegneria, ICT e Tecnologie per l’Energia e i Trasporti (DIITET) project DIT.AD022.207, STRIVE-le Scienze per le TRansizioni Industriale, Verde ed Energetica (FOE 2022), sub task activity Agro-Sensing2. This publication is also part of the project Nord Ovest Digitale e Sostenibile (NODES), which has received funding from the Ministero dell’Università e della Ricerca (MUR)–M4C2 1.5 of Piano Nazionale di Ripresa e Resilienza (PNRR) funded by the European Union–NextGenerationEU (Grant agreement no. ECS00000036). ABSTRACT Digital twins provide a powerful tool for testing and maintaining products and processes in several application fields, including manufacturing, smart cities, healthcare, and agriculture, aiming to optimize operational efficiency, resource usage, and planning accuracy. Research presented in this paper deals with the development of the digital version of off-road vehicles. Two different robot simulation frameworks are investigated. The first one is based on Gazebo, an open-source 3D robotics simulator, to test and validate the algorithms developed in the ROS framework; the second one adopts the vehicle mechanical assembly in MSC Adams, a multibody modeling software used to study the dynamics of complex mechanical systems. Both models are developed for a tracked robot that uses an innovative articulated passive suspension system on either side that allows each ground wheel to move independently with respect to the vehicle body, providing remarkable adaptability to irregular terrain. In addition, a Gazebo model is developed for a four-wheel drive/steering robot, including robot sensors such as GNSS, IMU, and visual sensors and a model of a typical agricultural environment (i.e., a vineyard). The paper presents the details of model design and implementation while investigating the best choice in developing the digital twin of off-road vehicles operating in the field. Additionally, an agricultural scenario has been selected as a use case to facilitate the evaluation of the analyzed frameworks. Our findings demonstrate that the Gazebo framework could serve as a suitable robot simulation framework for creating digital twins of vehicles, provided it incorporates real-time sensor measurements designed for identifying soil-wheel interaction dynamics. In contrast, the multibody model provides a higher-fidelity dynamic model, including track-terrain interaction. Despite its advantages, this model has substantially higher computational costs, which limits its applicability to realtime simulations, making it less feasible for practical use in the field. INDEX TERMS Agricultural robotics, digital twin, field robotics, mobility over deformable terrain, multibody modeling and simulation, robot simulation frameworks. I. INTRODUCTION A Digital Twin (DT) [1],[2] is a digital, typically computational, representation of a process or a tangible entity like a robotic vehicle. Creating a DT involves artificial The associate editor coordinating the review of this manuscript and approving it for publication was Lukasz Wisniewski . intelligence, machine learning, and/or software analytics alongside physics-based modeling to construct a digital simulation model capable of replicating the characteristics and actions of the physical counterpart [3]. To achieve this, the model often requires ongoing training and refinement using sensor data and a probabilistic computational framework that accommodates uncertainties [4]. Digital twins VOLUME 12, 2024 2024 The Authors. This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see https://creativecommons.org/licenses/by-nc-nd/4.0/ 178047 A. Rana et al.: Toward Digital Twin of Off-Road Vehicles Using Robot Simulation Frameworks are increasingly prevalent in various application fields such as industry, manufacturing [5], aerospace [6], smart cities, healthcare [7], agriculture [8], etc [9]. In [10], a focus on the precise state synchronization between the DT of a mobile robot and the physical asset is given. The proposed approach deals with the correct position evaluation in the smart factory context. In [11], on the other hand, the DT has been used to test localization and navigation algorithms under different operating conditions for an autonomous vehicle in a production hall. Moreover, another approach of the DT has been proposed in [12], where the system is composed of a human operator equipped with an exoskeleton robot and a virtual reality device. Information between the various parts of the system is exchanged in real-time to accelerate the instruction of robotic tasks in production environments. In [13], a digital twin of a commercial VTOL convertiplane aerial vehicle has been developed in Gazebo, enabling comparison of take-off, hovering, and landing maneuvers with and without the wind physics model. However, significant advancements are still needed, especially in addressing challenges related to outdoor environments [14],[15],[16]. In [17], digital twins are proposed as a suitable tool for virtual prototyping and damage detection in space exploration rover applications. However, as this is a preliminary feasibility study, no validation and verification have been presented. In [18], the digital twin of a pasture was developed, which is mainly for technical verification and data acquisition based on machine vision. Furthermore, [19] proposes a DT prototype in a smart farm. In particular, the DT serves as a substitute for the physical system during the development phase of a smart farming application. A DT comprises three components: the physical asset, the corresponding virtual counterpart, and the linking data exchange. This paper focuses on developing a virtual representation of off-road robotic vehicles. Although many 3D simulators to simulate robots in outdoor environments under different conditions are available [20],[21],[22], we explore two distinct simulation environments. The first employs ROS and Gazebo 11 to test and validate algorithms developed within the ROS framework, while the second leverages the vehicle mechanical assembly within MSC Adams. Gazebo [23] is an open-source simulation software born in 2002 at the University of Southern California as part of a Ph.D. research project. It is one of the most famous simulator frameworks used by the robotic community [21],[24],[25]. It is a powerful software tool that offers a comprehensive 3D simulation environment for creating and simulating various robotic systems, environments, and scenarios. One of its key advantages is the ability to test and validate algorithms, observe robotic behaviors, and more in a safety environment [26],[27]. Furthermore, Gazebo allows us to model robots, specifying their physical properties, i.e., collision, visual appearance, and inertia. It also provides a wide range of sensors that can be added to the robot model [28], providing perception capabilities and allowing the evaluation and experimentation of perception, planning, and control algorithms. Gazebo is often used alongside robotic frameworks [29]. Specifically, it has a strong integration with ROS, whereas Gazebo is employed to test and validate robotics applications, which are developed in ROS, for example, in a simulated environment before deployment in the real world. The Gazebo ROS package facilitates the communication between ROS and Gazebo. This package acts as a bridge, enabling the simulation of ROS-based robotic systems within the Gazebo environment. Therefore, developers can combine their ROS code with Gazebo, allowing them to test and assess the performance of their developed algorithms. MSC Adams, on the other hand, is a software package used for multi-body dynamics simulation. It is a widely used tool in engineering, particularly in the fields of mechanical, automotive, aerospace, and other industries where the behavior of interconnected moving parts needs to be analyzed. Moreover, the built-in toolkit Adams Tracked Vehicle (ATV) is designed specifically for simulating and analyzing the dynamics of tracked vehicles. This simulation environment also includes tools to simulate the interaction between the tracks and different types of terrain, including soft soils. The software also allows for the simulation of suspension systems, including track tensioning devices. Because of these features, MSC Adams is able to simulate the dynamics of an off-road robot with much higher accuracy than Gazebo. On the other hand, because of the higher computational burden and lack of simulated exteroceptive perception, the multibody model might be challenging to implement for a real-time digital twin application. The aim is to define the DT of an off-road robotic vehicle to exploit the advantage of the two distinct robotics simulators while investigating the possibility to be continuously updated using sensory data. Specifically, the contribution of this paper is twofold: (i) the Gazebo visual models of two custom-built off-road vehicles have been developed; (ii) an extensive comparison between Gazebo and MSC Adams has been undertaken to determine the most suitable framework for developing the digital twin of off-road vehicles operating in field conditions. The paper is organized as follows. Section II provides an overview of the robotic platforms. Section III details the development of visual models for the two robots created in Gazebo, while Sec. IV briefly introduces the multibody model developed in MSC Adams. Section Vdescribes the tests conducted using the two simulators, focusing on a specific agricultural robotics use case, and, finally, Sec. VI our conclusions from the investigation are drawn. II. ROBOTIC PLATFORMS In this paper, two custom-built off-road vehicles, namely a tracked robot and a wheeled robot, are considered, respectively, available at Politecnico of Bari, Italy, and at CNR-STIIMA, Italy. 178048 VOLUME 12, 2024 A. Rana et al.: Toward Digital Twin of Off-Road Vehicles Using Robot Simulation Frameworks The fully functioning prototype of the all-terrain tracked rover named Polibot [30] is shown in Fig. 1, while Fig. 2 presents a CAD rendering with the indication of the overall dimensions highlighting also how the rubber track is wrapped around the drive sprocket at the top, the idler wheel at the front, and the four ground wheels. The distinctive feature of the tracked locomotion system includes an articulated passive suspension system on each side, enabling individual movement of each ground wheel and improving adaptability to uneven terrain. Moreover, the four road wheels distribute the vehicle’s weight across the contact patch. FIGURE 1. The Polibot equipped with a multi-sensor system. FIGURE 2. Isometric CAD view of the Polibot with the indication of the main dimensions. As reported in Table 1, Polibot is based on the Robot Operating System (ROS) and is equipped with two 350 W 24 VDC brush motors, each coupled with an angular gearbox with a 30:1 reducing ratio. The driving motor and the angular gearbox have been selected to deliver a peak torque of 35Nm TABLE 1. Technical specifications for Polibot. at 80 RPM with a maximum payload of 50 Kg in addition to the possibility to overcome slopes up to 40 degrees. The undercarriage comprises two subframes attached to the main body frame via two brackets. Attached to the subframes via revolute joints, four swing arms can rotate independently carrying a road wheel each. The powertrain components are housed within the central chassis, while the output shaft is directly connected to the drive sprockets. The material used for the belt is a composite of melted natural rubber and fiberglass, with an inner steel cord. All wheels are constructed from UHMW, a high-density polyethylene known for its exceptional wear resistance. Polibot features an upper flat surface designed to accommodate additional devices and sensors such as cameras, LiDARs, IMUs, or laptops. Embedded in the main body, an Intel i7 computer has 16 GB RAM DDR, 256 GB SSD, Wi-Fi, and Bluetooth interfaces. The primary operating system on the computer is Ubuntu, which is utilized for running ROS and commanding the motor controllers via an RS232 serial port. The primary power source comprises a 24 VDC 30 Ah LiPo battery pack providing a standard autonomy of approximately 3 hours. The second robot architecture considered in this work, here referred to as CNRbot, is a four-wheel driving and four-wheel steering vehicle with a rocket suspension system based on two swing arms able to rotate around a horizontal axis while anchored to a set of dampers; this design is essential to keep the mainframe as stable as possible by reducing vibrations even on rough terrains by enhancing the efficiency of the sensors (i.e., cameras, lasers, and IMUs) installed on the vehicle. The vehicle prototype is shown in Fig. 3, whereas the CAD model is reported in Fig. 4. CNRbot, is a ROS wheeled platform providing an Ackermann steering geometry, which can be equipped with various proprioceptive and exteroceptive sensors that provide highly accurate information about the environment and the vehicle’s operational conditions. CNRbot has been designed with a total of four brushless driving motors and four planetary gearboxes with a gear ratio of 4:1 to properly adjust both the output torque and velocity, providing up to 40 Nm with an overall peak torque of about 50 Nm when spinning at 80 RPM. In this case, the maximum payload is 100 Kg with a capability to overcome slopes up to 40 degrees. To enhance the stability and the performance of the motors making them reach the desired speed with minimal delay and VOLUME 12, 2024 178049 A. Rana et al.: Toward Digital Twin of Off-Road Vehicles Using Robot Simulation Frameworks TABLE 2. Technical specifications for CNRbot. overshoot, a PID controller has been implemented in both robots to control the vehicle in Closed Speed Loop by using the data coming from the motors encoders. Thanks to its 10-inch off-road wheels, it can be used both for indoor and outdoor applications, and its high payload allows users to add additional devices and laptops. The large ground clearance enables the vehicle to operate in terrains with high density of obstacles such as rocks and debris. The rear panel offers several power outputs in order to connect external sensors and devices. This wheeled mobile robot (WMR) is electrically powered by two fully isolated AGM batteries with a power output rating of 2400 W. Table 2summarizes the main electric and mechanical features for the CNRbot. Finally, both robots can be remotely controlled using a standard joystick controller that operates via wireless or radio technologies. The operating range of the device depends on the communication technology used. With wireless technology, the range is approximately 10 meters, while radio technology allows for a significantly extended range. III. ROS-GAZEBO MODEL OF THE ROBOTIC PLATFORMS This section describes the implementation of the visual model of the two vehicles presented in Sec. II and the development of a simulated environment. A. UNIFIED ROBOTIC DESCRIPTION FORMAT In Gazebo, a simulated model of a robot is generated using the Unified Robotic Description Format (URDF) [31]. URDF is an XML file format widely used in the ROS (Robot Operating System [32],[33], a framework for developing robotics systems) environment as it provides a means to describe the kinematics, dynamics, and visual aspects of the robot model. In general, a URDF file is used to describe a robot as a tree of links connected by joints. The links refer to each physical component of the robot, while the joints represent how a link moves relative to another link by defining the location of the links in space. The visual model can be created using basic geometric shapes, such as cubes, cylinders, spheres, and more, or specific meshes for a more detailed and realistic representation of the model itself. For this study, the following steps are performed. First, a CAD assembly of the robot is built in SolidWorks (SW) FIGURE 3. The robot CNRbot with its sensor suite. FIGURE 4. Isometric CAD view of the all-terrain rover CNRbot with the indication of the main dimensions. (a 3D design software suite). Then, the model required by the ROS-Gazebo framework is generated by employing a software tool called SolidWorks to URDF exporter [34]. The 178050 VOLUME 12, 2024 A. Rana et al.: Toward Digital Twin of Off-Road Vehicles Using Robot Simulation Frameworks software tool enables the conversion of the CAD model and generates a ROS-like package that incorporates information about meshes, materials, textures, and the URDF file. The URDF file includes the different elements (rigid bodies) composing the vehicle. It is critical to define the elements in the right order to correctly build the tree that describes the kinematic relationships between the components of the vehicle.1Furthermore, the URDF file generated by the tool contains information regarding the visual representation of the CAD model converted into the specific format STL (STereo Lithography interface) for visualization in ROS. The tool also generates collision geometry information and physical properties such as mass, inertia, and other parameters required by physics engines like Gazebo, which will be discussed in more detail in Sec. III-C. The steps followed to obtain the digital model of the vehicles are as follows: 1) Design the rover with CAD software; 2) Open ‘‘Solidworks to URDF exporter’’ environment; 3) Select the first link, called the base link, i.e. the main component from which all child links are derived. Each URDF has solely a base link; 4) Select the necessary number of children that each parent link will have; 5) For each parent-child connection, assign the type of joint (e.g., revolute, prismatic, fixed, etc.) that connects them. For each joint, it is necessary to set several properties, such as position limits, velocity, effort, axis of rotation/translation (only for movable joints), etc. 6) Export the URDF file and associated files, such as meshes, materials, and textures required for the visual and physical representation of the robot. It is important to give a unique name to each link and each joint. In Fig. 5, the flow chart representing the steps used to obtain the digital model of the vehicles is shown. B. VISUAL ROBOT MODELS USING URDF Since Polibot and CNRbot are customized robots, visual models have been created following the procedure described in Sec. III-A. The URDF models of the Polibot and CNRbot, respectively, are described in the remainder of this section. As stated in Sec. II, the Polibot is a tracked robot [35],[36]. However, for ease of implementation, since a tracked robot employs a skid steering mechanism, each track is simulated as two wheels, which are controlled with the same velocity reference [37]. Moreover, defining the transmission attribute for each non-fixed joint is necessary to simulate it properly. Thus, four transmission attributes have been defined for the Polibot, one for each wheel. Finally, to complete the model and enable the robot to move, a controller [38] for skid steer driving is set to control the wheels’ velocity. In Fig. 6, the URDF model of the Polibot in the RViz [39] environment is shown. RViz is a 3D visualization tool integrated into ROS 1This translates into the TF (TransForm) tree of the coordinate transformations in the ROS environment. FIGURE 5. Flow chart of the methodology used for developing the URDF model. that enables visualization of the robot model with its links and joints and provides an interactive, real-time view of the environment around the robot. As can be observed, the robot is equipped with a simulated sensor suite mounted on board that represents the real sensors. The sensor is considered an extension of the robot itself, so the geometric shape of the sensor can be defined within the URDF file of the robot itself. Moreover, the simulated sensor emulates the behavior of the real sensor, extracting information about the environment and interacting with ROS. Specifically, the Polibot is equipped with an Intel Realsense D435 camera, a GPS receiver, an IMU sensor, and a Velodyne LiDAR, which enable the perception of the surrounding virtual environment. Sensor data, such as point clouds, camera images, laser scans, and more, can be visualized in RViz. On the other hand, the CNRbot has four driving and steering wheels [40]; thus, four attributes for the steering angle and four attributes for the wheel rotation have been defined. Consequently, a controller must be defined to enable the robot to move in the environment and simultaneously control all the wheels. For ease of implementation, the skid steering driver is used for this robot. Fig. 7depicts the URDF model of the CNRbot in RViz, equipped with a simulated sensor suite composed of an Intel Realsense D435 camera, a GPS receiver, and an IMU sensor. C. SIMULATED ENVIRONMENT This section introduces a Gazebo simulated environment. From now on, we will refer to the simulated environment as the world. Creating a world in Gazebo means creating an SDF (Simulation Description Format) model, which allows for the description and definition of different entities, such VOLUME 12, 2024 178051 A. Rana et al.: Toward Digital Twin of Off-Road Vehicles Using Robot Simulation Frameworks FIGURE 6. RViz visualization of the URDF model of the Polibot with the simulated sensor suite mounted on board. The robot is equipped with the following sensors: an Intel Realsense D435 camera, depicted as the grey element mounted at the top; a GPS receiver, represented by the blue cube; an IMU sensor, represented by the orange cube; a Velodyne LiDAR, represented by the black cylinder on the chassis. FIGURE 7. RViz visualization of the URDF model of the CNRbot with the simulated sensor suite mounted on board. The robot is equipped with the following sensors: an Intel Realsense D435 camera, depicted as the grey element mounted at the top; a GNSS receiver, represented by the blue cube; an IMU sensor, represented by the orange cube. as robots, sensors, objects within a specific environment, and more. URDF and SDF are XML-based file formats used in the robotics environment, but they serve different purposes. The first describes the robot’s structure, including joints, links, visual appearance, and collision properties; the second, on the other hand, is dedicated to describing the entire simulated environment in which the robot operates. It may include multiple robot models, sensors, physical properties of the world, and other details. Fig. 8illustrates the distinction between URDF and SDF. FIGURE 8. Gazebo scene featuring a comparison of a URDF (yellow square) and SDF (red square). For convenience, in this work, the robot and sensor models are defined in the URDF file because the SolidWorks tool generated the robot model, as explained in Sec. III-A. The SDF model comprises three main components: links, joints, and plugins. The link contains information about a specific model element’s visual and physical properties. Specifically, it describes how the link appears, i.e., the shape or the mesh, and the collision properties used for collision-checking purposes. Moreover, it includes the dynamical properties, such as mass, center of mass, and moments of inertia, and the surface properties, such as friction, bounciness, and more. On the other hand, a joint specifies the connection between two links, enabling the creation of complex articulated objects. Sensors are considered as a part of the robot model. Consequently, it is necessary to create a link representing the geometrical shape to which the sensor is attached and the joint to connect it to the main part of the robot. Moreover, the sensor element is added to the link, specifying the sensor type (e.g., camera, LiDAR, IMU, GNSS receiver, etc) and specific sensor parameters. To replicate the real-world behavior of the sensor in the simulated environment, plugins are used [28]. These plugins are shared libraries, providing additional behaviors and capabilities to the simulated objects in Gazebo. Each sensor has several configurable parameters to match the specifications of its physical hardware, allowing for realistic simulation. For example, in the case of the camera, it is possible to set the horizontal and vertical field of view (FOV), while for a LiDAR, parameters such as the range, the number of rays or channels, the resolution, and the update rate can be configured. Additionally, it is possible to apply the Gaussian noise, which allows the sensor to replicate its real-world behavior closely. Gazebo provides the Model Database containing several predefined SDF models [41], including simple shapes like boxes, spheres, cylinders, and more complex objects like cars, people, buildings, and more. However, users can create their own SDF model, either as a combination of simple shapes or as complex meshes using a 3D modeling tool, such as Blender [42], or available in many online repositories. Regarding our simulated environment, Fig. 9shows a vineyard available online [43], converted into a Collada file using Blender and imported in Gazebo. Alternatively, the scene can be generated by creating a 3D map of the 178052 VOLUME 12, 2024 A. Rana et al.: Toward Digital Twin of Off-Road Vehicles Using Robot Simulation Frameworks FIGURE 9. Simulation environment obtained from a 3D tool. environment by converting captured point clouds to a real environment using a 3D visual sensor, such as a camera or LiDAR. To create a 3D map based on the point cloud of the environment, a meshing algorithm is used [44]. This algorithm facilitates the generation of a mesh-based representation for map import in the Gazebo simulation environment, following these outlined steps: 1) Downsampling The obtained dense map is an optional yet advantageous step that accelerates the mesh reconstruction process and enhances the overall outcome. To fulfill this task, samples are generated following a Poisson-disk distribution [45]; 2) Knowing the normals is essential for reconstructing the surface of the elements that make up the map; 3) The reconstruction of the surface begins from the set of points and normals. A triangle mesh is computed employing The Ball Pivoting algorithm [46], which is based on the principle that three points constitute a triangle if a ball of a user-defined radius touches them without encompassing any others; 4) Texture mapping is created by triangle-by-triangle parameterization; 5) Projecting a 2D image onto the surface a 3D model for texture mapping is called UV mapping [47]. When the UV map is ready, the color can then be transferred to the reconstructed surface; 6) The mesh can be exported. Therefore, the 3D map can be used to create a Gazebo SDF model. Fig. 10 showcases a vineyard row obtained by following the procedure explained [44]. D. LIMITATIONS This section outlines the limitation of Gazebo. Gazebo does not natively support deformable terrain. This is the main issue in using Gazebo as a simulation framework for the development of the DT. Thus, simulating the dynamics of wheel/soil interaction is not possible. IV. MULTI-BODY MODEL In order to compare the two simulation frameworks, we developed the Adams model of the Polibot, the robot for which simulation in Gazebo would be more challenging. This FIGURE 10. Simulation environment reconstructed starting from real data acquired in the field by means a RGB-D camera. approach aimed to enhance the effectiveness of analyzing the two simulators. In MSC Adams ATV, the multibody model of Polibot is constructed as an assembly of seven independently modelled subsystems that are later invoked and integrated. As shown in Fig. 12, these seven subsystems are: the hull, the drive sprocket, the front, middle, and rear suspension units with their road wheels, the track belt, and the sensor frame. Each subsystem is made up of different parts joined together. For example, the front swing arm is composed of 4 parts, namely the swing arm, the tensioner, the idler wheel, and the road wheel. The biggest subsystem in terms of number of parts is the track belt. A single track comprises 56 elements, and each element is made of two parts (a segment and a connector). This means that both tracks yield a part-count of 224 bodies. The whole Polibot assembly is made up of 267 parts. To maximize the accuracy of the model, all the parts of the robot were exported from the 3D CAD models as Parasolid files and then imported into MSC Adams. The inertial properties of all the components are coherent with those of the real prototype. The overall mass of the assembly is 125 kg, and its center of gravity is located 40 mm ahead of the driving axle and 242 mm above the ground. The vehicle powertrain is made up of a reducer that connects the motor shaft to the sprocket, which then engages with the track, one per each side. Either a prescribed angular velocity or torque can be assigned to the motor shafts. The front suspension subsystem comprises four rigid bodies: two parts constituting the swing arm, a road wheel, and the idler wheel. One of the parts of the arm is hinged to the hull via a revolute joint so that it is free to pivot about the attachment point. Such rotation is opposed by a linear spring-damper force defined to model the shock absorber placed between the arm and the chassis. The other rigid body forming part of the front suspension arm is connected to the pivoting one by means of the track tensioning unit, which changes the relative position of the two parts via a translational joint. The middle road wheels are carried by two swing arms constrained to the hull via revolute joints and linked to one another by means of a linear spring-damper force. Although VOLUME 12, 2024 178053 A. Rana et al.: Toward Digital Twin of Off-Road Vehicles Using Robot Simulation Frameworks the rotations of the two arms of the middle suspension unit are kinematically independent, the presence of the elastic element makes sure that when one wheel is lifted, the other is pushed against the ground, thus allowing the track to better adapt to the obstacles and the uneven profile of the terrain being traversed. The Polibot prototype presents rubber-made tracks reinforced with steel cable souls. Within the ATV toolkit the track is composed of a discrete number of segments, which are automatically wrapped around the rolling elements before the simulation. The methodology followed to build the multibody model of Polibot in Adams is shown in Fig. 11 and can be summarized as follows: 1) Design the rover with a CAD software; 2) The geometry of all the parts of the robot are exported as Parasolid files extracted from 3D CAD elements; 3) Parasolid files are imported in MSC Adams and converted into rigid bodies. The rigid bodies are connected via revolute, translational or fixed joints, and the obtained sub-assemblies are saved as Templates; 4) Templates are used to create independent symmetric subsystems on each side of the main body; 5) Subsystems are integrated to form the assembly to simulate; 6) The track element subsystem is wrapped around the road wheels and sprocket to create the track belts; 7) Finally, the soil geometry and the parameters are defined. FIGURE 11. Flow chart of the methodology used for developing the multi-body model. For more details on the multibody model of Polibot (e.g. inertial parameters, contact modeling, validation against experimental data) the reader is invited to refer to [48]. FIGURE 12. Polibot multibody assembly and subsystems. A. LIMITATIONS This section addresses the limitations of the multi-body model developed with MSC Adams. These mainly relate to two aspects: computational cost and track-ground interaction modeling. As stated above, the multibody model of Polibot is made up of 267 different bodies which, together with all the constraints linking them, bring the number of equations solved by MSC Adams at each time step to 1824. This causes a high computational cost, especially on soft soil (such as sand or loam). For example, a computer with an Intel Core i74870HQ CPU clocking at 2.50 GHz and with 16 GB of RAM, using 3 threads in parallel, simulates 1 second of Polibot’s dynamics on loam in about 2940 seconds, which makes the multibody model unsuitable for real-time simulations, unless a much more powerful system is integrated. The second main limitation regards the track-ground interaction modeling. On soft soils, MSC Adams uses Bekker’s equation [49] as pressure-sinkage relationship: p=kc b+kφzn(1) where zis the sinkage, pis the pressure, bis the width of the contact patch, n,kc, and kφare terrain-specific pressuresinkage parameters. The exponential equation by Janosi and Hanamoto [50] is used as shear displacement - shear stress relationship: τ=(c+ptan φ)1−e−s/Ks(2) where τis the shear stress, cand φare, respectively, cohesion and internal friction angle of the terrain, Ksis the shear deformation modulus, sand pare the shear displacement and the pressure at the point in which the shear stress is to be calculated. Although these models are widely used in terramechanics [51], they rely on parameters that must be determined experimentally for each type of soil, which limits their 178054 VOLUME 12, 2024 A. Rana et al.: Toward Digital Twin of Off-Road Vehicles Using Robot Simulation Frameworks general applicability across different terrains and soil types. However, the alternative to classic terramechanics models is the integration of a FEM model of the terrain, which would worsen the computational burden of the system. More importantly, the multibody model of Polibot has been extensively validated against experimental data [48], proving that the dynamics of Polibot can be replicated with a good level of accuracy. Finally, it is worth recalling that sensor data cannot be simulated or integrated in MSC Adams, and therefore the robot cannot interact with the environment. V. RESULTS AND DISCUSSION In this section, we assess the suitability of the two robotic simulators concerning the implementation of the DT of the Polibot. To this aim, we simulate a common agricultural task by means of both frameworks. The task objective is to inspect a field organized in rows, such as in the context of a vineyard. A. ROW FOLLOWING ALGORITHM The goal of the simulated task is to follow a parallel trajectory with respect to the row while maintaining a constant distance to prevent collisions with and monitor crops [52],[53],[54]. To this aim, the robot is equipped with an RGB-D camera pointing on the row, an IMU, and a GNSS receiver to estimate the relative pose with respect to the current row. The relative pose of the robot, expressed by the relative orientation and the distance of the robot with respect to the current row, is used to feed the control algorithm. Specifically, the orientation of the robot is regulated by acting on the angular velocity whose value is given by a weighted sum of the distance and orientation error. On the other hand, the linear velocity of the robot is set at a constant value. The control law applied is as follows: v=σ ω=k1(d−¯ d)+k2(γ− ¯γ),(3) where vand ωare the linear and angular velocity, respectively; dand γare the distance and orientation of the robot w.r.t. the vineyard row; σand ki, for i=1,2, are constants greater than 0; finally, ¯ dand ¯γare the desired distance and orientation of the robot w.r.t. the vineyard row. For more details on these topics, readers are encouraged to consult the related articles [55] and [56]. B. SIMULATION SETUP The same simulation setup has been implemented in both Gazebo and MSC Adams. Specifically, in Gazebo, we have simulated the presence of a real vineyard row in the environment. Additionally, the robot simulation was completed by incorporating an appropriate sensor suite, namely an RGB-D camera, a GNSS receiver, and an IMU sensor, to validate and test the performance of the entire algorithm. Fig. 13 depicts the simulated environment, including the robot equipped with the sensor suite and the vineyard row. Each of these sensors FIGURE 13. Visualization in Gazebo of the simulated environment, including the robot with the sensor suite and the vineyard row. FIGURE 14. Visualization in RViz of the robot, the vineyard captured in Gazebo and the point cloud generated by the RGB-D camera. emulates the acquisition of realistic information about the environment and can be substituted by the real data coming from the physical asset of the DT. For instance, as depicted in Fig. 14, the simulated camera generates a point cloud of the surrounding environment at each acquisition instant, providing a realistic representation of the vineyard. However, simulating tracked robots in Gazebo presents challenges, with modeling wheel/ground interaction dynamics being hindered by the limitation of not simulating deformable terrains. The terrain included in the simulated environment replicates a rural terrain solely in appearance, not its physical properties. Nonetheless, in our case study, the modeling of a tracked robot, namely the Polibot, was addressed by substituting the tracks with two equivalent wheels on each side. Furthermore, knowing the real location of the vineyard, it was possible to orientate the virtual vineyard with the same orientation, i.e., 12.5◦w.r.t. the geographic North, which corresponds to the x-axis of the World reference system in Gazebo. The geographical reference position of the robot, instead, is defined by longitude =18.34581509◦and latitude =40.05999619◦. This specific parameter is configurable within the simulated GNSS receiver plugin. In addition, to simulate the system under quasi-real conditions, the inertial parameters were set relative to the real ones. In particular, the mass and the inertial matrix are specified as follows: m=125 kg,(4) I=  14.264 7.21E−05 7.21E−05 7.21E−05 11.628 3.09E−05 7.21E−05 3.09E−05 10.811  ,(5) where mis expressed in kg, whereas Iin kg ·m2. VOLUME 12, 2024 178055