Parameterization and Design of Telepresence Robot to Avoid Obstacles

Featured Application

Telepresence robot is useful for remote applications, healthcare and remote sensing.

Abstract

Background: The development of telepresence robots is getting much attention in various areas of human–robot interaction, healthcare systems and military applications because of multiple advantages such as safety improvement, lower energy and fuel consumption, exploitation of road networks, reduced traffic congestion and greater mobility. Methods: In the critical decision-making process during the motion of a robot, intelligent motion planning takes an important and challenging role. It includes obstacle avoidance, searching for the safest path to follow, generating appropriate behavior and comfortable trajectory generation by optimization while keeping road boundaries and traffic rules as important concerns. Results: This paper presents a state machine algorithm for avoiding obstacles and speed control design to a cognitive architecture named auto-MERLIN. This research empirically tested the proposed solutions by providing implementation details and diagrams for establishing the path planning and obstacle tests. Conclusions: The results validate the usability of our approach and show auto-MERLIN as a ready robot for short- and long-term tasks, showing better results than using a default system, particularly when deployed in highly interactive scenarios. The stable speed control of the auto-MERLIN in case of detecting any obstacle was shown.

1. Introduction

The development of telepresence robots is getting much attention in various areas of human–robot interaction, healthcare systems and military applications. The evolution of 6G and 5G also supports these systems and makes them easy to implement. Operating such systems remotely is easy and can be employed in healthcare surgery, and stopping wild forest fires. Many rescue operations use the latest communication technology devices [1]. The prominent areas include healthcare, elderly assistance, autism therapy, guidance and office meetings [1,2,3,4,5,6,7]. The word telepresence [8] means thinking of oneself as being controlled remotely in another environment. The telepresence robots connect through a remote location and receive commands of moving and actuating in that remote location.

Different studies address user-adaptive [2,8] and environment-adaptive systems [9] for human–robot interaction. However, these studies lack many deficiencies in obstacle avoidance and precise self-localization. In the present research work, we further explore the telepresence robots, emphasizing the design of speed control with an additional feature of avoiding obstacles. The mobile experimental robot for locomotion and intelligent navigation (MERLIN) is based on a 40 cm long lightweight chassis and a suspension system, enabling it to drive up to 40 km/h outdoors. Due to its initial purpose, it can be easily equipped with different sensor configurations to characterize the working environment.

In the recent era, telepresence mobile robotics has been expanding rapidly, with a wide range of commercial systems availability and research support [9,10,11,12]. The published work varies from navigation and immersion systems to corporate office and healthcare systems assessments. However, a comprehensive systems design with precision target control is lacking. The main purpose of this paper is to provide a design and analysis of the control systems, their experimental setup, and self-localization with future research directions.

MERLIN is a robotic system based on serious plays for upper limb telerehabilitation in patients with a stroke [13]. It is presented as an affordable and easy-to-use solution to allow the patient to complete intensive rehabilitation at home, with continuous remote monitoring and communication with the therapist [12,13,14]. The system comprises an upper-limb rehabilitation robot and a software platform that guides and measures the patient’s movements and allows physicians to customize the therapeutic plan and monitor the patient’s evolution [15,16].

The purpose of this manuscript is to present the usability validation of the MERLIN system. In this study, we evaluate the ease of use, consistency and acceptance of the system. These systems aim to capture the environment appropriately and to maneuver based on acquired knowledge [17,18,19,20,21]. The main contribution of this paper is to analyze the speed and position controller and stabilize the non-linear behavior by designing an optimized control system. This paper presents and illustrates some ideas that would contribute to the genetic basis of architecture, allowing us to take into account as far as possible the previous requirements. The challenge may be understood as the feasibility of designing an autonomous robot with the capacity to plan its actions to accomplish specified tasks. For that purpose, we emphasize design aspects: speed and control analysis. Furthermore, verification aspects will be made possible almost from implementation up to high-level mission specification when models based on state transition systems are employed.

In the presented research work, a mobile robot based on a chassis of a vehicle model was developed. In particular, a microcontroller-based control was developed, which controls the robot’s behavior depending on user preferences and environmental influences and controls. In addition to the pure control, actuators and sensors, the chassis may be modified or upgraded [22]. This includes small mechanical structures that are necessary. To control the robot’s trajectory, a control program will be developed to evaluate the measured values of various sensors and then spend appropriate control variables on the actuators. In addition, the controller is equipped with a communications interface that allows it to cooperate with a superior level of control. This contains the user program, with which the user can parameterize the robot. The computer also has a wireless interface to operate the robot wirelessly. The basic framework is necessary for the user program, which executes the mini-computer.

