Modeling and Simulation of Unmanned Driving System for Load Haul Dump Vehicles in Underground Mines

: This paper proposes the modeling and simulation of the unmanned driving system for underground load haul dump vehicles based on Gazebo/Ros. Firstly, the kinematics model of the load haul dump vehicle is derived. Then, the model of each part of the load haul dump vehicle is established based on SolidWorks and the model of the load haul dump vehicle is established by connecting the parts through a uniﬁed robot description format (URDF) ﬁle. Finally, the laneway model is established by using alpha shape to realize the modeling of the operating environment of the load haul dump vehicle. The speed, angular speed, bucket lifting, and bucket ﬂipping of the load haul dump vehicle are controlled using PID. The experimental results show that: The control errors of the speed and angular speed of the load haul dump vehicle are 0.283 m/s and 0.010 rad/s, respectively. The control error of the lifting bucket is 0.025 m and that of the ﬂipping bucket is 0.015 m. The angular velocity control error of the simulation system relative to the actual system is 0.330 and 0.106 m/s, respectively. The error between the SLAM of the simulation system and the actual system and the measured value is 0.917 and 3.44 m, respectively. The control performance of the load haul dump vehicle in the simulation system is good. Therefore, automatic driving algorithms can be studied and tested in this simulation platform.


Introduction
Load haul dump (LHD) vehicles are very important equipment in underground mines. Ore and minerals are usually dumped from the working face by LHD vehicles into the ore pass. Therefore, driving LHD vehicles requires a lot of manpower. Moreover, the working environment is harsh, which can seriously threaten the health of the driver: a large amount of dust in the laneway affects the respiratory system and the noise generated by the machinery hurts the hearing system. Although more and more battery-powered LHD vehicle chargers are being developed [1][2][3], most mines currently use the hydraulic LHD vehicles. In recent years, with the development of science and technology, unmanned LHD vehicles have become a research hotspot and they have solved the above problems. In addition, with the progress of human civilization, governments of various countries have paid more and more attention to human rights and issued relevant policies, which have promoted the intelligent process of mine automation. For example, in April 2020, the Ministry of Industry and Information Technology of China, the National Development and Reform Commission, and the Ministry of Natural Resources jointly announced the Guidelines for the Construction of Intelligent Factories (Mines) in the Nonferrous Metals Industry (Trial). Scholars have performed a lot of research and analysis on the core technology of unmanned LHD vehicles [4][5][6][7][8]. For example, Rowduru [9] reviews the automation of the steering mechanism for LHD vehicles and Gao [10] analyzes the steering characteristics. Altafini [11] proposes a path tracking criterion for an articulated LHD vehicle and Yu [12] compares and optimizes the path tracking control algorithm of the LHD vehicle. The literature [13,14]

Materials and Methods
In this section, we describe and model the unmanned driving system of the LHD vehicle in underground mines. It mainly includes four parts. The first part is the kinematic model of the LHD vehicle. Since the LHD models are all articulated, which is different from the car model, we analyze the kinematics of the LHD vehicle and derive the kinematic model of the LHD vehicle. The second part is the model of the LHD. We used Solidworks Sustainability 2022, 14, 15186 3 of 18 to build the 3D model of each part of the LHD vehicle and spliced the parts into the LHD model in the URDF file. The principle of interaction between linkage in the forward steering process of LHD vehicle is analyzed. In addition, we use the Gazebo plug-in to connect lidar, cameras, and IMUs to the LHD model. The third part is laneway modeling. The underground laneway is the environment where the LHD vehicle drives automatically. In order to ensure the environment is consistent with the real environment, we build a point cloud model using 3D SLAM through Livox Horizon lidar and use the alpha shape algorithm [28,29] to convert the point cloud model into a triangular patch model. The fourth part is the simulation of the unmanned driving system of the LHD vehicle in Gazebo. In order to cause the LHD vehicle to move in the Gazebo environment, we use the Gazebo plug-in to control the rotation of the wheel and control the steering and shovel loading of the LHD vehicle through the ros_control Ros package.

The LHD Kinematics Model
The underground LHD vehicles generally drive at speeds below 30 km/h and the kinematics model can describe the driving state of the LHD vehicle more accurately [30,31]. As shown in Figure 1, it represents the driving state of the LHD vehicle. In the figure, F and R are the center points of the front and rear wheels, respectively. (x f , y f ), (x r , y r ) are the coordinates of F and R, respectively. v f , v r are the speeds of F and R, respectively. C is the hinge point. γ is the hinge radian that is positive for turning left and negative for turning right. θ f , θ r represent the heading radian of the front and rear axles, respectively. l f , l r represent the length of the front and rear axles, respectively. d represent the wheelbase.
In this section, we describe and model the unmanned driving system of the LHD vehicle in underground mines. It mainly includes four parts. The first part is the kinematic model of the LHD vehicle. Since the LHD models are all articulated, which is different from the car model, we analyze the kinematics of the LHD vehicle and derive the kinematic model of the LHD vehicle. The second part is the model of the LHD. We used Solidworks to build the 3D model of each part of the LHD vehicle and spliced the parts into the LHD model in the URDF file. The principle of interaction between linkage in the forward steering process of LHD vehicle is analyzed. In addition, we use the Gazebo plugin to connect lidar, cameras, and IMUs to the LHD model. The third part is laneway modeling. The underground laneway is the environment where the LHD vehicle drives automatically. In order to ensure the environment is consistent with the real environment, we build a point cloud model using 3D SLAM through Livox Horizon lidar and use the alpha shape algorithm [28,29] to convert the point cloud model into a triangular patch model. The fourth part is the simulation of the unmanned driving system of the LHD vehicle in Gazebo. In order to cause the LHD vehicle to move in the Gazebo environment, we use the Gazebo plug-in to control the rotation of the wheel and control the steering and shovel loading of the LHD vehicle through the ros_control Ros package.

