[WIP][1.8.1, 1.9.1, 1.10.1, 1.11.0–2, 1.12.2–5] Principia—version ‎‎Kronecker, released 2024-11-01—n-Body and Extended Body Gravitation

[eggrobin]

Tweaking the masses would heavily distort the balance of the game.

So will N-body physics

I believe the Jupiter system is stable because of orbital resonances, so adjusting the orbital periods of Vall and Tylo might work out.

Minmus's orbit however is simply outside of Kerbin's Hill sphere - I don't see any reasonable way of getting it to orbit properly; at best, you might be able to put it in orbit around a Kerbin-Kerbol Lagrange point...

Experiments will have to show whether you get a solution that stays stable for the full 80 or so years that KSP spans.

Minmus is stable (the wobbling of the orbit as seen in-game is just the difference between an orbit around the barycenter and a an orbit around Kerbin).

The big three moons of the Jool system are in a resonance, it's just that I don't use barycentric coordinates for the initial conditions. A mess ensues. I'm not sure if the system would be stable even if the resonance were properly set up though.

Well... from my computer scientist's point of view, it would eliminate the quadratic asymptotic dependency on B, but I have a hunch at why your integrators would get a lot of extra work to do.

I used to think that too, but here's a hint: a division and a square root are ~10 clock cycles each. A trigonometric function is ~100 clock cycles. In real life, the constants matter.

Feel free to do a series of `lectures`, I'm quite interested in the topic. I do know basic calculus, and I think you should take that as a prerequisite... I've written a few n-body simulations myself (using the 'trivial' approach of v += a*dt, x+= v*dt), and I have a hunch on how RK improves on that.

Yes, I don't feel like explaining basic calculus. I can always point to Wikipedia for that. Anyway, unless you're really into topology, you don't want a math undergrad to teach you calculus (I'd probably go off a tangent onto algebraic topology anyway ).

I'm rather surprised by the number of people in the 'I don't know what a derivative is' group. This is a good thing, KSP gets people into math.

Decouples, docking ports and EVA jetpacks provide force, too. As do collisions between ships.

I think the main cause for fluctuations in stock orbits are just due to the fact that the orbit is not calculated for the CoM, but the center of control, so the slightest rotations of the craft are displayed as g forces. While the craft is non-rotating, the stock integrator is working pretty well for me.

If you'd attempt to re-do all those physics, I think you'd basically end up re-writing unity's physics engine, in the process introducing an uncountable number of new bugs, so I heavily recommend against doing that¹.

¹ I think that KSP should indeed be re-written with a from-scratch physics engine in C++, preferrably using fixed-point 64-bit integers for all positions and velocities, but I think that would require an immense amount of work and is entirely unrealistic at the moment.

All true (sounds kinda like the On/OffRails problem), but how to fix it? What about drag? Collisions? Decoupling? Acceleration by exhaust produced by other engines? Sounds like you would have to re-implement the entire physics engine and most other stuff in KSPs. And no, i ofc can't offer any good solution. Is precision that important while the vessel is off-rails? (Yea, I'm looking forward to read about the math involved as well )

There are definitely some unacceptable fluctuations, just look at the peaks of .gee_immediate.

You make some really good points here (drag is not an issue in space, but collisions and decoupling are); If I could grab the calls to AddForce and the like this would be easy, but yes, otherwise I'm basically talking about making my own physics engine here (which would be a good thing, but I'd have to be able to dig into SQUAD's code. I'm not sure C++ would be a good choice though, the .NET framework has its advantages. Maybe C#, interfaced with unmanaged bits for the performance-critical stuff? Of course if I could pick a language I'd say Ada, but that comes with its own set of problems.).