Subsequently, the robot’s behavior was examined theoretically. Our findings show that the robot’s safest trajectory settings are determined to apply. Finally, some test scenarios were run with the robot to determine its real behavior for a given trajectory. The desired behavior should be roughly similar [15].

As already mentioned, for this paper, a chassis of a vehicle model type hobby products international (HPI) Savage 2.1 was developed [16]. As shown in Figure 1, a two-track vehicle was equipped with Ackermann steering. It means that the vehicle can drive with only the two front wheels. In addition, the vehicle has four-wheel drive. The force can be transmitted to all four wheels in the same direction. Thus, similar conditions prevail here as in a conventional automobile with four-wheel drive. Turning on the spot is not possible. It follows that the position and orientation of the vehicle are coupled.

The aim should be for the mobile robot to equip MERLIN so that it leaves prescribed paths, navigate, detect obstacles, and avoid them. This required entirely new control electronics to be developed because the old control system did not meet expectations. MERLIN already uses the powerful direct current (DC) motor TruckPuller3 7.2V for the drive and the powerful model-equipped servo motor HiTec HS-5745MG for steering [17]. The drive motor is also equipped with an optical position encoder of the type of the company M101B MEGATRON Elektronik AG and Co, Germany. [18], which the speed and direction can determine.

In Section 2, the background of the study is reviewed, and in Section 3 of this paper, the remote control aspects are addressed in particular, and the modeling and design of the trajectory-controlling algorithm are developed. This is, in particular, used in assembly/disassembly tasks over a given trajectory, where objects are to be pushed by the vehicle toward target locations. Hardware assembling is developed in Section 4. Section 5 presents the results and discussion of the designed control: left/right turn and self-localization.

2. Background

One must choose a technology whose deployment is easy and is quickly understandable by the third-party user. If the user is familiar with the technology and getting acquainted, then no operational manual is required to perform a complex task. This is usually demanded in many fields, including plays, mobile applications, computer programs and robotics. In teleoperating devices such as telepresence robots, the communication interface plays a vital role in controlling the robots [19]. In the healthcare system field, master–slave robots (as a slave) work under the command of an expert (master). The additional usability feature could be an important feature by which many experts from various fields can operate the robots as per their demands or requirement efficiently and flexibly [20,21,22,23,24,25]. The following examples are where experts in many applications can employ these robots.

Medicine is one of the important areas that took advantage of teleoperated systems. The crucial objective is to enhance the performance using the teleoperated robots with good precision and accuracy. These teleoperated robots are becoming more common in microsurgery and minimally invasive surgery [26,27]. Another application area is virtual reality (VR) [27], used for training purposes [28] and simulations [29], which provides more sophisticated knowledge. The military is another area where these teleoperated systems are deployed. The major objective of using robots in this area is to protect human beings from being harmed in high-risk and dangerous situations. To perform such tasks is even crucial, and it is vital to spend less time obtaining the knowledge of the situation [30]. Other similar applications, such as retrieving casualties in battle [10,11,21] or detecting chemicals, gas or radiation [30,31], are also found. Many such systems are employed for many useful purposes, e.g., rescuing people from hazardous situations (fire or collapsed buildings) [32].

Understanding and evaluating the implementation of healthcare interventions in practice is an important problem for healthcare managers and policy-makers [20], and increasingly for patients and others who must operationalize them beyond formal clinical settings [21,22]. Robots are often the only way to explore and manipulate objects in hostile and remote areas. Traditional application areas are space exploration and processing plants for radioactive materials [10]. The advanced concepts for remote control approaches have been realized and are based on combinations of information processing methods with control approaches [23,24]. The increasing capabilities of telematics (telecommunication + informatics) infrastructure, in particular services provided via the Internet, enable nowadays a broad spectrum of commercially interesting applications of these techniques, including telemaintenance of equipment in industrial production or tele-education based on remote experimental facilities [25]. Telematics technologies enable the provision of a continuously growing spectrum of services at remote locations. Major applications are industrial automation, telerobotics for hazardous environments, spacecraft telemetry and telecommand, traffic control, smart homes, tele-education and telemedicine [13,15].

It is known that the necessity of designing truly autonomous robots comes from highly demanding applications (e.g., undersea intervention, planetary exploration, working in nuclear plants, and the coronavirus disease of 2019 (COVID-19)) [12,27,27]. Since when working in such application fields, any repairing intervention is excluded, the need for total technological autonomy is obvious. Furthermore, the dialogue with the end user is reduced to mission specification and, when possible, very few high-level communications. This means almost total operational autonomy is also required, especially in perception, decision and control. This search for functional independence raises major questions in control theory, knowledge-based and reasoning systems, and architecture. However, the specificity of the application domain generates particular constraints, which may sometimes be antagonistic according to the concerned scientific discipline. Historically, many approaches have been developed for performing robot behaviors [3,26,28].

