Orbital Rocket Guidance with Ruby
Berkopec, Nate
Using the popular space simulator Kerbal Space Program and some remote procedure calls, we're going to use Ruby to launch (simulated) rockets into space! We'll discuss the history of computing in the space program, real-life algorithms for getting rockets into orbit like the Space Shuttle's Powered Explicit Guidance Ascent System, and the software architecture of historic space computers like the Apollo Guidance Computer. Finally, we'll build our own orbital rocket, controlled by a Ruby program that emulates space computers of the past.
 Keeping an eye on that power transfer at T minus 50 seconds. The F4B propellant, now all pressurized. The F4B propellant, that's the third stage of the Saturn V pressurized. One minute, 15 seconds and counting. The spacecraft equipment now is on its own internal cooling. It's been sharing its cooling, getting its cooling from an external power source up to this time. We're now approaching the T minus one minute mark. T minus one minute. T minus one minute and counting. We may get even a little buffering today because of our countdown. We get quite a shaking here. That's a 30 second mark. They keep that down, you're right. Interesting. Let's see if we can place the plate together. We pass the T minus 50 second mark, the power transfer takes place. First stage, second stage, third stage and the instrument unit going to internal power. T minus 37 seconds and our count continues to go well. We'll be looking for an ignition of those five first stage engines at the T minus 8.9 second mark. We pass T minus 30. T minus 25 seconds and counting and Apollo 13 is go. T minus 20 seconds. T minus 20 seconds and counting. 17 guidance release. 15, 14, 13, 12, 11, 10, 9, 8. Ignition sequence has started. 6, 5, 4, 3, 2, 1. My name is Nate Berkepeck. I am the mission control director for the Ruby Space Program. As you know, we've had a lot of budget cuts over the last couple of years. You are here today to learn how to program a spacecraft computer in the Ruby programming language. Obviously, Ruby is not known for its aerospace applications, but we're not going to let that one stop us. Like I said, my name is Nate. I know nothing about space. I have no background in space at all. In fact, all I do is write about how to make Ruby web applications faster. I have no qualification for this, but that doesn't stop me from teaching this session. We're going to be using a program called Kerbal Space Program. Kerbal Space Program is a video game that simulates spacecraft and space launches. It's more known for its wacky, weird stuff that people do in it like this. It's just a physics sandbox. People do this crazy stuff in it. That's probably your experience with Kerbal Space Program. It's also an extremely accurate physics simulator. It will simulate something called the Janibikov effect. Janibikov was a Soviet cosmonaut. The Janibikov effect basically just shows that an object that rotates is stable in two axes, but not on the third. That's Kerbal Space Program there. What you saw before was an experiment on the ISS. It's actually an extremely accurate physics simulation, which means we can use it to simulate real-world space launches. We're going to use a mod compilation called Realism Overhaul, which takes Kerbal Space Program's universe and turns it into a model of the actual solar system. We're going to use that today to launch a Saturn V rocket into orbit using a program written in Ruby. The Ruby part is going to be managed by a library called KRPC, which stands for Kerbal Remote Procedure Call. It basically just turns any running Kerbal Space Program into an API that you can make calls to. It's managed by Google Pro of Ups. There's a Ruby client library. It's really slick. Basically you can control anything in Kerbal Space Program that you could control normally with a keyboard or joystick or whatever. Here's an example program for KRPC written in Ruby. We just require it. We connect to a running Kerbal Space Program with KRPC installed. Then we've got this vessel object, which is going to contain all of our telemetry, like how fast we're going, which way we're pointed. We've got a control object, which will let us do things like change the throttle, activate the next stage, and stuff like that. I've used pry here to just open up a console and let me play around with the different objects that KRPC makes available. How are we going to design a program to get us to orbit? I want to look at some of the space computers of the past. Space computers have to be three very important things. They have to work in real time. That just means that rocket launch is a pretty fast and furious thing. These computers have to do their calculations quickly. They have to interact with astronauts in real time as well. astronauts have to interact with this computer. Back in the 1960s, that was when you would put a punch card into a machine and get a result 10 minutes later. A real-time computer back then was sort of this new novel thing. Computers also have to be extremely reliable. The Apollo Guidance Computer actually had all of its components in triplicate. If there was a sensor, you had three sensors. If one sensor was reading incorrectly, you took the result from the other two. This kind of stuff was done because space is an extremely harsh environment. It's got vacuum. The temperatures can vary wildly. And of course, if this computer stops working, people are probably going to die. So our space computers have to be extremely reliable. They also have to be simple and they have to work in simple ways. Because mostly because of the reliability requirements here, it's difficult to send a very complicated computer into space. We have to send simple computers into space so that we know that they'll work. The origins of space computing go back to this guy named Charles Draper who ran the Draper MIT lab. He was actually the guy that got the Apollo Guidance Computer contract. In the 1950s, he basically put a bunch of gyroscopes and accelerometers into the back of a plane and let the plane fly itself with no external landmarks from the east coast to the west coast. And it was only off by a couple of miles when it got all the way to San Francisco. So no navigation with landmarks, just the gyroscopes and the accelerometers. That's Draper right there on the right. And that's obviously really important for space guidance because in space there is no reference point. We have to navigate without any external references and keep track of our position. Also in the 1950s, we were doing something called building sounding rockets. Building sounding rockets are upper atmosphere research rockets. They basically go straight up and then do some experiments in the upper atmosphere and then fall back down to earth. The most common one that the US built was called the Aerobie rocket. That's that second one there. What's one I'm going to talk about? So the Aerobie had two stages. The top stage here was a sustainer stage. It was liquid fuel. The really short stage here on the bottom is a booster stage. It's made with solid fuel. It only lasted about five seconds. Its job was to get the rocket off the pad. Let's take a look at the Aerobie launch here. A camera is adjusted in an Aerobie rocket which is going to penetrate outer space on a photographic mission. The sky is the limit. Here's the view from 50 miles up. The second boost from the rockets and if you look back over your shoulder, this is what the world looks like a hundred miles away. I feel terrible. How do you feel? The reason the view is spinning there is because the rocket itself is spinning. Most sounding rockets were spin stabilized. That just means that the fins on the rocket are canted slightly to one angle which imparts a spin on the rocket as it accelerates through the atmosphere. That's because a spinning rocket is more stable than one that's just going straight up because it keeps its position upward because it's spinning. It's the same way a gyroscope works which is what we'll talk about in a little bit. If we want to write an Aerobie program to guide a sounding rocket into the upper atmosphere, we have three important things we need to do. We need to detach from the launch power when thrust is at maximum. Most rockets do not immediately have full thrust available when you like them. It takes a while for the thrust to build to lift off thrust. If we just detach the launch pylon immediately, our rocket will just fall over and then shoot off to the side. We shouldn't do that. We have to wait until the thrust is all the way up to where we want it to be. Seconds before the booster stage, that's this stage right here and the right cuts out. We need to light the second stage. We have both stages firing at the same time. The reason we do that is because the second stage, like I said, is liquid fuel. It's a bunch of liquid jet fuel, rocket fuel, sloshing around in the tank. If the first stage cuts out and the second stage isn't already going, you'll go from about two Gs of acceleration to nothing. The fuel in the second stage will start to slosh around. Then there's nothing pushing the fuel into the engine itself. Then the engine won't start and you screw. You need to start the second stage before the first stage burns out. That's called hot staging. The stages were actually connected with a little cage. There wasn't a solid bearing on the outside, so the thrust could get out. You'll see the cage in a second. Then when we run out of fuel on the first stage, we separate the booster stage and let it fly away. Then we go into the upper atmosphere. Let's just take a quick look at what that looks like in the Kerbal Space Program. We've got a client object from CARAPC that we connect to. We activate the first stage, which is the ignition of the engines. We wait until the engine comes up to 60% of maximum thrust. That's enough to get us off the pad. Then we activate the next stage, which is to detach the launch pylon. The rocket launches. Then we've got to hot stage and detach the first stage. We're just going to take note of how much fuel we have in the first stage fuel tank. When we have about 10% remaining, we'll activate the second stage, the sustainer rocket. Then when we run out of fuel, we will activate the next stage, which is the detaching. It looks a little bit like this. That's the booster stage on the bottom. Here's the cage. There goes the sustainer stage. It'll go up to 100 miles or whatever. See, it's spinning there too, obviously. That's an unmanned sounding rocket. Very simple. Let's talk about manned spaceflight. The Soviets, who we were obviously in a space race with at the time, had a very different idea of what the role of a computer was in a manned space program. In the Soviet space program, the astronauts themselves were like spam in a can just along for the ride. Everything was automated. The reasons for that are sort of multiple, but mostly it was the Soviets did not want their space program to fail. They thought that the political consequences of a failed launch would be too much, so it was better to have it all automated and run by machine rather than down the sub monkey and capsule. What they did was they built these electromechanical computers. This is the Globus IMU unit that was flown in the Bokshad spacecraft. Versions of this were flown until 2005 in the Soyuz. The Soviets did not have a computer on their rockets with circuits in it, a digital computer, until 1980. As you can see, this is sort of like a steam clockwork kind of looking thing. The reason they did this was because it is very easy to formally verify something with switches and gears rather than something with circuits. It is a little bit less complicated. Something that you can definitely trust will do what you tell it to. The AGC was a little different. It was a digital computer. In fact, it was one of the first, especially at that form factor. This is the AGC itself. It is 70 pounds, most of which is the aluminum casing on the outside there. It was probably about the size of a modern PC tower. It is about this big. That thing on the right is the display keyboard. It makes the computer look smaller, but that disk is actually really big because it had to be big enough for fat finger astronaut spacesuit people to use it. It makes the AGC itself look a little smaller. A lot is made about how limited the AGC was. It was. 32K of ROM, 2K of RAM, and a 2MHz clock cycle. There were two of these. There was one in the command module and one in the lunar module. I guess you had a massive 64K of ROM. That's all it takes to get to the moon. How do you get to the moon with that sort of limited amount of resources? The answer is twofold. One you have to be really careful. Basically you're writing in a simple. You have much more control over all the resources. There's no operating system to get in your way. That thing is done pretty much like it's the computer equivalent of building a ship and a bottle. It's very minute. The programs themselves are totally handcrafted. Also you have a crap ton of money. The program itself costs 45 million at the time. That's 350 million in today's dollars. The program itself, the AGC code, ends up being about 70,000 lines of assembler. That's like $5,000 a line. So when you have a NASA budget, it's a little easier to grab stuff than the really tiny computers. But that's not to say that this wasn't a difficult mission. Just the transglutor injection itself. The AGC really did its job from basically after we left Earth orbit and then all the way back home to landing on Earth. That's kind of when the AGC was controlling the mission. So the transglutor injection, which is what got you from Earth orbit to Moon orbit, you can think about that as if trying to hit a moving target 500,000 kilometers away while you're on a train that's going around a curve. You're doing that with however many million pounds of rocket crust behind you. So it's a very difficult problem. There was no floating point operations. It was all fixed point. You had a 15-bit word size. So you could only represent in one register numbers from zero to 32,000 unsigned. So it's pretty amazing accomplishment for sure. One of the great things about the AGC is it's extremely well documented. We have all the source codes from the Apollo 11 mission. It's been hand transcribed and scanned in. It's on GitHub. And people have built their own AGC simulators and AGC replicas from this documentation. There's one online called MoonJS. It's written in JavaScript and uses ASM.js. And you can play with an AGC emulator. It's really cool. It's running the Disci Light Check program in this shot. We've seen this picture before. Yeah, it got kind of popular. It kind of blew up on social media. So who can tell me who this is? Margaret Hamilton. Yeah, so Margaret Hamilton was the director of flight software for the Apollo program. This picture is sometimes captioned as standing next to the code she wrote for the Apollo program. Of course, she didn't write the program herself. I think it kind of undersells her accomplishments because she was the software person for the Apollo program. That was her $350 million going into that project. Margaret Hamilton ended up being a real sort of thought leader in the field of software reliability and formal systems. It did a lot of work after the Apollo program on that as well. And like I said, the Apollo source code, the guidance for the source code itself is only 70,000 lines. That's probably like one of these phone books. So she's probably standing in front of multiple iterations of the HCC code. And it's worth remembering that Margaret and everyone else that worked on the Apollo guidance computer had no formal training. Computer science is not a thing at this point. You couldn't take a class anywhere on it. Almost everything that they did for the Apollo guidance computer, people were doing for the first time. Like I said, it's all available on GitHub. This is the Apollo 11 code. They would make little changes to each mission code as they went along. They have a pretty good sense of humor. This was the name of the routine that controlled the engines. So this was the 60s, right? So this was a reference to the LA riots and the Black Power movement at the time. This one, I'm going to give you a guess as to what this controlled. This was the disky control for the keypad and all the associated lights on it. I like this one. Booter landing guidance equations. Yeah, I got it in the mood. This is a good one. So the Booter module had a landing radar that had to be pointed at the ground. And if it wasn't pointed in the correct position, this routine got called and asked you to please crank the silly thing around, like crank the radar around, see if he's lying and whether or not he did it. And then off to see the wizard, that will go to the bird baby bird. Oh, this isn't really showing up. So even though this program is 50 years old, it doesn't stop people from opening new issues on GitHub about it. This is obviously referring to the Apollo 13 explosion. So one of the difficult things about the space mission is you have to do a lot of different things at once. During the launch, for example, we're going to have to keep track of what stage of the rocket we're in and whether or not we're out of fuel. Plus we had to keep ourselves pointed the right way. So it's an inherently multitasking sort of problem. At the time, multitasking was pretty new. This guy, Hal Lanning, was the guy that designed basically the operating system for the AGC. It wasn't a real operating system. It just sort of managed all the different processes that were running. It was called the executive. And Hal kind of just made it up. No one had ever done this sort of thing before. So Hal was like, yeah, I guess I have to invent priority based multitasking. So before the AGC, what you did to share time between programs was something called the box car method. Basically it's time slicing. So you split a second into smaller intervals and you give an interval to a program. And then when you're done with that interval, you switch to the next program, the next interval. It's like a box car passing by on a train. And the problem with that is what is the thing that you're doing right now is really important. It's more important than the next box car. You're working on the guidance equations right now and then the light update program wants time. Well, obviously we shouldn't do that, right? So Hal invented priority based multitasking. So this is a Ruby representation of how the AGC worked. The AGC had seven core sets. A core set was an area that a job was assigned. It was their sort of memory space. It was only 15 bytes. And only seven of those bytes were available to the programmer to use for scratch space and memory. So if you could imagine writing a method that can only take seven bytes of memory, that's what the AGC programmers had to deal with. It would also keep track of where it was in its routine. That's the app, LOC. And each core set had a priority. So higher priority core sets would run before the other ones. The executive would always run the highest priority core set job first. And a core set with a priority of zero was available. It didn't have anything going on. So you could only have seven tasks running at any given time. So if you want to ask for a new core set to run a new job, we give it a priority. We look for an empty entry in the core set table. And then we're going to give it a fiber. So most multitasking in the AGC was done cooperatively. There were interrupts. There was software interrupts. But it wasn't done very often because obviously interrupting a computer with like, you know, 15 registers at any given time would be dangerous because things get out of order and then you're screwed. So they tried not to use interrupts and mostly used cooperative multitasking. So we have that in Ruby with fibers. That's what we're going to use to emulate it. And then we just set a priority to whatever we want. Okay. A job itself is just going to be a class. And we're going to delegate a bunch of plumbing back to the core set so we can get access to like, our telemetry and stuff like that. Here's an example of a job. This will just print the priorities of all the current core sets. So we just go through the core set table and print the priority. And then we're going to yield with a fiber. At this point we'll yield control back to the executive. The executive will then decide if this gets to run again or not. When we call fiber.mzume, we enter here and go back to the beginning of the loop and so on and so forth. Okay. So this job just runs over and over and over and it doesn't do anything else. Obviously, okay. So then this is what the actual executive routine looks like. We sort the core set table by priority, highest priority at the top. We take the highest priority job. We call it resume on that unless it's priority zero or less than zero because then it's available. And if we fiber.yield with a kill symbol, we're going to say that's when this task, this job is done, make that core set available. Yeah. So when we're going to try to get the agency working, the, so that's a core set printer program. It would just run over and over, right? So that's not very useful. Like what if we only wanted to print the core set priorities every five seconds? Well, we can do that with something called the wait list. This was sort of the way that you manage scheduled work on the agency. The wait list was also about seven entries long. What it would do would, so the, any task on the wait list only had six milliseconds allotted to it to run. The wait list tasks were basically just like, hey, schedule this job, manipulate the priority of this other job. They were very quick little things that got scheduled for the future at a particular time. One thing that was used a lot for, and what we're going to use a lot for in our program is to sleep or delay a job. What we're going to do is just reverse the priority of the job. So if a job is priority 10, we'll make it priority negative 10 and give it a time to execute in the future. And then we'll just go through the wait list every once in a while and say, hey, is there anything in the wait list whose time has come and then just quickly call it. We'll just give it a block. We'll call the block. That's our wait list. That's exactly, the wait list is just straight from how the UTC actually worked. The AGC had a requirement that it had to be able to restart at any time. Part of this is because power was unpredictable. If power could spike to go down in any time and then the AGC would have to shut off, it would have to restart from where it was. It also used restart as a way to turn it on and off again and fix the problem. We'll get back to that in a minute. We can emulate this by just Marshall dumping the core set table and then reloading it again. It's kind of the not super accurate way of doing this. In AGC, jobs could actually sign up for different kinds of restart protection. You could register a waypoint during your routine and say, if we restart, please restart here. Things like that. It's way too complicated. We're not going to bother with that. This is, you could also stop reset. There was a button on the AGC to reset. We're going to emulate that by just clearing out the core set table in the wait list. The only thing that really enforced how much time a job could take was something called the night watchman. It was sort of a last resort. There was really nothing that said that, oh, you have to check the return control every once in a while or whatever. It was assumed that you would return control to the executive every 20 milliseconds, but that wasn't strictly enforced. There was something called the night watchman, which I don't remember the interval in the AGC. It would just, if you hadn't checked into the executive at a certain period of time, it would blow up and restart the whole computer. That's what we're going to do here. We're just going to start a thread, and every one second, if the main routine has not been run, that will blow up. That will restart. The restart protection actually came in very handy during the Apollo 11 landing. This is somebody's model of an AGC, and it's going through the moon landing. You'll hear the astronauts in the background. Let's just watch. That clicking noise is the actual display itself. You can hear the tone of his voice there. A program alarm was something that the executive would raise when it had a problem. How do you get a voice coming in? Right there. All clear, down here. Copy, all clear. All clear. It's true, everything has wound up when it hits the tune. So this is as they're coming down to the moon surface suddenly they're getting this computer error right and he's like give us a read in the 1202 program alarm because they were putting their hand over the abort button thinking well this is it like we're not going to make it to the moon. A 1202 alarm is what happened in the core set table overflow. That just meant that basically the computer didn't have enough time for all the work that it was doing. It would raise the 1202 alarm and you would reset the computer and hope that it didn't happen again. That's really actually what they did on the way down to the lunar surface. They would just keep restarting the computer every time that this alarm happened. It was caused by this the landing radar had like a power problem and was sending too many interrupts to the processor and overloading it. They never actually did fix that. They just changed the procedure during landing so that it wouldn't occur. So we're going to write our launch program now. So what do we have to do? We have to guide the spacecraft. Guidance is just where do you want to go? What is the exact path that we're going to take to orbit? It was an extremely important task in the Apollo guidance computer obviously. How do you get down to the surface of the moon? Navigation is where are you right now? So where are you pointed and how fast are you going? So I was talking about gyroscopes earlier. The Apollo guidance computer had something called the IMU. It's the inertial measurement unit. It was just a bunch of spinning gyroscopes and accelerometers. A gyroscope works like this. This is actually Draper himself demonstrating this. So you see how the spinning disk there is keeping its orientation even as the frame is being moved? So that's all a gyroscope does. It provides a stable platform that you can make a reference against. If the gyroscope got out of whack, which it did every like day, it would eventually just become inaccurate, you actually used a sextant, which I think is kind of amazing. They had a sextant built in to both the command module and the litter module. You take some star sightings and then reset where you were. Pretty amazing technology from literally the 1500s. The third task we have to do is control. We have to control the rocket. Nothing in the Apollo program was manual. Everything was fly by wire. Everything went through the computer. Part of this is because flying in the spacecraft is actually very complicated. The litter module, if you look at it, it's asymmetric. So if you have an asymmetric rocket with an engine directly underneath, that's actually very difficult to control. It's like trying to balance a broomstick on your finger, but the broomstick is bent. That's actually kind of complicated to think about and work with. So everything went through the computer and it corrected for that. But today we're just going to talk about guidance. KRFEC and Kerbal Space Program basically do the navigation and control part for you. So we're just going to talk about guidance. We're going to go to orbit. The orbit is fundamentally about taking a rocket, which is moving zero miles an hour and pointed straight up and going to 200 kilometers above the Earth and moving at 17,000 miles an hour sideways. The 75 had three stages, which would accomplish this. The launch profile took about 11 or 12 minutes to get into orbit. This path, this curve path, was something called a gravity turn. A gravity turn is usually implemented as an open loop algorithm. It just means that it doesn't take into account the exterior state of the vehicle. It's just sort of a pre-programmed thing. Go up a certain amount, turn this way, and then wait. It's not saying, okay, let's figure out where we are and make some corrections. It doesn't do any of that. That's a closed loop guidance algorithm. So we start with open loop guidance. Gravity turn looks like this. This is from a SpaceX rocket launch. So you go up a little bit, and then you turn the rocket over, and you let the force of gravity slowly tip the rocket over as you go to space. So the way to orbit looks like this long elliptical path. Moving a follow-up 13 actually gets the gravity turn maneuver really right. So gravity turn maneuver, you go up until you're moving at a certain speed, and then you pitch the rocket over. So the Saturn V pitched over five degrees. So let's just watch to see what that looks like. So after that five-degree pitch maneuver, you just let the engines point straight down and let gravity do the rest of the work for you. You don't do any other control input after that until you're out of the atmosphere. This is the real follow-up 13 launch. It's a little harder to see, but I want you to listen to what Jim Lovell says. So it's kind of hard to hear, but what he says is, roll and pitch program complete. So the rocket would roll slightly, and then it would just pitch over a little bit. The reason we don't do more guidance during this part of the flight in the atmosphere is because the rocket is actually very fragile. It's under a lot of forces, both from the enormous rocket engines underneath, and the atmosphere pushing against it. This is the actual constraint. You couldn't move more than one degree per second in pitch and yaw. There's just too much aerodynamic forces working on the vehicle for us to do anything else. Once you got out of the atmosphere, Apollo did something called iterative guidance mode. It had a bunch of different modes, and it's really complicated. It's a closed-loop guidance algorithm, which just means that at that point that it could take into account where it was, where it wanted to be, and then it would make the corrections. You could only do that outside of the atmosphere because that was the place where you could maneuver. They used something called linear tangent steering, which is a bunch of spherical trigonometry that I'm not going to explain other than to say that's what it looks like and that's what our program is going to use. If you start accounting for things which the linear tangent steering algorithm doesn't, like the Earth, not being flat, and the Earth's gravity varies, and all these other things, it starts to get really complicated really quick. I'm not going to talk too much about closed-loop guidance. The last thing, as the Saturn V comes off the pad, it does what's called a yaw maneuver. It tilts slightly and then goes back up straight. The reason it does this is because they just want to avoid a wind blowing it back into the tower. If an engine blows out as you come off the pad, you don't want the rocket to tilt back into the pad. That program would look a bit like this in Ruby. We tilt over about a degree and wait eight seconds and then go back up straight. That's called a yaw maneuver. I couldn't find a good video of the Saturn V doing this, but here's Antares' rockets, a more modern rocket doing the same maneuver. Notice the wind coming in from the right-hand side of the screen. And we have ignition. And we have lift-off. And there's that tilt. And then it goes back straight. It's really subtle, but it just keeps you from falling back into the pad. Okay, so this is our task. We're going to ignite the engines, wait for them to come up to thrust and lift-off. We're going to do a quick yaw away from the tower, accelerate 200 meters per second, then pitch eastward five degrees. Then we're going to disable the pitch control on our autopilots. That'll just let the rocket slowly tilt just with gravity. And then we'll wait until we're through the atmosphere, when dynamic pressure on the rocket is low. Then we'll begin close-loop guidance and then burn until our, the periaxis, that's the lowest point in our orbit. So we'll burn until the lowest point in our orbit is basically in space. Remember when I talked about how liquid fuel in a rocket can get sloshed around? So they didn't hot stage on the Apollo and the Saturn V. What they did was they had these things called Ullage motors. They're solid fuel rockets on the side of the stage that basically sort of ignite before the main engines and then get the rocket moving so that the fuel settles and then they light the main liquid engines. It's another great scene in Apollo 13, so I'll just point out the Ullage motors in here. That's the first stage. All right, look. Looks good. It's live right down the middle. We see your VPC is clear 13. Roger. EDS to manual. Inboard. Get ready for low charge, fellas. We're at the first stage. Notice how they slow down. There's the Ullage motors and then you see the second stage actually light. Okay, so this is what it looks like in Kerbal Space Program. We're on the pad ready to launch. We start a new RGC process. We just start the executive in a loop. That's it. Very simple. We ignite the engines. So that's the control object. Light, wait until the thrust comes up to 60%. And then we activate the next stage, which releases the rocket from the tower. And we'll request core sets for our gravity turn and a staging job. So that will control the actual rocket's stages separating. And then we kill this process, this core set, and let someone else use the core set. There we have lift off, lifting off the pad. On a way to orbit, first stage. This is what the gravity turn task ends up looking like. You wait until you're over 100 meters per second. Pitch over six degrees in this case. And then we disable the autopilot down here after we've waited 15 seconds. And that will just let the gravity turn slowly turn you over. There's the Ullage motors firing for the second stage. There's the interstage fairing dropping off. There's a staging job just basically says, hey, if there's an engine in this stage, wait until it's out of fuel, when it's out of fuel stage. And we're on a way to orbit. I've a very simple closed loop guidance job. It's not closed loop, actually. And we just slowly pitch over the rocket at a predetermined angle. And that's separating off the third stage. And there we are in orbit. So that's how you get to orbit with Ruby. Thank you very much. I was going to go a little quick there at the end because I realized I'm really low on time. But I do want to take at least one question. I have the code and the text for this talk at that GitHub address. Any questions? Did I ever turn off the garbage collector? No. I didn't go that deep. Anybody else? Any questions about the Apollo guidance computer? Yeah. Like a couple hours. No, I don't know what to picture me next to the code for now. It's only a couple hundred lines. It's really not that much code, actually. Definitely less than 70,000 lines of assembler. Yes. Sorry, can you say that again? Why are we not recreating another Apollo mission? So, yeah, obviously this is only the launch. That's actually like the simplest phase. In the real Apollo program, the launch was not controlled by the guidance computer at all. It was a separate computer called the LVDC. That was actually mounted in the Saturn rocket itself. The mission program for the Apollo are actually way more extensive. Landing on the lunar surface was extremely complicated. So, the answer to that is probably not, because it's really complicated. But it's a fun way to play Kerbal Space Program just to reduce yourself saying, hey, I can only write Ruby to control the rocket, but it makes everything take really long. Anybody else? Yeah. How many times did I crash? Dude, it's awful. So, remember I said it takes about 12 minutes to get to orbit. So, the only way to test your program is to go to orbit. So, if you have a problem that happens 11 minutes in, it's like, well, now I have to go restart and wait 11 minutes again to see if I fix it. So, it took forever. Yeah. Why didn't I try parallel testing? Five rockets. That's a good idea. Yeah. My rig is not that good. I think I could run the very resource intensive program. Yeah. You could not run Kerbal Space Program on the Apollo guns computer. All right. That's my time. Thank you. Thank you.
 Keeping an eye on that power transfer at T minus 50 seconds.  The F4B propellant, now all pressurized.  The F4B propellant, that's the third stage of the Saturn V pressurized.  One minute, 15 seconds and counting.  The spacecraft equipment now is on its own internal cooling.  It's been sharing its cooling, getting its cooling from an external power source up to  this time.  We're now approaching the T minus one minute mark.  T minus one minute.  T minus one minute and counting.  We may get even a little buffering today because of our countdown.  We get quite a shaking here.  That's a 30 second mark.  They keep that down, you're right.  Interesting.  Let's see if we can place the plate together.  We pass the T minus 50 second mark, the power transfer takes place.  First stage, second stage, third stage and the instrument unit going to internal power.  T minus 37 seconds and our count continues to go well.  We'll be looking for an ignition of those five first stage engines at the T minus 8.9  second mark.  We pass T minus 30.  T minus 25 seconds and counting and Apollo 13 is go.  T minus 20 seconds.  T minus 20 seconds and counting.  17 guidance release.  15, 14, 13, 12, 11, 10, 9, 8.  Ignition sequence has started.  6, 5, 4, 3, 2, 1.  My name is Nate Berkepeck.  I am the mission control director for the Ruby Space Program.  As you know, we've had a lot of budget cuts over the last couple of years.  You are here today to learn how to program a spacecraft computer in the Ruby programming  language.  Obviously, Ruby is not known for its aerospace applications, but we're not going to let that  one stop us.  Like I said, my name is Nate.  I know nothing about space.  I have no background in space at all.  In fact, all I do is write about how to make Ruby web applications faster.  I have no qualification for this, but that doesn't stop me from teaching this session.  We're going to be using a program called Kerbal Space Program.  Kerbal Space Program is a video game that simulates spacecraft and space launches.  It's more known for its wacky, weird stuff that people do in it like this.  It's just a physics sandbox.  People do this crazy stuff in it.  That's probably your experience with Kerbal Space Program.  It's also an extremely accurate physics simulator.  It will simulate something called the Janibikov effect.  Janibikov was a Soviet cosmonaut.  The Janibikov effect basically just shows that an object that rotates is stable in two  axes, but not on the third.  That's Kerbal Space Program there.  What you saw before was an experiment on the ISS.  It's actually an extremely accurate physics simulation, which means we can use it to simulate  real-world space launches.  We're going to use a mod compilation called Realism Overhaul, which takes Kerbal Space  Program's universe and turns it into a model of the actual solar system.  We're going to use that today to launch a Saturn V rocket into orbit using a program  written in Ruby.  The Ruby part is going to be managed by a library called KRPC, which stands for Kerbal  Remote Procedure Call.  It basically just turns any running Kerbal Space Program into an API that you can make  calls to.  It's managed by Google Pro of Ups.  There's a Ruby client library.  It's really slick.  Basically you can control anything in Kerbal Space Program that you could control normally  with a keyboard or joystick or whatever.  Here's an example program for KRPC written in Ruby.  We just require it.  We connect to a running Kerbal Space Program with KRPC installed.  Then we've got this vessel object, which is going to contain all of our telemetry, like  how fast we're going, which way we're pointed.  We've got a control object, which will let us do things like change the throttle, activate  the next stage, and stuff like that.  I've used pry here to just open up a console and let me play around with the different  objects that KRPC makes available.  How are we going to design a program to get us to orbit?  I want to look at some of the space computers of the past.  Space computers have to be three very important things.  They have to work in real time.  That just means that rocket launch is a pretty fast and furious thing.  These computers have to do their calculations quickly.  They have to interact with astronauts in real time as well.  astronauts have to interact with this computer.  Back in the 1960s, that was when you would put a punch card into a machine and get a  result 10 minutes later.  A real-time computer back then was sort of this new novel thing.  Computers also have to be extremely reliable.  The Apollo Guidance Computer actually had all of its components in triplicate.  If there was a sensor, you had three sensors.  If one sensor was reading incorrectly, you took the result from the other two.  This kind of stuff was done because space is an extremely harsh environment.  It's got vacuum.  The temperatures can vary wildly.  And of course, if this computer stops working, people are probably going to die.  So our space computers have to be extremely reliable.  They also have to be simple and they have to work in simple ways.  Because mostly because of the reliability requirements here, it's difficult to send  a very complicated computer into space.  We have to send simple computers into space so that we know that they'll work.  The origins of space computing go back to this guy named Charles Draper who ran the  Draper MIT lab.  He was actually the guy that got the Apollo Guidance Computer contract.  In the 1950s, he basically put a bunch of gyroscopes and accelerometers into the back  of a plane and let the plane fly itself with no external landmarks from the east coast to  the west coast.  And it was only off by a couple of miles when it got all the way to San Francisco.  So no navigation with landmarks, just the gyroscopes and the accelerometers.  That's Draper right there on the right.  And that's obviously really important for space guidance because in space there is no  reference point.  We have to navigate without any external references and keep track of our position.  Also in the 1950s, we were doing something called building sounding rockets.  Building sounding rockets are upper atmosphere research rockets.  They basically go straight up and then do some experiments in the upper atmosphere and  then fall back down to earth.  The most common one that the US built was called the Aerobie rocket.  That's that second one there.  What's one I'm going to talk about?  So the Aerobie had two stages.  The top stage here was a sustainer stage.  It was liquid fuel.  The really short stage here on the bottom is a booster stage.  It's made with solid fuel.  It only lasted about five seconds.  Its job was to get the rocket off the pad.  Let's take a look at the Aerobie launch here.  A camera is adjusted in an Aerobie rocket which is going to penetrate outer space on  a photographic mission.  The sky is the limit.  Here's the view from 50 miles up.  The second boost from the rockets and if you look back over your shoulder, this is what  the world looks like a hundred miles away.  I feel terrible.  How do you feel?  The reason the view is spinning there is because the rocket itself is spinning.  Most sounding rockets were spin stabilized.  That just means that the fins on the rocket are canted slightly to one angle which imparts  a spin on the rocket as it accelerates through the atmosphere.  That's because a spinning rocket is more stable than one that's just going straight up because  it keeps its position upward because it's spinning.  It's the same way a gyroscope works which is what we'll talk about in a little bit.  If we want to write an Aerobie program to guide a sounding rocket into the upper atmosphere,  we have three important things we need to do.  We need to detach from the launch power when thrust is at maximum.  Most rockets do not immediately have full thrust available when you like them.  It takes a while for the thrust to build to lift off thrust.  If we just detach the launch pylon immediately, our rocket will just fall over and then shoot  off to the side.  We shouldn't do that.  We have to wait until the thrust is all the way up to where we want it to be.  Seconds before the booster stage, that's this stage right here and the right cuts out.  We need to light the second stage.  We have both stages firing at the same time.  The reason we do that is because the second stage, like I said, is liquid fuel.  It's a bunch of liquid jet fuel, rocket fuel, sloshing around in the tank.  If the first stage cuts out and the second stage isn't already going, you'll go from  about two Gs of acceleration to nothing.  The fuel in the second stage will start to slosh around.  Then there's nothing pushing the fuel into the engine itself.  Then the engine won't start and you screw.  You need to start the second stage before the first stage burns out.  That's called hot staging.  The stages were actually connected with a little cage.  There wasn't a solid bearing on the outside, so the thrust could get out.  You'll see the cage in a second.  Then when we run out of fuel on the first stage, we separate the booster stage and let  it fly away.  Then we go into the upper atmosphere.  Let's just take a quick look at what that looks like in the Kerbal Space Program.  We've got a client object from CARAPC that we connect to.  We activate the first stage, which is the ignition of the engines.  We wait until the engine comes up to 60% of maximum thrust.  That's enough to get us off the pad.  Then we activate the next stage, which is to detach the launch pylon.  The rocket launches.  Then we've got to hot stage and detach the first stage.  We're just going to take note of how much fuel we have in the first stage fuel tank.  When we have about 10% remaining, we'll activate the second stage, the sustainer rocket.  Then when we run out of fuel, we will activate the next stage, which is the detaching.  It looks a little bit like this.  That's the booster stage on the bottom.  Here's the cage.  There goes the sustainer stage.  It'll go up to 100 miles or whatever.  See, it's spinning there too, obviously.  That's an unmanned sounding rocket.  Very simple.  Let's talk about manned spaceflight.  The Soviets, who we were obviously in a space race with at the time, had a very different  idea of what the role of a computer was in a manned space program.  In the Soviet space program, the astronauts themselves were like spam in a can just along  for the ride.  Everything was automated.  The reasons for that are sort of multiple, but mostly it was the Soviets did not want  their space program to fail.  They thought that the political consequences of a failed launch would be too much, so it  was better to have it all automated and run by machine rather than down the sub monkey  and capsule.  What they did was they built these electromechanical computers.  This is the Globus IMU unit that was flown in the Bokshad spacecraft.  Versions of this were flown until 2005 in the Soyuz.  The Soviets did not have a computer on their rockets with circuits in it, a digital computer,  until 1980.  As you can see, this is sort of like a steam clockwork kind of looking thing.  The reason they did this was because it is very easy to formally verify something with  switches and gears rather than something with circuits.  It is a little bit less complicated.  Something that you can definitely trust will do what you tell it to.  The AGC was a little different.  It was a digital computer.  In fact, it was one of the first, especially at that form factor.  This is the AGC itself.  It is 70 pounds, most of which is the aluminum casing on the outside there.  It was probably about the size of a modern PC tower.  It is about this big.  That thing on the right is the display keyboard.  It makes the computer look smaller, but that disk is actually really big because it had  to be big enough for fat finger astronaut spacesuit people to use it.  It makes the AGC itself look a little smaller.  A lot is made about how limited the AGC was.  It was.  32K of ROM, 2K of RAM, and a 2MHz clock cycle.  There were two of these.  There was one in the command module and one in the lunar module.  I guess you had a massive 64K of ROM.  That's all it takes to get to the moon.  How do you get to the moon with that sort of limited amount of resources?  The answer is twofold.  One you have to be really careful.  Basically you're writing in a simple.  You have much more control over all the resources.  There's no operating system to get in your way.  That thing is done pretty much like it's the computer equivalent of building a ship and  a bottle.  It's very minute.  The programs themselves are totally handcrafted.  Also you have a crap ton of money.  The program itself costs 45 million at the time.  That's 350 million in today's dollars.  The program itself, the AGC code, ends up being about 70,000 lines of assembler.  That's like $5,000 a line.  So when you have a NASA budget, it's a little easier to grab stuff than the really tiny computers.  But that's not to say that this wasn't a difficult mission.  Just the transglutor injection itself.  The AGC really did its job from basically after we left Earth orbit and then all the  way back home to landing on Earth.  That's kind of when the AGC was controlling the mission.  So the transglutor injection, which is what got you from Earth orbit to Moon orbit, you  can think about that as if trying to hit a moving target 500,000 kilometers away while  you're on a train that's going around a curve.  You're doing that with however many million pounds of rocket crust behind you.  So it's a very difficult problem.  There was no floating point operations.  It was all fixed point.  You had a 15-bit word size.  So you could only represent in one register numbers from zero to 32,000 unsigned.  So it's pretty amazing accomplishment for sure.  One of the great things about the AGC is it's extremely well documented.  We have all the source codes from the Apollo 11 mission.  It's been hand transcribed and scanned in.  It's on GitHub.  And people have built their own AGC simulators and AGC replicas from this documentation.  There's one online called MoonJS.  It's written in JavaScript and uses ASM.js.  And you can play with an AGC emulator.  It's really cool.  It's running the Disci Light Check program in this shot.  We've seen this picture before.  Yeah, it got kind of popular.  It kind of blew up on social media.  So who can tell me who this is?  Margaret Hamilton.  Yeah, so Margaret Hamilton was the director of flight software for the Apollo program.  This picture is sometimes captioned as standing next to the code she wrote for the Apollo program.  Of course, she didn't write the program herself.  I think it kind of undersells her accomplishments because she was the software person for the  Apollo program.  That was her $350 million going into that project.  Margaret Hamilton ended up being a real sort of thought leader in the field of software  reliability and formal systems.  It did a lot of work after the Apollo program on that as well.  And like I said, the Apollo source code, the guidance for the source code itself is only  70,000 lines.  That's probably like one of these phone books.  So she's probably standing in front of multiple iterations of the HCC code.  And it's worth remembering that Margaret and everyone else that worked on the Apollo  guidance computer had no formal training.  Computer science is not a thing at this point.  You couldn't take a class anywhere on it.  Almost everything that they did for the Apollo guidance computer, people were doing for the  first time.  Like I said, it's all available on GitHub.  This is the Apollo 11 code.  They would make little changes to each mission code as they went along.  They have a pretty good sense of humor.  This was the name of the routine that controlled the engines.  So this was the 60s, right?  So this was a reference to the LA riots and the Black Power movement at the time.  This one, I'm going to give you a guess as to what this controlled.  This was the disky control for the keypad and all the associated lights on it.  I like this one.  Booter landing guidance equations.  Yeah, I got it in the mood.  This is a good one.  So the Booter module had a landing radar that had to be pointed at the ground.  And if it wasn't pointed in the correct position, this routine got called and asked you to please  crank the silly thing around, like crank the radar around, see if he's lying and whether  or not he did it.  And then off to see the wizard, that will go to the bird baby bird.  Oh, this isn't really showing up.  So even though this program is 50 years old, it doesn't stop people from opening new issues  on GitHub about it.  This is obviously referring to the Apollo 13 explosion.  So one of the difficult things about the space mission is you have to do a lot of different  things at once.  During the launch, for example, we're going to have to keep track of what stage of the  rocket we're in and whether or not we're out of fuel.  Plus we had to keep ourselves pointed the right way.  So it's an inherently multitasking sort of problem.  At the time, multitasking was pretty new.  This guy, Hal Lanning, was the guy that designed basically the operating system for the AGC.  It wasn't a real operating system.  It just sort of managed all the different processes that were running.  It was called the executive.  And Hal kind of just made it up.  No one had ever done this sort of thing before.  So Hal was like, yeah, I guess I have to invent priority based multitasking.  So before the AGC, what you did to share time between programs was something called the box  car method.  Basically it's time slicing.  So you split a second into smaller intervals and you give an interval to a program.  And then when you're done with that interval, you switch to the next program, the next interval.  It's like a box car passing by on a train.  And the problem with that is what is the thing that you're doing right now is really important.  It's more important than the next box car.  You're working on the guidance equations right now and then the light update program  wants time.  Well, obviously we shouldn't do that, right?  So Hal invented priority based multitasking.  So this is a Ruby representation of how the AGC worked.  The AGC had seven core sets.  A core set was an area that a job was assigned.  It was their sort of memory space.  It was only 15 bytes.  And only seven of those bytes were available to the programmer to use for scratch space  and memory.  So if you could imagine writing a method that can only take seven bytes of memory, that's  what the AGC programmers had to deal with.  It would also keep track of where it was in its routine.  That's the app, LOC.  And each core set had a priority.  So higher priority core sets would run before the other ones.  The executive would always run the highest priority core set job first.  And a core set with a priority of zero was available.  It didn't have anything going on.  So you could only have seven tasks running at any given time.  So if you want to ask for a new core set to run a new job, we give it a priority.  We look for an empty entry in the core set table.  And then we're going to give it a fiber.  So most multitasking in the AGC was done cooperatively.  There were interrupts.  There was software interrupts.  But it wasn't done very often because obviously interrupting a computer with like, you know,  15 registers at any given time would be dangerous because things get out of order and then you're  screwed.  So they tried not to use interrupts and mostly used cooperative multitasking.  So we have that in Ruby with fibers.  That's what we're going to use to emulate it.  And then we just set a priority to whatever we want.  Okay.  A job itself is just going to be a class.  And we're going to delegate a bunch of plumbing back to the core set so we can get access  to like, our telemetry and stuff like that.  Here's an example of a job.  This will just print the priorities of all the current core sets.  So we just go through the core set table and print the priority.  And then we're going to yield with a fiber.  At this point we'll yield control back to the executive.  The executive will then decide if this gets to run again or not.  When we call fiber.mzume, we enter here and go back to the beginning of the loop and so  on and so forth.  Okay.  So this job just runs over and over and over and it doesn't do anything else.  Obviously, okay.  So then this is what the actual executive routine looks like.  We sort the core set table by priority, highest priority at the top.  We take the highest priority job.  We call it resume on that unless it's priority zero or less than zero because then it's available.  And if we fiber.yield with a kill symbol, we're going to say that's when this task,  this job is done, make that core set available.  Yeah.  So when we're going to try to get the agency working, the, so that's a core set printer  program.  It would just run over and over, right?  So that's not very useful.  Like what if we only wanted to print the core set priorities every five seconds?  Well, we can do that with something called the wait list.  This was sort of the way that you manage scheduled work on the agency.  The wait list was also about seven entries long.  What it would do would, so the, any task on the wait list only had six milliseconds allotted  to it to run.  The wait list tasks were basically just like, hey, schedule this job, manipulate the priority  of this other job.  They were very quick little things that got scheduled for the future at a particular time.  One thing that was used a lot for, and what we're going to use a lot for in our program  is to sleep or delay a job.  What we're going to do is just reverse the priority of the job.  So if a job is priority 10, we'll make it priority negative 10 and give it a time to  execute in the future.  And then we'll just go through the wait list every once in a while and say, hey, is there  anything in the wait list whose time has come and then just quickly call it.  We'll just give it a block.  We'll call the block.  That's our wait list.  That's exactly, the wait list is just straight from how the UTC actually worked.  The AGC had a requirement that it had to be able to restart at any time.  Part of this is because power was unpredictable.  If power could spike to go down in any time and then the AGC would have to shut off, it  would have to restart from where it was.  It also used restart as a way to turn it on and off again and fix the problem.  We'll get back to that in a minute.  We can emulate this by just Marshall dumping the core set table and then reloading it again.  It's kind of the not super accurate way of doing this.  In AGC, jobs could actually sign up for different kinds of restart protection.  You could register a waypoint during your routine and say, if we restart, please restart  here.  Things like that.  It's way too complicated.  We're not going to bother with that.  This is, you could also stop reset.  There was a button on the AGC to reset.  We're going to emulate that by just clearing out the core set table in the wait list.  The only thing that really enforced how much time a job could take was something called  the night watchman.  It was sort of a last resort.  There was really nothing that said that, oh, you have to check the return control every  once in a while or whatever.  It was assumed that you would return control to the executive every 20 milliseconds, but  that wasn't strictly enforced.  There was something called the night watchman, which I don't remember the interval in the  AGC.  It would just, if you hadn't checked into the executive at a certain period of time,  it would blow up and restart the whole computer.  That's what we're going to do here.  We're just going to start a thread, and every one second, if the main routine has not been  run, that will blow up.  That will restart.  The restart protection actually came in very handy during the Apollo 11 landing.  This is somebody's model of an AGC, and it's going through the moon landing.  You'll hear the astronauts in the background.  Let's just watch.  That clicking noise is the actual display itself.  You can hear the tone of his voice there.  A program alarm was something that the executive would raise when it had a problem.  How do you get a voice coming in?  Right there.  All clear, down here.  Copy, all clear.  All clear.  It's true, everything has wound up when it hits the tune.  So this is as they're coming down to the moon surface suddenly they're getting this computer  error right and he's like give us a read in the 1202 program alarm because they were putting  their hand over the abort button thinking well this is it like we're not going to make  it to the moon.  A 1202 alarm is what happened in the core set table overflow.  That just meant that basically the computer didn't have enough time for all the work that  it was doing.  It would raise the 1202 alarm and you would reset the computer and hope that it didn't  happen again.  That's really actually what they did on the way down to the lunar surface.  They would just keep restarting the computer every time that this alarm happened.  It was caused by this the landing radar had like a power problem and was sending too many  interrupts to the processor and overloading it.  They never actually did fix that.  They just changed the procedure during landing so that it wouldn't occur.  So we're going to write our launch program now.  So what do we have to do?  We have to guide the spacecraft.  Guidance is just where do you want to go?  What is the exact path that we're going to take to orbit?  It was an extremely important task in the Apollo guidance computer obviously.  How do you get down to the surface of the moon?  Navigation is where are you right now?  So where are you pointed and how fast are you going?  So I was talking about gyroscopes earlier.  The Apollo guidance computer had something called the IMU.  It's the inertial measurement unit.  It was just a bunch of spinning gyroscopes and accelerometers.  A gyroscope works like this.  This is actually Draper himself demonstrating this.  So you see how the spinning disk there is keeping its orientation even as the frame  is being moved?  So that's all a gyroscope does.  It provides a stable platform that you can make a reference against.  If the gyroscope got out of whack, which it did every like day, it would eventually just  become inaccurate, you actually used a sextant, which I think is kind of amazing.  They had a sextant built in to both the command module and the litter module.  You take some star sightings and then reset where you were.  Pretty amazing technology from literally the 1500s.  The third task we have to do is control.  We have to control the rocket.  Nothing in the Apollo program was manual.  Everything was fly by wire.  Everything went through the computer.  Part of this is because flying in the spacecraft is actually very complicated.  The litter module, if you look at it, it's asymmetric.  So if you have an asymmetric rocket with an engine directly underneath, that's actually  very difficult to control.  It's like trying to balance a broomstick on your finger, but the broomstick is bent.  That's actually kind of complicated to think about and work with.  So everything went through the computer and it corrected for that.  But today we're just going to talk about guidance.  KRFEC and Kerbal Space Program basically do the navigation and control part for you.  So we're just going to talk about guidance.  We're going to go to orbit.  The orbit is fundamentally about taking a rocket, which is moving zero miles an hour  and pointed straight up and going to 200 kilometers above the Earth and moving at 17,000 miles  an hour sideways.  The 75 had three stages, which would accomplish this.  The launch profile took about 11 or 12 minutes to get into orbit.  This path, this curve path, was something called a gravity turn.  A gravity turn is usually implemented as an open loop algorithm.  It just means that it doesn't take into account the exterior state of the vehicle.  It's just sort of a pre-programmed thing.  Go up a certain amount, turn this way, and then wait.  It's not saying, okay, let's figure out where we are and make some corrections.  It doesn't do any of that.  That's a closed loop guidance algorithm.  So we start with open loop guidance.  Gravity turn looks like this.  This is from a SpaceX rocket launch.  So you go up a little bit, and then you turn the rocket over, and you let the force of  gravity slowly tip the rocket over as you go to space.  So the way to orbit looks like this long elliptical path.  Moving a follow-up 13 actually gets the gravity turn maneuver really right.  So gravity turn maneuver, you go up until you're moving at a certain speed, and then  you pitch the rocket over.  So the Saturn V pitched over five degrees.  So let's just watch to see what that looks like.  So after that five-degree pitch maneuver, you just let the engines point straight down  and let gravity do the rest of the work for you.  You don't do any other control input after that until you're out of the atmosphere.  This is the real follow-up 13 launch.  It's a little harder to see, but I want you to listen to what Jim Lovell says.  So it's kind of hard to hear, but what he says is, roll and pitch program complete.  So the rocket would roll slightly, and then it would just pitch over a little bit.  The reason we don't do more guidance during this part of the flight in the atmosphere  is because the rocket is actually very fragile.  It's under a lot of forces, both from the enormous rocket engines underneath, and the  atmosphere pushing against it.  This is the actual constraint.  You couldn't move more than one degree per second in pitch and yaw.  There's just too much aerodynamic forces working on the vehicle for us to do anything  else.  Once you got out of the atmosphere, Apollo did something called iterative guidance mode.  It had a bunch of different modes, and it's really complicated.  It's a closed-loop guidance algorithm, which just means that at that point that it could  take into account where it was, where it wanted to be, and then it would make the corrections.  You could only do that outside of the atmosphere because that was the place where you could  maneuver.  They used something called linear tangent steering, which is a bunch of spherical trigonometry  that I'm not going to explain other than to say that's what it looks like and that's  what our program is going to use.  If you start accounting for things which the linear tangent steering algorithm doesn't,  like the Earth, not being flat, and the Earth's gravity varies, and all these other things,  it starts to get really complicated really quick.  I'm not going to talk too much about closed-loop guidance.  The last thing, as the Saturn V comes off the pad, it does what's called a yaw maneuver.  It tilts slightly and then goes back up straight.  The reason it does this is because they just want to avoid a wind blowing it back into  the tower.  If an engine blows out as you come off the pad, you don't want the rocket to tilt back  into the pad.  That program would look a bit like this in Ruby.  We tilt over about a degree and wait eight seconds and then go back up straight.  That's called a yaw maneuver.  I couldn't find a good video of the Saturn V doing this, but here's Antares' rockets,  a more modern rocket doing the same maneuver.  Notice the wind coming in from the right-hand side of the screen.  And we have ignition.  And we have lift-off.  And there's that tilt.  And then it goes back straight.  It's really subtle, but it just keeps you from falling back into the pad.  Okay, so this is our task.  We're going to ignite the engines, wait for them to come up to thrust and lift-off.  We're going to do a quick yaw away from the tower, accelerate 200 meters per second, then  pitch eastward five degrees.  Then we're going to disable the pitch control on our autopilots.  That'll just let the rocket slowly tilt just with gravity.  And then we'll wait until we're through the atmosphere, when dynamic pressure on the  rocket is low.  Then we'll begin close-loop guidance and then burn until our, the periaxis, that's the  lowest point in our orbit.  So we'll burn until the lowest point in our orbit is basically in space.  Remember when I talked about how liquid fuel in a rocket can get sloshed around?  So they didn't hot stage on the Apollo and the Saturn V. What they did was they had these  things called Ullage motors.  They're solid fuel rockets on the side of the stage that basically sort of ignite before  the main engines and then get the rocket moving so that the fuel settles and then they light  the main liquid engines.  It's another great scene in Apollo 13, so I'll just point out the Ullage motors in  here.  That's the first stage.  All right, look.  Looks good.  It's live right down the middle.  We see your VPC is clear 13.  Roger.  EDS to manual.  Inboard.  Get ready for low charge, fellas.  We're at the first stage.  Notice how they slow down.  There's the Ullage motors and then you see the second stage actually light.  Okay, so this is what it looks like in Kerbal Space Program.  We're on the pad ready to launch.  We start a new RGC process.  We just start the executive in a loop.  That's it.  Very simple.  We ignite the engines.  So that's the control object.  Light, wait until the thrust comes up to 60%.  And then we activate the next stage, which releases the rocket from the tower.  And we'll request core sets for our gravity turn and a staging job.  So that will control the actual rocket's stages separating.  And then we kill this process, this core set, and let someone else use the core set.  There we have lift off, lifting off the pad.  On a way to orbit, first stage.  This is what the gravity turn task ends up looking like.  You wait until you're over 100 meters per second.  Pitch over six degrees in this case.  And then we disable the autopilot down here after we've waited 15 seconds.  And that will just let the gravity turn slowly turn you over.  There's the Ullage motors firing for the second stage.  There's the interstage fairing dropping off.  There's a staging job just basically says, hey, if there's an engine in this stage,  wait until it's out of fuel, when it's out of fuel stage.  And we're on a way to orbit.  I've a very simple closed loop guidance job.  It's not closed loop, actually.  And we just slowly pitch over the rocket at a predetermined angle.  And that's separating off the third stage.  And there we are in orbit.  So that's how you get to orbit with Ruby.  Thank you very much.  I was going to go a little quick there at the end because I realized I'm really low on time.  But I do want to take at least one question.  I have the code and the text for this talk at that GitHub address.  Any questions?  Did I ever turn off the garbage collector? No.  I didn't go that deep.  Anybody else?  Any questions about the Apollo guidance computer? Yeah.  Like a couple hours.  No, I don't know what to picture me next to the code for now.  It's only a couple hundred lines.  It's really not that much code, actually.  Definitely less than 70,000 lines of assembler. Yes.  Sorry, can you say that again?  Why are we not recreating another Apollo mission?  So, yeah, obviously this is only the launch.  That's actually like the simplest phase.  In the real Apollo program, the launch was not controlled by the guidance computer at all.  It was a separate computer called the LVDC.  That was actually mounted in the Saturn rocket itself.  The mission program for the Apollo are actually way more extensive.  Landing on the lunar surface was extremely complicated.  So, the answer to that is probably not, because it's really complicated.  But it's a fun way to play Kerbal Space Program just to reduce yourself saying,  hey, I can only write Ruby to control the rocket, but it makes everything take really long.  Anybody else? Yeah. How many times did I crash?  Dude, it's awful.  So, remember I said it takes about 12 minutes to get to orbit.  So, the only way to test your program is to go to orbit.  So, if you have a problem that happens 11 minutes in, it's like,  well, now I have to go restart and wait 11 minutes again to see if I fix it.  So, it took forever. Yeah.  Why didn't I try parallel testing?  Five rockets. That's a good idea. Yeah. My rig is not that good.  I think I could run the very resource intensive program.  Yeah. You could not run Kerbal Space Program on the Apollo guns computer.  All right. That's my time. Thank you.  Thank you.