The LHD Kinematics Model
The underground LHD vehicles generally drive at speeds below 30 km/h and the kinematics model can describe the driving state of the LHD vehicle more accurately [30,31]. As shown in Figure 1, it represents the driving state of the LHD vehicle. In the figure, F and R are the center points of the front and rear wheels, respectively.    Decompose v f , v r into: From Figure 1, the F, R coordinate relationship can be obtained: Combining Equations (1)-(4), we receive: x r sin(π − θ r ) + y r cos(π − θ r ) = 0, It can be obtained from Figure 1: Equations (5) and (6) are derived from time to obtain: .
From Equations (9) and (12) we can receive: Comprehensive Equations (3), (4), (7) and (9)-(11) can be obtained: From Equations (13)-(15) we can receive: According to the above derivation, the center point F of the front wheel is the reference point and the kinematic model of the LHD can be represented by Equation (17).

The LHD Modeling
LHD vehicles are essential transportation tools for mining. Due to the narrow underground laneway, in order to enable the LHD vehicle to turn flexibly in the narrow laneway, the LHD vehicle is all articulated. At present, the unmanned LHD vehicle is still in the initial stage of industrial application and there is no large-scale production. Therefore, in order to study the unmanned driving of the LHD vehicle, we transformed the traditional LHD vehicle, as shown in Figure 2. We installed a camera and a lidar on each of the front body and the rear body. The camera is a device that provides the driver with a view when remotely controlling the LHD vehicle. The lidar has a scanning range of 270 degrees and it is the main sensor for the unmanned driving of the LHD vehicle. Intelligent controllers, IMUs, network communication, and other equipment are installed in a box in the rear body. way, the LHD vehicle is all articulated. At present, the unmanned LHD vehicle is still in the initial stage of industrial application and there is no large-scale production. Therefore, in order to study the unmanned driving of the LHD vehicle, we transformed the traditional LHD vehicle, as shown in Figure 2. We installed a camera and a lidar on each of the front body and the rear body. The camera is a device that provides the driver with a view when remotely controlling the LHD vehicle. The lidar has a scanning range of 270 degrees and it is the main sensor for the unmanned driving of the LHD vehicle. Intelligent controllers, IMUs, network communication, and other equipment are installed in a box in the rear body. We split the LHD vehicle into 24 parts, modeled each part in Solidworks, and then connected the parts through the URDF file. The naming of each linkage is shown in Figure  2. The relationship between each linkage of the LHD vehicle is shown in Figure 3. The dotted line in the figure represents five closed-loop kinematic chain models [32], which are 1. base_footprint-CB_Link-Z3_Link-Z2_Link-Z1_Link; 2. base_footprint-CB_Link-L2_Link-L1_Link; 3. CB_Link-Z3_Link-Z4_Link-CD_Link; We split the LHD vehicle into 24 parts, modeled each part in Solidworks, and then connected the parts through the URDF file. The naming of each linkage is shown in Figure 2. The relationship between each linkage of the LHD vehicle is shown in Figure 3. The dotted line in the figure represents five closed-loop kinematic chain models [32], which are 4. base_footprint-C1_Link-C2_Link-CH_Link; 5. base_footprint-C3_Link-C4_Link-CH_Link.
Since the closed-loop kinematic chain model cannot be defined in the URDF file, we used URDF to define the connection of the two links represented by the solid line in Figure  3 and used the Gazebo plugin to define the connection of the two links represented by the dotted line in Figure 3. The function package of the Gazebo closed-loop plug-in developed by us combined with the URDF file can realize the simulation of a closed-loop motion chain structure in Gazebo.  Figure 3. The relationship of physical links. Notes: base_link is the virtual link; LFW_Link, RFW_Link, LBW_Link, and RBW_Link are the left front wheel, the right front wheel, the left rear wheel, and the right rear wheel, respectively; Rcamera_link and Fcamera_link are the front camera and the rear camera, respectively; Blidar_link and Flidar_link are the front lidar and the rear lidar, respectively; Z1_Link and Z2_Link are flip cylinders; L1_Link and L2_Link are the lift cylinders; C1_Link, C2_Link, C3_Link, and C4_Link are the turning cylinders; imu_link is IMU.
Then, we described the motion principle of the LHD vehicle from the perspective of linkage motion. The LHD operation is divided into two processes. The first is the shovel loading process and the second is the driving process.
The motion principle of the LHD during the shovel loading process is shown in Figure 4a. The shovel loading is divided into two actions. The first is to lift the bucket and the second is to flip the bucket. The lifting bucket is controlled by the movement of the L2_Link in the L1_Link. When the length of the L2_Link in the L1_Link is shortened, the generated lift makes the front frame rise, and the entire front frame will rotate counter-
Since the closed-loop kinematic chain model cannot be defined in the URDF file, we used URDF to define the connection of the two links represented by the solid line in Figure 3 and used the Gazebo plugin to define the connection of the two links represented by the dotted line in Figure 3. The function package of the Gazebo closed-loop plug-in developed by us combined with the URDF file can realize the simulation of a closed-loop motion chain structure in Gazebo.
Then, we described the motion principle of the LHD vehicle from the perspective of linkage motion. The LHD operation is divided into two processes. The first is the shovel loading process and the second is the driving process.
The motion principle of the LHD during the shovel loading process is shown in Figure 4a. The shovel loading is divided into two actions. The first is to lift the bucket and the second is to flip the bucket. The lifting bucket is controlled by the movement of the L2_Link in the L1_Link. When the length of the L2_Link in the L1_Link is shortened, the generated lift makes the front frame rise, and the entire front frame will rotate counterclockwise around O 1 , O 2 . Conversely, when the length of the L2_Link becomes longer in the L1_Link, the generated descending force will lower the front frame, and the entire front frame will rotate clockwise around O 1 , O 2 . The flipping bucket is controlled by the movement of the Z2_Link in the Z1_Link. When the length of the Z2_Link in the Z1_Link becomes shorter, the Z3_Link will rotate counterclockwise around O 6 , and then the force generated by the Z4_Link makes the CD_Link rotate counterclockwise around O 9 . Conversely, when the length of the Z2_Link in the Z1_Link becomes longer, the Z3_Link will rotate clockwise around O 6 , and the force generated by the Z4_Link will cause the CD_Link to rotate clockwise around O 9 .
force generated by the Z4_Link makes the CD_Link rotate counterclockwise around 9 O . Conversely, when the length of the Z2_Link in the Z1_Link becomes longer, the Z3_Link will rotate clockwise around 6 O , and the force generated by the Z4_Link will cause the CD_Link to rotate clockwise around 9 O .
The motion principle of the LHD vehicle during driving is also divided into two parts. The first one is the steering control principle, as shown in Figure 4b. When the length of the C1_Link in the C2_Link becomes shorter, the length of the C3_Link in the C4_Link becomes longer. The base_link rotates clockwise around 12 O . The CH_Link rotates counterclockwise around 12 O and the LHD vehicle turns right. Conversely, when the length of the C1_Link in the C2_Link becomes longer, the length of the C3_Link in the C4_Link will become shorter. The base_link will rotate counterclockwise around 12 O .
The CH_Link will rotate clockwise around 12 O and the LHD vehicle will turn left. The second is the principle of longitudinal speed control. Obviously, the forward speed of the LHD vehicle is controlled by the rotation speed of the wheels. In the simulation model, we control the longitudinal speed and steering angular speed of the LHD vehicle by controlling the different rotational speeds of the four wheels. As shown in Figure 1, we use F as the reference point, f v represents the speed of the vehicle, and we can obtain the angular speed of the four wheels: In Equation (18)  The motion principle of the LHD vehicle during driving is also divided into two parts. The first one is the steering control principle, as shown in Figure 4b. When the length of the C1_Link in the C2_Link becomes shorter, the length of the C3_Link in the C4_Link becomes longer. The base_link rotates clockwise around O 12 . The CH_Link rotates counterclockwise around O 12 and the LHD vehicle turns right. Conversely, when the length of the C1_Link in the C2_Link becomes longer, the length of the C3_Link in the C4_Link will become shorter. The base_link will rotate counterclockwise around O 12 . The CH_Link will rotate clockwise around O 12 and the LHD vehicle will turn left. The second is the principle of longitudinal speed control. Obviously, the forward speed of the LHD vehicle is controlled by the rotation speed of the wheels. In the simulation model, we control the longitudinal speed and steering angular speed of the LHD vehicle by controlling the different rotational speeds of the four wheels. As shown in Figure 1, we use F as the reference point, v f represents the speed of the vehicle, and we can obtain the angular speed of the four wheels: In Equation (18), R represents the radius of the wheel and w l f w , w r f w , w lrw , w rrw are the angular velocities of the left front wheel, the right front wheel, the left rear wheel, and the right rear wheel, respectively.
Finally, we add the corresponding sensors model to the LHD model according to the position of the sensors in Figure 2. Camera, lidar, and IMUs models in were added to the URDF files through the Gazebo plugin as shown in Figure 5. The frequency of the lidar is set to 50 Hz. The frequency of the IMUs is set to 100 Hz and the frequency of the camera is set to 30 Hz.  Figure 2. Camera, lidar, and IMUs models in were added to t URDF files through the Gazebo plugin as shown in Figure 5. The frequency of the lidar set to 50 Hz. The frequency of the IMUs is set to 100 Hz and the frequency of the came is set to 30 Hz.

