Hi! This is the sixth post in my GSoC ‘15 blog series.

So the much awaited coding period began on 25th May, 2015. After a refreshing Community Bonding experience, setting up my workspace, and creating a Software Architecture Document - I was in a position to start coding.

Aims and Milestones

This week, according to the timeline, my aims were -

• Creating the initial set of ROS nodes for the Husky model for linear and angular motion
• Zeroing in on the basic interface for mapping the Kinect bodytracking information and Motivity interface being concurrently developed by Vito to teleoperation commands that Husky can understand
• Figuring out a way to integrate ROS and Tango into ERAS

So far it has been a good week and I am on schedule. I am able to manipulate the motion of the simulated Husky via an external stimuli.

Architecture

Before I describe my programs, let me first describe the high-level architecture with help of a simple diagram -

As is evident from the diagram, there are two distributed systems involved - both fairly complicated. These are -

• Tango Controls
• ROS (Robot Operating System)

This was by far the biggest challenge of the project. Interfacing data from one distributed system to the other while maintaining low latency and ensuring high performance.

Another challenge was handling real-time streaming data. I banged my head against Python Streams. Message brokers like RabbitMQ and ZeroMQ. But as Albert Einstein said -

“If you can’t explain it to a six year old, you don’t understand it yourself.”

All this while, I was confused in transferring data over an additional inter-process communication structure between two distributed systems. Meh. Sounds complicated. It actually is. And that is why I chucked that idea out. After spending three full days on this, I realized a much simpler architecture -

Voila!

The good thing about this diagram is that it works at scale with as many ROS nodes one may like to add for the rover (Husky) without compromising on the data coming from the Tango bus. The missing piece of the two distributed systems puzzle is solved by a Tango ROS Node. Now I have a plan to work on in the second week of coding.

These requirements had to be reflected in the Software Architecture Document as well. To this end, I set up the excellent OmniMarkupPreviewer for Sublime Text to preview the reStructuredText (.rst) documents that I created.

Tryst with ROS and Husky

I had never worked with an Unmanned Ground Vehicle before. I did use ROS for robotics experiments at my university lab but needed to quickly jog my memory about ROS programming with rospy. The excellent ROS wiki and the book ROS By Example -

It is a haven for robot hobbyists like me and I’ll continue to refer to it for time to come.

Alright, I started my week with ROS programming. My first job was to bring up the simulator and make sure that Husky model responds to commands -

Husky (and other ROS robots) describes movements in the form of Twist messages -

[(x, y, z), (a,b,c) ] where x,y,z is linear velocity along the x,y,z axes. And (a,b,c) is the angular velocity about the x,y,z axes.

So to move in a circle, we issue [ (5,0,0) , (0,0,2) ]. This would result in a linear speed of 5 in the x direction and angular speed of 2 about the z axis, resulting in a circular motion.

A simple way to explain the working is to use this command -

rostopic pub /husky_velocity_controller/cmd_vel geometry_msgs/Twist -r 100 '[0.5,0,0]' '[0,0,0]'

This publishes a Twist message to the Terminal telling the /husky_velocity_controller/cmd_vel ROS topic that the Twist denotes a linear motion of 0.5 m/s along the x direction.

This is Husky in action -

To do the same using rospy, the procedure is simple -

• Import the required libraries (to support rospy, logging, and Twist messages)

import roslib
import rospy
from geometry_msgs.msg import Twist

• Set up a ROS node - in this case move

rospy.init_node('move')

ROS nodes act as identifiers (source and destination of messages) in the ROS distributed system (modeled as a graph)

For instance, this is the ROS graph while the Husky is moving about -

This is why ROS scales so well. Any number of publisher and subscriber nodes can be added to extend different applications.

• Set up a publisher to the appropriate ROS topic with the ROS message type

p = rospy.Publisher('husky_velocity_controller/cmd_vel', Twist, queue_size = 100)

The queue_size argument specifies the message buffer length, and allows for asynchronous transfer of messages on the ROS meesage queue.

• Construct a Twist Message

twist = Twist()
twist.linear.x = 0.5;                   
twist.linear.y = 0; twist.linear.z = 0;     
twist.angular.x = 0; twist.angular.y = 0;  
twist.angular.z = 0;    

• Publish the message

p.publish(twist)

That was easy, isn’t it?

Changing the attributes can allow the Husky to move in a circle and nautilus shape -

In this way, I proceeded in creating ROS nodes to accept Twist messages from any application and made a small teleoperation program on the lines of the Arrow server in ERAS. With the help of Franco, I set up the Arrow Tango server and obtained the attributes for distance and orientation.

The next aim is to use the distance and orientation information on the Tango bus and map it to Husky commands so that it may move around appropriately on ground like this -

Random ROS Tidbit - While working with ROS, I came across this interesting command source

Why do I call it interesting?

It does not have a man-page, it does not have a –help or -h argument. It has one simple purpose -

Execute the content of the file passed as argument in the current shell

Note that it is not the same as ./ which creates a new shell to run the command. Shells are nifty processes which allow other program processes to run. I wrote a shell from scratch for a Network Programming course assignment. You may find it here.

Skype Meeting for Bodytracking

Franco, Yuval, Fabio, Ezio, Vito and I had an important meeting on 2nd May( a couple of hours before writing this post). The purpose of the meeting was Mapping Bodytracking with Telerobotics. The whole point of the project is to allow complete virtual and augmented reality immersion of the astronaut and the rover. This is what it means. The robot (a humanoid or a rover) should be able to mimic human action as much as possible. How? If the astronaut runs fast on the Motivity treadmill at a particular angle, the robot should move faster with that angle relative to the moving base position. This would make use of Vito’s Kinect-based bodytracking module for determining incremental distance and orientation.

