Leitfaden

[eggrobin]

It has been pointed out that, while the 1 mm/s increment in the flight plan is more than adequate to plan the execution of any reasonable mission, it is inadequate for the design of complex trajectories.

While the execution of a trajectory with many gravitational assists will involve numerous mid-course corrections with precisions worse than a mm/s, these corrections approximate some ideal trajectory which is highly sensitive on initial conditions. Finding those ideal trajectories is exceedingly inconvenient with the current tools.

This points to another problem; we currently provide no way to make and keep an ideal desired trajectory, to which adjustments made in the wake of real and imperfect execution would strive to return; rebasing after an imperfect execution can completely break a carefully crafted plan, requiring retuning everything blind to get back to the plan, guided by nothing more than the memory of the plan.

I think we can kill two birds with one stone here.

[eggrobin]

Some comments by @lpgagnon which feel related:

I regularly get to a point where I have one decent flight plan, but I want to try to "improve" it, or try something different to compare. some way to "save this plan to restore later" would be very handy for this.
"a second flight plan" sounds too specific; I might want more than two. e.g. deciding between multiple options for a Saturn capture that wants to visit moons

[eggrobin]

On the basic idea of the Leitfaden:

Comments by @ryanc55, emphasis mine:

Leitfaden, issue #3382 Sounds like it would be really useful to planning multiple gravity assist missions, and might get me out of my habit of going one at a time 🙂
I have a general sense for what I'm trying to do. e.g. Venus is nearing AN with Mercury so I'll try to do plane change there and then stay at Mercury-Mercury. But yeah, more complex and multi-body are beyond my ability to "feel out".

Comment by Zeusbeer:

that sounds like a good addition, which would make a manoeuvre sequence actually worthwhile to create.

It does indeed sound like most people don’t do the sort of subtle long-term planning that Reach does, because of the absence of such a feature (why plan so far ahead, when you’ll lose it all after the first burn?).

On the interaction of Δv edition, in response to floating ideas of precise edition by the arrow keys or the scroll wheel (we don’t want to clutter things with more buttons, especially if we have a theoretical optimization mode where we show 15 sig. dec.…).

Comment by @RCrockford:

I don't really use the continuity scrolling for anything interesting because the frame rate is too low to get a good feel for it - I tend to do it all using type ins because then I don't have to fight against a bit of lag sending me 1000 m/s off plan.

If the interaction is done on keyboard to start with, then surely being able to adjust with the up/down arrows is an improvement over backspace, type next digit up or down, enter.

Comment by @ryanc55:

The scroll wheel on hover would be fantastic, though I must admit I've never planned more than a single gravity assist at a time. […] I do wonder if high-resolution players would have issues getting the required mouse hover precision while also rolling the mouse wheel?

[eggrobin]

Experimenting with a dual scroll wheel and arrow key digit adjustment method, this feels very pleasant; while not as continuous as the sliders, this is much more resilient to latency, and works well for the manual hill climbing which is the bread and butter of fine-tuning encounters; in particular, by having the focus on one text field (whose digits are controlled with the arrow keys) and the mouse over another, two-dimensional hill-climbing is fairly quick.

One interesting thing is that past a close flyby, the trajectory cannot really be computed accurately; a stepwise tolerance much above 1 μm throws off an Earth ejection–Mars flyby–Mars flyby sequence.

However, much like the unattainable initial state still says something about the existence of a theoretical trajectory, it seems that keeping the local error in check even at a much larger magnitude is enough to find trajectories that are « close » to some real one, and thus usable (indeed if we were using a symplectic integrator for the flight plan, we would know that there is some « close enough » system that has the solution we computed; here we use a nonsymplectic method, but it seems this is still true).

For example, in Reach’s save 3072.proto.b64, the seven-year-long flight plan with 16 manœuvres is computed with a stepwise tolerance of 1 m; in the actual video, many multi-flyby segments of that flight plan (or a similar one) are shown being successfully executed despite the tolerance being at 1 m.