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

[Ezriilc]

Most likely your difference comes from the fact that you don't check for physicalSignificance

That has proved to be a factor, but after some testing, it looks like there is more to it.

If I'm not mistaken, the mass displayed by MechJeb in the "Delta-V Stats" window is the one affected by physicalSignificance.

The mass displayed elsewhere - like if I add it to a custom window - is different and greater.

The mass I'm calculating is even greater than that.

The difference is easier to see in a larger ship.

With the "Kerbal X" ship, I get a mass of "131.51", and MechJeb reports "131.5"; I had attributed that difference to possible rounding in MechJeb.

With my own ship, "Kolsys 5.2 Explorer" which is quite large, I get "692.54", and MechJeb "683.3".

By applying what sarbian has shown me, I get "692.4", which is still way off from the MechJeb value.

By using "0" for off instead of "1", I get "691.94" - closer, but still way off. ^(incorrect)

So, I'm stumped again. If anyone can shed some light on this, I'd be very grateful.

Edited March 19, 2014 by Ezriilc

[Ezriilc]

This is what the code you linked says:

 public enum PhysicalSignificance
    {
        /// <summary>
        /// Part is a normal, physics-enabled part.
        /// </summary>
        FULL = 0,
        /// <summary>
        /// Part has no physics, and in particular no mass or drag.
        /// </summary>
        NONE = 1,
    }

So FULL is 0 and NONE is 1, as sarbian said.

You are so right. I'm not on my best game today, it would seem. Point taken, and thank you very much!

EDIT: However, that makes the numbers even more confusing to me, because now they're nowhere near MechJeb's.

Edited March 19, 2014 by Ezriilc

[Ezriilc]

So FULL is 0 and NONE is 1, as sarbian said.

Is there any difference between FULL and no value or null? In other words, is FULL (0) the default value for physicsSignificance?

[John FX]

Hello, Bug report time again (I really must figure out how Github works)

When an engine is turned off with an action group, the TWR on the Delta-V window fails to update. The remaning Dv also fails to update here and in the vessel info window although the TWR does update in the vessel info window...

TWR should be about 1.45 and remaining Dv about 600 (aerospikes turned off, only NERVA left turned on)

[NathanKell]

Is there any difference between FULL and no value or null? In other words, is FULL (0) the default value for physicsSignificance?

It is the default, yes. Having physics disabled is useful for very-low-mass parts as otherwise they wobble a ton (which is particularly bad when you have a heavy engine on a cubic strut attached to a heavy tank).

Note that IIRC everything with module = Strut also has its mass ignored inflight.

[Ezriilc]

It is the default, yes. Having physics disabled is useful for very-low-mass parts as otherwise they wobble a ton (which is particularly bad when you have a heavy engine on a cubic strut attached to a heavy tank).

Note that IIRC everything with module = Strut also has its mass ignored inflight.

Ah! That makes sense to me, actually. Thanks a tonne for answering that for me.

So, to accurately display a ship's performance, I shouldn't logically count mass for those parts, since it will not effect the experience. Yea?

Now to see if that brings my numbers in line with MechJeb - for that matter, should they be?

[Ezriilc]

Note that IIRC everything with module = Strut also has its mass ignored inflight.

Would that be "Strut" OR "StrutConnector"? Or only "Strut"?

Adding this to my code brings my mass more inline. For Kolsys, I now get "686.8", which is still 3.50 tonnes more MechJeb shows in Delta-V Stats.

Any ideas where that difference is coming from?

EDIT: Alas, my mass for Kerbal X is now too low, so something's still not right.

Edited March 19, 2014 by Ezriilc

[safarley2901]

So I've been hunting for an answer to this for weeks, and barring going through 560 pages of thread posts, I was hoping someone would give me some quick info. Every time I try to use SpacePlane guidance to land one of my shuttles, all it does is point toward the gravity well and sit there. No deorbit burn, no auto warp. And when I try to force it to deorbit and use the space plane guidance (after lining up the landing zone manually) all it does is crash into the ground nose first.