Since Husky understands velocity in the Twist message, the distance/orientation information must be transformed into linear/angular velocity. I’ll be working on it this week.

Fabio brought up the important aspect of autonomy-control in the robotic system. He pressed upon the need of having three different stimuli to the robot -

• From the Bodytracking application (external)
• From the robot’s onboard sensors (internal)
• From an external source

This suggestion definitely adds robustness to the entire design, it will help the robot to avoid hitting a rock and override an astronaut’s command in case of danger. I will look into it this week and keep semi-autonomy in Telerobotics in mind.

Yuval talked about contacting the team in Canada which facilitated Husky during V-ERAS 14. The work that I do will be tested on a real Husky eventually.

Adding a UR10 robotic arm to the Husky to facilitate manipulation and imitation of the human hand was also proposed. I’ll look into that after the work on steering is complete.

In this way, the meeting was quite important and a bunch of crucial decisions regarding Telerobotics and Bodytracking were taken.

The Week ahead

The following week, we’ll have another meeting with all the students and possibly a joint code review session. I will be integrating ROS and Tango and adding support for different levels of Robot control through additional ROS nodes.

Summary

In hindsight, I was scared my GSoC coding experience would turn out be like this before the start of the Coding period -

Source - CLUE

:) In fact I faced nothing like that (but the headphone and the loneliness is true :D ) There were minor setbacks. I had to reinstall ROS as a result of purging my MySQL configuration for Tango. Obviously these were the usual frustrations which crop up with computer programming and Linux, but nothing humongous. But this is where the Zen of Python kicks in! Using top-notch resources like the logging module, rqt-graph, and the inbuilt ROS logger; programming was a breeze. Add to it the awesomeness of Italian Mars Society. I faced a doubt in bodytracking, and six people decided on a Skype call to resolve the issues being faced, and resolve it we did, with gusto.

The first week was super-hectic. Left with a computer and a programming problem; all-nighters were inevitable. It is proving to be a challenging and fun summer.

Watch out for my next post in the GSoC 2015 series!

Ciao!

The First Three Days

Hi! Last couple of days were quite hectic. I am still getting used to the 7-hours a day schedule of GSoC. But the good thing about GSoC is you can adjust the programming schedule according to your own convenience which is one more reason which takes it a notch above other summer coding programs. But I am devoting about 10 hours every day in these initial days to ensure I am well-positioned with respect to my timeline and also keep learning stuff on the go.

Rants aside, I recently completed the first draft of the Software Architecture Document for my project.

Software Architecture Document

Software Architecture Document (quite funnily abbreviated as SAD) is an important (read very) piece of information which entails and ensures what a software project is going to look like when it is built and shipped. I must thank the Italian Mars Society for giving me the much-needed push into the world of Open Source Software Engineering.

Architecture of any program, especially open-source programs, as described in the excellent book Architecture of Open Source Applications describes software in terms of different layers of abstraction components, depending on who wants to look and improve upon it. Open source applications are a product of efforts of multiple people working on different aspects of a project together. To facilitate effective and non-redundant collaboration with proper version control, a software architecture document comes in handy.

To put it in one line -

SAD ensures all developers, testers, and users are on the same page.

SAD for Telerobotics Application

Take my Telerobotics application for instance. It is made up of three distinct features or functional requirements -

• Mapping Human body-tracking information to rover motion instructions
• Allowing real-time streaming of the rover’s stereo camera-feed to the ERAS application
• Providing an Augmented reality interface obtained from the processing the rover sensor data

Although I am the only developer working on these aspects currently, I must ensure that the application is in a well-maintained state throughout the life of the project. I must also ensure that a developer with skills in Robotics gets relevant information to the Robotics subsystem of the application (ROS knowledge). I must separate the concerns of a Network Communications developer from the user (the astronaut) while working on Real-time streaming from the rover to the Head Mounted Virtual Reality device.

While the features describe the expected behaviour of the software system, they require a lot of background machinery which is essential for operation but not relevant for exposing to the end-user. These are non-functional requirements. To give an example, Robotics Operating System is used to manouver the Husky robot around. But the astronaut or the software system need not be concerned that robot communication, control, and command (C3 architecture) takes place using ROS or other robot platforms like YARP or Player/Stage.

Non-functional requirements in turn are quite important for satisfying the performance requirements of the software system. For instance, the Real-time streaming protocol (RTSP) that I’ll be working with soon directly impacts the performance requirement of Hard-Real Time streaming support.

The Software Architecture Document is generic in that it keeps in mind the evolving technology that may be used to cater to the application in focus. For instance, the Unmanned Ground Vehicle currently being considered is the Husky rover. It is my responsibilty to ensure that the logical layers are independent of the robot being used. The software should be extensible easily to a future ground vehicle that may use an altogether different control architecture than ROS.

Finally, SAD is practical. It describes the timeline of development of the features.

My experience with SADs

Working on the SAD has been an immensely edifying experience for me for several reasons -

1. My first foray into Software Engineering literature.
2. Learning reStructuredText as the documentation tool for SAD.
3. Appreciating how finely ingrained software-engineering principles are with Programming Language design. For instance, the sections of a SAD directly imbue the features of Object Oriented Programming (abstraction, encapsulation, separation of concern) and Functional Programming (Side effects, Higher-order functions).

Links to the document

If you are interested, the link to my software architecture document source is this.

The documentation on readthedocs can be found here.

Until my next post on my first week of coding.

Ciao!