As told to Matthew Kohut by Butler Hine and Mark Turner
When Pete Worden took over as the center director at Ames Research Center, one of the charters he came in with was to inject low-cost ways of doing spacecraft development into NASA as an agency. He kicked off a handful of projects to achieve this, including the Modular Common Bus. At the outset, he told us to design for a broad range of target locations: lunar orbit, lunar surface, libration points, and asteroid rendezvous. He also said we had to make the spacecraft compatible with a range of low-cost launch vehicles, from the Falcon 1 at the low end to the Minotaur 5 at the high end.
Capabilities-Driven Design: Fly It and They Will Come
The Common Bus basically flipped the standard NASA spacecraft development pyramid, where you start with your requirements and instruments and flow a spacecraft design from that. We call the Common Bus approach capabilities-driven rather than a requirements-driven development. The idea is to maximize the use of off-the-shelf or readily available components and look for a sweet spot in the design that will enable you to create a small spacecraft for common use independent of the payload you’re going to carry.
If you build a standard size and form factor, the science community will create payloads to fly on it. Once you standardize anything that’s going into space, the science community is creative about making packages work in that form factor. And while we didn’t design the spacecraft for any particular payload, we did look at the list of possible payloads: some of the robotic precursor concepts for the lunar lander, dust experiments and other science for lunar orbit, communication relay packages for lunar orbit, and typical packages for asteroid rendezvous. We picked the most challenging payloads in each of those areas and used them to shape our design. So even though we didn’t design for one payload, we did work with a lot of examples.
An Atypical Team
One thing Director Worden did early on was bring in Al Weston and Pete Klupar, two people from outside NASA who had extensive experience at the Air Force Research Laboratory (AFRL). Al was halfway a team member and halfway our primary customer. He was involved every step of the way. Formerly director of the National Hover Test Facility at Edwards Air Force Base, he had a lot of experience. Pete, who came from AFRL to Ames, has flown something like forty-five to fifty small spacecraft. During a typical NASA career, you get a half-dozen missions under your belt, if you’re lucky. The AFRL model is one we looked at in trying to enable small spacecraft design, and Pete was the one who brought that experience to the table. So we had a lot of resources around us with tremendous experience, but it wasn’t the traditional NASA experience.
Engineers prepare the Hover Test Vehicle for ground tests.
Photo Credit: NASA
We were set up like a skunk works, and we were allowed to handpick the best people on the team. A lot of them had some flight experience in International Space Station and Space Shuttle payloads or sounding rockets, but the team as a whole did not have a lot of experience with free-flyer spacecraft. One of the things we learned when recruiting people for this kind of team was to look at their hobbies, because that tells you a lot about how they’ll approach their work. Most people on this team had hands-on hobbies: woodworking, machining, racecar fabrication.
Our team has an extremely strong foundation in engineering design and materials. Most of our folks have fifteen to twenty years of hardcore engineering design experience. Their greatest strength is that they have multidisciplinary skills. Many of our engineers are capable of performing tasks typically done by a variety of engineering disciplines. For example, some have run smaller projects in which they have had to design, analyze launch loads, develop requirements, manage configurations, write their own test plans, and do their own verification and validation.
For the Common Bus effort, our designers assembled the prototype hardware they designed to the greatest extent possible. This was done to contain costs and also to allow them to experience firsthand what worked and what did not. Having a smaller cross-disciplinary team creates efficiencies by requiring less time to communicate and transfer information and instructions. For projects of this size, this approach has been very effective. They also had incredible intellectual curiosity. As soon as we gave them a problem, they ran out and researched everything that had been done.
A Modular Approach
Given the range of targets, we figured we’d have to design an orbiter and then separately design a lander, because we assumed that one spacecraft couldn’t meet such radically different requirements. So we started out designing landers and orbiters in parallel. As the designs evolved, the design team started breaking the systems up into modules. There were a lot of reasons to do that.
The thing that stretches out the cost and schedule of a typical spacecraft build is the integration flow—downstream integration that depends on upstream integration being completed first. We pushed for modularity so we could have parallel integration of the spacecraft development. According to some of the schedule rough cuts we analyzed, parallel integration could save us up to a year.
There was a “Eureka!” moment when the team suddenly realized that we could use some of the same modules for both orbiters and landers. Suddenly the team coalesced around these module designs that become an orbiter configuration when you combine them one way and a lander configuration when you combine them another way. And if you standardize the modules, then theoretically you can reuse that design for each mission and recombine the modules to meet specific mission requirements.
When you look at design drivers, especially your launch loads, a cylindrical structure is close to ideal. Early spacecraft like Pioneer have very efficient shapes; they’re usually cylinders with body-mount solar panels. Then you realize that, if you start using advanced composites, which they didn’t have in the sixties, you could have the beauty of flat surfaces for mounting your electronics, payloads, brackets, and harnesses very easily, yet maintain close to the same structural advantages of a cylindrical shape.
Through the use of composites, what worked for a lunar lander was also ideal for an orbiter. These common segments enabled us to maximize payload capacity, which was critical for these very small, mass-sensitive launch vehicles.
A Design Trade: Body-Mount Solar Panels
Historically, Ames has done body-fixed solar panels for a lot of designs. Other NASA centers standardized around deployable solar panel wings. Our preference for fixed solar panels was kind of a running joke because we wound up there for reasons having nothing to do with past Ames designs.
Body-fixed solar panels made us independent of attitude in space. That gave us structural advantages as well, and it also gave us a lot of flexibility to handle the thermal environment operationally rather than in the design. It meant we could be a three-axis stabilized spacecraft, or a spinner, or a combo. We could have a pointed instrument that needed to be three-axis stabilized, and then for thermal reasons we could do a slow rotation to avoid having one side constantly hot and the other constantly cold. One of the main reasons reusable spacecraft designs haven’t really worked in the past is because of issues like thermal design. Typically your thermal design has to be customized for the payload and the location where you’re sending the spacecraft. That’s what makes each spacecraft unique: the mission, the launch loads, and the thermal environment.
As we got deeper into the solar panel work, we also realized that, from an orbital mechanics standpoint, we could go on longer, slower-duration missions by being body-mount fixed instead of deployable. Vehicles sometimes take many days or weeks to get to their final destinations. If you’re going to the moon, you’d have to do a descent—a braking burn as you approach the moon—and the g-loads would be so great that you wouldn’t be able to use deployable solar arrays until you got to the moon. But if it takes days or weeks to get there, your only real option is to keep everything body-mount fixed. That bought us a lot of flexibility for many of these small science missions. It’s perhaps not optimal from a power standpoint, but it provided tremendous flexibility from a mission operations standpoint.
The Common Bus Hover Test Vehicle undergoes free-flight tests in the Hover Test Facility at Ames Research Center.
Photos courtesy Mark Turner and Butler Hine
When you go body-fixed, you have less surface area for solar panels. Our design was able to produce 200-plus watts, which gave us plenty of power for the baseline spacecraft use and 60 watts or so available for the instruments. For the whole range of instruments we looked at, 60 watts was plenty. Instruments with higher power requirements may call for deployed wings that articulate to track the sun, which can give you a kilowatt, but that starts to limit the types of missions you can do. That was one of our direct trades: power availability versus thermal and attitude generality.
Deployed arrays also went counter to our philosophy of keeping costs low with short turnaround time. Deployables require one of the more elaborate, lengthy, and expensive test sequences. The gimbals, for example, are typically one of the longer lead items on spacecraft development. So we saw bodyfixed panels as a real risk-reduction enhancement without compromising the particular science suite we were trying to address in this particular portfolio. But it was a trade-off. We did give up power in order to get this flexibility.
A Knowledge Network
Because Ames is a research and development center, the systems engineering group here has the ability to work on a diverse array of engineering projects. Since most of our engineers work on smaller, shorter-run projects, they typically have to be jacks-of-all-trades. To survive in this environment, you have to be able to synthesize a state-of-the-art problem quickly and figure out how to extract the knowledge you need from the resources available. Nowadays the Internet has made that much easier, but most of the guys on our team were practicing this in the days before the Internet. The ability to extract that type of knowledge—tracking down the necessary information, setting up a network of colleagues around the country to get the answers you need—is really a black art.
Since our team as a whole was relatively new to spacecraft design, we looked at what everybody else had done. None of our engineers like to reinvent the wheel. So we started by absorbing everything that had already been done historically and making sure we had an appreciation for that.
The two of us had the advantage of working for the Robotic Lunar Explorer Program (RLEP), so we had substantially researched prior lunar robotic missions such as Surveyor, Ranger, and even Lunakhod, a Russian lunar rover. We actually extracted Russian books and had parts of them translated so we could learn as much as possible. We also looked at robotic lander missions flown to Mars. So we didn’t start from scratch. We had extensive research already at hand on robotic missions—lunar and Mars, Apollo data from the past, ranges of instruments that could do robotic precursor activities for the Vision for Space Exploration. We found gold mines in the early Apollo precursor missions. A lot of smart people had gathered a lot of data, and a lot of deep thinking had been done.
During our time in the RLEP program office, we were able to tap into a few of the remaining lunar scientists who participated in Apollo and pre-Apollo programs. We managed to find one of the early Ranger project managers, who was extremely helpful in giving us some of the rationale for decisions made in those early days. Gary Olaf, who was heavily involved in lunar dust studies, was a treasure trove of information from these early experiments. He knew where to find the information, and he gave us a lot of pathways to find information that would typically be very, very hard to get. Again, it’s part of building a network.
One of the keys to success is knowing how to establish a human network. Every engineer on our team relies on a human network to get at stuff that would be otherwise quite difficult. Sometimes those contacts provide unexpected benefits. One of our Surveyor mission reports came from a consultant who happened to know a project manager from Surveyor, who gave him one of the few remaining hard copies of a document. Looking at the thousands upon thousands of people who worked on Surveyor and the millions of man-hours put in perspective how daunting it was for us to do our work with a dozen people. If we did not leverage the work thousands had done four decades prior, our job would have been impossible.
