Lisp in Space: The Highs and Lows of Autonomous Spacecraft Control

The history of space exploration is often told through the lens of hardware—the rockets, the landers, and the rovers. However, the software that governs these machines is where some of the most intense technical and political battles are fought. One such story is the attempt to integrate Lisp, a language known for its flexibility and high-level abstractions, into the mission-critical systems of NASA's Jet Propulsion Laboratory (JPL).

This is the story of Ron Garrett, a robotics and AI researcher who sought to push the boundaries of autonomy in space, and the struggle to implement a programming paradigm that was fundamentally at odds with the institutional culture of the time.

The Quest for Autonomy on Mars

In 1988, the challenge of operating a rover on Mars was defined by a brutal constraint: the 40-minute round-trip light time delay. This latency meant that real-time remote operation was impossible; by the time an operator saw a rock in the rover's path and sent a command to steer around it, the rover might have already crashed.

To solve this, Garrett and his team focused on increasing the level of autonomy. The goal was to allow a rover to be given a destination and then figure out the path to get there independently. This work took place on a series of prototypes, including:

• FANG (Futuristic Autonomous Navigation Gizmo): A medium-sized, heavy robot used for indoor and outdoor testing.
• Tooth: A shoebox-sized robot.
• Robbie: A massive, SUV-sized six-wheeled behemoth that became the first robot in the world to navigate using stereo vision.
• The Rocky Series: A lineage of prototypes that eventually led to the Sojourner rover.

Lisp as a "Superpower"

While most of NASA's software was written in C, Pascal, or Basic, Garrett's team leveraged Lisp. In the late 1980s, before the advent of Python or Java, Lisp provided high-level abstractions that allowed researchers to iterate rapidly.

Garrett describes the approach as turning every problem into a compiler problem. For smaller robots with limited memory, the team would use Lisp to design custom languages specifically for robotics, which were then compiled down to embedded code. For larger robots, Lisp ran directly on the hardware.

However, this choice met significant resistance. The prevailing wisdom at NASA viewed Lisp with suspicion due to its garbage collection—which could pause a process unexpectedly—and its high memory consumption. In an embedded environment where real-time response is critical, these were seen as catastrophic risks.

The Political Divide: Autonomy vs. Control

Technical disagreements often mask deeper political conflicts. At JPL, a turf war emerged between Garrett's research-oriented group and a more traditional operational group.

The traditional approach relied on "low autonomy," where an operator described an exact path for the rover to follow. While this reduced the risk of the robot "going rogue," it placed a massive operational burden on the human staff. Conversely, Garrett's approach sought to remove the human from the loop entirely.

As Garrett notes, this wasn't just a technical debate; it was a clash of livelihoods. The infrastructure of people whose roles depended on the manual operation of spacecraft were not naturally inclined to support a technology that aimed to automate their jobs out of existence.

Deep Space 1 and the Remote Agent

Although the high-autonomy Lisp approach didn't make it onto the Sojourner rover, it found a second chance with NASA's New Millennium Program. This program aimed to demonstrate technologies that could reduce mission costs through economies of scale.

This led to the creation of the Remote Agent, an autonomous flight controller for the Deep Space 1 (DS1) mission. The system consisted of several components, three of which were written in Lisp. Garrett's specific contribution was "the executive," the software responsible for deciding the spacecraft's moment-to-moment actions based on input data and contingencies.

To ensure reliability, the executive was programmed in a custom language designed to prevent common multi-threading issues like race conditions and deadlocks. The safety of this language was backed by a formal proof of correctness and extensive ground testing on flight-identical hardware.

The 150-Million-Mile Debugging Session

Despite the formal proofs, the Remote Agent failed during its three-day flight experiment. The spacecraft, 150 million miles from Earth, stopped making decisions.

Because the system was built with a Lisp REPL (Read-Eval-Print Loop) running on the spacecraft, the team had a unique capability: they could send S-expressions (Lisp code) directly to the machine via the Deep Space Network. After a grueling process of managerial sign-offs and 70-meter antenna transmissions, the team requested a system state dump.

The backtrace revealed a race condition—the very thing the language was designed to prevent. The failure occurred because a developer, unable to implement a specific feature using the language's safe constructs, had bypassed the safety guarantees by calling a lower-level Lisp construct. This "unsafe" escape hatch created the deadlock.

Lessons Learned

Using the REPL, the team managed to manually inject an event to "un-wedge" the system, allowing the mission to complete its objectives. However, the experience left a lasting mark. The autonomy project was canceled shortly thereafter, and the high-level Lisp approach was marginalized.

Reflecting on the experience, Garrett suggests that the value of a tool like Lisp isn't in its universal superiority, but in its "impedance match" to the user's mindset. For Garrett, Lisp's way of treating code as data and its powerful abstractions were a perfect fit, even if they were an institutional misfit at NASA.

Ultimately, the story of Lisp in space serves as a reminder that formal proofs are only as strong as their assumptions, and that the most sophisticated technical solutions can be derailed by a combination of human error and organizational politics.