Jim DiGriz

So as a "weekend project" I replaced the Hohmann Transfer planner to turn it into a proper bi-impulsive optimal transfer planner (the generalized Hohmann transfer problem). This is bi-impulsive -- not bi-elliptical -- the bi-elliptical transfer is actually tri-impulsive. There are algorithms to refine a bi-impulsive transfer into an optimal N-impulse trajectory, which this could feed into, but this is not that. The default behavior if you have circular, coplanar orbits is that you just whack "create node" and it acts like the old Hohmann transfer planner, only it won't miss if you're off by a bit. But it will also plan optimal burns between non-coplanar / non-elliptical orbits. So you can launch into an equatorial parking orbit around Kerbin and plan a transfer to Minmus and it will actually hit Minmus now. It will even plan burns when one of the targets is hyperbolic. That means if you have a ship in a parking orbit and want to do an asteroid capture mission you should just be able to select the target and whack "create node" and it'll work and give you the optimum transfer. The "intercept only" switch is the sort of "mono-impulsive" case where you don't care about the cost of the second burn. So if you're going to lob a nuke or kinetic interceptor at something, this is what you want. The drag down also allows selecting the time of the burn via all the familiar MJ options for selecting the time of a burn. In that case no optimization is done of the departure time and it is fixed. This just landed in dev build #805 A near-future addition to this will probably be allowing textbox entry of transfer windows for the min departure time, max departure time and max transfer time. But I hit my limit this weekend. A word on what is going on under the hood is that this is a Hard(tm) problem in mathematics to solve. There are potentially very many basins involved in this problem (consider a porkchop plot with potentially a hundred blue basins) and picking the right one, FAST is Hard(tm). What I threw together uses a simulated annealing global optimization first pass. This is a stochastic, random algorithm that attempts to search out the space randomly, not always necessarily taking optimum steps, but slowly "cooling" towards taking small steps to better positions. Then there is a second pass where the output of the annealing algorithm is fed into Levenburg-Marquardt to just do a gradient search for the best solution in the selected basin. TL;DR: Random searching is involved. You may get slightly different results each time you compute the trajectory. Generally these are off by a single orbit in the source or destination orbit, and typically will not be off by more than a few percent in cost. That isn't really a bug (although its possible that further refinement could reduce the jumps). A standard-looking Hohmann transfer I've found to be reliable. If you see roughly circular, coplanar transfers jump around a *lot* that would be bad. The code is here: https://github.com/MuMech/MechJeb2/pull/1057 Let the bug reports flow... EDIT: yeah #805 is totally broken of course, gimme a second... try #806

- The MechJeb you are using with 'A' and 'B' numbers is Atlas-Centaur "PEG" (which is not PEG) - To get Shuttle PEG (actual PEG) you need to download one of the versions with the PEG changes: https://github.com/lamont-granquist/MechJeb2/releases - In real life NASA and Russian agencies had full blown trajectory optimizers so that the pitch programs they fed into their boosters put the rocket on a course where closed-loop guidance was guaranteed to pick it up and work. If they had guessed at a bad pitch program like KSP players do, then their rockets would have flown equally as bad. - I don't find it a compelling programming problem, or even a compelling historical problem to have old versions of guidance. In reality the old Atlas-Centaur guidance, and Saturn IGM and Shuttle PEG were all informed by better trajectory analysis on the ground and therefore performed vastly better than what we can get out of them with no help. So, no, I've entirely abandoned Atlas-Centaur guidance and mostly abandoned PEG as well (I'm still keeping it up to day with current MJ-dev). The problem is that people ask "can it do this? can it do that?" and the answer for PEG in a lot of cases is that it can't. So I'm going to build guidance that can. If that means that it generates the flip problem that you get ahistorically high guidance accuracy I don't have the time or interest in caring about that problem. And no logs won't help, there's not going to be anything in the logs and the solution to problems with Atlas-Centaur guidance is to use PEG.

The Atlas-Centaur era guidance is much more approximate guidance than Shuttle PEG is, and the Shuttle PEG code includes proper yaw steering. Shuttle PEG should bug out less and steer better. Yeah that should happen a lot less often with Shuttle PEG. The issue with Shuttle PEG though is that I converted the node executor over to use PEG and it occasionally bugs out as well, but there's no option to turn it off. You generally want to make certain to lead all your node creations with enough lead time so that your vessel can slew around and then have at least 1/2 burntime before the node -- if you don't do that it may freak out.

