原创 Calculating trajectories for Apollo program

All of my work on Apollo came in a frenetic four-year period, from 1959 through 1963. It was in 1959 that I began work for the Theoretical Mechanics Division at NASA, at Langley Research Center. This was just shortly after NASA was formed. Shortly after I arrived there, a paper came out of the think tank, Rand Inc., describing a class of lunar trajectories called free-return, circumlunar trajectories—the now-familiar figure-8 paths. It was immediately obvious that this class of trajectories was the only reasonable way to go to the Moon and back. We began studying them intensely, using first a two-dimensional simulation of the restricted three-body problem, and later a 3-D, exact simulation.

In those days, we didn't have spreadsheet programs to draw graphs for us; we had to draw them ourselves. As low man on the TMD totem pole, I got elected to run parametric studies on the computer and plot the results. That task worked in my favor, though, because I gained an understanding of the physics of the problem and the relationship between parameters that I don't think I would have gotten, otherwise. I wasn't content to just make runs and plot curves; I wanted to UNDERSTAND what was going on, and I think that put us ahead of the Rand guys.

"After lifting off from the lunar surface, the lunar module made its rendezvous with the command module. The Eagle docked with Columbia, and the lunar samples were brought aboard. The LM was left behind in lunar orbit while the three astronauts returned in the command module to the blue planet in the background. (NASA photo ID AS11-44-6642)." -- From Apollo 11 mission, July 20, 1969; photo courtesy of NASA from 30th anniversary site

I pretty much designed the parametric studies. Our group, the Lunar Trajectory Group, was small. Our group leader, Bill Michael, gave me the assignment, and he and I talked daily. But he never had to tell me, Ok, run this trajectory ... now run that one. I was the one making the day-to-day decisions. Bill designed the computer program but neither of us built it. In those days, things were still done "closed shop," and someone from the computer division wrote the code. But I did what would now be called desk-checking, checking the code (in IBM 702 assembler) to make sure it was right.

Later, I did a sensitivity study, plotting the sensitivity of final to initial conditions. Nowadays, we'd call that a state transition matrix, but we didn't know that term, at the time.

My boss and I published a paper in 1961, which was the second paper published on circumlunar trajectories. We also developed quite a number of rules of thumb, approximations, and "patched conic" methods that allowed us to study circumlunar trajectories without spending tons of money for computer time.

Steering
At the time, we weren't thinking of Project Apollo. In fact, I had never heard of it. We had plans to send a "Brownie" camera around the Moon before 1965, using NASA's solid-fuel Scout research vehicle. When Scout's projected payload at the Moon went from a few hundred pounds, through zero and negative, those plans were abandoned. However, the effort left us more than ready for Apollo when it came along.

Next, I began studying the problem of steering the spacecraft, i.e., midcourse corrections. We were all pretty dismayed by the great sensitivity of the circumlunar trajectory to errors in initial conditions, and we knew the accuracy of the Scout boost guidance was orders of magnitude too low. Midcourse guidance would be essential. To my knowledge, my work on that topic was one of the earliest done, though I suspect the fellows from MIT, like Richard Battin, were studying the same problem. In fact, it was Battin's seminal work, seeking a midcourse correction scheme for Apollo, that helped make the Kalman filter practical.

During this time, I also discovered a family of trajectories that were relatively insensitive to injection errors. These trajectories had a nominally vertical reentry. You see, for orbits as highly elliptical as translunar orbit, the perigee is almost totally a function of the angular momentum. The requirement that we return with essentially the same angular momentum as the original orbit implies that the passage past the Moon should not alter that momentum. To achieve this result requires very tight guidance.

The required angular momentum, translated to velocity at the distance of the Moon, works out to be around 600 f/s. This should not be altered if we expect to achieve the kind of grazing entry required for a manned mission. Suppose, however, that we design an orbit that leaves the Moon with zero velocity. Then it should reenter the Earth, with a vertical entry—fatal for astronauts, but not for instruments. Even if our errors impart as much as 600 f/s of unplanned velocity, we will still enter the Earth's atmosphere and land, somewhere. If you don't care where, this peculiar class of trajectories allows one to fly to the Moon and back, even with the crude guidance of the old Scout. Of course, the mission never flew, so the trajectory is now nothing more than a footnote to space history. But an interesting one, nevertheless.

