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

[Solo Axlion]

Well I've found a bug of sorts. Or maybe I'm just doing something wrong. Attempting to use the AutoLander option of MechJeb, and despite the ship's path entering the atmosphere and on a collision course with the ground, the Autopilot aborted the landing attempt due to something with a negative Perapsis being > than another value. Don't exactly remember what it said, other than the negative value on one side and the ">".

[Scottiths]

Has anyone else noticed that MechJeb does not do a good job of calculating D-v when SRBs are involved? Or did I somehow mess up the instillation?

[HGGundamReviews]

I'm posting this for The_Duck and R4m0n to look at.

I tried adding MJ function's to Bobcat's SoyuzTMA_Descent_module from the 0.20 updated Soviet pack.

I added this line to the part.cfg

MODULE

{

name = MechJebCore

}

It caused a bug in the part that froze it in position. When I went to launch it the rocket would fire but not move. When I shut the rocket down and started decoupling things to see where the bug was it was in the command module. Just happily floating in mid air after everything had been detached from it.

I have no clue as to why this happened but figured I would let you guys know in case you can figure out a fix for it sometime in the future.

Using 2.0.8 (not the dev build)

[daver4470]

I'm posting this for The_Duck and R4m0n to look at.

I tried adding MJ function's to Bobcat's SoyuzTMA_Descent_module from the 0.20 updated Soviet pack.

I added this line to the part.cfg

MODULE

{

name = MechJebCore

}

It caused a bug in the part that froze it in position. When I went to launch it the rocket would fire but not move. When I shut the rocket down and started decoupling things to see where the bug was it was in the command module. Just happily floating in mid air after everything had been detached from it.

I have no clue as to why this happened but figured I would let you guys know in case you can figure out a fix for it sometime in the future.

Using 2.0.8 (not the dev build)

You didn't put it at the very end, did you? As in, outside the overall PART bracketed code?

You should probably post the edited .cfg of the part that's problematic, too.

[HGGundamReviews]

I added it as seen below.

PART
{
// --- general parameters ---
name = Soyuz TMA Descent Module
module = CommandPod
author = Bobcat, CrashnBurn
// --- asset parameters ---
mesh = model.mu
scale = 1
rescaleFactor = 1

// --- node definitions ---
// definition format is Position X, Position Y, Position Z, Up X, Up Y, Up Z
node_stack_top = 0.0, 1.275, 0.0, 0.0, 1.0, 0.0, 1
node_stack_para = 0.0, 1.2, 0.0, 0.0, 1.0, 0.0, 0
node_stack_bottom = 0.0, -0.25, 0.0, 0.0, 1.0, 0.0, 1

CoMOffset = 0, -0.8, 0

// --- editor parameters ---
cost = 1800
category = Pods
subcategory = 0
title = Soyuz TMA Descent Module
manufacturer = Bobcat Ind
description = This is the only part that comes back in one piece, it needs to. Otherwise your crew will have to walk back… and its a LONG way down
// attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision
attachRules = 1,0,1,1,0

// --- standard part parameters ---
mass = 2
dragModelType = default
maximum_drag = 0.20
minimum_drag = 0.2
angularDrag = 2
crashTolerance = 45
breakingForce = 630
breakingTorque = 630

maxTemp = 3400

vesselType = Ship

// --- pod/rcs parameters ---

rotPower = 5
linPower = 1

Kp = 1.0
Kd = 1.0

// --- internal setup ---
CrewCapacity = 3

INTERNAL
{
  name = SoyuzPod
}


MODULE
{
	name = ModuleCommand
	minimumCrew = 1
}

RESOURCE
{
	name = ElectricCharge
	amount = 250
	maxAmount = 250
}





MODULE
{
       name = ModuleJettison
       jettisonName = VZOR
       bottomNodeName = bottom
       isFairing = False
       jettisonedObjectMass = 0.1
       jettisonForce = 2
       jettisonDirection = 0 0 1

}

MODULE
{
name = MechJebCore
}

}

[Gaius]

I've seen the "immovable object" bug rear its ugly head before, on command pods without MechJeb. Its occurrence at the same time you made that change could be pure coincidence (correlation != causality). Can you replicate it on a fresh craft constructed using a fresh copy of that command pod?

[HGGundamReviews]

I've seen the "immovable object" bug rear its ugly head before, on command pods without MechJeb. Its occurrence at the same time you made that change could be pure coincidence (correlation != causality). Can you replicate it on a fresh craft constructed using a fresh copy of that command pod?

The ship worked fine before I made the change, and worked properly after I removed to module code. It works fine with a MJ part attached to it. But for some reason it doesn't work with the code put into its cfg file.

