Programming a Mars rover - Week 1!

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!