A general hierarchical scheme of autonomous vehicles (AVs) can be found in [29,30]. An AV or robot consists of both software and hardware architectures. Some hardware elements, such as sensors, provide imperative information for the software module [8,12,31]. Furthermore, the software module of AVs generates control commands according to the safety and comfort of the trajectory to the actuator. The actuator controls the hardware activities of AVs, such as steering, acceleration, deceleration, etc. Much research work focuses on identifying and stabilizing the AV and developing a micro-controller-based architecture [10,12,32]. The core responsibility of the design is to control the driving behavior and avoid an obstacle at each instant [8,33,34]. Another important module is the driving behavior planner, which is a decision-making module that provides reasonable obstacle avoidance and safe driving actions [35,36]. Another word, “maneuver,” is also used in the literature for this purpose, but for more clarity and consistency, the term “behavior” will be used to describe it throughout this paper. According to the actions generated by the behavior decision-making module, other independent attributes such as position, trajectory, orientation, and speed are considered [23,37,38]. A popular trajectory definition is a sequence of free-space spatiotemporal states feasible for vehicle dynamics [7,12]. The trajectory control in the software architecture of AVs was presented by [25,39,40,41] in a dynamic traffic environment.

Many trajectory controllers, such as geometric and kinematic, dynamic, optimal, adaptive, model-based and classical controllers, have been implemented for trajectory tracking control [26,35,38,42]. In the past literature, a trajectory planning survey was presented by [13] for autonomous ground vehicles (AGVs), and [43] proposed a comprehensive discussion of motion prediction models and risk estimators. The authors in [44] investigated the functional architecture for autonomous driving and the reasoning for distributing the principal components across the architecture. An overview of the control design methods to handle uncertain forecasts for semi-autonomous and autonomous vehicles was given by [33,37,45,46,47]. From the survey papers, it is easy to conclude that each article investigates individual components such as motion planning, behavior planning, and trajectory control rather than an integrated system [28,44].

One important area is sensor selection and integration. Researchers are exploring using various sensors, such as cameras, lidar, radar and ultrasonic sensors, to detect obstacles and determine the robot’s location. They are also investigating how to integrate these sensors best to provide a robust and reliable obstacle-detection system [48]. Another area of focus is control algorithms. Researchers are developing advanced algorithms that can accurately predict the robot’s motion and path and quickly respond to environmental changes to avoid obstacles. These algorithms typically involve using sensor data to estimate the robot’s state and then using that information to plan and execute safe trajectories [49]. A third area of focus is human–robot interaction (HRI). Telepresence robots are often operated by humans, who may not have much experience with robotics. Researchers are investigating how to make the control interfaces for telepresence robots more intuitive and easier to use to enable more effective human–robot collaboration [50].

In summary, the proposed work is focused on improving the reliability and robustness of the obstacle detection and avoidance system, developing advanced control algorithms that can quickly and accurately respond to changes in the environment and making the control interfaces user-friendly [51].

3. System Design and Implementation

The focus moves in a linear function of the target position between the robot’s orientation at the start of the trajectory and orientation. The following values given in

Table 1. Important parameters of calculation.

Values	Meaning
StartOri	Robot orientation at the start of the trajectory
TargetOri	Robot orientation trajectory target
TargetPos	Arc length of the moving trajectory
OriScale	Scaling the orientation difference between the start and end concerning the arc length of the trajectory

are of particular importance:

$$OriScale=\frac{TargetOri-StartOri}{TargetPos}$$

(1)

where this is an angle that must be in the interval [−π; π]. It is, therefore, possible to use modulo 2π arithmetic.

The simulated orientation finally calculates to:

$${\theta }_{{\varphi }_{\left(t\right)}}=StartOri+OriScale·{\varphi }_{\left(t\right)}.$$

(2)

As already mentioned, the simulated position and orientation values serve as setpoints for the position and orientation controller, where ${\varphi }_{\left(t\right)}$ represents the target position, which is the integration of the target speed. The position controller is implemented as a proportional-integral-derivative (PID) controller with anti-wind-up feedback. On the other hand, the orientation controller controls based on the distance covered, so a proportional-integral (PI) controller with a variable time base is selected here.

In addition to pure position and orientation control, there is obstacle detection and avoidance. It is superimposed on the two controllers and intervenes in the event of an impending collision with an obstacle. The two controllers are frozen because the robot must correct its course after avoiding an obstacle and stops first.

