Development

A look at Robot OS

By Rebecca Sobol
August 25, 2009

Robot OS (or ROS) is described as: "an open-source, meta-operating system for your robot. It provides the services you would expect from an operating system, including hardware abstraction, low-level device control, implementation of commonly-used functionality, message-passing between processes, and package management." It also provides tools and libraries for software development, along with some applications that should be common to all robots.

There has not been much collaboration in the robot world, according to this New Scientist article:

Each robot is individually manufactured to meet a specific need and more than likely built in isolation. This sorry state of affairs is set to change. Roboticists have begun to think about what robots have in common and what aspects of their construction can be standardised, hopefully resulting in a basic operating system everyone can use. This would let roboticists focus their attention on taking the technology forward.

ROS got its start as an open source project developed by Willow Garage and Stanford University. Now Willow Garage is focusing on ROS and has started the ROS wiki to further collaborative efforts among other robot developers. ROS is all about reusing code as much as possible among robots. While ROS is implemented in Python and C++, there are also experimental libraries written in Lisp, Octave and Java. ROS is a developer framework but people using other developer frameworks can use ROS libraries and package repositories. In fact, ROS has been integrated with other robot software frameworks such as Player and Orca.

The Robot OS Concepts document explains how the project is organized. "ROS has three levels of concepts: the Filesystem level, the Computation Graph level, and the Community level." The Filesystem level contains the resources that are stored on disk. "The Computation Graph is the peer-to-peer network of ROS processes that are processing data together. The basic Computation Graph concepts of ROS are Nodes, Master, Parameter Server, Messages, Services, Topics, and Bags, all of which provide data to the Graph in different ways." The ROS Community level includes the online Wiki, the code repository and other networked resources.

ROS code can be installed on a variety of Linux distributions including Debian, Ubuntu, Fedora and Arch. There is also an experimental Mac OS X port. After installing the ROS packages the developer can use the rosconfig tool to install a configuration of ROS on their machine. The ROS configuration can also be shared on multiple machines.

The rosconfig documentation explains the utility:

rosconfig is a command-line tool for installing, configuring, and building a ROS installation. The motivation for rosconfig is the kernel's "menuconfig" or "xconfig" tools, which set up a build environment for you. The idea is that you can use the rosconfig tool, combined with a YAML description of the system you want, and poof it sets it up for you -- which may entail SVN checkouts, network-filesystem symlinks, etc.

Robot OS includes an extensive package list that includes documented development tools, libraries, drivers and applications. In some ways ROS may be thought of as both a software development kit and an "app store". The ROS wiki also includes developer documentation and tutorials. For additional information you can also join the ROS users mailing list or browse the archives. Bugs in the core software or feature requests can be filed on the ROS bug tracker.

If the robotics community can come together around ROS, it will allow developers to improve and perfect the common robotics functions instead of simply reinventing them. New and interesting robotics innovations should come about as developers build higher level software on top of the underlying platform.

Comments (1 posted)

On properly packaging perl

By Jonathan Corbet
August 21, 2009

The perl5-porters recently saw a rather acrimonious discussion on how the Red Hat and Fedora distributions choose to package the Perl language and associated modules. Things have calmed down (the parties have essentially agreed to disagree), but an interesting issue remains: what can development projects do if they're unhappy with how distributors are treating their code?

When Tom Christiansen gets irritated with somebody, one can generally be assured that they will know about it. In this case, Tom let the world know that he was not happy with the way Red Hat packages and distributes Perl. The complaint is that, if one installs "perl," one does not get the entire Perl 5.10 distribution. Tom says:

Of these, the most egregious omission is CPAN.pm itself, as its absence precludes the easy fix of using CPAN to grab what Redhat forgot. Other pieces notably missing include Text::Harness and h2xs -- although h2ph *is* included! Go figger.

As it happens, it is possible to get the entire 5.10 distribution; one simply needs to install "perl-core" instead of plain "perl." Tom asserts that this arrangement is confusing; "perl-core" should not be a superset of "perl"; the package called simply "perl" (which is what most users will install) should be the thing that the Perl developers shipped. He says that Red Hat's arrangement causes confusion, with users not knowing if they actually have "Perl" or not.

