13 Minutes to the Moon: 5. The fourth astronaut

47m

How a briefcase-sized computer, less powerful than a smartphone, pioneered space tech for the first Moon landing. Astronauts Neil Armstrong and Buzz Aldrin rely on the software to guide their spaceflight to the lunar surface. Developed by a pioneering team of programmers, including trailblazing scientist Margaret Hamilton, the Apollo Guidance Computer helps usher in the digital age.

Hosted by Kevin Fong.

Starring:
Ramon Alonso
Elaine Denniston
Charlie Duke
Don Eyles
Eldon Hall
Margaret Hamilton
Dan Lickly

Theme music by Hans Zimmer for Bleeding Fingers Music

#13MinutestotheMoon
www.bbcworldservice.com/13minutes

Listen and follow along

Transcript

This BBC podcast is supported by ads outside the UK.

At Larsen, we've perfected storm doors, like the Larsen 60 Maximum View with Surelatch.

It's a guardian, keeping your little escape artists securely inside.

The Defender, protecting against what you don't want, with the most secure, first-ever magnetic latching technology.

When you hear, you know your 60 Maximum View is secure with Surelatch.

Larson, it's not just a a storm door.

Find us in aisle or learn more at larsondoors.com/slash Surelatch.

A happy place comes in many colors.

Whatever your color, bring happiness home with Certopro Painters.

Get started today at Certapro.com.

Each CertaPro Painters business is independently owned and operated.

Contractor license and registration information is available at certapro.com.

Hey, everybody, hang tight.

Seven and a half minutes.

Flight guns is landing radars radars, fixed to velocity's beautiful fraud.

You're about to hear a crucial moment in the 13 minutes before the landing of Apollo 11.

Right now, Eagle, carrying Armstrong and Aldrin, is coming up on eight minutes into its powered descent, taking them towards the surface of the moon.

At this point, Armstrong and Aldrin can't actually see the moon.

because the lunar module is flying sideways across the lunar surface.

And inside, the astronauts are lying on their backs, looking through a pair of small triangular windows at the star-filled skies above.

Right now, someone else, or rather, something else, is in the driving seat.

When they say P64, they're talking about a program that's running on the lunar module's remarkable onboard computer, which at this point is doing all the flying.

Here's Charlie Duke telling us what that felt like during his landing on Apollo 16.

You're coming down, this computer's flying it, but you don't see the moon because the windows are pointed up at space.

So at 2,000 meters, 7,000 feet, the vehicle pitches over into landing program, and you can see the landing spot for the first time.

And the computer told you, if you don't do anything, you're going to land at this spot.

664.

Okay, they got 64.

The astronauts are amongst the best pilots of their age,

but without the lunar module's unique computer and elegant programs, landing on the moon would have been impossible.

We choose to go to the moon.

Cap Conworld, go for landing.

Eagle Houston, you're go for for landing over plus two feet.

Commission on the 1203 program alarm.

Hold at that 18-foot.

We're going to make it a thing.

Roger.

Low level.

60.

60 seconds.

We've had shutdown.

We cut you down, Eagle.

Tech quality base here.

The Eagle has landed.

The mythology that surrounds Apollo 11's landing has often returned to the idea that Armstrong, the cool-headed test pilot, rescued the mission when technology failed.

But this heroic retelling overlooks the essential role played by Apollo's onboard computer.

About as big as a couple of shoeboxes and weighing 30 kilos, the Apollo guidance computer, built and programmed by the team at MIT, was the world's first digital, portable, general-purpose computer.

The landing was the most challenging because it was the point in the mission where the computer was being called on to do the most.

I look at Apollo 11 as

the first time man walked on the moon.

I looked at as the first time software ran on the moon.

In this episode, I'm going to talk to the architects of this revolutionary technology about how they took their idea from the drawing board to the surface of the moon and with it saw in the dawn of the digital age.

I'm Kevin Fong, and from the BBC World Service, this is 13 Minutes to the Moon.

Episode 5.

The fourth astronaut.

I therefore ask the Congress above and beyond the increase.

Let's jump back briefly to 1961, to the beginning of Project Apollo and Kennedy's momentous speech to Congress, declaring his ambitious intent to set sail on this new ocean of space.

We propose to accelerate the development of the appropriate lunar spacecraft.

We propose to develop alternate liquid and solid fuel boosters, much larger than any now being developed.

Rockets and spacecraft alone aren't enough to get you to the moon.

