Once the two spacecraft inhabit the same piece of paper (a feat that can consume a lot of fuel), they next must inhabit two orbits that are similar but not quite identical. Picture an ellipse or circle. Now draw a smaller one that is precisely the same shape, so that the two orbits always have the same distance between them, at every point. Putting the ships in different orbits might seem counterintuitive, but this is the only way that one ship can catch another around a planet. The ship on the smaller orbit needs to start behind the one in the larger orbit, because the closer orbits have greater speeds (sort of like the inside versus outside of an oval racetrack). For NASA’s rendezvous attempts, the orbits might be just ten miles apart; at that distance, the faster ship is catching up at the gentle speed of twenty feet every second.
Finally, as the faster ship catches its slower and higher partner, it maneuvers carefully upward to finally join the higher orbit. Now the ships are incredibly close, in the same orbit, moving at nearly the same speed. A few last maneuvers—like those practiced by Moser and company in the vacuum chamber—bring the probe and drogue to a locked embrace. These last, tiny steps can still be vexingly difficult. Moving in circles renders our natural human intuition to move in straight lines counterproductive, and success was elusive for astronauts in the first rendezvous attempts, frustrating exercises that deserved a “Yakety Sax” soundtrack.
Engineer Cathy Osgood (she who composed the pro-and-con NASA decision list with her husband) recalls the earliest times of computing rendezvous. At first, they planned a simpler approach. They would launch the first ship into an orbit, and then “just launch directly into the orbit and rendezvous.” But, “Oh no . . . if your launch [of the second ship] is delayed [even a few minutes], your plan has gone.” She and her colleagues next considered using two naturally different orbits that would intersect in at least one point over Earth. But calculations showed that the ships would be hurtling toward one another at dangerously high speeds. The engineers eventually arrived at the recipe outlined previously, involving an inside track and an outside track.20
Even though this method eventually worked, they encountered further difficulties. When two craft are in different orbits around Earth, they each encounter a slightly different amount of residual atmosphere. The “lower,” faster one fights against more drag from air resistance. This proved an elusive effect to master in engineers’ predictive calculations. Furthermore, to be precise, we can’t treat Earth as a perfect sphere. It bulges around the equator, and its gravitational tug varies from one orbital location to the next—not by much, but enough to cause complications. Engineers had to treat many of these factors as mysteries, running hundreds and thousands of computer simulations to understand the whole range of possibilities for a given mission.
All the while, a Gemini Earth-orbit mission in 1965 would still have some gaps of radio silence more than ten minutes at a time. NASA had worked its way to an unprecedented global communications network, with some twenty-five worldwide communication stations. When they’d had to evacuate the Zanzibar station in the midst of a coup, they set up another in nearby Madagascar. NASA built a station on barren little Ascension Island in the south Atlantic, despite conditions so brutal they forbade families from visiting the engineers stationed there. The network even included, during missions, a patient navy vessel bobbing in the Pacific. Despite all the progress, NASA had to accept that any capsule would spend time in dead zones in between their stations. During the more stressful and troubled missions, astronauts would enter the silent times alone, and ground-based engineers could only run their calculations and fret.
Worry and broken communication mirrored what some of the engineers’ households experienced in this era. “The bad part of that is a lot of families suffered,” says engineer Ken Young, echoing the confessions of many. “Especially Gemini, I worked six and a half days a week. I’d go home at noon on Sunday to watch the Oilers play . . . and the family suffered. That was our fault.” Divorces became commonplace in the engineering ranks.21
Rushing into the autumn of 1965, the schedule at Cape Canaveral reached a sort of steady-state crisis. Engineers endured hectic launch days crowding ever closer on the calendar. Launch days could start at two in the morning and, even if all went well, end at midnight, after refining the schedules for the next launch and starting to refurbish the launch pads. If one task or mission fell slightly behind, the team juggled the densely woven schedule to maximize the progress of every hour.22
A striking example of this shuffling came in the last months of 1965, as NASA tried to achieve one or both of two milestones: rendezvous of two spacecraft (getting close to one another); and an actual docking of two spacecraft (linking them together, probe to drogue). In late October, NASA had planned to have a manned capsule launch right after an unmanned launch. The manned capsule was to chase an empty, dormant segment of the unmanned rocket in orbit and briefly attach to it. However, as the astronauts waited on the launch pad, the first rocket (luckily with no astronauts on board) fractured to pieces as it ascended. With no target for docking, NASA canceled the second launch.
The planners and engineers huddled: before Christmas, they could try something else. They quickly scheduled two manned missions, hoping two manned capsules could attempt the first rendezvous before the year’s end.
The first mission went up without incident on December 4th, and the capsule found itself in patient orbit, awaiting its twin’s launch about a week later. The waiting was not entirely boring, unfortunately. Fuel cells, energy-supplying innovations that they were, misbehaved again, each time triggering alarm bells and flashing lights within the Gemini capsule. Imagine dealing with a significant fire alarm while strapped into a closet. As one astronaut later said, it was like “eating, sleeping, working, and going to the bathroom stuffed into the front seat of a sports car.”23 As the fuel cells kept them awake, the astronauts grew increasingly tired and cranky.
The second launch nearly ended in tragedy. The Titan rocket, delayed from October, ignited on December 12 with, as engineer Christopher Kraft called it, “the customary belch of gray and red smoke,” but then the sound stopped, with the rocket having barely shifted in its seat. An anxious pair of humans sat on top of an enormous explosion waiting to happen, as two poisonous and volatile chemicals longed to combine beneath them. In this case, calm human intuition saved the day. By the book, the astronauts were to pull an ejector ring and have the capsule fling them harshly out over the launch complex. But they decided to ignore their training because, in the quiet, with no sign of an explosion or fire, it seemed safer to sit tight. Fuel pressures eventually ebbed, and NASA safely removed the astronauts from the rocket. In the end, engineers found two little problems: an umbilical cord had disconnected from the rocket a tad early, leading the rocket to assume a major malfunction. Next, engineers found a little plastic dust cover in a fuel line; someone had simply forgotten to remove it when putting the rocket together before launch.24 But after some round-the-clock work, they sent the rocket on its way again just three days later.
Now, in the last weeks of 1965, NASA had two manned spacecraft trying to find one another in the immensity of space above Earth. Soon, the mathematics of rendezvous provided a miracle. One capsule caught sight of its twin, first appearing as a bright star, with the inner track slowly catching the outer track. The ships grew in one another’s windows until the two pairs of astronauts were just 130 feet apart, each traveling at absurd speeds above Earth. Rendezvous had worked, and several engineers have marked this moment as the pinnacle of their NASA careers, after years of proving, on paper, that it could happen. By gently using their thrusters, astronauts got their ships so close that they could have opened a hatch and literally touched one another. Fresh-faced and energetic astronauts peered out from the second capsule, seeing more scraggly and exhausted faces in the first. The first capsule had already been in orbit for a week and a half. Food crumbs, dried skin flakes, and droplets of pesky, escaped urine floated around t
he astronauts.
The second ship, with its happier campers, soon made its way back to Earth, while the first capsule slogged along to complete its long-duration mission, testing how long humans could stay in space. By the end, with their fuel cells dead and most of their electronics switched off to conserve power, one of the astronauts said spending fourteen days in the capsule was like “living in a men’s room”—and not a large one. Even removing a spacesuit was a major geometrical puzzle. One astronaut, out of tasks, just read Roughing It by Mark Twain, dreaming of open skies and elbow room. When they at last splashed down, navy divers swam to their capsule to recover the 13.75-day space veterans. Three frogmen attached a floatation collar to keep the capsule upright, as usual, and then helped the crew open the hatch. In this case, despite the rigorous training and seaworthiness of the divers, two of them apparently wretched in the ocean after getting a whiff of the cabin air and the fusty astronauts within.25
By the end of 1965, some of the blush had arguably faded from the spacefaring rose. And while plenty of progress could be found, troubles multiplied just as quickly. Engineers scratched their heads over how they could hold a massive Saturn V rocket upright before its launch. They designed a new launch tower with nine “swing arms,” each weighing around twenty tons and wide enough for a lane of car traffic. In addition to holding the rocket upright, the arms would convey fuels, oxygen, and electrical power. And they had to be nimble, retreating in two coordinated waves from the Saturn V rocket at just the right moments of a launch. The arms, while critical to Apollo, aimed to grip a not-yet-finalized rocket. Engineers struggled to design arms that could someday clasp a rocket that was still changing its dimensions, its fuel needs, and its electric power ratings month to month. The company charged with building the arms grew frustrated; they had signed on for X and kept getting requests for Y and Z, and then suddenly back to X.26
At the same time, any visitor or engineer moving around the Kennedy Space Center complex had to avoid a sobering, lingering eyesore. The massive crawler, that mechanical beast adapted from coal mining to carry a Saturn V and its nine-armed chaperone, had broken down halfway to the launch pad. The crawler sat there like a sad tractor abandoned by a rural highway.
* * *
i Astronaut Ed White, mission Gemini 4, spacewalk of June 3, 1965.
ii The remnant puff was technically a plasma.
iii With thanks to Frank Hughes and Ken Young for the detailed rendezvous conversations.
9
1966—Of Software and Star Balls
My father relays a story of a young, obsessive genius who helped mission planning. He lived in a small apartment, on his own. “He didn’t have any furniture. Just a few old milk crates and things like that.” But this man of simple means, one who frequently forgot to cash his paychecks, was helping correct the computer programs that would take us to the Moon. The young man literally checked the output of Apollo’s early computers by reading streams of printed numbers like a broker might have read a stock trading ticker. “In the morning, you’d come in,” my father says, “and he’d have left a stack of output, circling each error.” Computer experts from NASA and leading consultants at MIT had initially considered the engineer a little too eccentric to take seriously, but they discovered he was always correct.i
In 1966, Apollo felt a new bottleneck in a lesser-plumbed realm: computer “software.” (The term had only emerged in technical conversations in the late 1950s.) Engineers—primarily a group at MIT’s Instrumentation Laboratory—had been so focused on building small, robust, and simple computers for the Apollo missions that they’d neglected the need for programs that would live and run on those computers. At some point, NASA realized astronauts, with little natural interest or ability in using these suspicious new machines, were not going to merrily program them while floating in space. Someone had to create simple, reliable, never-crashing computer programs, with no time to spare.
A freshly minted engineer named Jack Garman joined NASA at this time, having taken a couple of programming classes as college electives. “I had no idea where Houston, Texas, was,” he said. “You know, it was kind of ‘Alice Through the Looking Glass.’ You get in the car, you drive down, and you start going to work. Your eyes are wide . . . everything was very awe-inspiring.” He recalled his assignment. “I came in May of ’66, and I think back in February of that year the software program for the Apollo onboard computers had gotten in deep trouble.” His new employer sent him to five weeks of special classes, to learn Apollo and to learn more about programming. None of his college studies (focused on traditional engineering) had prepared him for the torrent of nonstop novelties, but he was thirsty. “So while I was drinking from the fire hose, I had no trouble swallowing.” And, as often happened at a young agency that needed new thinking in Apollo’s every nook and cranny, a new employee could suddenly assume huge responsibilities. “So when I got back to the office,” he said, “I truly didn’t realize it at the time, but I was an expert. . . . [T]hey immediately made me a group leader . . . you know, I’m twenty-one, twenty-two maybe by this time.” Soon, just like Marlowe Cassetti, he would be a twenty-something needing to direct people in their thirties.
He encountered reluctance from the older guard. His colleagues said, “What is all this stuff? I just want it to work,” Garman recalls. “All this computer stuff, get it out of my hair.” The flaky nature of early computers fed the distrust. If the physical switches and wires actually worked (not always certain), then the programs running it—the software—would be full of bugs. And computers were anything but soft and fuzzy. The barrier to interaction was incredible at the time, even once they had screens instead of just cryptic strips of paper output. “The displays we looked at were just columns of numbers. . . . [T]hat technology absolutely amazed me, enthralled me, and [just] the ability to stare into a computer,” Garman said. “Have you seen the movie The Matrix? . . . [T]here’s a fellow staring at this sort of waterfall of numbers on a screen.” The character is able to recognize, in the cascades of numbers, everyday objects, like a person crossing a street. “That was deja vu for me,” Garman said. The computer displays of the time only showed a series of numbers (in octal format), and over time Garman recognized enough of the code to nod along, to literally see what the computer was doing. “People would walk up and say, ‘You’re weird.’ ”1
The problem of computer programming had quietly become central to Apollo’s success when NASA made the radical decision to put a digital computer “autopilot” into a flying machine.2 Garman later explained Apollo’s autopilot as follows: “Kind of like if you were walking down the street, you open your eyes to see where you are once every two seconds, and you see the hallway around you and the ceiling and the road ahead, and then you shut your eyes and then decide where to put your feet. . . . So you take three steps. Then you stop and open your eyes, look around, shut your eyes, and go. That’s exactly how the navigation and control work, okay? Read all the parameters, do the calculations, and pump out the next two seconds’ worth of commands for which way to point engine bells and throttles and so on.”3 The Apollo autopilot used a sensible sort of step-wise flowchart now familiar to much of the world’s software.
In May of 1966, a senior NASA leader had just declared that software would soon be the primary pinch point of the entire Apollo program. The good news arrived just two months later when MIT delivered a new and improved version of the physical computer itself. Compared to the older model, it ran faster, weighed less, consumed less power, and, crucially, held twice the memory (a whopping two kilobytes). It all fit within the volume of a shoebox. Engineers had also devised a way to make the final version watertight, because an astronaut’s space spill could drift within a capsule and ruin exposed circuitry. This computer was, for 1966, absolutely at the bleeding edge of technology, in terms of its reliability, its small, robust packaging, and its inner circuitry design, utilizing chips.
Now the programming, a task not even me
ntioned in MIT’s original Apollo contract with NASA, became job number one. The number of engineers assigned to the software grew and in 1966 finally passed the number working on the computer’s hardware. In a mode that would eventually grow to be sacred among programmers, the work took on a round-the-clock schedule. Stacks of program cards piled up for overnight runs, and managers started holding “configuration meetings” on a nightly basis, just to keep track of who had changed what in each segment of the Apollo computer program.4
It was an incredibly stressful time for the MIT Instrumentation Lab engineers. NASA managers “descended on us” in Cambridge, Massachusetts, one engineer later recalled. The NASA task masters emphasized that perfect was the enemy of good, that if they were to meet their deadlines, the software would simply not be as good as it could be. It wouldn’t beautifully manage fuel supplies and wouldn’t achieve a perfect textbook orbit around the Moon—just an orbit that wouldn’t kill the astronauts. Management pushed them to turn out version after version of the Apollo software that, as one engineer recalled, “was just so lousy, so full of bugs.”5
Finally, engineers had to decide where and how to store the computer program on a spacecraft. There weren’t many options at the time that were space-worthy. Whatever held the computer program, it had to be completely reliable, 100 percent of the time, no matter how the spacecraft might shake or tumble, no matter if it was hit by a heavy dose of space radiation or extreme temperatures, and so on. At the time, an increasing amount of software and data storage relied on reels of magnetic tape, but these were too delicate for the long Moon missions. Extreme temperatures and a blast of cosmic rays could corrupt or erase the tape, and reading the program would require motors to wind and unwind it. Extra motors, even small ones, meant more things that could leak or break.
The Apollo Chronicles Page 17