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

[dprostock]

I am a user of this excellent Mod.
As a future correction or eventual update, it would be very interesting if the MechJeb Maneuver Planner has the option for it to perform the cutting of engines abruptly. 

Step to explain the why of the requirement: Currently the burn in its final stage is by process of decrease, which in some cases causes the instability of the vehicle and the loss of attitude of the same. I think, with an abrupt cut, which could be chosen by the user, could come to be fixed.
Thanks !!!!

[wetnose]

MechJeb2 v2.9.1.0 (latest), KSP 1.9

Translation autopilot does not work with Breaking Ground parts (controllers, electric engines, propellers). So it is not possible to use it for stabilizing helicopters. Pity.

It is planned to fix this problem?

[Craze]

On 2/21/2020 at 2:33 AM, Mudwig said:

Can anyone explain how to stop this from happening?

  Reveal hidden contents

Why would it pitch down to -29.2° when it isn't even half way to the top of the atmosphere ( and less than 20 seconds to apoapsis )? I've had no problem launching other rockets with the same settings, but with anything using multiple 1st stage boosters like Delta II or Atlas V it just goes nuts and nose-dives immediately after booster separation.

Any help would be appreciated.

You have too much speed for this altitude. Reduce the TWR of stage 1 to 1.3 at start and for stage 2, set the TWR to a minimum of 0.9 when it is turned on.

[Atlessa]

Feature request:  Stricter landing guidance, especially in atmosphere, for 'falcon style landings'.

Current behavior: Landing guidance will only perform the final landing burn, setting the booster down 'wherever it damn well pleases'.

Desired behavior: Set droneship as target, see booster landed on deck.

 

I understand this isn't easy, but if we could at least get a "desired landing distance" setting (ie 0-500m) I think it might drastically help.  Right now this module seems to think of the player target only as a "suggest landing in this vicinity", sometimes landing 2-4km off target. Would be nice if we could have a setting to tighten the accepted landing window at least by a decent amount.

 

