14
$\begingroup$

My previous KSP question What can the KSP game actually teach about spaceflight and orbital mechanics, and what are its limitations? resulted in some really productive discussions and under-the-hood exploration of the KSP game and its utility for learning orbital mechanics, as well as seven excellent answers and almost seventy surviving comments.

In the spirit of full disclosure, I'm allergic to both any computer language with curly braces, and to patched conics. Ironically, I did once have an allergic reaction to Space Food Sticks as well, but I've never had the opportunity to see if I still have that allergy today. I don't think my question is biased or leading in any way, but instead will hopefully lead to some thoughtful as well as scientifically correct answers.

Answers to Going from LEO to lunar using only low-thrust ion propulsion - can it be done? include the SMART-1 spacecraft with

a nominal thrust of 68 mN, hence an acceleration of 0.2 mm/s² or 0.7 m/s per hour

and another example of a spacecraft that uses ion propulsion for orbital maneuvers and moving from orbit around one body to that of another is the Dawn Spacecraft currently orbiting Ceres:

With the propellant it carries, Dawn can perform a velocity change of more than 10 km/s over the course of its mission, far more than any previous spacecraft achieved with onboard propellant after separation from its launch rocket. However, the thrust is very gentle; it would take four days at full throttle to accelerate Dawn from zero to sixty miles per hour (96 km / hour).

The simplest implementation of patched conics assumes instantaneous impulse maneuvers, rather than days or weeks or even longer periods of very low, continuous thrust.

Question: So for simulated travel from orbit around one body to orbit around another, are patched conics (and by induction, KSP) "useless" for simulating ion propulsion?

If so, then is there in fact any scenario for which it is not (useless for simulating ion propulsion)?

For the purposes of this question, "simulate" is distinct from "animate". I'm more interested in how well the trajectory of a patched conics calculation matches reality rather than if KSP would provide a convenient viewing venue.

Mark's comment that 'KSP doesn't do patched conics for vehicles under acceleration' may be highly relevant to the "by induction" aspect of the question if this applies to the ion engine propulsion.

$\endgroup$
10
  • 4
    $\begingroup$ KSP is useless for simulating real ion propulsion for entirely different reason: at 4x phys-warp, a burn of 20 days will take 5 real-time days. $\endgroup$
    – SF.
    Jul 2, 2018 at 20:21
  • $\begingroup$ @SF. I've aded an edit at the top, thanks for pointing that out. $\endgroup$
    – uhoh
    Jul 2, 2018 at 20:28
  • 3
    $\begingroup$ KSP doesn't do patched conics for vehicles under acceleration. It uses a (non-energy-conserving) numeric integrator. $\endgroup$
    – Mark
    Jul 2, 2018 at 20:35
  • $\begingroup$ @Mark aha! That sounds like quite an important and probably central point! if you have any time, please consider expanding that into at least a short answer, thanks! I'd assumed it was done as just as a long series of individual impulses each followed by a short elliptical segment. $\endgroup$
    – uhoh
    Jul 2, 2018 at 20:40
  • 1
    $\begingroup$ @Polygnome for example this comment. A 20 day burn very low thrust burn could also be simulated (internally) as 3000 short bursts, one every 10 minutes, with elliptical solutions in between. The orbital mechanics of that would take seconds on a laptop, not hours. However it might be hard to integrate with the rest of the way KSP works. $\endgroup$
    – uhoh
    Jul 2, 2018 at 23:54

4 Answers 4

13
+100
$\begingroup$

You are kind of having an XY-problem in the sense that you are asking the wrong question.

Patched conics applies to vehicles moving under the influence of gravity and only gravity. Patched conics simply does not deal with vehicles under acceleration (or any other non-gravity force).

Therefore yes, you can obviously not use patched conics to predict the orbit of a vessel under acceleration, not without some other form of numeric integration for the duration of the burn. You can apply it before and after, but not during the burn.

The way KSP solves this is by simply numerically advancing the game state during the burn. In KSP, a vessel can be in one of two modes - it can either be "on rails", or in "physics mode". When a vessel is "on rails", patched conics is used to determine how the orbit propagates.

Obviously, there are rules for when the game can put a vessel "on rails", and one of them is that it can not be under acceleration, for the reasons explained above.

So the actual question you are asking is whether or not the physics engine KSP uses - which is the physics engine Unity uses (the game engine KSP is written in) is accurate enough for it.

Unity uses PhysX. PhysX is designed as a gaming engine, running at 60FPS. It is not meant as a scientific accurate simulation engine. It does not use numerically stable integrators, the way KSP re-parents the reference frame is not numerically stable, especially not over the course of days, floating-point errors will add up over those time scales and other problems, like small violations of conservation of energy will add up.

