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.)
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.
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.
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.
Maestro relies upon the newly-opened Java 3D, which itself runs on top of low-level graphics libraries and offers immersive display support. SAP uses additional Java tools, including Xerces-J, Java Expression Parser (JEP), Java Complier Compiler (JavaCC), Xalan-J, J-unit, and others.
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.
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.
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.
Return to ONLamp.com
Copyright © 2009 O'Reilly Media, Inc.