Jim DiGriz

This is still pestering about the update. No release, no updated thread topic => no it should not be considered stable.

Generally its better to approach the problem as an optimization problem rather than a system of equations to be solved. So use an off the shelf solution to the Lambert problem, wrap that with your source and destination orbit propagators (e.g. Orbit.GetOrbitalStateVectorsAtUT ) and pose the problem as a minimization problem of finding the starting time and ending time (or duration) of the transfer that minimizes the deltaV. To do that you have a 2 dimensional root finding problem with two variables (start and end time). Feed that into Levenburg-Marquardt and you should get an accurate result. Of course the problem is a global optimization problem with many local minima (all the upcoming transfer windows) so you need to feed it an initial guess. That's enough to do a simple helocentric solver. You can also do a solver that uses KSP's Orbit class to propagate orbits using the actual in-game patched conics API. In which case you can adopt a "shooting method" where the time and 3-vector of the burn can be optimized, and then you propagate to find the point of closest approach to the target orbit. Then wrap that with Levenburg-Marquardt, although its a bit tricky since you want to minimize the delta-V of the burn while keeping the final orbit nearly intersecting the target. A lot more clever things can then be done by replacing Levenburg-Marquardt with an NLP solver like ipopt or Matlab's fmincon, to do constrained nonlinear optimization, but that is also much more complicated.

For root finding on a line you should look at Brent's method: https://en.wikipedia.org/wiki/Brent's_method Or the brent.m file here: https://www.mathworks.com/matlabcentral/fileexchange/73600-trans-lunar-trajectory-optimization-otb-version For N-dimensional root finding Levenburg-Marquardt is the next step up, C# code can be found here: https://www.alglib.net/optimization/levenbergmarquardt.php Or Matlab's fsolve: https://www.mathworks.com/help/optim/ug/fsolve.html

Much harder to do that and nobody has the interest to write that code.

Create a directory GameData/MechJebUnlocked Make sure you also have ModuleManager installed

Lambert solvers. In the simplest case, neglecting the planetary orbits and only looking at the heliocentric problem you have three orbits and two unknowns. One is the coast to your departure time, which is determined by the departure planet's orbit. The last is the coast to the arrival time, which is determined by the arrival planets orbit. To figure out the transfer orbit from the departure position and time to the arrival position and time you use a Lambert problem solver. MechJeb actually has two. I think this one is Battin's method: https://github.com/MuMech/MechJeb2/blob/dev/MechJeb2/LambertSolver.cs This one is Gooding's Method: https://github.com/MuMech/MechJeb2/blob/dev/MechJeb2/GoodingSolver.cs I think the Gooding one is robust enough now that the former could be deleted, although I haven't fully tested the multi-revolution behavior of the Gooding Solver yet. Anyway. Now given the departure and arrival times you can solve the problem for how much delta V it costs for the departure burn and for the arrival burn (unless you're not going to match orbits and are going to do an impactor or a flyby). The problem then becomes searching for departure and arrival times which minimize the cost of the transfer orbit. You can brute force search that and that is what produces a porkchop plot. Or you can turn it into a minimization problem and use off-the-shelf algorithms to find the minimum value. Newton's method is the Calculus 101 tool that can be used to solve that problem, but since derivative information is difficult to obtain for the problem, its better to use some kind of quasi-Newtonian solver like Levenburg-Marquardt. For finding global solutions to the optimization problem that is harder and is the domain of simulated annealing or basin hopping algorithms.

That is normal output and isn't an error.

need ModuleManager as well.

And just like that there's an #899 build for KSP 1.8 which has the shader.bundle in it and fixes drop-down menu issues and some other glitches: https://ksp.sarbian.com/jenkins/job/MechJeb2-Dev/899/

KSP 1.8 STATUS: Later today or tomorrow probably, time permitting on Sarbian's side, but generally Very Soon(tm). ModuleManager obviously takes priority for him to release first since everything depends on that. I've started working on 1.8 patches for MJ here: https://github.com/MuMech/MechJeb2/pull/1186/files

