[1.12.x] Anatid Robotics / MuMech - MechJeb - Autopilot - [2.14.3] [4th March 2023]

[vossiewulf]

I haven't been able to get it to work at all so far, I put my delivery vehicle in a low orbit (~7-8k over Minmus) and as mentioned above sequentially launched each K&K unit in turn. If I went through the process as suggested above to tell them to control from the HAL location they'd at least do something instead of floating in space. Unfortunately so far in every case they do a good plane change burn to line the orbit correctly, but immediately after drop their landing gear and start burning in what appears to be a straight line between where they are and the target, impacting the ground with no attempt to slow down.

As mentioned I still found the feature handy in assisting my manual landings, but if there's a way to get it to land things coherently, I'd like to know what I'm doing wrong. I'll see if I can record a video of what they're doing when I try to use them.

[Gilph]

10 hours ago, vossiewulf said:

I haven't been able to get it to work at all so far, I put my delivery vehicle in a low orbit (~7-8k over Minmus) and as mentioned above sequentially launched each K&K unit in turn. If I went through the process as suggested above to tell them to control from the HAL location they'd at least do something instead of floating in space. Unfortunately so far in every case they do a good plane change burn to line the orbit correctly, but immediately after drop their landing gear and start burning in what appears to be a straight line between where they are and the target, impacting the ground with no attempt to slow down.

As mentioned I still found the feature handy in assisting my manual landings, but if there's a way to get it to land things coherently, I'd like to know what I'm doing wrong. I'll see if I can record a video of what they're doing when I try to use them.

Try doing the same thing from a 20k orbit, not a 7k one.

[Philaphlous]

Wow...just found this. Totally new to ksp mods. I can really automate the rendezvous and docking? So I just wasted an hour of my life only to get within 20m and be all over the place of my iss...ugh. This mod is going to save my life! And time! Lol

[vossiewulf]

1 hour ago, Philaphlous said:

Wow...just found this. Totally new to ksp mods. I can really automate the rendezvous and docking? So I just wasted an hour of my life only to get within 20m and be all over the place of my iss...ugh. This mod is going to save my life! And time! Lol

Just be aware that the features of MechJeb are unlocked as you progress through the tech tree. For example the docking autopilot comes fairly late, ditto the rendezvous autopilot, but fairly early on you get access to the Maneuver Planner that has the various pieces of the rendezvous process- you just have to execute them in turn manually. Basically get near the target orbit, use the plane match maneuver to get in the same plane, then the circularize maneuver to get your orbit roundified, MJ doesn't work well with eccentric orbits. Then you do a Hohmann transfer to the target and that should put you at rest within 100m or so of your target.

[Brigadier]

1 hour ago, Philaphlous said:

Wow...just found this. Totally new to ksp mods. I can really automate the rendezvous and docking? So I just wasted an hour of my life only to get within 20m and be all over the place of my iss...ugh. This mod is going to save my life! And time! Lol

Welcome to the forums.

Adding to what @vossiewulfsaid, come back here when (not if) you have questions on how MechJeb works.  There can be a little bit of a learning curve.

[vossiewulf]

6 hours ago, Gilph said:

Try doing the same thing from a 20k orbit, not a 7k one.

You're right, that works. I just watched him land one very smoothly, about 100m from where I intended but the limited map zoom makes accurate targeting impossible, so not sure if he landed 100m off or I was 100m off or some combination. But the important part is that it worked.

That being the case, someone at least needs to code a restriction into the landing AP to reject attempts below a minimum altitude. But I'd also say to make it work like the other APs it should at least show intended burns.

Thanks for the help @Gilph at least from here out I'll be able to auto-land when I need to. Like in this case it's middle of the night at my base when I arrived with my cargo ship, I'd have had to wait for it to be daytime and adjust orbit again.

[chrisl]

I'm in the middle of an Apollo era game playing on KSP 1.2.2 with RO/RSS/RP-0 (plus all their requirements as well as FASA and a few other parts mods).  That includes Mechjeb 2.6.  For the most part, everything works exactly as I'd expect it to.  However, I seem to be having an issue with two motors.  The "AJ10-137 SPS" (specifically the FASAApollo_SM_Engine from the FASA parts pack) and the "Lunar Module Descent Engine" (specifically the FASALM_DescentEngine from the FASA parts pack).  Both engines work but the Mechjeb autopilot has an issue with them.  If I create a maneuver node that should execute minutes or even hours in the future, and then tell the Mechjeb Maneuver Planner to "Execute next node", the craft will turn to face the node as intended.  But then the engine will ignite even though the time for the node might be hours in the future.  I haven't had this issue with any of the dozens of other engines I've used in my career game.  Just these two (so far, at least).  I'm sure this isn't a problem with Mechjeb itself.  My guess is something with the engine configs for these two motors is setup wrong.  But I'm just not sure what.  I'm hoping something else may have experienced this problem and might know what is causing it.

