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

[Virtualgenius]

Romfarer has a proper docking cam http://kerbalspaceprogram.com/lazor-docking-cam/ its brilliant

[J_Davis]

Could we get an option to change TWR and deltaV calculations based on Isp depending on whether we've modded the game to have Isp changing fuel consumption rate or Isp changing the engine thrust? This is important for realistic engine builds.

[NathanKell]

Already in, at least if your thrust corrector is Modular Fuels. Click All Stats on dV panel to get SLT column, which shows sea level TWR.

dV calculations don't change, mind. It's not like thrust has any effect on dV.

[J_Davis]

Already in, at least if your thrust corrector is Modular Fuels. Click All Stats on dV panel to get SLT column, which shows sea level TWR.

dV calculations don't change, mind. It's not like thrust has any effect on dV.

Yeah, I realized that after I wrote the post. dV is right, just not the twr. Thanks for letting me know about that!

[sarbian]

Now, I've seen something you might want to see (or not... )...

I have seen other errors related to this one. The game (or some MJ code, but at this point I doubt it) seem to return null for mainbody sometimes. I could add a check for null and hide the error but then some module would just stop working without error ...

I need to find out why I get those null mainbody.

As for the docking cam I prefer the Docking Port Alignment Indicator mod to the other cam mods, even if you lose the view.

[J_Davis]

Is this related to the NaN bug from engines having tweakable electric charges?

[sarbian]

I don't think so. Can you link the mod with an engine that does that ?

[BARCLONE]

I have seen other errors related to this one. The game (or some MJ code, but at this point I doubt it) seem to return null for mainbody sometimes. I could add a check for null and hide the error but then some module would just stop working without error ...

I need to find out why I get those null mainbody.

As for the docking cam I prefer the Docking Port Alignment Indicator mod to the other cam mods, even if you lose the view.

I was using the HullCam mostly for the pretty pictures, not for science, or anything serious...

What I was hoping for was to have the spent carrier stage turn around and just "happen" to catch sight of the lander. It was trying to do that, when the focus shifted to the lander and those exception messages started loading up.

Until I dropped the mods out, I had been using Romfarer's Lazor modules (including his docking cam).

Someone mentioned a "NaN" bug, and my log happened to have at least three entries:

[LOG 20:49:09.597] dT is NaN! tA: 2.18924802541733, E: 0, M: 0, T: NaN

...

[LOG 20:49:19.604] dT is NaN! tA: 2.31516206264496, E: 0, M: 0, T: NaN

...

[LOG 20:52:02.610] dT is NaN! tA: 2.27500748634338, E: 0, M: 0, T: NaN

I have no idea what these refer to, whether it's an engine parameter or something else.

Edited December 29, 2013 by BARCLONE

[Tomo2k]

Is anyone else finding that MJ2.1.1 Ascent Guidance is giving the inverse inclination?

Both Launch To Rendezvous and Match Inclination ascent guidance is giving me the wrong inclination, with it mirrored about the equator of the body - ie if the target craft is ascending 15 deg from the equator, ascent guidance gives me an orbit descending at 15 deg

So far this has happened to all my launches with a non-zero inclination.

MechJeb 2.1.1, KSP 0.23, no other mods.

[sarbian]

I pushed a new dev version with 3 changes :

- Auto tuning of the Tf parameter for the Attitude controller. Hopefully you won't have to bother with it anymore for larger of smaller ship

- A small change required for my FAR/MJ extension

- A debug message to investigate the null mainbody problem. Please send me logs

[Starwaster]

I pushed a new dev version with 3 changes :

- Auto tuning of the Tf parameter for the Attitude controller. Hopefully you won't have to bother with it anymore for larger of smaller ship

- A small change required for my FAR/MJ extension

- A debug message to investigate the null mainbody problem. Please send me logs

clarify #2 please? will it make FAR & MJ play together any better or is it just some minor tweak/fix that I shouldnt get too excited over?

[sarbian]

It's related the the the second plugin in this thread : http://forum.kerbalspaceprogram.com/threads/60933-Optional-MechJeb-Modules

For now it has limited use but it adds torque from FAR control surface. Rocket and plane behave better with it.

And in a version I did not push yet I added terminal velocity from FAR, so you MJ can now slow down properly on ascent.

Nothing that fancy for now, but I'll add useful other bits with time. I hoped to have the landing guidance use the FAR aerodynamic model but I did not find a clean way to do it yet.

If you have suggestion they are welcome in the thread.

[AndreyATGB]

Would be nice for the predicted orbit after aerobraking to be calculated properly with FAR.

Also somewhat more complex request, it would be awesome to be able to save different ascent profiles and have a list to choose them from. So I could have standard 100km orbit for different ships, some GKO and polar orbits without having to remember the settings and change them every launch.

Edited December 30, 2013 by AndreyATGB

[DrBackjack]

Not sure if this is a bug or not, but I never encountered it in 0.22 which is why I'm posting about it. With the latest stable release on 0.23, when using the rendezvous autopilot if a capsule develops a roll, mechjeb will not auto correct it. I need to press the roll keys A or D to get mechjeb to hold the roll.

[sarbian]

Would be nice for the predicted orbit after aerobraking to be calculated properly with FAR.

Also somewhat more complex request, it would be awesome to be able to save different ascent profiles and have a list to choose them from. So I could have standard 100km orbit for different ships, some GKO and polar orbits without having to remember the settings and change them every launch.