It would probably be trivial to just insert calls to my methods in RigidBody, but an installation process that requires the user to do disassembly/reassembly is cumbersome, not to mention legal issues (not even with SQUAD, that's Unity code).

Until I can come up with something smarter, I'll just experiment to see how far upstream I can grab the acceleration, and whether I can clamp it to kill numerical drift. Low accelerations (long-duration burns) will be specially handled anyway.

What accelerations should be considered negligible?

Edited February 8, 2014 by eggrobin
Of course of course of course here here here.

[mic_e]

You are right, Minmus's orbit should, indeed, be stable... I should have done my math before posting that assumption as a fact. Kerbin's Hill sphere has a radius of over 130 Mm, Minmus is well within that.

Have you considered measuring the ship's acceleration by determining the CoM's velocity at the beginning and end of each physics frame?

I'm not sure there is such a thing as 'neglegible' accelerations... firing 4 1kN RCS thrusters on a 100t vessel should definitely have an effect... and that only be a few milli-gees...

Have you checked whether the phantom gee forces produced by Unity cancel each other out?

[eggrobin]

You are right, Minmus's orbit should, indeed, be stable... I should have done my math before posting that assumption as a fact. Kerbin's Hill sphere has a radius of over 130 Mm, Minmus is well within that.

I didn't do the math, Mattasmack did the simulation, and although his integrator was not symplectic, his energy drift was low enough and his results consistent enough with mine for me to conclude that everything except the Jool system is stable for at least a century.

Have you considered measuring the ship's acceleration by determining the CoM's velocity at the beginning and end of each physics frame?

I'll try that and a few other things.

I'm not sure there is such a thing as 'neglegible' accelerations... firing 4 1kN RCS thrusters on a 100t vessel should definitely have an effect... and that only be a few milli-gees...

Have you checked whether the phantom gee forces produced by Unity cancel each other out?

I'm not sure what you mean by 'cancel each other out', but I'm not sure to what extent these gee forces actually exist either. They come from KSP (I'm just tracing perturbation and a few other things), so maybe bad calculations on KSP's side contribute to that. Bear in mind though that Unity uses single-precision floats, so with cancellations this can explain a lot here. Small enough accelerations can be dwarfed by cancellations.

More testing is in order.

[thorfinn]

yes, otherwise I'm basically talking about making my own physics engine here

No offense, but I don't think you can do that without getting old in the process.....

The thing about orbits being calculated for the root part and not for the CoM is definitely true (altitude is referred to the root part, too.)

And from a gaming point of view, I wouldn't want to COMPLETELY kill inaccuracies maybe... after all, real probes do midcourse corrections, if we could hit a 1000 m wide entry corridor from the other side of the system without a single midcourse that would be unrealistic too

[bulletrhli]

So if you want to look at the current prototype you can pull the source from GitHub and compile it; don't expect it to be playable soon (the current state is not an alpha; it's a messy way of generating nice screenshots). Once this is done, you too can generate nice screenshots!

(I guess you can use it to get a feeling for what N-body trajectories look like, but it's highly likely that the current plotting is a bit off.)

As far as providing the DLLs directly, configuring Git to do that without risking to accidentally publish a KSP assembly is more work than I want to do at the moment. Ask around if you don't know how to build from source.

Thank you, I didn't even think about compiling the source. I have never done that with anything KSP related. I did read the OP obviously but I could only extrapolate so much from it. I was unsure if a "playable" version would be in the future; Future meaning months from now because of the understandable scope of the project.

[eggrobin]

No offense, but I don't think you can do that without getting old in the process.....

Which is why I'm trying to find a way to avoid doing that.

And from a gaming point of view, I wouldn't want to COMPLETELY kill inaccuracies maybe... after all, real probes do midcourse corrections, if we could hit a 1000 m wide entry corridor from the other side of the system without a single midcourse that would be unrealistic too

I'd like my inaccuracies to come from something I programmed (I could add radiation pressure if you want the Pioneer anomaly), rather than cancellations. At least, I'd like the errors from cancellations not to impede decent trajectory planning (especially since things can be quite unstable in the N-body problem).

[thorfinn]

Which is why I'm trying to find a way to avoid doing that.

I suppose the hardest thing to manage would be "medium thrust" burns - i.e. if you wanted to accelerate the typical 30-minute LV-N burn beyond 4x. Too fast to treat the ship as a point mass but still annoying.

I'd like my inaccuracies to come from something I programmed (I could add radiation pressure if you want the Pioneer anomaly), rather than cancellations.

Fair enough But do you need it off-rails? I suppose that what you're worrying about is a tiny wiggle in the here and now making predictions after one or two close passes totally unreliable.

But then again, wouldn't that imply excessive precision in the burn and in the setting of maneuver nodes anyway? Couldn't you just low-pass the initial conditions data fed to the predictor? During high warp travel your integrator would take over and of course wou'd need that to be exceedingly precise - but that can be done.

Of course if I could pick a language I'd say Ada, but that comes with its own set of problems

You actually have experience with that? I thought that was an old USDoD in-house tool....

What accelerations should be considered negligible?

You mean "where should the long-duration burn regime start"? I dunno, you might want to make a runtime test: before allowing transition to high warp with engines on, check that the ship has no angular acceleration and a good margin of control authority left - to avoid tricks like having a single ion engine way off center and no reaction wheels and still flying straight because at high warp the ship is a point-mass LOLOLOLOL.

Edited February 9, 2014 by thorfinn

[eggrobin]

You actually have experience with that? I thought that was an old USDoD in-house tool....

That's the second language I learned (after VB6 ) and the first one in which I wrote algorithms (in Ada 95, if you want to sort something, you write a sorting algorithm. Same goes for most useful data structures, so you can't really avoid it). The fact that my father's job at the time included defining the standard for Ada 2005 might have had something to do with it.

You mean "where should the long-duration burn regime start"? I dunno, you might want to make a runtime test: before allowing transition to high warp with engines on, check that the ship has no angular acceleration and a good margin of control authority left - to avoid tricks like having a single ion engine way off center and no reaction wheels and still flying straight because at high warp the ship is a point-mass LOLOLOLOL.

No, I mean "under what threshold should I clamp the accelerations and attribute them to Unity's ineptitude"; long-duration burns will be handled by talking to the engines (I can't use Unity physics to compute the acceleration during timewarp and if I could I wouldn't want to).

EDIT: It's probably not too hard to integrate the torque due to the engines in timewarp. It turns out that the hard part is doing physics when Unity is trying to do its thing, rather than when we don't use the physics engine.

EDIT2: A well-known use of Ada in aerospace would be the Ariane 5 software, which was reused from Ariane 4. Ariane 5 was faster, this led to a Constraint_Error during a type conversion because they had removed a range check due to efficiency concerns. As a result, the rocket blew up. The spacecraft was Cluster. Turns out if you do stupid stuff, even a nice language with strong typing and range checks everywhere won't help you (also, their identifiers have terrible names).

Edited February 9, 2014 by eggrobin

[skykooler]

EDIT: It's probably not too hard to integrate the torque due to the engines in timewarp. It turns out that the hard part is doing physics when Unity is trying to do its thing, rather than when we don't use the physics engine.

I have the same issue with my timewarp rotation fix; I can make the ship rotate fine when it's on rails, it's making that interact correctly with Unity's physics engine when it comes out of warp where the problems come in.

[thorfinn]

No, I mean "under what threshold should I clamp the accelerations and attribute them to Unity's ineptitude"? long-duration burns will be handled by talking to the engines (I can't use Unity physics to compute the acceleration during timewarp and if I could I wouldn't want to)

I don't think I understand... because of Unity you have noise on the momentum values, the tiny residues of the Kraken, but if engines and RCS aren't on isn't any acceleration an error? Again, wouldn't a low-pass get rid of the noise?

EDIT: It's probably not too hard to integrate the torque due to the engines in timewarp

Do you think it would be useful at 100000x or the like?

EDIT2: A well-known use of Ada in aerospace would be the Ariane 5 software, which was reused from Ariane 4.

I know that story From Kernighan and Pike's The practice of programming. But the funniest thing for me is discovering that Ada code looks very much like Pascal. I learned programming in pascal and I still miss Borland TP7, I haven't yet seen anyone replicate that ease of use in a IDE....

Edited February 9, 2014 by thorfinn

[eggrobin]

I don't think I understand... because of Unity you have noise on the momentum values, the tiny residues of the Kraken, but if engines and RCS aren't on isn't any acceleration an error? Again, wouldn't a low-pass get rid of the noise?

Brilliant! I hadn't thought of looking at it in frequency space (and I missed it in your previous post because it's 4:40; I'll go get some sleep). Trying to grab the most noise-free acceleration is probably a good idea though. I think by computing the change in momentum myself (perhaps sorting the momenta to minimize cancellations) I can avoid the double->float->double conversions that KSP is likely to do (I mean, FlightIntegrator exports the Coriolis force in single precision, but FlightGlobals computes it in double-precison ). You have to be careful though, RCS can fire frequently.

Do you think it would be useful at 100000x or the like?

No, but it would prevent the "stick an ion engine on the side" technique. Automated stationkeeping (and attitude control) is on the roadmap, so that would just end up using up your ACS fuel very quickly.

I know that story From Kernighan and Pike's The practice of programming. But the funniest thing for me is discovering that Ada code looks very much like Pascal. I learned programming in pascal and I still miss Borland TP7, I haven't yet seen anyone replicate that ease of use in a IDE....

Real programmers don't use Pascal. This article has its faults, but it does make a good point that in Pascal, there is no escape, whereas you always have unchecked options in Ada ('Unchecked_Access or Ada.Unchecked_Conversion being examples). There are cases where you have to use them, and you're glad they exist. In the context of trying to escape Unity's incompetence, this is amusing...