You first have to know where to point them.

David Bindell is the author of Digital Apollo and a professor of aeronautics and astronautics at MIT.

The basic enabler for Apollo was the Saturn rocket.

Without that, Kennedy never would have made his famous goal-setting statement.

And in some way, one of the crucial, as yet undeveloped, pieces was the guidance, navigation, and control.

Getting it to orbit was more or less understood, but how you fly it to the moon, you know, people had thought about the basic physics of it.

They seemed like that pretty much worked.

But getting from a kind of basic architecture to actually how are you going to do it was very much still up for debate.

And how you navigate, just like ships crossing the the ocean, was

a huge challenge and a very important part of kind of tying all of that together.

The first contract let for the whole Apollo program was the contract to do the guidance navigation system.

It was only a month or two after Kennedy's speech.

And so there's a recognition there that guidance is critical.

But how do you find your way to the moon across uncharted, featureless space without magnetic poles or recognizable landmarks or maps to guide you.

You're in a place where there isn't even a sense of up or down, let alone north or south.

So, how do you do all of that with only 1960s technology at your disposal?

This was the challenge laid down by NASA's Contract 1, the first contract of the whole Apollo program, and it would be met by the team at the MIT Instrumentation Lab in Cambridge, Massachusetts, who featured in this 1965 TV show, Science Reporter.

These test engineers are checking out a sophisticated collection of telescopes, gyroscopes, and electronics for Project Apollo.

This guidance and navigation system will be mounted in an Apollo spacecraft to aid our three astronauts on their voyage to the moon and return.

The miniaturized computer at the very heart of this system.

Most navigation systems rely entirely on making observations of the world outside.

But there's an alternative, a method for finding your way by precisely measuring time and sensing your acceleration.

That technique is known as inertial navigation.

Inertial navigation is a technology that says if you know where you start and you know how fast you're moving and what direction you're moving, then you always know where you are.

Deborah Douglas is the director of collections at the MIT Museum.

She's going to explain how inertial navigation works.

Now grab your popcorn.

Think of those bad B-grade movies where the hapless kidnapped victim is thrown in the trunk and taken to the lair of the criminals, but escapes and goes to the police and says, Well, I was kidnapped on this corner and thrown in the trunk and I counted to 50 and then we turned left and I counted to 173 and so forth.

And that story is the story of inertial navigation.

And so whether you're launching a missile or a spacecraft, if you know exactly where you start on the planet in the universe, and you know the rate of speed of your vehicle, and you know the direction that it's going in, then you know where you are and how to hit your target.

And this problem had already been partly solved, but for the purposes of destruction rather than exploration.

Polaris, the missile that's fired from underwater, wonder weapon of even this miracle age.

Atomic submarine Washington put to sea with two Polaris aboard, ready for In the nuclear arms race with the Soviet Union, the United States had developed self-guiding ballistic missiles that couldn't be thrown off course by external influences like radio jammers.

The missiles contained finely calibrated sensors, gyroscopes and accelerometers which continually monitored the missile's direction and acceleration.

So at any moment in time, the missile knew precisely where it was, where it was headed and how fast it was traveling.

That information was fed back to a primitive computer that could adjust the missile's thrusters and keep them on course.

The National Broadcasting Company and the American Association of Colleges for Teacher Education present Continental Classroom, a course in physics for the atomic age.

This inertial guidance system had originally been developed by Maverick engineer Charles Stark Traper, who founded the MIT Instrumentation Lab.

The subject for today is guidance.

It's inertial guidance in particular, but before we get into the particular end of the game, I would like to define the subject before us.

The story of the MIT Instrumentation Laboratory begins actually back in the 1920s and 30s when a young man, Charles Stark Draper,

happened into MIT from California.

He'd been a recent graduate of Stanford University, came here and accidentally found himself becoming the world's leading expert in aircraft instrumentation.

Draper was by all accounts an extraordinary man.

A hugely successful inventor, he applied scientific instrumentation to flying and guidance during the Second World War.

He was always trying to push the boundaries and was so dedicated to helping Kennedy land a man on the moon he even volunteered for the astronaut program, but was politely turned down.

Draper's speciality was precision, reliability, and miniaturization.

After Apollo, the instrumentation lab separated from MIT and became Draper Laboratories.

Seamus Tui is their director of space systems.

Before Doc Draper came along, a lot of people knew the math and they knew the theory, but the practical application of building sensors of such precision to be made useful was something that Doc is credited for.

