IMPLEMENTATION AND RECONFIGURATION OF ROBOT OPERATING SYSTEM ON HUMAN FOLLOWER TRANSPORTER ROBOT

—Robotic Operation System (ROS) is an important platform to develop robot applications. One area of applications is for development of a Human Follower Transporter Robot (HFTR), which can be considered as a custom mobile robot utilizing differential driver steering method and equipped with Kinect sensor. This study discusses the development of the robot navigation system by implementing Simultaneous Localization and Mapping (SLAM).


I. INTRODUCTION
Robotic Operation System (ROS) is important to provide a flexible framework for developing robot related applications [1].ROS should be flexible and capable to provide distributed computations, software reuse, and rapid testing [2].The modular nature of ROS framework enables every aspect of the system to work separately and efficiently in regards to communications between nodes.By using ROS, community can develop algorithms for various purposes that are easily integrated to the framework and preserve the works for public.The flexible nature of ROS enables for coupling and message passing between existing processes and facilitates rapid testing even for applications that require advanced and stable data stream.
One of such systems has been developed previously for Human Follower Transporter Robot (HFTR) [3,4] (see Fig. 1).The references have developed the robot to be able to track and follow object based on the object color.However, the existing planning, execution, and monitoring (PEM) architecture is not sufficient to evade dynamic obstacles.In addition, developing a completely new algorithm requires significant amount of time.The existing program is not easily integrated to the next development phase for various reasons.
A number of studies related to ROS and HFTR has been previously conducted.Reference [5] studied the dynamic characteristics of bipedal robots.Reference [6] studied Segway robotic platform.Refer- Cite this article as: A. Saphala and P. I. Tanaya, "Implementation and Reconfiguration of Robot Operating System on Human Follower Transporter Robot," CommIT (Communication & Information Technology) Journal 9(2), 59-65, 2015.ence [7] studied navigation of wheel-legged hydraulic robot.[8] proposed systems and methods for robotic transport.Reference [9] discussed a near-term autonomy of follower robots.
This study intends to develop an improvement of HFTR navigation system.The system requires several inputs to function correctly such as the robot odometry, sensor, map, and data transformation.By utilizing ROS, the existing sensor system (Kinect) can be adapted for appropriate input for mapping and navigation (laser scan).It would enable implementation of simultaneous localization and mapping (SLAM), which is required to generate maps.HFTR would also be reconfigured to use the existing ROS framework and to transform data from encoder.Reconfiguration HFTR is often unavoidable because most of the existing driver is hard to be encapsulated to the ROS framework.Sometimes, using a compatible driver is preferable instead of adapting the old one.

II. RESEARCH METHODS
To implement and reconfigure the navigation stack of ROS for HFTR, Fig. 2 shows the dependency of the stack to the other modules.The stack depends on sensor sources, map, data transform, odometry, and base controller.
Firstly, the requirements for navigation stack are sensor data, odometry data, and map.The sensor data format follows the laser scan format to conserve the computing power.The HFTR is already equipped with  Kinect camera; thus, a converter is required from a depth image to laser scan.Consequently, Kinect camera driver is also required, which in turn, requiring data transformation where the data stream from their origin to the rest of HFTR.Secondly, the navigation stack requires odometry that supplying information of the robot movement and it is handled by the Differential Driver stack in the ROS.The Differential Driver stack requires: PWM adapters, which send a velocity command for robot motors, in this case, is to Arduino board through a serial port, and robot definition for virtual simulations.The Odometry also requires Data Transform to record the robot pose.

