sarbian

[1.7.x] Anatid Robotics / MuMech - MechJeb - Autopilot - [2.8.4] [14 June 2019]

Recommended Posts

1 hour ago, Kitspace said:

Powered Explicit Guidance

That one does only work with the builds from lamont-granquist - who actually commited a lot to the main mechjeb repo within the  last 12 hours or so.
This means there will be a total overhaul of MechJeb coming soon I would say... correct me if I'm wrong :sticktongue:

But first comes first:
https://github.com/lamont-granquist/MechJeb2/releases

The "normal" releases habe a non-functional PEG, but here you can find latest devs:
https://ksp.sarbian.com/jenkins/job/MechJeb2-Dev/

Share this post


Link to post
Share on other sites
3 minutes ago, Gordon Dry said:

That one does only work with the builds from lamont-granquist - who actually commited a lot to the main mechjeb repo within the  last 12 hours or so.
This means there will be a total overhaul of MechJeb coming soon I would say... correct me if I'm wrong :sticktongue:

But first comes first:
https://github.com/lamont-granquist/MechJeb2/releases

The "normal" releases habe a non-functional PEG, but here you can find latest devs:
https://ksp.sarbian.com/jenkins/job/MechJeb2-Dev/

Wait, what do you mean, normal releases have a non functional PEG?

This week I had at least four PEG launches. I mean successful ones. And I am using a normal release.

My problem is that it bugs out sometimes, but it certainly does not only function, but steer much better than me.

Share this post


Link to post
Share on other sites

@Kitspace well, with "normal" MJ relases incl. devs I never even managed it to have the PEG enabled ... perhaps my install is always-borked. (But wait, I'm one of the best beta testers, I use mods).

With the lamont-granquist versions I managed it really easily -  with a well balanced craft (which is historically same-alike as real) I even managed it to recreate historic launches like Sputnik-2 with same parameters (but the date and time).

And last but not least - I have read comments here and there that just said "the PEG in releases is non-functional" - when you say it works then you're lucky. Perhaps you don't use many mods.

Share this post


Link to post
Share on other sites
24 minutes ago, Kitspace said:

Wait, what do you mean, normal releases have a non functional PEG?

This week I had at least four PEG launches. I mean successful ones. And I am using a normal release.

My problem is that it bugs out sometimes, but it certainly does not only function, but steer much better than me.

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.

2 hours ago, Kitspace said:

Sometimes, seemingly randomly, the stage analysis window throws NaN, instead of some of the numbers for the stages. When that happens, A, B and pitch become NaN. The time to go reading is sometimes an erratically changing negative number or just another NaN as well.

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.

Share this post


Link to post
Share on other sites

So, at the moment, does Mechjeb use the Atlas Centaur guidance, or the Space Shuttle guidance? Are both of them referred to as PEG?

While I see how the Shuttle version should be more accurate, how is that related to how often it bugs out in game? As I said before, it does not seem to be related, to how complicated the task is, or whether it is possible at all.

Sometimes, it works perfectly and sometimes refuses to produce the numbers, for the exact same vessel. I somehow doubt that happened a lot in real life, even in the early days :)

Also, the early two axis guidance  code, may be a good thing to leave in on purpose, at least as an option, for people, who in one way or another, play career mode, or roleplay historical progression. After all, real Sputnik missions were flown with guidance, much closer to the early Atlas, than to the Shuttle :)

Anyway, why would it refuse to work like that? Maybe, there is a particular action, or pattern of actions, that make it happen somehow? I do not remember having this problem with the earlier versions. Would it help if I post the logs?

Edited by Kitspace

Share this post


Link to post
Share on other sites
4 hours ago, Kitspace said:

So, at the moment, does Mechjeb use the Atlas Centaur guidance, or the Space Shuttle guidance? Are both of them referred to as PEG?

While I see how the Shuttle version should be more accurate, how is that related to how often it bugs out in game? As I said before, it does not seem to be related, to how complicated the task is, or whether it is possible at all.

Sometimes, it works perfectly and sometimes refuses to produce the numbers, for the exact same vessel. I somehow doubt that happened a lot in real life, even in the early days :)

Also, the early two axis guidance  code, may be a good thing to leave in on purpose, at least as an option, for people, who in one way or another, play career mode, or roleplay historical progression. After all, real Sputnik missions were flown with guidance, much closer to the early Atlas, than to the Shuttle :)

Anyway, why would it refuse to work like that? Maybe, there is a particular action, or pattern of actions, that make it happen somehow? I do not remember having this problem with the earlier versions. Would it help if I post the logs?

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

 

Share this post


Link to post
Share on other sites

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.

imiLbJD.png

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

Edited by Jim DiGriz

Share this post


Link to post
Share on other sites

Here is the old behavior of the hohmann transfer planner:

pC9Qwbl.png

That comes nowhere near close to minmus.

Now here's the new behavior:

9nvBfQx.png

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:

hcc2JUp.png

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)

Edited by Jim DiGriz

Share this post


Link to post
Share on other sites

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

Edited by Jim DiGriz

Share this post


Link to post
Share on other sites

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:

ooAa1Yu.png

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

Edited by Jim DiGriz

Share this post


Link to post
Share on other sites

