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

[BloodyRain2k]

Is there anyway i can increase mechjebs smart a.s.s torgue? It's taking a long time for mechjeb to point to a node.

Your problem is either that you don't have enough torque, so either add more reaction wheels or turn on the RCS (or add more thrusters), OR if you know you have enough, the problem is that MJ isn't using it correctly.

That is something that happens for me a few times.

Open the Attitude module window and look what the Tf setting is, on Auto does MJ try to figure out a good value based on the mass of your craft.

The problem with that is that it sometimes gets it wrong and lighter crafts wibble oscilize, or larger ones lag oscilize.

I often found it then better to set it simply to manual with a value of 0.3 for smaller ones and 0.5 for the larger ones.

Sarbian already told me that he needs to figure out a formula that's a bit better but well, math and stuff can take some time.

What I don't know is if that value and setting are global or per craft saved but I'd guess for global.

[OrbitalDebris]

^^^ what he said. Every single time I've had rockets in space turning sluggishly, it's been because I didn't have enough reaction wheels. For maximum effect, put them as far from each other as possible - two wheels next to each other will have a much weaker effect than one at each end of the rocket, especially if it's long (torque = force x distance, the reaction wheels provide the force).

[Starwaster]

^^^ what he said. Every single time I've had rockets in space turning sluggishly, it's been because I didn't have enough reaction wheels. For maximum effect, put them as far from each other as possible - two wheels next to each other will have a much weaker effect than one at each end of the rocket, especially if it's long (torque = force x distance, the reaction wheels provide the force).

Be warned that torque is around the reaction wheel part, not the ship's CoM.

Placing wheels like that will work but it does stress things more than if it was in the center.

[TheSaint]

• Rendezvous AP still seems to have an issue (target vector drifts) during the last phases of an engine burn. If I disengage the RendAP quickly when the drift starts, then re-engage it, the drift goes away and the next step in the sequence begins normally. Something is not properly closing out at the end of each phase of a rendezvous, and MJ is getting "vapor lock", or "gimbal lock". There may be other issues at work here, but the clearing of the issue by shutting down the AP, then quickly re-engaging it, points to at least one issue within MJ.
  
• The drifting issue also occurs in the Ascent AP, during the last burn-to-apoapsis and during the circularization burn. Probably the same issue as with the RendAP.
  

I have had these two issues for a very long time, ever since 0.23 came out. When the burn is coming close to completion the node starts to drift away, and MechJeb will dutifully turn the ship to chase it, so you wind up in an orbit radically different than the one you wanted. It almost seems like MechJeb isn't holding precisely on the node, or that it's burning too long. It's become so annoying that I actually dropped KSP back to 0.22 so that I could use the previous builds of MechJeb that don't have this problem. If I had any programming skills at all I would help with it, but I'm an infrastructure guy, sorry.

[John FX]

I have had these two issues for a very long time, ever since 0.23 came out. When the burn is coming close to completion the node starts to drift away, and MechJeb will dutifully turn the ship to chase it, so you wind up in an orbit radically different than the one you wanted. It almost seems like MechJeb isn't holding precisely on the node, or that it's burning too long. It's become so annoying that I actually dropped KSP back to 0.22 so that I could use the previous builds of MechJeb that don't have this problem. If I had any programming skills at all I would help with it, but I'm an infrastructure guy, sorry.

This sounds like the node in KSP is moving and MJ is trying its best to keep pointed at it due to a (i suspect) slight node function change in 0.23.

There might be a change to the MJ code that could fix this but also there might be a chance that KSP would need to change its code to remove this effect.

[BloodyRain2k]

I have had these two issues for a very long time, ever since 0.23 came out. When the burn is coming close to completion the node starts to drift away, and MechJeb will dutifully turn the ship to chase it, so you wind up in an orbit radically different than the one you wanted. It almost seems like MechJeb isn't holding precisely on the node, or that it's burning too long. It's become so annoying that I actually dropped KSP back to 0.22 so that I could use the previous builds of MechJeb that don't have this problem. If I had any programming skills at all I would help with it, but I'm an infrastructure guy, sorry.

This sounds like the node in KSP is moving and MJ is trying its best to keep pointed at it due to a (i suspect) slight node function change in 0.23.

There might be a change to the MJ code that could fix this but also there might be a chance that KSP would need to change its code to remove this effect.

I'm not sure about the cause of the problem and even though I spent 2min now writing down my theory about it do I not want to spread false information so meh, just this note about it.

There is a damn simple solution to it however: the tolerance setting in the Maneuver Planner.