EDIT: RCS thrust probably doesn't flip its sign every other FixedUpdate, so I think I'm safe.

Edited February 9, 2014 by eggrobin
s.r'c,bilx.'cj

[carolyn]

This is very ambitious! Like many, I've thought about the N-body issue, but Squad seems pretty firm about keeping things on rails. Please don't throw snowballs at me, but maybe they are right -- after all, this isn't Orbiter. Going "off-rails" would really complicate things like time warp.

BUT.. perhaps something can be done near-term to get the one thing we sorely miss with the current patched-conic approximation -- LaGrange points. It might be possible to put LaGrange points themselves on rails, as well as the (non-elliptical) orbits around these points. Imagine each LP having a little SOI you could fly to and orbit. Sure, it wouldn't be numerically perfect, but this is KSP. The computational load would be greatly reduced vs. N-body, and time warp, etc., would still be possible, preserving the kerbally gameplay feel. Thoughts?

[thorfinn]

Please, read the first posts The point of much of his talk is that by using better, research grade code, you can be as fast or faster than KSP is today even with all the added n-body complexity. Also, Lagrange points (one capital, the guy came from Italy, not Chicago ) aren't all they're cracked up to be, it wouldn't be worth it to make an exception case just for them and hacky solutions are.... horribly hacky, no other way to put it.

