[1.12.x] Anatid Robotics / MuMech - MechJeb - Autopilot - [2.14.3] [4th March 2023]

[IntoSpaceAgain]

12 hours ago, dlrk said:

Is there a way to have MJ simultaneously circularize and change inclination together?

 

2 hours ago, rmaine said:

Look at the very nice precise maneuver mod. (The mod author has computer issues that have kept him from updating the compatibility test, so it poodlees about not being compatible with 1.5.1, but it really is). Create the circularization mods with MJ; then the precise maneuver node editor will open up and allow you to easily add a plane change.

MJ's Manoeuver Node Editor will allow you to do the same, although the GUI isn't quite as pretty as Precise Manoeuver.

[rmaine]

10 hours ago, IntoSpaceAgain said:

 

MJ's Manoeuver Node Editor will allow you to do the same, although the GUI isn't quite as pretty as Precise Manoeuver.

Yeah. I guess I'd forgotten about MJ's maneuver node editor because I've gotten so used to precise maneuver. Precise maneuver these days (it once didn't) actually has a specific plane change button to change inclination by specified amounts, as opposed to you having to compute what delta-V in what direction you'd need.

[Jim DiGriz]

On 10/28/2018 at 6:28 PM, dmsilev said:

I've been playing around a bit with the new bi-impulse transfer function, and it would be nice if there was an option for the old Hohmann transfer functionality as well. Sometimes, a three-burn solution is just better. To give a concrete example, I tried a fairly standard Kerbin->Minmus transfer just now. With the 3-burn system, you do a ~920 m/s initial burn, then a plane change somewhere along the way (usually about 10 or so m/s, though it varies) and then the capture burn. With the bi-impulse, it was giving me a transfer burn of ~11-1200 m/s (using the "optimum time" setting). It was also picking a decidedly higher-energy transfer, taking maybe 6 days to reach Minmus, and hence needing a bigger capture burn as well. In all, I'd estimate it was giving a solution that was maybe 300 m/s less efficient than the previous setup, so call it 25% more dV. 

I assume that it's a combination of the higher dv cost of low-altitude plane changes (even when combined with the big prograde burn) and more importantly the solver getting stuck in a local minimum in parameter space. The latter is a Hard Problem to solve (I deal with nonlinear optimizers from time to time in my day job, so I'm very sympathetic to the difficulty), so being able to fall back to a numerically-simpler algorithm might not be a bad idea. 

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...

[dmsilev]

2 hours ago, Jim DiGriz said:

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...

Thanks for the response. With regards to the UX problem, perhaps expose only a few options by default (for the transfer maneuver, that could just lock the time choice to 'optimum' plus the create/execute buttons), and then a "advanced mode" button which is deselected by default but when clicked enables the full menu of possibilities. An automatically-growing window (similar to how the Utilities window grows when the Autostage checkbox is selected) might be the way to present that. 

In that advanced mode, a checkbox (deselected by default) for "prograde/retrograde only" would recover the old behavior. The mid-course correction burn can be done quite easily already (via the fine-tune closest approach maneuver type), so if you wanted to offer a simple three-burn trajectory, you could have the code offer to chain the two nodes together. Honestly though, I wouldn't bother; my experience has been that the second burn usually is a combination of a plane change plus some minor tweaks to the trajectory due to the initial burn being a tiny bit off, so you don't want to calculate the second burn until after the first one has completed and you know how the actual trajectory compares to the nominal one. 

[Rixerod]

Guys, is it possible to add the MechJeb2 AR202 case to every command module in "Career mode"? I believe there was a solution in the earlier KSP versions...

Edit: I think I found the solution, it's called MechJeb and Engineer For All mod. Sorry if this counts as ad, I didnt mean it and you can safely remove this post.

Edited October 30, 2018 by Rixerod

[Jim DiGriz]

13 hours ago, dmsilev said:

Thanks for the response. With regards to the UX problem, perhaps expose only a few options by default (for the transfer maneuver, that could just lock the time choice to 'optimum' plus the create/execute buttons), and then a "advanced mode" button which is deselected by default but when clicked enables the full menu of possibilities. An automatically-growing window (similar to how the Utilities window grows when the Autostage checkbox is selected) might be the way to present that. 

In that advanced mode, a checkbox (deselected by default) for "prograde/retrograde only" would recover the old behavior. The mid-course correction burn can be done quite easily already (via the fine-tune closest approach maneuver type), so if you wanted to offer a simple three-burn trajectory, you could have the code offer to chain the two nodes together. Honestly though, I wouldn't bother; my experience has been that the second burn usually is a combination of a plane change plus some minor tweaks to the trajectory due to the initial burn being a tiny bit off, so you don't want to calculate the second burn until after the first one has completed and you know how the actual trajectory compares to the nominal one. 

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.