To be able to take that performance and reduce it down to the size that made it practical to put into the early flight control systems, including Apollo, was the big reason we got the contract.

Draper was exactly the man that Project Apollo needed.

But NASA's contract only described the vast problem they faced.

Finding a solution would demand not just precision instruments that could sense the vehicle's motion, but also a new kind of computer to bring that information together and use it to control the spacecraft.

A computer of a kind that the world had never before seen.

But by the mid-1960s, plans for this complex guidance and navigation system were still firmly on the drawing board.

So imagine you're like in a classroom in the mid-60s, and you're seeing the diagram which described really the world's first digital flight control system.

Up to that point, all the spacecraft and all the airplanes were moved by people pulling on levers and flipping switches.

You would pull something that would go through a pulley system to move.

You would use hydraulics to directly open valves.

Apollo couldn't afford that because of the weight.

So what they decided to do was, with the advance of electronics, was to actually have a flight computer fly the space vehicle.

First time it's ever been done.

But because of that, they had to figure out, okay, how is that computer going to communicate to all the different subsystems?

How would the computer command a valve to open?

How would a computer, you know, command something to happen on the spacecraft, turn on an engine, turn off an engine, redirect the engine.

And one of the things I find amazing about this is this is design in process.

It's got a date on the board there.

It's 24th of June 1964.

And this is the state of our understanding of what computer technology is going to look like to enable this mission at that time.

It's kind of like being there at the creation.

I mean, you can actually see where people went up and erased things with their hand as opposed to using a proper eraser.

You can imagine they would have arguments about what goes where, who does what.

And this is 1964.

So this is the drawing board.

I mean, this is literally the drawing board.

And to be honest with you, looking at the mess on the board in front of me and all the lines going in all these different directions and the clear rubbings outs and the corrections, it is not, it is not a plan that I would be happy to fly into space with.

Nevertheless, MIT took that audacious design and ran with it.

The scroll on that massive blackboard was turned into a few sheets of paper and a formal blueprint.

And as David Mindel explains, it wasn't just the design that had to be radically reduced in size.

I often talk about Apollo as the moment where people stopped bragging about how big their computers were and started bragging about how small they were.

You know, at the time a digital computer was something the size of a building that had its own fire department, its own air conditioning system, and the fact that it took umpteen kilowatts or megawatts of power and and that was how you bragged about it.

And then afterward it was that moment where people started to say, oh, you know, they're more valuable when they're small than when they're big.

The fact that Apollo had not just a digital calculator, but a digital computer was radical.

But in the 1960s, what did radical look like?

Oh, I'm Elvin Conrad Hall.

In Digital Apollo, David Mindel describes Eldon Hall as a lanky Idaho farmboy with a keen interest in electronics.

But this led him to greater things.

Hall had worked under Doc Draper on the Polaris project.

Later, he was brought in to lead the team that would design and build the computer hardware for Apollo.

His greatest engineering challenge was trying to shrink a computer from something the size of a room to a device not much bigger than a couple of shoeboxes.

But as team leader, he had another obstacle, convincing NASA that a computer could be relied upon in the first place.

Back in those days, nobody trusted computers.

All of the commercial computers would only work a few hours or maybe a few days without repair.

So the major problem at that period of time was reliability.

Because nobody believed that you could have a computer work for a couple of weeks like we had to have for these missions.

So I would say that was the major problem right then.

Not only achieving the reliability, but convincing the naysailers that could be done.

It was a joy to find Eldon Hall living out his retirement on the edges of Florida.

At 95, he's revered for his courage and foresight as much as he is for his genius.

Because to meet the challenge of making a computer small enough to fit the Apollo spacecraft, Hall decided to risk everything on an emerging and unproven technology, integrated circuits, a predecessor of the silicon chips that we all take for granted today.

We bought thousands of those things and put them in the very first computer that was built with integrated circuits.

And I mean, in 1962,

integrated circuits built with semiconductor technology is four or five years old.

It's only really been demonstrated to be possible in the late 1950s.

It was in the laboratory, but they hadn't built it for the market yet to sell any.

The first step I had is to convince NASA to let us use them.

Now fortunately, the program manager at NASA was stupid enough to say you can go ahead and do it.

He was probably the only program manager in NASA that would have said that, but he gave me permission to do it.

And now looking back, does it not strike you as stupendous, really, that they would take a risk on this uncertain, brand new technology?