By the way:

Automated stationkeeping (...) is on the roadmap

"That's pretty arrogant... I like that in a pilot" (cit.)

Do you have an idea of how that would work?

Edited February 9, 2014 by thorfinn

[eggrobin]

This is very ambitious! Like many, I've thought about the N-body issue, but Squad seems pretty firm about keeping things on rails. Please don't throw snowballs at me,

I can't, it's been a really warm and dry winter here in Switzerland. Though it's currently sort-of-snowing-but-sunny-and-windy-and-it's-+7-degrees-centigrade-so-how-is-it-snowing-anyway.

but maybe they are right

They are. The first-order approximation they have makes sense from a physical standpoint and saves them the expense learning how to do numerical integration: it's going to be several months before I get to the stage where things are playable and where I have been rewritten the integration in C++ for better performance, even though I have taken courses in numerical maths, received advice in numerical integration from Scott Manley and constant help from my fellow modders.

-- after all, this isn't Orbiter. Going "off-rails" would really complicate things like time warp.

It turns out time warp isn't as complicated as you'd think, astrophysicists have already solved this problem for us. See the OP and my upcoming explanatory posts. I do not doubt that we can do timewarp as fast as we need it and with good accuracy.

BUT.. perhaps something can be done near-term to get the one thing we sorely miss with the current patched-conic approximation -- LaGrange points. It might be possible to put LaGrange points themselves on rails, as well as the (non-elliptical) orbits around these points. Imagine each LP having a little SOI you could fly to and orbit. Sure, it wouldn't be numerically perfect, but this is KSP. The computational load would be greatly reduced vs. N-body, and time warp, etc., would still be possible, preserving the kerbally gameplay feel. Thoughts?