The above-described state machine for avoiding obstacles is shown in Figure 2. If the front sensors detect an obstacle too close, the trajectory run can no longer be continued. Therefore, the robot first stops as fast as the speed controller allows. Then the robot slowly drives backwards for 6 s with the steering turned to the maximum. The steering direction depends on which sensor detected the obstacle. In case the left front sensor detects the obstacle, the wheels are turned to the left; otherwise, the wheels are turned to the right. If one of the rear sensors detects an obstacle, the robot remains standing until the obstacle disappears. For a fixed obstacle, the robot will no longer drive backwards. If an obstacle rushes by, reverse travel is continued after the obstacle has disappeared. It must be remembered that the robot only forgets nearby obstacles after a second. After the time has elapsed, the robot slowly drives straight ahead unless a nearby obstacle is detected by at least one of the front sensors. Otherwise, the robot remains standing, just like when reversing. After 6 s, it is checked whether at least one of the front sensors detects a nearby obstacle. If so, the evasive maneuver described begins again from the beginning. Otherwise, the robot stops and reports to the mini-computer that it has successfully avoided an obstacle. It must then supply new target data, regulation of position and orientation, obstacle detection and avoidance.

3.1. Speed Control

The speed controller, as shown in Figure 3, controls the speed of the robot’s drive train. The drive consists of two DC motors connected in parallel, transmitting their mechanical power to the drive gear. On the electrical side of the motors, they are fed by the motor controller. The motor controller itself receives the manipulated variable from the controller. The actual value of the drive, i.e., the estimated position of the robot, is recorded by the encoder on the drive gear. This actual position value is differentiated once, smoothed, and finally fed into the control loop. A digital PID controller with anti-wind-up feedback is used as the controller here, but it is only used as a PI controller.

Path planning and self-localization are two important components of telepresence mobile robots. Path planning is determining the best path for the robot to follow to reach its destination while avoiding obstacles and other potential hazards [52]. Path planning algorithms typically use sensor data, such as information from cameras or lidar, to build a map of the robot’s environment and then to plan a safe and efficient path. Some common path-planning algorithms include the A* algorithm, Dijkstra’s algorithm, and rapidly-exploring random trees (RRTs) [53].

Self-localization is the process of determining the robot’s current location within its environment. It is typically done by using sensor data, such as information from cameras or lidar, to compare the robot’s current sensor readings with a pre-built map of the environment [54]. Some common self-localization algorithms include Monte Carlo localization (MCL), extended Kalman filter (EKF), and particle filter [55].

Path planning and self-localization are essential components for telepresence mobile robots, which help it to navigate and operate autonomously. They are typically integrated into a single control system that can make decisions and take actions based on sensor data and the robot’s current location and destination.

It is important to note that both path planning and self-localization are active research areas, and new algorithms and techniques are being developed to improve these systems’ reliability, robustness and efficiency.

The block diagram of the speed control loop is shown in Figure 3, in which we highlight three red boxes. These boxes are replicas of the real technical control of the robot modules. The red box motor driver describes the MD03 motor driver module. The module expects a manipulated variable $u_{\omega \left(t\right)}$ with values between −243 and 243. The quantizer then quantizes these to integer values. Finally, the output signal is normalized to values between −1 and 1. It is not normalized to the output voltage of the motor driver since it depends on the battery voltage. The battery voltage is considered in the gain of the controlled $K_S$. The motor driver directly closes the red box on the drive train, whose input variable is the output of the motor driver.

The drive model is approximated as a PT₂ element to determine the vehicle speed. This model contains the drive from the battery voltage to the motors and the gearbox to the tires. In particular, this modeling also includes the weight of the robot. A step response experiment determines the parameters $K_S$, ${\tau }_{S1}$ and ${\tau }_{S2}$ of the drive train. The integrator following the PT₂ element completes the model in that the robot travels a distance. It integrates the speed to a distance.

The red encoder box represents a control-technical simulation of the built-in rotary encoder. The rotary encoder has an integral behavior here since it picks up the speed from the gearing but converts it into a distance during processing. Since the encoder discretely measures the distance covered, it quantizes the distance to whole encoder pulses, i.e., integer values.

The hardware components must be completed with suitable software to form a control loop. First, the encoder position value is differentiated to obtain the robot’s speed. A PT₁ element then smooths this value with the time constant ${\tau }_P$ to reduce noise. This smoothed value is the actual speed $y_{\omega \left(t\right)}$ at the setpoint/actual value comparison.

A PID controller with anti-wind-up feedback is used as the controller. The manipulated variable limitation in the controller should correspond to the manipulated variable limitation of the motor driver so that the anti-wind-up feedback can work optimally.

It should be mentioned that angular velocities $\omega$ and angular distances $\phi$ are processed in the controller model. However, these are proportional to the linear speed and distance of the robot. Only the constant of proportionality still has to be determined in an experiment that will be carried out later.

