Resonant Orbit Calculator v1.4

[meyerweb]

14 minutes ago, kerbalfreak said:

Now I want to do one around Kerbol, 4 vessels 90º apart, at 17x10^9 meters (between Kerbin and Duna).

I want to consume the least possible amount of game-time, warping the minimum possible. Any tips?

Given that even an inward resonant orbit (a “dive” orbit) is almost 457 Kerbin days long, I think the best bet given those constraints is to launch a new constellation member from Kerbin (or from Kerbin LEO, if you’re taking them up in a single carrier craft) every 152 days.  You should park the last satellite within two years of initial launch, instead of 4-5 years.

Also, now I’m thinking that I should add a special feature where if Kerbol is your orbiting body, the planetary orbits should be visible… hmmmm…

Edited December 1, 2017 by meyerweb

[kerbalfreak]

If ins't too much trouble, can you give me a more "step by step" explanation?

Like what the Ap. around Kerbol of the vessels leaving Kerbin every 152 days, and what maneuvers should be done.

The vessels are already at orbit. They have around 5.000 m/s of Delta-V.

Thanks!

Edited December 1, 2017 by kerbalfreak

[meyerweb]

5,000m/s dV EACH?  Whoa.  You’ll be fine.

Here’s how I’d do it: fire the first vessel to Kerbin escape velocity, headed out of Kerbin’s SoI in more or less the same direction Kerbin orbits.  (Similar to any escape headed outward in the Kerbol system, say to Duna.)  Your solar orbit should have an Ap equal to the final parking orbit (17x10^9 meters).  Once it reaches its Kerbol apoapsis, burn to circularize the orbit.

152 days after the first vessel departs Kerbin, start the same process as above for the second vessel.  Make sure it leaves on the same trajectory as the first vessel, or else your time to apoapsis could get messed up and throw off the whole operation.

152 days after that, start the same process for the third.  After another 152 days, send off the fourth.

I strongly suspect (but haven’t checked) that the second vessel will leave Kerbin before the first vessel reaches its Kerbol apoapsis.  Ditto for the third leaving before the second reaches Kerbol Ap, and the fourth before the third.  I don’t think the third vessel will leave before the first reaches Kerbol Ap, but I’m also not sure.  The main point is, have the vessels leave in 152-day intervals.  Circularize each vessel as it reaches its final Kerbol altitude.  Done.

Here’s how I got 152 days: I used the Resonant Orbit Calculator to get the orbital period of a 17x10^9m orbit around Kerbol, which is 3655h:43m:28.9s.  Dividing that by 6 hours (a Kerbin day), I got 609.3 days.  That divided by four yielded 152.3 days.  (I rounded down for clarity’s sake.)

It’s possible that I’m on crack and/or an orbital mechanic n00b and 152 days is the wrong interval—if so, then someone please let us know what the actual interval should be, and why.

[kerbalfreak]

Many thanks!!!

I was thinking in something like this, but I would simple make 4 launches in a single year. That would make some sense if the relays stayed at the same orbit than Kerbin (which is an option). With an orbit bigger than Kerbin's doesn't make any sense to use the Kerbin's year as a parameter. I think I understood how you got the 152 days, it's 1/4 the time the vessels will take to complete a circular 17x10^9 m orbit. Everything in nice 6 hours Kerbin days 

I will try to make the orbit at 17x10^9m, will be a good learning if I decide to make something similar around Dres/Jool in the future. I'm also learning how to use Kerbal Alarm Clock, will be a nice opportunity to test it to alert me about the vessels reaching the apoapsis, and times to make the interplanetary launches.

About the burn to launch it to Kerbol, it should be like this, right? (behold my paint skills):

Is there a way to make this precise? Or just eyeballing is enough? I'm ok with MechJeb2 or other mods.





I will try, soon I'll tell you the results (hopefully without more questions).  

