Basics of Space Flight: Orbital Mechanics
braeunig.us
braeunig.us
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
[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.
There's a few more pages (incl. interplanetary mission planning) if you go up one level: http://www.braeunig.us/space/
Finally, here's a project of mine that implements a bunch of algorithms for two body orbital mechanics: https://github.com/rikusalminen/twobody
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.
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.
Aerospace has always used nautical miles (not statute miles) and thousands of feet to measure distance on earth.
I am from an European, metric country, and I didn't have any issues with BMW.
[1] https://drive.google.com/file/d/0B5SCh06PKpVtZHowN1l0TEw3cGs...
[2] https://drive.google.com/file/d/0B5SCh06PKpVtUzMxSGNhRy1vVlE...
I also dabble with space-related programming projects and I'd be interested in seeing your stuff.
(I will then read the article and realize what I was doing wrong the whole time.)
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.
http://orbit.medphys.ucl.ac.uk/
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.
No, it's the most realistic game about spaceflight, but it's not a simulator.
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.
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)
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.
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.
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.
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.
> 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.
Yeap. KSP players are well acquainted with that.
Also, it can be cheaper to use the moon to perform inclination change maneuvers. It was even done in real life: http://www.nytimes.com/1998/04/30/us/trying-to-save-satellit...
That maneuver is, oddly enough, patented.
[1] https://itunes.apple.com/us/app/mission-orion/id879837704?mt...
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.
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.
[1] http://www.amazon.com/Understanding-Space-Introduction-Astro...
Looks somewhat similar to what I did a few years ago in a now-abandoned project of mine: https://github.com/rikusalminen/libkepler/blob/master/src/ke...
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)).
https://github.com/rikusalminen/twobody/blob/master/include/...
You can, of course, get the classical elements from the orbit, they are useful for presenting human-readable numbers.
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!
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).
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).
https://www.youtube.com/playlist?list=PLYu7z3I8tdEm-oVAzO8EH...
It's the best (in depth) resource on orbital mechanics I ever found.
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.
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.
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 ;)