To adjust the control loop, a model of the drive train that is as precise as possible is first required. As already mentioned, the drive is modeled by a PT₂ element and subsequent integrator. The parameters are determined by analyzing the robot’s step response. The distance covered is recorded by the robot via the step response function. This recording can then be transferred to a personal computer (PC) for evaluation. However, since the speed step response is sought, the values obtained must be differentiated numerically once. The step response shown in Figure 4 was carried out with two “TruckPuller3 12V” drive motors with a battery voltage of 7.2 V and without a mounted PC. The blue characteristic shows the measured values. The quantization by the rotary encoder can be seen very well with them. The characteristic red curve describes an ideal PT₂ element with a gain of $K_S$ = 1350, and the time constants ${\tau }_{S1}$ = 0.1 s and ${\tau }_{S2}$ = 0.4 s. This element represents a fairly good approximation of the real system.

All variables are now known to set the control loop. For the time being, the PT₁ element is bypassed in the feedback to make the controller design easier. The PID controller is only used as a PI controller. It avoids erratic behavior of the control loop, which would be problematic anyway due to the limitation of the manipulated variable.

All time constants are represented as poles and zeros in the following derivations:

$$p_x=-\frac{1}{{\tau }_x}, n_x=-\frac{1}{{\tau }_x}$$

(3)

The drivetrain part relevant to the cruise control is the PT₂ element. Its mathematical description is:

$$G_S\left(s\right)=K_S·\frac{p_{S1}·p_{S2}}{\left(s-p_{S1}\right)·\left(s-p_{S2}\right)}$$

(4)

The PI controller lets itself through:

$$G_R\left(s\right)=K_P+\frac{K_i}{s}=K_P\frac{s+\frac{K_i}{K_P}}{s} =K_P.\frac{s-n_R}{s}$$

(5)

with the zero:

$$n_R=-\frac{K_i}{K_P}$$

(6)

For completeness, the transfer function $G_P\left(s\right)$ of the PT₁ element in the feedback is:

$$G_P\left(s\right)=K_S·\frac{\raisebox{1ex}{$1$}\!\left/ \!\raisebox{-1ex}{${\tau }_P$}\right.}{s+\raisebox{1ex}{$1$}\!\left/ \!\raisebox{-1ex}{${\tau }_P$}\right.}=-\frac{P_P}{S-P_P}$$

(7)

All quantizers and manipulated variable limitations are not considered when parameterizing the controller. As a result, the integrator of the encoder and the subsequent differentiator cancel each other out. This means that only the PT₁ element is left in the feedback path.

First, the transfer function of the open loop is determined. The amplification factor $K_M$ of the motor-driver must also be considered.

$$G_o\left(s\right)=G_R\left(s\right)·G_S\left(s\right)=K_P·\frac{s-n_R}{s}·K_M·K_S·\frac{p_{S1}·p_{S2}}{\left(s-p_{S1}\right)·\left(s-p_{S2}\right)}.$$

(8)

$$G_o\left(s\right)=K_p·\frac{K_M·K_S·p_{S1}·p_{S2}·\left(s-n_R\right)}{s·\left(s-p_{S1}\right)·\left(s-p_{S2}\right)}$$

(9)

Now the controller’s zero point $n_R$ is selected so that the slowest pole point is compensated. This simplifies the controller function to:

$$G_o\left(s\right)=K_P·\frac{K_M·K_S·p_{S1}·p_{S2}}{s·\left(s-p_{S1}\right)}$$

(10)

with:

$$n_R=p_{S2}$$

(11)

Since the feedback is bridged, it is sufficient to determine the transfer function of the open loop for the root locus. If one inserts the system parameters determined into Equation (9), one obtains the transfer function of the open control loop:

$$G_o\left(s\right)=K_P·\frac{\frac{1}{243}·1350·\left(-10\right)·\left(-2.5\right)}{s·\left(s-\left(-10\right)\right)} =K_P\frac{138.8}{s^2+10·s}$$

(12)

3.2. Root Locus of Speed Controller

The root locus for this is shown in Figure 5. The aperiodic limiting case occurs at a controller gain of $K_P$ = 0.18. With larger gains, the controller oscillates. The root locus curves were determined using MATLAB’s single-input, single-output (SISO) design tool. If the smoothing in the feedback of the control loop is also considered, the controller receives an additional pole. This also significantly changes the root locus curve. For the controller parameterization, the smoothing has a time constant of ${\tau }_P$ = 0.05 s, corresponding to a pole at −20.