About he craft, I didn't make anything too absurd. Just wanted a default relay to deliver to every planet, with plenty of Delta-V for maneuvers/adjustments, or burning/crashing it if I want to discard it in the future. Used a balanced nuke from Nertea's. The TWR is low, but acceptable for orbital maneuvering (I even got to circularize one around the edge of Kerbin's SOI, with this stage). Heres a pic:


A cluster with 4, for the old plan (4-5 years):

[meyerweb]

Yeah, it should be like that.  I don’t know if MechJeb will allow for more precision or not.  I’d probably use kOS to write my own departure scripts, but that’s me.

And NICE satellite design!  I might steal that for myself.

[kerbalfreak]

Haven't worked  Seems that the time is far greater than just 152 days 

[meyerweb]

Wow, yeah.  Clearly I was on crack.  I’d try asking in one of the more general forum threads, like https://forum.kerbalspaceprogram.com/index.php?/forum/16-gameplay-questions-and-tutorials/ .  Someone there probably knows enough to work out the right answer.

[kerbalfreak]

Seems that the time of launch needs to be very high, consuming almost the same as if I did the "old way". I think I can do the old way in 3 years, even less in a lower orbit. The constellation will be functional before finished, and KAC works very well for alerting me about the maneuvers. And I'm already very familiar with this method, I know it will work. Heres my constellation around Kerbin: 



I'm thinking in making a challenge out of this, the fastest method to get the 4 relays 90º apart around Kerbol, at 17 Gm.

Thanks!!

[meyerweb]

’ello, all!

I just updated the Stock KSP Resonant Orbit Calculator to v1.2.  Most of the changes are under the hood, but this version also corrects an embarrassing error on my part in previous versions, where at least some synchronous orbit values were off by a small but significant amount.  (One of the under-the-hood changes is to stop defining that as a static value for each body, and instead calculating it from the body’s various physical characteristics.)  It also fixes a duh-me bug that broke the line-of-sight diagram when the constellation was too low, which I introduced in the previous version.

I made a distinction above that it’s the Stock KSP calculator because I’m beta-testing resonant calculators for both Real Solar System and Galileo’s Planet Pack.  My eventual plan is to let users pick the system they want from a list of known mods, and possibly put the system configuration data on GitHub to allow mod authors and users to submit updates.

Another thing on the planning board: figuring out what to do in cases like Enceladus in RSS, whose minimum LoS altitude for a three-satellite constellation is precisely the SoI boundary.  Relatedly: figuring out how to include, account for, and hopefully diagram the effects of KSP’s occlusion modifiers.  Only sort of relatedly: deciding if I want to deal with antenna strength and satellite separation distances…

Edited January 6, 2018 by meyerweb
Removed links to beta tests

[meyerweb]

Version 1.3 is done!  Now with the ability to pick from the stock system (the default), Real Solar System, and Galileo’s Planet Pack.  Also, made a few more under-the-hood improvements.

I got the data for body names, equatorial radii, masses, atmosphere heights, and SOI from the game itself—I wrote a little kOS script to dump them all out to a log file, and took it from there.  So if there are bodies in RSS or GPP that the game wasn’t telling me about, like minor moons or large asteroids or something that need to be discovered first, they aren’t listed in the Body menu.

But! I put the “configuration file” on GitHub for inspection, correction, and extension.  You can find the repository at https://github.com/meyerweb/ksp-resonant-orbit-data.  The file in question is systems.js, which contains the data for all three systems.  If you have a favorite system-remaking mod, please submit the necessary data as a pull request and, assuming there are no problems, I’ll be happy to add it.

Now back to my list of other things to deal with, like occlusion modifiers…

Edited January 6, 2018 by meyerweb
Forgot to link to the actual ROC

[meyerweb]

And now: Version 1.4, which includes the ability to specify occlusion modifiers.  The default values are the stock defaults, which are—and I am trying to be charitable here—bananas.  The default atmospheric occlusion modifier, 0.75, means you can have satellites connect to each other at half the altitude needed without the modifiers.  (E.g., instead of a minimum line-of-sight of 600,000m above Kerbin, you can get away with 300,000m.)

This craziness is why I left the use of modifiers off by default.  If y’all think they ought to be enabled by default, though, let me know why.

About the only thing I think I have left to do is add a service worker, in order to remember your parameters between uses, and also to make it all work offline without a hitch.  That’ll be version 1.5, or maybe 2.0.  It’ll probably be a while before that happens, honestly.  But I’ll still be hanging around to answer questions, consider feature requests, fix bugs, and suchlike.

Edited January 10, 2018 by meyerweb
Forgot Markdown syntax has no power here

[linuxgurugamer]

web based is nice, but would also be nice to see it as an in-game mod 

[meyerweb]

2 hours ago, linuxgurugamer said:

web based is nice, but would also be nice to see it as an in-game mod 

Agreed!  Anyone who wants to do that based on this code has my pity, and also my permission.

[Sillvestra]

On 03/12/2017 at 5:31 AM, kerbalfreak said:

Haven't worked  Seems that the time is far greater than just 152 days 

 

I think I know why the method didn't work in this case.

When the number of days was calculated at 152.3, it was assuming that the satellites would be moving and Kerbin was a stationary launch site. This isn't the case. While the satellites moved forward in their orbits, Kerbin was also moving forward in it's orbit. This didn't give the satellites the effective 152.3 day orbit distance from Kerbin before the next launch occurred resulting in the satellites being spaced much much closer than the desired 152.3 days orbital period... 

The theory was fully correct however the math needs to include the continuing progression of Kerbin in it's orbital track. Not sure how this would be calculated but hopefully this will allow you to know what to add into the calculations for this type of launch.

As Kerbin is closer to Kerbol than the final satellite orbit, it will have a faster orbital time than the satellites. Therefore, a reverse orbital direction would result in a much shorter time between satellite launches although possibly at a slightly increased DV requirement. Just a thought...

Edited April 14, 2018 by Sillvestra
Had an additional thought that I wanted to add without making a 2nd reply to the post.

[Gordon Dry]

Thank you for that.

Spoiler

Waiting to be deployed:

 

[linuxgurugamer]

On 4/2/2018 at 12:09 PM, meyerweb said:

On 4/2/2018 at 9:50 AM, linuxgurugamer said:

web based is nice, but would also be nice to see it as an in-game mod 

Agreed!  Anyone who wants to do that based on this code has my pity, and also my permission.

I'm working on it now, will go nicely with the KerbalGPS mod I'm reviving

[Zhetaan]

@meyerweb and @kerbalfreak:
 

On ‎12‎/‎1‎/‎2017 at 2:57 PM, meyerweb said:

It’s possible that I’m on crack and/or an orbital mechanic n00b and 152 days is the wrong interval—if so, then someone please let us know what the actual interval should be, and why.

I know that this is late, but if it helps with the programming, here it is.  The problem is that the 152-day interval is appropriate spacing for the final solar orbit between Kerbin and Duna, but at no point before final insertion do any of the satellites involved occupy that orbit.  You're starting from the final orbit and solving for insertion, but Kerbin is neither on that orbit, nor on a resonant orbit, nor on an intercepting orbit, so the values you get are meaningless.

Simply put, your calculation began from Kerbin's orbital period about the Sun.  That won't work; Kerbin is moving and your final orbit is not in a simple resonance with Kerbin.  You need to use the synodic period and launch resonant to that.  In other words, that means that you are actually looking for something more powerful than a resonance calculator:  because you're launching satellites individually to a specific destination (even though there's no planet at that destination) you want a transfer window calculator.

We can take a few liberties:  since our destination is an orbit, not a planet, we don't have a time-sensitive initial launch window.  However, the timing of the first launch determines the timing of subsequent launches, so the subsequent launches are time-sensitive.  This saves us the trouble of needing to calculate ideal separation, anything to do with epoch and anomaly, and a few other things, so while you need a transfer window calculator, you can get away with the economy version rather than the full-fat, unadulterated product.

The synodic period is the time that it takes for two bodies in orbit about a parent to return to the same position relative to one another.  The difference between this and a resonant orbit is that in a resonant orbit, the resonance is only relative to one body in orbit about a parent--specifically, between the transfer orbit and final orbit.  In the case of synodic period, you need to account for the source orbit as well and solve for all of it as one value.

The calculation for synodic period is this:

1/T_syn = 1/T₁ - 1/T₂

Where:

T_syn = the synodic period,
T₁ = the inner sidereal orbital period,
T₂ = the outer sidereal orbital period, and
T₂ > T₁.

In this case, Kerbin's orbital period is 9203544.597 s and the relay orbit is 13160608.9 s (that's 426.090 d and 609.287 d, respectively), so without going into the details of the calculation, the synodic period is:

T_syn = 30609624.120 s, or approximately 1417.112 d.

If that seems high, that's because the orbit is very close to Kerbin's own.  Successive transfer windows to Eve and Duna are noticeably farther apart than windows to Jool and Eeloo.  That has to do with the harmonic involved in this calculation:  the closer the orbital periods are to one another, the longer it takes to catch up because each orbit sees the destination body move by less and less relative to the origin.  If something were to be, for example, co-orbital with Kerbin, then there would be no synodic period:  it will always be at the same relative position with respect to Kerbin.  On the other hand, if the destination were infinitely far away, then the synodic period would be exactly equal to one Kerbin year.  The synodic period always varies between one year and infinity, which may seem counter-intuitive, but then again, this is orbital mechanics:  counter-intuitive is part of the price of admission.

