We humans have turned our faces heavenward since we can remember—no doubt at the same time as we painted animals in caves and learned to make fire. Thousands of years later, we stand at the incredible moment in our history when we’ve successfully landed a creature of our own making on another planet: the Rover. On Mars.
To boldly go where no biped (or motorized space vehicle) has gone before requires serious heavy lifting in terms of planning, testing, operations, and logistics, not just here on Earth but also out there.
We talk to Nagin Cox, spacecraft systems engineer for NASA’s Curiosity mission, about the joys, challenges, and hard-hitting realities of developing, preparing for, and operating the Mars Rover missions.
NASA is no startup. This government agency has been around for 58 years, and it’s not looking to disrupt mature markets or make out like a bandit with a freshly minted IPO. NASA, explains Nagin, has always had a three-pronged mandate for its missions:
“There is something called the decadal survey,” she says, “which is done for NASA by a committee of very prominent scientists. Every decade they get together and they do this survey. They determine what the most important exploration objectives are. One of the largest conflicts has been—for decades—between bringing back an actual sample from Mars versus exploring the outer moons of the solar system like Europa and Titan. Given the limited budget of the U.S., it’s a challenge!”
Once the exploration objectives have been set, NASA designates specific missions as either ‘directed’ or ‘competitive.’ “Directed” missions are those where NASA determines which NASA center will be primarily responsible, while “competitive” missions are open to partnerships between scientists, universities, NASA centers and commercial companies. For example, Mars 2020, the mission that launched the Curiosity Rover now exploring Mars, is a directed mission.
“And from those science objectives,” continues Nagin, “everything else flows: what computer systems we need, avionics, altitude control, instrument suites, parachutes, and so on—and the interfaces among them all. And of course, we also need to take into consideration how we’re going to operate the mission once it’s launched, in a way that achieves the mission objectives. Part of the process is to evaluate lessons learned from prior missions. That’s mission planning.”
Anyone designing a new product or technology faces any number of known and unknown unknowns: Will our technology really do what it’s supposed to—while improving lives/efficiency/performance? What are the possible ways our hardware could break? What about all those things we don’t even know might happen?
"You have to think about all the unknown unknowns.”
But when you’re developing a machine that’s supposed to push through the Earth’s atmosphere and break the gravity barrier, travel through the vacuum of space, land (safely!) on the surface of another planet, and carry out various operations over a period of several years, these questions carry a much greater weight—and risk.
“It is indeed hard,” concurs Nagin. “And it’s a skill. You have to think about all the unknown unknowns.”
Every JPL’er (as the folks at NASA’s Jet Propulsion Laboratory, or JPL, call themselves) has built into his or her “mission DNA” the ability to “think about what you don’t know, and to leave a lot of margin for the things you don’t know that you don’t know. We come from academia, so it’s like going through a PhD dissertation multiple times throughout the mission. It’s a tough part of our culture, but [it’s] very strong in the what-if’s, in stress testing, in way overthinking the failure scenarios and margins and uncertainties.”
Nagin recounts the time in 2004 when the Spirit Rover landed on Mars.
“Spirit had a problem with its flash memory in the early days after landing. Our recovery from that rested heavily upon the chief software engineer, who had the foresight to create a backdoor into the flash memory. He didn’t have a hugely plausible scenario, but he prepared for it anyway.”
Despite the vast mysteries of space, there is quite a bit NASA does know and can prepare for, and that’s thanks to decades of reconnaissance missions and simulations.
“In general,” explains Nagin, “we will do a fly-by at the very early stages of a mission, that literally just flies by and takes pictures. Then we send an orbiter to be in the planetary system for a period of time, to map it, to get an idea of what the area is like, before we can even contemplate landing. You need to have enough data to choose where you want to land, what the terrain is like.”
On top of that, adds Nagin, even as one mission is in heavy development or perhaps already starting up, another group is already thinking about the next mission that will build on the findings and results of the current one. These are the “conceptual formulation folks.”
“The more you can minimize doing things that have never been done before, the greater chance you have of succeeding."
Simulation goes hand in hand with the reconnaissance missions. “We do shake tests that simulate the stresses of launch,” says Nagin. “We have large environmental test chambers that mimic the light from the sun—to give us the same thermal situation as in deep space. We took our radar out to the desert at Edwards Air Force Base, where pilots flew them at high speed toward the ground to simulate entry."
“And for entry, descent and landing, we get into a large amount of simulations—such as the parachute drop test, which is very expensive. We test parachutes in wind chambers for every mission, but the flight tests are much more expensive and are done more periodically.”
In short, Nagin says, “we do our best to piece together what it’ll be like on launch, and try to stay reasonable from a budget perspective. Certainly, we heavily incorporate the lessons learned from previous missions—we use all the imaging and telemetry and other info from those missions that we can. It’s a balance between science and data.”
A good example of the kind of iteration that NASA goes through on any given technical aspect of its Martian missions is the landing mechanism.
“You think you understand the behavior of parachutes,” smiles Nagin, referring to the large parachutes that help the Rovers touch down on the Martian surface. “And then, consistently, on the next mission, the parachutes fail again. The way they interact with the Martian atmosphere is different every time—given their large size, the material they’re made of, and maybe they’re a different shape. Then there’s the Rover itself, which is different on each mission.”
With Curiosity, she shares, “the thrusters on the descent stage were canted to a certain angle. But as we did more simulations, we realized that given the atmosphere, the speed, and the various ways in which the Rover could be swinging on the [parachute] rope during descent, we were running the risk of contaminating the deck with residue from the thrusters. So we had to redesign them.”
Here's a short video that summarizes the incredible engineering behind Curiosity's entry/decent/landing system:
Curiosity’s entire entry/descent/landing system was certainly very innovative, says Nagin, but the larger goal was to advance NASA’s ability to send larger missions and fulfill those decadal science objectives.
“The more you can minimize doing things that have never been done before, the greater chance you have of succeeding. So it all tends to be more incremental rather than crazy disruptive.”
When we ask Nagin what the toughest challenges have been for this mission, she lays it out straight. “We are consistently challenged by three issues: power, thermal, and timelines.”
But there’s this huge reactor out in space, called the Sun. Wouldn’t solar be a perfect source of abundant free energy?
“From a hardware perspective, power is always a huge challenge... Every time you build a more powerful computer, you need more power.”
The previous Rovers—Spirit and Opportunity—were indeed solar-powered. But Curiosity runs on nuclear power; specifically, radioactive decay of plutonium. The reason for going with nuclear on this mission is because “we’re not dependent on the seasons. We can do things at night [when there’s no sunlight], although it’s of course colder, so we spend a lot more energy waking the Rover and heating it up.”
Another way the Rover conserves energy is by, well, conserving energy. It’s a bit like a daily dose of electronic hibernation.
“From a hardware perspective, power is always a huge challenge,” says Nagin. “Every time you build a more powerful computer, you need more power.”
As far as the Martian environment is concerned, the Martian atmosphere is less than 1% as thick as Earth’s, and its gravity is a third of ours.
“Temperatures on Mars are more extreme than they are here on Earth,” says Nagin. “The atmosphere and the gravity are of course different, and it gets warmer than people think—so that creates these giant thermal cycles. The wind is not very significant.”
And finally, that aspect of timing, which is more critical in space than it tends to be here at home.
“There are launch windows that we have to meet: on Earth, if you have a problem, you can let a few weeks or months slip by, but with planets, if you miss your launch window, you slip by a few years—and that’s a long time to have to maintain your spacecraft and your people.”
Mars is one place that’s not very communication-friendly. For one thing, its distance from the Earth ranges from 34.8 to 250 million miles, depending on where in their orbits the two planets are at any given time. So how do NASA engineers talk to Curiosity?
“We can’t just joystick the Rover, like the Chinese did with their rover that they landed on the Moon,” shares Nagin, “because the moon is just three light seconds away, while a signal to or from Mars can take anywhere from five to twenty minutes to arrive. So we use remote sequencing. While the Rover is asleep, we’ll take a look at how she fulfilled the prior days’ activities. If that went well, we decide what we want to do the next day.”
"It’s critical to diagnose the true root cause of a problem rather than the symptoms.”
Translation: Get the scientists to agree on their priorities.
Once that hurdle has been cleared, Nagin continues, “We lay it all out in software similar to a GANTT chart. We get it all lined up and prepped, and then convert all the commands from the different teams into sequences, which are then converted to binary code that the Rover will understand.” She adds that it used to take mission control sixteen hours to plan Curiosity’s day; now, with all the experience behind them, it takes just nine.
The command sequences are then labeled for the spacecraft they’re destined for, and mission control wraps it another layer of metadata that addresses the command package to the specific antennas that will beam them to Mars.
In this case, it’s the Deep Space Network Station, or DSNS, with antennas in California, Spain, and Australia, and the specific frequencies they use are the F-band and S-band radio waves.
“Depending on where Mars is [in relation to Earth] at the time of transmission,” adds Nagin, “it could take anywhere between five to twenty minutes to transfer.”
Not likely to happen anytime soon. So how do you fix things that break on the ground out there? The usual can-do entrepreneurial spirit does come up against some hard realities on Mars.
“Obviously, you can’t fix the hardware. It’s gone,” says Nagin. “And that’s why you need [those] redundancies. So we’ll have two or more of the same computer on board, for example. You can also have functional redundancy, meaning functions that can be performed by several different pieces of hardware.”
What’s more common, she adds, is the software workaround. “We can load software after launch. We can patch it. Or we can do a full reload if it’s really bad.”
Then there are what Nagin calls “ground workarounds.” This refers to transferring the responsibility of performing the function in question back on Earth, in mission control.
“As a mission gets longer, some of the top expertise might still be with the original engineers... recovering that knowledge becomes progressively more challenging.”
“It might be slower and harder,” she says, “and it depends on whether it’s feasible and won’t break the project budget. The first thing you have to do is understand what happened up there, because it’s critical to diagnose the true root cause of a problem rather than the symptoms.”
Perhaps ironically, the one obstacle Curiosity’s human team is coming up against is the slow loss of human expertise, now that NASA’s Martian missions have been going on for a few years.
It’s not that the engineers are getting any less smart or capable.
“As a mission gets longer,” Nagin explains, “some of the top expertise might still be with the original engineers who’ve since moved on to other projects.” Or, as tends to happen with us humans, simply passing away due to old age, like with the Apollo program, she adds. “So recovering that knowledge becomes progressively more challenging.”
But NASA is not one to sit idly by. The agency has taken active steps to ensure that the volumes of expertise and knowledge that have been building up inside its mission personnel’s heads are captured, maintained, and shared. They’re capturing it all in a formal “lessons learned” process and database, which are made accessible to other missions, says Nagin. In addition to that, JPL follows a set of design principles that enable missions to communicate their know-how with each other and avoid reinventing the wheel.
With everything that’s on the table during these missions, not least the multi-billion-dollar budgets that make them possible, knowledge transfer has to be top priority.
Success is a funny thing. If it’s too easily attained, we don’t value it. But the higher the odds are stacked, the more euphoric that feeling of accomplishment. Landing a Rover on Mars and remotely operating it for four Earth years counts without question as one of the great achievements of humankind.
And yet, it’s the lessons learned on the ground that NASA’s team can share with the rest of us that are likely to prove more valuable to more industries back on Earth: figuring out how to approach what you don’t know you don’t know. Simulating environments, conditions and scenarios whose characteristics and parameters are unlike that of our own (or what we’re used to). Communicating and prioritizing when your most critical team member is a machine. And most importantly, ensuring that the knowledge accumulated and vetted over numerous team changes—not to mention over successive massive budgets—is well documented and transferred to new generations.
Success! Thank you for subscribing the Fictiv Blog!
Thank you! Please check your inbox for a confirmation!
Thank you! Please check your inbox for your subscription confirmation.
Oops! Something went wrong while submitting the form