Rear camera Front camera
Front lidar Rear lidar IMUs

Laneway Modelling
The underground laneway environment is harsh. The laneway is filled with a lot dust during mining operations and the ground is uneven, as shown in Figure 6a. In ord to ensure the simulation environment is consistent with the actual laneway environme we also performed in-depth research on laneway modeling. The laneway modeling p cess is shown in Figure 6b. First, we used the Livox Horizon lidar to scan part of the lan way of a mine and used LiLi-OM [33] to generate a point cloud model. Then, we de-nois the point cloud model and used the alpha shape algorithm to build a triangular me model. Then, we visualized and converted the model to ADE format using 3D softwa Finally, we loaded the ADE file through the URDF file and displayed it in Gazebo. T specific description is as follows.

Laneway Modelling
The underground laneway environment is harsh. The laneway is filled with a lot of dust during mining operations and the ground is uneven, as shown in Figure 6a. In order to ensure the simulation environment is consistent with the actual laneway environment, we also performed in-depth research on laneway modeling. The laneway modeling process is shown in Figure 6b. First, we used the Livox Horizon lidar to scan part of the laneway of a mine and used LiLi-OM [33] to generate a point cloud model. Then, we de-noised the point cloud model and used the alpha shape algorithm to build a triangular mesh model. Then, we visualized and converted the model to ADE format using 3D software. Finally, we loaded the ADE file through the URDF file and displayed it in Gazebo. The specific description is as follows.
cess is shown in Figure 6b. First, we used the Livox Horizon lidar to scan part of the lane way of a mine and used LiLi-OM [33] to generate a point cloud model. Then, we de-noised the point cloud model and used the alpha shape algorithm to build a triangular mesh model. Then, we visualized and converted the model to ADE format using 3D software Finally, we loaded the ADE file through the URDF file and displayed it in Gazebo. Th specific description is as follows.  During the process of lidar data acquisition and 3D SLAM algorithm mapping, som interference points were generated, as shown in the red circle in Figure 7a. The interfer ence points had a great impact on the quality of laneway modeling and they affected th During the process of lidar data acquisition and 3D SLAM algorithm mapping, some interference points were generated, as shown in the red circle in Figure 7a. The interference points had a great impact on the quality of laneway modeling and they affected the subsequent 3D patch modeling. To improve the quality of the laneway model, we denoised the original point cloud [34]. Figure 7a shows the original point cloud data, which consist of 72,268 points, of which there are 3477 noise points in total. Figure 7b is the point cloud after de-noising the points, with a total of 68,791 points.
14, x FOR PEER REVIEW 9 of 19 subsequent 3D patch modeling. To improve the quality of the laneway model, we denoised the original point cloud [34]. Figure 7a shows the original point cloud data, which consist of 72,268 points, of which there are 3477 noise points in total. Figure 7b is the point cloud after de-noising the points, with a total of 68,791 points. In order to import the laneway model into Gazebo, the point cloud model of the laneway needs to be converted into a format recognized by Gazebo. In this paper, we uniformly adopted the ADE format. Kirkpatrick et al. [26] proposed a contour extraction method for 2D point sets in 1983 and Edelsbrunner et al. [25] extended this method to boundary surface extraction of 3D point sets. This method is called the alpha shape algorithm. In this paper, we use the alpha shape algorithm to extract the 3D boundary surface of the laneway point cloud model, see Algorithm 1.

