Shuttle deorbit burnThe beauty of the Space Shuttle concept is that the end of a nominal mission is an airplane-like landing on a regular runway. To achieve this, the Shuttle needs to be steered into the atmosphere such that the landing site can be reached in aerodynamical flight, i.e. a so-called entry interface (EI) needs to be targeted.
Of course the density of the atmosphere increases gradually as the orbit goes deeper and there is no one point beyond which the Shuttle is 'in the atmosphere', but customarily the EI is defined as 400.000 ft above the surface of the planet. One important concept here is the range from entry interface (REI), i.e. the distance from the point where the trajectory goes below 400.000 ft to the runway.
This perhaps is a good moment to discuss something you might have wondered about when discussing spherical vs. IERS shape of Earth - could we not just forget the shape issue and just plot altitude above mean surface level to get rid of some complications? For many purposes we actually could (what you need depends on mission requirements of course - signal attenuation and radar ranging to the ground will care about the actual altitude, but rendezvous computations will not) - but when trying to enter the atmosphere, we really need the actual altitude above the reference ellipsoid, because that's what will determine the forces.
From the entry interface, there is a coasting period during which aerodynamic forces are increasingly felt till at around 270.000 ft aerodynamics is strong enough to lift the Shuttle and the trajectory can be steered with airfoils.
The aim of the deorbit burn is to steer the Shuttle to the entry interface at the right descent rate such that the coasting phase to 270.000 ft gives a good range to the landing site. Note that it is not enough to just hit the interface with the right REI - if the vertical speed is too large, the coasting phase will come out wrong and no good range can be achieved. As you might have guessed, this is another PEG-4 targeting problem.
Targeting vertical speed constraintsThe spatial location of the EI is determined by the combination of ignition time, transfer angle and target altitude just as in the previous cases which targeted an apsis. How to set the vertical speed?
Remember that the constraint reads v_V = c2 * vH + c1. If we set c1 to some negative value, we directly target a constant descent rate, no matter how our orbit looks before, we'll go down at that rate. Since the horizontal speed at interface depends on how high our orbit was before (descending more means being faster), this implies that the flightpath angle is not a constant - and if the angle is steeper, the coasting phase will be shorter. That's not what we need.
Conversely, if we set only c2, we're fixing the flightpath angle at the interface. This sounds good, unless you look at the actual shape of the orbit as it continues afterwards for a real de-orbit solution - we're in the last portion of the descent, approaching the periapsis, and the descent is typically slowing down. Aka, there is vertical upward acceleration - and that works out stronger if we come from a higher orbit. So while fixing the vertical speed makes the descent too rapid for higher orbits, fixing the flightpath angle makes it too shallow.
The obvious solution is to use a combination. NASA typically uses values like c1 = 14992 and c2 = -0.6017 (again from STS-30) to give a good shape of the part of the orbit below the EI till aerodynamical control starts in earnest.
Programming the burnLet's study this in practice. Create the following file:
Most items should be familiar - we're starting from a post-MECO solution with a high apsis, using a PEG-7 to try to insert but the burn is incomplete, so we're on a somewhat eccentric orbit and use a PEG-4 to de-orbit to a (fictional) emergency landing site that is along the current groundtrack. The PEG-4 is fit to the parameters discussed above. The last interesting item is the instruction to list the position at the entry interface, because we'd like to know how we're positioned relative to the landing site.
Fixing REIRun the file, and the result is the black line below.
Doesn't look too bad, except once you actually look at the range to the landing site produced by the on-screen message, it comes out too large by a few thousand miles (typically we'd like to have around 4000 miles).
So maybe we have a bad transfer angle? Let's increase it by 10 degrees and re-run - this time it came out better, so if we keep increasing it? But if you look at the radial Delta v requirement, it is large and keeps increasing - this is not good. So perhaps we should do ignition later?
You can go on like this, but in fact the whole procedure is screaming to be automated. Which it is - simply add the lines
to the PEG-4 definition and re-run. This time, the fit might take quite a while, but when it eventually converges, it'll deliver you a solution with hardly any radial velocity and a single mile offset to the range you want to target.
In fact, the original transfer angle was quite good for an orbit that high - for a 155 mile orbit, you'd select a much lower value of around 128 degrees - if you fit REI, you might still have radial components due to a poorly chosen transfer angle in the final solution, this is something not (yet) automatically optimized away.
So this is the kind of computation mission control needs to run if there's a problem during the circularization burn - given the current eccentric orbit, get us a solution which brings the Shuttle to the next available emergency landing site with a good REI and the correct angle at interface.
Note that there's no sanity check done whether your interface is reasonable given the landing site - you might specify a situation where you are in fact 3800 miles behind the site, and since the Shuttle can't turn around, that won't work. You have to infer from the geometry (i.e. Delta Az to site) whether this is within capabilities of your spacecraft or not, and the fit is only concerned with getting the situation in the orbital plane under control (largely because plane changes are so propellant-consuming that not much can be done anyway).
Continue with Geosynchronous insertion.
Back to main index Back to science Back to LEO targeting