Thoughts:

• It's Joseph-Louis Lagrange or Giuseppe Lodovico Lagrangia, not LaGrange or La Grange or Geordi La Forge. Yes, "la grange" means "the barn" (or "the grange"), but his name is written in one word without CamelCasing. Similarly, mine is Leroy, not LeRoy, Le Roy, Leroi, LeRoi nor Le Roi
  
• The only reason the SOI system works well (ok, it doesn't, the planets should really move around barycenters rather that each other, but let's assume they do) is that it's a first-order approximation of the equations of motion around the planet whose SOI you're in. In order to have this kind of approximation near Lagrange points, you'd have to use the 2-body Hamiltonian anyway, so you'd have to use an integrator (the solutions to the 3-body problem are given by a slowly converging series useless for practical purposes). If you have to do numerical integration, you might as well drop the first-order approximation and do N-body physics. I'll explain this point in further detail when I get to my series of exlpanatory posts.
  
• From a gameplay standpoint, SOIs might make sense, but regions around the critical points of the potential where you suddenly choose to change your approximation don't: How big would these Lagrange SOIs be? Around Lagrange points you would be integrating the 3-body problem, but when you get somewhat closer to a planet you'd use the 2-body approximation. I'm pretty sure your Lagrange SOIs shouldn't be spheres.
  

Post-Scriptum:

Lagrange points [...] aren't all they're cracked up to be

This is also a very good point. Lagrange points are useful landmarks when looking at trajectories in the CR3BP, but trajectories differ from the patched conics approximations in many other places (basically, anywhere except low orbits around either massive body, or in really high orbits around the system). If you had 'Lagrange SOIs' you wouldn't get horseshoe orbits.

"That's pretty arrogant... I like that in a pilot"

I should watch this movie someday. I don't know how I will do it yet (the stationkeeping, not watching the movie). The problem is defining which orbit you want to stay in. I'll add this to the list of open problems, there are people on these fora who have experience with that sort of stuff (Arrowstar comes to mind, there are probably many more).

I'll get to work on that low-pass filter! (actually, I think I'll start by logging the data and doing DFTs in Mathematica to see what things look like).

EDIT: come to think of it, I shouldn't get bogged down in data analysis. I'll try to do the integration without any particular preprocessing and I'll worry about filtering later.

Edited May 27, 2014 by eggrobin

[saharashooter]

Hang on, I don't think anyone has noticed an important issue. In some of the N-body simulations of the Kerbol system there are collisions between celestial objects.

How will that work out?

[eggrobin]

Hang on, I don't think anyone has noticed an important issue. In some of the N-body simulations of the Kerbol system there are collisions between celestial objects.

How will that work out?

As previously stated (though not in the OP), the unstability of the Jool system can probably be fixed by tweaking the initial conditions (actually, interpreting them differently). This would remove potential collisions.

Handling collisions of celestial bodies is currently not on the roadmap.

[thorfinn]

Handling collisions of celestial bodies is currently not on the roadmap.

After 0.24 comes out (so, no hurry at all ) I bet you'll want to look into how to handle the asteroids that will be introduced; they should be in the thousand-ton class more or less, and N-body will be perfect for moving them around in clever ways. I can see Scott dropping one onto the Mun with a fire extinguisher and a weak stability boundary trajectory already.