Most excellent work, Jim. My grasp of mathematics is at the high school algebra level, (hey, I was a Poli Sci major, give me a break. At least I didn't have to take remedial math), so I won't pretend to understand all that, but I get that you tweaked it to make it better, and that's mighty fine.

Sincere thanks for all your hard work. Now I'm going to go DL 807 and put this baby to the practical test :)

***EDIT***

Poking around in the new MJ version 807 after install, looked in the /Icons subfolder and saw that "Warp_Helper.png" appears to be a cameo of Jean Luc Picard. Can't stop laughing.

Edited by El Sancho
La pesada herencia del Kirchnerismo

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Hi Guys,

using Ksp 1.3.1 RP-1 install with MJ 2.7.0 and MechjebForEverything.

i loaded my careersave today and till today i had all the mechjeb features unlock and available inflight. Now there are only the data windows and settings available. The menu shows "all features can be unlocked with researching the right nodes in R&D or upgrading comm station" (or something like that). I added a lot of MM config to make parts compatible for RO and RP-0, bu nothing to do with Mechjeb.

What can i do?

Changing enabledFlight to true for the modules i need in the mechjeb_settings_global?

Log

EDIT: I need to investigate further its only one rocket design that has this problem and the command modules have an mechjeb module. This is weird.

Edited by JohnMcLane

Share this post


Link to post
Share on other sites

Game updated to 1.5 and now mechjeb shows as incompatible. Tried launch a previously built craft and craft appeared on launch site like it was made out of rubber bouncing all over the place like jelly. Tried launching it and rubber craft bounced itself to death.

Share this post


Link to post
Share on other sites
3 minutes ago, MikeO89 said:

Game updated to 1.5 and now mechjeb shows as incompatible. Tried launch a previously built craft and craft appeared on launch site like it was made out of rubber bouncing all over the place like jelly. Tried launching it and rubber craft bounced itself to death.

That has nothing to do with MechJeb.

Share this post


Link to post
Share on other sites

MechJeb2-2.8.0.0.zip built for KSP 1.5 (but most likly compatible with 1.4.x)

 

The fix for dv and hidden part decoupler is still in the work (and I will feel better releasing it as a dev version first).
 

 

Edited by sarbian

Share this post


Link to post
Share on other sites

Holy smokes, since updating to 1.5, game is unplayable. On all my craft now, all the joints are like jelly when going out to the launch pad. Boosters launch almost separately from main craft. Tried launching one of them manually and it held together until I enable Mechjeb again, then I had compound joint failure. I have serious problems here. I think I got some mods not playing nice together or something. I don't even know where to start to try to fix this. I feel like a space duck out of water (or drowning, dunno which). Good thing I still have 1.4.3 and 1.3.1.  This one here, I can't play it until I can figure this stuff out.

Edited by MikeO89

Share this post


Link to post
Share on other sites
41 minutes ago, reschke said:

FYI previous build is working in 1.5. I haven't noticed any problems with it.

Can confirm. Will be upgrading to the latest version due to the new transfer mode, though.

Share this post


Link to post
Share on other sites
1 hour ago, sarbian said:

The fix for dv and hidden part decoupler is still in the work (and I will feel better releasing it as a dev version first).
 

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

22 minutes ago, MikeO89 said:

 I think I got some mods not playing nice together or something.

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

Share this post


Link to post
Share on other sites
1 hour ago, reschke said:

FYI previous build is working in 1.5. I haven't noticed any problems with it.

I have a fresh install for 1.5 and with only mod manager3.1 and mechjeb2. installed, I have tried versions 2.8 #17 and #18

 version 2.74 and 2.73, all say the same, the game comes up and I can play. no mechjeb icons appear on launchpad, here is the screencap when loaded and my gamedata folder.mechjeb2%20error.png

and I was fine with 1.4.5 using 2.74, interesting that you got it working..

I wanted a clean install. so this is where I am so far.

any ideas?

thanks

Jammer

oops forgot log file..-

http://www.teamdemonic.com/photo/KSP/1.5-18/KSP.mechjeb2.8-18 error.zip

Edited by Jammer-TD
add logfile

Share this post


Link to post
Share on other sites
19 minutes ago, Jammer-TD said:

 

any ideas?

 

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?

 

Share this post


Link to post
Share on other sites
23 minutes ago, Jim DiGriz said:

 

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?

 

well you have spoiled me (as per attaching to a rocket-that was a stock craft. who does that anymore.. lol).. as for a while now I have not needed the other items you mentioned<maybe?>. I was very much in need of embedded at the beginning <KSP1.2days> so I wouldn't forget and at some point near the 1.4 era, I no longer seemed to need to add that mod and yet all command mods had mechjeb right through to your V2.7.4.. so I went for it  after your post and copied all but squad and mechjeb2.8(#18) from my v1.4.5-old and despite the warning all works fine. no attachment's needed again?

Thanks for all you do, for us players.. I did check my directory and I have a full list with no other mechjeb folders but mechjeb2 and couldn't find the embedded universal info if it was still on this list I have nothing sub to a mod. but I cannot find the original source I used.

in case you wanted to review the list of mods I am using<http://www.teamdemonic.com/photo/KSP/1.5-18/dir145-1.5-mm3-7.txt>. I cannot see what is helping add MechJeb to all things. so I wanted to re-download the items you listed but failed with the link on the page

 Useful links and companions mods

leading to MechJebEmbedded Universal https://forum.kerbalspaceprogram.com/threads/98390 

 MechJebForAll https://forum.kerbalspaceprogram.com/threads/83362  didn't work, off of the this forum's 1st page.. fyi.

The page you requested does not exist

Error code: 1S160/2

 

I know you have a lot on your plate. and I am up, up and away

Again Thanks

Jammer

Share this post


Link to post
Share on other sites

Just because it said "incompatible" doesn't mean it will not work. Mine said the same thing and I didn't reinstall anything for KSP. I simply updated and then started a new career mode game and it all worked.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.