## 3 Methodology  
Remotely controlling a physical robot over a network connection introduces a number of factors contributing to the overall performance of its control feedback loop. One such factor that significantly contributes to the overall user experience of this telerobotics system is the network latency. High latency results in a separation in time between the observation and control response and is thus detrimental to the reliability and accuracy of telerobotic operations. The components of the static segment include an in-lab Baxter robot [29] by Rethink Robotics, shown in Figure 1, and a desktop server that is the control host for the robot in our setup. The robot was connected via an Ethernet link through a managed switch to the host computer, which provided a server interface for external devices to connect to it, as well as a Robot Operation System (ROS) Python script [30] for operating the Baxter robot. Our control method utilizes Baxter's internal IK solver. Thus, every \"move\" transaction triggered by the teleoperator resulted in an Inverse Kinematics (IK) Solver Request/Response cycle, followed by an ROS Move Request/Response cycle between the host and robot. Our teleoperations script was optimized to bypass service availability checks in order to facilitate faster host operations. Since the local network configuration between the host and robot was static, the latency of these service interactions was highly stable throughout our tests. The teleoperations client was the primary component within the dynamic segment of our test infrastructure. This client connected to the host server. Utilizing a game controller and the associated Python library [31], we captured the control inputs from the controller and used these to transmit \"Move\" requests from the client to the host server. Each controller input was mapped to certain move commands comprising speed and direction for the robot to move its arm and end effector. Since the Baxter robot's ROS interface supports the utilization of Cartesian coordinates for arm placement, we utilized Cartesian controls for movement and button presses for gripper open/close controls. When the host receives a \"Move Request\" from the client, it queries the Baxter's internal IK solver for the corresponding 7-joint solution to the movement request, and, if a valid response is received, sends the joint solution request to the robot to trigger the actual movement. To identify latency components that had the largest effect on the control loop, the setup utilized in our research comprised both a dynamic and a static segment. The controlling  
Figure 1: Photo of [PERSON] robot. client was connected to the host via a variable network setup. It is this variability that allowed us to evaluate different network scenarios and control distances in our tests. To then analyze the impact of the client's network connectivity on the end-to-end latency of our telerobotic application, we conducted extensive tests for each network scenario we were targeting. These specific scenarios include the following:  
* A simple wired network connection between the client and host through our internal University network, resulting in minimal network distance between the client and host;
* A connection involving the University's Wi-Fi network as well as a VPN connection to expand our network radius to the network edge;
* A mobile hotspot 4G Cellular connection that required the client to connect via Wi-Fi to the mobile hotspot, which, in turn, connected through the cellular service network to the University's network edge and its VPN server, further widening the distance between the client and host;
* A connection through a duplicate of our client setup established at VTT in Finland through a transatlantic connection back to our University's network edge and its VPN service to maximize the network distance between the client and host. For the visual feedback control loop within this system, a webcam was connected to the host server.