Jump to content

[WIP][1.8.1, 1.9.1, 1.10.1, 1.11.0] Principia—version Germain, released 2021-01-13—n-Body and Extended Body Gravitation


Recommended Posts

On 3/25/2020 at 7:26 PM, The Tesseract said:

Any tips?

to evaluate possibilities (a.k.a how hard something might be) I tend to load RSS so i can then use data & work (see especially. Table 3 & 6 and Figures 6 to 13) from people much more experienced & skilled in this domain than me. ;-)

Spoiler

Earth-Moon L1

(models discussed in the article include solar pressure dynamics which is not modeled in KSP)

85QpO9B.png

"The results are not satisfactory, but we still keep the data for further discussion and later comparison with the simulation results of triangular LPOs. The collinear LPOs keep very similar orbital shapes to original orbits after the CRTBP-to-ephemeris transition, so the modified method shows little advantage over the traditional strategy. Besides, the costs per 180 days are becoming slightly larger with the increasing amplitudes for each type of the nominal orbits and the costs of real LPOs around  L1 are slightly less than those around L2."

 

I have been interested in E-M L2 given the Queqiao satellite but, for my situation, manual station keeping ~ every 8 to 20 days would be quite un-fun...:

Queqiao Satellite Earth-Moon L2

3HYo768.png

source link for figures below: https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20040171140.pdf

v4GjD8e.png

luYHRDg.png

so if you do come up with something I am eager to hear about it :-) especially given this prior note below about station keeping challenges...  

On 7/6/2019 at 8:01 AM, pleroy said:

you might be underestimated the complexity of station keeping.  At least the following problems need to be solved:

  1. The orbit needs to be characterized and its mean properties determined.  This is not easy in an N-body universe because there is a zoo of interesting orbits that must be considered, and therefore just finding an approximate ellipse requires care.  @eggrobin has been spending the last 5-6 months looking into this specifically for perturbed Keplerian orbits, e.g. LEO; he read a treatise on the topic and numerous research papers, and is just starting to reach the point where he has an idea how to do that in the game.
  2. Once the target orbit is characterized, there is an interesting optimization problem to solve to stick to that orbit with minimum fuel.  We are not particularly competent here, but we know that @Jim DiGriz has been spending years working on this topic.  For what it's worth, there is actually a competition organised by ESA to find good algorithms for trajectory optimisation.
  3. Once the physics problems have been solved, there remains the challenge of integrating with Principia.  This may sound like a "simple matter of programming", but it's certainly months of work: we would first need to design an API that allows modifying the behavior of vessels (that's much more complex than the read-only APIs we currently expose), implement it through our code base without breaking anything, putting tests in place on both sides of the API to make sure that there is agreement on the contract and that no regressions arise.  

 

Edited by AloE
add data & links in spoiler
Link to post
Share on other sites
14 minutes ago, FlyingGeeze said:

How to download from that chinese sharing site?

Do you have to create a account there?

Are you in China?  If you are, you'll need a QQ or WeChat account.  Chances are that you have one already.

If you are not in China, why the hell do you want to download from that site?

Link to post
Share on other sites

Hello Principia devs,

I find you to be some of the most highly qualified coders on this site, so I am unsure if this will honestly be of much use, but as I mentioned I've been using 1.9 with Principia for some time and it's been working fine, apparently.

Would you be open to me making a binary build available and forwarding bug reports to you as well as making a proper pull request for basic support as well as any bugs we may find along the way?  If you are, I'd be willing to help you out.  You can read more about my adoption program for updating plugins here:

In short:

I just fix bugs, I do not add features.  And I report back.  It's to help you, not harm you.  In that spirit, I will not do this without your permission and will not be upset if you decline.

I already have a fairly decently good release of Frobenius in my personal use case, but as you and I know, testing matters.  I'd love to get some eyes and ears on it for you, but I need your permission and will not proceed without it since you are quite obviously active members of this community.

What's your thoughts on the matter?  No pressure, and infinite respect! :)

@eggrobin, @pleroy

Edited by R-T-B
Link to post
Share on other sites
4 hours ago, R-T-B said:

me […] making a proper pull request for basic support as well as any bugs we may find along the way?

This was done in #2505 already. Support will thus be added in Fubini, which will be released on the next new moon, on the 23rd of April.

4 hours ago, R-T-B said:

me making a binary build available

Please don’t do that. It would make support messy, as we would need to keep track of versions built in between releases (the mod is frequently in a broken state at master).

Further, building reproducibly on all three platforms may prove a challenge for you (we have a fairly robust setup based on Azure pipelines now, but this used to be a mess for years), and releasing a Windows-only build would likely lead to further confusion.

Link to post
Share on other sites
4 hours ago, eggrobin said:

This was done in #2505 already. Support will thus be added in Fubini, which will be released on the next new moon, on the 23rd of April.

Please don’t do that. It would make support messy, as we would need to keep track of versions built in between releases (the mod is frequently in a broken state at master).

Further, building reproducibly on all three platforms may prove a challenge for you (we have a fairly robust setup based on Azure pipelines now, but this used to be a mess for years), and releasing a Windows-only build would likely lead to further confusion.

Understood.  Do understand:  I would only have been building for the 1.9 Frobenius patched target (and I possess a lot of *nix and WIndows horsepower, so the build target is not an issue), and as described in my thread, I tag all my versions at the logger with a prefix.

But as far as what I can offer you, it is limited honestly as I am not as good a C++ dev as I am at higher level languages (I can read and write it but my time with it is low).  I appreciate your consideration and of course will honor your wishes.  No offense taken and appreciate your thoughts.

I am very happy to hear Principia is already on it.  You guys are awesome.

Edited by R-T-B
Link to post
Share on other sites

@pleroy when you have a moment, a "what to look for" suggestion from you would be helpful to me to gather better info on a Principia fatal KSP crash condition I am encountering:

In KSP 1.8.1, I am exploring some setups using various RSB & FASA prebuilt rocket models (i.e. Delta IV, Atlas, Saturn, V, etc) for sandbox study scenarios comparing RO Kerbin v. RO RSS & I've been encountering the following kind of Principia Fatal crash at some of the rocket stage separations.  I expect there will be lots of iterations of launches etc with variations (including crazy staging engine, maneuver, etc 'mistakes' we will be making) on these type of rockets so if I know what to look for I expect to be able to get a much better sense for & information about what leads to the crash so i can create more stable study environments.  Logs etc in this folder : https://drive.google.com/open?id=1dD4KAfOmW-qH0N98rQ7e4c5nFc8jADVx  Thanks!

Link to post
Share on other sites
23 hours ago, AloE said:

@pleroy when you have a moment, a "what to look for" suggestion from you would be helpful to me to gather better info on a Principia fatal KSP crash condition I am encountering:

 

This is very likely to be the same bug as in issue 2507, which will be fixed in Fubini.  The funny thing is that this bug (which is quite subtle) has been with us for years, and we suddenly got three reports in the last month.  Either people are playing with Principia more, or some change in KSP or in some other mod causes the bug to trigger much more frequently.

Link to post
Share on other sites

After installing Principia Frobenius I have severe problems with aircraft and craft in atmosphere in general.

1. I have an airplane that flied very well with Principia Frenet, but is now unflyable. Immediately after takeoff, it pitches up vertically, stalls and loses control. If I delete Principia Frobenius and install Principia Frenet, the same airplane takes off and flies fine.

The issue does not repeat with all aircraft. This particular plane is similar to F-100, with a heavy J57 engine in the back. Installing Principia Frobenius makes it unstable in pitch: once the aircraft started rotating "up", it just keeps rotating, increases angle of attack and goes out of control. My guess is that inertia of the heavy engine plays a role (???)

I should add that FAR calculations in the SPH don't show any issue with the aircraft, with either Frenet or Frobenius version installed. All the numbers are green and the yellow Cm curve looks as it should. Nothing in the FAR window tells that the plane is going to be unstable.