The aerobraking with FAR is related to the landing AP, and that's the part I am struggling with. I have an idea to use an approximation, I'll see if I how it does.

As for the saving ascent profile that won't come for now. I want to have a look at the ascent AP since I want to see if I can implement a "real" gravity turn. So I don't want to add some code I'll have to change later.

DrBackjack : it's known. I need to have a look at it, but as I said in a previous post I am sick of looking at that part of the code ^^

[AndreyATGB]

All right, good to know those are planned. Using version 149 terminal velocity is still not working for me with FAR. It says 788 on the launch pad and quickly goes to infinity like before, wasn't it supposed to work? I have the FAR control surface patch but I don't see why that would interfere.

[AbeS]

well with FAR installed terminal velocity isn't that important during ascent, it is so high that hitting terminal velocity would actually be inefficient. Starting with a TWR of 1.2 and letting it full thrust would work great

[sarbian]

You need an updated version of my MJ/FAR plugin, and I did not upload it yet. Will do later today

[sarbian]

And I uploaded it just now

AbeS : I had small 1 stage rocket hitting the terminal velocity without problem. While it's not all that useful it's better than having a value that means nothing.

Edited December 30, 2013 by sarbian

[DerekL1963]

OK, using build 148, I'm getting two problems;

First problem, MJ not calculating the delta-V for the upper stage;

Second problem, when I separate the stages in orbit (both stages have probe cores as can be seen in the picture) I can manually control the upper stage but MJ cannot perform any control functions. There are two error messages in the log;

[ERR 12:38:08.199] MechJeb caught exception in core OnSave: System.NullReferenceException: Object reference not set to an instance of an object

at MuMech.MechJebCore.OnSave (.ConfigNode sfsNode) [0x00000] in <filename unknown>:0

[ERR 12:38:08.235] MechJeb module MechJebModuleThrustController threw an exception in Drive: System.NullReferenceException: Object reference not set to an instance of an object

at MuMech.CelestialBodyExtensions.RealMaxAtmosphereAltitude (.CelestialBody body) [0x00000] in <filename unknown>:0

at MuMech.VesselState.TerminalVelocityStockKSP () [0x00000] in <filename unknown>:0

at MuMech.VesselState.TerminalVelocity () [0x00000] in <filename unknown>:0

at MuMech.MechJebModuleThrustController.TerminalVelocityThrottle () [0x00000] in <filename unknown>:0

at MuMech.MechJebModuleThrustController.Drive (.FlightCtrlState s) [0x00000] in <filename unknown>:0

at MuMech.MechJebCore.Drive (.FlightCtrlState s) [0x00000] in <filename unknown>:0

[AndreyATGB]

well with FAR installed terminal velocity isn't that important during ascent, it is so high that hitting terminal velocity would actually be inefficient. Starting with a TWR of 1.2 and letting it full thrust would work great

I know but it was mentioned in the change log and wasn't working. Apparently the new plugin will fix it

[sarbian]

DerekL1963 : you root part is the probe in the first stage. The root part must be in the last stage.

Thanks for the info on how to duplicate that bug. I'll look into it but it will have to wait later this week.

[rosenkranz]

OK, using build 148, I'm getting two problems;

First problem, MJ not calculating the delta-V for the upper stage;

http://i1065.photobucket.com/albums/u384/DerekL1963/KSP/screenshot51-1.png

Second problem, when I separate the stages in orbit (both stages have probe cores as can be seen in the picture) I can manually control the upper stage but MJ cannot perform any control functions. There are two error messages in the log;

I think what is happening is that MJ stores which part is in control. When you stage or undock, the child ship no longer contains the control part and it's not picking the first controllable part to go with. Thus all MJ controls are 'locked out'. If you pick a controllable part (like the AR202) and 'control from here' it will clear the exception and work normally.

[Gaius]

Yup. I had the same problem last night: decoupled two spacecraft in space, and MechJeb was unable to control the separated craft until I did the "Control from here" thing -- the Navball was properly reflecting the orientation of the ship, but all of the Smart A.S.S. commands were doing things relative to the other ship and freaking out, doing a kind of confused wobble in place as it tried to turn, but the other ship wasn't moving.

If, in fixing this, you could also make it turn Smart A.S.S. to the "Off" setting when switching control to the newly undocked ship, that'd be cool. Note: NOT DISABLING the module, NOT closing the window, JUST setting Smart A.S.S. to the "OFF" setting instead of "+ TGT" or "- PAR" or whatever. Alternately, upon restoring the undocked craft to its previous Smart A.S.S. settings, make sure it also restores the "control from here" part and the targeted docking port. Right now if you dock with +TGT or -PAR or whatever on, when you undock, that setting is restored, but the "control from here" part and/or targeted docking port are not, and the ship often whips around at high speed and smashes your spacestation as it tries to instantly reorient to whatever random target it has or relative to whatever control part its using instead of using control part and the docking port it was using when it docked. This often happens faster than you can switch to the undocked vessel (whenever I undock, I end up in control of the space station rather than the undocking craft, and have to manually switch over to it and try to hit "OFF" on the Smart A.S.S. before it smacks something -- at this point, "confused undock wobble" is a blessing when it happens).

Edited December 30, 2013 by Gaius

[sarbian]

. Note: NOT DISABLING the module, NOT closing the window, JUST setting Smart A.S.S. to the "OFF" setting instead of "+ TGT" or "- PAR" or whatever.

Reading that doeas not make me in a mood to fix anything at all