Figure 6 shows the root locus of the new control loop. The poles for distinctive points are drawn in different colors. The aperiodic limit case occurs with a controller gain of $K_P$ = 0.139 (magenta). The stability limit is at a gain of $K_P$ = 2.15 (orange). The amplification of $K_P$ = 0.18 (green) determined in the previous investigation leads to a slightly oscillating behavior.

Now the transmission behavior of the control circuit is determined. The open-loop transfer function is unaffected by the smoothing in the feedback, so Equation (9) can still be used for this. However, the transfer function $G_G\left(s\right)$ of the closed control loop is relevant for the overall behavior, which is calculated as:

$$G_G\left(s\right)=\frac{G_o\left(s\right)}{1+G_o\left(s\right)·G_P\left(s\right)}.$$

(13)

By inserting the individual transfer functions, one obtains:

$$G_G\left(s\right)=\frac{\frac{K_p·K_M·K_S·p_{S1}·p_{S2}}{s·\left(s-p_{S1}\right)}}{1+\frac{K_p·K_M·K_S·p_{S1}·p_{S2}}{s·\left(s-p_{S1}\right)}·\left(-\frac{p_P}{s-p_P}\right)}.$$

(14)

By solving the double fraction, we obtain:

$$G_G\left(s\right)=\frac{K_p·K_M·K_S·p_{S1}·p_{S2}·\left(s-p_P\right)}{s^3-\left(p_{S1}+p_P\right)·s^2+p_{S1}·p_P·s-K_p·K_M·K_S·p_{S1}·p_{S2}·p_P}.$$

(15)

At this point, the controller gain of the speed controller is set to $K_P$ = 0.18. The control circuit thus has a slightly oscillating behavior. However, it must be noted that the actual value measurement is subject to a large amount of quantization noise. If the oscillation amplitude is below the rotary encoder’s resolution, it is practically non-existent because it cannot penetrate the controller input. Due to the zero point $n_R$ at $n_R$ = $p_{S2}$ = −2.5, the amplification of the integral component is calculated:

$$K_i=-K_p·n_R=-0.18·\left(-2.5\right)=0.45.$$

(16)

This means that all parameters for the speed controller are known. Inserting them into Equation (15) results in the transfer function $G_G\left(s\right)$ for this special case of the speed controller.

$$G_G\left(s\right)=\frac{25·s+500}{s^3+30·s^2+200·s+500}$$

(17)

The poles of the controller are included:

$$P_1=-21.9149$$

(18)

$$P_{\raisebox{1ex}{$2$}\!\left/ \!\raisebox{-1ex}{$3$}\right.}=-4.04256\pm 2.54426j$$

(19)

The zero point of the controller corresponds to the time constant ${\tau }_P$ of the PT1 element in the feedback.

$$n=-20$$

(20)

Figure 7 shows the step response of the speed controller when the speed jumps from 0 EncImp/s to 800 EncImp/s at time t = 0 s. The diagram clearly shows that the system is corrected very quickly. There is a slight overshoot in speed.

The permanent oscillation is so small that it can no longer be seen in the diagram. The system reached the end value after approximately one second. The controller is thus set almost ideally. Finally, the manipulated variable-limited and quantized control loop was modeled with Simulink and given the same step response. The result can be seen in Figure 8. It can be seen that the actual y value has reached the setpoint u after approx. one second. Furthermore, as expected, a slight overshoot of the actual value and a strong quantization of the speed by the rotary encoder can be seen. Overall, however, this is a very satisfactory result.

4. Results and Discussion

The result section deals with some test scenarios with which the quality of the parameterized robot can be determined. For this purpose, relevant data were recorded by the robot and then displayed graphically. The data were recorded directly from the microcontroller for the experiments where only the drive speed is shown. The data source was therefore recorded lucidly. In the trajectory experiments, only the mini computer was recorded. However, its sampling rate is not synchronized with the robot, so a small amount of jitter can occur in the sampled values. It is sometimes reflected in small jumps in the curves.

Table 2. Significant experimental parameters.

Parameters	Unit	Value
Obstacles	4 × 4 feet	8 (Static)
Path	Curved	1
Starting Point	-	Main entrance
End Point	-	Corridor
Coverage	meters	140

contains the significant parameters for the experiment environment, which shows the obstacle type, i.e., static, and the number of static obstacles is eight and 4 × 4 feet in size.

4.1. Speed Control Loop

The first experiment analyzed the speed controller. The quantization of the actual speed created by the rotary encoder was 100 EncImp/s. Step responses of the velocity loop from a standing start were recorded for velocities of 100, 200, 300 and 600 EncImp/s. Based on the simulations already carried out on the ideal robot model, the final value should be reached after about one second. The step responses were recorded in the hallway of the electrical engineering (EE) building at the University of King Abdulaziz. Since the ground there is very flat, it is an almost interference-free environment. Figure 9 shows the four-step responses in a jitter-free time diagram, where the graphs were previously smoothed with a digital PT₁ element with a time constant of 20 ms.