In 1961 I moved to General Electric in Philadelphia, where they had landed a study contract for Apollo and were also planning to bid on the hardware contract. I was responsible for all the generation of nominal trajectories for those efforts. I did similar stuff for lunar missions that never flew or flew with radically altered plans; the names of projects Surveyor and Prospector come to mind.

I think I did some of my very best work at GE. Generating a lunar trajectory is not easy. The problem is a two-point boundary-value problem, complicated by the fact that both points (the launch and return sites) are fixed on a rotating Earth, and we have the "minor" midpoint constraint that the trajectory come somewhere near the Moon. We quickly learned that simply trying to guess at suitable launch conditions was a hopeless venture. Therefore a large part of my energies went into building quite a number of patched-conic approximations, programs to solve the complicated spherical trig, front-end and back-end processors, and "wrappers" for GE's N-Body program. My crowning achievement was a fully automated program that required only the barest minimum of inputs, such as the coordinates of the launch and landing points, plus a few other things such as year of departure, lunar miss distance, and lighting conditions at both the Moon and Earth reentry. The program would then seek out the optimal, minimum-energy trajectory that would meet the constraints.

I was also asked to study the problem of returning from the Moon to the Earth. Thanks to my experience with approximate methods, I knew exactly how to do this: Give the spacecraft a tangential velocity of about 600 f/s, relative to the Moon. From that desired end, it's fairly easy to figure out what sort of launch one needs at the Moon's surface. We generated quite a number of trajectories, both approximate and exact, that effected the Moon-to-Earth transfer. As far as I know, they were the first such studies ever done.

During this same period, I was developing a method for computing nearly parabolic orbits. The classical two-body theory upon which all approximate methods are based has three distinct solutions, depending upon whether the orbit is elliptic, parabolic, or hyperbolic. The equations for the elliptic and hyperbolic cases all go singular for an eccentricity of one. Unfortunately, that's exactly the kind of orbits involved in translunar missions. It drove both the computers and their programmers crazy, trying to solve problems so close to a singularity. I developed a set of power series solutions based on Herrick's "Unified Two-Body Theory." Though Herrick's original formulation was unsatisfactory (his functions required two arguments), it was a rather short step to replace them by new functions that used only one argument. Between 1961 and 1963, I published quite a number of papers on these functions, most of them internal to GE and widely distributed within NASA. I was also busily putting them to work in trajectory generators. Unfortunately for me, I never managed to get credit for them; you'll find them today in astrodynamics texts, called the Lemon-Battin functions.

In 1963 I spent nine months at GE's Daytona Beach facility, studying the problem of how to abort from the lunar mission. At first glance, you might think nothing much can be done; once zooming toward the moon, you're pretty much committed to continue. However, out near the Moon, the velocity relative to the Earth is rather low, and you have tons of available fuel for maneuvering, thanks to the need to enter and exit lunar orbit. Therefore, it's theoretically possible during some portions of the mission to simply turn around and head back for Earth. In other phases, you can lower the trip time quite a bit, by accelerating either toward the Moon (to hasten the swingby) or toward the Earth. In my studies, I discovered yet another class of returns, in which you make no attempt to slow down, but simply deflect the velocity downwards enough to graze the Earth's atmosphere. Aerodynamic braking does the rest.

All these abort modes ended up designed into the missions and programmed into the Apollo flight computers. Two of them—accelerating toward the Moon on the way out, and toward the Earth on the way back—were used to reduce the life-critical flight time during Apollo 13. If you watch the movie of the same name, you'll hear discussions of Fast Return and Free Return trajectories, both of which I had a hand in designing.

The computers
Most of our work was done on the IBM 70x series, from 702 through 7094. Later in the Apollo era, we had Univac 1108s and 1110s, and the CDC 6600. None of them, of course, could hold a candle to the modern PC with Pentium processor. I think their cycles times were all around a microsecond, which is equivalent to a 1MHz clock speed; not even up to the smallest microprocessor of today. Memory was via magnetic cores, which were even slower. The IBM's had a maximum of 32K RAM (but 36-bit words, not bytes). Nevertheless, the later processors, notably the Univacs and CDCs, were no slouch. Both had hardware floating point and long word lengths (CDC's words were 60 bits long), so one could do some serious number crunching.

Despite their low performance, on paper, we got a lot of work out of those old machines. For those used to waiting 15 seconds for a Windows spreadsheet to even load, it's difficult to imagine how much work a 1MHz computer can do when it's running full tilt in machine language, not encumbered by bloated software, interpreted languages, and a GUI interface. I'm old enough to remember, and look back on those days wistfully.