Right, right.

I couldn't believe, sitting here now, I couldn't believe anybody would

want to take that risk.

And did you at the time feel the enormity of that decision, that you were committing Project Apollo to a decision that would ensure the success or the failure of that mission?

Well, yes.

But I felt also there was no alternative.

We wouldn't be able to get a computer with enough computing capacity without that technology.

If anything happened that this computer with integrated circuits fell on its face, then they just wouldn't be there.

Maybe we wouldn't get to the moon.

If you're looking for a legacy from Apollo, there are many to choose from, but I've come to think of this as one of its most significant, with NASA poised to incorporate a digital computer as an integral part of their mission design.

Apollo bought

60% of the total output of chips made in the U.S.

during the peak of the program.

60%.

That's an enormous boost to a kind of new and unproven technology.

It was a key moment where the companies that were making chips were able to show, look, the most important, most life-critical, most difficult, challenging program in the whole United States is using our stuff.

That's an enormous boost to what then became the basis for the entire computer industry in this country.

But the hardware was nothing without a set of instructions to tell it what to do.

Good hardware needs good software.

But if you examine NASA's original contract, astonishingly, software appears to have been an afterthought.

You know, one of the amazing things about the Apollo guidance contract, which again is the first contract left for the whole Apollo program, is that, A, it's only 10 pages long.

Today it would be 10,000 pages long.

But it actually doesn't even mention the word software.

It's not invented yet.

And there's one line that says, of course, the MIT Instrumentation Lab will create the programs necessary for this

computer to work well.

By 1967, they're at a point where, oh my goodness, this software thing is really complicated, it's really expensive, there's a lot of bugs in it, and we might not make the end-of-the-decade deadline because of the software.

And we didn't even know what software was when the program started.

And so it really is the kind of first time that software rears its head as

something in and of itself that's worthy of paying attention to, that's complicated, that's expensive, that can make something happen that can't happen otherwise, and can kill you if it goes wrong.

For the development of the software, NASA would need to call on the skills of a new breed of scientists.

Responsible for authoring the thousands of lines of computer code that the astronauts' lives would depend upon, these programmers would prove to be some of the most brilliant and creative people in the entire space program.

Margaret H.

Hamilton is what I, if I sign something,

but I'm Margaret or Margaret Hamilton.

Just tell me

what was your job title during Project Apollo?

I started off as a programmer and ended up as being in charge of the onboard flight software for the LEM and the command Module.

Margaret doesn't give many interviews and so it was a great pleasure to be able to talk to her about what the embryonic field of computer science was like in 1964 when she joined the project.

Most of the Apollo space program revolved around a culture of regimented structure, protocol and procedures.

But in the 1960s the world of software was like the Wild West.

There were no rules.

There was no field for what we did.

When the people would interview you at the time, they would ask you if you knew the language on their computer.

If you did, you almost had a job.

To me, it was like saying, do you know these English words?

And it's like saying, oh, okay, you have a job writing a novel.

I just thought that was a really strange way of thinking people qualified.

And people would go around and use terms like the term software.

Nobody knew what software was.

Not even people who were some of the people doing software.

There's no way to describe it to people like family members.

What is that, right?

Equally impressive and fascinating was the character of Don Isles.

Another programmer, he almost stumbled into a key role within the Apollo program aged just 23.

Sunshine came softly through my

window today.

I was one of the people who programmed the onboard computer in the lunar module.

I did not take computer science in college.

I'm not sure I could have.

I was a math major, but not a very good one.

So at that point, I was sort of a bedraggled graduate wondering what he was going to do next.

I joined the program fairly late in the middle of 1966 when a great deal of the software for the command module had been written and a lot of the sort of tools in the way of the simulators and the operating system were in existence.

But at that point the application code, if you will, for the LIM, the part that actually flew the different mission phases, was just starting up.

And so I was lucky enough or unlucky enough to be assigned to work on the lunar landing phase.

How did that feel to be programming the onboard computer for Project Apollo?

It must have seemed like an enormous opportunity.

I think it seems that way more in retrospect.

You know, at the time I was happy enough to have a job.

I don't know if I ever said to myself, goodness, this is awesome.

Compared to the starch shirts and ties at Mission Control, the coders in Cambridge were free spirits.

It was a very unregimented, very free sort of environment.

I think they realized that to accomplish the task at all, they needed to give us the freedom to take the initiative.

