[PART, 1.0.2] Anatid Robotics / MuMech - MechJeb - Autopilot - Historical thread

[Tallinu]

No. It will have the AR202 and a new pod, probably nothing else for now.

I'll post a separate download with all the old parts converted for 2.0 for compatibility reasons, though.

The other radial part, the "brain" in the rounded case, was always my favorite by far... Would you consider eventually shipping that along with the AR202 and this new pod (once more important issues have been dealt with, of course)?

[Athlonic]

...

Something else I forgot to mention. As I was performing a planetary transfer, mechjeb automatically staged!!!! I was not expecting this since there was no option to control this, and bad things could have happened if I circumstances were different. I suggest adding a check box to allow automatic staging to the maneuver planner window.

I was about to report this too.

If you have "auto staging" enabled in the "ascent autopilot" windows, MJ will auto stage when Swapping/undocking ship later.

If you uncheck "auto staging" after the launch, it is ok.

[SunJumper]

You know what I would love?

The ability to have a separate ascent path for every body.

[elkar]

Ship name: Duna Recon Lander

Planetary bodies landed: Duna

This one sir is not going to work. That recon module is bugged and MkV rover is wont be able to get inside, it will get stuck. Just test it out. Its a known bug to HOME author yet he hasnt fixed it. :/

[elkar]

Small notes on 2.0.7:

-- Docking autopilot has worked so far for me.

IT does not for me. Yes it seems to be better than in 2.0.6 but now I'm getting basically same "random turn off" like I did before.

Now, it says 0,12 m/s but in fact that is being shifintg with 0.00 value and it doesnt move forward at all. Just hovering there.

[Castun]

Another issue to report here.

I've noticed that if you are already in the middle of a transfer window (in my example, from Kerbin to Duna) and schedule a maneuver to transfer there, it schedules the maneuver for right then and there, regardless of your location in orbit and angle to Kerbin prograde. This means the planned maneuver would end up deorbiting your craft or send you off in the wrong direction if you followed it.

[dimovski]

I doubt that is the case for Duna, but usually you can change the location of the burn by moving to the node editor, and placing it at apoapsis or periapsis...Now,I hope,the last post on page 100 wont be overlooked, I really want this to work properly..

[rosenkranz]

Wow. I really like the new smoked glass gui (at least that is what it looks like to me). I note you made the font just a smidge bigger (thank you thank you thank you thank you). I'm happy to report that everything i've tested so far in 2.0.7 is working great. But I do have three observations.

First, i have noticed it started chasing the node a little bit again. It seems to try to get the dV down to .1 but the node wanders a lot that low on 50+ton ships (not sure about lighter ones). One wonders if a variable (say in the attitude window) for a deadband on that, might help a lot. Honestly if it got with .3m/s for the maneuver, i'm happy.

Second, on the rendezvous module, it wants to change planes first. It does this even if the relative inclination is .11 deg. Which usually wastes an orbit to fix and since it's such a low dV maneuver, there is a lot of node chasing going on there. Perhaps there should be a larger tolerance for this. I get around it by having the planner do the holman transfer first. Once the burn is complete for that, engaging the rendezvous module correctly figures it is already on intercept and goes from there.

I'm not sure what a good tolerance should be. Perhaps it should scale with the distance involved. If you and the target are relatively close (say in LKO) a relative inclination of even a full degree probably wouldn't make a lot of difference to the intercept. Of course without doing the math, I wouldn't know if 5 deg would make a difference really. (i'll have to test this manually and get back to you)

Third, on the fine tune burn on rendezvous, it seems to aim for 100m from target. Due to variance and node chasing this has put me on collision course more times that is statistically agreeable. 100m seems to work great for smaller ships, but for stations and larger things 100m will often end badly. Any way to get a variable to modify this? I've been getting around it by diabling the autopilot prior to the final burn and doing the burn early so as not to hit the station.

[The_Duck]

If you are having problems with the landing AP, check this Github issue which I think correctly identifies the problem and a workaround; we will work on fixing the issue.

Also a little request, can you please restore the decimal coordinate system MJ 1.9.8 had please? It makes using ISA maps and Kethan Maps for landing a hell of alot easier.