It is easy to see that all step responses reached the final value after about a second and then oscillated around it. The deviation of the slightly smoothed measured values was around ±50 EncImp/s for each graph. This is a very good value. The oscillating behavior probably resulted from many individual components.

First, the controlled system, i.e., the drive train, is very complex since it combines many mass-spring-damper systems and some non-linearities. For the sake of simplicity, however, the track was modeled as a PT₂ system. The effect of the play can be seen very well in the magenta graph. The speed jumps to a very high value for a short time in the beginning. This results from the no-load acceleration of the transmission during play. If it is used up, the motors are abruptly braked, and the robot accelerates as desired.

4.2. Step Response

On the other hand, the system also oscillated due to the rotary encoder’s quantization and the controller’s setting. It was parameterized intentionally, so it tends to oscillate, but the amplitude remained below the encoder resolution. A step response followed with a speed of 300 EncImp/s. This was carried out in the courtyard of the EE building of the University of King Abdulaziz. The ground there has bumps at periodic intervals, representing a strong disturbance for the slow drive speed. The bumps are small valleys on the ground surface. The recording is shown in Figure 10 and contains measured values smoothed with a PT₁ element with a time constant of 20 ms.

The graph shows that the controller regulated the robot quite well. It should be noted that the quantization of the encoder was 100 EncImp/s steps. Without a fault, the controller deviated from the setpoint here by −50/+75 EncImp/s. After around eight seconds, the speed increased slightly as the robot’s front wheels sank into the bump. The robot actively tried to slow down the increase in speed using the motors. Now the wheels had to be lifted out of the valley again. This required a lot of energy, which first had to be made available by the drive. However, since it was very slow due to the last braking, it took some time for the motors to build up enough power again. This can be seen in the graph by the valley just before the ten-second mark. After overcoming the first obstacle, the robot accelerated strongly due to the still very large manipulated variable and the speed overshoots. Finally, the procedure started again since the rear wheels sank into the bump. However, the braking effect was much greater here since most of the robot’s weight was on the rear axle.

On the whole, however, the disturbance was quite well-compensated for. It must be remembered that this is a violent and short-term disruption. The disturbance would be completely corrected if the robot were to work on a long uphill or downhill gradient. It should also be noted here that the cruise control is also active at zero speed, i.e., when stationary. This means that the robot is actively braking with its motors. If one tries to move the robot with an external force, this is quite easy at first, but it becomes more and more difficult as the robot defends itself against this disturbance more and more.

4.3. Avoiding Obstacles

Now, the course of the speed when driving around an obstacle is shown for completeness. The robot should move backwards for 6 s with 300 EncImp/s and then forward at the same speed for 6s. The course of the actual speed, which was smoothed with a PT₁ element with a time constant of 20 ms, is shown in Figure 11.

A good approximation of the setpoint can be seen for both setpoint jumps. Thus, the robot moved fast enough to avoid an obstacle.

Different categories of healthcare-based telepresence robots have been discussed [48,49,50,51,52,53,54]. Different telepresence robots used by healthcare doctors to interact with patients during their initial visit have been described. The major advantage of the proposed technique is to help frontline healthcare workers to be safe from an infected patient.

Most of the proposed controlling techniques can interact with telepresence robots efficiently and robustly, except for the lack of control in the scenario of disconnection or delays. Based on the review, all existing telepresence robots cannot behave intelligently according to the controller behavior in communication issues. This study shows better, more effective and more efficient control techniques for interacting with telepresence robots for specific purposes or in general. It also shows the lacking features of existing telepresence robots, i.e., modification of design and lack of human interaction, (e.g., chaotic behavior of telepresence robots in case of delays or connectivity issues). Second, it shows the object avoidance capability and addition of peripheral attachments for more human-like behavior in a remote environment. A focus on development will help researchers.

4.4. Self-Localization

This section describes a simple but impressive test. Using the magnetometer [56], the robot was driven in manual mode twice in a circle across the corridor of the EE building of the University of King Abdulaziz.

One tour was driven clockwise, and one counter-clockwise. The position was recorded, and the resulting trajectories were finally superimposed on a Google Maps aerial photograph. The size of the trajectories was subsequently adjusted so that they fit reasonably into the building. However, the aspect ratio and orientation have been retained. The result can be seen in Figure 12.