I was wondering if anyone else has this problem? I have a crap ton of mods, but they all work. The craft itself operates perfectly, just wont land. Any ideas?

[sojourner]

Well for the first part. you have to get back into atmosphere and not be in orbit before activating the landing function in the spaceplane guidance. Not sure about the second part though.

[safarley2901]

Well for the first part. you have to get back into atmosphere and not be in orbit before activating the landing function in the spaceplane guidance. Not sure about the second part though.

Hey thanks for the response, I realize how self assuming my post would have come across and was actually going to ask if anyone had any good tutorials for landing the darn things. Landers are... I was going to say easy, but I've gotten used too. Space planes? My creations drop like a rock.

Thanks again though, I appreciate it.

[Hachouma]

Oh god that eye is looking at me

[VaporTrail]

Oh god that eye is looking at me

The MechJeb all-in-one pod... Breaking the Fourth wall since '13.

[Mykill Metal]

Having a problem with landing guidance. It seems to place a landing prediction somewhere in front of the ship. Does not move. And screws up the rest of the landing process. I can't seem to get it to actually land at the target. It just burns randomly towards the prediction marker.

[Mykill Metal]

also...is it possible for the next update to include a version where I don't have to unlock the different windows? I hate having to modify the .cfg every single time.

[sojourner]

You only have to modify the .cfg once. The next time you update just replace the .dll file.

[John FX]

I don`t know how easy it would be to program but it would be cool for MechJeb to be able to have multiple ascent profiles for each craft. The first is the main one that launches the craft from Kerbin but the second would be for if there is a lander as the payload that also needs an ascent profile (usually very different from the first)

What happens currently is that each time I do a mun mission I launch, entering the launch profile, land on mun, launch, entering the munar launch profile overwriting the first one.

Then the next time I launch my turn starts at 2km, ends at 7km and is at 23% and I am trying to orbit Kerbin at 20km...

Maybe have the ability to save a launch profile for every body for each craft?

Then multilander.craft could have a profile saved (or sections in the profile) for Kerbin (for launch), Mun, Minmus, Ike, Gilly and Tylo etc and lifting off from anywhere would not overwrite the other profiles.

[Galane]

Having a problem with landing guidance. It seems to place a landing prediction somewhere in front of the ship. Does not move. And screws up the rest of the landing process. I can't seem to get it to actually land at the target. It just burns randomly towards the prediction marker.

What altitude are you landing from? On which body? Does the ship have an overabundance of RCS and/or reaction wheels? From around 70KM Kerbin orbit, with ships that have a lot of control force for their mass, Landing Guidance often just goes nutzo. (I posted a craft a ways back up thread specially constructed to always trigger that problem from a 71KM orbit so Sarbian could track down what's doing it.)

Try starting from a higher orbit. My test craft does the deorbit burns properly from higher altitude.

[Starwaster]

I don`t know how easy it would be to program but it would be cool for MechJeb to be able to have multiple ascent profiles for each craft. The first is the main one that launches the craft from Kerbin but the second would be for if there is a lander as the payload that also needs an ascent profile (usually very different from the first)

What happens currently is that each time I do a mun mission I launch, entering the launch profile, land on mun, launch, entering the munar launch profile overwriting the first one.

Then the next time I launch my turn starts at 2km, ends at 7km and is at 23% and I am trying to orbit Kerbin at 20km...

Maybe have the ability to save a launch profile for every body for each craft?

Then multilander.craft could have a profile saved (or sections in the profile) for Kerbin (for launch), Mun, Minmus, Ike, Gilly and Tylo etc and lifting off from anywhere would not overwrite the other profiles.

I usually just leave it on automatic. It will generate appropriate ascent plans for every body by itself.

[mrskwid]

so has anybody tried the Orbital resonance feature and if so i would like to learn how to use it to keep satellites in formation.

i think i can get a network up their but i don't won't to have to micro manage them once i do.

[CatastrophicFailure]

Just throwing this out there, since MechJeb typically works pretty well for me and generally does what it's told...

Feature requests: a lock roll, or better yet, climb-then-roll feature on the ascent guidance.

