obile robots were defined by Posadas et al (2008) as physical agents that move and interact continuously while embedded in a dynamic environment. A mobile robot is also described as a situated and embodied agent endowed with mobility (Obe and Dumitrache, 2012). Control of mobile robots is categorized into three types namely, autonomous control, semi-autonomous control, and Tele operation. Autonomous control implements various control algorithms that control mobile robots in their environment without human intervention. Semiautonomous control allows a user to instruct the mobile robot on what to do but the robot decides how the task is carried out. This mode of control is supervisory. In a Tele operated control, the mobile robot is entirely controlled by the user. Oxford dictionary (2015) defines "remote control" as the control of a machine or apparatus from a distance utilizing radio or infrared signals transmitted from a device. Teleoperation is often used in place of Remote control in research or technical environments. Teleoperation means controlling or doing work at a distance (Wichmann et al, 2014). The meaning of the distance, however, can vary. The distance can be physical, such as an operator controlling a robot at a remote location. The distance could also be a change in scale, for example, a surgeon using teleoperation to conduct surgery at the microscopic level. In 2014, Wichmann et al. reported that teleoperation systems are designed using a master-slave system model where the control system depends heavily on the mobile robot platform.

Various communication technologies have been used to achieve teleoperation for a mobile robot. These technologies include Bluetooth, Infrared, WIFI, GSM, Internet of Things (IoT) (Chikurtev, 2019), and Internet (Luimula et al., 2007). While some of these technologies impose a constraint on the range of operation, GSM and the Internet have proven to overcome such barriers (Chin et al, 2003, Ankit, 2014and Juang&Juang, 2016). The Internet which is based on TCP/IP enables connectivity of billions of devices worldwide, giving access to communication, data, pictures, videos, and even real images of distant environments (Siegwart and Saucy, 1999). The advancement in the development of internet applications has made it the ideal testing ground for sophisticated new applications, such as video-conferencing and remote control systems (Oboe & Fiorini, 1997). However, only a few examples of real physical interaction with distant places are available at the moment. Goodrich and Schultz (2007) defined two categories of interaction, remote and proximate. Remote interaction refers to the situation where the human and the robot are separated spatially or even temporally (i.e., Opportunity Mars rover), while with proximate interaction the humans and the robots are collocated.

This research work aims at creating a portable IP-based remote-controlled system for mobile robot interaction. According to James (1997), a software unit is portable (exhibits portability) across a class of environments to the degree that the cost to transport and adapt it to a new environment in the class is less than the cost of re-development. Portability in general terms is the usability of an object or component of the system in multiple environments without any modification in the internal structure.

Internet Protocol (IP) is a protocol in the Internet Layer of Transport Control Protocol/Internet Protocol (TCP/IP) model. It hides the underlying physical network by creating a virtual network view (Lydia et al, 2006). It is an unreliable, best-effort, and connectionless packet delivery protocol. Best-effort means that the packets sent by IP might be lost, arrive out of order, or even be duplicated. IP was designed with the assumption that a higher layer of the protocol will address these anomalies. According to Lydia et al., (2006), one of the reasons for using a connectionless network protocol was to minimize the dependency on specific computing centers that used hierarchical connection-oriented networks. Available remote control systems require specialized hardware and software that are heavily dependent on the mobile robot's platform or architecture. In this work, an architecture is proposed to eliminate the dependency of the remote control system on the robot's platform.

