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!

Hi all! I made it through the first half of the GSoC 2015 program. This is the evaluation week of the Google Summer of Code 2015 program with the Python Software Foundation and the Italian Mars Society ERAS Project. Mentors and students evaluate the journey so far in the program by answering some questions about their students and mentors respectively. On comparing with the timeline, I reckoned that I am on track with the project so far.

The entire Telerobotics with Virtual Reality project can be visualized in the following diagram -

Achievements-

Husky-ROS-Tango Interface

• ROS-Tango interfaces to connect the Telerobotics module with the rest of ERAS.

• ROS Interfaces for Navigation and Control of Husky

• Logging Diagnostics of the robot to the Tango Bus

• Driving the Husky around using human commands

Video Streaming

• Single Camera Video streaming to Blender Game Engine

This is how it works. ffmpeg is used as the streaming server to which Blender Game Engine subscribes.

The ffserver.conf file is configured as follows which describes the characterstics of the stream:

Port 8190
BindAddress 0.0.0.0
MaxClients 10
MaxBandwidth 50000
NoDaemon

<Feed webcam.ffm>
file /tmp/webcam.ffm
FileMaxSize 2000M
</Feed>

<Stream webcam.mjpeg>
Feed webcam.ffm
Format mjpeg
VideoSize 640x480
VideoFrameRate 30
VideoBitRate 24300
VideoQMin 1
VideoQMax 5
</Stream>

Then the Blender Game Engine and its associated Python library bge kicks in to display the stream on the Video Texture:

# Get an instance of the video texture
bge.logic.video = bge.texture.Texture(obj, ID)

# a ffmpeg server is streaming the feed on the IP:PORT/FILE
# specified in FFMPEG_PARAM,
# BGE reads the stream from the mjpeg file.

bge.logic.video.source = bge.texture.VideoFFmpeg(FFMPEG_PARAM)
bge.logic.video.source.play()
bge.logic.video.refresh(True)

The entire source code for single camera streaming can be found in this repository.

• Setting up the Minoru Camera for stereo vision

It turns out this camera can stream at 30 frames per second for both cameras. The last week has been particularly challenging to figure out the optimal settings for the Minoru Webcam to work. It depends on the Video Buffer Memory allocated by the Linux Kernel for libuvc and v4l2 compatible webcams. Different kernel versions result in different performances. It is inefficient to stream the left and right cameras at a frame rate greater than 15 fps with the kernel version that I am using.

• Setting up the Oculus Rift DK1 for the Virtual Reality work in the upcoming second term

Crash-testing and Roadblocks

This project was not without its share of obstacles. A few memorable roadblocks come to mind-

1. Remote Husky testing - Matt (from Canada), Franco (from Italy), and I (from India) tested whether we could remotely control Husky. The main issue we faced was Network Connectivity. We were all on different networks geographically, which the ROS in our machines could not resolve. Thus some messages (like GPS) were accessible whereas the others (like Husky Status messages) were not. The solution we sought is to create a Virtual Private Network for our computers for future testing.

2. Minoru Camera Performance differences - Since the Minoru’s performance varies with the Kernel version, I had to bump down the frames per second to 15 fps for both cameras and stream them in the Blender Game Engine. This temporary hack should be resolved as ERAS moves to newer Linux versions.

3. Tango related - Tango-controls is a sophisticated piece of SCADA library with a server database for maintaining device server lists. It was painful to use the provided GUI - Jive to configure the device servers. To make the process in line with other development activities, I wrote a little CLI-based Device server registration and de-registration interactive script. A blog post which explains this in detail.

4. Common testing platform - I needed to use ROS Indigo, which is supported only on Ubuntu 14.04. ERAS is currently using Ubuntu 14.10. In order to enable Italian Mars Society and the members to execute my scripts, they needed my version of Ubuntu. Solution - Virtual Linux Containers. We are using a Docker Image which my mentors can use on their machine regarding of their native OS. This post explains this point.

Expectations from the second term

This is a huge project in that I have to deal with many different technologies like -

1. Robot Operating System
2. FFmpeg
3. Blender Game Engine
4. Oculus VR SDK
5. Tango-Controls

So far, the journey has been exciting and there has been a lot of learning and development. The second term will be intense, challenging, and above all, fun.

To-do list -

1. Get Minoru webcam to work with ffmpeg streaming

2. Use Oculus for an Augmented Reality application Source

3. Integrate Bodytracking with Telerobotics

4. Automation in Husky movement and using a UR5 manipulator
5. Set up a PPTP or OpenVPN for ERAS

Time really flies by fast when I am learning new things. GSoC so far has taught me how to not be a bad software engineer, but also how to be a good open source community contributor. That is what the spirit of Google Summer of Code is about and I have imbibed a lot. Besides, working with the Italian Mars Society has also motivated me to learn the Italian language. So Python is not the only language that I’m practicing over this summer ;)

Here’s to the second term of Google Summer of Code 2015!

Ciao :)