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

[cheech420now]

I'm on #236 and for some reason MJ has gotten pretty cavalier about overshooting burns badly, is my TWR crazy high for space? yeah, it's 2.49, but it doesn't matter if I limit acceleration to 5m/s etc, MJ still doesn't care about overshooting burns, it doesn't start lowing thrust until a split second before the burn is done, making it overshoot several m/s

Do you have smooth throttle turned on if so turn it off. Turning it off fixed this problem for me.

[K3-Chris]

Turned off, I'll see if that helps, if it does, that's pretty weird.

[sarbian]

Hmmm, anyone tried TweakableGimbal with latest MJ dev build? MJ keep rolling my rocket

http://forum.kerbalspaceprogram.com/threads/66128-0-23-5-TweakableGimbal-(V0-2-1-release-Jan-18-2014)

MJ does not know those gimbal (and the one used by KSO) so it lacks some info on how much torque they can deliver and il mess things up.

I'll think about how to fix it.

[mwlue]

MJ does not know those gimbal (and the one used by KSO) so it lacks some info on how much torque they can deliver and il mess things up.

I'll think about how to fix it.

Noted with thx, take ur time.

[Kerbonautical]

Ok, realised I didn't put in the version number when asking last time so my bad. I'm using Mechjeb 2 for version 23.5 via the last successful artefact on the website you host it on as of yesterday, very recent version.

I'm having a basic issue with compatibility within Career. I had edited the .cfg of the AR202 so that I would have access to all MJ's abilities off the bat. I did this by changing the tech node they should all be unlocked with to 'start' and the EntryCost to '0'. I didn't mess with anything else while in there but I cannot get MJ to offer me more than the first set that unlock. As a test I decided to add the subcategory 'control' one of the sets of abilities that would typically be unlocked later in the game and this added a second AR202 to my parts, so it is technically unlocking, but it's not stacking the abilities on top of the single AR202.

Any ideas what's going on here? Sorry to bother you with these problems by the way, I'm sure you get enough on your plate in a day. I've tried everything I can to solve the problem in the past two weeks including entirely fresh installs of the game and mod but just cannot get any succes. I should clarify I only have a low level understanding of what some of the stuff in the .cfg even means, but if I don't understand it I don't touch it. The only things altered are mentioned above. The mod also works perfectly in Sandbox, it seems to just have some issue with the tech tree.

[sarbian]

Did you do that after starting the career mode ? Thing can get a bit messy when you change the position of a node and you load a save with other position.

I could investigate the problem if you put your save and modified AR202 somewhere like dropbox.

But you want the AR202 to have all the features unlocked for start ? Then I'd do a ModuleManager patch like that :

@PART[mumech_MJ2_AR202]
{
    @MODULE[MechJebCore]
    {
        name = MechJebCore
        !MechJebLocalSettings {}
    }
}

It will remove the MJ tech requirement of the AR202 and you'll have all features unlocked ( if I did not mess up the patch )

[Pondafarr]

Feature creep request: When using the Ascent Module for "launch to rendezvous", could the "desired orbit" and "inclination" text input boxes be auto-updated to match the target info? The current mechanics appear to have the craft ascend to just the altitude listed, then disables the ascent module. (just confirmed that behavior, if the altitude box has a lower orbit than target, set altitude overides rendezvous input) Fixing this should allow "direct to rendezvous" type of launches. (unless I am just ignorant on how to do that with mechjeb).

Also, a hash mark on the "edit ascent path" indicating current position along ascent curve (or relative altitude on curve) during ascent would be a great indicator if changing the curve during ascent.

As always, LOVE MechJeb!

Edited April 25, 2014 by Pondafarr

[Green Skull]

I'm on #236 and for some reason MJ has gotten pretty cavalier about overshooting burns badly, is my TWR crazy high for space? yeah, it's 2.49, but it doesn't matter if I limit acceleration to 5m/s etc, MJ still doesn't care about overshooting burns, it doesn't start lowing thrust until a split second before the burn is done, making it overshoot several m/s

The PID for attitude adjustment is also pretty weird, it's going full tilt towards the direction you set until it gets there, then it tries to stop, net result is a lot of oscillation back and forth, doesn't matter what I do in the 'tude settings 0.3, 0.8, autotune, stock SAS etc my rockets wobble around horribly, in small and simple designs I can ride it out but in larger and more fragile rockets I can't rely on MJ anymore, I need to use stock SAS to stop it wobbling around.