There are issues with existing mobile robot remote control systems which include but are not limited to, operation range, portability, and the multi-interface option of the system. Various researchers have addressed some of these problems, however, the problem of switching a remote control system from one mobile robot to another with little or no reconfiguration has not been dealt with. In Chin et al. (2003), a Real-Time Remote Control Architecture Using Mobile Communication was proposed. GPS, GSM, and GIS were applied in the development of real-time communication for remote data transfer which solved the range of operation problems, but the system lacked portability. Jose et al. (2004) illustrated a Java/Matlab-Based Environment for Remote Control System Laboratories. Matlab/Simulink and the Quanser Win Con environment were used to develop a control system using the HTTP server to process client requests. The client program is a java applet written in Java. The range of operation issue was eliminated by the architecture but failed to address portability and multi-interface options. In Mobile Robot Temperature Sensing Application via Bluetooth, Abdullah and Poh (2011) developed a control system using the KC-21 Bluetooth module and PIC16F877A microcontroller for remote temperature sensing. The system has a limited range of operations. Ankit et al. (2014) in Controlling of Remote Robot through mobile phone using DTMF Signal, developed a remote control system using microcontroller, CDMA modem, and DTMF signal. The system lacks portability and multi-interface options. Almali et al. (2015) developed a Wireless Remote control for Mobile robots operating in dangerous or narrow places for human beings. A 433MHz RF transceiver module was used to establish a connection between the mobile robot and the computer controlling it. The system has a limited operating range and also lacked portability.

This research work addresses the issue of portability and multi-interface options for mobile robot remote control systems. This will facilitate the use of one remote control system with a multi-interface for different mobile robots on several platforms, this will give room for using a robust interface for the control system at a particular time.

Oboe and Fiorini, 1998 in "A design and control environment for internet-based telerobotics describe the environment for the design, simulation, and control of internet-based force-reflecting telerobotics using a segment of the network to connect the master to the slave. Simulation of the complete telerobotic system and emulation using a planar force-reflecting master and a virtual slave uses a MatLab-Simulink program interfaced with a set of dedicated routines for internet modeling. The issues in the variable time-delay system were addressed by using the delay parameters acquired from the network probe to design the controller. However, the work does not address multiple interfaces that could be used as the master or controller. Lung et al., 2002; designed an internet-based human-assisted robotic controller system but the security of the web page was not considered as anyone that stumbles on the web application can control the robot. Chin et al., 2003 adopted the use of G3 (global positioning system (GPS), global system for mobile (GSM), and geographic information system (GIS)) system in developing realtime communication and remote control systems for robot real-time remote control, navigation, and surveillance. The designed system is not portable as it was only implemented on a Windows platform. Visual Basic, which is the choice of programming language, is not supported on other operating systems. Jose et al., 2004; developed a Java/Matlab-Based Environment for Remote Control System Laboratories, illustrated with an Inverted Pendulum -a novel environment that provides 24-hours-a-day access to a Web-based lab for the remote control of different didactic setups. A detailed description of an environment for the teleoperation of real Lab via the Internet, was achieved however, the design cannot be replicated on robots with different platforms due to the heavy dependence on Matlab/Simulink.

Abdullah & Poh, 2011; Mobile Robot Temperature Sensing Application via Bluetooth developed a Bluetooth-based control system for remote measurement of temperature from the robot's surrounding environment. The range of operation is limited to ten (10)

The proposed portable IP-based remote control system for Mobile Robots is aimed at solving two basic problems usually encountered with common Mobile Robot remote control systems. The first problem is the communication range between the Mobile Robot and its remote control interface. This range limit is entirely dependent on how far the communication link can transmit or receive data sent from both ends (usually 10 Meters for Bluetooth, 100 Meters for WIFI). The second problem is the portability of control interfaces with different platforms to provide different user interfaces that can be used to control different Mobile Robots. To solve the above-mentioned problems, the new system is divided into three functional parts namely: Command hub, Control Interface, and Mobile Robot Gateway.

Figure 1 shows the entire architecture of the Mobile Robot Remote Controlled System. The system components run separately on different devices, performing different roles in achieving the overall goal of the system. The components are also loosely coupled to ease upgrade and maintenance without affecting the operation of the other ones.

The Command Hub is at the center of the entire Remote control system for mobile robots. It is one of the three components required to develop the full system as shown in figure 2 The control interface component in the system is the one that interacts with the user and based on the operation performed on it, it will create and send an appropriate HTTP request to the command hub respectively. The control interface performs two basic functions. The first function is to take users' actions and transform them into a valid HTTP request required by the command hub. The second function is getting telemetry data from the command hub to create visual feedback for the users. The structure of this component is therefore organized along with its functions. Two modules are provided, one to constantly fetch new or updated data from the command hub to update the telemetry view of the mobile robot's vitals while the other module handles user interactions with the control interface and makes appropriate HTTP requests to the command hub.