[eggrobin]

After 0.24 comes out (so, no hurry at all ) I bet you'll want to look into how to handle the asteroids that will be introduced; they should be in the thousand-ton class more or less, and N-body will be perfect for moving them around in clever ways. I can see Scott dropping one onto the Mun with a fire extinguisher and a weak stability boundary trajectory already.

That would be interesting. "Hello, I'm Scott Manley. Today we'll to throw a main-belt asteroid at Eeloo by crashing a Kerbal on EVA into it. Let us first derive a closed-form expression for our trajectory."

I don't think asteroids are in 0.24 though, they are in the NASA thing.

Interesting conclusions from the poll results:

• It seems Scott's not here. Could somebody draw his Manley attenion to the remaining open astrophysics question (the one about reference frames for the ER3BP)? Answering it would do too of course.
  
• The majority seems to know basic calculus, so I'll use that. I'll post a link to Feynman's Lectures on Physics for the ~40% who don't, there's a quick introduction to calculus which doesn't involve defining the derivative at a point as a linear form on a Banach space. It's really well written (I'm pretty sure that's where I first learned calculus around 2007).
  
• There are 6 people who checked neither of the bottom 2 options. Either they can do numerical integration but not elementary physics, or they didn't see that it was a multiple choice poll
  

I think the first post I'll write will be on the integration of general ODEs with RK integrators. In later posts I'll talk about Hamiltonian mechanics, the Kepler problem and the patched conic approximation (it would be nice if people understood why SOIs make sense in their current form, but not as Lagrange point hacks or any such sort of nonsense). I'll then get to SPRK integrators, and eventually to the Saha & Tremaine stuff.

I'll try to write the first post over the evenings of the coming week. There will be little modding this week because exams. I'll probably be more productive from Saturday onwards though.

Edited February 10, 2014 by eggrobin

[Tenneko Kazeno]

I don't know anything about this subject but hopefully these papers will help you.

Lagrangian Coherent Structures in the Elliptic Restricted Three-body Problem and Space Mission Design

Stationkeeping on Unstable Orbits: Generalization to the Elliptic Restricted Three-Body Problem

I hope this helps keep this project going as it looks amazing.

[rhoark]

Asteroids will most likely be a new kind of debris rather than celestial bodies, from the engine's perspective.

[jxi24]

How should stationkeeping be implemented? In particular, how should the user set the orbit they want to maintain?

I think a good method of doing this is for the user to set a tolerance for deviations (or maximum deviation) from their current orbit (probably use the semi-major axis, or have one for both apoapsis and periapsis). Then have it use RCS to adjust the orbit back if available, or use whatever other engines are available. I do not know how you would go about implementing it without having to switch to the vessel. In the code you could just have it as a flag and have it check periodically, maybe check once every 5-10 orbits or use a given time period?

[eggrobin]

I don't know anything about this subject but hopefully these papers will help you.

Lagrangian Coherent Structures in the Elliptic Restricted Three-body Problem and Space Mission Design

Stationkeeping on Unstable Orbits: Generalization to the Elliptic Restricted Three-Body Problem

I hope this helps keep this project going as it looks amazing.

My question is mostly a gameplay one actually. The most sensible reference frame is the rotating-pulsating one, but I'm afraid this might be a tad confusing on the map (it's not an isometry). It is also convenient to use true anomaly, rather than time, as the independent variable, which affects what the potential looks like, but I think this is less confusing than the lack of isometry induced by a pulsating map view.

I think a good method of doing this is for the user to set a tolerance for deviations (or maximum deviation) from their current orbit (probably use the semi-major axis, or have one for both apoapsis and periapsis).

The thing is, you don't deviate from your predicted orbit (the prediction and the actual orbit are computed in the same way). For LKO and the like, you could do what you say with the deviation from the Keplerian orbit, thus compensating for orbital decay. The question is, how do you say you want to stay in a Lissajoux or halo orbit around a Lagrange point? Or a horseshoe orbit? Or another kind of exotic orbit? You can see from the prediction that the orbit will end up being unstable, but saying "I want to make corrections to keep me in that kind of an orbit" is something complicated (this is why astrodynamicists exist ).

