Author Topic: Apollo Guidance Computers  (Read 124 times)

Offline Peter B

  • Saturn
  • ****
  • Posts: 1299
Apollo Guidance Computers
« on: November 03, 2024, 10:00:30 PM »
I'm involved in a discussion with one Apollo disbeliever who is claiming superior computing skills to me (his skills are likely superior, but (a) he has no way of knowing that for sure, and (b) I studied computing for a couple of years at a technical college, so I probably know a fair bit more about programming than the average person).

Anyway, he's convinced the AGC wasn't up to the job, because he thinks it was little more than a glorified stopwatch, and that it didn't have the means to control the spacecraft it was installed in.

Now, my understanding is that in the process of managing an engine burn, the computer was able to do things like throttle and/or gimbal the engine to take account of reducing mass and shifting centre of mass; and that it could keep the spacecraft pointed in a chosen direction, by firing thrusters to counteract a measured rotation? Also, that might involve firing thrusters which were at right angles to each other? Am I in the target area here?

Second, he says that, as a consequence of this, he doesn't think the LM could land itself on the Moon. Now, my understanding was that the LM could indeed theoretically guide itself all the way to the surface of the Moon, it just had no terrain avoidance system, so it might land...but on a rock or a crater slope.

Third, he talks about hearing a talk about a Hubble servicing mission. He says that on one particular servicing mission, when the Shuttle's robot arm grabbed Hubble and twisted it around, Hubble objected to the rotation, and tried to counteract it. Now, my understanding is that Hubble indeed has a mechanism to maintain its orientation in the form of reaction wheels and gyroscopes. But I would have thought it likely that if the robot arm was going to move Hubble around, Mission Control or the crew would inhibit the mechanism to avoid exactly that problem. It seems pretty unlikely that in all the planning and training for the mission, this would be missed or forgotten. But I thought I'd check this with the Brains Trust to confirm whether I'm on the mark.

Thank you!
Ecosia - the greenest way to search. You find what you need, Ecosia plants trees where they're needed. www.ecosia.org

I'm a member of Lids4Kids - rescuing plastic for the planet.

Offline TimberWolfAu

  • Venus
  • **
  • Posts: 52
Re: Apollo Guidance Computers
« Reply #1 on: November 04, 2024, 08:11:13 AM »
My understanding is that a lot of the heavy number crunching was done on Earth, with the details transmitted to the craft. It's not like they would have been performing sudden moves, everything would be well planned in advance.

Offline JayUtah

  • Neptune
  • ****
  • Posts: 3810
    • Clavius
Re: Apollo Guidance Computers
« Reply #2 on: November 04, 2024, 12:01:18 PM »
Yes, the Apollo guidance computer was what we would call an embedded controller. You don't need a lot of computing power to do that. However, for the actual argument we're going to need a lot more than, "I'm really smart and I say it can't be done." There are a lot of demonstrably smart people who very firmly believe it can be done, and can bring receipts.

First among them are books written by Don Eyles and others by Eldon Hall. But not least of all them is Curious Marc on YouTube, whose team led by Mike Stewart found an old AGC on a trash heap and restored it to function. I met him briefly in 2019; I think he probably forgot more about computer science last night over a beer than I ever knew. His YouTube channel is replete with people who have the original hardware in hand and considerable computer and electrical engineering experience. They're working from the original system specifications.

The Luminary code is out there on GitHub and there is at least one full-scale software emulator out there. If the claimant is a software guy, maybe he can tell us why P63, P64, and P65 are not up to the task. The claim, "The computer wasn't powerful enough," is typically made by people with only modern general-purpose computer experience—none in historical computer architectures and none in embedded systems. The Incredulous Expert character has been around since I started looking at these claims in the 1990s and never seems to be as smart as he claims.