I've heard stories, and I'm not sure if they're true, that

you were working on Project Apollo, but you might as easily of an afternoon when you weren't working be protesting against Vietnam.

Is that right?

Well, I wasn't the only one, but yes, that was the era when we were protesting against Vietnam.

Sometimes, you know, I was tear guest.

Yeah, they were somewhat tumultuous times, and I was part of that, too, in a limited way.

In his Apollo memoir, Sunburst and Luminary, named after the programs he wrote, Don Iles details how he created the landing software to run on this simple yet incredibly efficient machine.

The AGC, the Apollo Guidance computer, took up one cubic foot.

Well, I think it weighed 70 pounds, complete 55 watts, if I remember the number correctly.

It had, in terms of memory, the equivalent of 76 kilobytes.

In modern terms, that was in the form of 16-bit words.

And of that 76 kilobytes, only four kilobytes was random access memory, read-write memory.

The rest was a very durable, reliable form of hardwired memory.

It's fashionable for us today to marvel at how incredible our modern computers are and how puny the Apollo guidance computer was in comparison.

But it's not a fair comparison.

If you plugged your laptop or phone into an Apollo vehicle on the way to the moon, for any number of reasons, it probably wouldn't be up to the task.

Mission success success depended directly on every single person involved in the Apollo program, from computer architects and programmers to the people firmly on the front line, managing the more mundane task of turning these grand ideas into physical reality.

It was the mid-1960s and computing was still a laborious process.

Once written, the code was printed out onto reams of paper and then translated into punch cards that could be read directly by huge mainframe computers on the ground.

All of this had to happen before the programs could be tested and made ready to be incorporated into the compact Apollo guidance computer on board the spacecraft.

Dan Likely was a senior programmer in this long chain of production.

We got to the moon using punch cards.

People today can't believe it.

It was all done with punch cards and key punches and put a batch of cards and ran it through a card reader into those big IBM computers.

And there were over 100 people working at it on the end.

They had to all integrate their cards and put them together and submit it in one big run overnight.

And then we'd run the simulations the next day, sure whether it was good or not.

And there were two women who worked on them.

My name is Elaine Denniston.

I went there as a temp, a temporary employee.

In those days, we had a company called Kelly Services.

So I was a, quote, Kelly girl.

And I was hired to Key Punch.

And then after a certain period of time, and I have no idea when, they kept me on and hired me as a full-time employee.

Elaine Denniston's job was to turn the printed lines of computer code into punched cards.

These were literally stiff cards about the size of a standard business envelope with a series of holes punched into them.

It was my job to type what the programmers gave me, type it into these cards.

So you would type up what they had written onto a card and then the cards would be collected.

And of course these prima donna programmers would be late, I got to do this over, give me another half hour and so on and so on.

So she had to go around at night before she left and beat up on all these programmers and get their information, run it, make sure there were no errors in it and then turn it in for the overnight run.

You know, after I'd been at the job for a while, I could spot certain patterns and I know if you had a left parent somewhere, somewhere there had to be a right parent or there should have been a period at the end of some string of numbers.

That's what I spotted.

And when I saw those, I would actually go back to the programmer and they look at, oh yeah, thank you.

But I was persistent and I would haunt them.

H-A-U-N-T.

Not only was she young, she was a black woman.

who had to go around and use her weight to boss around all these prima donnas.

It's unbelievably good at it.

She was very, very good.

She had a wonderful personnel and she was really smart.

I liked most of them.

Most of them were pretty nice.

They were very, yeah, they were thankful.

They did not say, who are you to tell me?

They did not do that.

They were thankful to have it because if the code wasn't right, then the program wouldn't go.

Getting the code right was vital, but making sure that the code was translated translated correctly into these punched cards was equally important.

The trick here was to trap errors on the ground so that the astronauts didn't have to face them in space.

And once all of this was done, the software was ready to be uploaded into the Apollo guidance computer.

Now I say uploaded, but it wasn't anything like as straightforward as that.

Let me introduce you to the remarkable idea of core rope memory, a form of computer memory which had to be woven into the spacecraft.

Literally, David Mindel.

The core rote memory worked in a way where there are these things called magnetic cores, and they're like little tiny, barely even visible doughnuts of magnetic material.

The software was literally woven into the cores.

If a wire went through a particular core, that represented a zero, and if it went around the core, it represented a one.

And we're sitting here today in Waltham, Massachusetts, which is the cradle of the textile manufacturing industry in this country.