I had the same problem. For me MJ couldn't handle a high gimbal engine. In my case turning a 5 to a 2 in the engines config on the gimbal range sorted this and made the rocket flyable.

[Kerbonautical]

Did you do that after starting the career mode ? Thing can get a bit messy when you change the position of a node and you load a save with other position.

I could investigate the problem if you put your save and modified AR202 somewhere like dropbox.

But you want the AR202 to have all the features unlocked for start ? Then I'd do a ModuleManager patch like that :

@PART[mumech_MJ2_AR202]
{
    @MODULE[MechJebCore]
    {
        name = MechJebCore
        !MechJebLocalSettings {}
    }
}

It will remove the MJ tech requirement of the AR202 and you'll have all features unlocked ( if I did not mess up the patch )

Hmmm, I may have actually swapped MJ for a slightly newer build after starting the career, which may have had an effect. I could have also tweaked it after starting the Career too. I'm gonna go back and double check the .cfg and start a new career to see if that corrects things perhaps. If not I'll have a shot with the ModuleManager patch. Just to check is there anywhere specific to drop that code within the module manager .cfg? Sorry, like I say I kind of only half get what I'm doing in these things.

[sarbian]

I had the same problem. For me MJ couldn't handle a high gimbal engine. In my case turning a 5 to a 2 in the engines config on the gimbal range sorted this and made the rocket flyable.

The code to know how much torque a gimbal can generate might be bad then. When I wrote my new GimbalAutoTrim module I found out that I could improve that, I ll work on it in the coming weeks.