The red trajectory, which runs clockwise, was recorded first. It can be seen that the calibration of the magnetometer was very good. The start and end points of the trajectory are the same. In the image, however, these points are slightly apart. Each control cycle adds a correction value to the old position, so the position is an incremental value. This, of course, leads to error accumulation so that the estimated position deviates more and more from the actual position as the distance increases. On the first three straight lines of the red track, one can see that the tracks run fairly parallel to the outline of the building. This angle is no longer so accurate in the fourth straight line, so the error has probably increased the most here. On the other hand, one looks at the blue track, which was travelled counter-clockwise, the second straight section is parallel to the outline of the building. However, the other straight sections then deviate.

The strong angle errors in the trajectories can have many causes. On the one hand, the magnetometer calibration can be insufficient since it may have been held at an angle during calibration, rotated too quickly, or had interference fields. On the other hand, many sources of interference in the building generate magnetic fields or deform the earth’s magnetic field. Power lines, heating systems and stair railings are examples of this. Drifting of the magnetometer cannot be ruled out either. Online calibration would help here.

4.5. Complex Path

The last test shows how well the robot can travel a more complex path. This test was also carried out in the courtyard of the university campus. The robot had to drive straight ahead for 10 m and then return to its original point, but in doing so, it had to approximately assume the original orientation. The path definition is given in

Table 3. Lane definition.

Point	Position in X-Direction	Position in Y-Direction	Orientation
Start	0 m	0 m	36°
1	−4.539 m	8.91 m	27°
2	0 m	0 m	27°

.

Figure 13 now shows the target path and the actual path. The actual path consists of the coordinates measured by the robot. In the ideal case, it should therefore correspond to the target path. However, the actual path does not describe the path travelled, as this cannot be determined without special measuring devices. In addition, the marked target points are marked.

It can be seen that the target path was maintained quite well. There was only a small deviation in the orbits. This is mainly because, in point 1, the second path section was calculated from the current robot position. However, this did not correspond one hundred percent to the desired position. This resulted in a deviation from the previously calculated path. However, the targets were reached very well.

It must be noted that the robot did not return exactly to the starting point during this journey. It was about 2 m away from it. However, this is due to the inaccuracy of the self-localization. The orientation, on the other hand, was correct. Auto-MERLIN is a highly nonlinear system having a gearbox for power transmission, and it is not easy to obtain its accurate mathematical model. Therefore, a system identification approach was used to find the approximate model of the system. The root locus method was used to design a speed controller by introducing appropriate poles and zeros shown in Figure 6. The results validate the identified model of the system. The experimental data are given in the form of

Table 4. Experimental data for different trials.

Examples	Trial 1	Trial 2	Trial 3	Mean
	Distance (m)/Time (s)	Distance (m)/Time (s)	Distance (m)/Time (s)	Distance (m)/Time (s)
1st trip	8.67 m/92 s	9.79 m/98 s	9.13 m/95 s	9.2 m/95 s
2nd trip	9.89 m/90 s	9.13 m/87 s	8.13 m/88 s	9.0 m/88 s
3rd trip	9.13 m/98 s	9.05 m/89 s	9.05 m/75 s	9.0 m/87 s
4th trip	8.44 m/87 s	9.84 m/72 s	9.94 m/61 s	9.3 m/73 s

.

5. Conclusions

A control board and a voltage regulator for the steering servo motor are also required to maneuver the robot successfully. Fundamentally different models were successfully developed, built and tested. A new motor mount had to be created for the drive, to which two motors could be attached. It was necessary because the existing motor alone could not generate enough torque to move to and maintain the robot’s stable operating points. In addition, the brackets for the ten distance sensors had to be designed.

In the proposed research work, we designed speed and position control. The speed control loop was designed using the PID controller. An algorithm was developed for the state machine to avoid obstacles. It was a complex task that needed precise analysis and design. In the case of the robot, the high-level controller was a mini-computer running the application program. To this end, controlled test drives were undertaken, and the results were evaluated. Finally, the ideally adjusted robot was checked for its desired behavior.

The robot was tested over the step responses and the self-localization to test the maneuverability and control. It was seen from the results that the robot followed the given path with an ignorable number of hits. The robot’s calculated driven trajectory was measured and provided very precise results. It can be seen that the target path was maintained quite well.

As the summary suggests, software drivers should be written for the hardware. The timing of these drivers probably needs to be adjusted. So far, no driver has been developed for the SD card. This development would likely also fill a separate research task. In addition, the soldering pads on the control board used are attached the wrong way around so that the SD card slot cannot be attached. There is also no driver for the real-time clock. Another problem, which became apparent in the course of the research, is the correct self-localization of the robot. So far, it estimates its position by gradually adding up the distance travelled in the direction of orientation. First, the arc length travelled is used as the tangent length of the motion vector. It is also tolerable for small changes in direction. However, the systematic error accumulates over time when cornering. A correct solution to this problem would be quite complex and likely bring little improvement.