[Loren Pechtel]

On 9/12/2017 at 11:46 AM, eklipsa said:

i try it from 200k on Kerbin, how more high ?!?!?!... is just dont work,if i do target select he dont burn, if i select land somewhere  he burn but stop when he still have 20k.

"From orbit" is your problem.  My experience with land anywhere is that if you're basically stationary it works well, if you're moving fast it's a form of suicide.  If you don't care about efficiency, simply burn to bring your orbital velocity to zero and then engage it.  If you care about efficiency lower your periapsis as low as you safely can, do your braking burn as you approach periapsis then engage it.

[Nils277]

@sarbian I have recently added some custom coded engines to the Feline Utility Rover. One user mentioned that the engines are not recignized by MechJeb though. What should i do (either as a push request for MechJeb or in the code of the engine) so that they are recognized? The engines already implement IThrustProvider as well as IEngineStatus. I have searched for these Interfaces as well as the firespitter engines in the repository but the engines do not seem to be recognized by their class name or these interfaces. Or can only engines that are derived from "ModuleEngines" be recognized in MechJeb?

Can you help me out here?    

Edited September 14, 2017 by Nils277

[sarbian]

Only engines derived from ModuleEngines are recognized. IThrustProvider provides nearly no info, so I can not use that for most of MJ logic. MJ needs thrust, fuel flow and a few other infos. Engines provided by Firespitter, RO and the likes all extends the stock ModuleEngines and thus are supported. 

I won't extends support to other module because the code change would extensive on my end. A quick look at your code makes me think you re-invented the wheel there  A lot of the stock module methods are virtual to allow you to reuse it.

10 hours ago, chrisl said:

I'm in the middle of an Apollo era game playing on KSP 1.2.2 with RO/RSS/RP-0 (plus all their requirements as well as FASA and a few other parts mods).  That includes Mechjeb 2.6.  For the most part, everything works exactly as I'd expect it to.  However, I seem to be having an issue with two motors.  The "AJ10-137 SPS" (specifically the FASAApollo_SM_Engine from the FASA parts pack) and the "Lunar Module Descent Engine" (specifically the FASALM_DescentEngine from the FASA parts pack).  Both engines work but the Mechjeb autopilot has an issue with them.  If I create a maneuver node that should execute minutes or even hours in the future, and then tell the Mechjeb Maneuver Planner to "Execute next node", the craft will turn to face the node as intended.  But then the engine will ignite even though the time for the node might be hours in the future.  I haven't had this issue with any of the dozens of other engines I've used in my career game.  Just these two (so far, at least).  I'm sure this isn't a problem with Mechjeb itself.  My guess is something with the engine configs for these two motors is setup wrong.  But I'm just not sure what.  I'm hoping something else may have experienced this problem and might know what is causing it.

Can you try the dev builds made for RO/RSS : https://ksp.sarbian.com/jenkins/job/MechJeb2-RO/

They are up to date with the regular MJ version and includes a lot of fix and new features.

[chrisl]

6 hours ago, sarbian said:

Only engines derived from ModuleEngines are recognized. IThrustProvider provides nearly no info, so I can not use that for most of MJ logic. MJ needs thrust, fuel flow and a few other infos. Engines provided by Firespitter, RO and the likes all extends the stock ModuleEngines and thus are supported. 

I won't extends support to other module because the code change would extensive on my end. A quick look at your code makes me think you re-invented the wheel there  A lot of the stock module methods are virtual to allow you to reuse it.

Can you try the dev builds made for RO/RSS : https://ksp.sarbian.com/jenkins/job/MechJeb2-RO/

They are up to date with the regular MJ version and includes a lot of fix and new features.

Thank you Sarbian.  It looks like the dev build resolved the problem I was having.

[Jim DiGriz]

On 9/8/2017 at 3:52 PM, drhay53 said:

I'm not sure if you understand the particular bug that I'm talking about, because this method is not a workaround. The issue is:

2) After reaching the target apoapsis and coasting to space, MJ creates a circularization burn that mirrors the inclination. i.e., if the inclination at launch was -6, instead of circularizing at -6, MJ circularizes to +6, doing a 12 degree inclination change along with circularization at the same time. 

@Jacke @drhay53 The circularization burn 180 degree flip was fixed here:

