Open Source and NASA's Mars Rover

Nice weather, 50 million dollars, and no fishing boats: these are the
requirements for launching a craft to Mars. Before the launch -- and
after it -- people work intensively on not just the hardware, but also the
software.

The extreme environments encountered in space reflect the intense
atmosphere necessary for writing the mission-critical code. Obviously, testing
is a priority, as are clear specifications; these are desirable in any
programming situation. However, most of us don't perform while being monitored
by an independent observer, nor do we work with a 100-page software test plan
that translates to actual tests. The NASA team must even live on the slightly
longer Martian diurnal cycle to provide support during the mission. To further
complicate matters, the hardware is extremely limited and the software
development begins before the vehicle is even built. The team is now
experimenting with using Extreme Programming (XP) to meet these demanding
requirements.

Jeff Norris (Figure 1), Mark Powell, and Marsette Vona (both in Figure 2)
from NASA spoke at the O'Reilly
Open Source Conference on Thursday on the subject of the Mars Exploration
Rover mission and the role of open source software in the project.

Figure 1. NASA's Jeff Norris (Photo by Derrick Story for the O'Reilly
Network.)

The rover consists of several components where mass and power consumption
are key considerations. The laptop used for the presentation was more powerful
than the rover, which uses a 25Mhz processor and has only 128MB of RAM. (The
total memory, including flash, is 387MB.) A faster processor would require
more power, which in turn would prohibitively increase the mass of the rover. The bulk of
the available weight goes to cameras, scientific instruments, batteries, solar
panels, and locomotion equipment.

Figure 2. NASA's Marsette Vona and Mark Powell (Photo by Derrick
Story for the O'Reilly Network.)

Rover Hardware

Because of the limits of mass on the rover, the hardware needs to be versatile. For
example, past missions used large fish-eye cameras to check the sun's position
for the purpose of calculating position, but now small pan cameras perform this
task and take other useful photographs. Solar panels charge the batteries
that power the heater, essential for the equipment to survive the night
temperatures. Eventually, if no other equipment fails, the dust build-up on
the solar panels will reduce their effectiveness and the rover will break.
Already, the two rovers have exceeded their projected 90-Martian-day
lifespans.

An extendable arm hosts additional equipment. One example is a rock
abrasion tool (RAT). The RAT lightly rubs the surface of a rock to clean it,
and then slowly, over a matter of hours, grinds into the rock to take samples.
There are no burrowing instruments, although there is an ice borer that a
subsequent Phoenix mission will carry. The Phoenix mission aims to repeat the
failed attempt to explore the polar ice caps. Work has already begun on this
project.

The rover also carries several cameras used not only for positioning and
photography, but also in surface navigation and descent. Speaking of descent,
the landing required a four-minute entry burn to slow the rover. A parachute
opened, lowering the rover on a bridle. The release triggered a few meters
above the ground, and the craft bounced to the ground. The total descent took
six minutes to slow in speed from 5.4 kilometers per second to zero.

Communication

Bandwidth is limited by Earth rise and set, and distance. Early in a mission,
there might be one to five sessions per Martian cycle, with about 30MB relayed
through orbiters and JPL's Deep Space Network.

Like the game Robo Rally, where players program moves for the next five
turns, scientists create instructions for the rover during the Martian night.
This program drives it through the Martian day while there is no contact with
Earth.

The scientists use multiple images of the rover's surroundings to generate a
view for planning. There are several possible outlooks, including an immersive
3D view, photos with mineralogical test results superimposed on the landscape,
and color highlighting showing the range of the arm. These diagrams help to
create plans and simulations.

Software

The software that drives the mission is known as Science Activity Planner
(SAP). It has three roles: mission operations, public outreach, and generating
next-generation technologies. NASA has made a version of the visualization
software used to plan the daily mission available to the public; download Maestro from NASA.

In addition to this cornucopia of Java, applications such as MySQL, Linux,
CVS, and Emacs reduced the workload of the team. Open source software (OSS) was
vital to the success of the project because it conserved team resources. In
combination with commercial, off-the-shelf (COTS) hardware, open source software
reduced costs, simplified the overall system design, and allowed access to
outside experts.

Using OSS at NASA

Historically, NASA has not used OSS for mission-critical development,
although there have been isolated incidents of its use. For the Mars mission,
administrators decided that open source systems had reached a sufficient level
of maturity. The fact that the team was small and experienced in using OSS
tipped the balance in favor of an introduction of OSS.

There were several concerns to overcome before this happened, however.
Marsette Vona named several of the objections and the responses to them.

To begin with, some wondered why the software was free if it was good.
Another concern was that OSS developers might quit the project. To these, the
team countered that non-monetary motivations drive many developers, and that a
person quitting was also a risk of in-house and commercial software. In fact,
OSS software reduces the risks associated with replacing developers, because
someone else will still have access to the code.

Managers wondered how it was possible to know the quality of OSS. The same
risk exists in commercial software, and access to the source code can aid in
evaluating quality.

Finally, the question arose as to whether there would be licensing issues if the resulting application were not open source. The team replied that it is often possible to purchase a commercial license for a component.

Conclusion

The success of this mission should contribute to a lasting place for OSS
within NASA projects, and the public response to Maestro may encourage future
public releases. The team hopes that the next version of SAP will be open
source. Of the three software components -- Maestro, CLARAty (Coupled Layer
Architecture) for the robotic arm, and ROAMS (Rover Analysis, Modeling and
Simulation) -- only Maestro is currently available.

A potential problem with the release of the obstacle-avoidance software is
that the U.S. State Department considers such algorithms as weaponry,
subjecting them to export restrictions. The team is working toward approval
for release, with one almost ready to go, but there is no indication of how the
State Department will rule.

After the talk, I spoke with Marsette Vona to ask whether he had experienced the
frustration of choosing a component, only to see a nicer one available a short
time later. With all of the time involved in testing and transport before
deployment, I expected this familiar complaint on a grander scale. He replied
that this wasn't a problem for them, because they prefer a well-tested
configuration, and do not work with the newest hardware to begin with. Marsette
did tell me that by the time the mission actually landed, Red Hat 7.3 was near
the end of its supported lifespan.

It is encouraging to see the inroads open source has made into even a very
specialized and rigidly controlled environment such as NASA. They seem to have
reached a balance of using OSS and COTS where they shine, leaving themselves
time and money for the more uncommon portions of the project. The release of
Maestro software also gives us a chance to see the project our tools have
contributed towards. In the future, hopefully it will be the norm for
publicly funded work to benefit the public at large.

Ann Barcomb
studied writing, history, and philosophy before accepting a job as a programmer.