Jim DiGriz

MJ probably has the best PID controllers in KSP-land since Sarbian put a ton of time into the "MJ" PID and then went and ported over the kOS PID controllers and integrated them. What we're left with is that this is not an easy problem, and nobody in KSP-land seems to have general purpose solutions to it. I think real life spacecraft (at least shuttle-sized ones) don't use PID controllers and the attitude controllers are tuned by calculus of variations solutions to the problem given the torques, moment of inertias and response rates. But that is some solidly graduate level math. Other people have tried and failed at non-PID controllers in KSP-land before because high-school level algebra/calculus isn't sufficient to solve that problem so PID controllers have historically been used instead. In Chapter 9 of "Optimal Control with Aerospace Applications" example 9.1 on page 179 is "Single-axis spacecraft attitude control problem" https://www.amazon.com/Optimal-Control-Aerospace-Applications-Technology-ebook/dp/B00GG9YORO That is probably the direction that attitude control needs to go to improve it to the point where it doesn't need user tweaking. Pull Requests accepted. Up until then, users are absolutely expected to learn to create rockets that the PIDs can handle better (e.g. less control authority => less wobbling), or to learn to tune the PIDs themselves.

It does take that into account, the countdown timer is coming from KSP itself though which does not.

Software developer. Server configuration management software. Dayjob has gotten a bit boring. In college I was a physics-astronomy double major before dropping out -- mostly because I spent too much time in the library and at the computer labs working on stuff that was interesting to me rather than always going to classes... And I'm kinda jealous, I would kill to pick the brain of someone who worked at CSDL on guidance...

@dmsilev @Papa BullDust dev build #819 has a checkbutton to do the old coplanar transfer

Possibly, I found some bugginess when I was investigating the prior reports, but real life has intruded on KSP time.

I've actually got some plans on that latter issue. The PEG/PVG node executor already grabs the target orbit instead of the maneuver node and then executes a finite burn to hit the orbit exactly rather than interacting with the maneuver node (which makes it work with principia nodes as well, which do not burn down). It wouldn't be too hard to have that node executor grab all the future target orbits and execute burns to hit those target orbits. By grabbing the last orbit before even doing the first burn, then any small inconsistency in the burn would just get fixed later. And if the maneuver planner was changed to support passing back an array of future maneuver nodes then all kinds of possibilities open up (chopping up interplanetary burns into N burns with full orbits between them, the optimal N-impulsive stuff, etc). That is all still sitting on a development branch though needing lots of debugging.

I think the latter problem is actually due to the way that I clip the transfer time which is a heuristic that can be tweaked (and really should be made explicitly tweakable). But yeah ultimately the problem there is that I'm trying to confine it so that it avoids finding solutions that are way too long, which is a multiple-minimums issue. Given the thought that I put into it though (which was "eh, that looks awful, lets try half that" I think that can probably be improved). The mid-course correction burn being inserted and dropping the dV requirement makes a lot of sense though. That is pretty compelling for adding back the simplistic coplanar version. There's actually an algorithm that starts with the two-burn solution and automatically finds the optimal N-burn solution from it: https://arc.aiaa.org/doi/pdf/10.2514/3.4949 My evil master plan is to try to get to having that implemented eventually, so it would just find these MCCs for you. But that isn't going to happen any time soon. Also been considering what the overall UX for this should really look like (including going all the way and just throwing up porkchop plots for users to select regions out of). One thing I'm considering is just having an entirely separate advanced maneuver planner window that was broken out on its own, but I kind of hate all the window sprawl already.... I'm already thinking that the hohmann transfer function being cluttered up is the wrong UX for newbie users anyway. And I left all the old functions lying around in the code because I kind of anticipated I'd want to add it back in. Its just UX, which in many ways is a much harder problem than nonlinear optimization...

It doesn't. There's some additional time added to pre-burn for slewing. It also doesn't ignite until it is aligned with the node.

Yeah, it calculates it, that field needs to be removed.

Correct.

Hah, I forgot about that, of course it works interplanetary as well if you escape first. Can you beat the advanced transfer to another planet function or do you just prefer to eject out of the SOI first then Hohmann transfer?

dev will work fine in 1.4.x or 1.5.x just ignore the compatibility check.

If that's in the last couple of seconds, then its terminal guidance issues, you need to freeze guidance at some point before the end or you get swamped by errors. Basically the same problem that MJ has when it has nearly burned a maneuver node to zero and if you have the deltav m/s tuned up too high it'll constantly try to 'hunt' the maneuver node and due to errors can never burn it down to exactly 0 m/s. All guidance has this problem.

