By Andrew Cheng
NEAR was the Near-Earth Asteroid Rendezvous, the first launch in NASA’s Discovery Program—and the first dedicated asteroid mission. The plan was to insert the vehicle into orbit around Eros, one of the larger near-Earth asteroids. Not everything went according to plan.
This image mosaic, taken earlier in the NEAR mission, shows Eros’s southern hemisphere, offering a long-distance look at the cratered terrain where the spacecraft touched down.
Photo Credit: NASA
NEAR was the first planetary mission by the Johns Hopkins University Applied Physics Laboratory (APL). And NEAR was probably the first NASA mission on which the Internet was widely used. I remember being called in to my management’s office and being asked, “How come I don’t have a file of all the letters and announcements and schedules that I sent out to my science team?”
And I said, “Oh, I’m not doing that. I’m using e-mail.”
“Using e-mail?”
Not that management wasn’t aware of e-mail, but, in 1993, it was a bit innovative to rely on it instead of printed paper.
NEAR was also the first mission with an open-data policy. Previous missions, like Galileo, had a one-year proprietary data period; investigators owned the data for that year and often were reluctant to let other people use it. We were the first mission that had to agree up front to an open-data policy with no proprietary period. Our scientists—in fact, the whole science community—was not used to that idea. In their view, they were investing years to build the instruments and develop the mission, and then wouldn’t receive any reward for the effort.
Without a proprietary period, and with the rapid release of all data, scientists anywhere in the world would be able to glean new scientific results and potentially scoop the mission investigator team. But our experience on NEAR, and subsequently on numerous other missions, alleviated this concern. Mission investigators are familiar with the mission, the instruments, and the science issues, and they have dedicated funding to analyze the data. Given those advantages, they are rarely, if ever, scooped. Science missions with open-data policies are now standard for NASA.
NEAR was also one of the first faster-better-cheaper missions. We advocated for less than thirty-six months’ development, and we actually delivered in twenty-seven. We also came in below our cost cap, which was $150 million. One reason for this success is that we were able to work the way we had always done at APL, even though this was a new type of mission. That was a good lesson: you really don’t want an implementing institution to completely change the way it does business. Even if nobody knew at the time what we were getting into.
When we started mission implementation in 1993, no one had any idea how to operate a spacecraft around a small body. That was the biggest leap into the unknown for NEAR.
Even though we had identified the target asteroid, we didn’t know its mass. Because of that, there was no way to simulate orbital operations. Things you take for granted today, in terms of simulating navigational accuracy and showing that you can obtain all the promised measurements, we couldn’t do because we had no idea what the orbits were going to be like. It was worse than that, actually, because APL, it turned out, had no idea how to operate a planetary mission. We had to learn on the fly.
The NEAR spacecraft undergoing preflight preparation in the Spacecraft Assembly Encapsulation Facility-2 at Kennedy Space Center.
Photo Credit: NASA
Our original plan was to approach the asteroid very slowly and remain at a high altitude—where irregularities in the gravitational field due to the non-spherical shape of the asteroid would be less important—until we gained enough knowledge to orbit at a low altitude, which was required for many of the key measurements we wanted to obtain. Our original plan changed.
There’s folklore that says the job of a mission or program manager or project scientist is to just say no—that when requirements are set they’re set. Real life is not like that. On NEAR, we had a bunch of things we agreed to that were not in our original plan. Flying by Mathilde—to explore a C-type asteroid (meaning its surface is believed to have a high concentration of carbon) for the first time and obtain great science—was one of them. We had to spend extra fuel to get there and undertake operations we had never tried before. And then we agreed to fly closer to Eros than we’d ever intended to or guaranteed we would, and finally land on the asteroid.
The final mission operations ended up being the Mathilde encounter, Earth flyby, the Eros flyby—which was supposed to be the rendezvous, but we missed—the Eros rendezvous insertion, the asteroid landing, and then the science operations.
Learning from Problems
The changes, and our first miss of the Eros rendezvous, ended up being good news. Since we were learning on the fly, we learned more the longer we flew. After we failed to get into orbit as originally planned, we flew by Eros and made preliminary measurements of its mass and shape. This information allowed us to simulate orbital operations, which we couldn’t do before because the information didn’t exist. When we returned to Eros in February 2000 and entered orbit, we were able to descend to a low altitude quickly and make all the planned measurements (plus more) as a result.
That first flyby taught us some tough lessons, too. When we started the second burn of the spacecraft’s main bipropellant engine, it shut down after one second. This brought back memories of what happened on Mars Observer, which was lost during the second burn of its big bipropellant engine. And we didn’t know what had happened on NEAR.
Miraculously, NEAR recovered twenty-seven hours later. The spacecraft contacted Earth and indicated the battery was fully charged. It was in sun-safe mode, but fine. But what actually happened?
We were only able to recover the first forty-something minutes of events that led to the shutdown. After that, we don’t really know what happened because low voltage detected on the spacecraft shut off the solid-state recorders, and the data were lost. So we don’t know what happened toward the end, but we understood the series of errors leading up to that time—starting with how the spacecraft was fundamentally put together. Its construction had many advantages for the mission, but it also contributed to the shutdown.
The main engine was perpendicular to the main load-bearing structure, so when we fired the engine, the structure flexed just enough to create a false reading of lateral thrust on an accelerometer, and that’s what shut us down. The data by which an analyst could have predicted this would happen was actually available but had not been seen or acted on by the right people in order to set the accelerometer’s threshold properly.
High-resolution surface images and measurements made by NEAR’s Laser Rangefinder have been combined into this visualization based on the derived 3-D model of the asteroid.
Photo Credit: NASA
Once the burn was shut down, an automatic command was supposed to place the spacecraft into an Earth-pointing safe mode. It turned out that the command script programmed this maneuver to be done with thrusters, but the same script also disabled the thrusters. So the command was initiated with thrusters but used momentum wheels when the thrusters were disabled. The wheels didn’t have enough torque to stop us in the proper attitude, so we overshot. And because the spacecraft didn’t stabilize at the Earth-pointing attitude, it went again to a sun-pointing safe mode. It didn’t stabilize immediately in this mode, either, so it began to fire its thrusters again to compensate.
In other words, our preflight testing failed to turn up several errors. APL has a deeply ingrained culture of test as you fly, fly as you test. Nevertheless, at least four errors were not turned up by our testing. The right tests—of the guidance system, the autonomy system, the operations scripts—were not done. That’s what caused our problems.
Still, NEAR was designed with enough back-up systems and redundancy that it recovered from the anomalies. We don’t know exactly how it recovered, but when it contacted Earth twenty-seven hours later, the battery was fully charged and the spacecraft was in a nominal state.
There were a number of lessons to be learned there: the way the ops team should operate, the way operations scripts are tested, the way the guidance system is tested before launch. We took those lessons to heart because they showed us where we needed to improve. Since then, we routinely perform the tests that would bring out issues like those experienced on NEAR, and we have not had any similar anomalies on subsequent missions.
Success
Many things also went right. Achieving the first landing on an asteroid is one of them. Another was a magnificent science return that exceeded all expectations.
Our second rendezvous burn occurred at the beginning of 2000, only a few months after the losses of the two Mars ’98 spacecraft. Things that happen to other projects can have a big effect on you, and that’s exactly what happened to us. The Mars ’98 missions were lost, and NEAR was about to make its second attempt to get into orbit around Eros, after screwing up the first one. You can imagine the kind of scrutiny we were under, and the interest we got from Headquarters—exactly the kind of interest you don’t want.
When the time came for us to land NEAR, Headquarters said no, you’re not landing the spacecraft. Instead, we were allowed to command the spacecraft to “descend to the surface,” because descending to a surface does not necessarily mean a safe, soft landing.
When our ops team announced that the spacecraft was on the surface and we were still in contact with it, it took a while for that news to sink in. There was a stunned silence in the room, with all our VIPs looking around nervously. It succeeded? Yes, it did!
These images of Eros were acquired by NEAR on February 12, 2000, during the final approach imaging sequence prior to orbit insertion.
Photo Credit: NASA
Because it was the first launch of the Discovery Program, everybody needed NEAR to be successful. Obviously, APL needed it because it was our first planetary mission. NASA needed it to enable the Discovery Program to establish that it was a credible, useful, important thing to do with Congress and with the Administration. The community needed it because there was great science to be had.
To help us succeed, we had strong support from Headquarters. At the time, the Discovery Program Office at Marshall Space Flight Center did not exist, so we worked directly with the program executives at Headquarters, and we had a good relationship with them. That relationship was—and is—key to helping missions proceed smoothly.
Getting the team to truly be a team is also important. Science, engineering, and management are separate disciplines, but they all have to be pulling in the same direction or you cannot succeed. Nobody can do the mission by themselves. You need the whole team. There were many instances on NEAR, from getting to launch on time and within budget to overcoming the problems that arose in flight—like the 1998 burn anomaly—where the difference between success and failure was, simply, the team.
And it isn’t enough for the leadership team to know what the requirements are; your whole team needs to understand them deeply. Not only what they are literally, but where they come from and how they bear on what the mission is supposed to be doing. The subsystem leads and even the people at lower levels than that should understand them, too, because they make decisions every day. If they don’t understand your requirements, they may create a problem you won’t find out about for a long time. Or they may have a better solution to offer that fulfills the intent of the requirement. It must be okay to ask questions and bring up issues, even about subjects that may be outside ones discipline.
Many lessons are learned over and over again. It’s not that we’re stupid and never learn from the past, but when you’re going to new places, doing new things, and making discoveries, you often run into old problems in new guises. Technical circumstances, political environment, external environment, and program management are always changing. So when the gremlins show up on your program, they may look different from the ones people saw before, even though they are fundamentally the same. The challenge is to recognize those similarities earlier so you can apply lessons learned to fix them with less pain than your predecessors.
About the Author
 |
Andrew Cheng is the chief scientist for the Space Department at the Johns Hopkins University Applied Physics Laboratory, where he serves as the departments external liaison for space science and provides independent science advice and strategic vision to lab and department leadership. He was the project scientist for the Near-Earth Asteroid Rendezvous mission, which was the first to orbit (and eventually land on) an asteroid. |
www.youtube.com/watch?v=O4gqsuww6lw#t=0m49s
