Remote tests in Telerobotics

Ciao :) The sixth week of GSoC 2015 got over. According to the Telerobotics project timeline, this week was supposed to be the Buffer Week to account for any unforeseen work that may pop up. We at the Italian Mars Society were trying to get ROS communication possible over a large network. After effective discussion via mail and prioritizing on Trello, the first Husky test was scheduled on July 1, second test on July 7 and the third test on July 8. It was an international effort spanning timezones in UTC-5:00, UTC+2:00, and UTC+5:30 regions. So zeroing in on a common time was an interesting sub-challenge in itself.

By a large network, I mean this -

On visceral observation, the problem statement looks quite tractable and practical. But like all problems in Computer Networks, this one looked easy in theory, but frustrated the budding Computer Scientist in me as the solutions proposed didn’t work out.

Husky Test 1

Matt (from the Space Research Systems Group, Carleton University), Franco, and I were trying to get the Husky UGV in Canada to respond to the commands sent from the three parts of world involved (Canada, India, Italy). The few problems we came across -

1. ROS version issues caused a minor problem. The Husky robot was running an older version of ROS (Hydro) while Franco and I were using the newer version (Indigo). This caused problems in reading certain Husky messages. Solution - Upgrade ROS version on the Husky robot OR downgrade our version to ROS Hydro and Ubuntu 12.04.

2. Network Issues - Unable to communicate with all three computers in all cases. There was no bidirectional communication between the ROS computers and ports were blocked.

3. Success - GPS Messages and status messages were received from the Husky robot laptop set as the ROS Master. But the Husky laptop was unable to receive Teleoperation messages from Franco’s computer and my computer (even though it detected that we were publishing messages). Again a Network problem.

Solution - Virtual Private Networks, well almost…

At first, I had to ensure that the TP-Link WiFi Router at home was not creating problems. To ensure this, I added my laptop interface in the Demilitarized Zone (DMZ), and enabled Port Forwarding for all the ports of interest.

Success with Blender Game Engine Streaming

Now, this solved quite a few problems - my public IP could now behave like one. To prove this, Franco and I held a Web-Stream session in which his laptop in Italy behaved as the Blender Game Engine Client while I provided a live video feed from the Minoru Camera while using a FFMpeg Server. His words - “You are live. I can see the stream.” provided the much-needed boost I required to tackle the pending Computer Networks problems I had to solve in the following couple of days.

Coming to the VPN problem, I first read about the various VPN Server solutions available, like -

• OpenVPN
• PPTP (Point-to-Point Tunneling Protocol)
• IPSec
• SSH Tunneling

The second Husky test was done with a PPTP VPN setup which wasn’t quite succesful. The reason being - ROS requires bidirectional communication between the peers, and I couldn’t become a peer while I was the VPN server. It caused a slew of other pesky problems like REQ TIMEOUTS, Disconnected ROS Nodes, disabling Internet on the VPN server, etc. But as a start, it was assuring that the problem could be solved. I realized that the learning curve for working with computers at the scale of the Internet is no child’s play. But there was another takeaway with the second Husky test. Andrea (from the Husky team) could work with my remote node as the ROS master and still get the Husky up and running. This means that all the Husky traffic and node maintenance could be relegated through my PC and transferred to the Husky. Much assuring.

Armed with the Computer Networks concepts I learnt at my college, I set on to set up the slightly tougher OpenVPN server. This is a snapshot of the OpenVPN access server that I set up -

I was not only able to set up a world-wide VPN, but also able to set up communication among the peers. But the firewalls on the Husky computer network were strong for it and sent Andrea’s laptop in a continous Trying to Reconnect loop. There went our hopes with OpenVPN. I am still looking into this issue. The main issue was that the UDP channel of OpenVPN was accessible in the Husky network but not the TCP channels. This caused intermittent connection losses and the OpenVPN client couldn’t figure out what to do. There must be a solution to this and I’ll find it.

Throughout this experience, I learnt a lot of new things about practical Computer Networks. Once I’m able to crack the VPN problem, I could put it to use in diverse scenarios (remote robotics testing, as a road warrior, Internet of Things applications, creating a network of friends, etc. ). VPN brings everyone on the same page (or logical subnet). I also did quite a bit of work with the Stereo Video Streaming which would be the theme of my next post. Stay tuned.

Ciao!