## 4 Dynamic Simulation of One Mobile Robot Using Flat Surfaces  
Dynamic simulation necessitates the use of a virtual environment, commonly referred to as a world. For the testing phase, a simulation scenario was selected that includes a flat surface and several structural elements resembling those typically encountered in an indoor setting. The experimental setup comprises a workspace enclosed by four walls, covering an area of 5 \(\times\) 20 m\({}^{2}\), specifically designed for the virtual evaluation of the robotic prototype. The mobile robot has compact overall dimensions of approximately 0.03 m in length, 0.02 m in width, and 0.015 m in height, which facilitates its deployment in narrow and cluttered environments during search and rescue operations. In the current study, the focus was limited to planar surfaces. Locomotion was achieved by applying linear velocity commands to the /cmd_vel topic. It is important to highlight, however, that the prototype is engineered to overcome obstacles and ascend stairs with a height not exceeding half of the robot's total height. A dedicated simulation campaign is currently under development to assess the robot's climbing performance under various conditions, including the traversal  
Figure 12: Transmission of AV camera images to RViz2 via topic publishing. of obstacles and step-like structures. The ROS2 and Gazebo configuration described in the previous section was used. This configuration is launched via a launch file named /display.launch.xml, developed within the /my_robot_description package. Its purpose is to instantiate all communication and simulation components of the proposed architecture. As a result, the mobile robot model was successfully transmitted and instantiated in the Gazebo simulation environment without errors, based on the system log output. The system is controlled entirely through the Ubuntu terminal, using a Bash shell to interact with the virtual kernel elements. The log summary confirms the successful parsing of the Xacro file elements, their publication within the Gazebo environment, and the acceptance of the virtual control configuration for the DC motors. During the robot launch sequence, four distinct differential drive controllers (diff_drive_controller_1 through diff_drive_controller_4) were successfully initialized, each managing a pair of wheel joints symmetrically assigned across the robot's base. These controllers correctly subscribed to the /cmd_vel topic for velocity commands, published odometry to /odom, and actively broadcast transform frames between the base_footprint and their respective wheel joints. Wheel parameters, including a uniform diameter of 0.0886 m and a pairwise separation of 0.32204 m, were consistently reported, indicating a well-synchronized multi-controller architecture for distributed wheel actuation in the simulated locomotion model. Each controller relies on the gazebo_ros_diff_drive plugin, which includes an internal PID velocity control loop automatically integrated within the plugin's library (libgazebo_ros_diff_drive.so). This ensures that each wheel pair tracks its target speed smoothly without requiring external tuning unless specified. To print the velocities of the DC motors, Vectors 3 and 5 must be configured--corresponding to the linear and angular vectors. For the testing phase, data were published to the /odom topic using the /geometry_msgs/msg/Twist interface. In ROS2, this vector is generically referred to as Twist. The linear velocity will be published in the Vector 3 subvector of the Twist vector, with a value of 0.4 m/s, as shown in Figure 13.  
Thus, the mobile robot will move within the workspace at the velocity published to the /cmd_vel topic by transmitting the Twist vector using the /geometry_msgs/msg/Twist interface. Figure 14a,b show two positions of the mobile robot following its linear movement along the x-axis. Figure 14: X-axis movement of the mobile robot via linear velocity publishing to the /odom topic using the /geometry_msgs/msg/Twist interface.