Algorithm 1 alpha-shape
S N × , Rolling circle radius α In order to import the laneway model into Gazebo, the point cloud model of the laneway needs to be converted into a format recognized by Gazebo. In this paper, we uniformly adopted the ADE format. Kirkpatrick et al. [26] proposed a contour extraction method for 2D point sets in 1983 and Edelsbrunner et al. [25] extended this method to boundary surface extraction of 3D point sets. This method is called the alpha shape algorithm. In this paper, we use the alpha shape algorithm to extract the 3D boundary surface of the laneway point cloud model, see Algorithm 1.

Algorithm 1. alpha-shape
Input: 3D points set S(N × 3), Rolling circle radius α Output: Triangular patch BF(M × 3) 1: Assign S to S0, S0 = S 2: while S is not empty do 3: Arbitrarily choose a point P1 in S 4: Calculate the distances (Dis) of P1 from other points in S, and the points set that satisfies Dis ≤ 2 × α is denoted as S1 5: Combine the points in S1 in pairs to get the set Pair 6: while Pair is not empty do 7: Arbitrarily select a pair of points P2, P3 from Pair and remove the pair of points P1, P2 from the Pair 8: Find the centers O and O of a sphere of radius α passing through points P1, P2 and P3 9: Traverse the point set S1, and find the distance sets D and D from other points to the center of the sphere O and O 10: if min(D) > α or min(D ) > α then 11 We input the de-noised point cloud into the alpha shape algorithm, with α set to 5, and 53,168 triangular patches were outputted, as shown in Figure 8. The value of α has certain requirements. In this case, α was the maximum value of the point cloud interval. If α is too small, multiple shapes will be formed. If α is too large, the shape will be more convex and deviate from the shape of the laneway. We input the de-noised point cloud into the alpha shape algorithm, with α set to 5, and 53,168 triangular patches were outputted, as shown in Figure 8. The value of α has certain requirements. In this case, α was the maximum value of the point cloud interval. If α is too small, multiple shapes will be formed. If α is too large, the shape will be more convex and deviate from the shape of the laneway. Then, the triangular patch model was converted into an ADE file using the 3D software. Figure 9 shows the three views of the laneway in the 3D software. Then, the triangular patch model was converted into an ADE file using the 3D software. Figure 9 shows the three views of the laneway in the 3D software.