Beyond that, it goes against the developers' intent, which included providing users with all the basic modules they needed from the outset. Many users, it seems, will not (or cannot) add extension modules to their systems; the Perl developers tried to ensure that these users would have a minimally-functioning system available to them. But, alas:

But why did we bother? For all that effort is now undermined, even unravelled, if now vendors choose to strip down the real Perl distribution by paring away pieces that we've decided to ship. I don't envy them their positioning themselves as forkers, doomed to winnow and weed and forever maintain, but that's their own problem. Worse is when they present this stripped minidistro as the real thing. It's a misleading and confusing state of affairs which should be discouraged.

Tom "spot" Callaway explained Red Hat's packaging decisions:

At the time of the split, we had a LOT of packages which depended on simply "perl". We also had a lot of people who wanted individual perl modules updated that live within the "perl tarball", which is a complicated task to undertake. By splitting the perl modules out into separate subpackages we were at least able to allow people to build newer RPMs. In addition, the split had the added benefit that people who did not need nor want all of the components built with perl could get a system without them. This lowered the default Fedora installation footprint.

Tom says that the package naming could be changed, but that would have a number of unfortunate effects on users. That said, there are some possibilities for improving the situation, but the best course is not entirely clear. Tom Christiansen was not completely happy with the explanation, but he also seemed to understand the pressures which led to Red Hat's way of doing things.

In the near term, it looks like things will ~~not change a whole lot~~ be changing; see this comment for details. But we're likely to see this kind of debate come back in the future. Distributors serve as a sort of middleman, tweaking and refining upstream packages in ways which they think improve things - either for their users or for themselves. Distributor changes can include splitting up the package (as with Perl), removing user-unfriendly messages (as has happened with cdrtools), making the software more consistent with the rest of the distribution, fixing security problems, removing software seen as legally problematic, and so on. It's part of what distributors do, and users generally appreciate the effort.

Upstream developers are harder to convince; they have released the software in the form that they think is best, so it can be discouraging to see others messing with it. Most developers suffer in stoic silence, taking comfort in the fact that their software is finding a wider audience. But others have taken various types of action in an attempt to influence how distributors treat their code.

Consider some examples. The kernel developers changed their release process dramatically with the (successful) goal of reducing the number of patches applied by distributors. Some developers do their own packaging. Jeff Waugh has suggested that much of the packaging role of distributions could be "disintermediated" entirely, with users routinely getting their software directly from its developers. Jörg Schilling inserted (widely ignored) statements into his code stating the alteration of some parts of the program would be a copyright violation. Firefox makes aggressive use of its trademarks to control the changes made by distributors. Daniel Bernstein took things to a (non-free) extreme, only allowing qmail to be distributed if it had not been modified at all; this restriction inhibited qmail development for years until the code was finally released into the public domain.

In the end, releasing code under a free license means giving up control over what is done with it. So free software developers will always be at the mercy of distributors, who will always have the right to make the changes they think are necessary. The occasional grumble notwithstanding, the system works pretty well; all of the parties involved share an interest in having the software work as well as possible for their users.

Comments (79 posted)

System Applications

Audio Projects

Rivendell 1.5.2 released

Version 1.5.2 of the Rivendell radio station automation system has been announced. "This is a maintenance release of Rivendell. The following issues have been corrected: Fixed problems with build the Rivendell Pluggable Authentication Module (PAM) plug-in. Fixed problems with hard-start events in RDAirPlay. Added checks in rddbcheck(8) to verify cart/cut/audio consistency. Fixed a regression that caused audio exports to fail when the path contained one or more spaces."

Development

System Applications

Audio Projects

Database Software

Embedded Systems

Web Site Development

Desktop Applications

Audio Applications

Data Visualization

Desktop Environments

Desktop Publishing

Financial Applications

Graphics

Interoperability

Music Applications

Miscellaneous

Languages and Tools

Assembly Language

C

Caml

Perl

Python

Tcl/Tk

Debuggers

IDEs

Version Control