Mobile robot system integration

The development overview section in this chapter introduced four topics of discussion in the mobile robot system integration, each of which is covered in the subsequent sections. An overview of the remote mobile robot system is given by Figure 4.15, which shows the communication between each module in the scheme.

Figure 4.15. Overview of the mobile robot system integration.

4.5.1 ROS implementation

The remote mobile robot code was also implemented using the Python programming language, and the program for each robot’s ROS implementation and localised control is documented in Appendix B. The Python client library for ROS is rospy, which enables the ability to interface between ROS topics and services. The flow diagram in Figure 4.16 represents a basic implementation of the ROS core, using topics that were subscribed to during the initialisation.

Topic names are also defined by the programmer at initialisation, and it is imperative that the topic name be used in a call-back function where the attributes of the topic are accessed. For example, the rosAI.py program in Appendix B subscribes to the amcl_pose topic in line 115. The topic name is defined as amclCb, which is the name of the call-back function in line 107,

and it is here where the AMCL attributes of the robot’s position are retrieved for use in the main loop of the code.

Figure 4.16. A basic format of the ROS core implementation.

4.5.2 Robot OPC-UA Client

The OPC-UA Client code implementation for each mobile robot is documented in Appendix C, under the OPCdata.py filename. Since the program was written in Python, the

OpenOPC library was used here as well, hence the connection to the Matrikon OPC Server

and the methods used for accessing OPC tags are direct implementations of the procedure outlined in section 4.4.6. One apparent difference is the change in IP address configuration due to the remote residence of the Client.

The OPCdata.py file was imported as a library in the remote robot control code (Appendix B), and the functions used from the file were: 1) getxyGoal which reads the robot’s x and y

coordinate goal location from the OPC-UA Server, 2) setStatus writes the current boolean status of the robot, whether it is busy or available, and 3) xyPos writes the current x and y coordinate position of the robot to the OPC-UA Server.

4.5.3 Decentralised robot control

The ROS move_base action client was used to move the robot to a specific location in the environment by accepting goal coordinate locations. The state diagram in Figure 4.17 shows the sequence involved in the local navigation algorithm. The sequence begins by waiting for a goal location command from the higher-level control system, via the OPC Server, and executes the move_base service after the “busy” status of the mobile robot is set. The status variable was used to reserve the robot resource to a particular task so that there are no goal location conflicts.

Figure 4.17. State diagram of the local navigation algorithm.

The goal was reached when the robot was within a distance of 0.5m from the actual location, which was calculated by using the standard distance formula between two points, as shown in Equation 4.1. 𝑑 = √(𝑥𝑔− 𝑥𝑐) 2 + (𝑦𝑔− 𝑦𝑐) 2 (4.1)

4.5.4 Stage simulation

The ROS/Stage simulation of the mobile robots involves the use of specific files, each containing parameters or definitions of the robots and the simulation environment. The diagram in Figure 4.18 represents the association between the different file types configured to achieve the simulation in Stage. References to the code in the Appendix are shown in brackets for each file.

Figure 4.18. Stage file associations with Appendix references in brackets.

The function of each file illustrated in Figure 4.18 is discussed in the list below:

 The world file is a programmable description of the simulation environment, which includes the robots and the map. The simulation window size and floor size can be defined here, as well as the attributes of the robots, such as the names, colours, and start-up positions in the simulation.

 The map file is included in the world file and allows for modular programming through the use of models.

 The turtlebot file is similar to the map file in that it allows for the definition of models related to the robots. These include robot size and hardware attached to the robot, such as laser range finders (LRF).

 The yaml file is required for the specification of the map data, which include the map image name and the resolution of the image.

 The launch file is essential since it was used to define the links between the various ROS nodes in the simulation. ROS and Stage topics were configured in this file for each robot in the system, and the parameters for the localisation algorithm, in this case AMCL, were also set. In addition, an optional definition for the ROS 3D robot visualisation tool, rviz, can be configured here.

An execution of the launch file produces a Stage simulation window with the map, robots, and LRF scanners as shown in Figure 4.19. The map illustrates the locations of two tasks, each containing source and destination points for the robots to transport material between goal locations.

Figure 4.19. Stage simulation window with map and robots.