I'm going to start a new thread for the LEO targeting tool since it's not actually related to the Shuttle as such.

What is LEO targeting?

It is a GPL-licensed, commandline-controlled numerical solver for various orbital targeting problems - mainly intended for use in low Earth orbit, although it can do problems beyond that.

What can it do?

Unlike analytical expressions, it can deal with finite burn duration effects, the change of acceleration during a burn as propellant is depleted, J2 and J3 perturbations due to Earth's non-spherical nature, perturbations caused by other solar system bodies... and taking all these effects into account, it can fit burn solutions.

For instance, if you need to de-orbit a Shuttle to a specific landing site and want to know what the optimal time for the burn is to make it to a good entry and not waste any propellant - the tool can do it.

If you want a transfer orbit from your current orbit to another orbital target - the tool can do it.

If you simply want to learn orbital mechanics, play around with how to get from one orbit to another orbit without a full simulation environment - the tool can do it.

If you want to visualize orbits with 3d plots - the tool can generate the data.

As an example, here's a visualization of periodic variations of the eccentricity in J2 and J3 gravity

What is the current status?

The current release 0.4 is available from my page where there's also a set of tutorials on how to use it.

The latest release supports numerical solutions of the Lambert problem (finding a transfer orbit given the initial burn time and the desired arrival time).

As a quick example, here's a visualization of the arrival point for realistic conditions (finite burn duration, J3 gravity,...) and the analytical solution (instantaneous burns, spherical gravity) when the solution of the latter is always used.

Basically, using the analytical expression in the realistic situation misses the target intercept by 2.5 km and does not bring the chaser spacecraft to a proper rest relative to the target. This could of course be corrected, but would cost extra propellant and take extra time.

Continuing from https://forum.flightgear.org/viewtopic.php?t=35276#p341783, have you thought of integrating your c++ code into simgear and providing a Nasal wrapper function to expose the numerical calculations to Nasal? If computation time is ever an issue, the use of the ubiquitous BLAS libraries to replace the MathHelpers functions might make a c++ backend significantly more advantageous than a Nasal backend.

Computation time is only an issue because we're generally getting solutions too fast - in the real Shuttle, a Lambert fit usually took around two minutes to compute - the Nasal code usually takes less than half of that. We're regularly able to compute stuff 'instantaneously' which took of the order of 20-30 seconds aboard the real thing, so in places I have even inserted timers to generate a delay.

Not much point then. As for a single aircraft, I would have assumed that this code would have been useful for future FG spacecraft visiting the ISS (or other LEO targets). It might even stimulate interest in FG rocket building

I got some use cases with higher orbit insertion (Shuttle with OMS kit mostly...) recently for which the tool wasn't really working well, so I invested some work to fix various issues.

The PEG-4 fitting should now be more stable (aka the range of parameters for which it converges wider) and the fit becomes progressively more permissive with the number of iterations - assuming people would rather want an inexact solution than no solution - for practical applications I think it's often about fractions of a second of burn time, so it may not even be possible to reach perfect accuracy anyway.

There's also a bug fixed for the second Lambert burn when inperial units are chosen, and the 'up' velocity definition in proximity coordinates is now based on the proper parallel-transported derivative.