Edit : It is a fresh install, I was having other issues with the soviet pack a few days ago and did a fresh install of it to remove some incompatible DLL's the pack originally had and installed fresh seperate versions of those plugin's, Docking Cam and Kerbal Attachment System updated for 0.20 so everything was working smoothly. Until I tried to install the MJ code into that command pod. Unless someone figures out that little bug I'll just slap a AR case on it somewhere. It does work with a MJ attached to it from the outside.

Edited June 2, 2013 by HGGundamReviews

[Gaius]

The ship worked fine before I made the change, and worked properly after I removed to module code. It works fine with a MJ part attached to it. But for some reason it doesn't work with the code put into its cfg file.

...which doesn't answer the question I asked. (Depending on the answer, the .craft file may be required to determine the problem, or may even be the source of the problem.)

[TBryson2]

When using the Ascent Autopilot, The ship always turns to a heading 90 degrees off of what is entered. I.E., If I plug in 0, ship heads 090. If I plug in 180, ship heads 270. Plug in 90, ship heads 0.

I am running 2.0.8 and latest KSP.

Thanks, TB

[SpaceDude]

I understand that the radial mechjeb part is the only one left that survived the transition to AR. My question is, can this part me made smaller? It really is too big for probes.

[RoboRay]

You don't put in heading... you put in inclination. It's working correctly.

[GavinZac]

When using the Ascent Autopilot, The ship always turns to a heading 90 degrees off of what is entered. I.E., If I plug in 0, ship heads 090. If I plug in 180, ship heads 270. Plug in 90, ship heads 0.

I am running 2.0.8 and latest KSP.

Thanks, TB

Is your command module orientated the 'wrong' way? I had this where I thought I could stick the probe legs on the *top* of the Stayputnnik and have MechJeb land on them. Instead, MechJeb happily pointed the probe at the moon and suicide burned in the wrong direction.

If it's awkward, what I do is place a dock at the 'right' end of the ship and right click -> control from here. You see the navball change and MechJeb knows what direction to go in now.

Edit: I just read that it was in Ascent Autopilot (I had been in reading Autopilot...), yeah, it sounds like you put in the Orbit inclination.

Edited June 2, 2013 by GavinZac

[Innuce]

Just installed the new KSP patch v20.2 but sadly whatever they fixed, it wasn't the docking bug.

I did test escaping to the Space Center, then re-selecting my craft from the Tracking Station. That still works as a workaround.

C'mon v20.3!

[Canopus]

Is it just me or has the spaceplane landing autopilot gotten less precise? The same planes that it could land a few versions back now all crash.

[Castun]

Has anyone else noticed that MechJeb does not do a good job of calculating D-v when SRBs are involved? Or did I somehow mess up the instillation?

I've noticed this as well. My first stage always reports 0 dV even though I have LFEs & SRBs in the first stage.

[Wayfinity]

Hi there,

I am trying to get this to work under OSX but am having no luck. Is there anything that i am doing wrong or does this just not work under OSX? I've installed it the same way as per i did with my windows machine, i.e. Parts in Parts, Plugin's in Plugin's.

I've tried to find a solution but to no avail as it would appear that people using OSX are not a huge demographic which is disappointing since KSP is so brilliant!

Cheers.

[Innuce]

The file structure has changed.

The Parts and Plugins folders are now in sub-folders in the new GameData folder. Inside the GameData folder you'll find a folder called Squad. That's where all the default Parts go.

Mods each get their own folders now. So MechJeb2 for instance will have a MechJeb2 folder under the GameData folder.

Hope that helps!

[marius86000]

Hi! Is it possible to turn on the RCS without letting MechJeb use it?

[TBryson2]

You don't put in heading... you put in inclination. It's working correctly.

Ok, let me see if I understand this correctly. Inclination is the direction that the planet (moon) is turning. i.e. if I set my inclination to "0" my ship will launch in that direction. Any other setting of inclination (90, 180...) is based on the way the planet is turning?

Thanks!

TB

[Gaius]

Ok, let me see if I understand this correctly. Inclination is the direction that the planet (moon) is turning. i.e. if I set my inclination to "0" my ship will launch in that direction. Any other setting of inclination (90, 180...) is based on the way the planet is turning?

Yes (sort of), it's the standard way (in astronomical literature) that orbital inclinations are given. More technically, it's the angle between the plane of an orbit and the reference plane (a planet's equator if we're talking about orbiting a planet) as measured from the ascending node. If the object orbits a planet with an inclination of 0, that means it flies directly over the equator, going in the same direction as the planet is rotating. An orbital inclination of 90 is a polar orbit, 180 is a retrograde orbit.