A station keeping autopilot!

Seems to me the groundwork for these is already there (Smart A.S.S. has a roll lock, docking AP recognizes distance and position), so actual implementation shouldn't take much effort...

...should it?

[drtedastro]

being able o assign a roll program to the ascent program would be top notch...... I have wanted that for eons.

also a time to launch..... would be nice. just a simple launch at xxxD xxH xxM xx.0000 sec... would be fantastic...

[BudgetHedgehog]

Regarding orbital transfers...

If I transfer to another planet, I've noticed that even if I'm at a transfer window or am a few days away (according to KAC), MJ will wait until the next one. Or, I have several vessels I want to launch in this window but if I let MJ do it all, their burns all happen at the same time, which I can't do and leaves all bar one still orbiting Kerbin waiting for the next window (according to MJ, even though a transfer window is active now).

Anyway, my question is, is there a way to force MJ to transfer to another planet NOW? Like, I don't care if it takes a bit more dV to do it because I have plenty, I just want to go now, not in 1 day and not in 150 days.

[Crater]

Regarding orbital transfers...

If I transfer to another planet, I've noticed that even if I'm at a transfer window or am a few days away (according to KAC), MJ will wait until the next one. Or, I have several vessels I want to launch in this window but if I let MJ do it all, their burns all happen at the same time, which I can't do and leaves all bar one still orbiting Kerbin waiting for the next window (according to MJ, even though a transfer window is active now).

Anyway, my question is, is there a way to force MJ to transfer to another planet NOW? Like, I don't care if it takes a bit more dV to do it because I have plenty, I just want to go now, not in 1 day and not in 150 days.

If you know what your tansit time is supposed to be, you could try for an "Intercept at time X" transfer, but you'll really need to be accurate on where in your orbit you place the burn, or you could find it to be extremely delta-v intensive.

Other than that, you could try plotting the burns well in advance, storing them using something like Kerbal Alarm Clock, or PreciseNode for each craft, then running the burns manually one orbit early, or one orbit late, and then tweaking the course with a mid course correction.

[BARCLONE]

Sarbian,

Installed dev193, testing the Landing Guidance AP with a little Pathfinder on Moho...

Let me try to describe what happened to two landers in a row:

Picked the landing location on the map, engaged the AP. The lander goes into the initial de-orbit burn OK, brings the predictor over the target site. During the decent, the AP rotates the lander -NML, and continually fires the engine at a very low throttle notch. This appears to be bringing the final landing position to match the selected position, but the AP is jerking the thrust vector around erratically and this never stabilizes. Lander is otherwise free-falling and is accelerating from gravity. As the targets line up to within a few meters of each other, MechJeb turns the lander PRO-GRADE and shoves the throttle to full until the altitude is less than 3 Km. At Moho, this means the lander is now screaming toward the surface at over 800 m/s. Near the 1 Km altitude, the lander lowers the gear, and flips into a heads-up attitude, but there is no possibility to slow down and the lander hits the ground at better than 600 m/s.

Not exactly what I expected...

ADDENDUM:

Looking now at the KSP.log file...

I'm not finding anything in the way of an exception being thrown prior to impact, but exceptions-a-plenty afterward. In fact, about 4/5 of the log file is nothing but a list of error exceptions. However, most of the errors deal with "MechJebModuleThrustController" and "MechJebModuleAttitudeController".

Here's a link to the KSP.log file...

2nd ADDENDUM:

Just re-installed dev192, and I'm getting the same weird behavior. Looking at the direction "needles" on the bottom-left, it gives the appearance that the yaw and pitch controls are fighting each other. It's a constant back-and-forth action on both directional axis. Could this be some sort of "infinite loop" in the code?

One change in my observation earlier. The bad burn is very close to being -RAD instead of PRO-GRADE. The outcome, however, remains the same. SPLAT.

Edited March 22, 2014 by BARCLONE

[BloodyRain2k]

Yeah, something seems to be wrong with the Landing AP on Moho, it seems to try to do an atmospheric landing but without the drag deceleration that fails and it just raises the PE above the surface again and then derps out.