I can't imagine anyone who actually knows the claims made about the AGC seriously saying it lacked the "means." It had the ability to pick off gimbal angles from the IMU. It's straightforward free-body dynamics to convert that to spacecraft attitude and compare that to a set point (9 multiplications). The mathematical foundation is a straightforward proportional-differential controller, part of industrial automation since the 1940s. The outputs are "discretes," commands to initiate and stop control moments in the cardinal directions. There was actually a separate discrete logic bank that controlled the actual jets; it could compensate for the loss of a thruster. The computer just says, "Hm, I've measured my pitch angle as being outside the hysteresis and getting worse in the up direction. Send the PITCH DOWN command to the jet logic and hold it there until the pitch rate is positive." (2 comparisons and 1 memory write, etc.) It's important to understand how many tasks were performed by custom electronics that today we would contemplate doing in software. The above is the operation of the DAP in ATT HOLD mode (one of three modes). It's an always-running task that only needs to happen every 0.1 second in order to keep the ship oriented properly during accelerated flight. It's inactive during unaccelerated flight.

The thrust program is a separate task. Its inputs are accelerometer data from the IMU and altitude data from the landing radar. The radar operates on its own and uses an interrupt to "poke" the altitude directly into the computer's memory at 800 Hz. The computer doesn't need it that frequently, but it's up to date at any given moment; the computer just has to read it. The other input (in manual mode) is the pilot's desired descent rate. The output is a single value: the actual actuator position for the pintle throttle on the DPS. I recall this runs at 10 Hz, but my memory may be fuzzy. But it's 2 comparisons and possibly one memory write.

The DPS gimbaling is a separate low-priority task. The DAP increments a counter for each direction every time it has to fire. If one counter is consistently higher than the other, this program has four outputs: screwjack motor commands in each direction along two engine gimbal axes. Here again you have auxiliary electronics that handle turning the screwjack motors on and off at the commanded chi angle. Six comparisons and possibly two memory writes.

The higher level programs P63-P66 simply feed desired set points into the higher-frequency control tasks according to either a time-based schedule or in coarse response to inputs from various sensors. These are very slow-paced operations. This is incidentally how modern autopilots work, so this isn't a strange proposition to anyone who has actually programmed flying machines (which I suspect your claimant hasn't).

P63's job is to get the LM from "high gate" to "low gate." These "gates" are simply altitude, forward speed, vertical speed, and attitude parameters that need to be met in order to transition to a new program. "Initiating powered descent" simply means pulling the trigger on P63 from orbit. P63 operates according to a physics model that prioritizes residual orbital behavior, but integrates downward ballistic behavior—orbital braking. The ship is heads-down so that the pilot can view the surface and engine facing the direction of travel to maximize braking thrust. Its input is a programmed set of desired velocity states. Its output is throttle set-point and attitude set-point. The goal is to adjust altitude orbitally and downrange position in order to arrive at "low gate." This is straightforward closed-loop control. (Most software-only people have zero experience in control theory.)

P64's job is to get the LM from "low gate" to a laterally-stationary position some 100 feet above the landing site and descending at a rate within a certain range. This program has a very coarse (one nautical mile granualarity) map of terrain variation near the landing site. So it does have terrain avoidance in the grossest sense, but not enough to avoid boulders and craters. It operates according a physics model that ignores orbital behavior and focuses strictly on ballistic physics. Its input is the programmed landing point in 2D coordinates (latitude and longitude), which the pilot may change (but doesn't have to) by using the joystick. P64 has to find the 3D coordinates (latitude, longitude, and altitude from theoretical lunar center) by interrogating its terrain map for those coordinates and estimating the local terrain variation. This is so its notion of "100 feet above the surface" isn't really 30 feet below it. It uses a bilinear interpretation method for this, but has to do it only once when the landing point is redesignated.

The ship has rolled over on its back and pitched forward (again, just a program feeding desired attitude set-points to the DAP). This lets the crew see the landing site and lets the landing radar point at the ground. The DPS is now pointing more down than forward. P64 wants to alter the descent rate and forward motion according to a preset series of conditions so as to arrive at the landing point at an altitude of 100 feet and descending at a certain rate. That's a simple set of comparisons: Am I too high? Am I too low? Am I dropping faster or slower than I should be (proportional-differential control)? Is my downrange velocity and deceleration appropriate for the time-to-go for the landing point? Because pitch angle, throttle setting, altitude, descent rate, and forward travel rate are all coupled, the program response through its various discrete set-points is non-trivial, but these are figured out ahead of time. Control laws in coupled variables are child's play for people who have actually studied engineering.

