We are actually very fortunate that the Earth is not very spherical, because without that satellites on the high inclination orbits like the polar orbits and the Molinya orbits would crash into the Earth.
Due to perturbations of the Moon, high inclination orbits have a tendency to be pushed from low eccentricity to very high eccentricity. (This is known as the Kozai-Lidov mechanism.) However, the fact that the Earth's gravitational potential is not exactly spherical (it has a quadrupole moment) makes these orbits precess, and this precession happens to be fast enough to suppress the eccentricity oscillations.
The quadrupole moment of Venus is much, much less than that of the Earth. For comparison, the relative difference between the radius at the equator and the radius at the pole of Earth is about 0.3%. For Venus it's less than one part in 100,000. However, Venus doesn't have a moon, so there's no third body to cause Kozai-Lidov oscillations [1].
[1]: Actually, this is not strictly true, since the Sun acts as a third body. However, it's so much further away that the Kozai-Lidov effect from the Sun is weak. That's why the Venus Express was able to maintain a polar orbit around Venus.
This page is mostly a digest of the book "Fundamentals of Astrodynamics" by Bate, Mueller and White (known as the "BMW" after the authors). This page is useful as a reference but not really good for learning material. I find the Wikipedia pages on this subject a bit shallow too (one of these days I'll contribute improvements to the Wikipedia pages), so if you intend to learn this stuff, obtaining a book is the only viable option (if you know of other good online resources, please share with us. I don't). The 1st edition BMW book from 1971 is available for dirt cheap (15-20 USD), the 2nd edition came out just a month ago but it's poorly available (I'm still waiting for my copy from Amazon).
There's a few more pages (incl. interplanetary mission planning) if you go up one level: http://www.braeunig.us/space/
These algorithms are mostly based on the BMW book as well as a bunch of research papers from the 1960s to 1990s. Look around in different branches for some of the more advanced algorithms (including a search for closest approaches and sphere of influence transitions like Kerbal Space Program and a boundary value problem solver for interplanetary travel), they're still work in progress.
One day I'll turn this into a mission planner software for space simulator games (or some kind of game, not sure yet). If you happen to need some orbital mechanics algorithms, take a look of the above and I'm happy to answer any questions or help with this.
Spacecraft Attitude Determination and Control, edited by Wertz, is another classic. Used copies are available for around 35 USD, but new copies usually over 200 USD.
Spaceflight Dynamics by William E. Wiesel is also a good book with a broader overview into much more topics, including attitude dynamics and rocket dynamics. As opposed to the BMW which only covers orbital motion, but in more depth.
Orbital Mechanics by Prussing and Conway (of Laguerre-Conway fame) is also a very nice book, going into more details of advanced orbital motion, including some more modern methods.
But damn, aerospace engineering books are really expensive. I've spent a small fortune on these books.
Totally agree with one caveat for potential purchasers: my copy of BMW uses US/imperial units which is a little annoying if you're from a metric background. I'm not sure if there's a metric edition.
Couple months ago I started working on space shooter/simulator, just for fun. Newtonian physics, html canvas. It had 2D top view (F2 key) and 3D view (F3 key), but because canvas is quite slow on fullscreen I usualy switched rendering off (F1 key) and then I spent most of the debuging time there. I only needed few data to be displayed so I only rendered speed, distance fuel etc. as numbers. Then I added yaw pitch roll indicator and even though it was on canvas, because only small part was changing it was kinda fast, so I started adding more and more avionics and eventually the instrument flight [1] aspect of it become much more interesting that realistic planet renderings and I completely neglected 3D view [2]. The most fun so far was programing docking autopilot. So if you haven't make your own space simulator, you should, it's fun. (unfortunately it's not finished and not even in publishable state)
I am also interested. I've been curious what strategic elements a real space combat situation (on the scale of a solar system) demands, and if an interesting game can be made out of it.
I'm using real engines and fuel consumption (draco thrusters from Space-X) and somewhat realistic ship mass (3t) and I can tell you space combat is virtually impossible. Especialy "space pirates" kind of fight where they wait in ambush mid way. I fly mostly around jupiter and "eyeballing it" from one moon to another is impossible. You can fly reasonably easy within few km from space station but that's it. For everything else expect delta V more than km/s. Guided missiles would imho be impossible with FPS realistically achievable in game. Dunno about lasers, i'm trying to keep it real.
Well I am pretty sure playing KSP will give one a much deeper "feel" for orbital mechanics. The linked page contains all the math if you actually want to calculate the orbits optimally. I think i will stick with mechjeb. :)
Yeah, KSP is great for getting an intuitive feeling for what one would have to do to navigate space successfully – at least to the point where one would be able to identify grossly inefficient behavior immediately and be able to do something that’s somewhat effective at getting where you want to go (though probably not most effective). I think that’s pretty awesome, mostly because orbital mechanics is not something we think of being able to have an intuitive understanding of, at least if you don’t have the requisite math background (and maybe even then not).
With KSP, at least if you play it long enough, you really do gain a rough intuitive understanding, even if you do not ever calculate anything. But one should probably also mention that it is time-inefficient and, well, not exactly rigorous. (Both of those things don’t matter that much since it’s just a game.)
Obviously you can also break out the calculator and approach it that way (but I don’t think that’s necessary, except maybe when it comes to interplanetary stuff and getting the right angles). The game is luckily easy enough to brute force things and when you are stuck around KSP’s Mars equivalent with little fuel you can still always fiddle around with maneuver nodes forever to see if there is some way out – and then be forced to learn to be efficient that way.
Its interesting to look at the MFD design for mission planning as an applied version of the linked page.
I have not played much KSP, is there anything as realistic as orbiter? From what little I've seen it tended toward comical set of pants, like comparing ChopperLifter to MS flight sim.
Orbital docking dynamics are weird. If you undock from the ISS and thrust up a little bit, in half an orbit you'll come right back. Increasing or reducing your speed along the orbit (moving front or back) will eventually affect your altitude. Docking isn't as simple as "if you wanna go forward, thrust forward". All the control mix; like hovering a helicopter but slower. Flying "in formation" can be very expensive in terms of fuel depending on the formation, or it can be free if in a favorable geometry. There is a classic very hard sci fi story along the lines of extorting someone who doesn't know orbital mechanics by literally throwing them off a space station, and the victim panics not knowing he'll be back in half an orbit seeing as escape velocity is a little faster than a human shove!
One amusing anecdote is for an inclination change greater than 60 degrees or so, its cheaper to land and take off again or go on a very high orbit into deep space and change your inclination there. The ISS is at a very high inclination and at least energetically, to put the thing into a GTO around inclination 0 or so, it would be cheaper to land and re-launch the thing.
As others have mentioned, Kerbal Space Program uses two-body mechanics, ie. only one celestial body has gravitational influence on the spacecraft. And every gravitational field has perfect spherical symmetry. In Orbiter, you can get restricted n-body dynamics and non-spherical gravitational fields so things such as Lagrangian points or Molnya orbits can be simulated.
The solar system of KSP is a lot smaller in scale, the home planet is just 600 km and the atmosphere is 70 km thick. Liftoff to orbit takes just a few minutes (instead of 8-10 min) and a full orbit is about 30 min (instead of 90 min for LEO).
KSP mods can add a level of realism and add more "scientific" tools to the game. "Kerbal Engineer" is a must-have addon because it adds some numeric data about the orbit that the game developers have intentionally left out (a decision I disagree with). MechJeb is a popular addon that adds all sorts of automation, similar to some Orbiter MFD modes. There are also mods to use the real solar system (in real scale) instead of the fictional universe.
But no, overall, KSP is not nearly as realistic as Orbiter is. However, making any comparisons is pretty useless - they are both really fun games with a different emphasis and I play them both regularly.
Kerbal's two-body mechanics thing is the worst limitation. Getting into orbit around Mun looks weird, as you suddenly snap from one gravitational system to another.
Slightly non-spherical gravitational fields don't matter too much unless you're doing a lot of orbits.
> Slightly non-spherical gravitational fields don't matter too much unless you're doing a lot of orbits.
Actually the effects of non spherical gravity is one or two orders of magnitude greater than the influence of all the other bodies in the solar system combined for low earth orbit satellite operations. It has a huge effect, causing a rotation of the orbital plane several degrees per day (up to 10 or so).
The effect isn't as great for lunar or interplanetary trajectories, though.
> Is the 2-body mechanics just a question of simulation speed?
No.
2 body dynamics can be predicted from initial conditions to an arbitrary time any time in the past or the future. N-body dynamics have to be numerically integrated timestep by timestep.
But simulating n-body dynamics is not difficult or computationally expensive. Two things to understand: n is a very small number, around 20, the number of planets and moons in the solar system. And we're only interested in the restricted n-body problem, ie. movement of one massless particle (the spacecraft) in the gravity field of the planets and moons, so it's O(n) complexity, not O(n^2).
Ultimately this was a game design decision.
> Or why wouldn't they compute based on the top N nearest-biggest objects?
For such a small number of bodies, this wouldn't save any time but would add a lot of complexity.
KSP's physics simulation is much simpler than Orbiter's: it treats the "patched conics" approximation as real, i.e. a craft is only ever affected by one object's gravity at a time. This was a deliberate choice to allow efficient time-warping with large numbers of objects, but it means orbits are unrealistically stable and you can't take advantage of phenomena like Lagrange points.
On the other hand, KSP's trajectory planning UI is way, way more intuitive than anything I've seen for Orbiter, albeit not quite as automated or flexible.
The term "patched conics" is actually a bit of a misnomer in the KSP community. A more "scientific" term would be two body dynamics.
Patched conics techniques are mission planning methods that provide semi-analytical solution to lunar and interplanetary trajectories and help searching for launch windows and planning outbound maneuvers. It's a rather crude approximation for real world use, but it gives good initial values to be used for more sophisticated (and computationally expensive) methods.
This mission planning utility for KSP implements the patched conic algorithms: http://ksp.olex.biz/
Once you find a launch window, you can use that as a starting point for a more fancy method such as this: https://alexmoon.github.io/ksp/ (this implements "pork chop plots" or solves the two body boundary value problem, also known as the Lambert or Gauss problem)
For real life (or Orbiter) use, the next step would be to numerically integrate the entire trajectory in a restricted n-body setup.
For more information, see: Carlson, K. M. "An Analytical Solution to Patched Conic Trajectories Satisfying Initial and Final Boundary Conditions"
http://ntrs.nasa.gov/search.jsp?R=19710007291&qs=Ns=Loaded-D... (NASA has made this NTRS paper available again, I tried real hard to find it a few years ago because it was temporarily but intentionally offline)
It's much simpler than Orbiter. But don't let the comical characters fool you: the only thing truly lacking is N-body simulation.
> Orbital docking dynamics are weird
This is simulated well enough.
> One amusing anecdote is for an inclination change greater than 60 degrees or so, its cheaper to land and take off again or go on a very high orbit into deep space and change your inclination there.
KSP isn't nearly as realistic as Orbiter, but I personally see it as a good thing because it makes the right simplifications to give even a 10-year old a reasonable chance at developing an intuitive understanding of orbital dynamics.
Said 10-year old won't be able to plot a real trajectory for a rocket/satellite, but giving a 10-year old an intuitive understanding of inclination changes, gravity slingshots, Hohmann transfers, etc. is an amazing feat by itself.
> I have not played much KSP, is there anything as realistic as orbiter? From what little I've seen it tended toward comical set of pants, like comparing ChopperLifter to MS flight sim.
By default, yes, it's pretty comical. But that's where mods come in. The modding community for KSP is huge, and there's a large set of mods that aim for higher realism (for example: overhauling the atmospheric flight model to add realism; adding the need for life support; adding the need for a satellite network to enable communication with Kerbin). There's a pack of mods called Realism Overhaul that does those things and a lot more.
If you like docking maneuvers and want to play with them on iOS, then I found the Mission Orion app [1] pretty fun, leaning strongly towards the simulator side of the spectrum.
Shuttle by Vektor Grafix felt quite realistic back in its time (1992), although I don't know how much of the experience can be attributed to proper orbital mechanics calculations.
I remember getting a basic primer on this stuff when I attended a USAF Space Operations course back when I was in the Army Reserve.
Our textbook (and an excellent book for the layperson interested in this sort of thing) was Understanding Space [1]. It's still sitting on my bookshelf at work and I occasionally have a reason to crack it open.
As a software engineer in the aerospace industry, I was once working on a project to create a simulator for a new satellite program. I got stuck with writing a simulation model for the Attitude Determination and Control system (rather than something non-physics-y like the communications system). A lot of my job involved taking matlab scripts from the scientists and translating them into Ada code. An understanding of the basics of orbital mechanics came in very handy, as otherwise I would really not have had any way of knowing if my model was generating nonsensical output. Not to mention the onus was always on me to prove to a scientist that there was a bug in his algorithm.
In case it might be of some use to anyone, I started a guide for beginners on the subject: https://airsick.guide/ . For Python fans (or anyone with a computer, really), there is also a (very simple) library designed with KSP in mind: https://github.com/qsantos/spyce.
Did you by any chance, happen to look at my code for reference? Or are they somewhat similar just out of coincidence and similar naming conventions? If you did, in fact, look at my project for reference, I'm glad to have helped!
Just for comparison, here's the orbit determination from initial conditions code from a newer project of mine. It doesn't compute the classical orbital directly, because that tends to add numerical error (ie. first you compute inclination using acos() and a moment later you compute the orientation matrix using cos(inclination)).
I don't remember looking at this project. I think I did read other implementations of this algorithm, and they all end up very similar, so it's probably due to algorithm itself.
It might be interesting to link to all codebases that might be relevant. Maybe I will add a list to https://airsick.guide/tools.html.
---
I only searched briefly for more stable methods. Thanks for the reference, I'll have a look!
Yeah, there aren't too many ways of detemining orbital elements from initial conditions so it is very likely that the code implementing that ends up looking the same. The similarity in variable names and naming_conventions made the two functions look rather similar.
What comes to stability: given just a single pair of (position, velocity) vectors, it's hard to make something that is really stable. If you have several pairs, you can use the method of least squares to try to fit an orbit into observations.
Not using too many arcus trig functions (acos, asin), will give a bit better results near zero.
Additionally, not having to solve the Kepler's equation would be an improvement for near-parabolic trajectories. In other words: it might be preferable to store (true anomaly at epoch, timestamp of epoch) rather than time of periapsis passage or mean anomaly at epoch to avoid this. The issue is that E - e*sin(E) loses numerical precision when e is near 1 (parabolic) and E is near zero. Same applies for the hyperbolic equivalent of Kepler's equation.
Anyway, nice to find people with similar interests! Good luck with your projects.
Regarding the naming convention, I am trying to stick to PEP8 as strictly as possible (sometimes, even in C) and to use overly explicit variable names. I had not noticed that you did that too for the structure member, with `longitude_of_ascending_node` and such. My objective is to have the code be as readable as possible to a newcomer (hence Python, too).
You should consider using my libtwobody project as a "backend" for your Python library. That is actually one of the design goals for the library, to provide low level primitive operations for higher level tasks and be usable from "scripting" languages.
Advantages over a simple implementation such as yours: proper handling of parabolic and near parabolic orbits, state of the art solvers for time of flight (Kepler's equation) and universal variable formulation. Additionally I've done some work with higher level algorithms for interplanetary trajectory planning.
The library may seem a bit cryptic if you're not too familiar with the literature on this subject, but it should not be too difficult to get up to speed with it. It might take a little bit of trivial software engineering to make it work to get it working as a dll but shouldn't be too much work. I'm happy to help, drop me an email (address in commit log) or contact me on irc (freenode, same nick as here on hn).
Another classic book in the field is An Introduction to the Mathematics and Methods of Astrodynamics by Richard Battin of Draper Labs who passed away fairly recently. He developed and led the design of the guidance, navigation, and control systems for the Apollo flights at Draper. https://www.bostonglobe.com/metro/2014/02/23/richard-battin-...
There's another interesting approach to orbital mechanics using geometric algebra. Paper below is from 1983, has anyone come across a later application?
The book Fundamentals of Astrodynamics" by Bate, Mueller and White, where it seems like these notes come from was my Orbital Mechanics textbook in college.
Our final project was to program a crude missile defense system. Great book. It's an old one, but I highly recommend it. It's one of the few textbooks I saved from college.
While getting ready for work this morning I was thinking about this very thing while I was brushing my teeth. I was thinking it would be nice to learn what the actual orbits of all 8 planets are, relative to the sun, and here I get into work and this is posted.
Now granted, I just wanted to know just the orbits as this stuff is way over my head, but I guess it would be good to learn it.
I got the same feeling. You can learn a lot through trial and error.
Probably the need to know everything comes in once you have to pay for that extra dV or if you plan to put your colleagues on thousands of tons of explosive rocket fuel ;)
Due to perturbations of the Moon, high inclination orbits have a tendency to be pushed from low eccentricity to very high eccentricity. (This is known as the Kozai-Lidov mechanism.) However, the fact that the Earth's gravitational potential is not exactly spherical (it has a quadrupole moment) makes these orbits precess, and this precession happens to be fast enough to suppress the eccentricity oscillations.
There is a very good and very readable article by Scott Tremaine on this subject here: http://arxiv.org/abs/1309.5244