Jump to content

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


r4m0n

Recommended Posts

I just tested with jmanidb example. Copied it in a landing.cfg in GameData\MechJeb2 and I have the landing site on the landing guidance windows.

Oh, I´m so sorry.

The feature is that they appear in the landing guidance window. That is working fine.

I thought that the runways are added to the spaceplane guidance for landing.

Link to comment
Share on other sites

RCS units that are destroyed in flight seem to result in nullref errors in the RCS balancer later:


KWrcsQuad Exploded!! - blast awesomeness: 0.5

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)


[KWrcsQuad]: Deactivated

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)


MechJeb module MechJebModuleRCSBalancer threw an exception in OnUpdate: System.NullReferenceException:


at (wrapper managed-to-native) UnityEngine.ParticleEmitter:set_maxSize (single)


at FXGroup.SetPower (Single pwr) [0x00000] in <filename unknown>:0


at FXGroup.set_Power (Single value) [0x00000] in <filename unknown>:0


at MuMech.MechJebModuleRCSBalancer.OnUpdate () [0x00000] in <filename unknown>:0


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

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)


1 explosions created.

Shortly after, the world went black, gone, vanished, navball disappears, void, anguish, etc. Could be total coincidence, not sure. <---- (could also be an issue in Deadly Reentry which also threw some errors, though they were pretty benign, but I'll be looking at that as well since DRE is my responsibility now and the error was linked to new code)

Link to comment
Share on other sites

I just tested with jmanidb example. Copied it in a landing.cfg in GameData\MechJeb2 and I have the landing site on the landing guidance windows.

sarbian thanks for all your kindness and patience with this. After some tests with jmanidb example, plug is running as it should. I think I found out what my problem was. On github the first line of the example file is

MechJeb2

and I used this.

jmanidb example file has in its first line

MechJeb2Landing

and with this its working for me now. Could this be possible or am I only too tired.

Link to comment
Share on other sites

Bug report: MechJeb is reading incorrect values for thrust from engines that have <100% values for the throttle limiter tweakable and a non-zero minThrust value in their engine config. This doesn't matter in many cases, as almost all engines have minThrust = 0, and the throttle limiter tweakable isn't used all that often. However, KW Rocketry solid boosters are an easy way to experience this bug- they have a minThrust of half of their maxThrust, and tweaking the throttle limiter lets you adjust the thrust of otherwise uncontrollable SRBs.

79op7HN.png?1

This Globe X-10L "Thor II" SRB from KW Rocketry had the throttle limiter tweaked to 15% (0.15). It has a maxThrust of 3015 kN and minThrust of 1507.5 kN. The thrust according to MechJeb is maxThrust*throttleLimiter = 3015*0.15 = 452 kN. The actual thrust is minThrust + (maxThrust - minThrust)*throttleLimiter = 1507.5 + (3015 - 1507.5)*0.15 = 1733.6 kN.

If the throttle limiter is pulled all the way down to 0%, MechJeb will believe that this engine cannot produce thrust, despite it actually still producing 50% thrust at 0% throttle limiter.

This testing was done with the latest dev build of MechJeb (#343).

Link to comment
Share on other sites

Hey can someone tell me what data mechjeb uses to launch into the plane of a target? I'm trying to make a custom window so that I can do it manually but I'm not sure what data I should be looking at. Should be the target's longitude of the ascending node right?

I'm looking at this diagram and I'm guessing that the "Target LAN" field uses the direction from the center of the body you're on to your position over that body as the reference direction? I'm guessing I need to launch when "Target LAN" says either 0 or 180. Am I on the right track or do I have this totally wrong?

Orbit1.svg

edit: I know that AN and DN work for bodies within the same SOI but they don't work when you're trying to launch into the plane of another planet. The autopilot seems to handle it just fine though so I'm wondering what data it's going off of.

edit 2: Okay well I'm still not sure what the reference direction is but after messing around for a bit it seems that my craft always crosses the target's plane when LAN = targetLAN +/- 90deg. Not sure but it looks like the reference direction for a planetary SOI is the parent planet's prograde direction on its orbit?

Edited by The Pink Ranger
Link to comment
Share on other sites

ArcFurnace : should be fixed in last dev. Thanks for the detailed report. Hopefully I did not break anything :P

Mekan1k : there is a whole window for that already (Attitude Adjustment). Do you use FAR ? If so do you use the optional module ?

I m a bit busy IRL atm, so don't expect much for now.

Edited by sarbian
Link to comment
Share on other sites

Hello, I have a problem. Mechjeb UI does not show any text (links and buttons are clickable). Am I missing some specific fonts or sth?

KSP.log does not indicated any related issues. Image:

snapshot1.png

KSP 0.25, Mechjeb 2.4.0 (no other mods), Fedora Linux x86_64, integrated Intel HD Graphics 4400 (my work laptop :P)

Any idea what would be the reason?

I know that out of better ideas you will start with "your gfx card is too slow" and truth is on my other PC (Gentoo x86_64, Nvidia 570) KSP works perfectly with Mechjeb.

But vanilla KSP alone works pretty well and without technical issues on that laptop so I would expect nothing else from Mechjeb being "merely" A.I a mod.

Link to comment
Share on other sites

I'm trying to figure out why MechJeb consistently overcorrects roll and yaw on my aircraft (stock KSP aero). Yaw tends to stay fairly OK, but roll grows from perfectly OK on takeoff to +/- 30 degrees by 5km, sometimes earlier. It doesn't get worse than that, and by 15km the problem resolves itself, but that still means I'm doing S turns through the lower atmosphere.

I'm highly suspicious of this code: https://github.com/MuMech/MechJeb2/blob/dev/MechJeb2/VesselState.cs#L455

// TODO : Tweakable for ignorePitch / ignoreYaw  / ignoreRoll 
ModuleControlSurface cs = (pm as ModuleControlSurface);
Vector3d partPosition = p.Rigidbody.worldCenterOfMass - CoM;

Vector3d airSpeed = vessel.srf_velocity + Vector3.Cross(cs.part.Rigidbody.angularVelocity, cs.transform.position - cs.part.Rigidbody.position);

Quaternion airSpeedRot = Quaternion.AngleAxis(cs.ctrlSurfaceRange * cs.ctrlSurfaceArea, cs.transform.rotation * Vector3.right);

Vector3 ctrlTroquePos = vessel.GetTransform().InverseTransformDirection(Vector3.Cross(partPosition, cs.getLiftVector(airSpeedRot * airSpeed)));
Vector3 ctrlTroqueNeg = vessel.GetTransform().InverseTransformDirection(Vector3.Cross(partPosition, cs.getLiftVector(Quaternion.Inverse(airSpeedRot) * airSpeed)));
ctrlTorqueAvailable.Add(ctrlTroquePos);
ctrlTorqueAvailable.Add(ctrlTroqueNeg);

First off, that TODO is an issue with my planes: every single one of my control surfaces is limited.

Secondly, the "ctrlTroquePos" that's calculated implicitly is assuming that the control surface produces no lift if there's no control input. Not true unless you're flying at zero angle of attack.

Thirdly, adding together the ctrlTorquePos and ctrlTorqueNeg is going to do particularly funny things.

At zero angle of attack, the + vector is mostly up and a bit forward, the - vector is mostly down and a bit forward. Adding them together gets you a vector that's perfectly zero in the direction you're controlling, but twice as long in the forward direction. In other words, MechJeb is assuming that the rudder of a plane flying perfectly straight can produce pitch (because it's above the center of mass) but neither yaw nor roll (because those are canceled out when you calculate all + and all - input and add them together). Similarly, elevators and ailerons are predicted to produce yaw but neither pitch nor roll.

Seems like there's many more than one thing that needs to be calculated:

(1) the forces acting on this part with no control input

(2) the forces acting on this part with a pitch=1 control input

(3) the forces acting on this part with a pitch=-1 control input

(4) ... +/-yaw, +/-roll

Then we can maybe interpolate.

I remember trying to figure out what the @#$ was wrong with the controller a year ago, and finding the code that the calculated ctrlTorqueAvailable to be 192% inscrutable, so even if I fixed the calculation, I couldn't fix the controller.

Link to comment
Share on other sites

reavertm : yes, that may be font related. Have a look at the Linux thread to see the common linux problem. If it's not that then you'll have to post a log (see there to find it.

First off, that TODO is an issue with my planes: every single one of my control surfaces is limited.

I'm glad that you offer to fix it then

Secondly, the "ctrlTroquePos" that's calculated implicitly is assuming that the control surface produces no lift if there's no control input. Not true unless you're flying at zero angle of attack.

Yes, it is a problem but not one as easily solved as you think

Thirdly, adding together the ctrlTorquePos and ctrlTorqueNeg is going to do particularly funny things.

At zero angle of attack, the + vector is mostly up and a bit forward, the - vector is mostly down and a bit forward. Adding them together gets you a vector that's perfectly zero in the direction you're controlling, but twice as long in the forward direction. In other words, MechJeb is assuming that the rudder of a plane flying perfectly straight can produce pitch (because it's above the center of mass) but neither yaw nor roll (because those are canceled out when you calculate all + and all - input and add them together). Similarly, elevators and ailerons are predicted to produce yaw but neither pitch nor roll.

You may want to look at ctrlTorqueAvailable type before saying that.

Seems like there's many more than one thing that needs to be calculated:

(1) the forces acting on this part with no control input

(2) the forces acting on this part with a pitch=1 control input

(3) the forces acting on this part with a pitch=-1 control input

(4) ... +/-yaw, +/-roll

Then we can maybe interpolate.

I remember trying to figure out what the @#$ was wrong with the controller a year ago, and finding the code that the calculated ctrlTorqueAvailable to be 192% inscrutable, so even if I fixed the calculation, I couldn't fix the controller.

Sorry for writing inscrutable code. I'll wait for your glorious fix.

I m tired of people complaining but never doing much more. Most of those who complain about their plane stability don't post their craft. How am I supposed to fix anything out of thin air ? Have a look at Mekan1k post and see how you can make MJ work better.

Edit : I can't even swear anymore. I may have to switch to French.

Link to comment
Share on other sites

French really is such a beautiful language when used to cuss. I strongly encourage you to make it so!

"I love French wine, like I love the French language. I have sampled every language, French is my favorite. Fantastic language. Especially to curse with. Espèce de loup-garou à la graisse de renoncule de mille sabords. It's like wiping your behind with silk. I love it. "

Edited by NathanKell
Replaced profanity with Haddock
Link to comment
Share on other sites

I m tired of people complaining but never doing much more. Most of those who complain about their plane stability don't post their craft. How am I supposed to fix anything out of thin air ? Have a look at Mekan1k post and see how you can make MJ work better.

I may not speak for everyone, but I'd just like to say that I for one greatly appreciate the work that you and all the other contributers have done for MechJeb. I wouldn't be able to enjoy KSP nearly as much as I do right now without MJ.

So again, thank you. :)

Link to comment
Share on other sites

ArcFurnace : should be fixed in last dev. Thanks for the detailed report. Hopefully I did not break anything :P

Seems to be working just fine. Thanks for the quick fix! I don't quite feel up to fixing these sorts of things myself, so the least I can do is make your life as easy as possible ;)

Link to comment
Share on other sites

ArcFurnace : should be fixed in last dev. Thanks for the detailed report. Hopefully I did not break anything :P

Mekan1k : there is a whole window for that already (Attitude Adjustment). Do you use FAR ? If so do you use the optional module ?

I m a bit busy IRL atm, so don't expect much for now.

I use NEAR, with the optional Module. I try not to use NEAR, but this problem occurs with almost every craft.

I'm trying to figure out why MechJeb consistently overcorrects roll and yaw on my aircraft (stock KSP aero). Yaw tends to stay fairly OK, but roll grows from perfectly OK on takeoff to +/- 30 degrees by 5km, sometimes earlier. It doesn't get worse than that, and by 15km the problem resolves itself, but that still means I'm doing S turns through the lower atmosphere.

I'm highly suspicious of this code: https://github.com/MuMech/MechJeb2/blob/dev/MechJeb2/VesselState.cs#L455

// TODO : Tweakable for ignorePitch / ignoreYaw  / ignoreRoll 
ModuleControlSurface cs = (pm as ModuleControlSurface);
Vector3d partPosition = p.Rigidbody.worldCenterOfMass - CoM;

Vector3d airSpeed = vessel.srf_velocity + Vector3.Cross(cs.part.Rigidbody.angularVelocity, cs.transform.position - cs.part.Rigidbody.position);

Quaternion airSpeedRot = Quaternion.AngleAxis(cs.ctrlSurfaceRange * cs.ctrlSurfaceArea, cs.transform.rotation * Vector3.right);

Vector3 ctrlTroquePos = vessel.GetTransform().InverseTransformDirection(Vector3.Cross(partPosition, cs.getLiftVector(airSpeedRot * airSpeed)));
Vector3 ctrlTroqueNeg = vessel.GetTransform().InverseTransformDirection(Vector3.Cross(partPosition, cs.getLiftVector(Quaternion.Inverse(airSpeedRot) * airSpeed)));
ctrlTorqueAvailable.Add(ctrlTroquePos);
ctrlTorqueAvailable.Add(ctrlTroqueNeg);

First off, that TODO is an issue with my planes: every single one of my control surfaces is limited.

Secondly, the "ctrlTroquePos" that's calculated implicitly is assuming that the control surface produces no lift if there's no control input. Not true unless you're flying at zero angle of attack.

Thirdly, adding together the ctrlTorquePos and ctrlTorqueNeg is going to do particularly funny things.

At zero angle of attack, the + vector is mostly up and a bit forward, the - vector is mostly down and a bit forward. Adding them together gets you a vector that's perfectly zero in the direction you're controlling, but twice as long in the forward direction. In other words, MechJeb is assuming that the rudder of a plane flying perfectly straight can produce pitch (because it's above the center of mass) but neither yaw nor roll (because those are canceled out when you calculate all + and all - input and add them together). Similarly, elevators and ailerons are predicted to produce yaw but neither pitch nor roll.

Seems like there's many more than one thing that needs to be calculated:

(1) the forces acting on this part with no control input

(2) the forces acting on this part with a pitch=1 control input

(3) the forces acting on this part with a pitch=-1 control input

(4) ... +/-yaw, +/-roll

Then we can maybe interpolate.

I remember trying to figure out what the @#$ was wrong with the controller a year ago, and finding the code that the calculated ctrlTorqueAvailable to be 192% inscrutable, so even if I fixed the calculation, I couldn't fix the controller.

I want to see this applied- just so I can yell GENIUS at the top of my lungs.

reavertm : yes, that may be font related. Have a look at the Linux thread to see the common linux problem. If it's not that then you'll have to post a log (see there to find it.

I'm glad that you offer to fix it then

Yes, it is a problem but not one as easily solved as you think

You may want to look at ctrlTorqueAvailable type before saying that.

Sorry for writing inscrutable code. I'll wait for your glorious fix.

I m tired of people complaining but never doing much more. Most of those who complain about their plane stability don't post their craft. How am I supposed to fix anything out of thin air ? Have a look at Mekan1k post and see how you can make MJ work better.

Edit : I can't even swear anymore. I may have to switch to French.

Thanks Sarbian!

Link to comment
Share on other sites

I just tested with jmanidb example. Copied it in a landing.cfg in GameData\MechJeb2 and I have the landing site on the landing guidance windows.

When I moved landingsites.cfg into the MechJeb2 folder and renamed it to "landing.cfg" as you said you have, I was able to get it working.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...