Rosboard Client

The main objective of this library is to selectively stream ROS topics using websockets from a remote robot to a local machine, allowing to use visualization tools like rviz, rqt, mapviz, etc on live data transmitted over the internet. The library implements a client to use with a rosboard server running in the remote robot.

Dependencies

This package requires the following dependencies:

• twisted
• autobahn
• cv2
• simplejpeg
• numpy
• icmplib
• PyQt5

Existing alternatives

There are already some alternatives that allow to transmit ros data over the internet, however they have some drawbacks

• Connecting a local ROS2 system to a remote one using a VPN like Husarnet. This removes the possibility of selecting only some topics for transmission, and does not perform any compression of the data, which makes it unsuitable for robots running high data rate sensors like cameras and LIDAR and relying on a cellular connection to stream the data.

• Using rosbridge_suite. Though this does allow to stream topics selectively through websockets, its compression proved inefficient for large messages like images and occupancy grids, which lead to a very high bandwidth usage, lag “accumulation” and a severe drop in the rate of messages arriving to the desktop client.

Rosboard showed to overcome this drawbacks, keeping a comparatively lower bandwidth usage when streaming data intensive messages and having lower non-accumulating lag.

Brief functionality description

This library provides a desktop client that connects to a remote rosboard server and allows to create subscriptions to topics on that server. When a message is received binary data is decoded and passed to a user specified callback.

The library also provides a set of republishers meant to convert json data from rosboard back to ROS messages and republish them on the local machine. They account for the special subsampling and compression made by rosboard on Images, LaserScans, PointCloud2s and OccupancyGrids, and can convert virtually any other type of messages by relying on the rclpy_message_converter library, added as a submodule in this package.

The networking module is decoupled from the ROS dependent republishers, so it can be used as a standalone package providing custom callbacks for subscriptions that handle the json payloads. The socket client decompresses and decodes all the data before passing it to the callback.

An easy way of running this over the internet is using ngrok. After setting your authtoken you can tunnel the rosboard server, usually in the 8888 port using the tcp protocol:

ngrok tcp 8888

The url that ngrok provides can be used as host for creating the rosboard client.

How to use it

Note: Running the rosboard client requires the usage of our own rosboard fork running in the server side. This fork provides the required functionalities for the client to work as intended. Some of the functionalities that are available in our fork are:

• Streaming topics from the client to the server.
• Streaming of occupancy grids.
• Checking that QoS profiles are kept when streaming topics.

To use the client, please follow the next steps:

• Configure a workspace in which you will use the tool e.g. (~/rosboard_client_ws/).
• Clone the repo in your workspace source folder:

    $ cd ~/rosboard_client_ws/src/
    $ git clone git@github.com:kiwicampus/rosboard_client.git # if using SSH
    # or
    $ git clone https://github.com/kiwicampus/rosboard_client.git # if using HTTPS
    

• Navigate to the rosboard package and initialize submodules and install requirements:

    $ cd ~/rosboard_client_ws/src/rosboard_client/
    $ git submodule update --init --recursive
    $ pip install -r requirements.txt
    

• Build the package:

    $ cd ~/rosboard_client_ws/
    $ colcon build --symlink-install --packages-up-to rosboard_client
    

• Source the workspace:

    $ source ~/rosboard_client_ws/install/setup.bash
    

By this point you can either run the standalone or the GUI rosboard client nodes:

# To run the standalone node. Remember to configure `topics_to_subscribe.yaml`
$ ros2 run rosboard_client rosboard_client
# To run the GUI node.
$ ros2 run rosboard_client rosboard_client_gui

Note: this instructions do not take into account any additional interfaces packages that you require when running the client. Remember to download, build and source those interfaces packages. Not sourced interfaces might prevent topics from streaming.

Rosboard GUI

This package includes a graphical user interface (GUI) that can be used to connect the local computer (client) to the server. The GUI allows an user to define which topics will be streamed from the server to the client and viceversa. In addition to such capability, the interface presents information related to the rate in which the topic messages are received and the latency of them i.e. the time difference between the message header stamp and the current system time. Finally, some general metrics are presented regarding the CPU usage, average roundtrip time (RTT), and current download speed. This application is intended to ease the streaming process while being capable of dynamically selecting which topics are streamed.

Comparison with Rosbridge

We think of rosbridge as the main alternative to rosboard. In this context, we want to prove that rosboard presents an improved approach to streaming data from a remote device within the context of ROS. To do so, we propose a benchmark of metrics relevant to the streaming process. We must note that we will provide any third party with the capability of executing their own tests. We will benchmark two (2) metrics: latency and download speed.

• Latency: we define latency as the time difference between the timestamp of the received message and the current computer time. We must note that there might be difference in the server and client clock that might affect this measurement.
• Bandwidth Usage: is the measurement of received bytes per second while using rosboard. Keep in mind that this measurement is a system-wide metric. In this context, any additional process using the network interface might contaminate the test.

Two laptops were configured in a Local Area Network (LAN) using a network switch. The network switch was not connected to the internet in order to prevent contaminating the test. The used switch had a bandwidth limit of 100 Mibps. We did the benchmark with a data-intensive topics: a RGB camera streaming. The next table presents the used specifications for the streamed topic: