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.

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.

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…

Hey gang—I’ve updated the ROC to v1.1 at https://meyerweb.com/eric/ksp/resonant-orbits/. It functions mostly the same, but has the following enhancements: Calculates and displays the minimum altitudes for maintaining Line of Sight (LOS) for various constellations. Buttons to instantly set the constellation orbital altitude to the minimum LOS or geosynchronous altitudes (where applicable). Warns you if your constellation’s altitude is inside the planet’s atmosphere (where applicable). Also tries to warn you when a dive orbit’s periapsis will lead to lithobraking. Has a toggle to show the LOS lines between points in the constellation. The lines will be broken and flickery if they’re blocked by the planet. (Does not take KSP’s occlusion modifiers into account—this may be added in a future version.) Now under the MIT license! (TL;DR: do what you like with it as long as you preserve the license and have a link back to the original.) It also works on mobile, though the layout’s not great. Ah well, always leave some low-hanging fruit to pluck later, amirite? Share and enjoy!

You’re most welcome, and thank YOU—your comment was also exactly what I needed at the right time. Now that http://shop.oreilly.com/product/0636920012726.do is done and off to the printers, I’ve been thinking about what personal projects to work on, now that I have some spare time again. Your comment has definitely pushed this project higher on the list.

Ahhhh, I see. I guess I’ve never played a non-kOS game long enough to have satellites drift!

Interesting, Poodmund! I think there’s a lot of overlap there, but what interests me is that (if I’ve understood it correctly) you’ve also basically made a rendezvous calculator—I’ve reached the same orbit, but I’m here and it’s there, so how do I fire to meet up with it on the next orbit? Pretty cool! Of course, if I haven’t understood, let me know. I’e never really used MechJeb, so maybe I’m not getting the actual goal of your tool. (I do like the rosette lines…maybe I’ll steal those…)

Whoa, whoops! Somehow got those two swapped. Corrected and uploaded. Thanks, epigeios!

Nice, pap1723—thanks! My actual name is Eric Meyer (or Eric A. Meyer if you’re going by my book-writing name) but you can also use meyerweb as an identifier. However you want to do it. I’ll go update the original page to include my name (kind of an obvious oversight now that you’ve pointed it out!) and link to your version for those of the RSS persuasion.

Oh, heh. I read that as “the closest approach will be super close and you just need to tweak slightly on the way”. But, fair enough! I’ll play with it some more. I may try comparing numbers with Transfer Window Planner, to see if TWP can be used as a guide for modifying what Astrogator generates.

Earlier today I tried using Astrogator to get four probes from Kerbin to Duna, with the plane-change maneuver node option enabled. I used kOS to precisely execute the burns for the nodes Astrogator created, but none of the craft actually got Duna encounters. I ran them out to their closest approach, but they never entered Duna’s SOI. They reached Duna’s orbit late/slow, it seemed to me. I reverted to a pre-departure save and ran the ejection burns again, then manually set up radial adjustment maneuvers once they’d left Kerbin’s SOI. About 220m/s of radial-in burning achieved encounters. I had the craft departing from an 80km Kerbin orbit. Is that too low? Anything I can provide to help diagnose? My craft are somewhat mod-dependent—I use kOS and surfacelight parts, for example—so not sure if a save file will be of use, but let me know.

That’s more or less what I do, and it works fine, except this is what I have: lock steering to lookdirup(heading(azimuth,90):vector, ship:facing:topvector). I think I snarfed that from someone else’s script when I was starting out, so there are probably better ways to do it. I’m also wondering, now that I look at it again, if this would lead to disaster if I built a ship where the command module was upside down or sideways at launch…

Interesting! And I kinda wish my Google searches had turned that up before I started work; I might’ve taken a different approach. There are a couple of things there I might take inspiration from—I’d been thinking about line-of-sight lines between satellite positions—but I don’t think I want to go as far as trying to map broadcast ranges or calculate connection strengths. It’s a bit beyond the scope of what I intend here. I just added a “Flip orbit” checkbox to mine to let users choose which resonant orbit they want to see, at least if there’s no SOI bounds involved (I’ll fix that limitation eventually, I hope). I prefer showing one carrier orbit at a time; showing both at once seems a bit too cluttered and potentially confusing. I do think I’ll add an option for showing a body’s geosynchronous altitude, if one exists.

Oh, that’s a very good point. I’ll have to think about a way to let the user easily flip the orbit direction. Probably a checkbox? I might need one anyway, to cover your earlier “take longer for lower dV” scenario. Pondering…

I don’t do this, it’s true, though I do check to see if an Ap will leave the SOI, and if so flip the resonant orbit. But in my various tests (which were not at all exhaustive), I never found a situation where the injection dV was lower for a Pe-below-final resonance than it was for an Ap-above-final resonance. Do you have an example of one? I feel like the math precludes it, but I may not be thinking robustly enough. Unless—are you thinking of the situation around Kerbin, where the goal is to get a carrier craft to as low an orbit as possible to save on launch dV? This one I’m not quite understanding. Do you mean a 5/6 resonance for a six-satellite constellation, or a 5/6 resonance for a three-satellite constellation?

Heh, like minds and all that. Don’t let my implementation stop you, though—I learned a ton about JS and SVG in the process! Which was honestly the real point.