2. Sounding rockets returning to Earth by parachute start rotating wildly when the main chute opens. It makes sense, because I'm using a double chute which opens from the sides: when the chute pulls the rocket, it starts rotating.  But then the rocket keeps rotating with the parachute attached, the parachute is rotating as well, and this rotation is not stopped by atmospheric drag. The rocket keeps rotating until it hits the ground. Then it keeps rotating on the ground in an upright position, like a spinning top toy, not affected by any friction or drag. This can go on for several minutes, until the rocket finally lies on its side and starts rolling on the surface.

I do realize that Principia has nothing to do with aerodynamics, atmospheric drag and surface friction. But the current behaviour is bordering on game-breaking as it makes the J57 engine unusable. It's possible that the issue is caused by wrong model of J57 itself, as the real J57 is MUCH longer that the model in the game (it's six meters long) meaning that it's CoG is much closer to the center of the plane. But for now I'll have to go back to Principia Frenet, at least for the early game X-plane missions.

Edited by KSP user
Link to post
Share on other sites
35 minutes ago, KSP user said:

After installing Principia Frobenius I have severe problems with aircraft and craft in atmosphere in general.

1. I have an airplane that flied very well with Principia Frenet, but is now unflyable. Immediately after takeoff, it pitches up vertically, stalls and loses control. If I delete Principia Frobenius and install Principia Frenet, the same airplane takes off and flies fine.

[…]

2. Sounding rockets returning to Earth by parachute start rotating wildly when the main chute opens. It makes sense, because I'm using a double chute which opens from the sides: when the chute pulls the rocket, it starts rotating.  But then the rocket keeps rotating with the parachute attached, the parachute is rotating as well, and this rotation is not stopped by atmospheric drag. The rocket keeps rotating until it hits the ground. Then it keeps rotating on the ground in an upright position, like a spinning top toy, not affected by any friction or drag. This can go on for several minutes, until the rocket finally lies on its side and starts rolling on the surface.

This issue has been reported by @nepphhh and @scimas https://github.com/mockingbirdnest/Principia/issues/2519, however I have not been able to reproduce it, which makes it very difficult to diagnose.

Could you provide a stock craft that reliably reproduces the issue? I am currently unable to run RSS/RO (the only machine I have that can run that at usable speeds is about 600 km away, and given the circumstances it will be a while before I can get back to it).

Link to post
Share on other sites

I was able to partly replicate the rotation issue with this stock craft, in a clean 1.7.3 install with just Principia Frobenius and FAR:

Rotating_Rocket.craft

Launch the rocket without time warp, wait until it reaches 15km, stage and enable time warp 4x.  The rocket should start to tumble, then rotate wildly.  Rotation only starts with time warp on.

I was not able to replicate rotation with stock parachute attached and rotation on the ground. 

EDIT: And here is a stock airplane that flies (reasonably) well with Principia Frenet, but is unflyable with Principia Frobenius.

Plane.craft

Please note it's not supposed to be a good plane, the question is flyable or not flyable at all. Also note that the reaction wheel is off - I did it on purpose.

Edited by KSP user
Added plane file
Link to post
Share on other sites

2020-04-23

For the new moon (lunation number 251), the new release (Fubini) is out.

  • Support for 1.9.1 has been added.
  • The flight planning and orbit analysis window are now available in the tracking station, bringing into line with map view.
  • Some changes have been made to mitigate the aforementioned issue #2519. Wild spin no longer seems to be an issue, however some unexpected oscillations arise under some circumstances. We will keep investigating this issue.
  • Some issues that would cause crashes have been resolved.

See the change log for more details.