Simulation of Unmanned Driving System of the LHD vehicle in Gazebo
In this part, the motion control of the LHD vehicle is implemented in Gazebo through the ros_control Ros package, as shown in Figure 10. The/vehicle/L2_Joint_position_controller node controls the lift bucket by controlling the displacement of the L2_Link in the L1_Link. The/vehicle/Z2_Joint_position_controller node controls the flip bucket by controlling the displacement of the Z2_Link in the Z1_Link. The/vehicle/cmd_vel node controls the speed and articulation angular speed of the LHD vehicle by controlling the rotational speeds of the four wheels according to Equation (18). We use the Gazebo plug-in to add the motor model at the above link. The PID controls the motor to execute the movement of LHD vehicle according to the command issued. The/vehicle_teleop_keyboard is the keyboard control node, which sends motion commands to the LHD vehicle through the keyboard input. The keyboard control details are as follows: 1. Enter "w" from the keyboard to control the vehicle forward; 2. Enter "x" from the keyboard to control the vehicle back; 3. Enter "a" from the keyboard to control the vehicle to turn left; 4. Enter "d" from the keyboard to control the vehicle to turn right; 5. Enter "r" from the keyboard to control the vehicle to lift the bucket; 6. Enter "f" from the keyboard to control the vehicle to lower the bucket; 7. Enter "t" from the keyboard to control the vehicle to flip the bucket counterclockwise; 8. Enter "g" from the keyboard to control the vehicle to flip the bucket clockwise.

Simulation of Unmanned Driving System of the LHD Vehicle in Gazebo
In this part, the motion control of the LHD vehicle is implemented in Gazebo through the ros_control Ros package, as shown in Figure 10. The/vehicle/L2_Joint_position_controller node controls the lift bucket by controlling the displacement of the L2_Link in the L1_Link. The/vehicle/Z2_Joint_position_controller node controls the flip bucket by controlling the displacement of the Z2_Link in the Z1_Link. The/vehicle/cmd_vel node controls the speed and articulation angular speed of the LHD vehicle by controlling the rotational speeds of the four wheels according to Equation (18). We use the Gazebo plug-in to add the motor model at the above link. The PID controls the motor to execute the movement of LHD vehicle according to the command issued. The/vehicle_teleop_keyboard is the keyboard control node, which sends motion commands to the LHD vehicle through the keyboard input. The keyboard control details are as follows:

1.
Enter "w" from the keyboard to control the vehicle forward; 2.
Enter "x" from the keyboard to control the vehicle back; 3.
Enter "a" from the keyboard to control the vehicle to turn left; 4.
Enter "d" from the keyboard to control the vehicle to turn right; 5.
Enter "r" from the keyboard to control the vehicle to lift the bucket; 6.
Enter "f" from the keyboard to control the vehicle to lower the bucket; 7.
Enter "t" from the keyboard to control the vehicle to flip the bucket counterclockwise; 8.
Enter "g" from the keyboard to control the vehicle to flip the bucket clockwise.  After the laneway model and the LHD model were imported into Gazebo, the abo control nodes were ran. The LHD vehicle can be controlled to move in the lanew through the keyboard, as shown in Figure 11.

Results
In order to verify the reliability and effectiveness of the unmanned driving simu tion system of the LHD vehicle, the following experiments were designed.

Experiment 1
In the Gazebo simulation platform, the speed and angular speed commands w inputted through the keyboard and the commands and the coordinates of the referen point of the LHD vehicle were simultaneously recorded. The speed and angular spe commands inputted from the keyboard were compared with the speed and angular spe executed by the simulation to verify the control performance of the LHD model in Gaze In addition, the recorded speed and angular speed commands were substituted into t kinematic model Equation (17) to verify the accuracy of the kinematic model.
As shown in Figure 12, the black dotted line is the speed command inputted from t After the laneway model and the LHD model were imported into Gazebo, the above control nodes were ran. The LHD vehicle can be controlled to move in the laneway through the keyboard, as shown in Figure 11.  After the laneway model and the LHD model were imported into Gazebo, the above control nodes were ran. The LHD vehicle can be controlled to move in the laneway through the keyboard, as shown in Figure 11.

Results
In order to verify the reliability and effectiveness of the unmanned driving simulation system of the LHD vehicle, the following experiments were designed.

Experiment 1
In the Gazebo simulation platform, the speed and angular speed commands were inputted through the keyboard and the commands and the coordinates of the reference point of the LHD vehicle were simultaneously recorded. The speed and angular speed commands inputted from the keyboard were compared with the speed and angular speed executed by the simulation to verify the control performance of the LHD model in Gazebo. In addition, the recorded speed and angular speed commands were substituted into the kinematic model Equation (17) to verify the accuracy of the kinematic model.
As shown in Figure 12, the black dotted line is the speed command inputted from the keyboard and the range of the speed is 0-2 m/s. The red dotted line is the angular speed