Would need to supply a `Vector3d force_function(double time, Vector3d pos, Vector3d vel)` (so passing a function handle rather than Vector3d forcevector) at a minimum so that the supplied force would be a function of time and could be a function of the dynamics. Because you need to supply more than just the force on the next physics tick, and you want to do more than supply a constant force for all time of the simulation -- you want to be able to say things like "apply a force that acts opposite the velocity vector".

@Eriksonn following some references from that Fukushima paper led to this paper: https://link.springer.com/article/10.1007/BF00053511 Which derives the gravitational field of a uniform density arbitrary shaped object using Polyhedron. Just skimming it it seems more accessible to someone with college calculus. It does it all analytically requiring no numerical integration or quadratures. My guess at a textbook that would cover integrating the series coefficients as integrals over the mass distribution would probably be (following the references in that paper above, and then following the recommendations on amazon to find something newer): https://www.amazon.com/Geodesy-Wolfgang-Torge/dp/3111174549/ Also I suspect that any graduate level classical mechanics course would cover that as well, but likely not in as much depth. I don't think there's going to be any undergrad text which cover it AFAIK. Certainly it wasn't covered in any classes of mine. Doesn't even seem like Arfkin + Webber covers it although it covers spherical harmonics and legendre functions so the basic math is probably there, but their slant is more towards quantum mechanics applications.

This is the correct answer. I'm not really certain that box is useful at all in stock launches right now for launch to plane. It should probably always be zero, and that textbox and all the code behind it should most likely get removed (although not from the rendezvous function, just from launch-to-plane).

BTW Ipopt looks like it is free to redistribute: https://github.com/coin-or/Ipopt My plan would be to wire that up to MJ by plopping the 3 O/S versions of the DLLs into the MJ source tree + builds and then doing the necessary to link to them, but you could probably wire that directly up to Principia's build system.

Yeah I think I've abandoned PVG now in favor of discrete pseudospectral techniques, but there's an even larger learning curve to overcome. What I'm shooting towards is more or less this: https://www.tandfonline.com/doi/full/10.1080/0305215X.2018.1472774 The pseudospectral techniques applied to rocket guidance starts with Rea's thesis: https://dspace.mit.edu/handle/1721.1/8608 But using the flipped radau points: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.660.3328&rep=rep1&type=pdf The analytic jacobian and hessian calculations that you need to do for that approach are complicated and what I'm breaking my teeth on right now: https://arc.aiaa.org/doi/10.2514/1.A32071 There's also the question of how to do mesh refinement that I haven't even looked at: https://onlinelibrary.wiley.com/doi/abs/10.1002/oca.957 Plus there's costate estimation to check optimality (and maybe refine convergence using the transversality conditions of the indirect ("PVG") method?) https://link.springer.com/article/10.1007/s10589-009-9291-0 Plus other refinements: https://link.springer.com/article/10.1007/s12567-017-0165-5 Right now I'm just playing around with different targeting conditions for a simple vacuum launch problem to be able to answer the question of "just wind up with a periapsis of 185km with the least amount of fuel burned" which I strongly suspect is not a 185x185 orbit, but just YOLO'ing it and throwing a numerical jacobian and hessian at it fails to converge. So I'm now trying to analytically take the derivative of the periapsis constraing with respect to cartesian coordinates and pondering my choices of coordinate system (although Rea's thesis makes a case for just sticking with cartesian for the general purpose case of terminal conditions). https://github.com/matt-weinstein/adigator That package might help with the analytical differentiation, but to do targeting of J2 you'd need to take the BLST elements and take partials wrt the coordinate system. So anyway that's why MechJeb development kinda stalled out for the past month or so... And I'd love to be able to take this package and integrate it with MechJeb but it is commercial/non-redistributable: http://www.gpops2.com/

That should probably get turned into a bug report: https://github.com/MuMech/MechJeb2/issues Right now I know I don't have time to investigate, and I'm guessing sarbs doesn't either. Kind of vaguely hoping that one is a bug in KSP and it magically gets fixed because it looks weird and seems to be tied to that specific part. Either that or there's something unique about that part which exposed a bug in MJ.