And this is the town that the Apollo computers were manufactured in by former textile workers because the software for Apollo was hardware that was literally sewn into the structure of the computer manually, by hand, with computer aid.

The thing you have to realize about the rote memory is it was a proven technology at the time.

And if you're taking your spacecraft to the moon based on these weird abstract things called computer programs, where are they going to live?

So the core memory played this tremendously important role in making that system just absolutely bulletproof robust.

Making things bulletproof became Margaret Hamilton's focus.

She recognized that nothing could be made perfect, that there would always be errors and mistakes, and that she had to find a way of dealing with them.

Out of this obsession emerged a new discipline that Margaret Hamilton is credited with inventing, software engineering.

I began to get fascinated by errors because there were no tools for finding them.

They almost didn't exist like they do now.

We try to understand the errors and find new ways not to let them ever happen again.

That's part of software engineering.

Finding a way to develop a system to write software so that it would be reliable.

You know, this is software upon which people's lives will depend.

And so as a coder, you're sort of slightly abstracted from the business of flying flying the vehicle, but did you get a sense of that, you know, people's lives are in my hands, or at least in the hands of my code?

Absolutely.

Especially when it came to worrying about the manned missions.

A person's life was at stake.

The astronauts' lives were at stake.

And that's when I began to worry about everything working together and what the astronaut might do by mistake, what would happen as a result of hooking up the wrong radar, the radar in the wrong position, could affect the software.

How do you let him know it when he's busy doing his stuff and he doesn't even notice that there's a problem?

So it became a mission.

So was your role a little bit like, you know, the conductor of an orchestra to make sure that...

Yes.

It was like that.

It's just bringing all the pieces together at the right time so they have their function.

Otherwise, if they're coming at the wrong time, it can just wreck the whole piece.

Wrong time, wrong priority, wrong data,

interface errors.

Those are the big three.

The interface on a modern computer is so seamless that you barely notice it.

We take for granted our keyboards and touch screens.

Today we can even talk to our computers.

But 50 years ago, none of that existed.

To see the Apollo guidance and navigation system in operation, we visited the system's test laboratory and talked with Mr.

Ramon Alonso, assistant director of the instrumentation laboratory.

One of the interesting aspects of the guidance system is the way in which the astronaut controls the guidance equipment through the computer.

Back then, no one was sure how humans should interact with a computer in a real-time application until Ramon Alonso, a gifted mathematician at MIT, came up with a surprisingly simple scheme he called Verb and Noun.

The system of codes used is

reasonably simple, consists of a numerical verb and a numerical noun.

These are little sentences made of numbers, then?

Essentially, if you straight a bit...

Nice to see the old

horse again.

When was the last time you saw this Ramon?

Oh lord, maybe in this early 70s somebody there were still some around.

The interface resembled a giant calculator with huge buttons.

But as Ramon Alonso told me, when we reunited him with the computer he'd worked on 50 years ago in the basement of the MIT Museum, there was a reason for that.

We had a problem, we had to solve it.

The astronaut had to be able to see the

lettering on the computer, whatever they had to interact with, through the visor.

And the buttons had to be big enough so they could push them with enormous gloves.

There were all kinds of constraints like that.

One day coming into work, it occurred to me that if I wanted to say do something, how would I say that?

Do something, all right?

Verb and noun.

It couldn't have been simpler.

Verb, what do you want to do?

Noun, what do you want to do it to?

With this crude vocabulary, users could give the Apollo guidance computer different instructions and run a range of programs.

And pretty soon, a funny thing began to happen.

People say, hmm, very interesting.

Yes, we're good.

Are you going to leave this verb and noun the way it is?

Not up to us.

There's another group that's going to do that.

Yeah, but you can't leave verb and noun.

Why not?

Well, it's not military enough.

It's not serious enough.

It's not scientific enough.

You had a lot to do with the astronauts through this project.

What did you think of them?

What did you make of them?

I thought one group was very, very, very smart.

I didn't think so much of the other one.

I thought they were dumb, frankly.

However, they were all charismatic and surviving test pilots, 40-year-old surviving test pilots.

You don't get to be a surviving test pilot at age 40 without having done a lot of things right or being so lucky that you're off the chart.

And one of the astronauts,

when given the tour of the computer, said, you know, the first thing we're going to do when we're up there is turn the sucker off.

We're pilots.

We fly things.

We don't have things fly us.