Kerbonautical : you just create a .cfg file anywhere in gamedata and put the patch in it. (and put the module manager dll in gamedata if you don't have it already ).

To make things less messy I keep all my personal patch in a subfolder.

[Green Skull]

I also noticed that even with the gimbal disabled or locked on high gimbal engines it did the same thing - if that helps.

[Kerbonautical]

Oh wow, first time I've made a .cfg, though of course wouldn't have had a clue what to do without the code. Thanks man! It worked a treat. The toolbar functionality is really awesome too by the way

[Rickenbacker]

I did a search for this in the thread but found nothing. My problem: Whenever I use any parts from the ARM patch, MJ stops displaying DeltaV. Not just for the ARM engines, but for ALL engines on that particular ship. If I then build a ship without those parts, MJ shows DeltaV just fine again. This is really odd.

[Starwaster]

I did a search for this in the thread but found nothing. My problem: Whenever I use any parts from the ARM patch, MJ stops displaying DeltaV. Not just for the ARM engines, but for ALL engines on that particular ship. If I then build a ship without those parts, MJ shows DeltaV just fine again. This is really odd.

Use the latest dev build. First page, first post. Click the link for dev builds and download MechJeb2.dll and copy it over the existing MechJeb.dll. (or back the original up first if you want)

[Spanier]

My MechJeb messes up every landing attempt on the Mun. It works fine until the half of the breaking burn, then it flips from retrograde to upwards and misses the target. I testet for a 10x10, 10x6, 20x7 and 7x7 [km, lower value above the target] orbit.

[tmikesecrist3]

I have been having problems with that to, I thought it might have been the new lem in the FASA mod.... but I know I use to be able to use it for that any thoughts people?

[LameLefty]

My MechJeb messes up every landing attempt on the Mun. It works fine until the half of the breaking burn, then it flips from retrograde to upwards and misses the target. I testet for a 10x10, 10x6, 20x7 and 7x7 [km, lower value above the target] orbit.

I actually had that problem last night trying to land on Gilly from a 17km orbit. My ship kept wobbling around like MJ was drunk. I finally just landed manually even though it took like 10 minutes to free-fall low enough to pick a spot.

[Starwaster]

My MechJeb messes up every landing attempt on the Mun. It works fine until the half of the breaking burn, then it flips from retrograde to upwards and misses the target. I testet for a 10x10, 10x6, 20x7 and 7x7 [km, lower value above the target] orbit.

I have been having problems with that to, I thought it might have been the new lem in the FASA mod.... but I know I use to be able to use it for that any thoughts people?

I actually had that problem last night trying to land on Gilly from a 17km orbit. My ship kept wobbling around like MJ was drunk. I finally just landed manually even though it took like 10 minutes to free-fall low enough to pick a spot.

Try from a higher orbit. Your descent angle at the time of your suicide burn will be closer to vertical and MJ2 will have less trouble with it.

FYI, the real moon missions started their descent from ~100km altitude. Because of the scale of the Mun (or Gilly) you won't have to do anything nearly that severe.

Oh... and Gilly.... sheesh, actually good luck on that one. MJ2 is going to have an absolutely horrendous time. I'd put throttle limits in place. I forget what worked for me, find Gilly's gravity at the surface and limit MJ2 to maybe twice that. (when the Translatron was working properly, it made Gilly a lot easier for me cause if I picked a bad spot I could have it hover while I moved the ship)

[mario.masters]

Works for me. Try scheduling a fine tuning after your initial transfer burn.

I do that as required. See below what I'm experiencing.

Well, it works in tests on my end. If you see this again can you post again with the periapsis, apoapsis, and inclination of your initial orbit around Kerbin?

Info below with pics (if it helps).

I always perform a fine tuning if needed, however I never had to burn more fuel on the actual fine tuning than the initial orbit transfer maneouver. I cheated my way into orbit hoping to reproduce the issue and I managed to do it. Pe and Ap = 100km approx, inclination = 0. Details from hyperedit window below.

This is what Mechjeb does when I ask it to perform a Hohmann transfer.

This is the projection for the fine tuning maneuver, and the node projection.

And finally this is the same situation however only using Mechjeb v233.

[The_Duck]

I do that as required. See below what I'm experiencing.

Thanks. I tried entering the same orbital parameters with hyperedit, but can't reproduce the problem. Can you make sure that you're using #236 and not #234 or #235? #236 had a fix for something that could cause this problem. Finally, if you encounter it again you could upload your KSP_Data/output_log.txt and link it here; it may have some clues.

[technogeeky]

This might be a bad question, but are you guys using profiling on MechJeb (the plugin or the parts)?

I ask because I finally got profiling working. (using the legacy statistical profiler, on Linux). And my testing scanner craft for SCANsat happens to use the MechJeb probe. In terms of percentage of total time, and after discarding the first few largest percentage items (because they are native things like object.runtime_invoke_void_this, etc ... the first few high percentage items wereMuMech.MechJebPod.Update (mostly MuMech.MechJebPod.AdvanceAnimationTo with ten thousand calls) with 13% of all calls, then MuMech.MechJebCore.OnGUI(), then DrawGUI(), with 12.22% of all calls.

Another way to look at this data set is to example the calls to object_runtime_invoke_void_this(), where MechJeb has a factor of 2 to 10 more calls than any other caller.

In other words, I wonder without knowing anything about MechJeb code if some of these functions are running more often than is ideal. Isn't there some vague technique where you want to only make/allow calls when something has changed (and merits a redraw or something)?

Pardon me, as I'm really speaking out of ignorance here. This is my first set of 'clean' profiling results (clean as in, does not contain all of the loading and is a nice 30 second sample). I was just surprised to see so many calls to MechJeb functions compared to... everything else. In some cases, it appears to be an order of magnitude difference.

Obviously, if you want the profiling results I can try to put them up somewhere. The capture file is ~ 7 MB (even for only 30 seconds).

I really need to strip out all of my mods for my dev environment version of KSP.

edit: It's really hard to get good output that I can copy/paste, since emveepee doesn't allow it. There is a tool to dump some of the output into a text file, which I have done, but it does not have the same ordering. So I will just paste some random profile results:

 0.00% (4) MuMech.MechJebPod.AdvanceAnimationTo (UnityEngine.Animation,string,single,single,single)
    10746 calls from MuMech.MechJebPod.Update ()
    10724 calls to UnityEngine.Animation.Sample ()
    16 calls to UnityEngine.Animation.get_Item (string)
    1 calls to UnityEngine.Mathf.MoveTowards (single,single,single)
    1 calls to UnityEngine.AnimationState.set_weight (single)

 0.00% (0) MuMech.MechJebPod.Update ()
    10891 calls from object.runtime_invoke_void__this__ (object,intptr,intptr,intptr)
    10746 calls to MuMech.MechJebPod.AdvanceAnimationTo (UnityEngine.Animation,string,single,single,single)

 0.00% (0) UnityEngine.Animation.Sample ()
    10724 calls from MuMech.MechJebPod.AdvanceAnimationTo (UnityEngine.Animation,string,single,single,single)
    89 calls from TimeOfDayAnimation.Update ()
    4 calls from ModuleLandingLeg.AnimationInitialState ()
    10816 calls to UnityEngine.Animation.INTERNAL_CALL_Sample (UnityEngine.Animation)
    1 calls to [/media/ssd/steam/SteamApps/common/Kerbal Space Program/KSP.x86](UNKNOWN)

 0.02% (16) MuMech.MechJebModuleMenu.SetupToolBarButtons ()
    9684 calls from MuMech.MechJebModuleMenu.DrawGUI (bool)
    1 calls from MuMech.MechJebCore.OnGUI ()
    7523 calls to MuMech.MechJebModuleMenu.SetupToolbarButton (MuMech.DisplayModule,bool)
    1072 calls to MuMech.DisplayModule.isActive ()
    880 calls to System.Linq.QuickSort`1/<Sort>c__Iterator21.MoveNext ()
    130 calls to MuMech.MechJebCore.GetComputerModules ()
    41 calls to MuMech.MechJebModuleMenu.SetupMainToolbarButton ()
    4 calls to System.Linq.OrderedEnumerable`1.GetEnumerator ()
    3 calls to MuMech.DisplayModule.get_showInCurrentScene ()
    3 calls to [UNKNOWN MEMORY REGION]
    2 calls to UnityEngine.Object.op_Equality (UnityEngine.Object,UnityEngine.Object)
    2 calls to GameDatabase.GetTexture (string,bool)
    1 calls to MuMech.MechJebModuleMenu.CleanName (string)
    1 calls to MuMech.MechJebModuleThrustWindow.isActive ()
    1 calls to MuMech.UserPool.RecursiveUser (object)
    1 calls to MuMech.MechJebModuleSettings.GetName ()
    1 calls to System.Linq.QuickSort`1/<Sort>c__Iterator21.System.Collections.Generic.IEnumerator<TElement>.get_Current ()
    1 calls to System.Linq.Enumerable.Cast (System.Collections.IEnumerable)
    1 calls to object.stelemref (object,intptr,object)
    1 calls to MuMech.MechJebModuleRendezvousAutopilotWindow.GetName ()

 0.01% (11) MuMech.MechJebCore.OnGUI ()
    10163 calls from object.runtime_invoke_void__this__ (object,intptr,intptr,intptr)
    9738 calls to MuMech.MechJebModuleMenu.DrawGUI (bool)
    214 calls to MuMech.MechJebCore.GetComputerModule ()
    169 calls to MuMech.MechJebCore.GetComputerModules ()
    8 calls to MuMech.VesselExtensions.GetMasterMechJeb (Vessel)
    8 calls to MuMech.GuiUtils.CheckSkin ()
    4 calls to System.Collections.Generic.List`1/Enumerator.MoveNext ()
    3 calls to UnityEngine.Matrix4x4.get_identity ()
    2 calls to [UNKNOWN MEMORY REGION]
    1 calls to MuMech.MechJebModuleMenu.SetupToolBarButtons ()
    1 calls to UnityEngine.Vector3.get_zero ()
    1 calls to UnityEngine.Screen.get_width ()
    1 calls to UnityEngine.GUI.set_depth (int)
    1 calls to UnityEngine.Matrix4x4.TRS (UnityEngine.Vector3,UnityEngine.Quaternion,UnityEngine.Vector3)
    1 calls to UnityEngine.GUI.get_skin ()

0.01% (9) TimeControl.FlightScene.Update ()
    479 calls from object.runtime_invoke_void__this__ (object,intptr,intptr,intptr)
    247 calls to int.ToString ()
    122 calls to KSP.IO.PluginConfiguration.SetValue (string,object)
    88 calls to string.Concat (string,string,string,string)
    6 calls to string.Concat (string,string)
    2 calls to object.__icall_wrapper_mono_object_new_ptrfree_box (intptr)
    1 calls to string.InternalAllocateStr (int)
    1 calls to string.CharCopy (char*,char*,int)
    1 calls to UnityEngine.Mathf.Pow (single,single)
    1 calls to KSP.IO.PluginConfigNode.SetValue (string,object)
    1 calls to System.NumberFormatter.NumberToString (int,System.IFormatProvider)

0.01% (7) MuMech.MechJebCore.Update ()
    601 calls from object.runtime_invoke_void__this__ (object,intptr,intptr,intptr)
    472 calls to MuMech.MechJebCore.OnSave (ConfigNode)
    111 calls to MuMech.MechJebModuleThrustController.OnUpdate ()
    3 calls to UnityEngine.Object.FindObjectOfType (System.Type)
    3 calls to MuMech.VesselExtensions.GetMasterMechJeb (Vessel)
    2 calls to UnityEngine.Object.op_Inequality (UnityEngine.Object,UnityEngine.Object)
    2 calls to UnityEngine.Object.op_Equality (UnityEngine.Object,UnityEngine.Object)
    1 calls to UnityEngine.Input.GetKeyDown (UnityEngine.KeyCode)

Edited April 26, 2014 by technogeeky

[technogeeky]

I hope the above is meaningful enough to get the idea of the question I'm asking. I included the TimeControl.FlightScene.Update() example to show an example that most other functions from other mods (or indeed from KSP itself) have far fewer calls and far fewer runtime-invokes.

edit: I've had enough KSP mod development struggle for today. Time to fire up the 64-bit version and play!

[OrbitalDebris]

The Mechjeb pod has this weird creepy eye that moves around a lot, so it could be that. What happens if you try the same tests with the AR202? (the boxy mechjeb thing with the big light and antenna)

[OrbitalDebris]

I got tired of choosing between having the latest mechjeb goodness and the MJ integration in the ALCOR capsule, so I recompiled it and don't have to choose any more

If anybody else wants to join in the fun (no guarantees, it's compiled with Visual Studio 2013 and not MonoDevelop) you're welcome to try it - this makes RPM 0.16 compatible with MJ dev builds (you need to get the zip file for the MJ build you have). Just extract the GameData directory of the zip file on top of your KSP GameData directory and overwrite the two DLLs when asked.

One thing: I did have to make one code change. In build 231 MechJebModuleTargetController.Orbit got renamed to TargetOrbit, so I had to change a few places in MechJebRpmButtons.cs to get it to build - the updated file is in the 'src' directory of the zip file. Unfortunately this did not fix the build-to-build incompatibility between MJ and RPM - replacing MJ with build 235 resulted in the "Autopilot software not installed" message.

Since rebuilding is a pretty trivial exercise, I'll see if I can keep posting updated builds of RPM compatible with MJ dev builds as they become available. I don't promise that I'll be able to keep up with Sarbian, but I'll try to post at least one a day when new dev builds appear.

IMPORTANT: It's been brought to my attention that this is incompatible with technogeeky's SCANSat v6rc build with RPM, probably for the same reason that dev builds of MechJeb are incompatible with RPM. So please be aware that you can't have both this and SCANSat v6rc installed at the same time (in other words, to use SCANSat v6rc, RPM and MechJeb at the same time you need to use the release 2.2.1 version of MechJeb).

Current version:

As of Mechjeb build 254, Sarbian has fixed the underlying problem (an obscure bit of .net versioning, see here if you're interested) and these builds are no longer needed. You can use any dev build after 253 with RPM 0.16 without needing one of my recompiles. It also means there should no longer be any problems with SCANSat either. Goodness all around!

Older versions:

For build 2.2.1.253

For build 2.2.1.252

For build 2.2.1.251

For build 2.2.1.250

For build 2.2.1.249

For build 2.2.1.248

For build 2.2.1.247

For build 2.2.1.246

For build 2.2.1.245

For build 2.2.1.244

For build 2.2.1.243

For build 2.2.1.242

For build 2.2.1.240

For build 2.2.1.239

For build 2.2.1.238

For build 2.2.1.237

For build 2.2.1.236

Edited May 14, 2014 by OrbitalDebris

[Starwaster]

I got tired of choosing between having the latest mechjeb goodness and the MJ integration in the ALCOR capsule, so I recompiled it and don't have to choose any more

If anybody else wants to join in the fun (no guarantees, it's compiled with Visual Studio 2013 and not MonoDevelop) you're welcome to try it - this makes RPM 0.16 compatible with MJ dev build 236. Just extract the GameData directory of this zip file and overwrite the two DLLs when asked: https://onedrive.live.com/redir?resid=962FD212EEE06DAC!12252&authkey=!AAVYXGEqOA8zTzQ&ithint=file%2c.zip

One thing: I did have to make one code change. In build 231 MechJebModuleTargetController.Orbit got renamed to TargetOrbit, so I had to change a few places in MechJebRpmButtons.cs to get it to build - the updated file is in the 'src' directory of the zip file. Unfortunately this did not fix the build-to-build incompatibility between MJ and RPM - replacing MJ with build 235 resulted in the "Autopilot software not installed" message.

Since rebuilding is a pretty trivial exercise, I'll see if I can keep posting updated builds of RPM compatible with MJ dev builds as they become available. I don't promise that I'll be able to keep up with Sarbian, but I'll try to post at least one a day when new dev builds appear.

That's great!

You know what you could do though? Get a github account, fork MJ2, apply your fix and then do a pull request. Then you don't have to worry about 'Keeping Up With the Sarbians' (sounds like a reality TV show, doesn't it....)