A base controller is an important element in the navigation stack because it is the only way to effectively control your robot. It communicates directly with the electronics of your robot.

ROS does not provide a standard base controller, so you must write a base controller for your mobile platform.

Your robot has to be controlled with the message type geometry_msgs/Twist. This message was used on the Odometry message that we saw before.

So, your base controller must subscribe to a topic with the name cmd_vel, and must generate the correct commands to move the platform with the correct linear and angular velocities.

We are now going to recall the structure of this message. Type the following command in a shell to see the structure:

    $ rosmsg show geometry_msgs/Twist
  

The output of this command is as follows:

The vector with the name linear indicates the linear velocity for the axes x, y, and z. The vector with the name angular is for the angular velocity on the axes.

For our robot, we will only use the linear velocity x and the angular velocity z. This is because our robot is on a differential-wheeled platform; it has two motors to move the robot forward and backward and to turn.

We are working with a simulated robot on Gazebo, and the base controller is implemented on the driver used to move/simulate the platform. This means that we will not have to create the base controller for this robot.

Anyway, in this chapter, you will see an example to implement the base controller on your physical robot. Before that, let's execute our robot on Gazebo to see how the base controller works. Run the following commands on different shells:

    $ roslaunch chapter5_tutorials gazebo_xacro.launch model:="'rospack find robot1_description'/urdf/robot1_base_04.xacro"
    $ rosrun teleop_twist_keyboard teleop_twist_keyboard.py
  

When all the nodes are launched and working, open rxgraph to see the relation between all the nodes:

    $ rqt_graph
  

You can see that Gazebo subscribes automatically to the cmd_vel topic that is generated by the teleop node.

Inside the Gazebo simulator, the plugin of our robot is running and is getting the data from the cmd_vel topic. Also, this plugin moves the robot in the virtual world and generates the odometry.