But at the same time, it was also the fact that they wanted to go to the moon.

And And they didn't care what they had to do to do so.

And so they were the right warriors.

And there's no question that they were the right people.

One of those warriors was astronaut Charlie Duke.

Well, it was a simple little keyboard.

We had three digital readouts, but no text.

It was all just numbers, three sets of numbers.

And you had to know what P64 verb 1092 was.

You know, that noun-verb combination is rate of descent, forward velocity, and altitude.

It was a crude little system,

but it worked.

So here we've got the keypad, which is just numbers 0 through 9, plus and a minus.

And then on the left, it's...

Back at Draper Labs, Seamus Tue, let me have a go at playing astronaut on one of the original Disky interfaces that Ramon Alonso had designed.

So let's say you were in lunar orbit and you're safely there and you want to start initiating the lunar landing guidance algorithm, which was 63.

That was the noun number attached to it.

So what you would do is you would press down.

Noun.

63.

Enter.

Enter.

So that tells it that's the program you want to run.

Well, when do you want to start?

You want to start in 15 seconds?

Yeah, why not?

15 seconds.

Then you would say verb.

Verb.

15.

15.

Enter.

and then a clock would start tick tick tick tick tick uh start ticking down and at when it ran to zero the computer would then initiate program 63 which would in this case do a very large braking burn to slow you down so you start dropping down to the surface of the moon and that's the beginning of power descent that's the bigger beginning of power descent so noun

enter verb 15 for that enter look i've

so overrated this flying the apollo capsule thing minus 0.2 minus 0.7.

And we use the things 986 for Delta VZ, which is 9.5.

And this is how the astronauts flew to the moon.

In the final 13 minutes of descent, Armstrong and Autron were very often in the hands of Alonso, Iles, Hamilton, and their co-workers, dependent on programs that fired thrusters and rocket engines, precisely controlling their speed and direction of travel right until the moment of touchdown.

Here's Charlie Duke talking about what that was really like.

Okay, we're off to a good start play school.

We were almost on target, a little west and a little north, and the computer told you if you don't do anything, you're going to land at this spot.

54 LPD dropping out the bottom now.

800 feet, 30 down.

Being Houston, we're going to be just a little off.

But we're just now being

double spot.

But all it knew was how high you were above the moon.

It could be on a slope, it could be in a big crater,

be on top of a rock.

So you had to maneuver to get a landing spot.

So things got

really busy the last three or four hundred feet.

And I was looking out my side occasionally and we ended up

probably 200 meters from where we had intended to land and

it was

engine stop we hit the ground dead dead level and we just erupted with excitement

and I could see the I could see all the way to the ground just like flying the LTV piece of cake fantastic Percy Persegan is playing it one on the plane's a feature

How essential was that Apollo guidance computer to your landing on the moon?

Could you have done it without it?

It would have been difficult.

We practiced that.

It took a lot more fuel, but we knew that the computer was really essential.

And how strange was it for you?

I mean, you were a test pilot, you flew single-seater fighters, you used to be completely in control of your vehicle, and now there's a computer there and it's partly managing how you fly.

How strange was that for you, and how did you get used to it?

I liked it, actually.

It's so proficient with these automatic systems.

They're so sensitive and so precise.

You hate to admit it, but they do a lot better job than you do in being efficiently and getting it exactly right.

The computer was always on and always in operation.

The balance of control between astronaut and computer shifted back and forth.

It was a partnership.

But when they first conceived of the idea, says David Mendel, Doc Draper's team thought their computer would do it all.

The group at Draper who built the guidance system really felt that they could make a fully automatic landing when the program started.

They actually said, you know, the interface for this system will have two buttons.

It'll have one button that says go to moon and one button that says take me home.

And as it turned out, the interface must have had 500 buttons on it and it was much more complex and much more richly interactive.

My interpretation of Apollo certainly is that it was the first software systems where people's lives depended on it.

It was the first real-time control digital computer that was portable in that way.

And it was the first fly-by-wire system,

which means that the astronaut really didn't control the spacecraft directly.

The astronaut moved to joystick or entered numbers that went into the computer and then the computer controlled.

That's how every airliner we fly today, pretty much, modern ones, are all fly-by-wire.

But Apollo was really the first fly-by-wire, anything with a digital computer it.

The achievements of the team at MIT echo on into the present day.

And it's left its impression on all of us, not least the people who worked on the mission, built those computers, and wrote those lines of code.