https://github.com/MuMech/MechJeb2/pull/898

Right now you must be on a dev build to get that fix, though.

https://github.com/MuMech/MechJeb2/pull/935

Looks like it fixed the launch *timing* bug which was completely separate from the inclination bug (and not sure if that's you @drhay53 on GitHub, if it is, thanks)

[drhay53]

2 hours ago, Jim DiGriz said:

@Jacke @drhay53 The circularization burn 180 degree flip was fixed here:

https://github.com/MuMech/MechJeb2/pull/898

Right now you must be on a dev build to get that fix, though.

https://github.com/MuMech/MechJeb2/pull/935

Looks like it fixed the launch *timing* bug which was completely separate from the inclination bug (and not sure if that's you @drhay53 on GitHub, if it is, thanks)

I used to run the dev builds but I stopped a few months ago for some reason. Thanks for sorting these out! That is me on github too.

[KSPrynk]

I didn't see this issue come up in the last few weeks of posts but it looks like manual settings/value entries aren't being retained in the Attitude Adjustment GUI when leaving the mission - either by completion or reversion.  I noticed this when updating from build #730 to build #740, then updated to #741 to be sure I hadn't missed a fix.  I've logged an issue in GitHub.

[drhay53]

To deal with the ascent guidance bugs and get the fixes, I installed the latest Dev version, #741. Rover autopilot does not seem to be setting the heading to navigate to waypoints anymore. Heading control just stays at whatever value you have it set at.

Is this a known issue, or do I need to submit logs and an issue somewhere? And if an issue is needed, where is the appropriate place to log an issue on the dev version?

edit: Perhaps it is in this PR? This seems to be where the "follow" button was renamed "drive", and they seem to be mucking about with how waypoints are selected.

https://github.com/MuMech/MechJeb2/commit/65eafbe720bfa20150ebb71594ac18fbd7d73fde

Edited September 21, 2017 by drhay53

[RuBisCO]

So been testing out 1.3.1 on windows things that are buggy with MechJeb

1. Autolanding: it can't land where you tell it to anymore, also keeps trying to warp at low altitude

2. Accent Circularizing Orbits: In accent mode when it comes time to automatically circularize the orbit it often chooses a new inclination instead of staying on the one it is on.

So far everything else seem to work properly, rover nav, landing prediction, etc.

[Mandella]

3 hours ago, RuBisCO said:

So been testing out 1.3.1 on windows things that are buggy with MechJeb

1. Autolanding: it can't land where you tell it to anymore, also keeps trying to warp at low altitude

2. Accent Circularizing Orbits: In accent mode when it comes time to automatically circularize the orbit it often chooses a new inclination instead of staying on the one it is on.

So far everything else seem to work properly, rover nav, landing prediction, etc.

For number 2 above, are you using BetterTimeWarp with Loss-less Physics turned on? I was having that issue with Mechjeb and turning off Loss-less Physics seems to have stopped it.

[Noromier]

So for the past couple of days I have been trying to figure out what exactly I am doing wrong but I just can't figure it out. When trying to dock a ship with another in orbit using MechJeb everything works fine if I dont enable force roll. However alignment is actually fairly critical for what I'm attempting to do. So when I do enable force roll to 0 the ship just keeps rocking back and forth wildly. I have tried using more/fewer or stonger/weaker rcs points as well as using more/fewer reaction wheels in various configurations. The rcs points dont seem to make a big difference but the more reaction wheels I add the worse things get. This also will occur if I use Smart A.S.S. to force roll to 0 while controlling from the docking port. Linked is a shot of the ship with CoM on so you can see how it is balanced. The tanks are setup so that no matter what resources are used the CoM will not move. I am truly at a complete loss at this point so any help would be greatly appreciated. I am also linking my log as well just in case. 

I was going to add here a List of the mods i'm using in case that would also be helpful but its rather long. If that is needed though I will be happy to post it. I am using MechJeb 2 Dev Release v2.6.1.0-741

https://imgur.com/RmF49px

https://www.dropbox.com/s/z4jv2b49g1517n6/output_log.txt?dl=0

[Argyle MHF]

22 hours ago, Noromier said:

<snip>

I have seen the same behavior under the same circumstances, and I think the issue is the frame of reference used by MJ to answer the question "what is 0 degrees?", but I am probably not articulating that well. Anyway, I've experienced this. If, for an additional data point,  you want my logs, mods, etc, I can provide them.

Unrelatedly, a while back I was inquiring about some docking issues. @Starwaster had some great advice, which left me to conclude that I'm building too big & heavy for sensible docking. But that's my thing so I persevere, no complaints. @sarbian at one point offered to including a toggle between the pre & post dev version 710 docking code. I'd like to request this toggle be added to MJ sometime when you have absolutely nothing better to do. I haven't the foggiest clue about pull-requests.

But I get this whole modding thing, so if you'd rather not, I can change my thing to be smaller construction.

Thanks.

Edited September 28, 2017 by Argyle MHF
Prepositions are useful, yo.

[mrvice]

Ksp 1.3 - Anyone else have the problem that autostage feature is not working?

[ansaman]

3 minutes ago, mrvice said:

Ksp 1.3 - Anyone else have the problem that autostage feature is not working?

Yes. I have noted this for the dev build. I don't know about any other edition.

[JonathanPerregaux]

I've noticed that for several versions now, Auto Warp requires me to initiate time warp by pressing ">" on my keyboard. Once I do this, Auto Warp kicks in and ramps the time warp factor up and down. This used to be totally automatic, to the point where I could press spacebar on the launch pad, go to the bathroom, and come back with my ship in orbit.

Some maneuvers still Auto Warp automatically (Landing Guidance, for example), but it seems that most maneuvers require me to start time warp first.

Is this change in behavior intended?

[ansaman]

Apparently, Mechjeb used to force to warp before waiting for the ship to settle to the maneuver node. Now it waits for the main program to settle down. Pressing the warp freezes all movement. If you wait, it will eventually still proceed to warp unless the craft is unbalanced.

[Brigadier]

13 minutes ago, ansaman said:

Apparently, Mechjeb used to force to warp before waiting for the ship to settle to the maneuver node. Now it waits for the main program to settle down. Pressing the warp freezes all movement. If you wait, it will eventually still proceed to warp unless the craft is unbalanced.

While that was true for me a while ago, that's not been my recent experience.  I agree with @JonathanPerregaux - despite my vessel orienting correctly to the maneuver node, it sometimes won't warp when, in the past, it used to.  I, too, have to press '>' and then '<' to convince it to go.  It's not a big deal for me but the behaviour seems to have changed for some reason.  And, it's not consistent for me; sometimes the warp-to-node feature works as before.

[funkcanna]

Hi, when I try to create a node (in this case its an advanced transfer) It says "error creating node".  the logs show this:

 

[EXC 13:59:09.953] NullReferenceException: Object reference not set to an instance of an object
    Targeting+Sample.Borrow (.Conic o1, .Conic o2, Double v)
    Targeting+Interval.find_region_edge (.Conic orbit1, .Conic orbit2, Double v1, Double v2)
    Targeting.check_void_transition (.PairOfIntervals intervals, .Sample prev, .Sample samp, .Sample ival_start)
    Targeting.sample_orbits (.Conic orbit1, .Conic orbit2, Int32 count)
    Targeting.Intercepts (.Conic orbit1, .Conic orbit2, Int32 samples)
    Orbit._FindClosestPoints (.Orbit p, .Orbit s, System.Double& CD, System.Double& CCD, System.Double& FFp, System.Double& Darn it, System.Double& SFp, System.Double& SFs, Double epsilon, Int32 maxIterations, System.Int32& iterationCount)
    PatchedConics._CheckEncounter (.Orbit p, .Orbit nextPatch, Double startEpoch, .OrbitDriver sec, .CelestialBody targetBody, .SolverParameters pars)
    PatchedConics._CalculatePatch (.Orbit p, .Orbit nextPatch, Double startEpoch, .SolverParameters pars, .CelestialBody targetBody)
    MuMech.TransferCalculator.DistanceToTarget (System.Double[] x, System.Double[] fi, System.Object obj)
    alglib.minlmoptimize (.minlmstate state, .ndimensional_fvec fvec, .ndimensional_rep rep, System.Object obj)
    MuMech.TransferCalculator.OptimizeEjection (MuMech.ManeuverParameters original_maneuver, .Orbit initial_orbit, .Orbit target, Double UT_arrival, Double earliest_UT)
    MuMech.OperationAdvancedTransfer.MakeNodeImpl (.Orbit o, Double UT, MuMech.MechJebModuleTargetController target)
    MuMech.Operation.MakeNode (.Orbit o, Double universalTime, MuMech.MechJebModuleTargetController target)
    UnityEngine.Debug:LogException(Exception)
    MuMech.Operation:MakeNode(Orbit, Double, MechJebModuleTargetController)
    MuMech.MechJebModuleManeuverPlanner:WindowGUI(Int32)
    MuMech.DisplayModule:ProfiledWindowGUI(Int32)
    UnityEngine.GUI:CallWindowD