Different Control Interfaces are designed based on the two modules explained earlier to expand the choice of control for each Mobile Robot in the system. Available control interface includes:

Cross-Platform Mobile Interface: This type of interface is meant for users that prefer to control their Mobile robots from a smartphone. The interface wasdesigned with Apache Cordova, HTML 5, CSS 3, and JavaScript. This ensures that the resulting interface can be used on Windows Phone, Android Phone, and iPhone as well.

Web Application Interface: This type of interface is available to users that want to control their Mobile Robots through a web browser. The web browser is used to access Web applications deployed alongside the command hub to provide the control interface. This Control interface is designed with ASP.Net MVC 4, HTML 5, CSS 3, and JavaScript. A variety of web browsers are supported.

Desktop Interface: In this type of control interface, the traditional Desktop application is used to provide the interface to the users. C# programming language is used to develop this interface.

This is the component that interfaces directly with the Mobile Robot. It plays a major role in connecting the robot to the remote control interface through the command hub. There are two different types of Mobile Robot Gateway namely, Internal Mobile Robot Gateway and External Mobile Robot Gateway. The internal Mobile Robot Gateway runs locally on the robot's operating system. This type of Gateway is only supported by Mobile Robots capable of running scripts, executable programs and whose hardware supports networking and direct connectivity to the Internet. The Gateway is implemented as part of the required software running locally on the robot's platform. The Gateway runs directly on the Mobile Robot's control board as shown by Robot 2 in figure 1. External Mobile Robot Gateway does not run on the robot platform, it runs on a remote computer connected to the Mobile Robot through Bluetooth or a WIFI device. This type of Gateway is meant for Mobile Robots that do not have shields or devices to directly connect to the Internet thereby using the remote computer's Internet connectivity for its operation. In the case of External Mobile Robot Gateway, a remote computer connected to the Internet is placed within the communication range of the Mobile Robot, the computer shares its internet connection with the Mobile Robot. The Gateway is also executed on the remote computer to serve as the conduit through which communication is established with the control interface via the command hub. Robot 1 in figure 1 makes use of the External Mobile Robot Gateway.

The Mobile Robot Gateway operates in a circle of three operations namely Sense/Listen, Think, and Act. Figure 4 shows the interaction of Gateway operations in a single circle.

? Sense/Listen Operation:-in this operation, the Gateway awaits new commands from the command hub through an active Web Socket if available or through an HTTP request to the REST API exposed by the command hub. If the Mobile Robot is in autonomous or semi-autonomous mode, values from the proximity sensors are fetched by the Gateway. Any data acquired from this operation is then passed on to the THINK operation in the circle. ? Think -analysis of data passed from the Sense/Listen operation is carried out during this operation. It is mainly responsible for command interpretation and conversion into a simpler form that could be handled on the Mobile Robot easily.

After the interpretation and conversion task has been carried out, the result is sent to the ACT operation to take necessary action. ? Act: -this part is responsible for generating the control sequence based on the input received from the THINK operation. It determines the destination of the resulting control sequence (i.e. Mobile Robot or Command hub). The control sequence now determines the behavior the Mobile Robot will exhibit. This operation is also responsible for sending telemetry data to the command hub. After this operation is carried out, control is returned to the Sense/Listen operation iv. Command Design One of the roles of the Command Hub is the generation of commands to be sent to the Mobile Robot. These commands are generated based on the interaction of the users with the control Interface. Each action performed by the user on the control interface corresponds to a specific command meant for the Mobile Robot to execute. When an action is performed on the control interface, a request is sent to the REST API (Application Programming Interface) exposed by the Command Hub. The Command Hub now maps the request to the corresponding command to be generated and sent to the Mobile Robot. For example, if the user presses the "Move Forward" Button on the Control Interface, an HTTP POST request is sent to http://Command-Hub-DomainName/api/move/1, then "f" command is generated and sent to the Mobile Robot. The "Command-Hub-DomainName" is the domain name of the server hosting the Command Hub. Table 1 shows the comprehensive list of all Uri, HTTP verbs, and associated commands mapped to them.