That isn't PEG, that is the old Surveyor-era Atlas-Centaur guidance that precedes both IGM and PEG. The correct reference for that is here: https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19660006073.pdf The orbiter notes are incorrect and buggy, and I can't recall exactly where (it's been over a year and I've forgotten the algorithm, not to mention the specific bugs in that wiki). An implementation of that code that works is here: https://github.com/MuMech/MechJeb2/blob/7a78a57740a37eeb5509e2c3f8d09c012b347648/MechJeb2/MechJebModuleAscentPEG.cs (Yes that file is still named "PEG" but I named it incorrectly ages ago) Where my code agrees with the NASA code and disagrees with OrbiterWiki you should not use the Wiki pseudo-code (where my code disagrees with the NASA paper, I'd bet I've got bugs and NASA knew what they were doing...) Note that I never got the yaw steering implemented. The N-stage summations in Terens paper are brutal to implement and debug to eliminate typos. The actual PEG algorithm is easier to implement fully.

+1 there were actually some odd bits of code in that PR, i just couldn't figure out what the edge conditions might be

FWIW I've never used it either. Using the TGT mode on SMART.A.S.S. on both sides. My preferred docking indicator is Navball Docking Alignment Indicator CE (its more lightweight UI than the Docking Port Alignment Indicator which has its own window, but it may take more getting used to). I use MJ rendezvous stuff to get within about 100m, and then either setup the TGT mode on both sides (using RCS on the station to rotate the station so its trivial to dock) or else I just fly it manual with the docking indicator on the navball (it just takes some getting used to training your fingers how to push the navball indicator around). This is one of those things that I'd suggest HyperEdit'ing some ships into orbit and playing around with docking until you can do it "manually" (by which I mean using MJ but without using the docking autopilot). With SmartASS on both sides all you have to do is use MJ to get close and kill relative velocity and then just worry about closing speed and little puffs of translation to keep things perfectly aligned. And if you don't know about the HNIJKL keys for RCS control then learn about them. H/N is all about managing relative velocity, and then IJKL is all about getting your closing velocity to line up perfectly with the docking port. As you orbit during the maneuver your velocity vector will drift slightly (just due to orbital mechanics) so you do need to use IJKL to keep perfectly aligned. Once you get used to it, you should be able to stop "cheating" with SmartASS on the station if you like and be able to position your craft over an arbitrary docking port and use the indicator to dock.

You don't need to match inclinations with the Moon. You can launch into a polar orbit and transfer to the moon just fine. The timing of the launch becomes more of an issue in order to select a plane where the transfer orbit will be cheap.

"bit wiggy" it doesn't know anything about N-body and uses KSP's maneuver nodes which don't know anything about N-body.

I believe the existing code in MJ was written to handle the pre-1.0 soup atmosphere, and will not work post-1.0 I don't know of anyone trying to tweak the existing algorithm to make it work. I'm working on writing an actual grown-up trajectory optimization algorithm for MechJeb to use (not a highly limited finite burn executor like PEG) which should be able to solve nearly any problem. With the addition of aerodynamic forces it should be able to solve the hoverslam problem exactly (without any deep throttling). But I'm months away from that. I don't have a lot of interest in trying to kerbal up fixes to the existing code. The best way right now to do SpaceX style launches may be writing your own kOS code or modifying someone else's and not using MechJeb.

There's a lot of different Ascent Guidance options. You're going to have to be much more specific about what you're trying to do, how you're trying to do it, and what is going wrong. AFAIK nothing got touched recently, I've been off working a major overhaul that turned into another major overhaul...

If it's just corkscrewing then it's probably a design problem where either you've got too much aerodynamic torque causing it to roll and/or you don't have enough torque from engines or reaction wheels. If you can manually use the controls to neutralize the roll then it might be MJs fault. If it's oscillating around the roll axis its probably MJs PIDs fault, and tuning the attitude controller could fix it. If the displays in the lower left show that MJ is pinning the roll control at the rails trying to fight the roll but its still rolling then its pretty much certain its a design flaw. Can you launch the rocket without MJ and not have it roll or does it spin under manual control as well? etc..

From the old bug I submitted against KSP it looks like this bug is getting actively worked on.