Results
In order to verify the reliability and effectiveness of the unmanned driving simulation system of the LHD vehicle, the following experiments were designed. In the Gazebo simulation platform, the speed and angular speed commands were inputted through the keyboard and the commands and the coordinates of the reference point of the LHD vehicle were simultaneously recorded. The speed and angular speed commands inputted from the keyboard were compared with the speed and angular speed executed by the simulation to verify the control performance of the LHD model in Gazebo. In addition, the recorded speed and angular speed commands were substituted into the kinematic model Equation (17) to verify the accuracy of the kinematic model.
As shown in Figure 12, the black dotted line is the speed command inputted from the keyboard and the range of the speed is 0-2 m/s. The red dotted line is the angular speed command inputted from the keyboard and the range of the angular speed is −0.1-0.1 rad/s. Since the real-time feedback data of the simulation platform are the coordinates of the reference point, the simulation execution speed was obtained by dividing the distance difference between the two frames by the time difference. Similarly, the angular speed of the simulation execution was obtained by dividing the difference in articulation radian between two frames by the time difference. The solid blue line in the figure is the speed of the simulation execution and the solid green line is the angular speed of the simulation execution. The speed and angular speed of the simulation were basically the same as the commands inputted from the keyboard. In order to quantitatively analyze the control performance of the LHD simulation platform, the root mean square error (RMSE) was used as the index. The higher the RMSE, the better the control performance.
the simulation execution was obtained by dividing the difference in articulation radian between two frames by the time difference. The solid blue line in the figure is the speed of the simulation execution and the solid green line is the angular speed of the simulation execution. The speed and angular speed of the simulation were basically the same as the commands inputted from the keyboard. In order to quantitatively analyze the control performance of the LHD simulation platform, the root mean square error (RMSE) was used as the index. The higher the RMSE, the better the control performance.
( ) Here, ˆi y represents the speed or angular speed of the simulation execution in the i frame and i y represents the speed or angular speed of the keyboard inputted in the i frame. According to Equation (19), the RMSE of the simulation execution speed relative to the input command was 0.283 m/s and the RMSE of the angular speed relative to the input command was 0.010 rad/s. In addition, with the same speed and angular speed commands in Figure 12, the trajectory obtained from the kinematic model was compared with the trajectory recorded by the simulation platform, as shown in Figure 13. The blue solid line in the figure is the trajectory of the reference point of the LHD vehicle recorded by the simulation platform and the red dotted line is the theoretical trajectory obtained by the kinematic model. The RMSE of the trajectory recorded by the simulation platform relative to the theoretical trajectory in the X direction is 1.412 m and the average percentage error in the Y direction is 0.727 m. These errors originate from the speed and angular speed control errors in Figure  12. It can be shown that the derived kinematics model of the LHD vehicle is very accurate at a low speed. Here,ŷ i represents the speed or angular speed of the simulation execution in the i frame and y i represents the speed or angular speed of the keyboard inputted in the i frame. According to Equation (19), the RMSE of the simulation execution speed relative to the input command was 0.283 m/s and the RMSE of the angular speed relative to the input command was 0.010 rad/s. In addition, with the same speed and angular speed commands in Figure 12, the trajectory obtained from the kinematic model was compared with the trajectory recorded by the simulation platform, as shown in Figure 13

Experiment 2
The commands of lifting and flipping the bucket were inputted through the keyboard, the commands and the results of simulation execution were recorded, and the control performance of the shovel during the shovel loading process in Gazebo were verified.
As shown in Figure 14, the black dotted line in the figure is the command input from the keyboard to lift the bucket, that is, the displacement of the L2_Link in the L1_Link. The solid blue line is the result of the simulation platform execution and the displacement amount executed by the simulation platform relative to the RMSE of the input command is 0.025 m. The red dotted line in the figure is the command to input the bucket from the keyboard, that is, the displacement of the Z2_Link in the Z1_Link. The green solid line is the result of the simulation platform execution and the displacement amount executed by the simulation platform relative to the RMSE of the input command is 0.015 m.

Experiment 3
The execution results of the simulation platform and the actual system were compared by issuing the same speed and angular speed commands.

Experiment 2
The commands of lifting and flipping the bucket were inputted through the keyboard, the commands and the results of simulation execution were recorded, and the control performance of the shovel during the shovel loading process in Gazebo were verified.
As shown in Figure 14, the black dotted line in the figure is the command input from the keyboard to lift the bucket, that is, the displacement of the L2_Link in the L1_Link. The solid blue line is the result of the simulation platform execution and the displacement amount executed by the simulation platform relative to the RMSE of the input command is 0.025 m. The red dotted line in the figure is the command to input the bucket from the keyboard, that is, the displacement of the Z2_Link in the Z1_Link. The green solid line is the result of the simulation platform execution and the displacement amount executed by the simulation platform relative to the RMSE of the input command is 0.015 m.

Experiment 2
The commands of lifting and flipping the bucket were inputted through the keyboard, the commands and the results of simulation execution were recorded, and the control performance of the shovel during the shovel loading process in Gazebo were verified.
As shown in Figure 14, the black dotted line in the figure is the command input from the keyboard to lift the bucket, that is, the displacement of the L2_Link in the L1_Link. The solid blue line is the result of the simulation platform execution and the displacement amount executed by the simulation platform relative to the RMSE of the input command is 0.025 m. The red dotted line in the figure is the command to input the bucket from the keyboard, that is, the displacement of the Z2_Link in the Z1_Link. The green solid line is the result of the simulation platform execution and the displacement amount executed by the simulation platform relative to the RMSE of the input command is 0.015 m.

Experiment 3
The execution results of the simulation platform and the actual system were compared by issuing the same speed and angular speed commands.

