One of the crucial components of the navigation stack is a base controller. It is the only way to effectively control a robot that communicates directly with the hardware of the robot. However, ROS does not provide any common base controller, and so we have to develop a base controller for our mobile robot platform.

The base controller must subscribe to a topic with the name /cmd_vel, which has the message type /geometry_msgs::Twist. This message can also be used on the odometry message that we saw before. As well as this, the base controller has to generate the correct commands for the robot platform with the correct linear and angular velocities.

We can recall the structure of this message by typing the following command in a shell to view the structure:

$ rosmsg show geometry_msgs/Twist

The output of the preceding command will be as follows:

In the preceding screenshot, two vector structures show the linear and angular velocities the along x, y, and z axes, respectively, since our mobile robot is based on a differential-wheeled platform that has two motors to move the robot forward and backward and to turn. Therefore, we will only use the linear velocity x and the angular velocity z to drive the robot.

Likewise, we are working with a simulated mobile robot in Gazebo where the base controller is implemented on the plugin driver to move the platform. This means that we won't have to create the base controller for this robot.

Next, let's run our simulated robot on Gazebo to see how the base controller functions. We will have to run the following commands on different terminals:

$ roslaunch chapter7_tutorials gazebo_xacro.launch model:="'rospack find
chapter7_tutorials'/urdf/robot_model_05.xacro"
$ rosrun teleop_twist_keyboard teleop_twist_keyboard.py

When all the nodes are launched and running, we will open rxgraph to view the relation among all the nodes:

$ rqt_graph

The output is shown in the following screenshot:

In the preceding screenshot, we can see that Gazebo automatically subscribes to the cmd_vel topic that is generated by the teleop node.

As we have discussed in the previous section, the driver plugin of our robot is running inside the Gazebo simulator, which receives data from the cmd_vel topic and moves the robot in the virtual world. Simultaneously, this plugin also generates the odometry data.

Moreover, it can be assumed that we have the adequate background knowledge to develop the base controller for a physical robot. We can also refer to the web for more information (https://www.robotshop.com/).