The default 0.1 m/s work normally for all, but if you have a rather heavy ship that might tend to wobble a bit just from beginning to turn then it's likely that you need to raise the tolerance because at the 0.1 m/s point will the wobble be enough to knock the node marker all over the place.

Why the hell it helped you Saint, to revert to 0.22 is beyond me, that setting is set to 0.1 m/s since it's in. Maybe something got changed in the Attitude controller, or it was the Tf setting of it, I'd bet on that.

Anyways, try raising the tolerance and see if that helps. Also try playing with the Tf value in the Attitude window, auto tends to get it wrong for heavier ships, I usually go for 0.3 or 0.5 if it get's a little twitchy.

[John FX]

I'm not sure about the cause of the problem and even though I spent 2min now writing down my theory about it do I not want to spread false information so meh, just this note about it.

There is a damn simple solution to it however: the tolerance setting in the Maneuver Planner.

The default 0.1 m/s work normally for all, but if you have a rather heavy ship that might tend to wobble a bit just from beginning to turn then it's likely that you need to raise the tolerance because at the 0.1 m/s point will the wobble be enough to knock the node marker all over the place.

Why the hell it helped you Saint, to revert to 0.22 is beyond me, that setting is set to 0.1 m/s since it's in. Maybe something got changed in the Attitude controller, or it was the Tf setting of it, I'd bet on that.

Anyways, try raising the tolerance and see if that helps. Also try playing with the Tf value in the Attitude window, auto tends to get it wrong for heavier ships, I usually go for 0.3 or 0.5 if it get's a little twitchy.

I`ve just done a test and it does it with a small agile craft (10T) that has no detectable wobble and it happens when the remaining burn is a full 1m/s. It starts to reduce throttle to finalise the burn, the node marker starts to move and the craft starts spinning and the node marker does not stop moving and MJ chases it without end, faster and faster, while the burn Dv increases. For me this is a new `feature` that was not present in previous versions of MJ (I don`t update often)