In short: It might even be possible to get a flight path somewhat close to what would be reality, but if you need really precise numbers, you should use a proper math/astrodynamic library that was designed for this and doesn't need to run for multiple days to simulate the burn.

The general principles are all correct, but KSP simply isn't concerned with the small nuances of floating-point precision errors, or absolutely strict observance of conservation laws, or even numerically stable integration.

You can learn a great deal about ion drives with KSP. You can learn that Hohmann transfers do not really work with them, and that you need to plan trajectories quite differently then when using a higher thrust engine, but that using them comes with extremely high delta-v.

With regards to the comments: As said before, PhysX runs on 60FPS. KSP will take the orbital state vectors after each frame, calculate all needed parameters for the patched conics approximation and give you an updated trajectory. However, KSP will only deliver the trajectory as if the vessel would not continue to accelerate. It is an instantaneous snapshot of the vessels current state. KSP supports modding, and mods have already replaced the stock system with a complete n-body simulation. This mod is called Principia. So it might completely be possible to include trajectory predictions for long burns in KSP with a mod, but that is simply not something the stock game deals with.

$\endgroup$
7
  • 1
    $\begingroup$ Thanks! My two comments (1, 2) were posted almost simultaneously with your answer. Also, thank very much for "going deep" and describing the physics engine used. A simple Runge-Kutta would work better hopefully they'll build their own physics engine really soon; hello halo orbits! $\endgroup$
    – uhoh
    Jul 2, 2018 at 23:55
  • 2
    $\begingroup$ @uhoh They won't. There is absolutely no reason to. Its a game, not a scientific calculator, there are specialized tools out there for that. It needs to be accessible to a wide audience of people who have no idea what so ever of spaceflight. Patched conics offers that, and its simply not economic to replace PhysX with another physics engine, especially a custom one. $\endgroup$
    – Polygnome
    Jul 3, 2018 at 0:10
  • $\begingroup$ One of the frequent people here is putting out a series of YouTube tutorials and some of them use KSP to explain real spaceflight missions. I proposed they switch to Universe Sandbox as it is not a game. Looks like we generally agree on most everything. astronomy.stackexchange.com/q/26803/7982 $\endgroup$
    – uhoh
    Jul 3, 2018 at 0:17
  • $\begingroup$ @uhoh When KSP is accurate enough to showcase the points they are making, then why shouldn't they? Especially if they already own KSP but not US(2). Furthermore, I could not find really concrete information about the accuracy of US compared to proper astrodynamic libraries. $\endgroup$
    – Polygnome
    Jul 3, 2018 at 0:25
  • $\begingroup$ @uhoh does universe sandbox support objects under thrust? It doesn't mention such in its feature list. $\endgroup$
    – Slow Dog
    Jul 3, 2018 at 3:07
8
$\begingroup$

A more in-depth error analysis would be needed, but I think you can keep the patched conics assumption (that is: consider only one main attractor in any given moment) and at the same time apply a continuous thrust that renders the orbit non Keplerian. For the case of interplanetary orbits, most of the trajectory will be in the Sun sphere of influence, so if the thrust forces are significantly bigger than the attraction of the planets, you would still make a good approximation.

BTW, talking about curly braces...

$\endgroup$
9
  • 1
    $\begingroup$ poliastro - Astrodynamics in Python. omg there's my productivity for the summer out the window, if not for the year. That looks fascinating, thanks! $\endgroup$
    – uhoh
    Jul 2, 2018 at 12:23
  • $\begingroup$ fyi I've just asked How does the polyastro python package "Going to Mars with Python" example work? What's it really doing? $\endgroup$
    – uhoh
    Jul 2, 2018 at 12:38
  • $\begingroup$ While the answer might be right, it also could be quite wrong. The reason the switchover from one sphere of influence to the other works as well as it does is that the object gets the heck out of that region of (roughly speaking) equal and opposite forces quickly. This may not the case for very low thrust ion propulsion, and so a test of some kind might really be in order to support an answer that can be accepted. $\endgroup$
    – uhoh
    Jul 2, 2018 at 15:28
  • $\begingroup$ See "The concept of 'sphere of influence' is one of the lies we tell to children which is an expression meaning that it's not true but it makes simple explanations easer." and the rest of what's written here. $\endgroup$
    – uhoh
    Jul 2, 2018 at 15:33
  • 2
    $\begingroup$ Just to give a further clue. KSP's ion drives are so ridiculously overpowered that I have landed on the moon with them. $\endgroup$
    – Joshua
    Jul 2, 2018 at 15:43
7
$\begingroup$

I'm going to answer the question "Is KSP (as an example of an application with patched conics) useless for simulating ion propulsion?