People like Elson Hall, Margaret Hamilton, and Don Iles.

Did you feel the weight of the responsibility?

Because so many people were involved in this, but at that moment, with the computer so

firmly embedded in these last few seconds.

The last few seconds of the landing, yes.

Yes, I was.

I was very nervous, yes.

Did it ever enter your mind that if it doesn't go to plan, people are actually going to perhaps look back to my hardware and say it was my fault?

Yes, yes.

That always worried me, yes.

And so,

you know, when they eventually landed, once they finally confirmed they were safely on the surface, how did that feel for you?

Very relaxing when they touched down, bounced in, shut the engines down.

Do you think under ideal conditions the guidance system controlled by your computer could have landed the lunar module on its own?

We thought so.

One of the good things that happened from Apollo 11 is people knew something called software existed, and it made it seem more interesting.

They don't have to be astronauts, but they can be involved in many different ways.

Down two and a half.

I think in some larger sense, we felt we were there with them, you know, that we were there more intimately, we thought, in our own heads than anybody else was, because it wasn't just something we made was there.

it was something where we had programmed the thoughts, if you will, of this computer were there.

And by the way, that information may still exist.

You know, those limbs ended up crashing on the moon.

Whether that memory would have been durable enough to survive the crash with the information intact, I don't know.

But, you know, in a sense, I can say my work is on the moon.

Tranquility base here.

The eagle has landed.

Rocket Tranquility, we copy you on the ground.

You gotta play together.

In episode 6, we'll tell the story of what Apollo Insiders regard as the gutsiest mission of the entire program.

One that took humans away from Earth orbit and around the moon for the very first time, faster and further than anyone had ever traveled.

Apollo 8.

This to me was looking at new territory, new exploration, especially on the far side of the moon.

We don't want to just go to the moon.

We want to go in orbit around the moon.

Now, frankly, that's an order of magnitude difference in risk.

There's no way that's happening.

We were a mission-critical program and we were not ready.

13 Minutes to the Moon is an original podcast from the BBC World Service.

Today, we visited the Instrumentation Laboratory at MIT and the Raytheon Company in Baltimore, Massachusetts.

13 Minutes to the Moon is produced by Andrew Luck Baker.

Our theme music is by Hun Simmer.

Extra production and research effort is by Sue Norton and Madeleine Finley.

The series editor is Rami Zabar and the podcast editor is John Minnell.

Many thanks to the MIT Museum Collections for the use of the Science Reporter TV show.

Thanks also to Draper for the interview with Dan Likely and additional archive material.

To discover even more about the amazing team behind the Apollo guidance computer, visit wehackthemoon.com, a specially created digital portal where you'll find videos, images and stories showcasing the science and engineering behind Project Apollo.

That's wehackthemoon.com.

And thanks to everyone who posted comments and left ratings and reviews, they're much appreciated.

Keep them coming.

Our hashtag is 13 Minutes to the Moon.

That's all one word.

Don't forget there are videos, photos and documents to enjoy on our website.

That's at bbcworldservice.com slash 13 minutes.

I'm Kevin Fong.

Thank you for listening.

Hello, it's Kevin here again, and before I go, I wanted to tell you about another podcast from the BBC World Service.

Like 13 Minutes to the Moon, The Hurricane Tapes sheds new light on a story you might think you already know, but the subject matter couldn't couldn't be more different.

It centers on Reuben Hurricane Carter, a celebrity boxer who was tried, convicted and released twice for a triple murder he always denied committing.

The story became part of popular culture, inspiring a Hollywood movie and a Bob Dylan song, and our reporter Steve Crossman was fascinated by it.

And then he came across a series of audio recordings of Reuben Carter himself that had never been heard before.

Steve went on a year-long odyssey trying to track down everyone involved and piece together what really happened.

The result is the Hurricane Tapes, which is available in full for you to listen to right now.

Just search for the Hurricane Tapes wherever you found this podcast.

The Mercedes-Benz dream days are back with offers on vehicles like the 2025 E-Class, CLE Coupe, C-Class, and EQE sedan.

Hurry in now through July 31st.

Visit your local authorized dealer or learn more at mbusa.com/slash dream.

A happy place comes in many colors.

Whatever your color, bring happiness home with CertaPro Painters.

Get started today at Certapro.com.

Each Certipro Painters business is independently owned and operated.

Contractor license and registration information is available at Certapro.com.