All right, I'll work on this. We switched to a uniform system of degrees-minutes-seconds for MJ 2 just to simplify the code, but I guess as you point out other things use decimal so we should have that option.

the new window editor (which is a great addition) only allows me to remove a few of the info windows, while i would in fact prefer keeping the info windows, while removing some of the others from the mechjeb in-flight tab.

If you want to remove some windows that aren't custom info windows, you can do it by blacklisting them in the MechJeb part's part.cfg. I just wrote up some information on this for the manual, check it out: http://wiki.mechjeb.com/index.php?title=Manual/Blacklisting_modules

It was in the VAB with custom windows showing Delta V, Acceleration, Part count and the like

Thanks. If I had to guess I'd imagine something was going wrong with the separate thread that is used to calculate dV stats, but I'm not sure what it might be. We'll keep an eye out for issues.

despite the return from moon, or i use it wrongly. I just pic this option on the maneuver planing when i was in moon orbit to return to Kerbin, but it make my pe go directly to collision in Mun.

Thanks; can you make this happen reliably, and if so can you say when it happens, so I can try to reproduce it?

I have just decoupled my Eve transfer stage from my probe + lander payload, and I wanted to see some reentry flames, so I switched to it...when it crashed into the surface it still had a velocity of 65m/s, orbital velocity 80-something-ish, and I couldnt end flight or change vessels...

Sorry, I can't quite tell what happened from your description, and what should have happened. Were you using the landing AP and it didn't slow down enough, or something?

If you have "auto staging" enabled in the "ascent autopilot" windows, MJ will auto stage when Swapping/undocking ship later.

Yes, autostaging is now a global setting. This is ultimately by design, but we haven't yet added the interface options to properly support this capability yet. We still need to add in some settings that let you specify whether you want autostaging always/only during autopilot functions/only during ascent/never.

You know what I would love?

The ability to have a separate ascent path for every body.

We plan to add this at some point.

I've noticed that if you are already in the middle of a transfer window (in my example, from Kerbin to Duna) and schedule a maneuver to transfer there, it schedules the maneuver for right then and there, regardless of your location in orbit and angle to Kerbin prograde.

OK, I think I know why this might happen and will look into it.

First, i have noticed it started chasing the node a little bit again. It seems to try to get the dV down to .1 but the node wanders a lot that low on 50+ton ships (not sure about lighter ones). One wonders if a variable (say in the attitude window) for a deadband on that, might help a lot. Honestly if it got with .3m/s for the maneuver, i'm happy.

Check out the "tolerance" option in the Maneuver Planner

Second, on the rendezvous module, it wants to change planes first. It does this even if the relative inclination is .11 deg. Which usually wastes an orbit to fix

I'm not convinced that this is a waste. A 0.11 degree error in a 100 km Kerbin orbit can translate into a final error of over a kilometer after the Hohmann transfer intercept (0.11 * pi / 180 * (700 km) = 1.35 km is the maximum separation between two 100 km orbits with a relative inclination of 0.11 degrees). Fixing that error first saves the time and fuel that would be needed to fix it after intercept.

Third, on the fine tune burn on rendezvous, it seems to aim for 100m from target. Due to variance and node chasing this has put me on collision course more times that is statistically agreeable. 100m seems to work great for smaller ships, but for stations and larger things 100m will often end badly. Any way to get a variable to modify this?

Yes, I plan to add a setting for this.

Edited April 21, 2013 by The_Duck

[daver4470]

I've been having a weird issue with the game that may be MechJeb related. I've got a gaming laptop with a dual-graphics setup. There's an Nvidia GeForce 670M as the main graphics option, and the Intel on-die HD Graphics that are part of the Ivy Bridge processor in the system as a secondary option. The system basically uses the Ivy Bridge graphics for 2D applications, and switches to the 670M for games/etc.

Obviously I run KSP on the 670M. However, I've been running into an issue where, as near as I can tell, something is actually stopping the 670M from being used as the graphics renderer. In practice, what happens is that KSP turns into a slideshow, and my GPU usage goes from a constant 75-80% to 0%. The common factor I've run into is that this seems to happen while the rendezvous autopilot in MJ2.0 is doing its thing.

