Jovus

Finally got it to work! Heavily based on (and many thanks to) AlexMoon's and @TriggerAu's work in the area (https://github.com/alexmoon/ksp/blob/gh-pages/src/lambert.coffee and https://github.com/TriggerAu/TransferWindowPlanner/blob/master/TransferWindowPlanner/SharedStuff/LambertSolver.cs) Which leaves me with a licensing question. You can see AlexMoon's original license from 2013/14 and its requirements regarding distribution and modification of the software. However, I'm technically not distributing or modifying that software in any way, but instead writing my own, in a different language, heavily based upon that original work but with some subtle-but-important differences. Right now my work is ARR, mostly because that's easier in my time crunch than looking into what open-source license I actually want to use when I make this available. And I'm not trying to avoid giving credit where credit is due. At the same time, to be brutally honest, I'm not sure I want to (at the moment) include a license that could be read as saying effectively, "Hey, this is someone else's work and I just cribbed," because I have to present this as an end-of-semester project, and my Professor may have strange ideas about the acceptability of using someone else's solution to the problem to help me write one, especially when they're as similar as they are. So I'm asking y'all (and tagging @TriggerAu and would be tagging AlexMoon if I knew what his handle on the KSP forums was), because I don't want to be either a) in breach of license or b) ungrateful for the help, and I would like advice on how to proceed. This is also the first time I've ever done something where licensing might possibly be an issue. Maybe the easiest thing would be to delete my work from GitHub for the nonce and re-upload when I've fixed the licensing? How bound am I by the original license in AlexMoon's work, since this is to my mind a heavily-inspired-but-technically-original piece? (You can see the repository in question here: https://github.com/Jovus/Transfer-Window-Finder)

OK, for a large enough time-of-flight, my algorithm transgresses the parabolic minimum or maximum (depending on which is in place). Now to track down why...

Running into a weird bug with my Lambert solver. I've construed the problem as you can see here: http://www.braeunig.us/space/interpl.htm#gauss I'm also using their method of linear interpolation to find the correct parameter. As construed, this method should converge for all cases except where R1 and R2 are colinear. However, that's not at all my experience. I'm clearly getting behaviour where, after a certain time-of-flight bound, the algorithm diverges (and quits with an error due to either taking the square root or a trig function of a number that is out of bounds). If anyone feels like taking a look, you can see the code in question here: https://github.com/Jovus/Transfer-Window-Finder/blob/master/libs/scratch.py Note I'm using cartesian coordinates, because ellipses aren't spherically symmetric. Also, I'm more than happy to give credit, despite the slapdash state of the license.

That's exactly what I was going to do, except I'll choose the farther body, whether destination or departure body, on the principle that the inner body obviously make a full revolution if the outer body does. But centering on the Hohmann time is the bit I was missing - which sounds obvious once you've said it, but that's how ideas work. Thanks again!

Perfect answer. Thanks!

Been a while since I posted here, so I don't expect a response, but I thought I'd ask: Pretty much all interplanetary launch window solvers use time-of-flight as an input, rather than an output. Does anyone know a good source for various bodies what a reasonable time-of-flight would look like? Or how to get a starting estimate? I can find Earth/Mars data that seems to indicate a good middle value being ~200 days, and of course I would pad that out to around 100-500 to catch unlikely trajectories. I'm also sure someone somewhere has tables that'll give me reasonable values for Earth/planet trajectories. But what if I want to leave from Venus? Or Jupiter? Maybe what I should do is take the lower bound of ToF to be half the inner body's orbital period, and the outer bound to be the outer body's orbital period, but that seems like an excessively large window. Related, does anyone have any recommended sources for orbital parameters for the planets? Especially including true anomaly at some specified date. (I can programmatically update from there; long-term accuracy isn't a concern.) Again, everyone, thanks for all your help.

Got it. Thanks! I've seen references to the ephemerides in further papers, but never explained as well as you just did. Once I'm done I'll probably post my work to github, because after all I might as well. Unfortunately I haven't done much further work on it, because I'm focused for the moment on building a linear algebraic equation solver. (Without using the solver methods that come with most programming languages.)

Thanks! Is your stuff on github? I'd love to see it. I'm not inventing any new solvers, of course, but just doing a survey of (some of) those already developed. Specifically, my strongest reference is probably https://arxiv.org/pdf/1403.2705.pdf and its references. Gravity assists and whatnot are out of scope - mostly because that sounds like a pain in the butt. Maybe if I get into the project and find out it's not as time-intensive as I expect, I'll build that in just to show off. It shouldn't be hard after I have the basic problem architecture, but I'm professionally lazy (which I define as doing the job right the first time, and not frittering away time I need to be doing something else on a pet project). And yes, I'll be making porkchop plots, because I have to present my data somehow, right? Though I'll probably stick to C3 instead of resolving it into delta-V. Finally, a pseudo-state solver is also out-of-scope, meaning my time-of-flight calculations might be off up to 30 days when we're dealing with the outer planets. Again, out of scope. I'm not sure what you mean by the ephemerides, or the reference to JPL's Horizon? Also, thanks to everyone who has contributed to this thread. You've all been immensely helpful. I'll try to keep this thread updated as I work on this project, too, since it might be of niche interest in this community.

This is in fact exactly what I am doing, except I'll probably be using C or Python, because I like punishment. I'm certainly going to keep you on speed-dial. Oh, and the purpose of the project is to compare efficiency of different Lambert solvers. I just want to dress it up as an actually useful tool, because I don't like making toys. Or you can be tricksy and do an adaptive sectioning technique for optimization down to [insert reasonable section here]. For example, first you do a search on the two-year scale; then you throw out the biaunnum that is longer. Then you do a search on the six-month scale, and throw out the worst one. Then you do a search on the month scale inside the best half-year, then a week search inside the best month, etc. Then you can draw your contours with lower specificity toward the outside, or just end up with a smaller plot and a disclaimer that 'everything outside this window is outside desired parameters'. @VikingStormtrooper You already know this, of course; I'm just pointing it out for posterity/other readers.

Yes. Lambert's problem in differential equation form is how you solve for time-of-flight for a certain orbit (or, conversely, the characteristic energy): https://en.wikipedia.org/wiki/Lambert's_problem

Thanks! If I'm understanding correctly, Lambert's problem applies to the trajectory between the planets, with the planets simply occupying the desired time/space points in the problem, correct? The problem of the trajectories inside the gravity wells of the planets is irrelevant to it.

I've taken on the project of writing an interplanetary trajectory optimization tool and a comparison of algorithm efficiency for the problem at arbitrary starting points. Looking further into the problem, however, I have a question that I can't seem to answer. When you optimize an interplanetary trajectory in a patched-conics approximation like KSP, how do initial and target orbit influence the problem? Specifically, I understand how the 'interplanetary' part works. Given the position of two planets, you can calculate the orbit that will intersect one position at one time (the departure date) and the position of the other at another time (the arrival date) easily by cranking through Lambert's Problem for the solar orbit case. However, how do you account for leaving the orbit of the start planet and arriving in orbit of the destination planet? Put another way, how do you calculate ejection angle or the optimum burn to leave/enter the patched conic gravity well?

Magnetism does no work. It is not a form of energy. Magnetism is a force. But again, a force incapable of doing work. To more fully answer the question: no, this would not work, and yes-maybe-kind-of this would work. Setting aside deformations from other celestial bodies for a moment, the Earth's magnetic field rotates with the Earth (more or less; we're also ignoring the liquidity of the mantle). If you put a ring up there in orbit not connected with the Earth, the ring would move through Earth's magnetic field and a current would flow around the ring. However, if you tapped that current (and you would have to, to keep the ring from melting), the ring would slow to a stop and fall out of the sky, because energy must come from somewhere, and the energy creating the current is the energy of orbit. To counteract this, you'd have to use station-keeping fuel. So you'd ultimately be finding an extremely inefficient and expensive way to trade rocket fuel for electricity. If you attached the ring via a long pylon to the ground, however, then the ring would be 'orbiting' the Earth with the same period as the Earthly rotation. Therefore it would not move relative to the Earth's magnetic field, and therefore it would not induce a current. Now, that last bit is a bit oversimplified. The magnetic field of the Earth doesn't quite move exactly with Earth's rotation, due to many factors (the liquidity of the Earth, deformations from celestial bodies and events, etc.) So you probably would be able to induce some current, especially with a very long ring (which you have). At that point, instead you'd be slowing the rotation of the Earth (albeit minutely, because she's a big'un).

*HISS* Purge the evil! Purge the evil!

Definitely the best way to handle impatience. Kudos to whoever-you-are.

My biggest issue with KSP is that it's forcing me to switch from a Physics PhD program to the Applied Physics and Mechanical Engineering PhD program so I can work on rockets.

Did a search, came up with nothing. If I have this pack installed, and I'm following the contracts, but I decline/fail/ignore some of them, will the mod still keep generating contracts? If so, how? Will it continue to follow the same program, move to a different program, re-offer the same contract, or what? Specifically what I want is to be able to use this mod as a guideline and to spice up an RSS career, but I don't want to follow it slavishly. At the same time, I still want (for example) to get the whole series of Apollo missions even if I decide not to accept Apollo 1. (I'm running 1.1.3 currently.)

They have both the relative Isp and the form factor to be great for stage-and-a-half designs a là the Atlas 1.

@ElWanderer Thanks, that was exactly what I needed. I was missing the ARCSIN(TAN(current_latitude)/TAN(target_orbit_inclination)) bit, and trying something around converting to a ground track and comparing secants. (It was ugly. It didn't work. I'm not proud.) Your method works like a charm.

Congratulations!

Also, 3 sigma (while outside the 'standard' of 'proof') is still pretty likely. Assuming the distribution is correct.

Out of curiosity, is there any possibility (or clues that you have, since you've worked on this) for the gravity turn to be flown by varying the kick angle and start velocity rather than the throttle? ETA: Badly formed question. I'm not asking you to change your mod; I'm writing my own autopilot and I want to use those parameters instead of throttle (since I'm using RO and throttle doesn't vary), and I was hoping that, as you've done all the work behind this, I might be able to borrow a bunch of your work, so I'm asking if, in your opinion, the mathematics might be relatively easily portable to different parameters.

I wouldn't be overly upset if there were a handful of cut-scenes for major milestones. Landing on a new body for the first time, for example. If there were a (10 second?!) cut-scene every time I launched a rocket, I'd yank it out before even seeing it once.

No, no, and a thousand times, no. If I want a real run to have variability over a simulation, I'll install TestFlight (or any of another hundred possible failure mods).

Because you're not specifying flow direction with the new rules; you're just specifying flow priority.