One of these days after I've solved the ascent and node executor issues adequately, I plan on giving the landing guidance module a complete overhaul with a decent trajectory optimization algorithm and closed-loop guidance which should be able to hoverslam a rocket pretty near perfectly in any atmosphere. There's months and months between here and there though.

Yeah, I actually already solved the problem of the maneuver node disappearing in PEG assisted burns. PEG is kind of ideal for Principia usage since it targets the next orbit patch rather than caring anything at all about the maneuver node, so after a bit of defensive coding it no longer aborts the burn when the maneuver node disappears, and it still has a copy of the desired target orbit, so it just burns to get you on that orbit. I've considered a feature where if you have e.g. three maneuvers planned that it could grab the next orbit patches for all of them, and then burn to target the orbits so that whatever imprecision occurred in the first burn would be compensated for in the second burn, etc. So you could plan a multiple burn ejection maneuver and hit "execute all nodes" and it would just run through them all and wind up precisely on course. Then of course, working backwards have a button to bust up an ejection burn into N burns. Benefits of targeting orbital elements rather than the idealized impulsive burn node. If anyone wants to play around with it now: https://github.com/lamont-granquist/MechJeb2/releases Note that the Node Executor has been replaced with PEG and there's no option to turn it off and go back, and there's known bugs with small dV / small lead time and possibly high inclination node execution that I'm working through (i.e. its a snapshot of my dev branch, it is not released code--i would not recommend it for serious career saves at this point). To make it work with principia, FIRST you want to turn on "snow on navball" so that PEG has something to hold onto. THEN you need to select "inertial frame" so that the navball doesn't rotate around the orbit. THEN you need to select "infinite thrust" so that the orbit coming off of the navball and the principia orbit are tangent. THEN it helps to "show patched conics" and ensure that the patched conic prediction and the principia prediction are tangent at the location of the maneuver node (if they're not something is messed up). THEN you need to coast to just before the ignition point of the maneuver node manually in order to get the best agreement between the patched conic prediction and principia's prediction. THEN finally hit execute on the maneuver node. Talking to principia correctly will result in that process just becoming "plan a maneuver and hit execute" and it'll actually target the principia orbit instead of a mostly-correct tangent orbit -- that whole tapdance is just about letting MJ grab a tangent orbit to the correct principia prediction.

Well we do the "Simulation" with the PatchedConics API here: https://github.com/MuMech/MechJeb2/blob/dev/MechJeb2/Maneuver/TransferCalculator.cs#L394-L398 Everything will look like it works correctly, and I can drop Debug.Log's in there showing that what the optimizer calculates is a maneuver which leaves e..g. Kerbin and has one patch there, then the next patch is heliocentric. then the next patch is in the SOI of the target and hits it exactly. Then it drops a maneuver node with exactly that dV and UT and what comes off the maneuver node is a trajectory which interacts with the Mun and throws off the rest of the trajectory. So what it looks like is that our "Simulation" is missing some extra glue code which "finds" that Mun encounter on the way out. It vaguely smells like some of the changes that went into the orbit class to deal with closest-approaches might be responsible? There's other cases where it just fails to find any solution and I've tried to debug those and gotten nowhere and can't seem to understand what is going on there at all. I think those tended to get trajectories that would get to the right point (via "TruePositionAtUT"), but wouldn't find an SOI there at all, like Moho was missing in the Sim which made no sense to me. All you'd get was a heliocentric orbit which hit the right point, but nothing was there. Then I even included the attempts to roll it forwards a couple orbits and recompute and it still fails. Most of my testing was done on Kerbin->Duna transfers where the interactions tended to fairly often show up because everything (Kerbin-Mun-Duna) is fairly coplanar so interactions are common. Kerbin->Moho was more useful to find trajectories which just barfed (particularly without checking 'include capture burn' -- it was more sane when that was ticked). AFAIK this bit never gets hit so is unlikely to be responsible: https://github.com/MuMech/MechJeb2/blob/dev/MechJeb2/Maneuver/TransferCalculator.cs#L440-L445 I experimented around with various different ideas for this as well: https://github.com/MuMech/MechJeb2/blob/dev/MechJeb2/Maneuver/TransferCalculator.cs#L446-L449 I think I tried reusing the SolverParameters object rather than making a new one, but fell back (i think) on just the way it was before... I might have just started at it all too long and started hallucinating though... not the first time i missed something simple and relatively stupid...