It's important to realize that neither of these programs needs to be furiously computing things at zillions of times per second in order to achieve this, just as you don't need to make micro adjustments to your steering wheel every millisecond in order to stay on the road. Most of these programs just sat and waited for the ship to cover the distance, checking every couple of seconds to see whether any of the parameters had drifted out of tolerance.

P65 is the auto-land program, which no one used but which could have been used in theory to land an uncrewed LM. In a hypothetical unmanned mission, it would have reduced the descent rate over the remaining 100 feet of altitude in order to achieve a small rate of descent, a zero lateral rate, and a perfectly vertical attitude at an altitude of six feet, whereupon it cuts the DPS. Again the DPS is doing the heavy lifting here (pun intended). P65 just sets a vertical attitude for it to hold and frobs the throttle setting up and down to maintain the proper altitude-and-descent-rate profile.

P66 was the manual landing program, which all the pilots used. The DAP switches to a different attitude hold mode but takes its set-point from the hand controller. The throttle switches to manual. This is a dirt-simple program. I suspect your claimant has a completely wrong-headed idea about what computing tasks actually needed to be done.

The scenario where ground computers are doing the heavy computing has more to do with orbital flight mode. The big number crunching was done at Lawrence Livermore lab on the CDC 6600, which was about as powerful as a Pentium 90 CPU. These intermediate results could be fed to the RTCC computers—IBM 70x and 360 series—to (more slowly) finish, and then desired orbital flight parameters can be uploaded to the AGC.
"Facts are stubborn things." --John Adams

Offline Zakalwe

  • Uranus
  • ****
  • Posts: 1597
Re: Apollo Guidance Computers
« Reply #3 on: November 05, 2024, 03:22:35 AM »
And of course the F-8 Digital Fly-By-Wire program must also, naturally, be a hoax too?







"The strain of anti-intellectualism has been a constant thread winding its way through our political and cultural life, nurtured by the false notion that democracy means that 'my ignorance is just as good as your knowledge.' " - Isaac Asimov

Offline Von_Smith

  • Venus
  • **
  • Posts: 85
Re: Apollo Guidance Computers
« Reply #4 on: Today at 01:24:38 PM »
Haven't posted in  while on this forum but:  How much more complex would AGC need to be than the guidance systems on, say, a Surveyor or Lunakhod lander? 

I guess that wouldn't matter if your skeptic is a flat-earther type who denies all space travel, but I'd be curious as to what if any the unique guidance challenges were that the AGC would have to meet that unmanned craft landing on the moon wouldn't.  Seems this would be relevant for an interlocutor who might be performing skepticism specifically reserved for Apollo.
« Last Edit: Today at 01:26:41 PM by Von_Smith »

Offline Peter B

  • Saturn
  • ****
  • Posts: 1299
Re: Apollo Guidance Computers
« Reply #5 on: Today at 03:25:55 PM »
Haven't posted in  while on this forum but:  How much more complex would AGC need to be than the guidance systems on, say, a Surveyor or Lunakhod lander? 

I'll leave it to JayUtah to comment on the consequences, but I know that Surveyors flew straight in, and only needed to worry about when to ignite the landing engines. The Lunakhods entered lunar orbit and decelerated to a landing from there like the LMs.

Quote
I guess that wouldn't matter if your skeptic is a flat-earther type who denies all space travel, but I'd be curious as to what if any the unique guidance challenges were that the AGC would have to meet that unmanned craft landing on the moon wouldn't.  Seems this would be relevant for an interlocutor who might be performing skepticism specifically reserved for Apollo.

My dude seems to be only an Apollo hoax believer, who hangs his hoax belief on both his alleged computing skills and his personal incredulity. He scoffed at the idea of engine burn parameters being read up to the astronauts and at the lack of computing power of the AGCs.
Ecosia - the greenest way to search. You find what you need, Ecosia plants trees where they're needed. www.ecosia.org

