Have you ever wondered, how do real-world rocket vehicles get to orbit with such an accuracy, that they meet and dock with a space station traveling at almost eight kilometers per second? The short answer is: through some very ingenious algorithms in their onboard computers. For the long answer: my name is Przemek, and this is Space Shuttle guidance done in Kerbal Space Program. So let’s say we want to deliver some supplies to the International Space Station Now, you’ve flown those missions before in Kerbal Space Program, and you know it’s not so very hard to rendezvous, once we’re in a good orbit. But if your initial orbit is inclined to your target, things get pretty complicated. So the most difficult and important part of such launch is the ascent to parking orbit. And I have created an ascent autopilot that does exactly that. It was programmed in kOS (one of the best mods out there, so do look it up if you don’t know it already) and it uses the Space Shuttle’s algorithm for orbital guidance. My implementation is flexible enough that we can run other vehicles too, so to demonstrate, I’ll use the Atlas V from Real Scale Boosters mod. Now, using my autopilot, flying such missions is as easy as select target and run PEGAS. And the first thing that happens is calculation of the launch window. In fact, it’s just a rough estimate, because in reality it’s very difficult to calculate it precisely, but we’ll make do with that. Fortunately the whole system is fairly insensitive to that and being off by a minute or two shouldn’t be a big issue. From this point, our vehicle is in complete control of PEGAS which handles staging and attitude. So, we have the final countdown there should be the RD-180 ignition and now the AJ-60s and liftoff! Now, there are usually two phases of ascent to orbit: and the first one, we’re in now – atmospheric ascent. And the idea here is not so much about precision of what we’re doing, as is about safety. We just want to get outside the atmosphere in one piece instead of breaking up due to high dynamic loads. So the logic we’re following is taken pretty much straight from ferram’s Realism Overhaul tutorial, so basically pitch over by some known angle and hold attitude prograde at zero angle of attack. And once we’ve gained enough altitude that air density is no longer an issue, then we will switch to orbital ascent using the Space Shuttle algorithm. If you ever heard the word PEG or Powered Explicit Guidance, then this is exactly it, this is one way of referring to it. Now, the thing about most orbital guidance algorithms, Shuttle’s included, is that they do not take atmosphere into account at all. Although take that with a grain of salt, as I don’t know about the most modern algorithms. This is because maths behind aerodynamics are very complex and back then it couldn’t be quickly and reliably solved mid-flight. So, because in that phase the only thing that matters is precision and fuel efficiency, we’re better off waiting till we’re above the air, so we can neglect its effects. And right about now the SRBs should be flaming out and we’re going to jettison them a little later. This is actually what the real Atlas does, it carries them for a few seconds, as it might be unsafe to separate if we’re too low and the air is too dense, so we carry them for a little bit. And now the automatic guidance will engage and take control of attitude. But why the Space Shuttle and why the Shuttle’s guidance algorithm and what’s so special about it? Well, to understand that we need to go back in time to late 1960s when the Shuttle doesn’t exist yet – not beyond drawing boards, proposals and requirements. And two of those requirements are of particular interest to us right now. The first one was the ability of the newly designed vehicle to allow construction and servicing of a low orbit space station, which will be later known as the International Space Station. The other was the ability to retrieve satellites from orbit and not just deliver them. Both those objectives have one thing in common: they share a mission profile of an orbital rendezvous. This isn’t to say that rendezvous was something new, as the concept was demonstrated in the Gemini program before and used extensively in Apollo. Just never before has this kind of mission profile been a routine one. So for this reason, among others, the Shuttle needed an entirely new guidance algorithm. And indeed, in the early 70s the Unified Powered Flight Guidance was designed by the Draper laboratory. It was called “unified” because it was a single program to handle many kinds of flight modes: ascent, abort through orbital maneuvers, up to deorbit burn. Out of those I only implement the standard ascent mode in my autopilot, and I will describe it in a bit more detail in a moment, because now we’re approaching a burn mode change. Previously the engine was set at full throttle, but if we continued on like that, we’d soon reach acceleration in excess of 8 Gs – which isn’t good for the payload at all. So we’re going to throttle down gradually to limit acceleration at about 4.5 Gs. The Shuttle itself had a 3 G limit in place to protect the crew. And another set of pre-timed events occurs now: we first jettison the payload fairing and now the Centaur Fairing Load Reactor. And now we have engine cutoff and a separation sequence, which is controlled by PEGAS, and fully customizable. First the Common Core Booster separates, then ullage motors activate on the Centaur, and there’s the ignition, and UPFG soon after takes control of the attitude again. So let’s see how we’re doing. The orbit looks pretty good and the algorithm reports time to go of about 400 seconds which will be just about enough time to explain the basic principle behind UPFG. But before we focus on “how” let’s answer “what” it really does – the very idea of rocket guidance. As a general principle, we want to steer a known vehicle which has a known current state into some target state which in the ascent mode happens to be some kind of orbit. Now, this orbit is most likely described with a set of orbital elements such as semi-major axis and eccentricity or apoapse and periapse if you prefer, and inclination and longitude of ascending node. It’s very uncomfortable however – if you’ve ever tried changing just your apoapse you know it’s impossible unless you’re currently at periapse. Similar thing with inclination and LAN – it’s hard to change one without the other, which isn’t good for guidance at all. Ideally, we’d like to work with some mathematically sane coordinate system, like Cartesian XYZ system. In XYZ it’s fairly easy to describe our current state, but it’s not the same with a target orbit. After all, orbit is not a single point but a whole ellipse of them, so such description is not really possible. However if we were given some XYZ position and velocity, we could easily verify whether it is a good orbit or not – simply by checking altitude velocity angle and the like. And it turns out, this is enough to do very precise guidance. One remaining thing is the vehicle – after all, we need to know exactly what are we steering. In general, there will be plenty of parameters we could write down about it, but from the point of view of rocket motion, it all boils down to just four: dry mass of the vehicle, mass of the propellant it has in the tanks and parameters of its engines: combined thrust and specific impulse. So basically, how much does it weigh, how hard can it push itself and how efficiently can it do that. And if we have a multi-stage vehicle, there will be those four numbers per each stage – which in turn isn’t so very comfortable to plug into any mathematical equation. So the clever guys from guidance came up with something called thrust integrals. I will not give a detailed explanation of them here, as this would be unnecessarily boring, just outline the greatest advantage they give us. The thrust integrals allow us to coalesce the vehicle description into one set of numbers, irregardless of the number of stages. So, thanks to that, the capability to guide multistage vehicles is kind of built into the algorithm itself. Even though the Shuttle did not really make full use of that, for the major part it was a single stage vehicle, the OMS thrusters were used only to circularize. And it just so happens that I’ve explained the first important part of UPFG: calculation of the thrust integrals. So let’s recap what have we found out so far. We know what vehicle we’re steering, we know where we are we don’t know where we want to be. But we have a way of figuring out whether our destination – if we had one – is a good one. The fact that we essentially don’t know where we’re going might seem like a bit of a problem, but let’s assume for now that we somehow guessed the exact destination. We have some XYZ position and velocity vector. From that we could calculate the distance we need to cover and the velocity we need to gain. This is exactly this velocity-to-go, the v-go marker that you see in PEGAS interface. It can be thought of as maneuver delta-v which you’re used to. Knowing our vehicle, we can also calculate how long will it take to gain that velocity, and this is the time to go – the t-go – marker. Now, there is a technique, known for years prior to the Shuttle, that allows directly calculating pitch and yaw angles, given the current and target states. This is called Linear Tangent Guidance, and it’s the main reason we needed those trust integrals to begin with. It only has one catch: since general solution for gravity and thrust is mathematically difficult, just like aerodynamics, the LTG assumes the Earth is flat, and the gravity vector never changes. Which is obviously wrong, so our result will be wrong because in reality, the spherical Earth’s gravity will pull us down differently. So the guys who designed UPFG came up with a neat way to correct that. They designed a function to predict the future state of a vehicle in free motion under just gravity, called Conic State Extrapolation, and then figured out a way to incorporate thrust into it. This way, they ended up with a decent future state predictor, using which we can: first calculate a rough guidance using Linear Tangent, then use Conic State Extrapolation to find out what the gravity vector really would be like, and save that knowledge for the next run. Plug it back into the LTG, gradually increasing the accuracy of its results. But in fact, the initial inaccuracy might not be only due to bad gravity handling. We simply might have guessed our target wrong – would be good to correct for that too. And the way UPFG approaches that is not by slowly correcting our initial guess. Instead it finds an entirely new target position, that is nearest to the predicted one, and discards our guess at all in the process. And with this new target, the whole algorithm runs again. So, to sum up: we start by guessing some destination, we calculate pitch and yaw angles to get there using Linear Tangent, we use Conic State to correct for the gravity, and we verify our guess in the target by picking a new one. And then we run the algorithm again with that new value. And if we repeat this process several times, the error will get smaller and smaller as we go, and at some point it will become so little, that we might safely say that a true solution has been found – one that has no errors anymore. And when that happens, we say that the algorithm has converged. From then on we can follow its guidance. So there you have it, I hope I have at least outlined the Space Shuttle guidance algorithm. Of course, I didn’t go into much detail as this would be very complex and definitely not just for a 10 minute video. But if you want to know more, do check the description for this one. I’ve written a much more thorough explanation of the algorithm on my github pages. So if you’re interested in the all intricacies and bells and whistles of UPFG, then please do check it out. And right about now we’re getting to the the main engine cutoff, which should be in a few seconds. And there we have it. PEGAS says mission successful so let’s take a look at the parameters: inclination and longitude of ascending node look perfect, angle between orbits: 0 degrees. Apoapse and periapse might look a little bit off, but I think, not sure, but I think they are within actual accuracy limits of the Atlas V vehicle. But let’s see how difficult would it be to plan a transfer maneuver from this parking orbit, if we wanted to rendezvous with the Space Station. So if we just raise our apoapse till we get a little intersect… just like that… and now if we do that a little later, a few orbits later, then we should probably be getting close. Let’s check that out. We should get a pretty reasonable intersect. Oh, there we have it – 200 meters. 200 meters intersect by a maneuver I planned within what, 10 seconds? Well, that’s it, I hope you’ve enjoyed watching it, if you want to test PEGAS yourself, the links are in the description so you can download it right away. Tutorials are included so you can try it yourself with hopefully little pain. Once again, thanks for watching my name is Przemek and that was Space Shuttle guidance algorithm done in Kerbal Space Program. Fly accurately!