Read this for more info.

It's noteworthy that, technically speaking, an orbital inclination is always between 0 and 180. It cannot be less or more, since it is properly measured from the ascending node, and if the angle was negative or >180, you'd be measuring from the descending node. That said, specifying a negative inclination is a convenient way of saying you want to launch southwards instead of northwards (i.e. treat your point of ascent as if it's the descending node).

Edited June 2, 2013 by Gaius

[RoboRay]

Ok, let me see if I understand this correctly. Inclination is the direction that the planet (moon) is turning. i.e. if I set my inclination to "0" my ship will launch in that direction. Any other setting of inclination (90, 180...) is based on the way the planet is turning?

Thanks!

TB

Yes. If you are orbiting directly along the equator in an easterly direction (heading 090), your orbit is not inclined (inclination is zero). A perfect polar orbit would have an inclination of 90 degrees.

While a retrograde equatorial orbit (heading west), is technically also not inclined, it's customary to refer to it as inclination 180 to eliminate confusion. Any inclination greater than 90 is a retrograde orbit.

Edited June 2, 2013 by RoboRay

[HGGundamReviews]

...which doesn't answer the question I asked. (Depending on the answer, the .craft file may be required to determine the problem, or may even be the source of the problem.)

Ok I figured this out and it was something stupid I did. I had as I previously stated added the MJ code to the command pod of the Soyuz TMA from Bobcat's Soviet Pack. What I didn't realize is that I also added it to the Soyuz TMA Orbital Module (the ball shaped thing on top of the command pod) along with Chatterer. I removed the MJ code from that, got the same results, command pod locked in mid air. I removed the Chatterer code from the Orbital Module and left the MJ code in the command pod and it launched without a problem. I added the Chatterer Code to the command pod and it froze again. Apparently MJ and Chatterer can't coexist (code wise) in Bobcat's parts. It's the only mod I have found this with. I did 5 different tests, (on fresh installs of 0.20.2 with new versions of all mods involved).

I have no idea what is exactly happening. I looked at the debug menu and was not showing in errors when trying to launch so I don't know what the interaction is between Bobcat's part, Mech Jeb, and Chatterer are that's freezing the part in place.

I'll post a thing about it in both of the other two threads and maybe all the makers involved can see what's happening. This is a damned interesting ghost in the machine bug I tell you.

[Castun]

Ok I figured this out and it was something stupid I did. I had as I previously stated added the MJ code to the command pod of the Soyuz TMA from Bobcat's Soviet Pack. What I didn't realize is that I also added it to the Soyuz TMA Orbital Module (the ball shaped thing on top of the command pod) along with Chatterer. I removed the MJ code from that, got the same results, command pod locked in mid air. I removed the Chatterer code from the Orbital Module and left the MJ code in the command pod and it launched without a problem. I added the Chatterer Code to the command pod and it froze again. Apparently MJ and Chatterer can't coexist (code wise) in Bobcat's parts. It's the only mod I have found this with. I did 5 different tests, (on fresh installs of 0.20.2 with new versions of all mods involved).

I have no idea what is exactly happening. I looked at the debug menu and was not showing in errors when trying to launch so I don't know what the interaction is between Bobcat's part, Mech Jeb, and Chatterer are that's freezing the part in place.

I'll post a thing about it in both of the other two threads and maybe all the makers involved can see what's happening. This is a damned interesting ghost in the machine bug I tell you.

But they work fine with the Bobcat parts as long as you use the external parts?

[HGGundamReviews]

Yeah the external parts work fine, its just adding their module codes to the part.cfg files that makes the parts freeze.

[evilC]

I seriously love mechjeb, but please, for the love of god, can we sort RCS rotation out?

In space, it keeps accelerating until the last possible second - so it always wildly overshoots - often by 50% or so of the amount turned.

Is there some problem getting calcs right here or is it just a case of more time being spent on other areas?

I had a look at the source, and predictably the maths is a bit beyond me, but from observation, the method it is using is basically a bit crazy - if you keep thrusting past 50% of the way through a turn (In space), there is no other possible outcome except overshooting.

How about this to simplify things? When mechjeb uses RCS, it checks the effect it is having - ie it starts to build up a picture like "my delta rot for x axis is about 2deg/sec"

So now mechjeb has some idea of what your delta rot is, so it can work out "at this rot rate I will hit target in 2s, and the historical delta rot means I need 2s to kill this much rot, so I better switch from speeding up to slowing down now"

Or am I grossly over-simplifying this?