[Zosma Procyon]

Stupid question but I'm a bit oblivious? Is this an updated mechjeb release? And does it include the little remote control looking Mechjeb part?

[Stone Blue]

3 minutes ago, Zosma Procyon said:

Stupid question but I'm a bit oblivious? Is this an updated mechjeb release? And does it include the little remote control looking Mechjeb part?

Not stoopid question... Only stoopid question is the one *not* asked

but, uhh, this is the original mechjeb release thread, since Sarbian took it over... and yes, its where you can find the latest release for KSP 1.4.5 and 1.5.1...
and yes, v2.8.1.0 is the updated (latest for 1.5.1)... and yes, it still includes the AR202 and Pod parts...

If you want to go partless, and add MJ to all command parts, LGG has this mod you can also install:
 

 

[Zosma Procyon]

If replace my Mechjeb file with this and load my saved game, will I get the error where everything with a mechjeb part is deleted because the mechjeb part files aren't found?

https://spacedock.info/mod/1854/MechJeb and Engineer For All

[Tonka Crash]

1 hour ago, Zosma Procyon said:

If replace my Mechjeb file with this and load my saved game, will I get the error where everything with a mechjeb part is deleted because the mechjeb part files aren't found?

https://spacedock.info/mod/1854/MechJeb and Engineer For All

That mod is installed alongside MechJeb. It doesn't replace it. That mod is just a Module Manager patch to add MechJeb functionality to all command pods and probes without needing the AR-202.

[Papa BullDust]

On 10/30/2018 at 1:48 AM, Jim DiGriz said:

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...

@Jim DiGrizI specifically came to the forums today to write about this issue, only to find user @dmsilev has nicely summarised the problem with the new Bi-impulsive. It can, in certain situations "waste" dV by performing the plane change at the same time as the acceleration burn whilst deep within a gravity well. I would like to add a simple request to add back into MechJeb the true Hohmann (co-planar) fuctionality. This would allow once again, the plotting of a later plane change manoeuvre at a more optimal time. I realise that this may well clutter up the interface a little, but MechJeb (I would argue) is a learning tool also; it may also encourage new users to seek out the differences between the two modes.

TLDR; please add the old Hohmann transfers back in!

[Kevin Kyle]

Mechjeb has disappeared. I dont know what happened. I think it happened while I was in the VAB editing a rocket I previously built. Thats when I first noticed. I had just written down the weight of the payload just prior to that then decided to rebuild that part. It did have a MJ unit on it. I basically trashed the whole guidance container I had and made another. Put the rocket back together and went to check the new weight and there was no window, in fact all the mj windows and tabs were gone. I cant imagine what I did. Its a very modded install. Im not even sure it was mj's fault.

Ive tried various things to fix it including removing and re-installing mj using ckan for it all. MJ2 on 1.5.1 Log file below. If anyone has any insight into what happened, I would appreciate it.

https://www.dropbox.com/s/crfehjgm2e9yqt1/KSP.log?dl=0

Oddly enough this seems to have been fixed with a just released ckan update for File Extensions plugin or CommNet Antennas Extension. Mechjeb parts suddenly have re-appeared and all is as if nothing happened. I dont know what to think. Dont even know what fixed it or what was wrong.

Edited November 4, 2018 by Kevin Kyle
Problem fixed

[sarbian]

Try deleting the cfg in C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\MechJeb2\Plugins\PluginData\MechJeb2

But you have a lot of exception from EVE, Scatterer and Kopernicus...

[Benoit Hage]

Hello @sarbian, hello @Jim DiGriz,

I'm having a problem with the new Hohmann / Bi-impulsive transfer (dev 814). When trying to intercept the Moon in RSS, Mechjeb is way to late to perforn the burn.

Printscreen (Imgur)

Mod list (Imgur)

Logs, save and craft (Dropbox)

Am I doing something wrong? Could this be a bug? Thanks in advance.

[Jim DiGriz]

On 11/5/2018 at 1:07 PM, Benoit Hage said:

Am I doing something wrong? Could this be a bug? Thanks in advance.

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

[Gorby1]

On 10/21/2018 at 8:34 PM, Jim DiGriz said:

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?

