> I need to know what math courses and concepts are required for learning and understanding celestial/orbital mechanics.
To be prepared to study basic, two-body orbital math, I think you could get by with these prerequisites:
High school algebra -- solving equations in one variable; occasional use of the quadratic formula.
Plane trigonometry -- simple definitions (e.g., sine = opposite / hypotenuse), understanding of complementary angles (e.g., sin(x) = cos(90 degrees - x)), simple identities (e.g., tan(x) = sin(x) / cos(x)).
Calculus -- simple derivatives and integrals in one variable, the chain rule, etc.
Vectors -- basic operations and concepts -- right-hand vs left-hand coordinate systems, addition, subtraction, scalar multiplication, dot products, cross products.
Iteration method(s) -- Newton's method will serve you well enough for most stuff. If you're writing code and don't mind wasting CPU cycles (at least in your rough draft), often you don't even need that; if f(x) always increases (or always decreases) as x increases, you can just do "try x=k; if f(k) is too high (or low), increase (or decrease) k and try again."
Optional but highly recommended -- Matrices -- addition, subtraction, multiplication.
That's six different topic areas, but none of them go beyond the introductory level. Notice that I didn't list things like partial derivatives, determinants of matrices, etc.
The toughest thing you'll run into at the basic level is "Lambert's problem" -- given that you're at point P1 at time T1, how do you get to point P2 *at time T2*? For example, if you want to go from Earth to Mars, your flight path isn't much good unless you get to point X on Mars's orbit at the same time Mars gets there. There are a number of methods to solve Lambert's problem, some better than others. Personally I use Battin's method; I've heard good things about Vallado's method but have never tried it myself.
Some suggestions in general:
1) Once you've become comfortable with basic vector math (if you're not there already), go for vector based methods instead of working with Keplerian elements whenever you can. There are times when it's easier to work with Keps than with vectors, but my experience is that more often than not, the reverse is true.
2) You'll run into a lot of formulas which have limited domains of application; some are only good for ellipses, some are only good for hyperbolas, etc. Keep an eye out for "universal formulas" -- those which are good for any orbit, and so don't require you to make an
a priori determination about the orbit before using them.
3) In Keplerian elements, the semi-major axis (Orbit MFD's "SMa") is visually intuitive (at least for circles and ellipses), but as a working variable for orbital math it leaves something to be desired. It's not continuous -- as Ecc increases from less than 1.0 to greater than 1.0, SMa increases to "positive infinity," flips to "negative infinity," then climbs back toward zero. Using the reciprocal of the SMa avoids that problem, but leaves you without any useful information for a parabola -- if your six Keps are (1.0/Sma), Ecc, Inc, LAN, Agp, and Tra, and you're working with a parabola, you have no way of knowing the size of the parabola -- if it's an orbit around the Sun, it's periapse could be at Mercury's radius, Neptune's radius, or anywhere else. I can only assume that SMa and (1.0/SMa) based formulas are increasingly imprecise when Ecc is very close but not equal to 1.0.
Here's a useful formula for the "semi-latus rectum," also called the "parameter" of a conic section, denoted "p"
p = a (1 - e^2) ... or, to put it in Orbiter-ese:
p = SMa (1 - Ecc^2)
The parameter is directly related to the size of the orbit; it's the satellite's radius at 90 degrees away from periapse.
I've got some code I've developed for orbital math, and I don't even store the SMa as data, I use the parameter instead -- my keps look like this:
typedef struct {
double par; /* parameter, a.k.a. the "semi-latus rectum" [m] */
double ecc; /* eccentricity [-] */
double inc; /* inclination [rad] */
double agp; /* argument of periapse [rad] */
double lan; /* longitude of ascending node [rad] */
double tra; /* true anomaly [rad] */
} keps;
My reasons for prefering the parameter are:
a) unlike using SMa or (1.0/SMa), with the parameter you can get precise position and velocity for all conic sections;
b) the (a (1 - e^2)) relationship occurs fairly often in orbital formulas, so many formulas can be simplified by using the parameter;
c) when I do need the SMa, the conversion is easy enough to do; and finally,
d) working with the parameter allows one to use the word "rectum" with a straight face. This can be particularly amusing when discussing Uranus, a la, "the semi-latus rectum of the orbit to Uranus."
Anyway, keep an eye out for (a (1-e^2)) relationships, and when you find them, try using (p) and see if it makes your life any easier.
Hope this helps ...