III. RESULTS AND DISCUSSION
In this section, we present the results of the implementation and reconfiguration of the HFTR operating system.Firstly, in order to utilize the navigation stack [2], the robot has to be configured in a specific manner.
Figure 3 shows the overview of the required configuration.The components in white boxed are those that have already been implemented.Those in gray are optional components and have also been implemented.Those in blue should be created for each robot platform.The navigation stack requires a transform configuration, which is unique for each robot, sensor information in a laser scan data type, odometry information, base controller, and map [10].
The above navigation stack requires a static map, which is created by Simultaneous Localization and Mapping (SLAM) module.A gmapping package is a ROS wrapper for OpenSlam's gmapping.This package provides ROS a node called slam_gmapping, which is a laser-based SLAM.Using this stack, a two-dimension occupancy grid map can be created.To utilize this package, the robot need to be able to steam a laser scan data, as well as provides a relatively accurate odometry data and transforms [11].In addition, the navigation stack also requires differential driver.The differential_drive stack provides basic tools to interface with differential drive robots with the ROS navigation stack.This stack can take twist message from navigation stack or other nodes, and publish messages for left wheel and right wheel of a differential drive robot.It also receives feedback from wheels encoder and generates transform messages as required by the ROS navigation stack [6].This package provides four nodes [7]: diff_tf that provides transform for the robot base, pid_velocity that is a basic PID controller for motor speed, twist_to_motors that translates twist messages to a two-motor velocity target for the differential drive robots, and virtual_joystick that is a GUI controller with twist output (see Fig. 4).
Figure 5 shows active nodes and topics from rqt_graph for navigation stack.Figures 6-9 show the enlarged portions of Fig. 5, and the figures respectively are the left, center, upper right, and lower right sections.
The active nodes include driver sections, sensor sections, navigation sections, localization nodes, and map server.The navigation section is centered on the topic move_base which governing where the robot should go through twist topic.The localization node, amcl, functions as pose matcher for the robot.The map_server node simply publishes a static map for the navigation section.
The launch file for the nodes in Fig. 5 is shown in Fig. 10.To execute map_server and amcl nodes, the code needed in launch file is displayed in Fig. 10.It also displays the launch code for move_base node which retrieve parameters from: • costmap_common_params.yaml,• local_costmap_params.yaml, • global_costmap_params.yaml,and  • base_local_planner_params.yaml.In Fig. 11, the costmap common parameters is presented.These parameters are used by both global costmap and local costmap.In this file, the obstacle range and ray trace range is defined, which means at which range the obstacle is detected and at which range the robot would attempt to seek a clear path.The footprint is the shape of the robot on two dimension, which have to be defined since the HFTR cannot represented by a circle but by a polygon.The observation source is the sensor input, which in this case is laser scan sensor.
Figure 12 shows the local costmap parameters.It simply defines the publish rate and update rate of the map, and local costmap's properties.It also defines the odometry topic and robot base.
Figure 13 shows the global costmap parameters, which define map topic, update frequency and robot base.Figure 14 displays the base local planner parameters, in this file, the maximum and minimum velocity and acceleration both translation and rotation of the robot is defined.Figure 15 shows a virtual representation of the HFTR with a static map inside rviz.The map used is that of FB311.In Fig. 16 the global costmap is shown on top of static map.In Fig. 17 the local costmap is shown on top of the static map.Finally, in Fig. 18 both map are shown on top of the static map.In Fig. 19, sending a navigational goal is shown, and in Figure 20, the virtual representation of HFTR can be moved inside rviz by sending twodimension position estimation data [13].

IV. CONCLUSIONS
The Robot Operating System software has been implemented and reconfigured to work with Human Follower Transporter Robot.The following are the related packages.The ROS serial package is required to enable communication through serial port with Arduino, which controls DC motors.The differential_drive package can act as a motors driver for the HFTR, as well as providing odometry and transform data.Kinect sensor can be utilized with ROS software; there are drivers for Kinect available within ROS framework, freenect_launch package, which include with coordinate frame transform program associated with Kinect's shape.ROS framework structure lends a flexibility to change the sensor data input, it enable streaming two dimension laser scan data from Kinect sensor.The slam_gmapping node works well with HFTR, the generated map can be used directly for navigation purpose without external changes.Navigation stack is able to be implemented and reconfigured for HFTR.It can control the movement of the HFTR reasonably well.Despite the unique mechanical design of the HFTR, ROS is able to function well with it.Thus it can be concluded that: ROS framework is generic, which means it can work with a lot of robot types.The absence of HFTR from ROS database and library means that the developed programs can be made into new package for HFTR in ROS library.Robot model which can be used to virtually represent the HFTR can be used in rviz.The models evolution also can be seen as implementation process of ROS.With better implementation of ROS, various parameters and data can be included in URDF file for more complete description, which results in more detailed model.From the navigation experiments, it can be concluded that: the navigation stack can be implemented and reconfigured in HFTR; the navigation stack can register static map and obstacle; the occupational value in grid map can be seen from global costmap (wall) and local costmap (obstacle) which depends on distance from the object (inflation); and, the navigation pose and goal can be sent through rviz.

Fig. 2 .
Fig. 2. The connection between modules in the robot operating system.The directed line denotes dependency, for example, module Navigation requires module Map.

Fig. 3 .
Fig.3.The navigation stack overview[4].Those components in white blocks have been developed, in gray are optional, and in blue are those created for each robot platform.