Robot Control and Simulation

In this chapter, you will set up your ROS development environment specifically for programming GoPiGo3. This understanding is going to be built by going from using the keys of your laptop keyboard to the more technical way of using ROS topics. Finally, you will guess what topics will allow you to wire manual keyboard/topic-based control to internal programming logic (that is, smart behavior) that will make the robot capable of executing autonomous tasks. In this sense, 3D simulation in Gazebo is an essential tool for testing behavior during development before pushing the app to the physical robot, saving time and effort when it comes to field-based work.

By the end of this chapter, you will have learned how to set up the ROS environment for a real robot. Remote control and autonomous control establish a qualitative difference in terms of robot software...

Technical requirements

For this chapter, no additional hardware or software configuration will be needed. Just make sure that you have the following:

GoPiGo3, as per the Technical requirements section of Chapter 6, Programming in ROS – Commands and Tools
A laptop, as per the Configure your ROS Development Environment section of Chapter 3, Getting Started with ROS

In the next section, we will prepare the ROS environment so that your laptop and the robot can communicate with each other under a unique ROS graph. Let's go over the code we'll need:

Code for this chapter (laptop): In this chapter, we will make use of the code located in the Chapter7_Robot_control_simulation folder (https://github.com/PacktPublishing/Hands-On-ROS-for-Robotics-Programming/tree/master/Chapter7_Robot_control_simulation). Copy its files to the ROS workspace so that they're available...

Setting up the GoPiGo3 development environment

In the previous chapter, you tried the ROS desktop version in the Raspberry Pi of GoPiGo3. For a serious development strategy, you should launch the minimum configuration of the application in the robot and launch all the accompanying development tasks within the laptop.

Remember that in Chapter 3, Getting Started with ROS, you run ROS on your laptop. Hence, the robot application itself was executed in such an environment, with no possibility to move a physical robot since we didn't establish a connection outside of the computer.

In this section, you will learn how to work simultaneously with the laptop and Raspberry Pi ROS environments when they're linked, that is, the Raspberry Pi controlling the GoPiGo3 robot and the laptop for CPU-intensive computing/visualization tasks.

...

Case study 3 – remote control using the keyboard

This case study will help you complete the first version of the GoPiGo3 ROS package. In the previous chapter, you were dealing with the distance sensor and the Pi camera, and we devoted one case study to each of them.

By including the motion functionality with the present robot drives, you will have a robot that is able to perform basic interactions with its environment:

Perception capabilities include detecting obstacles with the distance sensor and visual recognition of the surroundings with the Pi camera.
Actuation capability, where the robot is able to move on the floor while being aware of the possible obstacles with the distance sensor and recognizing shapes and people with the image feed from its camera.

Case study 3 focuses on actuation capability. In this section, you will learn how to remotely move the robot using...

Remote control using ROS topics

In the previous section, you controlled the robot's publishing messages in the /cmd_vel topic using a human interface, the keyboard and the mouse. In this section, you will publish the messages directly using rostopic from the command line. This way, you will become familiar with this relevant topic and the structure of its messages. It is crucial to understand how /cmd_vel works under the hood since you will be using it in many of the advanced examples we'll be covering in the remaining chapters of this book.

The motion control topic – /cmd_vel

Now that we've enjoyed playing with the robot, let's understand how this form of control works. The /cmd_vel topic that the...

Remotely controlling both physical and virtual robots

Up to this point, you have dealt with a piece of configuration where the ROS master node ran in the robot. For the rest of this chapter, you will only be working with the laptop. Due to this, you need to revert your configuration so that the master node can be located again on the desktop computer. Otherwise, you will receive an error and won't be able to launch any ROS environment.

Reverting the ROS master to the local computer

The solution to this is pretty simple; just follow these steps:

Open your local .bashrc file and comment the line at the end that specifies what URL to point to in order to find the ROS master:

$ nano ~./bashrc
   ...
   export ROS_HOSTNAME...

Summary

In this chapter, you have achieved correspondence between the physical GoPiGo3 and its virtual model in Gazebo. You have checked how it doesn't matter whether you're controlling the actual robot or a virtual robot from the point of view of ROS. Since both are moved using the same topic, /cmd_vel, ROS does not care about which type of robot you're dealing with.

This fact explains how, from the point of view of ROS, you have the choice to test your code with a virtual robot and then safely apply it to the physical robot. We just need to launch the ROS node of the physical robot. This is useful in three situations. First, when you are developing a new application for an existing robot, you can debug the code with a virtual model in Gazebo. Second, when you do not have available the hardware of the robot – because you are still deciding which one to buy...

Questions

If you need to have two different computers communicating over ROS, where should you locate the ROS master node?

A) In the one that has the more recent version of ROS.
B) The ROS master node will run in the first one where you launch the roscore process.
C) You can place the master wherever you want. In one of the computers, you run roscore, and in the other one, you tell ROS that the master node is located in the other machine.

You have a physical robot named mazinger_zeta that accepts geometry_msgs/Twist messages in the /walk topic. What is the correct topic remapping command for remotely controlling the robot with the keyboard?

A) rosrun key_teleop key_teleop.py /walk:=/cmd_vel
B) rosrun key_teleop key_teleop.py /key_vel:=/walk
C) rosrun key_teleop key_teleop.py /walk:=/key_vel