An Overview of Remote Tele Operation Robots

Remote tele-operation in robotics enables human operators, known as remote operators, to control a remotely controlled robotic device from a geographically different location, often over long distances, while getting feedback from different sensors that are on-board the robot. Unlike autonomous robots, which operate independently, tele-operated robots require humans for intervention in movement and task execution. This technology leverages real-time data transmission, high-speed connectivity, and advanced control interfaces to provide seamless interaction between the operator and the robot. The benefits of remote tele-operation robots include increased efficiency, improved safety by keeping humans out of dangerous environments, and significant cost savings compared to traditional methods. There is a growing demand for remote tele-operation robots across various industries as organizations seek scalable solutions to meet operational needs.

Remote tele-operation can be used across multiple domains, some examples are:

1. Healthcare – Telesurgery or remote surgery is an emerging tool that allows expert surgeons to operate on patients from a different location using robotic arms.
2. Industrial Inspection/Maintenance – Drones or ground robots can be used inspecting machinery in hazardous environments such as nuclear plants, deep-sea oil rigs, etc. This can also be used for inventory management and replenishment in warehouses. Tele-operation is especially valuable for dealing with hazardous or unpredictable situations remotely, allowing operators to manage risks from a safe distance.
3. Hospitality/Offices – Robots equipped with tablets can act as virtual avatars of the person driving the robot. This resembles the physical presence of the person and can be used in office settings for meetings, by teachers in schools or at homes for elderly care.
4. Defense and Security – Surveillance operations to identify threats are also a common application used by the military and law enforcement agencies.
5. Disaster Management – Remotely tele-operated robots can be used for delivering essentials during disasters; they can also help with search and rescue operations.

Users interact with the tele-operation system through intuitive interfaces, benefiting from the ability to control and monitor robotic devices remotely, which enhances their effectiveness and safety. In this article, we explore architecture that combines ROS 2 (Humble or earlier) enabled robots with Zenoh to perform remote-teleoperation and visualization.

Zenoh

Zenoh (Zero Overhead Network Protocol) is a pub-sub-query (publish-subscribe-query) protocol designed for low-latency and high-performance across various computing environments, from cloud to embedded systems. Zenoh provides a set of abstractions that unify data in motion, data at rest, and computations on an internet scale. It also supports peer-to-peer, routed, and brokered communication, with efficient data transmission and handling.

The default communication protocol used by ROS 2 is called DDS. However, when building applications centered around remote tele-operation and visualization, DDS has certain disadvantages:

1. DDS was primarily designed to work on wired networks with low message loss. Wireless performance may degrade, and reliability issues must be managed by developers via DDS QoS settings. Any application that leverages robots would primarily work in a wireless network setting, so it is important to have seamless wireless support.
2. DDS is not intended for resource constraints for embedded devices. There are lightweight DDS implementations like Micro XRCE-DDS by eProsima, however, this becomes another module that must be integrated in the system.
3. DDS does not natively have internet support.

When comparing Zenoh and DDS, Zenoh streamlines the development of remote tele-operation applications by providing a more efficient and robust communication layer, which accelerates the workflow for developers.

On the other hand, Zenoh was designed to take care of these disadvantages such that communication could be established across multiple different systems from private/Cloud to resource constrained embedded devices on the internet scale without having to integrate other modules or manage settings at each level of the solution. Zenoh efficiently routes data between systems, and the process of managing and transmitting data across networks is optimized to ensure reliable and organized data flow.

Remote Tele-operation and Visualization Solution and Architecture

The solution consists of remotely accessing a user interface hosted on the cloud; Figure 1 shows the user interface developed for this demo. The image on the left-hand side is superimposed to give a top view of the robot movement and is not part of the main UI. The image in the center is what the user would see, this consists of three different elements:

1. Arrow keys to allow robot movement
2. Live feed of the camera sensor mounted on the robot
3. LiDAR data plotted in blue in an ego-centric manner to allow the user avoid obstacles

Developers can use code to customize or build additional visualization features, enabling integration of new layouts or embedding visualization tools directly within the application.

Figure 1: User-facing web app for performing remote tele-operation.

1. Robot: Listed inside the block are different ROS 2 nodes and Zenoh components that would be running on the robot. These include:
   • Camera Node: This is a ROS 2 wrapper node that acquires and collects frames from a camera sensor mounted on the robot and publishes the frames onto the /camera/color/image_raw topic.
   • LiDAR Node: This is a ROS 2 wrapper node that acquires and collects scan data from a LiDAR sensor mounted on the robot and publishes the data on the scan topic.
   • Custom Node: The custom node is responsible for pushing the camera and lidar data to Zenoh-router (explained later). It consumes the camera data and pushes it to Zenoh-router without modification. The LiDAR topic data is processed to produce an ego-centric view of the scans so that the user has an intuitive view of where all the surrounding obstacles are. All this data is pushed to the Zenoh-router via individual key expressions.
   • Zenoh-bridge-dds: The Zenoh-bridge-dds is a standalone executable that acts as a bridge between DDS systems and Zenoh systems. It discovers all DDS writers and readers in a DDS system and routes each DDS publication on a topic T as a Zenoh publication on key expression T. In the other way, assuming a DDS Reader on topic T is discovered, it routes each Zenoh publication on key expression T as a DDS publication on topic T. It should be noted that the Zenoh-bridge-dds provides flexibility to filter out unwanted topics to reduce network traffic. In our pipeline, it connects the robot’s data like tele-operation commands given to the robot to control it. Additionally, Zenoh-bridge-dds can log system activities and data for monitoring and analysis.
2. AWS: An EC2 instance is configured in AWS to enable remote visualization of the robot data and send control commands to it. The following components were involved:
   • Apache Web-server: Apache is an open-source web-server software that is used to serve the web content to the user.
   • Zenoh-router: The Zenoh routers route the data between clients and local subnetworks of peers. They can be deployed using any topology. In other words, Zenoh routers facilitate the movement of data between different parts of a Zenoh network, allowing clients and peers to communicate even if they are not directly connected. The Zenoh-router also provides the ability to record data for later analysis or playback.
     The Zenoh router comes with various plugins like:
     • REST Plugin: The function of this plugin is to expose the key-value store via RESTful HTTP APIs. In the pipeline, it is used for publishing data from the web browser to the robot, specifically controlling data.
     • Web-server Plugin: The function of this plugin is to provide a HTTP server that maps URLs to Zenoh keys. In the pipeline, the camera feed and LiDAR data are sent to the router as Zenoh keys which are then subsequently mapped to a URL that the web app can display for the user.
     • Storage-manager Plugin: The storage-manager plugin provides persistent storage capabilities for Zenoh, enabling data to be stored and queried. For simplicity, this plugin is not used in the given pipeline.
3. User Interface and Control: This component is the user interface that was created for the purpose of demonstrating the pipeline. A sample image was already shown in Figure 1.

Figure 2: Remote tele-operation architecture diagram using Zenoh.

Conclusion

Zenoh is a powerful protocol that allows seamless integration between Cloud and embedded devices with low latency and high performance. Due to this Zenoh lends itself very well for a use-case like remote tele-operation and visualization. This becomes even more relevant when working with ROS 2 enabled robots. In view of this, we have presented an architecture that can be used to enable remote tele-operation of robots that use ROS 2.