I don't even know how to begin to troubleshoot this. The game does occasionally crash, due to texture memory issues, but in general there's no crash log to analyze. I believe you guys said that MJ2.0 "offloads" calculation tasks into new threads. As a wild-ass guess, could there be some weird interaction going on with the offloaded calc threads using, say, the CUDA processors on the 670M and somehow, as a result, disengaging the graphics? All I know is that this definitely started after I moved to MJ2.0.

Any advice would be greatly appreciated....

[r4m0n]

I've been having a weird issue with the game that may be MechJeb related. I've got a gaming laptop with a dual-graphics setup. There's an Nvidia GeForce 670M as the main graphics option, and the Intel on-die HD Graphics that are part of the Ivy Bridge processor in the system as a secondary option. The system basically uses the Ivy Bridge graphics for 2D applications, and switches to the 670M for games/etc.

Obviously I run KSP on the 670M. However, I've been running into an issue where, as near as I can tell, something is actually stopping the 670M from being used as the graphics renderer. In practice, what happens is that KSP turns into a slideshow, and my GPU usage goes from a constant 75-80% to 0%. The common factor I've run into is that this seems to happen while the rendezvous autopilot in MJ2.0 is doing its thing.

I don't even know how to begin to troubleshoot this. The game does occasionally crash, due to texture memory issues, but in general there's no crash log to analyze. I believe you guys said that MJ2.0 "offloads" calculation tasks into new threads. As a wild-ass guess, could there be some weird interaction going on with the offloaded calc threads using, say, the CUDA processors on the 670M and somehow, as a result, disengaging the graphics? All I know is that this definitely started after I moved to MJ2.0.

Any advice would be greatly appreciated....

Unity already uses multiple threads to run the game, so I don't see one extra being the problem there. The additional CPU load may be triggering something, though. I'd look at some way to mark KSP to always run on the good GPU.

I don't have any experience with this situation, but you can try this.

[Nuprin Feelgood]

Absolutely loving MechJeb 2. thanks for all the hard work.

I have a request... Is it possible to have a resource counter that can be added into a custom window?

I have a standard window that I use now in the VAB to show the things I need to know, it would be great to have a total of fuel/oxidizer/monop amounts available in that window. So that I don't have to add it up in my head based upon what tanks I have placed. This would be equally useful for those using realism mods with Oxygen, food and whatnot. (I am not brave enough for that level of realism)

Just a thought. Keep up the great work.

[TinfoilChef]

the new transparent UI looks cool and all but like others I have a *VERY* hard time reading it. Could we please get an option to use the old 1.9.x style UI?

[Sabactus]

If you are having problems with the landing AP, check this Github issue which I think correctly identifies the problem and a workaround; we will work on fixing the issue.

All right, I'll work on this. We switched to a uniform system of degrees-minutes-seconds for MJ 2 just to simplify the code, but I guess as you point out other things use decimal so we should have that option.

If you want to remove some windows that aren't custom info windows, you can do it by blacklisting them in the MechJeb part's part.cfg. I just wrote up some information on this for the manual, check it out: http://wiki.mechjeb.com/index.php?title=Manual/Blacklisting_modules

Thanks. If I had to guess I'd imagine something was going wrong with the separate thread that is used to calculate dV stats, but I'm not sure what it might be. We'll keep an eye out for issues.

Thanks; can you make this happen reliably, and if so can you say when it happens, so I can try to reproduce it?

Sorry, I can't quite tell what happened from your description, and what should have happened. Were you using the landing AP and it didn't slow down enough, or something?

Yes, autostaging is now a global setting. This is ultimately by design, but we haven't yet added the interface options to properly support this capability yet. We still need to add in some settings that let you specify whether you want autostaging always/only during autopilot functions/only during ascent/never.

We plan to add this at some point.

OK, I think I know why this might happen and will look into it.

Check out the "tolerance" option in the Maneuver Planner

I'm not convinced that this is a waste. A 0.11 degree error in a 100 km Kerbin orbit can translate into a final error of over a kilometer after the Hohmann transfer intercept (0.11 * pi / 180 * (700 km) = 1.35 km is the maximum separation between two 100 km orbits with a relative inclination of 0.11 degrees). Fixing that error first saves the time and fuel that would be needed to fix it after intercept.

Yes, I plan to add a setting for this.

Are there plans, or even the ability in the game, to allow mechjeb to operate a ship with a horizontal configuration. Just wondering of this is possible.