I`m guessing there is a good reason why reverting to a previous version of MJ stops this action.

[BudgetHedgehog]

Hi all,

I've got the latest version of MJ and I completely removed any MJ files before I installed it....however, with almost all of my ships, large and small, many parts and few parts, I've been having an issue with MJ's Autopilot constantly rolling my ships left and right and MASSIVELY overcompensating when trying to point towards a node to the point I have to intervene and try and 'help' it aim at the node with the movement keys or even turning autopilot off and having to fly manually. It used to work fine on these same ships before....what happened?

I've had that a few times. Some times, it just won't point at the node so I maunally turn it and when it's there, it auto-warps and carries on. I really want a fix for this

[Justin Kerbice]

I also encounter many time these "node running away", but never a faster and faster chase like John FX.

But for 1 m/s of dV, does it really matter ? Unless you do a long interplanetary move for which a tiny shift can turn into a enormous disaster, you just have to turn off autopilot as fast as you can and the engine and go for your next move.

[Starwaster]

I also encounter many time these "node running away", but never a faster and faster chase like John FX.

But for 1 m/s of dV, does it really matter ? Unless you do a long interplanetary move for which a tiny shift can turn into a enormous disaster, you just have to turn off autopilot as fast as you can and the engine and go for your next move.

When you're OCD about your maneuvers, like I am, yes it matters! That's why when I'm down to my last 1m/s, I switch from node orientation to 'kill rot' or just turn on ASAS.

Then I turn on RCS thrusters and finish the burn on RCS alone.

[Ezriilc]

Hi, ya'all!

Can anyone describe how MechJeb calculates mass, or point me to that info? Specifically, does MechJeb ignore any parts or resources?

You see, I'm writing a .craft file parser, and I keep getting a higher mass for my ships than MechJeb does. I'm not counting clamps, but I do count absolutely everything else, including all parts and resources - even ElectricCharge (I know, it's zero) and IntakeAir (same as LF & Oxy!?).

Of course, I'm assuming that I'm the one making an error, and not the folks at MechJeb, so I'm wondering where I've gone wrong.

Using Kerbal X as an example, MechJeb calcs its mass as "131.5" in the Delta-V Stats window, but "131.81" in the Vessel window. Now, I had always assumed that the Vessel window showed total mass with clamps, but that number matches my number without clamps, so I'm confused.

It seems that the more parts and/or bigger a ship is, the more difference between my numbers and MechJeb's, and mine are always higher. I've triple-checked that I'm not counting mass where I shouldn't, so I'm stumped as to why my calcs differ.

Anyone familiar with this or have some insight?

[TheSaint]

This sounds like the node in KSP is moving and MJ is trying its best to keep pointed at it due to a (i suspect) slight node function change in 0.23.

There might be a change to the MJ code that could fix this but also there might be a chance that KSP would need to change its code to remove this effect.

Possible. It's hard to troubleshoot since the latest builds of MechJeb won't run on 0.22.

I'm not sure about the cause of the problem and even though I spent 2min now writing down my theory about it do I not want to spread false information so meh, just this note about it.

There is a damn simple solution to it however: the tolerance setting in the Maneuver Planner.

The default 0.1 m/s work normally for all, but if you have a rather heavy ship that might tend to wobble a bit just from beginning to turn then it's likely that you need to raise the tolerance because at the 0.1 m/s point will the wobble be enough to knock the node marker all over the place.

Why the hell it helped you Saint, to revert to 0.22 is beyond me, that setting is set to 0.1 m/s since it's in. Maybe something got changed in the Attitude controller, or it was the Tf setting of it, I'd bet on that.

Anyways, try raising the tolerance and see if that helps. Also try playing with the Tf value in the Attitude window, auto tends to get it wrong for heavier ships, I usually go for 0.3 or 0.5 if it get's a little twitchy.

I can give this a try, but I have my doubts. My observation has been that the issue is actually more pronounced with smaller ships than larger ships. The larger ships are more sluggish in following the node, so they complete their burn closer to the original direction.

I`ve just done a test and it does it with a small agile craft (10T) that has no detectable wobble and it happens when the remaining burn is a full 1m/s. It starts to reduce throttle to finalise the burn, the node marker starts to move and the craft starts spinning and the node marker does not stop moving and MJ chases it without end, faster and faster, while the burn Dv increases. For me this is a new `feature` that was not present in previous versions of MJ (I don`t update often)

I`m guessing there is a good reason why reverting to a previous version of MJ stops this action.

Me as well. I can run the same ship in both versions and use the Ascent Guidance to shoot for a 100km orbit. Both instances are stock except for MJ, all MJ settings are default. In 0.23 with MJ #188 it ends up in a wildly eccentric orbit (140km x 85km on my last try, but it varies a lot). With the same ship in 0.22 with MJ #130 it nails it, every time, never more than 500m off.

Don't get me wrong, don't want to seem like a complainer. I really appreciate all the work that Sarbian, et al have done on MechJeb, and I realize that they all have day jobs. Just wanted to add a +1 to other's observations about this issue. I know it will get fixed eventually. In the mean time I just get to enjoy playing 0.22 for a little while longer.

[Galane]

@TheSaint, I wonder if that might have something to do with why sometimes MJ puts a craft into a perfectly circular but off center orbit? Some of the times it's done that, I've tried to re-circularize at the desired altitude or the AN or DN and it just would not get it right.

I haven't been using KSP for a while, waiting on parts for a new PC, took the Phenom II 555 CPU out of this box (to use on the new AM3 board) and replaced it with an AM2 Athlon 2 7550. The Phenom could just handle the Eve assembly in Kerbin orbit. With the Athlon 2 it's almost down to a slideshow. The new board should hopefully be able to unlock 1 or 2 more cores on the Phenom, and I have a Radeon HD 6870 to go in it.

[BARCLONE]

"...This sounds like the node in KSP is moving and MJ is trying its best to keep pointed at it due to a (i suspect) slight node function change in 0.23. "

"...simple solution to it however: the tolerance setting in the Maneuver Planner."

As I mentioned in my post, "there may be other factors" besides MJ. I do think there is a problem within KSP that's at the root of this issue, but I also think there is something within MJ that is (big 50-cent word here) exacerbating the problem. Shutting down the autopilot and re-engaging it quickly seems to clear the problem, so MJ is at least contributing to the error. Locating why it's doing this is probably bigger than trying to explain it.

I tried increasing the tolerance setting, and found the problem started showing itself earlier in the tail-off. The problem also shows up during the ascent, when the sustainer gets into the circularization phase. I had a large (5m) launcher start chasing its tail at between 4 and 5 m/s of remaining thrust after changing that tolerance setting to 0.3. I'll give it this, it wasn't as jittery as it normally is, but MJ still tried to dutifully chase the vector around the navball.

One interesting thing about all this chasing -- if you watch the apoapsis and periapsis numbers, you'll see MJ is trying to get a near-perfect circle in the orbit. Mine typically come out with about 200-300 meters difference after the chase, so as far as having an odd-shaped orbit, it's not doing that to mine. The orbit is usually very good; it's just annoying to watch every ship chase its tail at the end of (virtually) every burn. I can certainly live with it for now, but visually it's disturbing.

[John FX]

I just flew one of my larger craft and it did a burn perfectly down to 0.03m/s (my standard setting when there are no issues which normally works fine)

It`s the smaller craft that can turn quickly that get confused for me.

[Ezriilc]

Me again. I'm hoping that someone has some info about how MechJeb calculates mass, and that I haven't asked in the wrong place or something.

Anyone?

[sarbian]

https://github.com/MuMech/MechJeb2/blob/master/MechJeb2/VesselState.cs#L304-L311

&

https://github.com/MuMech/MechJeb2/blob/master/MechJeb2/PartExtensions.cs#L15-L18

[Ezriilc]

https://github.com/MuMech/MechJeb2/blob/master/MechJeb2/VesselState.cs#L304-L311

&

https://github.com/MuMech/MechJeb2/blob/master/MechJeb2/PartExtensions.cs#L15-L18

So... you're saying that I need to figure it out for myself.

K, thanks.

[sarbian]

?

The line of code where the mass is calculated are highlighted with those link. What more do you need ?

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

[Ezriilc]

?

The line of code where the mass is calculated are highlighted with those link. What more do you need ?

I'm sorry if I'm being a bother.

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

Thanks for the tip, and that does seem to be where the difference lies. I can see by that code that some parts are ignored, but the API: Part wiki doesn't explain why that might be.

Why would some parts not have any physics? I don't get it. Again, sorry if I'm being thick.

Edited March 19, 2014 by Ezriilc

[sarbian]

There is a flag that make the Unity Physic engine to ignore some parts. They are considered weightless and don't contribute to the physic at all.

From memory struts and fuel line are the main culprits. There is a line in the part cfg that set the flag, but I don't have the game here and don't remember it. Check the struts .cfg and you should see something.

[Ezriilc]

There is a flag that make the Unity Physic engine to ignore some parts. They are considered weightless and don't contribute to the physic at all.

What I don't understand is why. I mean that I can't imagine a scenario where any part should not have any physics. That doesn't mean that I don't think there are any, just that it escapes me. I'm pretty new to this, so I assume that I'm just missing something simple.

From memory struts and fuel line are the main culprits. There is a line in the part cfg that set the flag, but I don't have the game here and don't remember it. Check the struts .cfg and you should see something.

A quick scan of 170 stock and 2 MechJeb parts returns this:

Search "PhysicsSignificance" (6 hits in 6 files)
  Parts\Utility\telescopicLadder\part.cfg (1 hit)
    Line 12: PhysicsSignificance = 1
  Parts\Utility\telescopicLadderBay\part.cfg (1 hit)
    Line 12: PhysicsSignificance = 1
  Parts\Utility\ladder1\part.cfg (1 hit)
    Line 11: PhysicsSignificance = 1
  Parts\Utility\LandingLeg1-2\part.cfg (1 hit)
    Line 16: PhysicsSignificance = 0
  Parts\Structural\strutCube\part.cfg (1 hit)
    Line 11: PhysicsSignificance = 1
  Parts\Structural\strutOcto\part.cfg (1 hit)
    Line 11: PhysicsSignificance = 1

So, does this mean that "LandingLeg1-2" is the only part that gets ignored? Either way, why would any of these parts not be considered significant?

Thanks a lot for holding my hand through this. I'm trying to do as much research as I can without pestering anyone, but I ran into a brick wall with this issue.

Edited March 19, 2014 by Ezriilc

[sarbian]

It's the other way around.

1 makes a part massless and dragless.

0 does something else but I'd need access to my computer to remind me what.

[Ezriilc]

It's the other way around.

1 makes a part massless and dragless.

0 does something else but I'd need access to my computer to remind me what.

I mean no disrespect, but are you sure?

By checking for "0", and ignoring only those parts, my results match MechJeb's mass for Kerbal X - "131.51".

By instead checking for "1" as you suggest, I get a mass of "131.79", which doesn't match any values I see coming from MechJeb or anywhere else.

Could it have been switched in a recent update? "1" for "Off" does seem counter-intuitive.

Also, I'm no expert in C# by far, but the code here suggests to me that the only possible values for PhysicsSignificance are "FULL" (1) and "NONE" (0). Am I reading that correctly?

EDIT: Yea, I'm clearly not qualified to be doing this, but I still appreciate the help! And no, I was not reading that right. derp.

If anyone knows why any parts would/should have no physics, I'd love to find out. It makes no sense to me, but at least I'm learning how to code around it.

Edited March 19, 2014 by Ezriilc

[eggrobin]

Also, I'm no expert in C# by far, but the code here suggests to me that the only possible values for PhysicsSignificance are "FULL" (1) and "NONE" (0). Am I reading that correctly?.

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.