I tried to do that last night. The fractional orbital period tunable happened because I realized that doing distance correctly is a bit more difficult than it sounds (its relatively simple in the perfectly circular case, but getting it right in the arbitrary case isn't really a one-night tweak but more like a solid weekend of work).

Your target is an orbit. It can be any orbit, even a constructed one. I've got a task on my task list to extend this to transfer to manually entered orbits (with or without selecting some of the elements to match a target orbit). That will probably require the ability to drop down the second rendezvous maneuver node as well though, since for an arbitrarily constructed orbit it may not be entirely obvious how to construct the second burn (in the satellite constellation case you just circularize at your target apo and you're done).

Dev build #808 with a bugfix to where the hohmann planner would fail to create a node randomly. Also I probably just made best friends with everyone who puts up satellite constellations since you can now lead/lag a target in its orbit by a given fraction of its period. So "0.25" to lead 90 degrees in a circular orbit. https://github.com/MuMech/MechJeb2/pull/1065 https://ksp.sarbian.com/jenkins/job/MechJeb2-Dev/808/artifact/MechJeb2-2.7.4.0-808.zip

https://github.com/linuxgurugamer/MechJebForAll/blob/master/GameData/MechJebForAll/MechJebAndEngineerForAll.cfg that file is all there is to it.

You forgot to include the AR202 part on your rocket and forgot you also need to install MechJebForAll / MechJebEmbeddedUniversalFree / MechJebAndEngineerForAll or whichever mod you used on 1.4.x?

Heh, I was not entirely planning on the Hohmann transfer planning rewrite shipping as a release build today... I guess that's why there are two zeros in 2.8.0.0 and an infinite number of integers tho... Expecting fully modded installs to work perfectly the day of a release of a new KSP minor version is not realistic at all. Of course everything is broken. Even though it looks like it is pretty compatible it will almost certainly have broken someone and mods like Kopernicus that have strict suicide checks in their start up code and will refuse to run at all on new versions. Mod authors will need to start doing work, and some of them may not even be aware a new version landed. RSS/RO/RP-1 players are still back on KSP 1.3.x because not everything for KSP 1.4.x is up to date yet. If you have joint issues look for something related (like Kerbal Joint Reinforcement?) in your mod list and look for errors it is throwing in KSP.log

That has nothing to do with MechJeb.

FOR PEOPLE WANTING 1.5.0 SUPPORT: Gotta wait for Sarbian to do the necessary to get really official builds shipping against 1.5.0 binaries. BUT I just tested and I don't see any changes that are required for 1.5.0, and compiling against 1.4.5 and installing on 1.5.0 seems to work fine. I think you can just ignore the mod incompatibility warning.

And just like that there's a build #807 I decided I hated what was going on with that transfer to minmus so cut the default transfer space search size in half back down to what the ideal hohmann transfer time is, and this is the result: That is probably what people want by default. (the asteroid mission is still goofy, I gotta find a way to make that more sane by default...)

Also a note from a question that came up in chat... This does not include a course correction -- that would actually be considered 3 burns. While this only draws a single maneuver node on the trajectory, the point of intersection with the target trajectory is where the next node should go. I'm thinking I should include a checkbox to also drop that node, if only to make it clear what is going on (this is however, difficult without some major plumbing changes to MJ since there is no support for dropping multiple maneuver nodes from a single maneuver operation -- they all return one { dV, UT } pair, they would need to be replumbed to support returning an array of those pairs). But the point is that this is like the Hohmann transfer. You do a burn to change to the transfer orbit, then you later do a burn to go from the transfer orbit to the target. For transfers to a planet or moon the trajectory will always impact and the second maneuver would be in the center of the body. What would be slick would be to notice that the target is massive and then prompt the user for a periapsis and apoapsis radius to capture into. Or to include just the current 'fine tune closest approach' functionality (which would actually be fairly trivial wiring I think).

Here is the old behavior of the hohmann transfer planner: That comes nowhere near close to minmus. Now here's the new behavior: This is going to get you there, but the transfer planner takes its own sweet time an the orbit swings way out past the orbit of minmus before coming back. This is the problem with optimizers is that they're both very clever and very dumb. This is a good case for why there either needs to be better moar cleverer bounds on the transfer time or it needs to be tweakable. I was gonna show off how cool it was for doing asteroid intercepts, but: Once again the optimizer is really clever and found that intercepting the asteroid at the end of the trajectory was the most optimal burn, but that is likely what nobody wants. So... Progress... But it really needs a way to constrain the transfer time... (which is actually not that difficult, I just hit my limit this weekend)

"Press 'F' to pay respects"