[dimovski]

@The_Duck : the debris I left to fall into EVE (wanted to see teh pretteh flames ) crashed onto the ground, but was "marked" as like it still exists, so I couldnt leave to VAB, nor switch vessels (still in atmosphere)...So my whole voyage was for nothing...also, do I really need to launch into 270 heading for inner transfers?

[Scautura]

I've got weird happenings with MJ2: every so often, the translucent windows become totally transparent (no background whatsoever, virtually impossible to read or interact with, titles overwritten with the first line of the window). Not sure what's causing it (although I do have a fair number of mods installed, so am I hitting some sort of texture limit or other conflict? I don't have any of Romfarer's mods, specifically because of issues with them.) I've tried a few things to try solving it, including the latest snapshot from the dev server (I first saw it when I tried a dev snapshot though, so... Stumped at this point), removing and reinstalling, and deleting the config, but it still happens.

Any ideas?

Edited April 21, 2013 by Scautura

[heikkik]

Fresh install of KSP, a fresh new modpack. Finally upgrading to 2.0.7 on MechJeb. I think I need to watch Scott's tutorials again...

[Blaylock1988]

This one sir is not going to work. That recon module is bugged and MkV rover is wont be able to get inside, it will get stuck. Just test it out. Its a known bug to HOME author yet he hasnt fixed it. :/

It worked for me, I was able to drop this onto duna (despite the landing AP), drive the rover out, park it back inside and dock it. I then flew this thing back into orbit, picked up some fuel then landed in another place on Duna and use the rover again.

If you are having problems with the landing AP, check this Github issue which I think correctly identifies the problem and a workaround; we will work on fixing the issue.

I actually discovered the workaround that they mentioned, it did show the target, but I didn't notice any improvements in the AP so I didn't think to mention that workaround.

Edited April 21, 2013 by Blaylock1988

[Sovek]

There is a bug with the custom seperators, they show up fine on the ground, but once up in orbit they are not there. I'll try pinpointing where its going at.

[Climberfx]

Are there plans, or even the ability in the game, to allow mechjeb to operate a ship with a horizontal configuration. Just wondering of this is possible.

What i do in those cases is to have another control module or even a docking port in a vertical position. In this way you can put control from here and solve your problem! (i think)

[HGGundamReviews]

I don't know if it would be possible, but it would be sweet to have a landing option where you can target a landed ship or base and have a (Land Within X meters Of Target) Again don't know if its possible but it would be damned sweet.

[Climberfx]

I don't know if it would be possible, but it would be sweet to have a landing option where you can target a landed ship or base and have a (Land Within X meters Of Target) Again don't know if its possible but it would be damned sweet.

I would love to have that to, but for now, the pick point get closer enough for me. Just pic a point with a good zoom on your vehicles/base.

[Climberfx]

So Mr. Duck, here go the record of the Return from Mun error. I recommend you to see the role video (about 40 minutes), to see other minor things, like the keep rounding and rolling and almost never get the target from maneuver node (in some big ships this is more accentuated).

But if you want to see the Return from Mun error go directly to 23 minutes and beyond.

But to not be only about minor adjustments, i recommend too that you see the perfect landing coordinate by Mechjeb target to KSC. (i turn it off after it aims, because on my machine it get crazy stuff.)

Craft i use (KSPX parts and Mechjeb 2.0.7) - https://www.dropbox.com/s/6tpw6z9ogrdlqwz/Climber%20Next%20One.craft

Edited April 22, 2013 by Climberfx

[Simplicity]

Well I hate to say it, but I have gone back to using Mechjeb 2 for everything except docking.. - when I tried to dock my tug onto my station it went crazier the closer I got to the station, by the time I tried to abort (I was hoping it would stabilize) it was too late, and I smashed into the station..

[CtrlAltEL1TE]

Yeah the autopilot docking is bloody crazy, and ive noticed some wierd issues with the ascent autopilot in 2.0 which wernt in 1.9 (might just be me setting it up wrong). Ive found that it stops burning at 100% before making it into a stable orbit and only throttles back to 100% after it passes the apoapsis... it then re-enters the atmosphere and crashes because it doesnt have enough thrust to complete the burn AFTER the apoapsis has passed.