Volume XXI Issue I Version I At the hardware level, two robots were designed to validate the workability of the remote control system whose architecture was shown in figure 1. These Mobile Robots have different platforms and configurations each of which corresponds to the two types of Mobile Robots in figure 1. The Mobile Robots are: SleekBot V1: This was designed to use Arduino Nano R3 as its main control board. All other actuators and sensors are connected to the main control board. In this configuration, a Bluetooth module is used to communicate with an external Mobile Robot Gateway.

Figure 6 shows the breadboard schematics of the robot's hardware configuration.

SleekBot V2: This is the second Mobile Robot, it was designed to use Raspberry Pi 2 Model B as its main control board while Arduino Nano R3 was used as a slave control board. In this configuration, a USB camera with a two degree of freedom is connected to the mainboard and Internal Mobile Robot Gateway was used because the main control board is capable of running executable programs and it is also capable of connecting to the internet directly. Figure 7 shows the breadboard schematics of SleekBot V2.

The system was implemented in three stages, each stage corresponds to the deployment of each component that made up the system. For web interface users, the system provides a landing page where navigation to other modules is accessed. Figure 8 shows the home page layout.

Two types of Mobile Robot Gateway were implemented. The specific implementation used was determined by the robot's ability to connect directly to the internet. In a scenario where the Mobile Robot can connect directly to the internet, a python program was used to implement the Gateway. The second implementation was used when the Mobile Robot connects to the internet through another computer. A desktop application written in C# was used to implement the Gateway on the computer with internet connectivity.

At this stage of implementation, a web API written in C# was used to implement a REST-Based service that acts as the command hub for the system. The service was deployed to Internet Information Service (IIS) with MS SQL Server 2012 to act as the backend storage for the system.

This module is used to register all users making use of the control platform. All valid users of the system need to be authenticated before they are granted access to control any mobile robot remotely. Figure 9 shows the user registration interface for web interface users while figure 10 shows the registration interface for mobile users.

This module is used for authenticating all users making use of the system. All users must pass through this module to use the system. Figure 11 and figure 12 show the login user interface (UI) for web and mobile users.

The main menu provides navigation to important modules the user can use to perform different tasks in the system. Figure 13 shows the main menu for mobile interface users

To make use of any robot on the platform, the user needs to register the robot. Figure 14 shows the interface dedicated to the registration. After registration, all registered Mobile Robots by the user is displayed in the Mobile Robot List as shown in figure 15.

The settings module is used to configure the parameters required for the interface to work properly. Figure 16 shows a settings Interface for mobile Users

This interface provides the necessary widget to remotely control mobile robots. Actions performed on this interface translate to a command to be executed on the mobile robot. Figure 17 and figure 18 show the remote control interface for web and mobile interface users.

The goal of this research work to develop a portable IP-based multi-interface remote-controlled system for mobile robots was achieved. The system offers the use of a single remote control device across different mobile robots and the use of a multi-interface for a single mobile robot.

The solution architecture is based on three loosely coupled components performing various tasks at different levels to collectively achieve a single aim of having a portable control system. At the core of the system is a REST-based web service handling communication between the user interface and the mobile robot. Various programming languages were used at different levels to achieve the overall goal of the system. A cross-platform mobile application, Web application, and the desktop client was developed to serve as the system's user interface. Implementation of the system was carried out on three different mobile robots based on different platforms. The system was evaluated based on the time complexity of the algorithm used in its components. The result shows that the system time of execution is linear (O (n)).

The system developed is not without its weakness, hence the need to improve some parts that are currently inefficient in its mode of operation. These include:

1