- I think that it gets it correctly in all cases, because the first block is responsible for adding or not adding mechjebcore to all the command pods. then the second block is responsible for overwriting all the unlock settings on all the mechjebcore modules. - RP-0/RealismOverhaul already adds mechjeb to all command pods and unlocks it all from the start, so this code disables itself and lets RP-0/RealismOverhaul handle it: https://github.com/KSP-RO/RealismOverhaul/blob/master/GameData/RealismOverhaul/RO_RecommendedMods/RO_MechJeb.cfg (plus a bunch more references to MechJebCore scattered around the configs) https://github.com/KSP-RO/RP-0/blob/6fb9c62edc1d467d01275b2030993e4aaf17a5b7/GameData/RP-0/Tree/ProceduralAvionics.cfg#L24-L46 there's some work going on right now to have MJ disabled when avionics are insufficient + disabled which is more the kind of integration that RO/RP-1 players want.

Yep, I just removed that. I don't entirely understand how I tested it and that worked, but that should be removed on dev now. And the reason for going this direction is that it should get the use case correct where someone creates both MechJebUseCommandPod and MechJebUnlocked -- so that they have to use the AR-202 part but everything is unlocked from the start. Which is a bit weird, but it makes the full 2x2=4 block of uses cases all semantically correct. With the other patch it would have ignored the MechJebUseCommandPod "setting". Now that I look at it MechJebUseCommandPod should really be MechJebUseAR202, it reads like it means the opposite now.

@steddyj I'm reasonably but not entirely certain that it is correct as its written. The first block should run first (at least I'd hope -- this is where the uncertainty lies) and should add MechJebCore to all ModuleCommand parts. Then the second block should run and it should update all the settings of all the MechJebCore modules. I fixed a silly typo a few minutes ago which might have been causing problems: https://github.com/MuMech/MechJeb2/pull/1165 Otherwise I checked this on a normal commandpod in stock and found that it worked correctly. Make sure to nuke the module manager cache.

Just created a new dev build #884: https://ksp.sarbian.com/jenkins/job/MechJeb2-Dev/884/ It has an update to that MM config file: https://github.com/MuMech/MechJeb2/pull/1164 You all should be able to: 1. make an empty folder in GameData named MechJebUnlocked 2. delete the ModuleManager.ConfigCache file to force MM to reupdate 3. restart KSP 4. gloriously cheat your way to orbit

Stage and a half is going to be more problematic with PVG than with old PEG versions because it is fantastically much more accurate about calculations now -- which means that due to the dV being off it accurately computes that a rocket with those stats will never make it to your target and refuses to converge. You might be able to beat on it with a hammer and find some way to trick it, but its getting better about trying to hack it not working. I'd suggest not building 1.5 stage rockets, its probably going to be too much of a pain. Nobody has reported a workaround to me.

Nope. No budget for tech writers. Really would need the userbase to maintain most of the docs to have any hope of it being done well. I did some docs for old PEG ascent launches, and need to do more for PVG (but it is all in flux right now so I won't waste time documenting stuff that I'm going to make out of date soon), but documenting the entire MechJeb API is something that won't ever get done unless it is collaborative.

Use the Attitude Adjustment menu, if you're using the HybridController (which you should) adjust the MaxStoppingTime. The default is now '2' which conserves RCS fuel. Turn that up to '10' and it will get a lot snappier.

Known issues. https://github.com/MuMech/MechJeb2/issues/1052 I have eventual plans, but they are very large.

Also if anyone is trying to use RSB with RO/RSS/RP-1 with KSP 1.4/1.5/1.6, when trying to load the stock ships it comes up with a warning about Tweakscale and InterstellarTextureSwitch2 on all the ships. Those can just be ignored and the ship will load. Tweakscale is not recommended for RO installs. IFS is also not something widely used by the RO/RSS community -- B9PartSwitch and RF and ProcParts already takes care of those kinds of issues -- I don't know that IFS would be bad to mix in, but it isn't necessary. So just ignore the warnings, then 'rebuild' the parts that have double-fuels and resave and everything should work fine.