img_20170330_185921

A telepresence robot – Enhancements

In this article, I’m going to describe architecture enhancements for the control system of the WebRTC-controlled telepresence robot I built a few months ago, presented in a previous article.

Since I did not manage to have a satisfying WebRTC support directly in a native Android app, I previously settled for a hack where the smartphone of the Telebot uses two different connections to the signaling channel: one to receive user control in the Android app, and one to handle the WebRTC session in the browser.

This was bad for two reasons:

  • The robot can enter an incoherent state if one connection is closed and not the other.
  • User control commands do not benefit from WebRTC, instead they travel through the server, adding latency and jitter.

The idea for the new architecture is to have the Android app run a small HTTP server in background that can accept motor control commands and send them to the Bluetooth device. We will send users commands on an RTCDataChannel and forward them to this small HTTP server with JavaScript in the browser.

General schematic of the enhanced architecture
General schematic of the enhanced architecture


Let’s put together a tiny single-threaded HTTP server for our Android app. For the sake of simplicity, requests and responses content will be formatted as JSON. I know the implementation is only partial, but it is totally sufficient and standard-compliant for our limited needs.

In particular, we need to properly handle Cross-Origin Resource Sharing (CORS) because since the server is local, we are going to hit it with cross-origin requests.

Now that our small HTTP server is ready, we have to handle the control requests by specializing the class.

The setControl() function writes the command over the Bluetooth serial connection.

We are now able to send requests containing control commands from the JavaScript code!

This assumes that resources on 127.0.0.1 are not considered mixed content, even if accessed over HTTP from an HTTPS page. The W3C specification is strangely not clear about that, but it seems to me this is the right behaviour, since you can’t get a TLS X.509 certificate for localhost. Chromium allows access, anyway.

The last step is to set up the RTCDataChannel. The user side opens it, and the robot side accepts it:

Finally, it works! It is way easier to move the robot thanks to the reduced latency. Of course, the complete source code is available on my repository on GitHub.

One thought on “A telepresence robot – Enhancements”

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">