eggrobin

Members
  • Content Count

    399
  • Joined

  • Last visited

Community Reputation

482 Excellent

5 Followers

About eggrobin

  • Rank
    Sr. Spacecraft Engineer

Recent Profile Visitors

3,729 profile views
  1. I think so; going from J2-only to J2 through J12 (in del Ferro) reduced the error on the orbit of Io from 2″.1 per revolution to 0″.077 per revolution. What does the transit look like in-game in the 1.3.1 versions (I think Fatou is the last one of those)? It would be fun to have a visualization of the improvement.
  2. For the new moon (lunation number 245), the new release (Fourier) is out. Two crashes involving flight plan edition (one reported by @Neph) have been fixed.  See the change log for more details. For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云
  3. The documentation is here: https://github.com/mockingbirdnest/Principia/wiki/Orbit-analysis. It includes some background information on frozen orbits and ground track recurrence, as well as many examples based on real-life satellites to illustrate the underlying concepts.
  4. For the new moon (lunation number 244), the new release (Fibonacci) is out. An orbit analysis tool has been added which computes mean elements and orbit recurrence properties. This has been in the works since February; more features will be added at a later date, e.g., mean solar times of ascending nodes (for controlling sun-synchronicity). See below for a screenshot of the orbit analysis tool in action on a Молния orbit. The tool is fairly complex; documentation will be provided soon. A crash reported by @Delay has been fixed. A dependency issue that would prevent Principia from starting has been fixed.  See the change log for more details. For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云
  5. A single angle is not enough to describe how a planet is oriented (this requires three degrees of freedom), nor even how its axis is oriented (two degrees of freedom). You may find it useful to read the section on the semantics of the quantities used for body rotation, and to look at the figure referenced therein, to understand how to properly describe the orientation of a planet. The section on the principia_gravity_model configuration will then tell you how to specify that information in the configuration file.
  6. For the new moon (lunation number 243), the new release (del Ferro) is out. Higher degree and order gravity models have been added for Mercury, Venus, Mars, Jupiter, Saturn, Uranus, and Neptune; satellites of these planets will now have more realistic motion (this change only takes effect on new saves) Some bugs reported by @Sir Mortimer, @scimas, and @Kobymaru have been fixed.  See the change log for more details. For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云.
  7. Indeed; and at this point, we run into the code complexity of threading that callback all the way down to the integrator; further, even if we did that, there is the aforementioned performance problem: In addition, the integration method1 that we use for long-term vessel trajectories only works if the forces that it is applying depend solely on the position of the vessel, not its velocity; and it only has nice properties if these forces derive from a potential. This in turn means that we would need to switch to a different kind of integration method (which would likely have to be slower to have comparable accuracy), again inducing lots of complexity. TL;DR: thrust in timewarp is not trivial, and will not happen soon; it cannot be a simple “apply force” binding like the ones found in Unity or KSP. ⸻ 1 A symmetric linear multistep method, whose underlying one-step method is conjugate-symplectic.
  8. Principia and Orbital Decay (or any other mod that alters the orbits) are fundamentally incompatible. @Papa_Joe, since you are the new maintainer of Orbital Decay, please note the above; it may be useful to document this incompatibility. You cannot; this is inherently at odds with what Principia does, because keeps an internal dynamical state that it gets propagated by numerical integration, and overrides what stock orbits do. Any changes to the orbits would have to be done as part of the numerical integration, and considerations of complexity as well as performance mean that they have to be done by Principia. To quote some related past discussion to that effect:
  9. @Eriksson What about the Fukushima paper linked by @pleroy, or the ones that @Jim DiGriz linked? Those are specifically about computing the gravitational field given the shape. @AloE Kerballoons is using Rigidbody.AddForceAtPosition instead of Part.AddForceAtPosition, which means that Principia cannot learn about those forces, and therefore cannot make them affect the trajectory; this is the same issue that we found in FireSpitter earlier: In order to be compatible with Principia, a mod that imparts a net force to the vessel must do so with Part.AddForceAtPosition (or Part.AddForce) instead of Rigidbody.AddForceAtPosition (or Rigidbody.AddForce); the force can then be handled by the game (and any mods) instead of being passed directly to Unity. This should be a pretty simple change: all usages of AddForceAtPosition are actually on the RigidBody of a part (part.RigidBody.AddForceAtPosition), so dropping the .RigidBody would do the trick.
  10. Indeed: if the geoid is equal to the terrain height, there is no such thing as downhill (everything is horizontal), which should intuitively be pretty disturbing when you are standing on the slopes of Minmus. As an extreme example, consider a cube of uniform density; figure 1 of Chappell, Iqbal, and Abbott (2012), The gravitational field of a cube, shows the shape of a lake on one of the faces of the cube (lakes, being fluid, lie on an isopotential). Note that the shape of the lake (and thus the geoid) resembles a sphere far more than the face of the cube, whose corners are mountains.
  11. @Eriksson I have not checked the correctness of your code. However, I believe that there is an issue with the general approach: what you are doing is computing a spherical harmonics expansion for the topography (the shape of the ground), rather than the gravitational field (the shape of would-be sea level). In other words, if you correctly compute that which you are trying to compute, you will end up with a gravity field such that the geoid and the topography are the same, i.e., where the ground is (locally) horizontal everywhere. This should not be the case (the sides of mountains are not horizontal, that's how things go downhill). Instead, the geoid tends to be smoother than the topography. For an illustration of this principle, see figure 1 of Franz Barthelmes (2013), Definition of functionals of the geopotential and their calculation from spherical harmonic models: theory and formulas used by the calculation service of the ICGEM. Further, something about the numbers you list in your earlier post give me pause. You have coefficients for degree 1. These correspond to a translation of the geoid; if the geopotential is computed around the centre of mass, they are 0; Principia makes the assumption that they are, and ignores them. However, in your case, they are not only nonzero, but they are fairly large (about the same order of magnitude as, say, C22); this indicates that, if your calculations are correct, you are computing the spherical harmonics with respect to something fairly far from the centre. Note that Principia also ignores degree 2, order 1, as, for bodies whose axis of figure is close to the axis of rotation (which is most often the case), these coefficients are tiny. This may not be the case for arbitrary planets. Note that if it is not the case, it is possible that the rotation of the planet would be chaotic.
  12. This sounds cool; I would be interested in knowing how you generate that; computing the gravitational field from the shape of the body is not trivial, even making simplifying assumptions about internal structure. The best practice is to put the files of your mod in the directory of your mod (so GameData\NameOfYourMod\whatever.cfg). The @ thing is ModuleManager syntax. This means that you need to have ModuleManager (it can be redistributed with your mod, most mods that patch configs do that); you need to look at the ModuleManager documentation to see what you want to do with that syntax (if I recall correctly, @principia_gravity_model:FOR[NameOfYourMod] should do the job, but I am no ModuleManager expert). The specification for these files can be found in https://github.com/mockingbirdnest/Principia/wiki/Principia-configuration-files (using the terminology from that page, you want sufficient principia_gravity_model configurations for the relevant bodies), which means that the gravitational_parameter and reference_radius are not required (the in-game gravitational parameter and radius will be used if they are omitted). We support up to degree and order 30; we have found that this was needed to accurately capture the behaviour of orbits around the Moon (the Moon is very lumpy). For the Earth, we only go to degree and order 10. You should probably inspect the coefficients that you generate and handwave a cutoff from that (if the coefficients remain very large at high degrees, go to high degrees, otherwise ignore higher degrees). Note that we do have a cutoff in-game, so the higher degrees have more a limited range (and thus should only incur a computational cost where they matter). Again, this looks cool.
  13. This would have no effect: Principia creates the ephemeris (and the celestial bodies) when a new game is started, and never reads the configurations again.
  14. @Delay, that would just be the osculating inclination at the node (assuming that we are in the body-centred inertial frame, otherwise it is a largely meaningless angle). As previously discussed, osculating elements are not that useful when it comes to describing your orbit, because they vary wildly along the orbit; arguably the inclination is less affected than the other elements, but I would rather have a consistent approach when it comes to displaying this information, and keep the stuff on the nodes about strictly instantaneous properties at that node (apsis distances, velocities, etc), and display global properties of the orbit (including mean elements) separately.
  15. There is currently nothing that will show a good corresponding two-body orbit. At any time, the game is made to believe that the vessel is following its osculating orbit, so your usual orbital element displays (Kerbal engineer, MechJeb, etc.) will show the osculating elements, which may help; however, the osculating elements are subject to short-period variations that can be misleading as to the true nature of the orbit (in particular the osculating eccentricity and argument of periapsis of near-circular orbits will be wildly inaccurate, to the point of being entirely useless: for TOPEX/Poseidon, the osculating eccentricity ranges between 0.000'2 and 0.001'2, whereas the proper (“mean”) eccentricity is less than 0.000'11.). As @pleroy previously mentioned, I am working on something (the Ferrari change log mentions the ground track recurrence analysis), but this is nontrivial.