The problem there is that the PatchedConics API has changed in KSP and there's no public information on how to use it correctly. MechJeb was the best documentation on how it worked, but it changed. I can see some clear cases where what is going on is that the advanced transfer planner is missing an interaction with the Mun/Minmus/Moon on the way out of the system (will also affect coming back from Jool and its moon, etc) and sometimes it still does succeed, but the maneuver node which is picked by the transfer planner then shows the correct outgoing interaction with the moon and the planned transfer is off. Other times it seems to just bork the transfer planner completely. I have no idea how to fix without being able to look at the KSP sources or without a massive effort in disassembling the call sequence that the maneuver nodes actually use. The result is that you have to hunt around when it throws that error. It can help to draw a square on the transfer planner and magnity the low-cost section you actually care about and then hunt around in there. Try other transfer windows. Try ticking or not ticking the box to include the capture burn and see if you can hunt around and find a decent transfer window that way.

It will eventually, but not in response to passive-aggressive demands.

You waited for the steam summer sale as well?

On the convex optimization paper, this is a much more accessible overview: https://www.researchgate.net/publication/316988674_Survey_of_Convex_Optimization_for_Aerospace_Applications It mentions three software packages SDPT3 (Matlab), SeDuMi (Python) and ECOS (C) which are free and can be used to solve convex problems. Of those the latter being written in C would have a hope of being used natively by MechJeb via P/invoke to C similar to how Principia is written in C++. Obviously someone could use kRPC to use SeDuMi, but to use python with MechJeb you'd probably want to plug MechJeb into kRPC the same way kOS has plugins for e.g. Trajectories.

