The Robot Operating System (ROS) is an open source collection of packages built around an architecture of publishing messages that is geared towards robotics and embedded systems. At the moment, it is built to run on Ubuntu, with some limited experimental support for other operating systems: http://www.ros.org/wiki/ROS/Installation. I chose to stick with Ubuntu to avoid any problems down the road that choosing an experimental OS might bring.
A great installation guide for ROS can be found here: http://www.ros.org/wiki/electric/Installation/Ubuntu. Personally, I am running the Natty (11.04) version of Ubuntu, but running on other versions should be all right.
ROS works with nodes (essentially processes within the ROS framework) and nodes communicate to one another through topics (or data streams). To facilitate the distribution of topics amongst nodes on different machines (via Internet connection), a Master machine is designated by the user. The Master receives all data from all nodes and intelligently distributes data between the nodes that require it.
There are three ways nodes interface/communicate: publisher–subscriber, services and actions. The bread and butter of ROS is its producer-consumer framework, or known correspondingly in ROS as publisher–subscriber. A node will publish a topic with a given message (or msg), and another node will subscribe to that topic, receiving data in the form as defined by a msg. A msg is a text file that describes a data type, and resembles a C structure. For example, the Point.msg from the package geometry_msgs is
Services resemble a client-server architecture. A node will advertise/provide a service wherein another node will give some input and the node will return some output. This is defined by a service type, which consists of two parts: input messages and output messages. Here is an arbitrary example to better illustrate:
Here a node (client) will send a float32 and string as input for a service topic and expect to receive an int16 and bool back.
Actions are similar to services, but are built towards functionality that requires a long response time (i.e. more than second). Examples of this are usually performing a physical task such as docking a robot, opening a gripper or moving an arm.
Custom messages and services can be created for your own purposes and are built upon basic message types, just like in C. For more information, I recommend reading http://www.ros.org/wiki/ROS/Tutorials/CreatingMsgAndSrv.
A neat function of ROS is that because of its architecture it pretty simple to see how all components in a system are connected. The command line executable rxgraph will build a flow chart of all components currently running. For example, when running rxgraph on my CSC578C project:
ROS is a great tool for building straightforward and modular components for robotics. This post serves as more of an overview of the fundamentals of what ROS is and why I like it. I highly recommend reading the well written tutorials for ROS to get started learning it.
|Takes care of a lot of infrastructure||Can be a bit bulky when compared to pure embedded implementation (“Using a bulldozer to build a sandcastle”)|
|Large community to call on for support||The effectiveness/completeness of some stacks/packages can be a bit misleading|
|Built around modular design||Can take up a lot of bandwidth — leads to slow performance (at least on my University’s wireless network)|
|Supports Arduino through rosserial||For distributed projects, requires Internet as well as devices capable of running ROS (i.e. netbook)|
To demonstrate a simple and interesting use for ROS, take a look at the joystick package I created for ROS (when I get around to writing a post about it). The package is built around the pygame package, specifically its joystick library.