Not 100% sure this is the right place to post this, but I created a single-use widget for calculating resonant orbits to deploy satellites into a circular orbit at regular intervals along that orbit. It’s at http://meyerweb.com/eric/ksp/resonant-orbits/. In case you’re wondering “what the heck is this?”, a resonant orbit is most commonly used to set up CommNet constellations around non-Kerbin bodies. Suppose you want to put three relay satellites into circular polar orbit around Minmus. You could launch them one at a time from Kerbin and do all kinds of shenanigans to get them into a common orbit (say, 100,000 km above Minmus) at 120-degree intervals along that shared orbit. Which requires matching inclination and LAN and all manner of stuff, and then trying to jostle them into the right places along the circle. Or, you could build a carrier craft that hauls three satellites to Minmus, then release them one at a time. That solves inclination and LAN problems, but what about timing? The easiest thing is to put the carrier craft into an eccentric orbit with its periapsis at the altitude the satellites should share, and an orbital period 4/3rds the length the satellites will have in their circular orbit. In this example, the satellites’ final orbits at 100,000m above Minmus will have a period of 2 hours, 39 minutes, 29.5 seconds. So you put the carrier into an orbit with a periapsis of 100,000m and an apoapsis of 167,652.4m. That has an orbital period of 3 hours, 32 minutes, 39.3 seconds—exactly 133% the orbital period of the circular orbit. Having done that, you just release one satellite from the carrier as it passes periapsis on each of three successive orbits. Hey presto! You now have three satellites in a polar triangle, sufficient to cover the entirety of Minmus and maintain a network back to Kerbin. Quick, deorbit or otherwise move the carrier’s orbit so it won’t smack into the first satellite you released on its next periapsis. I built some spreadsheets to manage the necessary calculations for myself, but it seemed more fun to build a web-based tool that could draw a diagram of the orbits and all that while also spitting out exact Ap and Pe altitudes. And, while I was at it, show the minimum altitude for a functioning three-satellite setup as well as the edge of the SOI for whatever body I was trying to put satellites around if my orbits were large enough to be a problem, show atmospheres (where applicable), tell me the dV I’d need to inject each satellite into its final circular orbit, and stuff like that. It looks like this: It’s of fairly limited use, but it was fun to make and it supports stock as well as RSS and GPP. I figured if someone out there could make use of it, that was good enough for me to release it. Share and enjoy! (P.S. If anyone has feature requests, I’m happy to hear them, though I may not get around to actually doing them. I mean, I might do them, but I have a tendency to toss these little projects into the wild and then get distracted by some new project and never go back to update the old ones. So fair warning and all that.)

Thank you!

Imagine a craft carrying three satellites to be deployed into an equatorial triangle around, say, Duna. An efficient way to get the satellites into their triangle is to have the carrier craft take up an elliptical orbit with an orbital period 4/3rds as long as the orbital period of the satellites after they’re inserted into circular orbit, with its periapsis intersecting with the satellites’ final orbit. So if the satellites are supposed to be in an orbit with a period of 300 minutes, the carrier should assume an orbit with a period of 400 minutes. Then, each time the carrier reaches periapsis, one satellite undocks and injects itself into a circular orbit. Do that three times, and you get three satellites equidistant from each other around the equator. The carrier then moves to another orbit, or deorbits, or something that will prevent it colliding with one of the satellites. My question is: what’s the technical term for the 4/3rds orbit the carrier is on while it’s dropping off the satellites?

I wish I could! kOS and Javascript are about the upper limit of my programming abilities, I’m afraid.

Okay, cool. I just tested this with the GDLV3 stock craft. My only change to the stock craft was to slap a KAL-9000 on the side of the OKTO probe core, so I could run my test programs. On the pad, the Rockomax 64 fuel tank shows as being in stage -1 when I use kOS to crawl the part tree. The Skipper engine is in stage 2, as the stock staging has it. The Rockomax never leaves -1, and the “Stage View” Resources view never shows any resources, even while the craft is in flight and clearly burning fuel. I then tried recreating the GDLV3 in the VAB, and got similar results. In most arrangements, I got a stage of -1 for the R64, and in a few I managed to get it into stage 0. In no case did its resources show up in “Stage View” while in flight (and while its fuel was being drained by the Skipper). This was true whether or not I left the FL-T800 tank on top of the structure, or removed it. So this definitely seems to be a problem with KSP, not kOS. Annoying, but unless the devs are interested in implementing their own tree-traversal resource calculations (and I can’t imagine why they would) it’s just something we’ll have to deal with.

Nice! Any plans for creating built-in structures to allow things like the stationary flyby cameras found in other camera-manipulating mods, geographic/world coordinates, and similar? I assume these could be calculated from what’s already provided, but it would be nice to have a way to say “plop a camera here in the world and don’t move it while still staying pointed at the craft”. Example: put a camera on the ground 500 meters from the launchpad and track the craft as it takes off.

I’d really love an option to label each part. An easy-to-lay-out approach could be to put a number next to each part, and then add a legend to one side, or the bottom, listing each part name next to the corresponding number. (If this exists and I overlooked it, my apologies!)

Hmmm, that’s a good point about in-flight stage rearrangement. I don’t think I did that, but it’s possible, so I’ll do some more testing just to make sure. Speaking of making sure, when you say “with ‘stage only’ selected”, do you mean selecting the “stage view” button in the stock resources panel?

I’ve been running into a situation where sometimes, the stage resources show as zero because (it turns out) the ship’s fuel tanks have been demoted to stage number `-1`. This happens most often when a craft launches with both liquid and solid fuel engines, such as the stock GDLV3. Once the GDLV3 reaches space, having staged off the solid boosters, the Rockomax 64 fuel tank is in stage `-1` (along with the OKTO, the struts, the KAL9000 I slapped on the side, and several other parts). Having the R-64 in stage `-1` means the current active stage calculates as having a dV of 0, because the ship is currently on stage 2, as is the Skipper engine. Staging to stage 1 moves the Skipper to stage 1, but the R-64 stays at stage `-1`. Is there a way to prevent this? I’d prefer a programmatic way to prevent or fix it, as opposed to restructuring the craft or its staging in the VAB just to accommodate this.