Yeah so I worked at debugging this all night last night and figured out how to make it work, but it took some additional patching of the node executor in mechjeb (still patches sitting on my machine and not pushed anywhere or released that i'm testing). In the flight planner you need to click "instant impulse", "show on navball" and "inertially fixed". This does three things. It gives me a maneuver node to grab the trajectory off of ("instant impulse"), it fixes the node in the internal frame of the impulse ("inertally fixed") and models the node impulsively ("instant impulse"). The result is that if you click "display patched conics" to look at the keplerian tangent orbit coming off of the maneuver node that it very closely approximates the planned trajectory. What PEG can do then is solve the finite burn problem of going from your unpowered coasting orbit before the burn to your unpowered coasting orbit after the burn. The result is that e.g. I could hit the Mun with a periapsis of 46 km compared to a planned periapsis of 43 km, and burn 3-4 more dV of fuel compared to the 850-ish planned dV (so a 0.5%-ish penalty for the finite burn over the plan). I need to add some kind of RCS to my vehicle and redo the test to see if that makes it better or not, but I suspect that the 3km deviation there is due mostly to the deviation between keplerian approximation to the target coasting orbit and the actual N-body orbit over the course of the burn (and possibly due to the impulsive burn not quite being perfectly impulsive). At any rate, once I can poke Principia to get the real N-body coasting orbit from the planner then it should get very exact compared to plan. I'll post an update once I get the code into a releasable (although probably beta quality) state.

The point is that you need to launch it and watch the pitch program and see what it does. You won't know until you get to booster sep what the value is that PEG will predict. It may be wildly off above or below where your rocket pitch is at that point. Based on what actually happens during the launch you need to probably adjust the pitch rate up or down to initially loft it higher or lower. Without having a proper trajectory optimizer (more or less all that yapping I did in the long answer above about convex optimization) you are the trajectory optimizer which is done through multiple launches of the same vehicle and building up skill at getting a feel for how the rocket responds based on how you tweak the pitch angles.

Interplanetary transfer planning generally starts with patched conic solutions. Searching NTRS for "patched conics" turns up a bunch of references: https://ntrs.nasa.gov/?N=0&Ntk=All&Ntt=patched conic&Ntx=mode matchallpartial&Nm=123|Collection|NASA STI||17|Collection|NACA Where you wind up eventually is somewhere like this: https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20160001644.pdf The patched conics stuff is fairly difficult undergraduate-level math. The real stuff with n-body physics and proper optimization methods is going to be graduate level math (starting with Calculus of Variations and Primer Vector theory and then choosing some suitable optimization method to learn about). Richard Battin's book is very good as a foundational reference (it won't present pre-packaged solutions to all these problems, but its essential background knowledge): https://arc.aiaa.org/doi/book/10.2514/4.861543 He's pretty much the guy who did the math that sent the Apollo missions to the Moon (and invented all the math that went into late-50s and 60s-era IRBM/ICBM guidance). There's some discussion in there on alternative means of doing trajectory optimization that only rely on undergrad-level calc, but they're involved. Battin also has numerous tricks and insights. That books is also probably the best reference on the Lambert problem that I've found. Vallado's book is also good: https://www.amazon.com/Fundamentals-Astrodynamics-Applications-Technology-Library/dp/1881883183 A better place to start out initially is probably: https://www.amazon.com/Orbital-Mechanics-Engineering-Students-Aerospace/dp/0080977472 Note that if you're end goal is N-body interplanetary trajectory optimization, none of those books will really fully lay out a solution for you. A graduate level textbook that gets you going with primer vector theory and introduction to TPBVP solvers is: https://www.amazon.com/Optimal-Control-Aerospace-Applications-Technology/dp/146148944X Then the book which actually talks about ways to solve the problem you really want to solve is: https://www.amazon.com/Spacecraft-Trajectory-Optimization-Cambridge-Aerospace/dp/1107653827

There's a wiki: https://github.com/lamont-granquist/MechJeb2/wiki Note that using it in stock is probably a really bad idea, it is pretty much for RSS-only. You might be able to make it work, but it'll also all change after Shuttle-era PEG lands in MJ.

Yeah, convex optimization algorithms are at the leading edge of current research in trajectory optimization. I'm working my way through late-60s era calculus-of-variations style trajectory optimization and that is more likely to land in MechJeb sooner rather than later. Right now I've got proper PEG (shuttle-era PEG, not Atlas-Centaur-isn't-really-PEG-explicit-guidance that is currently released in MJ) wired up to the Ascent manager and Node executor in my own dev branch. We can probably improve that even more by some later explicit guidance algorithms which would be more suitable to stock ascents off of Kerbin (I've been trying to figure out how to use PEG on Kerbin and its a lot more difficult than Earth). We could also use a real CoV trajectory optimizer -- but consider that means adding a runge-kutta integrator, an algorithm to compute numerical jacobians plus a quasi-newton raphson root finder that degrades gracefully into a gradient descent method (stock newton raphson can't handle the spacecraft trajectory optimization problem) and wrap that with a multipoint boundary condition solver to chop up long burns. And all that needs to be debugged and run right. And convex optimization is going to be a lot harder with no off-the-shelf convex optimization routines written in C# (and even in C/C++ any libraries will probably cost $$$$ to use so those are out). And largely the only pay off I can see to convex optimization that is going to be useful to KSP is going to be dealing with integrating the atmospheric drag part of hoverslams. We should be able to wire up PEG to to airless landing problem just fine for KSP and get a really optimal landing guidance script without needing convex optimization. I can see some possible uses for it so that the optimizer could automatically avoid terrain, but we should be able to solve that problem both heuristically and through some obvious mission planning advice -- if you try to land on the immediately opposite side of a crater from a very low orbit that skims the surface, you shouldn't be that shocked that you lithobrake into the lip of the crater, so don't plan those kinds of missions... And when it comes to hoverslams in an atmosphere we can probably use PEG plus heuristics to deal with the drag -- run a full CoV simulation first with a drag model and use that solution to tweak PEG and while the result might not be perfectly optimal it should beat any existing hoverslam script. From the paper: "Onboard sensors for terrain-relative navigation generally require specific viewing orientations, which imposes a constraint on the vehicle orientation (attitude)." Trying to solve the optimization problem with those kinds of constraints is the kind of thing which is motivating SpaceX and NASA towards convex optimization for closed-loop guidance. KSP players + rockets don't have to worry about those kinds of constraints. So for KSP-level problems we can probably do something more like this: https://arc.aiaa.org/doi/abs/10.2514/2.5045?journalCode=jgcd That handles the Ascent problem, but similar to how IGM was used for lunar landings and how PEG can be used for landings, we could adapt that code to hoverslams in an atmosphere. Basically that is just a CoV solver, with a drag model, path constraints on aerodynamics and analytical solutions for the coast and burn arcs for speed so it can be run closed-loop.

Looks like the trick I was missing was to turn off Principia's finite burn modelling, although I seem to have some kind of bug which shuts off the engines halfway through the burn, so I need to do some debugging before I can release a version which I can state truly handles burn execution with Principia. I'm reasonably confident that I can work it out at this point though.