I'm a member of Lids4Kids - rescuing plastic for the planet.

Offline JayUtah

  • Neptune
  • ****
  • Posts: 3810
    • Clavius
Re: Apollo Guidance Computers
« Reply #6 on: Today at 08:33:28 PM »
Haven't posted in  while on this forum but:  How much more complex would AGC need to be than the guidance systems on, say, a Surveyor or Lunakhod lander?

Complexity is part of the solution space, but the key factor is reliability. One system is human-rated while the others are not. Since the Surveyors were never outside the realm of ground control, ground control factored into the overall plan. The automated portion used a simple slant-range computation and closed-loop control of a throttled engine. Closed loop means the throttle setting is an ongoing function of the velocity and distance along any slanty trajectory toward the surface. If a crater or a boulder happens to be there—oh, well.

For LM guidance, pinpoint landing was the goal—and scrupulously avoiding killing the crew. That means a descent from a precisely measured orbit and lots of fail-safe thinking. Computers are really good at flying orbits and nominal braking maneuvers, while human pilots are not. Conversely, human pilots are really good at avoiding obstacles they can see with the Mark I eyeball once they arrive on station. The goal was to put a human on the Moon, not just land something on it. So make that human a very skilled pilot and give him a ship that can fly itself to a point where the pilot's skills become necessary. This is why the AGC needs the different modes and is therefore more complex than the single-program automation of the Surveyor.

My dude seems to be only an Apollo hoax believer, who hangs his hoax belief on both his alleged computing skills and his personal incredulity.

So, on nothing. It's one thing to say, "I don't believe they did it." That can translate to, "I have no idea what needed to be done or how the people who say they did it, did it." For the argument from authority to have any teeth, there need to be some receipts for that authority. From such an expert I would expect a more detailed explanation of what parts of the problem were intractable and what specific aspects of the computer system were measurably incapable of it. If his argument is just, "I'm very smart, and I can't see how it could have been done," then we have a whole bunch of demonstrably very smart people who can explain in great detail how it was done, and actually recreate the experience with surviving hardware and existing specs. Then the most parsimonious explanation for handwaving disbelief is ignorance.

Quote
He scoffed at the idea of engine burn parameters being read up to the astronauts...

That factually happened. Denying that it did is irrational. Reducing a simple maneuver to a discrete set of numbers is how astrodynamics works, whether someone wants to believe that or not.

Quote
...and at the lack of computing power of the AGCs.

Compared to what? The common mistake is to compare the computer to other computers. The proper method is to compare the computer to the required task. I can say that my smart watch has more computing power than the engine control module in my car. But does that prove my car won't work?

I use dirt-simple MCUs (microcontrollers) in many of my designs and products. These are inexpensive, to be sure, but also consume far less electrical current than the much faster processors I could use if I wanted. Right-sizing components is part of control system design. The testament to how carefully the computing load on the AGC was planned is the series of 120x program alarms that indicated that even a marginal increase in computing requirements (i.e., the rendezvous radar) would overload the system.

Again, most of the "computer people" you meet online have zero understanding of control theory and little if any understanding of real-time embedded systems. I've explained the control laws involved and how little computing power they required. The AGC was an embedded system running a discrete and deterministic software load with predictable, simulatable, and measurable performance requirements. It's not a web server or a smart phone running heaven-knows-what job mix. This is why I tend to hire crusty old game programmers for my embedded systems software. These are the guys who know how to shoehorn functionality into a deterministic hardware environment.

Also, the AGC was not a general-purpose computer. It was a computer created for the specific task of spacecraft guidance and control. As such it had things like counter interrupts and shift memories that you don't find on general processors. There was a lot of bolt-on hardware that offloaded the tasks that we would these days implement in software on a general MCU. Unless your guy has really done a deep dive into the AGC architecture, I wouldn't consider him an expert.
"Facts are stubborn things." --John Adams