We support two sets of versions of KSP: downloads are available for 1.9.1 & 1.8.1, and for 1.5.1, 1.6.1, 1.7.x. Make sure you download the right one (if you don't, the game will crash on load).

For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云.

Link to post
Share on other sites
  • 2 weeks later...

 

On 4/30/2020 at 6:18 PM, sonionoff said:

how does one actually turn on axial tilt? or i missed some info bout it

It's already on by default. You may not think so because you're seeing in the wrong plotting frame.

It got me thinking for a long time too, but then I realized that all planets have axial tilt RELATIVE to it's orbit around the sun, and when the current plotting frame is on the orbited body, principia rotates the camera so as to be aligned with the body rotation axis.

If you look to earth's perspective relative to the camera, it spins in a perfect 90º angle, but just look to the moon and you see it's orbit inclination is tilted relative to the earth's rotation axis (just like real life). But it's easy to check the axial tilt if you go to the tracking station and look to on other planets, like Uranus, which is tilted almost 90º and you can actually see that when you time warp. Or even better, in the tracking station, click the principia button and change the Plotting frame selection to Sun-centered inertial. Doing so will make the camera rotate and you will see earth's rotation axis just like you probably expected.

"The truth is always there, but sometimes you have to see it from another angle"

Edited by mateusviccari
Link to post
Share on other sites

I have a bug with the maneuver planner, that being the actual planning node and the future prediction don't line up. For example, I'll have the planning node down however the future planner shows that I will be burning 5 seconds after where my node is. The biggest problem is that the maneuver on the navball wants me to burn where the maneuver node is, and not where the predicted future orbit's periapsis lies. Any idea how to solve this?

Link to post
Share on other sites

That is not a bug, that's how maneuvers actually work, both in real life and in KSP. A burn is not instantaneous, it takes non zero amount of time. Principia is doing burn calculations starting from your t0 time to however much time it will take for the engines to provide the required delta V. The stock maneuver planning shows exactly aligned PE/AP markers because it doesn't take into account the finite duration of the burn, which is wrong. 

You have two options: 1. turn on instantaneous burn calculation in principia planning UI. OR

2. Preferably, move your node around until the markers line up however you want them to. 

Link to post
Share on other sites

Thanks for the info, I didn't think the calculations would take into consideration the burn time! Also, while I'm at it, do you know of a way to fix the manoeuvre gui so that it shows the burn going down like it does in vanilla?

Edited by turk_buster
Link to post
Share on other sites

There is no fix for it. That comes from the fact that Principia has to inject the delta V amount again and again into the stock system for the node direction to change realistically and the 2nd bullet point from https://github.com/mockingbirdnest/Principia/wiki/Concepts#flight-planning . Basically it is only a flight planner, not an execution helper. Whether there are any plans to implement something like that in the future, only the devs can say anything about that.

Not having some kind of auto-updating system does make gameplay a little inconvenient, like losing the whole flight plan just because you EVAd, but that's how it is right now.

From my experience, you get used to executing the nodes based just on the burn time. And the N body trajectories are so chaotic that it's just better to do small correction burn afterwards rather than aiming to do one single perfect burn.

Link to post
Share on other sites

Yeah, I've been playing it more and the execution planner is less and less important. The pros of not having to manage when to start a burn far outweigh the cons of having to watch your flight path until it matches your manoeuvre.

Link to post
Share on other sites

Hello everyone! New forum user here and I was hoping to get some help. I recently installed KSP 1.8.1 in ubuntu 16.04. I installed Principia along with Rp-1. I got the game working, but had horrible lag when flying low which made any airplane mission unplayable. In my attempt to improve this I noticed that I did not have the proper Nvidia driver installed. I installed the driver and now the game runs like a charm. Unfortunately it only runs without Principia. If I have Principia installed the game crashes the moment I create a new save. I am running the game using the game folder as the working directory (I think, I am still a noob with ubuntu). The player log has this line repeated 12 times:

"Plugins: Couldn't open GameData/Principia/Linux64/principia, error: GameData/Principia/Linux64/principia: cannot open shared object file: No such file or directory
 
(Filename: ./Runtime/Misc/Plugins.cpp Line: 282)"

If I understand correctly, to help diagnose Principia there is another log I need to provide, but I am not sure which one it is. In my glog/Principia folder I have a bunch of files labeled INFO and WARNING. Is it one of those?

I hope somebody can help me with this issue. It is a great mod and the developers have made a fantastic job. Thank you in advance.

Link to post
Share on other sites
On 5/8/2020 at 2:46 PM, Darth Marvin said:

If I have Principia installed the game crashes the moment I create a new save.

The FAQs explain how to report bugs.  Note that on Linux you'll need version 8 of libc++ and libc++abi.  Since Xenial is fairly old, these libraries may not be installed on your system.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...