Comparison between Simulation and Reality Experiment 3
The execution results of the simulation platform and the actual system were compared by issuing the same speed and angular speed commands.
The LHD vehicle and the installation of the sensor in the actual system are shown in Figure 1 and the experiment was carried out in the real laneway, as shown in Figure 6a. The remote terminal sends commands to the intelligent controller on the LHD vehicle through 5G and then the intelligent controller sends commands to each actuator through CAN communication; that is the remote-control mode. The terminal commands were recorded at 10 Hz while in the remote-control mode. When simulating in Gazebo, the previously recorded commands were also sent to the simulation platform controller at a frequency of 10 Hz. As shown in Figure 15, the red solid line in the figure represents the speed command, the blue solid line represents the result of the simulation platform execution, and the green solid line represents the result of the real system execution. According to Equation (19), the execution speed of the simulation platform is 0.193 m/s relative to the RMSE of the issued command. The actual system execution speed is 0.360 m/s relative to the RMSE of the issued command and the execution speed of the simulation platform is 0.330 m/s relative to the actual system execution speed. The LHD vehicle and the installation of the sensor in the actual system are shown in Figure 1 and the experiment was carried out in the real laneway, as shown in Figure 6a. The remote terminal sends commands to the intelligent controller on the LHD vehicle through 5G and then the intelligent controller sends commands to each actuator through CAN communication; that is the remote-control mode. The terminal commands were recorded at 10 Hz while in the remote-control mode. When simulating in Gazebo, the previously recorded commands were also sent to the simulation platform controller at a frequency of 10 Hz. As shown in Figure 15, the red solid line in the figure represents the speed command, the blue solid line represents the result of the simulation platform execution, and the green solid line represents the result of the real system execution. According to Equation (19), the execution speed of the simulation platform is 0.193 m/s relative to the RMSE of the issued command. The actual system execution speed is 0.360 m/s relative to the RMSE of the issued command and the execution speed of the simulation platform is 0.330 m/s relative to the actual system execution speed. Likewise, Figure 16 is a comparison of the angular velocities from the simulation, the actual system, and the command. According to Equation (19), the angular speed of the simulation platform execution relative to the RMSE of the issued command is 0.069 rad/s. The RMSE of the angular speed executed by the actual system relative to the issued command is 0.123 rad/s and the RMSE of the angular speed executed by the simulation platform relative to the angular speed executed by the actual system is 0.106 rad/s.  Likewise, Figure 16 is a comparison of the angular velocities from the simulation, the actual system, and the command. According to Equation (19), the angular speed of the simulation platform execution relative to the RMSE of the issued command is 0.069 rad/s. The RMSE of the angular speed executed by the actual system relative to the issued command is 0.123 rad/s and the RMSE of the angular speed executed by the simulation platform relative to the angular speed executed by the actual system is 0.106 rad/s. The LHD vehicle and the installation of the sensor in the actual system are shown in Figure 1 and the experiment was carried out in the real laneway, as shown in Figure 6a. The remote terminal sends commands to the intelligent controller on the LHD vehicle through 5G and then the intelligent controller sends commands to each actuator through CAN communication; that is the remote-control mode. The terminal commands were recorded at 10 Hz while in the remote-control mode. When simulating in Gazebo, the previously recorded commands were also sent to the simulation platform controller at a frequency of 10 Hz. As shown in Figure 15, the red solid line in the figure represents the speed command, the blue solid line represents the result of the simulation platform execution, and the green solid line represents the result of the real system execution. According to Equation (19), the execution speed of the simulation platform is 0.193 m/s relative to the RMSE of the issued command. The actual system execution speed is 0.360 m/s relative to the RMSE of the issued command and the execution speed of the simulation platform is 0.330 m/s relative to the actual system execution speed. Likewise, Figure 16 is a comparison of the angular velocities from the simulation, the actual system, and the command. According to Equation (19), the angular speed of the simulation platform execution relative to the RMSE of the issued command is 0.069 rad/s. The RMSE of the angular speed executed by the actual system relative to the issued command is 0.123 rad/s and the RMSE of the angular speed executed by the simulation platform relative to the angular speed executed by the actual system is 0.106 rad/s. Figure 16. Comparison chart of angular speed from the simulation, real system, and command. Figure 16. Comparison chart of angular speed from the simulation, real system, and command. Experiment 4 SLAM was performed on the simulation platform and the map created by SLAM on the simulation platform and the map created by SLAM on the real system were compared.

SLAM Based on Simulation Platform
SLAM is an important research direction for autonomous driving of underground unmanned LHD vehicles. Since both the downhole environment and the indoor environment are closed spaces, the indoor SLAM method can be used for the downhole SLAM method [35]. This paper adopts the cartographer mapping method proposed by Wolfgang [36] in 2016. The driving environment of the LHD vehicle is the laneway model established in the second chapter. Figure 17a is the map built using the real system. Using the method of real-time online mapping, the driver drives the forklift from the vicinity of point A to the vicinity of point E along the laneway. Figure 17b is the map created by the simulation. In the same way, real-time online mapping is used to control the LHD vehicle to drive from the vicinity of point A along the laneway to the vicinity of point E by inputting commands from the keyboard. SLAM was performed on the simulation platform and the map created by SLAM the simulation platform and the map created by SLAM on the real system were compare SLAM is an important research direction for autonomous driving of undergrou unmanned LHD vehicles. Since both the downhole environment and the indoor enviro ment are closed spaces, the indoor SLAM method can be used for the downhole SLA method [35]. This paper adopts the cartographer mapping method proposed by Wolfga [36] in 2016. The driving environment of the LHD vehicle is the laneway model esta lished in the second chapter. Figure 17a is the map built using the real system. Using t method of real-time online mapping, the driver drives the forklift from the vicinity point A to the vicinity of point E along the laneway. Figure 17b is the map created by t simulation. In the same way, real-time online mapping is used to control the LHD vehi to drive from the vicinity of point A along the laneway to the vicinity of point E by inpu ting commands from the keyboard.  In Figure 18, there is a comparison of the map established by the simulation and t actual system and the main parameters measured. It can be clearly seen that: (1) The ma established by the simulation and the actual system are basically the same. Except for t BC segment, which differs by 6 m, the errors of other segments are all within 1.  In Figure 18, there is a comparison of the map established by the simulation and the actual system and the main parameters measured. It can be clearly seen that: (1) The maps established by the simulation and the actual system are basically the same. Except for the BC segment, which differs by 6 m, the errors of other segments are all within 1.5 m. The RMSE of the map established by the simulation and the actual system is 2.843 m. (2) The map established by the simulation is closer to the measured value than the map established by the actual system. The RMSE of the map established by the simulation and the measured value is 0.917 m and the difference between the map established by the actual system and the measured value RMSE of 3.44 m. (3) The broken line graph in Figure 18 represents the simulation and real cumulative errors from the starting point to the destination of the LHD vehicle, respectively. It can be seen that the cumulative error tends to increase. The final cumulative errors of simulation and real are 3.79 and 7.40 m, respectively.