I'm fairly confident in the answer, but I have not tried it to verify for myself.  Since you want to minimise time, instead of five-quarter intervals, try launching at one-quarter intervals with that:  i.e., every 354.278 days, and tell me whether that works.

[meyerweb]

On 8/19/2018 at 9:35 AM, linuxgurugamer said:

I'm working on it now, will go nicely with the KerbalGPS mod I'm reviving

[linuxgurugamer]

I have the calculations working now, will be doing some development on live stream this evening.  Would be gaps to see you there

[4x4cheesecake]

18 minutes ago, linuxgurugamer said:

will be doing some development on live stream this evening

Can you be a bit more precise? Your twitch profile says 'Monday evening, 7pm - 11pm' but which timezone do you refere to?
I'm quiet interested as well

[linuxgurugamer]

9 minutes ago, 4x4cheesecake said:

Can you be a bit more precise? Your twitch profile says 'Monday evening, 7pm - 11pm' but which timezone do you refere to?
I'm quiet interested as well

US Eastern, I'll update the profile

[linuxgurugamer]

For those interested, here is a picture showing the progress.  Lots of progress, now I need to get the LOS lines working, and then implement dashed lines:

[linuxgurugamer]

And it's now released:

 

[dtondo]

Can someone do a video about how to use this?

[Kerbart]

6 hours ago, dtondo said:

Can someone do a video about how to use this?

I don't have the time to make a video, but the concept is very straightforward. Suppose, for argument's sake, that you want to deploy 4 satellites in a one-hour orbit. To spread them out evenly, they need to be ¹/₄ orbit or 15 minutes apart. So you build a launch vehicle that carries all four satellites, and deploy it in an orbit that is chosen in such a way that it shares it apoapsis with the target one-hour (circular) orbit, but it has a periapsis much lower, so that the orbital period is not one hour, but rather 45 minutes.

Every time you're at the apoapsis, you release a satellite and have it circularize its orbit. The next time your "deployer" comes around it's "15 minutes in front" of the previous deployed satellite (after all our deployer is on a 45m orbit) and it releases the next satellite. So you're releasing the satellites, in their circular orbit, 15m away from each other - 4 satellites evenly spaced on a 1 hour orbit.

This calculator helps you to figure out the orbit specifics. In this case, for Kerbin, you'd need a circular orbit of 450.525 km for a 1hr orbital period, and a 450.525×83.854km orbit to deploy (at 45m intervals) or an 787.528×450.525km orbit to deploy (at 75m intervals). Releasing from the "higher" orbit has the advantage that your satellites need less dV (about 122 m/s) to circularize their orbits.

Edited September 11, 2018 by Kerbart