Then have it use RCS to adjust the orbit back if available, or use whatever other engines are available. I do not know how you would go about implementing it without having to switch to the vessel. In the code you could just have it as a flag and have it check periodically, maybe check once every 5-10 orbits or use a given time period?

I don't need no stinkin' physics engine.

Actually, I'm trying to prevent Unity from doing too much anyway, so I'll definitely not be loading the vessel.

The idea would be to model the vessel as a rigid body (no, not an Unity RigidBody, an actual rigid body), see where the thrusters are and what torques/forces they apply, compute the resources required for the correction, perform the correction by just feeding it to the integrator and subtract the resources from the vessel.

Edited February 11, 2014 by eggrobin

[mic_e]

The problem is defining which orbit you want to stay in.

The main problem is that there are too many differenct orbits. A few examples would be:

Keep a satellite in an eccentric orbit from burning up due to disturbances from the mun

Keep a keostationary satellite above a certain longitude

Keep a satellite from drifting away from a Lagrange point

Keep an Aldrin cycler on its correct trajectory

I don't think you'll be able to write code that is general enough to cover any two of these cases. You'll just have to offer multiple hard-coded options, and add more as people request them (or leave it to the people to write them). For the beginning, I'd simply stick to an algorithm that does maneuvers on each Ap/Pe pass, fixing Pe/Ap to their pre-set values. If the required burn d-v would be too high (say, > 1m/s), display a warning message and stop the stationkeeping.

Edited February 11, 2014 by mic_e

[eggrobin]

The main problem is that there are too many differenct orbits. A few examples would be:

Keep a satellite in an eccentric orbit from burning up due to disturbances from the mun

Keep a keostationary satellite above a certain longitude

Keep a satellite from drifting away from a Lagrange point

Keep an Aldrin cycler on its correct trajectory

I don't think you'll be able to write code that is general enough to cover any two of these cases. You'll just have to offer multiple hard-coded options, and add more as people request them (or leave it to the people to write them).

Good point (also, I had never heard of cyclers, thanks for mentioning that!). I guess I'll end up having a few hardcoded options.

Regarding people writing their own stationkeeping, I guess something like kOS, with a proper language and extensive APIs, would be nice...

*daydream mode on* contemplates making a plugin that interfaces with Ada, provides some packages for vehicle control, and integrates GNAT with a minimalistic IDE in-game. *daydream mode off* Let's get back to the current crazy idea.

[thorfinn]

Crazy idea: let the user define some keyhole regions along the orbit (or maybe even auto-define them with suitable artificial stupidity) and when the trajectory drifts too far from one or more of them, adjust velocity to re-center the predicted trajectory through the next keyhole(s). Of course they would have to be defined in phase space, more than in regular 3D space, BUT it might be possible.... OK, end of crazy talk for today.

Anyway, I'd worry about all this after the basic N-body is done

Also: Genesis probe halo stationkeeping design

<< While many options exist and have been tested, a simplified version of a target point method developed by Howell and Pernicka [Howell 93] is used to generate the results presented here. The goal of this controller is simply to apply an impulsive maneuver, or ÃŽâ€V, in order that the error, the deviation in position between the actual trajectory and the nominal trajectory at some target time downstream, is reduced to zero >>

LAST EDIT: Hey, not so crazy talk after all then (at least my physical intuition still works late at night, always nice to know. Don't ask me how to minimize a cost function over a 6x6 matrix though...)

FOLLOWING DAY EDIT: it would be probably better to split the task in two cases, one for "weakly bound" trajectories (like L1 halos) where the thread-the-needle method is employed, and a "strongly bound" case for orbits at least up to geostationary where Keplerian parameters adjustment is periodically done (with some deadband)

Edited February 11, 2014 by thorfinn