With the answer being - not entirely.

What KSP will teach you (if you stick to reasonable spacecraft) is that ion propulsion requires different sorts of maneuvers to those of higher-thrust spacecraft. Continuous thrust is indeed the way to go, as fuel efficiency and the Oberth effect are less relevant, leading to gradually increasing approximately circular orbits to escape velocity, rather than the increasing eccentricity of classical rocketry. Likewise, all maneuvers simply take much longer. On the other hand, ion spacecraft have monstrous amounts of Delta-V compared to other craft, and are thus obviously well suited to long-range missions with lightweight probes.

The game doesn't support low-thrust spacecraft particularly well, though. Most importantly, the game uses timewarp to speed up long-duration spaceflight, with years passing by in minutes. But significant timewarp only works with spacecraft not under thrust. A maneuver that takes hours of thrust takes hours of game-time. A pure calculation wouldn't have this restriction, but KSP simulates the stresses of the spacecraft while under thrust (so as to allow unplanned disassembly), as well as the possibility of collisions with other objects. Low thrust spacecraft aren't much fun from a gameplay perspective.

Does KSP teach you about low thrust spacecraft less comprehensively than reading, or maths? Probably not. Can it teach a teenager (or adult) something approximately accurate about the difference between low and high thrust spacecraft as a side effect of playing a game? Absolutely.

$\endgroup$
3
  • 3
    $\begingroup$ On a side note regarding the game, KSP does allow you to manually turn on "physics warp" while thrusting, though it can be a bit dangerous due to instabilities in the simulation at large time steps. For low thrusts on stable craft (no wobble resonances), though, it can make long burns more reasonable to play with. You can also combine this with a mod like kOS so you can script the maneuver and go do something else for a while during the burn. $\endgroup$
    – Dan Bryant
    Jul 2, 2018 at 20:14
  • 3
    $\begingroup$ At least without mods "physics warp" is limited to 4x. Better than no warp at all but still painful for long duration low thrusts. I expect this is the reason ksp's ION engines are "rediculously overpowered", if they weren't overpowered they would be useless as no player would want to deal with burns measured in weeks (of real wall-clock time) $\endgroup$ Jul 2, 2018 at 21:57
  • $\begingroup$ @PeterGreen Yup. KSP fails very badly at making low thrust playable. I had a capture at Moho on a Nerva engine take 40 minutes. My memory is that there is a mod that permits background "burns" with low thrust engines in flat enough space. I wish they would give us a semi-physics mode: Make the vessel utterly rigid (model as one object) and permit high physics warp. Good for ion engines and rovers. $\endgroup$ Jul 14, 2018 at 23:47
1
$\begingroup$

As a comment above pointed out, KSP uses patched conics for celestial bodies and spacecraft on rails / under high timewarp and uses RK4 for spacecraft under thrust / up to 4x physics warp.

The engine would be capable of doing numerical integration of low thrust trajectories under physics warp. The problem is that there is no model of a finite burn in KSP and the feature that is really lacking is a steering model. If you had a steering model then the engine could numerically integrate the trajectory of the spacecraft under thrust just fine. The question to answer is "over the course of the hours long burn, what direction is the spacecraft pointing as it goes around its orbit?" along with "and how do you pick the correct direction and duration of the burn in order to wind up where you want to go?". If you added a duration to a maneuver burn, along with maybe a button to make the supplied vector switch between inertially fixed or relative to the Frenet (prograde/normal/binormal) frame then you have a crude steering model. That could be used with an integrator along the lines of RK4 to render the predicted burn and terminal orbit.

A big complication emerges though in figuring out how to decrement the fuel resources on the craft and change the mass during the burn. While the vehicle in KSP is "on rails" under high timewarp it is in a state of being "unloaded" and lacks any parts at all. Mods like Kerbalism (possibly only Kerbalism gets this correct right now AFAIK) have to take the vessel object and serialize it into ConfigNodes in order to get at the actual parts on the vessel and change resources and then deserialize it back. That has nothing to do with the celestial mechanics simulation though.

Based on prerelease videos it sounds like KSP2 may have implemented something a lot like this, with finite burns with a simple steering model on top of a patched conics planetarium (although the Rask and Rusk binary planet system may have some limited N-body interactions within the SOI of those planets if I'm guessing correctly), combined with fixing the issues with resource consumption under high warp.

And I suggest you get over your "allergy" to patched conics and curly braces. Initial guess generation of interplanetary transfers usually uses the solution of patched conic approximations (and you'll miss out on languages like Rust). If you can't learn to solve problems with patched conics you probably won't be successful jumping directly to N-body problems (and biases like that ensure that you'll always be a critic).

$\endgroup$
2

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.