Discussion
Experiments 1 and 2 show that the control performance of the shovel simulation system is good and that the commands can be well executed during the driving process and the shovel loading process. In addition, Experiment 1 can also show that the derived kinematics model of the LHD vehicle is accurate at a low speed. However, whether the kinematics model can accurately describe the motion law of the LHD vehicle at a high speed is not yet studied in this paper. Experiment 3 shows that the control performance of the simulated system is better than that of the actual system, the execution errors of the two systems are within an acceptable range, and the simulated system can be used to simulate the actual system. Why is the control performance of the simulated system better than the actual system? It is mainly explained by the following two aspects: (1) The actual system is more difficult to control than the simulation system and the simulation system is powered by a motor. The actual system is powered by hydraulic pressure and the power transmission system is far more complicated than the simulation system. (2) The command transmission of the actual system is more complicated than that of the simulation system. The actual system is a command issued by remote control, so the command transmission delay is much greater than that of the simulated system. Experiment 4 shows that the simulation system is used to simulate the actual system, on which we can perform some algorithm tests. However, an abnormal phenomenon was found in the data of Experiment 4: the parameters of the map established by the simulation system, those of the map established by the actual system, and those of the measured values of the laneway were compared. The lengths of AB, CD, DE, and the width of the maps established by the two systems are relative to the measured values. Similar to the lengths of AB, CD, DE, and the width of the maps established by the two systems，we found that their difference was not large and was within the acceptable range, but the error of the length of the BC in the actual system from the measured value was 7.4 m. There are two reasons for this abnormal phenomenon: (1) The characteristics of the laneway in the BC section were not obvious and (2) The vibration of the LHD vehicle in the actual system increased the data of the noise collected by the IMU, while the movement of the LHD vehicle in the simulation system did not. The above two reasons lead to the "corridor effect" in the process of mapping the actual system. To sum up, it can be concluded that the effect of drawing on the simulation system is better than that when using the actual system.

Discussion
Experiments 1 and 2 show that the control performance of the shovel simulation system is good and that the commands can be well executed during the driving process and the shovel loading process. In addition, Experiment 1 can also show that the derived kinematics model of the LHD vehicle is accurate at a low speed. However, whether the kinematics model can accurately describe the motion law of the LHD vehicle at a high speed is not yet studied in this paper. Experiment 3 shows that the control performance of the simulated system is better than that of the actual system, the execution errors of the two systems are within an acceptable range, and the simulated system can be used to simulate the actual system. Why is the control performance of the simulated system better than the actual system? It is mainly explained by the following two aspects: (1) The actual system is more difficult to control than the simulation system and the simulation system is powered by a motor. The actual system is powered by hydraulic pressure and the power transmission system is far more complicated than the simulation system. (2) The command transmission of the actual system is more complicated than that of the simulation system. The actual system is a command issued by remote control, so the command transmission delay is much greater than that of the simulated system. Experiment 4 shows that the simulation system is used to simulate the actual system, on which we can perform some algorithm tests. However, an abnormal phenomenon was found in the data of Experiment 4: the parameters of the map established by the simulation system, those of the map established by the actual system, and those of the measured values of the laneway were compared. The lengths of AB, CD, DE, and the width of the maps established by the two systems are relative to the measured values. Similar to the lengths of AB, CD, DE, and the width of the maps established by the two systems, we found that their difference was not large and was within the acceptable range, but the error of the length of the BC in the actual system from the measured value was 7.4 m. There are two reasons for this abnormal phenomenon: (1) The characteristics of the laneway in the BC section were not obvious and (2) The vibration of the LHD vehicle in the actual system increased the data of the noise collected by the IMU, while the movement of the LHD vehicle in the simulation system did not. The above two reasons lead to the "corridor effect" in the process of mapping the actual system. To sum up, it can be concluded that the effect of drawing on the simulation system is better than that when using the actual system.

Conclusions
In this paper, the models of the LHD vehicle and the laneway were mainly used to build a simulation system for unmanned driving of the LHD vehicle. The accuracy of the kinematic model of the LHD vehicle at a low speed was verified by experiments. Second, the principle of the interaction between the linkages during the driving and loading process of the LHD vehicle were analyzed and the Gazebo plug-in was written to support the closed-loop kinematic chain structure. An accurate 3D laneway model was established by combining 3D SLAM with alpha shape. Finally, the four experiments showed that the performance of the simulation system was good and can be used for the simulation of the actual system. In addition, the results of Experiment 4 show that the simulation system's mapping results for the real world are better than the actual system. This can provide a new way of thinking for researchers in the direction of SLAM.