I could never get the advanced transfer to another planet to work well for me. Obviously this is a problem with my brain and not Mechjeb, but yes - instead I always left Kerbin SOI then did a Hohmann transfer. Which of course didn't work very well either unless I first matched or came close the the target's inclination, but the bi-impulsive transfer takes care of all of that much better. I realize my orbital maneuvers could be far more efficient, but... I'm no rocket scientist, what I do "works" in the end, and I have fun doing it!

[DerekL1963]

1 hour ago, Gorby1 said:

I have fun doing it!

^^^  The most important thing after all!

[sarbian]

On 9/26/2018 at 1:11 PM, sumghai said:

@sarbian, I have a bit of an unusual request/question.

As part of my upcoming revamp of the SDHI SMS mod, I have a Service Module that combines an engine, a fuel tank and a decoupler, and it is important that all three are integrated into the one and the same part, so I cannot split them up again.

Some of my beta testers have noted that MechJeb displays a delta-V of 0 m/s for this Service Module stage. even though it is a functional engine that does consume fuel.

How does MechJeb determine what parts counts towards the delta-V budget of each stage? Is there a way to manually force my Service Module part report this delta-V information to MechJeb?

It took some time (mostly because I did not have any...) but the last dev finally work properly with your Service Module (and most likely other parts with similar problems).

Hopefully I did not break anything else.

[drtedastro]

 

thanks for the updates.

Cheers.

[JonathanPerregaux]

I noticed that Ascent Guidance and Smart ASS seem to rotate my ships 90°. I have a rocket-boosted spaceplane and it ascends on edge with MechJeb instead of a normal "flying" orientation. I have to "control from here" on the MechJeb part, which causes the navball to go sideways and show the ground/sky vertically (eek), but fixes the ascent orientation of my plane.

Edited November 11, 2018 by JonathanPerregaux

[Guest]

Does MechJeb ascent guidance work with principia? So far, it simply wants to flip my rocket upside-down.

[Gordon Dry]

Last session I was using #814 and found this in the log - I never had that before:

Exception: Can't access internal member 'GUIUtility.systemCopyBuffer' it may have been removed / renamed
  at MuMech.MuUtils.GetSystemCopyBufferProperty () [0x00000] in <filename unknown>:0 
  at MuMech.MuUtils.get_SystemClipboard () [0x00000] in <filename unknown>:0 
  at MuMech.MechJebCore.Update () [0x00000] in <filename unknown>:0 
 
(Filename:  Line: -1)

Exception: Can't access internal member 'GUIUtility.systemCopyBuffer' it may have been removed / renamed
  at MuMech.MuUtils.GetSystemCopyBufferProperty () [0x00000] in <filename unknown>:0 
  at MuMech.MuUtils.get_SystemClipboard () [0x00000] in <filename unknown>:0 
  at MuMech.MechJebCore.Update () [0x00000] in <filename unknown>:0 
 
(Filename:  Line: -1)

Exception: Can't access internal member 'GUIUtility.systemCopyBuffer' it may have been removed / renamed
  at MuMech.MuUtils.GetSystemCopyBufferProperty () [0x00000] in <filename unknown>:0 
  at MuMech.MuUtils.get_SystemClipboard () [0x00000] in <filename unknown>:0 
  at MuMech.MechJebCore.Update () [0x00000] in <filename unknown>:0 
 
(Filename:  Line: -1)

Something went bork again in my career as it seems - as always.
Full log and stuff:
https://www.dropbox.com/s/xny5vt2pt8bp2yq/2018-11-11_1 KSP.log and stuff.7z?dl=1

[PTGFlyer]

Does MechJeb have a straight-up autopilot? Like, can I set it to hold an altitude, speed, and heading?

[sarbian]

13 hours ago, PTGFlyer said:

Does MechJeb have a straight-up autopilot? Like, can I set it to hold an altitude, speed, and heading?

The smartA.S.S  does exactly that in one of its tabs.

Edit: err no, the plane AP  

Edited November 12, 2018 by sarbian

[maja]

On 11/11/2018 at 2:07 AM, JonathanPerregaux said:

I noticed that Ascent Guidance and Smart ASS seem to rotate my ships 90°. I have a rocket-boosted spaceplane and it ascends on edge with MechJeb instead of a normal "flying" orientation. I have to "control from here" on the MechJeb part, which causes the navball to go sideways and show the ground/sky vertically (eek), but fixes the ascent orientation of my plane.

In the Ascent Guidance window are two fields, where you can enter degrees of rotation after a launch and at the start of a gravity turn. Enter into both of them 90 degrees and your craft will not turn.