(And if someone knows a different mod that already does this, PLEASE let me know.  And please don't say kOS... I really, really suck at scripting xD )

[Jim DiGriz]

kOS is the answer.

People keep asking for this, but the code is very difficult.  I took a run at it awhile back and got frustrated with what I wanted to do with it.  The existing code is actually very full featured, but tightly coupled to itself in ways that make it difficult to e.g. extract the ODE integrator.  If the ODE integrator and the parts simulation of the flying sim were extracted to be more self contained then the remaining actual physics sim would be vastly simpler to debug and extend.  Implementing features on top of the existing code is likely to produce a mess of spaghetti that nobody can understand.

[VoidSquid]

On 2/24/2020 at 8:48 PM, Jim DiGriz said:

ideally a multinode finite burn executor that target a list of orbits rather than a list of maneuver nodes

That sounds quite ambitious, do you think the current state of both, KSP and MJ, is a good enough and stable code base for this? Keeping my fingers crossed

From a practical standpoint, me being just a fellow KSP player who's benefiting from all the work of our countless modders, I'd prefer fixing of current issues (I'm thinking here, among other things, of the rover autopilot issue since the introduction of the scanner arms in BG) over new features.

To be clear: no offence, if it wouldn't be for you and the other fellow modders, KSP wouldn't be the game I still play and love, it's just my humble opinion.

Thanks again, and my kind regards!  

[DStaal]

6 hours ago, Atlessa said:

Feature request:  Stricter landing guidance, especially in atmosphere, for 'falcon style landings'.

Current behavior: Landing guidance will only perform the final landing burn, setting the booster down 'wherever it damn well pleases'.

Desired behavior: Set droneship as target, see booster landed on deck.

 

I understand this isn't easy, but if we could at least get a "desired landing distance" setting (ie 0-500m) I think it might drastically help.  Right now this module seems to think of the player target only as a "suggest landing in this vicinity", sometimes landing 2-4km off target. Would be nice if we could have a setting to tighten the accepted landing window at least by a decent amount.

 

(And if someone knows a different mod that already does this, PLEASE let me know.  And please don't say kOS... I really, really suck at scripting xD )

Biggest difference I've noticed on this is how much control authority you have on your ship.  During landings (unlike anytime else) MJ warps to the burn and *then* turns to the burn.  The amount of time that turn takes makes a major difference in how accurate the landing is, in my experience.

[VoidSquid]

36 minutes ago, DStaal said:

MJ warps to the burn and *then* turns to the burn

Yeah, this did cause not only one crash for me, in particular with vessels having a relatively small torque in relation to their moment of inertia. For larger vessels then, I do manual landings, better safe than sorry  

A little remedy is to disable MJ's time warping feature for such complex operations.

Interestingly, for "normal" maneuvers, you can set a time when MJ stops time warp and adjusts the vessel's attitude before executing the burn, my default here is 20s, 30-40s for larger vessels, and changing attitude manually or using stock SAS for huge vessels (for the latter, MJ simply does not even try to jaw/pitch/roll for me, no idea what's wrong here).

I still like MJ's auto landing, perfect for small to medium (probe) landers, in particular in conjunction with my laziness  

Edited February 26, 2020 by VoidSquid

[Jim DiGriz]

4 hours ago, VoidSquid said:

That sounds quite ambitious, do you think the current state of both, KSP and MJ, is a good enough and stable code base for this? Keeping my fingers crossed

From a practical standpoint, me being just a fellow KSP player who's benefiting from all the work of our countless modders, I'd prefer fixing of current issues (I'm thinking here, among other things, of the rover autopilot issue since the introduction of the scanner arms in BG) over new features.

To be clear: no offence, if it wouldn't be for you and the other fellow modders, KSP wouldn't be the game I still play and love, it's just my humble opinion.

Thanks again, and my kind regards!  

Right the problem is that MJ isn't built on particularly good foundations and I'm thinking about KSP2.

So there's a reasonably solid ODE integrator in MJ now which is approaching the functionality of Matlab's ODE45, there's now Brent's 1-d minimization and root finding algorithms, there's a pretty well debugged Gooding Lambert solver, there's alglib.net's implementation of Levenburg-Marquardt for gradient descent rootfinding in N-dimensions, there's other stuff like Shepperd's solution for orbit propagation (and sometime soon calculation of the primer vector and state transition matrix).  All of that is getting MJ on a much more solid foundation where its both more debuggable and easier to rip out large pieces of MJ in the event that KSP2 happens and hit the ground running.  Some of that is noodling on issues that don't seem important but ultimately it leads to things like being able to simplify the flying sim to be able to more accurately land rockets (and maybe doing something about the parts sim in the fuelflowsimulation as well).  So the stuff which seems pointlessly foundational can feed back into fixing bugs across the board by leveraging battle tested components (which is why I messed up Hohmann transfers which nobody really needed in order to get Brent's algorithm solidly tested).

The idea of doing a multi-node KAC-like suspendable node executor probably is something that "well maybe that is more a plan for KSP2" comes up, IDK.  Depends on when KSP2 happens or if it happens.

And the problem is that I've never used rovers, and don't think I've ever touched the rover autopilot once.  MJ is way too sprawlingly vast.  Similarly I haven't had any time to play with any of the new features.  And there's hundreds of hours of work that I'd like to get done ahead of that just to make rockets work better.  I've got some code right now which implements a quaternion-based PID controller which might be a quantum jump up in PID control and fix a lot of the issues people have with controls which cuts across the board.

Before I touched rovers/BG I'd probably look at fixing the rendezvous autopilot since there HAS to be a way to make that better and easier to use without wasting so much RCS.

In the RSS/RO world people have been bugging me a lot about mid-course corrections since often plane changes in low orbit are very suboptimal.  Could also do bi-elliptic transfers now that the maneuver planner supports multi-node planning (which is like a 4 year old user request).

[Jim DiGriz]

If you want a bit of promising developments I just found this paper:

https://arc.aiaa.org/doi/abs/10.2514/1.G004048

That has a clearest explanation of apollo descent guidance I've seen, with successively increasing levels of tweaks to make it more and more optimal, but without needing to solve a full pseudospectral convex optimization problem.  That bumps landing guidance up significantly on the list of things I might take a run at cleaning up.

Edited February 27, 2020 by Jim DiGriz

[Jim DiGriz]

Meanwhile https://ksp.sarbian.com/jenkins/job/MechJeb2-Dev/948/ should hopefully fix the transfer planner.  I'm at least able to replicate alex moon's numbers now from circular nearly-coplanar equatorial orbits to ejection.  The porkchop numbers are still high by a few dV which I have a few things I want to try to fix those.

EDIT: Well I already found one more bug.  If you see it sometimes places a maneuver node which is wildly higher dV than the porkchop prediction that is now known:

[LOG 22:27:51.687] zero miss phase before optimization = 14996932537.2083 m (763.306944838952 m/s)
[LOG 22:27:52.041] zero miss phase after optimization = 64372.1103050466 m (1153.38572748793 m/s)

[LOG 22:27:52.043] periapsis phase before optimization = -315746.987141928 m (1153.38572748793 m/s)
[LOG 22:27:52.092] periapsis phase after optimization = -11.7580441570608 m (1153.40341200134 m/s)

The m/s values should not be jumping highly like that.

That is from a 90 degree inclination, 0.80 eccentricity parking orbit, though, so hopefully most users don't hit that.  Probably know what the fix is for that one as well, but it'll take another few days.

Edited February 27, 2020 by Jim DiGriz

[VoidSquid]

Hey @Jim DiGriz, thanks a lot! You want me to test and play a bit with #948? If not, I'll wait for the version with the fix for that " wildly higher dV than the porkchop prediction", if you don't mind.

[Jim DiGriz]

7 minutes ago, VoidSquid said:

Hey @Jim DiGriz, thanks a lot! You want me to test and play a bit with #948? If not, I'll wait for the version with the fix for that " wildly higher dV than the porkchop prediction", if you don't mind.

I think you should be able to play with it and it'll work if you don't try anything too crazy.  If you do find it does weird stuff on non-crazy things that would actually be useful to know about.

[VoidSquid]

Will do and let you know if I see anything weird  

[VoidSquid]

Hey @Jim DiGriz, a pretty minor issue:

I planned a crazy transfer to Jool from a polar (89 deg. incl.) LKO and got this:

 

"you're already orbiting Jool" 

(and uppercase y, if you don't mind  )

The dv doesn't sound too unreasonable, does it?

The maneuver nodes though look weird:

But you already said that, "if you don't try anything too crazy", so I'm not that surprised. I'm wondering though, why does the porkchop give me a cumulated dv of 3800, while KSP says the 1st maneuvers already costs 5900 m/s?

Something doesn't add up here, quite literally.

Will do some more reasonable tests the other day (as time permits).

 

Edited February 27, 2020 by VoidSquid

[Jim DiGriz]

Yeah think you replicated the problem I was seeing, look in the logs for that "zero miss phase" and "periapsis phase" and look for the dv values jumping around a lot.  They shouldn't.  They almost certainly are.  Gotta lock down the optimizer more.

And the psychedelic porkchop may be accurate, I just can't visualize it very well in my head.  It does seem weird because you shouldn't be able to see individual orbits on that, and the porkchop omits interactions with minmus and the mun (and the jool moons) so nothing else should really be changing that much.  Some of the weird stabbity bits of the porkchop plots I can't quite visualize what is going on there either though and those artifacts show up in professional publications.

Edited February 28, 2020 by Jim DiGriz

[VoidSquid]

Main reason for reporting this was that the porkchop said 3800 m/s, while the transfer burn is already 5900 m/s, I didn't expect a true and good maneuver at all, but this difference was unexpected.

And yes, the log entries are there, wildly jumping, as expected

Spoiler

[LOG 21:35:06.437] zero miss phase before optimization = 117744160290.414 m (2194.09827981087 m/s)
[LOG 21:35:08.235] zero miss phase after optimization = 4055798.20578786 m (4183.97941262805 m/s)
[LOG 21:35:08.235] Transfer calculator: termination type=5
[LOG 21:35:08.235] Transfer calculator: iteration count=100
[LOG 21:35:08.241] periapsis phase before optimization = -2156963.95101045 m (4183.97941262805 m/s)
[LOG 21:35:08.398] periapsis phase after optimization = 2.8771094577387 m (4184.0856147211 m/s)
[LOG 21:35:08.398] Transfer calculator: termination type=2
[LOG 21:35:08.398] Transfer calculator: iteration count=5
[LOG 21:35:08.398] from optimizer DV = [448.266723897792, 895.263259569012, 4062.52791641213] t = 4638069.92519653 original arrival = 30902702.6839475

 

[Jim DiGriz]

Yeup that's the bug I need to fix.

[VoidSquid]

A question/suggestion: in the TWP I can set the earliest and latest possible departure dates for a transfer, can this functionality added to MJ?

I know I change that time frame by zooming in/out, but that is very eyeballing, and in particular when say a good transfer window starts in a few days already, it requires pixel-exact mouse positioning when zooming in. Plus I'd like to enter numerical values, like the maneuver planner provides (that feature actually brought me to MJ in the first place, stock functionality lacked that totally in 1.3., it's better now, but still not comparable to MJ's facilities).

Edited February 28, 2020 by VoidSquid

[Treveli]

Ok, wondering if anyone else is getting this. Just started this morning, MJ is either going on strike and not responding, or forgetting it's job half-way through a maneuver/operation.

1st instance- Launched using ascent guidance. Everything was going fine until getting around 70km, then the autopilot shuts off. No notice or warning, button changed from 'disengage autopilot' to 'engage autopilot'. The craft was still functioning, no problems with it. MJ just shut off way before reaching it's 200km target and circularizing.

2nd instance- MJ refuses to create and execute a node. Transfer maneuvers, circularzing, fine tune, not working. I put in my parameters for the node, hit  'create and execute' or 'execute next node', the node and orbital predictions appear for a literal eye blink, then are gone. 'Create node' works, but then the node vanishes when hitting an execute button. Rendezvous autopilot is also not responding, with the same 'blink' and gone as nodes.

This start just this morning. I've reverted back to 1.90 from 1.91, but still not working. I do run mod heavy, but I've been doing that with MJ for a long time, and have never seen this happening, and no other mods have been updated today. Have tried reinstalling with CKAN, no effect, will try downloading a fresh copy and doing it manually.

[VoidSquid]

I remember seeing this once long time ago, after resetting to defaults (there's a function for that in MJ somewhere in the drop menu), everything was back to normal.

[Treveli]

Try that if it happens again. Manual install of the fresh copy fixed it. 

[Jim DiGriz]

9 hours ago, VoidSquid said:

A question/suggestion: in the TWP I can set the earliest and latest possible departure dates for a transfer, can this functionality added to MJ?

I know I change that time frame by zooming in/out, but that is very eyeballing, and in particular when say a good transfer window starts in a few days already, it requires pixel-exact mouse positioning when zooming in. Plus I'd like to enter numerical values, like the maneuver planner provides (that feature actually brought me to MJ in the first place, stock functionality lacked that totally in 1.3., it's better now, but still not comparable to MJ's facilities).

Yeah I'm very dissatisfied with that as well, but UX and adding more buttons is almost harder than math to get right though since if you move things around people get confused.  Its also very cramped and squishy in the maneuver planner box (and look at everyone complaining about the size of ascent guidance on tiny screens before suggesting making it bigger).  But yeah, it needs to be better somehow.

Edited February 28, 2020 by Jim DiGriz

[VoidSquid]

Just now, Jim DiGriz said:

since if you move things around people get confused

Well, nobody said rocket science is easy  

But seriously, ordinary ignorant folks like me don't understand even the tip of the iceberg about it, but now and then we might catch a glimpse. That very moments, I wish not to be restricted by a limited UI.

Does everything have to be simplified until it's not recognizable anymore?

During my university time, I did some serious physical chemistry, mostly quantum mechanics (wave functions, partial differential equations, NMR spectra, and related crazy stuff). 

If possible, keep the stuff accessible for the ordinary person, but don't block folks who want to go more into depth from doing so.

[VoidSquid]

Did another transfer calculation,  Kerbin->Eeloo

SMA 17000000 m, eccentricity 0.96, inclination 88 deg.

Everything looks fine, from the visual porkchop window (no multiple orbits) to the nodes (2900 and 1540 m/s) to the burns KSP shows me.

I'd have expected some "weird stuff" here, but no, everything looks reasonable.

Nothing off in the log as well.

Edited February 28, 2020 by VoidSquid