Orbital_Rocket_Guidance_with_Ruby_0_47.png Orbital_Rocket_Guidance_with_Ruby_48_131.png Orbital_Rocket_Guidance_with_Ruby_132_515.png Orbital_Rocket_Guidance_with_Ruby_516_2411.png Orbital_Rocket_Guidance_with_Ruby_2412_2471.png Orbital_Rocket_Guidance_with_Ruby_2472_3311.png Orbital_Rocket_Guidance_with_Ruby_3312_3527.png Orbital_Rocket_Guidance_with_Ruby_3528_3875.png Orbital_Rocket_Guidance_with_Ruby_3876_4031.png Orbital_Rocket_Guidance_with_Ruby_4032_4151.png Orbital_Rocket_Guidance_with_Ruby_4152_4487.png Orbital_Rocket_Guidance_with_Ruby_4488_4667.png Orbital_Rocket_Guidance_with_Ruby_4668_4715.png Orbital_Rocket_Guidance_with_Ruby_4716_4775.png Orbital_Rocket_Guidance_with_Ruby_4776_5519.png Orbital_Rocket_Guidance_with_Ruby_5520_9059.png Orbital_Rocket_Guidance_with_Ruby_9060_9863.png Orbital_Rocket_Guidance_with_Ruby_9864_11915.png Orbital_Rocket_Guidance_with_Ruby_11916_15059.png Orbital_Rocket_Guidance_with_Ruby_15060_16187.png Orbital_Rocket_Guidance_with_Ruby_16188_16487.png Orbital_Rocket_Guidance_with_Ruby_16488_21803.png Orbital_Rocket_Guidance_with_Ruby_21804_23315.png Orbital_Rocket_Guidance_with_Ruby_23316_29591.png Orbital_Rocket_Guidance_with_Ruby_29592_30731.png Orbital_Rocket_Guidance_with_Ruby_30732_33899.png Orbital_Rocket_Guidance_with_Ruby_33900_34067.png Orbital_Rocket_Guidance_with_Ruby_34068_40079.png Orbital_Rocket_Guidance_with_Ruby_40080_40727.png Orbital_Rocket_Guidance_with_Ruby_40728_41207.png Orbital_Rocket_Guidance_with_Ruby_41208_43439.png Orbital_Rocket_Guidance_with_Ruby_43440_45215.png Orbital_Rocket_Guidance_with_Ruby_45216_45395.png Orbital_Rocket_Guidance_with_Ruby_45396_46391.png Orbital_Rocket_Guidance_with_Ruby_46392_47075.png Orbital_Rocket_Guidance_with_Ruby_47076_49019.png Orbital_Rocket_Guidance_with_Ruby_49020_49187.png Orbital_Rocket_Guidance_with_Ruby_49188_54863.png Orbital_Rocket_Guidance_with_Ruby_54864_55655.png Orbital_Rocket_Guidance_with_Ruby_55656_55787.png Orbital_Rocket_Guidance_with_Ruby_55788_56171.png Orbital_Rocket_Guidance_with_Ruby_56172_56351.png Orbital_Rocket_Guidance_with_Ruby_56352_56423.png Orbital_Rocket_Guidance_with_Ruby_56424_56591.png Orbital_Rocket_Guidance_with_Ruby_56592_56795.png Orbital_Rocket_Guidance_with_Ruby_56796_56855.png Orbital_Rocket_Guidance_with_Ruby_56856_57503.png Orbital_Rocket_Guidance_with_Ruby_57504_57599.png Orbital_Rocket_Guidance_with_Ruby_57600_57695.png Orbital_Rocket_Guidance_with_Ruby_57696_58115.png Orbital_Rocket_Guidance_with_Ruby_58116_58271.png Orbital_Rocket_Guidance_with_Ruby_58272_58487.png Orbital_Rocket_Guidance_with_Ruby_58488_58823.png Orbital_Rocket_Guidance_with_Ruby_58824_59399.png Orbital_Rocket_Guidance_with_Ruby_59400_62819.png Orbital_Rocket_Guidance_with_Ruby_62820_62879.png Orbital_Rocket_Guidance_with_Ruby_62880_63047.png Orbital_Rocket_Guidance_with_Ruby_63048_63073.png
Keeping an eye on that power transfer at T minus 50 seconds. The F4B propellant, now all pressurized. The F4B propellant, that's the third stage of the Saturn V pressurized. One minute, 15 seconds and counting. The spacecraft equipment now is on its own internal cooling. It's been sharing its cooling, getting its cooling from an external power source up to this time. We're now approaching the T minus one minute mark. T minus one minute. T minus one minute and counting. We may get even a little buffering today because of our countdown. We get quite a shaking here. That's a 30 second mark. They keep that down, you're right. Interesting. Let's see if we can place the plate together. We pass the T minus 50 second mark, the power transfer takes place. First stage, second stage, third stage and the instrument unit going to internal power. T minus 37 seconds and our count continues to go well. We'll be looking for an ignition of those five first stage engines at the T minus 8.9 second mark. We pass T minus 30. T minus 25 seconds and counting and Apollo 13 is go. T minus 20 seconds. T minus 20 seconds and counting. 17 guidance release. 15, 14, 13, 12, 11, 10, 9, 8. Ignition sequence has started. 6, 5, 4, 3, 2, 1. My name is Nate Berkepeck. I am the mission control director for the Ruby Space Program. As you know, we've had a lot of budget cuts over the last couple of years. You are here today to learn how to program a spacecraft computer in the Ruby programming language. Obviously, Ruby is not known for its aerospace applications, but we're not going to let that one stop us. Like I said, my name is Nate. I know nothing about space. I have no background in space at all. In fact, all I do is write about how to make Ruby web applications faster. I have no qualification for this, but that doesn't stop me from teaching this session. We're going to be using a program called Kerbal Space Program. Kerbal Space Program is a video game that simulates spacecraft and space launches. It's more known for its wacky, weird stuff that people do in it like this. It's just a physics sandbox. People do this crazy stuff in it. That's probably your experience with Kerbal Space Program. It's also an extremely accurate physics simulator. It will simulate something called the Janibikov effect. Janibikov was a Soviet cosmonaut. The Janibikov effect basically just shows that an object that rotates is stable in two axes, but not on the third. That's Kerbal Space Program there. What you saw before was an experiment on the ISS. It's actually an extremely accurate physics simulation, which means we can use it to simulate real-world space launches. We're going to use a mod compilation called Realism Overhaul, which takes Kerbal Space Program's universe and turns it into a model of the actual solar system. We're going to use that today to launch a Saturn V rocket into orbit using a program written in Ruby. The Ruby part is going to be managed by a library called KRPC, which stands for Kerbal Remote Procedure Call. It basically just turns any running Kerbal Space Program into an API that you can make calls to. It's managed by Google Pro of Ups. There's a Ruby client library. It's really slick. Basically you can control anything in Kerbal Space Program that you could control normally with a keyboard or joystick or whatever. Here's an example program for KRPC written in Ruby. We just require it. We connect to a running Kerbal Space Program with KRPC installed. Then we've got this vessel object, which is going to contain all of our telemetry, like how fast we're going, which way we're pointed. We've got a control object, which will let us do things like change the throttle, activate the next stage, and stuff like that. I've used pry here to just open up a console and let me play around with the different objects that KRPC makes available. How are we going to design a program to get us to orbit? I want to look at some of the space computers of the past. Space computers have to be three very important things. They have to work in real time. That just means that rocket launch is a pretty fast and furious thing. These computers have to do their calculations quickly. They have to interact with astronauts in real time as well. astronauts have to interact with this computer. Back in the 1960s, that was when you would put a punch card into a machine and get a result 10 minutes later. A real-time computer back then was sort of this new novel thing. Computers also have to be extremely reliable. The Apollo Guidance Computer actually had all of its components in triplicate. If there was a sensor, you had three sensors. If one sensor was reading incorrectly, you took the result from the other two. This kind of stuff was done because space is an extremely harsh environment. It's got vacuum. The temperatures can vary wildly. And of course, if this computer stops working, people are probably going to die. So our space computers have to be extremely reliable. They also have to be simple and they have to work in simple ways. Because mostly because of the reliability requirements here, it's difficult to send a very complicated computer into space. We have to send simple computers into space so that we know that they'll work. The origins of space computing go back to this guy named Charles Draper who ran the Draper MIT lab. He was actually the guy that got the Apollo Guidance Computer contract. In the 1950s, he basically put a bunch of gyroscopes and accelerometers into the back of a plane and let the plane fly itself with no external landmarks from the east coast to the west coast. And it was only off by a couple of miles when it got all the way to San Francisco. So no navigation with landmarks, just the gyroscopes and the accelerometers. That's Draper right there on the right. And that's obviously really important for space guidance because in space there is no reference point. We have to navigate without any external references and keep track of our position. Also in the 1950s, we were doing something called building sounding rockets. Building sounding rockets are upper atmosphere research rockets. They basically go straight up and then do some experiments in the upper atmosphere and then fall back down to earth. The most common one that the US built was called the Aerobie rocket. That's that second one there. What's one I'm going to talk about? So the Aerobie had two stages. The top stage here was a sustainer stage. It was liquid fuel. The really short stage here on the bottom is a booster stage. It's made with solid fuel. It only lasted about five seconds. Its job was to get the rocket off the pad. Let's take a look at the Aerobie launch here. A camera is adjusted in an Aerobie rocket which is going to penetrate outer space on a photographic mission. The sky is the limit. Here's the view from 50 miles up. The second boost from the rockets and if you look back over your shoulder, this is what the world looks like a hundred miles away. I feel terrible. How do you feel? The reason the view is spinning there is because the rocket itself is spinning. Most sounding rockets were spin stabilized. That just means that the fins on the rocket are canted slightly to one angle which imparts a spin on the rocket as it accelerates through the atmosphere. That's because a spinning rocket is more stable than one that's just going straight up because it keeps its position upward because it's spinning. It's the same way a gyroscope works which is what we'll talk about in a little bit. If we want to write an Aerobie program to guide a sounding rocket into the upper atmosphere, we have three important things we need to do. We need to detach from the launch power when thrust is at maximum. Most rockets do not immediately have full thrust available when you like them. It takes a while for the thrust to build to lift off thrust. If we just detach the launch pylon immediately, our rocket will just fall over and then shoot off to the side. We shouldn't do that. We have to wait until the thrust is all the way up to where we want it to be. Seconds before the booster stage, that's this stage right here and the right cuts out. We need to light the second stage. We have both stages firing at the same time. The reason we do that is because the second stage, like I said, is liquid fuel. It's a bunch of liquid jet fuel, rocket fuel, sloshing around in the tank. If the first stage cuts out and the second stage isn't already going, you'll go from about two Gs of acceleration to nothing. The fuel in the second stage will start to slosh around. Then there's nothing pushing the fuel into the engine itself. Then the engine won't start and you screw. You need to start the second stage before the first stage burns out. That's called hot staging. The stages were actually connected with a little cage. There wasn't a solid bearing on the outside, so the thrust could get out. You'll see the cage in a second. Then when we run out of fuel on the first stage, we separate the booster stage and let it fly away. Then we go into the upper atmosphere. Let's just take a quick look at what that looks like in the Kerbal Space Program. We've got a client object from CARAPC that we connect to. We activate the first stage, which is the ignition of the engines. We wait until the engine comes up to 60% of maximum thrust. That's enough to get us off the pad. Then we activate the next stage, which is to detach the launch pylon. The rocket launches. Then we've got to hot stage and detach the first stage. We're just going to take note of how much fuel we have in the first stage fuel tank. When we have about 10% remaining, we'll activate the second stage, the sustainer rocket. Then when we run out of fuel, we will activate the next stage, which is the detaching. It looks a little bit like this. That's the booster stage on the bottom. Here's the cage. There goes the sustainer stage. It'll go up to 100 miles or whatever. See, it's spinning there too, obviously. That's an unmanned sounding rocket. Very simple. Let's talk about manned spaceflight. The Soviets, who we were obviously in a space race with at the time, had a very different idea of what the role of a computer was in a manned space program. In the Soviet space program, the astronauts themselves were like spam in a can just along for the ride. Everything was automated. The reasons for that are sort of multiple, but mostly it was the Soviets did not want their space program to fail. They thought that the political consequences of a failed launch would be too much, so it was better to have it all automated and run by machine rather than down the sub monkey and capsule. What they did was they built these electromechanical computers. This is the Globus IMU unit that was flown in the Bokshad spacecraft. Versions of this were flown until 2005 in the Soyuz. The Soviets did not have a computer on their rockets with circuits in it, a digital computer, until 1980. As you can see, this is sort of like a steam clockwork kind of looking thing. The reason they did this was because it is very easy to formally verify something with switches and gears rather than something with circuits. It is a little bit less complicated. Something that you can definitely trust will do what you tell it to. The AGC was a little different. It was a digital computer. In fact, it was one of the first, especially at that form factor. This is the AGC itself. It is 70 pounds, most of which is the aluminum casing on the outside there. It was probably about the size of a modern PC tower. It is about this big. That thing on the right is the display keyboard. It makes the computer look smaller, but that disk is actually really big because it had to be big enough for fat finger astronaut spacesuit people to use it. It makes the AGC itself look a little smaller. A lot is made about how limited the AGC was. It was. 32K of ROM, 2K of RAM, and a 2MHz clock cycle. There were two of these. There was one in the command module and one in the lunar module. I guess you had a massive 64K of ROM. That's all it takes to get to the moon. How do you get to the moon with that sort of limited amount of resources? The answer is twofold. One you have to be really careful. Basically you're writing in a simple. You have much more control over all the resources. There's no operating system to get in your way. That thing is done pretty much like it's the computer equivalent of building a ship and a bottle. It's very minute. The programs themselves are totally handcrafted. Also you have a crap ton of money. The program itself costs 45 million at the time. That's 350 million in today's dollars. The program itself, the AGC code, ends up being about 70,000 lines of assembler. That's like $5,000 a line. So when you have a NASA budget, it's a little easier to grab stuff than the really tiny computers. But that's not to say that this wasn't a difficult mission. Just the transglutor injection itself. The AGC really did its job from basically after we left Earth orbit and then all the way back home to landing on Earth. That's kind of when the AGC was controlling the mission. So the transglutor injection, which is what got you from Earth orbit to Moon orbit, you can think about that as if trying to hit a moving target 500,000 kilometers away while you're on a train that's going around a curve. You're doing that with however many million pounds of rocket crust behind you. So it's a very difficult problem. There was no floating point operations. It was all fixed point. You had a 15-bit word size. So you could only represent in one register numbers from zero to 32,000 unsigned. So it's pretty amazing accomplishment for sure. One of the great things about the AGC is it's extremely well documented. We have all the source codes from the Apollo 11 mission. It's been hand transcribed and scanned in. It's on GitHub. And people have built their own AGC simulators and AGC replicas from this documentation. There's one online called MoonJS. It's written in JavaScript and uses ASM.js. And you can play with an AGC emulator. It's really cool. It's running the Disci Light Check program in this shot. We've seen this picture before. Yeah, it got kind of popular. It kind of blew up on social media. So who can tell me who this is? Margaret Hamilton. Yeah, so Margaret Hamilton was the director of flight software for the Apollo program. This picture is sometimes captioned as standing next to the code she wrote for the Apollo program. Of course, she didn't write the program herself. I think it kind of undersells her accomplishments because she was the software person for the Apollo program. That was her $350 million going into that project. Margaret Hamilton ended up being a real sort of thought leader in the field of software reliability and formal systems. It did a lot of work after the Apollo program on that as well. And like I said, the Apollo source code, the guidance for the source code itself is only 70,000 lines. That's probably like one of these phone books. So she's probably standing in front of multiple iterations of the HCC code. And it's worth remembering that Margaret and everyone else that worked on the Apollo guidance computer had no formal training. Computer science is not a thing at this point. You couldn't take a class anywhere on it. Almost everything that they did for the Apollo guidance computer, people were doing for the first time. Like I said, it's all available on GitHub. This is the Apollo 11 code. They would make little changes to each mission code as they went along. They have a pretty good sense of humor. This was the name of the routine that controlled the engines. So this was the 60s, right? So this was a reference to the LA riots and the Black Power movement at the time. This one, I'm going to give you a guess as to what this controlled. This was the disky control for the keypad and all the associated lights on it. I like this one. Booter landing guidance equations. Yeah, I got it in the mood. This is a good one. So the Booter module had a landing radar that had to be pointed at the ground. And if it wasn't pointed in the correct position, this routine got called and asked you to please crank the silly thing around, like crank the radar around, see if he's lying and whether or not he did it. And then off to see the wizard, that will go to the bird baby bird. Oh, this isn't really showing up. So even though this program is 50 years old, it doesn't stop people from opening new issues on GitHub about it. This is obviously referring to the Apollo 13 explosion. So one of the difficult things about the space mission is you have to do a lot of different things at once. During the launch, for example, we're going to have to keep track of what stage of the rocket we're in and whether or not we're out of fuel. Plus we had to keep ourselves pointed the right way. So it's an inherently multitasking sort of problem. At the time, multitasking was pretty new. This guy, Hal Lanning, was the guy that designed basically the operating system for the AGC. It wasn't a real operating system. It just sort of managed all the different processes that were running. It was called the executive. And Hal kind of just made it up. No one had ever done this sort of thing before. So Hal was like, yeah, I guess I have to invent priority based multitasking. So before the AGC, what you did to share time between programs was something called the box car method. Basically it's time slicing. So you split a second into smaller intervals and you give an interval to a program. And then when you're done with that interval, you switch to the next program, the next interval. It's like a box car passing by on a train. And the problem with that is what is the thing that you're doing right now is really important. It's more important than the next box car. You're working on the guidance equations right now and then the light update program wants time. Well, obviously we shouldn't do that, right? So Hal invented priority based multitasking. So this is a Ruby representation of how the AGC worked. The AGC had seven core sets. A core set was an area that a job was assigned. It was their sort of memory space. It was only 15 bytes. And only seven of those bytes were available to the programmer to use for scratch space and memory. So if you could imagine writing a method that can only take seven bytes of memory, that's what the AGC programmers had to deal with. It would also keep track of where it was in its routine. That's the app, LOC. And each core set had a priority. So higher priority core sets would run before the other ones. The executive would always run the highest priority core set job first. And a core set with a priority of zero was available. It didn't have anything going on. So you could only have seven tasks running at any given time. So if you want to ask for a new core set to run a new job, we give it a priority. We look for an empty entry in the core set table. And then we're going to give it a fiber. So most multitasking in the AGC was done cooperatively. There were interrupts. There was software interrupts. But it wasn't done very often because obviously interrupting a computer with like, you know, 15 registers at any given time would be dangerous because things get out of order and then you're screwed. So they tried not to use interrupts and mostly used cooperative multitasking. So we have that in Ruby with fibers. That's what we're going to use to emulate it. And then we just set a priority to whatever we want. Okay. A job itself is just going to be a class. And we're going to delegate a bunch of plumbing back to the core set so we can get access to like, our telemetry and stuff like that. Here's an example of a job. This will just print the priorities of all the current core sets. So we just go through the core set table and print the priority. And then we're going to yield with a fiber. At this point we'll yield control back to the executive. The executive will then decide if this gets to run again or not. When we call fiber.mzume, we enter here and go back to the beginning of the loop and so on and so forth. Okay. So this job just runs over and over and over and it doesn't do anything else. Obviously, okay. So then this is what the actual executive routine looks like. We sort the core set table by priority, highest priority at the top. We take the highest priority job. We call it resume on that unless it's priority zero or less than zero because then it's available. And if we fiber.yield with a kill symbol, we're going to say that's when this task, this job is done, make that core set available. Yeah. So when we're going to try to get the agency working, the, so that's a core set printer program. It would just run over and over, right? So that's not very useful. Like what if we only wanted to print the core set priorities every five seconds? Well, we can do that with something called the wait list. This was sort of the way that you manage scheduled work on the agency. The wait list was also about seven entries long. What it would do would, so the, any task on the wait list only had six milliseconds allotted to it to run. The wait list tasks were basically just like, hey, schedule this job, manipulate the priority of this other job. They were very quick little things that got scheduled for the future at a particular time. One thing that was used a lot for, and what we're going to use a lot for in our program is to sleep or delay a job. What we're going to do is just reverse the priority of the job. So if a job is priority 10, we'll make it priority negative 10 and give it a time to execute in the future. And then we'll just go through the wait list every once in a while and say, hey, is there anything in the wait list whose time has come and then just quickly call it. We'll just give it a block. We'll call the block. That's our wait list. That's exactly, the wait list is just straight from how the UTC actually worked. The AGC had a requirement that it had to be able to restart at any time. Part of this is because power was unpredictable. If power could spike to go down in any time and then the AGC would have to shut off, it would have to restart from where it was. It also used restart as a way to turn it on and off again and fix the problem. We'll get back to that in a minute. We can emulate this by just Marshall dumping the core set table and then reloading it again. It's kind of the not super accurate way of doing this. In AGC, jobs could actually sign up for different kinds of restart protection. You could register a waypoint during your routine and say, if we restart, please restart here. Things like that. It's way too complicated. We're not going to bother with that. This is, you could also stop reset. There was a button on the AGC to reset. We're going to emulate that by just clearing out the core set table in the wait list. The only thing that really enforced how much time a job could take was something called the night watchman. It was sort of a last resort. There was really nothing that said that, oh, you have to check the return control every once in a while or whatever. It was assumed that you would return control to the executive every 20 milliseconds, but that wasn't strictly enforced. There was something called the night watchman, which I don't remember the interval in the AGC. It would just, if you hadn't checked into the executive at a certain period of time, it would blow up and restart the whole computer. That's what we're going to do here. We're just going to start a thread, and every one second, if the main routine has not been run, that will blow up. That will restart. The restart protection actually came in very handy during the Apollo 11 landing. This is somebody's model of an AGC, and it's going through the moon landing. You'll hear the astronauts in the background. Let's just watch. That clicking noise is the actual display itself. You can hear the tone of his voice there. A program alarm was something that the executive would raise when it had a problem. How do you get a voice coming in? Right there. All clear, down here. Copy, all clear. All clear. It's true, everything has wound up when it hits the tune. So this is as they're coming down to the moon surface suddenly they're getting this computer error right and he's like give us a read in the 1202 program alarm because they were putting their hand over the abort button thinking well this is it like we're not going to make it to the moon. A 1202 alarm is what happened in the core set table overflow. That just meant that basically the computer didn't have enough time for all the work that it was doing. It would raise the 1202 alarm and you would reset the computer and hope that it didn't happen again. That's really actually what they did on the way down to the lunar surface. They would just keep restarting the computer every time that this alarm happened. It was caused by this the landing radar had like a power problem and was sending too many interrupts to the processor and overloading it. They never actually did fix that. They just changed the procedure during landing so that it wouldn't occur. So we're going to write our launch program now. So what do we have to do? We have to guide the spacecraft. Guidance is just where do you want to go? What is the exact path that we're going to take to orbit? It was an extremely important task in the Apollo guidance computer obviously. How do you get down to the surface of the moon? Navigation is where are you right now? So where are you pointed and how fast are you going? So I was talking about gyroscopes earlier. The Apollo guidance computer had something called the IMU. It's the inertial measurement unit. It was just a bunch of spinning gyroscopes and accelerometers. A gyroscope works like this. This is actually Draper himself demonstrating this. So you see how the spinning disk there is keeping its orientation even as the frame is being moved? So that's all a gyroscope does. It provides a stable platform that you can make a reference against. If the gyroscope got out of whack, which it did every like day, it would eventually just become inaccurate, you actually used a sextant, which I think is kind of amazing. They had a sextant built in to both the command module and the litter module. You take some star sightings and then reset where you were. Pretty amazing technology from literally the 1500s. The third task we have to do is control. We have to control the rocket. Nothing in the Apollo program was manual. Everything was fly by wire. Everything went through the computer. Part of this is because flying in the spacecraft is actually very complicated. The litter module, if you look at it, it's asymmetric. So if you have an asymmetric rocket with an engine directly underneath, that's actually very difficult to control. It's like trying to balance a broomstick on your finger, but the broomstick is bent. That's actually kind of complicated to think about and work with. So everything went through the computer and it corrected for that. But today we're just going to talk about guidance. KRFEC and Kerbal Space Program basically do the navigation and control part for you. So we're just going to talk about guidance. We're going to go to orbit. The orbit is fundamentally about taking a rocket, which is moving zero miles an hour and pointed straight up and going to 200 kilometers above the Earth and moving at 17,000 miles an hour sideways. The 75 had three stages, which would accomplish this. The launch profile took about 11 or 12 minutes to get into orbit. This path, this curve path, was something called a gravity turn. A gravity turn is usually implemented as an open loop algorithm. It just means that it doesn't take into account the exterior state of the vehicle. It's just sort of a pre-programmed thing. Go up a certain amount, turn this way, and then wait. It's not saying, okay, let's figure out where we are and make some corrections. It doesn't do any of that. That's a closed loop guidance algorithm. So we start with open loop guidance. Gravity turn looks like this. This is from a SpaceX rocket launch. So you go up a little bit, and then you turn the rocket over, and you let the force of gravity slowly tip the rocket over as you go to space. So the way to orbit looks like this long elliptical path. Moving a follow-up 13 actually gets the gravity turn maneuver really right. So gravity turn maneuver, you go up until you're moving at a certain speed, and then you pitch the rocket over. So the Saturn V pitched over five degrees. So let's just watch to see what that looks like. So after that five-degree pitch maneuver, you just let the engines point straight down and let gravity do the rest of the work for you. You don't do any other control input after that until you're out of the atmosphere. This is the real follow-up 13 launch. It's a little harder to see, but I want you to listen to what Jim Lovell says. So it's kind of hard to hear, but what he says is, roll and pitch program complete. So the rocket would roll slightly, and then it would just pitch over a little bit. The reason we don't do more guidance during this part of the flight in the atmosphere is because the rocket is actually very fragile. It's under a lot of forces, both from the enormous rocket engines underneath, and the atmosphere pushing against it. This is the actual constraint. You couldn't move more than one degree per second in pitch and yaw. There's just too much aerodynamic forces working on the vehicle for us to do anything else. Once you got out of the atmosphere, Apollo did something called iterative guidance mode. It had a bunch of different modes, and it's really complicated. It's a closed-loop guidance algorithm, which just means that at that point that it could take into account where it was, where it wanted to be, and then it would make the corrections. You could only do that outside of the atmosphere because that was the place where you could maneuver. They used something called linear tangent steering, which is a bunch of spherical trigonometry that I'm not going to explain other than to say that's what it looks like and that's what our program is going to use. If you start accounting for things which the linear tangent steering algorithm doesn't, like the Earth, not being flat, and the Earth's gravity varies, and all these other things, it starts to get really complicated really quick. I'm not going to talk too much about closed-loop guidance. The last thing, as the Saturn V comes off the pad, it does what's called a yaw maneuver. It tilts slightly and then goes back up straight. The reason it does this is because they just want to avoid a wind blowing it back into the tower. If an engine blows out as you come off the pad, you don't want the rocket to tilt back into the pad. That program would look a bit like this in Ruby. We tilt over about a degree and wait eight seconds and then go back up straight. That's called a yaw maneuver. I couldn't find a good video of the Saturn V doing this, but here's Antares' rockets, a more modern rocket doing the same maneuver. Notice the wind coming in from the right-hand side of the screen. And we have ignition. And we have lift-off. And there's that tilt. And then it goes back straight. It's really subtle, but it just keeps you from falling back into the pad. Okay, so this is our task. We're going to ignite the engines, wait for them to come up to thrust and lift-off. We're going to do a quick yaw away from the tower, accelerate 200 meters per second, then pitch eastward five degrees. Then we're going to disable the pitch control on our autopilots. That'll just let the rocket slowly tilt just with gravity. And then we'll wait until we're through the atmosphere, when dynamic pressure on the rocket is low. Then we'll begin close-loop guidance and then burn until our, the periaxis, that's the lowest point in our orbit. So we'll burn until the lowest point in our orbit is basically in space. Remember when I talked about how liquid fuel in a rocket can get sloshed around? So they didn't hot stage on the Apollo and the Saturn V. What they did was they had these things called Ullage motors. They're solid fuel rockets on the side of the stage that basically sort of ignite before the main engines and then get the rocket moving so that the fuel settles and then they light the main liquid engines. It's another great scene in Apollo 13, so I'll just point out the Ullage motors in here. That's the first stage. All right, look. Looks good. It's live right down the middle. We see your VPC is clear 13. Roger. EDS to manual. Inboard. Get ready for low charge, fellas. We're at the first stage. Notice how they slow down. There's the Ullage motors and then you see the second stage actually light. Okay, so this is what it looks like in Kerbal Space Program. We're on the pad ready to launch. We start a new RGC process. We just start the executive in a loop. That's it. Very simple. We ignite the engines. So that's the control object. Light, wait until the thrust comes up to 60%. And then we activate the next stage, which releases the rocket from the tower. And we'll request core sets for our gravity turn and a staging job. So that will control the actual rocket's stages separating. And then we kill this process, this core set, and let someone else use the core set. There we have lift off, lifting off the pad. On a way to orbit, first stage. This is what the gravity turn task ends up looking like. You wait until you're over 100 meters per second. Pitch over six degrees in this case. And then we disable the autopilot down here after we've waited 15 seconds. And that will just let the gravity turn slowly turn you over. There's the Ullage motors firing for the second stage. There's the interstage fairing dropping off. There's a staging job just basically says, hey, if there's an engine in this stage, wait until it's out of fuel, when it's out of fuel stage. And we're on a way to orbit. I've a very simple closed loop guidance job. It's not closed loop, actually. And we just slowly pitch over the rocket at a predetermined angle. And that's separating off the third stage. And there we are in orbit. So that's how you get to orbit with Ruby. Thank you very much. I was going to go a little quick there at the end because I realized I'm really low on time. But I do want to take at least one question. I have the code and the text for this talk at that GitHub address. Any questions? Did I ever turn off the garbage collector? No. I didn't go that deep. Anybody else? Any questions about the Apollo guidance computer? Yeah. Like a couple hours. No, I don't know what to picture me next to the code for now. It's only a couple hundred lines. It's really not that much code, actually. Definitely less than 70,000 lines of assembler. Yes. Sorry, can you say that again? Why are we not recreating another Apollo mission? So, yeah, obviously this is only the launch. That's actually like the simplest phase. In the real Apollo program, the launch was not controlled by the guidance computer at all. It was a separate computer called the LVDC. That was actually mounted in the Saturn rocket itself. The mission program for the Apollo are actually way more extensive. Landing on the lunar surface was extremely complicated. So, the answer to that is probably not, because it's really complicated. But it's a fun way to play Kerbal Space Program just to reduce yourself saying, hey, I can only write Ruby to control the rocket, but it makes everything take really long. Anybody else? Yeah. How many times did I crash? Dude, it's awful. So, remember I said it takes about 12 minutes to get to orbit. So, the only way to test your program is to go to orbit. So, if you have a problem that happens 11 minutes in, it's like, well, now I have to go restart and wait 11 minutes again to see if I fix it. So, it took forever. Yeah. Why didn't I try parallel testing? Five rockets. That's a good idea. Yeah. My rig is not that good. I think I could run the very resource intensive program. Yeah. You could not run Kerbal Space Program on the Apollo guns computer. All right. That's my time. Thank you. Thank you.
to program a spacecraft computer in the Ruby today to launch a Saturn V rocket into orbit look at some of the space computers of the past. extremely reliable. The Apollo Guidance Computer what that looks like in the Kerbal Space Program. the director of flight software for the Apollo for, and what we're going to use a lot for in our not controlled by the guidance computer at all.