Useful on-the-fly equations for Orbiter

[Alexrey]

Hi guys,

After using the launch azimuth equation (http://www.orbiterwiki.org/wiki/Launch_Azimuth) with great effect to get to the ISS I thought maybe there where other simple and useful equations that could easily be used on-the-fly to make fairly accurate manoeuvres instead of using MFDs and autopilots (possibly even some differential equations if they are easy enough to interpret and solve, i.e. no n-body systems of equations!). Does anyone know if such a list has been compiled?

 

[Urwumpe]

They are a bit harder to find, but here they are:

http://www.orbiterwiki.org/wiki/Front_Cover_Equations

 

[blixel]

I thought maybe there where other simple and useful equations that could easily be used on-the-fly to make fairly accurate manoeuvres instead of using MFDs and autopilots (possibly even some differential equations if they are easy enough to interpret and solve, i.e. no n-body systems of equations!). Does anyone know if such a list has been compiled?

I started making a "how to calculate stuff" document, purely for my own sake, but you might find it interesting/informative.

https://docs.google.com/document/d/1A3oKluj0-Sc93zYaUqdslh4C5tqBXeVARBWb1odzeuQ/edit

Also, this link dgatsoulis showed me a year or so ago is really useful:

http://www.braeunig.us/space/problem.htm

 

[Thorsten]

I've been looking for guidance to fly without AP and complex MFDs myself, and I think the answer is really that there's not so much around here. When I think about piloting without MFD or autopilot, I need rules of thumb which are 'good enough' such that I can maneuver without working everything out by hand.

Like

* At what distance to base should I start the de-orbit burn dependent on how much acceleration my thruster has?

(for the Shuttle 12.500 km seems to be a good value, the Deltaglider can be a lot closer, 8000 km has worked for me)

* What's the approximate relation between my apogee, my perigee and the vertical velocity with which I will hit the atmosphere, and what's the maximum g-load I can expect?

(I don't really know - I try to de-orbit from 300 - 360 km and get the nominal intersection point of the orbit with the terrain a few hundred km before the base - that leads to survivable g-loads)

* I am trailing an object orbiting in the same plane by d kilometers - how much will I catch up every orbit when I lower my orbit by x km?

(100 km lower seems to get a few hundred km every orbit)

* What Delta v budget does any given spacecraft provide - and what budget do I need to change orbital planes at given altitude, what budget do I need to reserve to de-orbit?

(the DG has plenty, the Shuttle not - apart from de-orbiting and a few minor corrections, the Shuttle can't really do anything).

All these don't need infinite precision, while at the same time the approximate relations must be fairly simple formulae. If we had them, one could actually pilot a bit more by hand, guesstimates sort of work by trial and error, but I find it much more instructive to understand what I'm doing than to follow what an MFD tells me to do.

Just my two cents in any case...

 

[Urwumpe]

At what distance to base should I start the de-orbit burn dependent on how much acceleration my thruster has?

Wrong question. You want to start burning so, that you have approximately produced half of the needed DV at the point of your maneuver. Approx. That kind of targeting works, but is pretty inaccurate.

So, if you have a 150 m/s deorbit burn, you split the burn into two parts: 75 m/s before the maneuver point, 75 m/s after it. If you again use the rocket equation and the data for your thruster, you can calculate now, how much fuel you need (usually the acceleration is not constant), and how long the thruster has to burn to consume the fuel for 75 m/s.

That time is the time you have to start burning before the maneuver point.

The distance between deorbit and landing is more complex. You generally have a point in space called entry interface (EI), which is pretty fixed relative to the base. You have conditions by which you may pass this interface, for example a flight path angle of -1.2°. With that data, you can calculate a transfer ellipse from your current orbit and the entry interface, that fullfills the conditions of the entry interface. Where the transfer ellipse crosses your current orbit is the maneuver point of the deorbit burn and the velocity vector difference between current orbit and deorbit orbit is your DV.

That is, as you can see, still a very simple straight forward process to calculate.

You can add more parameters there if needed. For example you can add a off-plane component to the deorbit burn to intentionally waste fuel for fullfilling weight limits for reentry.

What's the approximate relation between my apogee, my perigee and the vertical velocity with which I will hit the atmosphere, and what's the maximum g-load I can expect?

There is no approximate relation between the values.

For pure ballistic reentries, there is a relation between eccentricity, Sma (and thus apogee and perigee) and the maximum decelleration that you will get, if the reentry angle is lower than -5°

I am trailing an object orbiting in the same plane by d kilometers - how much will I catch up every orbit when I lower my orbit by x km?

Depends on the difference in orbit period, which depends on semimajor axis.

What Delta v budget does any given spacecraft provide - and what budget do I need to change orbital planes at given altitude, what budget do I need to reserve to de-orbit?

See Rocket equation.

Inclination change is

DV = 2 * velocity * sin(RelInc/2)

velocity is your current velocity when you do the change.

And as explained above, by the deorbit planning, your deorbit fuel demand depends on the mission - a Shuttle in 300 km altitude orbit needs much less fuel for deorbit than a Shuttle visiting Hubble in 650 km altitude.

If you know where your spacecraft will be in the worst case for a deorbit, you can reserve the needed fuel for the mission.

 

[Thorsten]

I much appreciate your answers and the time you put into them, but I think you misunderstood my point.

I am a theoretical physicist doing quantum field theory for a living - I know how to compute any classical equation of motion I want and I could probably code the whole dynamics in the simulation myself. That's not what I am after.

Pretty much any computation has an approximation in some limits. And often you learn a lot about the essential physics you're governed by just by looking at approximate scalings. It'd be nice to explain this to people. It's how we teach physics to students - understand the essentials, find the relevant approximations, understand scalings.

There is no approximate relation between the values.

There sure is. You could just run hundred trajectories through the simulation and do a plot of the maximum g-load, and you'll find that the result is a smooth and monotonous function, which means it can be parametrized by some expression, and having that expression one could estimate what to expect in a few seconds. Just nobody has done it - that doesn't mean it can't be done

And as explained above, by the deorbit planning, your deorbit fuel demand depends on the mission - a Shuttle in 300 km altitude orbit needs much less fuel for deorbit than a Shuttle visiting Hubble in 650 km altitude.

Sure, again my point being that at the end of the day, the relation is reasonably simple, because because so close to the Earth gravity can be assumed constant, so the shuttle at 650 km has a bit more than twice the potential energy than a shuttle at 300 km while the orbital speed is roughly the same, so they have the same kinetic energy in a circular orbit. So to make up for the difference in potential energy, I need to reduce kinetic energy, and knowing that that goes like v^2 and potential energy like h, I can solve the problem.

Which means if you fly the shuttle and memorize a single number, i.e. how much Delta v it needs from 300 km, you can know immediately how much you need for any other altitude the shuttle can reach. You sure can work out the same thing by doing the exact numbers in the MFD of your choice - but you miss the essential simplicity of your situation then.

I can also compute the total Delta v budget of the shuttle if I want/need to - but the number could also be in a collection of useful pocked formulae.

That's just what I mean - lots of problems don't require you to solve complicated differential equations (because there's reasonable simplifications you can make) or advanced math - you need to be told a single number, and then there's a scaling relation which works good enough.

But maybe that's just my approach to things... As the non-existence of a collection of such scalings seems to indicate.

 

[Urwumpe]

I am a theoretical physicist doing quantum field theory for a living - I know how to compute any classical equation of motion I want and I could probably code the whole dynamics in the simulation myself. That's not what I am after.

I am software developer for nearly everything around CFD simulations (and everything else that can be programmed, even if it takes a hammer), with a background in software engineering and spaceflight technology.

I leave quantum field theory for people with more time for details, I am really happy if 1+1 results in 10 and not a probability function that might collapse at 2 on a good day.

And I look really good in black clothes. :lol:

Pretty much any computation has an approximation in some limits. And often you learn a lot about the essential physics you're governed by just by looking at approximate scalings. It'd be nice to explain this to people. It's how we teach physics to students - understand the essentials, find the relevant approximations, understand scalings.

Yes, but then there is something I use to call "engineering reality". Yes, you can be too precise. And you can be too abstract. Your model has to fit for the task you do.

Thus, as many orbiteers will confirm, in the moment you think there are just simple rules without a bunch of exceptions, you will burn, crash, bounce or get good scores in lithobraking.

There sure is. You could just run hundred trajectories through the simulation and do a plot of the maximum g-load, and you'll find that the result is a smooth and monotonous function, which means it can be parametrized by some expression, and having that expression one could estimate what to expect in a few seconds. Just nobody has done it - that doesn't mean it can't be done

For the same spacecraft, with the same ballistic parameters and the same steering algorithm.

And even then, a warning that you might have already heard before: Only because you can get something plotted from limited amounts of samples with a smooth undisrupted curve, this does not mean that there is a simple function behind it.

Sure, again my point being that at the end of the day, the relation is reasonably simple, because because so close to the Earth gravity can be assumed constant, so the shuttle at 650 km has a bit more than twice the potential energy than a shuttle at 300 km while the orbital speed is roughly the same, so they have the same kinetic energy in a circular orbit. So to make up for the difference in potential energy, I need to reduce kinetic energy, and knowing that that goes like v^2 and potential energy like h, I can solve the problem.

Wrong. Since the 300 km and 650 km are relative to the surface of Earth and the energy potential is a function of Semimajor axis and the actual gravity field around you. Tiny, important details.

Which means if you fly the shuttle and memorize a single number, i.e. how much Delta v it needs from 300 km, you can know immediately how much you need for any other altitude the shuttle can reach. You sure can work out the same thing by doing the exact numbers in the MFD of your choice - but you miss the essential simplicity of your situation then.

No, exactly that won't work out. While you have relative simple almost linear plots for piloting the shuttle for short distances, any long term targeting is impossible as there is no simple rule and simple number.

I can also compute the total Delta v budget of the shuttle if I want/need to - but the number could also be in a collection of useful pocked formulae.

No, it can't - what if you have more or less payload? Changes the Delta V. What if you deploy payload in Orbit and get lighter along the mission. Or heavier by returning a payload from orbit?

That's just what I mean - lots of problems don't require you to solve complicated differential equations (because there's reasonable simplifications you can make) or advanced math - you need to be told a single number, and then there's a scaling relation which works good enough.

That usually only works for really small intervals, that are usually too small for spaceflight applications. For example, if your time to a space station is significant lower than your orbit period, you can assume to be moving in a gravity-free space for steering, take a straight course and will arrive there. But the longer you need, the more gravity will make your course differ from the simpler straight line model and change your course.

But maybe that's just my approach to things... As the non-existence of a collection of such scalings seems to indicate.

I see it like that: What gets the job done, gets the job done. If Galilean gravity works for an ascent guidance algorithm it is fine, if I need Newtonian gravity, its also fine.

I just can't use Galileo, when I should be using Newton.

 

[kamaz]

I started making a "how to calculate stuff" document, purely for my own sake, but you might find it interesting/informative.

https://docs.google.com/document/d/1A3oKluj0-Sc93zYaUqdslh4C5tqBXeVARBWb1odzeuQ/edit

Uh. Not that I'm criticizing, but you have the following example:

6.67259E-11 * 3.301880e23 = 220320914692

Doing things this way actually defeats the whole point of using exponential notation. The whole idea is that you can multiply the mantissas and add the exponents:

aEb * cEd = (a*c)E(b+d)

So to solve your example:

6.67E-11 * 3.3E23 = (6.67*3.3)E(-11+23) = 22E12 = 2.2E13

which does not require scientific calculator -- it can be easily done using a standard calculator, pen & paper, or even in your head.

And, here is usually no need to use more than 2-3 significant digits. With 2 significant digits, you're going to get the result within 2%, and with 3 significant digits within 0.2% (due to error propagation) -- which is good enough most of the time.

Also, if you are using a laptop for doing in-flight calculations, then I recommend you get GNU Octave, because it is much more convenient than a calculator. Here's your example of calculating circular orbit velocity worked in Octave:

octave:1> G = 6.67E-11;
octave:2> M = 3.3E23;
octave:3> R=2.44e6;
octave:4> h=100e3;
octave:5> r = R+h;
octave:6> v = sqrt(G*M/r)
v = 2943.8

I find Octave much better than calculator, because I can see what I have actually typed.

You can even define your own functions. See the manual for details.

 

[C3PO]

[ame="http://www.orbithangar.com/searchid.php?ID=1176"]Equation MFD[/ame]

 

[Thorsten]

And even then, a warning that you might have already heard before: Only because you can get something plotted from limited amounts of samples with a smooth undisrupted curve, this does not mean that there is a simple function behind it.

The actual function is the solution of a fairly complicated differential equation. However, the approximation to it doesn't have to be - it's the whole point of parametrizing things, so you don't need to do the costly integrals.

Wrong. Since the 300 km and 650 km are relative to the surface of Earth and the energy potential is a function of Semimajor axis and the actual gravity field around you. Tiny, important details.

Of course not wrong. The absolute value of a potential energy has no physical meaning (like no potential ever has), only derivatives of the potential (forces) have.

So I can choose to normalize my potential energy to zero at the surface of Earth for simplicity without any loss of generality.

Now, gravity goes like ~1/r, but there the reference is the center of Earth. Using 6300 km for the Earth radius, you're comparing 1/(6300 +300) with 1/(6300+650) and you'll find that the values are just 5% different, so to a first approximation the gravity field can be assumed to be constant.

The point is that the Shuttle can't get far from Earth enough - it can't ever be in an orbit that is not reasonably circular, and it can't ever probe the regions where gravity is substantially different. To understand roughly what it does, using circular orbits and constant gravity fields is good enough.

Of course, one I use the DG to go to Mars, I need to chuck these approximations out of the window because my 'corrections' then aren't 5% but 500%.

No, exactly that won't work out. While you have relative simple almost linear plots for piloting the shuttle for short distances, any long term targeting is impossible as there is no simple rule and simple number.

*shrugs*

I've actually put it to the test, just using the standard instrumentation and a bunch of my pocket formulae, I launched the shuttle into an ISS chasing trajectory, intercepted ISS, docked, de-orbited and made it right to the runway at the Cape. No launch FDM, aerobrake FDM, autopilot, docking helper,... needed. I didn't use any cheats like adding propellant, I had the g-load always within the limits known to me,... I should perhaps add that this was my fifth simulated Shuttle launch in Orbiter. So as far as I am concerned, pocket formulae work just fine for piloting the Shuttle and they help you onto a *very* rapid learning curve.

I think you're largely mystifying things which don't need to be mystified. Solving the differential equations you do for high accuracy. You sure do need more than 5% accuracy to do a slingshot maneuver in deep space, but you sure don't need more than that to intercept ISS or de-orbit the shuttle. People could learn to fly Shuttle and get an understanding of the basic physics much easier than by pointing them to complicated tools solving the numerics for them.

Yes, but then there is something I use to call "engineering reality". Yes, you can be too precise. And you can be too abstract. Your model has to fit for the task you do.

I think we can agree on that one

 

[Thorsten]

There is no approximate relation between the values.

Well, my friend who looks really good in black clothes, it would seem you're wrong on that one as well - there's not only an approximate relation, there's even a simple relation.

The maximal acceleration to expect as a function of vertical speed is a constant term plus a term quadratic in the vertical speed.

I've written a numerical simulation of entry trajectories, and for instance for a sample craft with an L/D of 1 starting from 75 km altitude at 7500 m/s horizontal speed, I get the maximal acceleration as function of vertical speed as

vertical [m/s] max. acc [g]
0.0 - 1.32
100 - 1.34
200 - 1.36
400 - 2.03
500 - 2.71
600 - 3.50
800 - 5.39
1000 - 7.66

As you can easily convince yourself, that's nicely fit with a*x^2 + b. I get the same fit function for purely ballistic entries, just the parameters are different. Which is pretty interesting.

 

[Urwumpe]

Try it with changing L/D and controlled reentries and despair.

For short distances of a few scale heights in altitude, your function will work out, for a full reentry guidance, you need to approximate a solution.

I somewhere have the relation between L/D and the approximate altitude at which you will level off.

But that function is not simple at all - maybe just one fraction in it, but too complex to calculate in your head or have just a single diagram with multiple plots.

 

[Thorsten]

Try it with changing L/D and controlled reentries and despair.

Do you ever pilot anything like aircraft?

Once I can control my entry trajectory because I have force on the airfoils and can control L/D, there's not so much I need any more - I just need the order of magnitude, I act on that, then see what happens, correct iteratively as time goes by.

Say you want to descend with a Concorde from cruise altitude (Mach 2.02 at 54.000 ft) - what you need to pilot this is a single number - when should you cut thrust, start to decelerate and then descend? And the answer is - expect to take about 270 miles and 30 minutes prior to arrival.

Once you do this, you may not get the exact same descent rate every time. You may have rather different winds on the way. Your fuel load may be different. Your passenger load may be different. You may be vectored to a certain route as you arrive. It doesn't matter - 10 minutes into the descent, you easily see whether you have to adapt your approach or not, and you can well adapt within the envelope, just control sinkrate, or increase thrust a little. Piloting means constantly adapting to circumstances.

What doesn't work is starting the descent 100 miles to destination, because you'll have to fly the Concorde far outside its envelope to go down fast enough.

The de-orbit problem is fairly similar. The Shuttle has a decent footprint, I think you have something like 1500 miles available to pilot. The DG has much more than that, I don't know the precise numbers, but certainly in excess of 4000 miles. And that means you don't need to get the de-orbit burn right to 5% accuracy to be in a safe corridor and land - once you have lift, you can pilot and adapt your trajectory as you need within the footprint.

But you do need to hit the right corridor, which means you need a few rough numbers. Starting the de-orbit burn 5000 km to base will let you overshoot with the Shuttle. Reducing velocity too much with the DG will let you drop too deeply into the atmosphere with the DG and the initial deceleration shock before you bounce will be too much. So it's these numbers and their rough scaling you need for piloting atmosphere entries.

Computing the trajectory which will bring me right to base before the de-orbit burn is tough (and doesn't even have a unique solution). Just hitting the right corridor and piloting from there is not - and it's even fun.

 

[Alexrey]

Sorry to change the conversation, but I realise now that what I'd like to be able to do is get into orbit at a desired inclination, rendezvous with another orbiting body (e.g. the ISS), and then de-orbit to a desired point on Earth (e.g. Cape Canaveral) using only basic MFDs. The first part can be done nicely using the launch azimuth equation, but the second and third parts look like they'll each need a system of differential equations to solve (ideally I'd like to be able to do what Rendezvous MFD does for orbital rendezvous, except by solving my own equations rather than using the MFD itself). If there are relatively simple equations that can be used I'd love to hear about them, but if I do need a system of DEs I'd also love to know which ones to use as then I can just write a numerical algorithm to solve them.

 

[Urwumpe]

For deorbit and landing, you only need to deorbit at the right time and correct all remaining errors by piloting.

Important is just doing the deorbit burn in such a way, that your orbit ground track will be near the base when you land. How much is "near" depends on your spacecraft. The Space Shuttle can fly up to 1500 km to the side from the orbit ground track (this distance is called "cross range capability")

 

[Enjo]

The first part can be done nicely using the launch azimuth equation, but the second and third parts look like they'll each need a system of differential equations to solve (ideally I'd like to be able to do what Rendezvous MFD does for orbital rendezvous, except by solving my own equations rather than using the MFD itself). If there are relatively simple equations that can be used I'd love to hear about them, but if I do need a system of DEs I'd also love to know which ones to use as then I can just write a numerical algorithm to solve them.

The algorithm would work only if you flew a perfect, predicted trajectory from the start to the end. It never happens, so you need a tool that gives you feedback from your errors, that you need to correct. That's when mathematicians learn control theory

 

[Alexrey]

I'll never forgive myself for not taking control theory at uni! :facepalm:

 

[Thorsten]

Sorry to change the conversation, but I realise now that what I'd like to be able to do is get into orbit at a desired inclination, rendezvous with another orbiting body (e.g. the ISS), and then de-orbit to a desired point on Earth (e.g. Cape Canaveral) using only basic MFDs.

That's all perfectly possible (and before anyone says it's not, I have tried it with the Space Shuttle).

Waiting is an important component.

First, wait till ISS passes right over your launch site. Then launch (I guess a bit ahead of ISS is best, might even catch it directly, but it doesn't matter so much in terms of propellant, just in terms of time).

The crucial thing is to get the inclination precise enough during ascent, because on the orbital maneuvering engines of the Shuttle you'll never fix it later. Open 'align plane' MFD during launch, watch the relative inclination change, once you're clear of the atmosphere, adjust thrust axis such that relative inclination goes to zero. You should be able to correct a lot during ascent, the SSME has quite some thrust.

Stop the ascent as soon as apogee is at ISS altitude, leave perigee lower, but still above atmosphere. You basically don't need to do anything except to wait - there will be a reasonably close intersection with the ISS orbit sooner or later, you're not looking for a particular intersection point but just for any, which makes the problem much easier, so just have the MFD (forgot its name, but from the default selection) open and wait, if you get a good point, make small adjustments to perigee to get the time difference really to zero. That gets you within 50 km or so - fly the rest by transponder.


For de-orbit, start the burn at 12.500 km distance to base from ISS altitude, more from Hubble (or lower orbit first to 300 km, then use the above value), your track needs to be close enough to the Cape, the shuttle has a specified 1,085 nm cross range (I think Urwumpe may find that this is 1850 km), that close the trajectory has to be. Try to cue sheet trick
http://www.orbiter-forum.com/showthread.php?t=32822
to manage the piloting during the entry phase if you don't want an MFD for the job.

Enjoy.

I'll never forgive myself for not taking control theory at uni!

If you can drive a bicycle, you know enough. If you have a deviation right, steer left. If your glidepath is too steep, pull up. If you have +5 deg inclination to the orbit, thrust with a course to the negative direction. Pilot such that a quantity you want to control has the value it should. That's all there is to it.

 

[Alexrey]

Thanks Thorsten I'll give those techniques a try sometime.

If you can drive a bicycle, you know enough. If you have a deviation right, steer left. If your glidepath is too steep, pull up. If you have +5 deg inclination to the orbit, thrust with a course to the negative direction. Pilot such that a quantity you want to control has the value it should. That's all there is to it.

Yeah, I know that control theory is just making adjustments to inputs based on outputs, but differential equations and applied maths in general really interest me. I would love to be able to create my own MFD for navigation because then I would gain an intimate knowledge of the underlying maths.

 

[Urwumpe]

Yeah, I know that control theory is just making adjustments to inputs based on outputs, but differential equations and applied maths in general really interest me. I would love to be able to create my own MFD for navigation because then I would gain an intimate knowledge of the underlying maths.

Actually, it is a lot simpler in reality, since the differential equations are only interesting during the design process.

Important in flight are just three letters: P, I and D.

These describe the various control loop behaviors and can be combined:

P = proportional
I = integrative
D = differential

Proportional response is simply that the control signal scales linear with the error signal.

Integrative response grows with the integral of the error signal: The longer the error persists, the stronger the control signal gets. This has a strong tendency to overshoot but can adapt good to changing environments.

Differential response grows with the change of the error signal: The faster the error changes, the stronger the control signal gets. This reacts VERY fast, but can't correct errors by itself = It can not steer a spacecraft alone. Also, the existence of a D component means, that you also have a small time delay, before the control reacts (important for the stability of the control loop)

Most typical examples you will find in real applications are P, PD, PI and PID controllers.

A PID controller is also called an universal controller, since you can represent the behavior of ANY of the other possible controllers with it, by giving it different parameters.