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

[Virtualgenius]

Thats very interesting codepoet on explaining how MJ lands is it possible to tighten the variables perhaps or not that simple, generally I am trying to setup a base and I usually want my dwelling no further apart than 25m. I usually eva a kerbal move him to a position then target him, in previous versions I have always landed 5 to 10m away and sometimes right on top.

[BARCLONE]

A follow-up to my last post...

I was watching the screen during one rendezvous, and saw the time warp indicator (upper left corner) flicker the second arrow briefly, but repeatedly, even though the ship was supposed to be at only time warp 1. Something is tickling the warp when it shouldn't...

[sarbian]

I'm experiencing a lot of nav ball target reticle jittering as a burn reaches the end,[...]

Any ideas?

Stock does it too afaik. I can't do anything about it.

[HoneyFox]

Stock does it too afaik. I can't do anything about it.

Perhaps you can make it automatically switch to KillRot mode when the delta V is smaller than a certain threshold (a bit bigger than the threshold that judge the completion of a maneuver), then use RCS thrusters to do the last bit of tuning.

Of course such procedure would be better to have a switch so users can decide whether they want this or not.

Edited January 15, 2014 by HoneyFox

[Bobe]

Hmm. I must be doing something wrong. A lot of people are talking about how freakishly accurate the landing autopilot is, that they have to deliberately create some offset, or take manual control, in order to avoid landing right on top of the flag or object that they've targeted for landing. The only thing I have to do to avoid landing on a specific spot or object is to target that spot and select 'land at target'.

MechJeb has NEVER landed me closer than 30 meters from the target, and on the few occasions when it did get that close I'm pretty sure it was an accident. When I'm in orbit and select 'land at target', MJ does the de-orbit burn, but stops trying to make corrections as soon as the predicted landing site is within 150 meters of the target, and it generally doesn't even attempt to make any corrections at all after that unless the prediction gets farther away than 500 meters or so.

This isn't really a big deal to me, I don't mind taking manual control if necessary, it's just annoying to see you guys talking about being able to have MJ land your ship right on the VAB helipad or on the launch pad without any trouble, that's all.

Anyway, my $0.02. Later.

Strange. The only issues I've had with the landing guidance is it sometimes forgetting to perform the braking burn. Typically this is my error, as I may have forgotten to install batteries or something, but on a few occasions it has simply failed inexplicably. However, ignoring those instances, all my landing have been within 1-2 m of my target, regardless of the size, and I actually haven't experienced that issue since.

I had a Mk1 lander touch down next to a rover I had waiting and it was so precise (or rather fractionally imprecise) that it nestled up snugly against the rover with its legs either side of it. It was an... intimate encounter. Recently I set up a kethane operation with three heavy landers of between 40 and 45 tons each, all landing directly on their target flags. I will say that all these landings were in a vacuum, my few landings on Duna (I'll ignore the horrific crash on Eve, my bad) were successful but I haven't tried to land at a target. I'm so obsessed with setting up this kethane resupply system that my other endeavours are on the back burner.

[sarbian]

On thing is important to mention when you talk about the landing AP (and any other problem with MJ) : do you use the official release or the dev version (and it's release number). The landing AP had some big change since the last official.

Later Today or tomorrow I'll release the RCS / Docking AP I worked on for the last 2 night and we will see how it goes. It was working fine late yesterday but I need to fix something I broke in the AP logic.

I amazed how hard it is to have the RCS controller do precise burn. It should be easy and yet I had to add damping just so it don't wobble all around while trying to maintain a set speed.

I should check again how the RCS available thrust is computed, that may be the root of my problem. I am sure the guy who added it did not know how to do it properly

[diomedea]

I am sure the guy who added it did not know how to do it properly

I am sure that same guy (hint who he is! ) now knows much better, and not only about that feature.

[sarbian]

I hope he does, it was his first contribution to MJ and it was sooooo long ago

[codepoet]

You and me both...

And to answer Codepoets's questions;

...

The answer is "yes". I've tried a variety of scenarios, and I find it impossible to predict when MJ will land right on target, and when it will land somewhere completely unrelated.

OK, well if you would like to offer up a paricular scenario that someone interested working on the code will be able to reproduce and maybe improve then please do so - it would be useful to have a save file, or craft file with full instructions and a landing location on a particular body, from a particular starting orbit. Unfortunately saying "it does not work in a variety of scenarios" is not going to give anyone much to work with and is unlikely to motivate anyone to want to do any dev work on that area.

I can offer some advice though related to the code I have worked on (ie parachutes):

1) You will probably get better results if you have more than one parachute on your craft (particularly a drogue and a non-drouge) and use tweakables to set the full deploy height for each one be different so then each open at different times. That way the auto pilot will have more oppertunites to correct for errors by changing when it plans to open the parachutes.

2) You will get the best results with the parachutes depending on the pitch angle of the velocity vector at the time that the parachute(s) are deployed. That might take a little thinking to work our that that means - basically how much you are going down against how much you are going sideways. If you are going straight down before the parachutes open (low altitude eve) then it does not matter much when they open you will always land in the same place. However if you are going almost horizontal when you deploy the parachutes (ie high altitude Duna) a small change in the ground height can make a big difference to when the parachutes are fully deployed and hence the landing location. Somewhere in between these two extremes is a peak of optimum accurarcy. (ie Kerbin).

I hope this is helpful or at least interesting. Sorry that I am not offering to make it work better, but it works fine for my own gameplay, and that is what motivates me. However if you can provide a detailed scenario where it is failing I will gladly take a look.

[BARCLONE]

Stock does it too afaik. I can't do anything about it.

Both stock and the "enhanced" mod are affected. Rats!

Perhaps you can make it automatically switch to KillRot mode when the delta V is smaller than a certain threshold (a bit bigger than the threshold that judge the completion of a maneuver), then use RCS thrusters to do the last bit of tuning.

Of course such procedure would be better to have a switch so users can decide whether they want this or not.

That's something I was wondering about -- using the RCS (if available) when the Dv required gets below a certain (user-settable?) value. Using the main engine seems to be over-kill for some of these burns, and depending on the engine, it has to be "pulsed" rapidly to keep from over-burning.

[Starwaster]

Sarbian, I was looking at the docking AP code to see about tweaking how the rate at which the AP approaches the docking axis. Really to change the ratio between lateralVelocityNeeded and zVelocityNeeded. Doesn't seem that hard to do but something else caught my eye which was zSep and lateralSep.magnitude. You're comparing the two in places in the code even though they're dissimilar things. The code still works (until you get very VERY close to the dock) because reducing lateral separation brings zSep within the range that it expects in order to be able to advance forward. But the earlier comparison is to check if zSep is less than lateralSep even though zSep actually has to be high (being the dot product between two vectors) in order to be considered close to the docking axis. That's why it tends to follow a diagonal course to the dock and why on a few occasions it gets hung up very close to the dock but offset by a few tenths of meters. (it probably could let go at that point and magnetic attraction take over but it's still stuck in approach mode)

Edit: There's a few places in there where it seems like it's expecting that zSep is the distance to the dock (along the axis) but because it's a dot product its range will always be -1 to 1. (though for our purposes, when in front of the dock it's really going to be 0 to 1)

Edited January 15, 2014 by Starwaster

[sarbian]

Dot product are in the -1 to 1 range only for the dot of 2 normalized vector. Here zAxis is normalized but separation is not, so zSep is actually the distance.

Anyway I am rewriting all that right now

[Damaske]

Is there a known problem with RAIPER engines and mechjebs vertical landing? I've been attempting to land a ship that has 2 basic jet engines (off at time of landing) and two RAIPER engines. I run the RAIPER in air-breather mode and i end up slamming into the ground. Is there an setting that you can set the RAIPER's max output, to its lowest (at ground level) ISP (or whatever it is) so Mechjeb is forced to brake much earlier. I feel that if you set the lowest thrust as the max it can do it will burn a much better braking burn.

If needed I can submit the craft i am using to help improve testing and getting the RAIPER engines landing fine tuned.

[sarbian]

MJ will have trouble landing anything running on air-breather. They are too slow to change regime.

[Damaske]

I've heard that the RAIPER has no spool up time or is that only the close cycle mode? Also I am using the latest dev build #167.

[Starwaster]

Dot product are in the -1 to 1 range only for the dot of 2 normalized vector. Here zAxis is normalized but separation is not, so zSep is actually the distance.

Anyway I am rewriting all that right now

You sure about that? I've never seen a dot product out of that range before.

Maybe it's because I'm used to normalizing everything though but that sounds odd

[sarbian]

I've heard that the RAIPER has no spool up time or is that only the close cycle mode? Also I am using the latest dev build #167.

The AirBreathing config of the RAPIER has those value, so it has spool up time :

useEngineResponseTime = True

engineAccelerationSpeed = 0.2

engineDecelerationSpeed = 0.35

Starwaster : the definition of the dot product is the product of both vector magnitude multiplied by the cos of the angle between them, so it can indeed go beyond 1.

Edited January 15, 2014 by sarbian

[Damaske]

The AirBreathing config of the RAPIER has those value, so it has spool up time :

useEngineResponseTime = True

engineAccelerationSpeed = 0.2

engineDecelerationSpeed = 0.35

.

ok, so make sure its in closed cycle before landing got it.

still crashed and burned in closed cycle on the VAB setting, plus with drogue parachute it missed the building completely.

Edited January 16, 2014 by Damaske

[Galane]

It doesn't open parachutes in more than a single stage.

I took this craft, removed the launcher, the rovers, the two side mounted cockpits/pods - everything but the Eve lander part. Then I removed the chair and the tank and engine it was sitting on, replaced with a MK1 pod with a docking port and a couple of ox stat panels. Topped off with an OKTO2 on top of the port so it could fly unmanned.

During landing MechJeb only popped the two MK25 chutes, and it waited to do the suicide burn until the landing gear was almost touching the ground, still descending at over 20 m/sec. I lowered the gear manually earlier, so I don't know if it would also have failed to lower it soon enough.

I had TAC fuel balancer running because during the deorbit burns it was draining pretty fast from the tanks that would drop first during ascent from Eve. Wouldn't work too well to have part of the ship fall off too soon.

It's supposedly a craft capable of landing on Eve with quite a bit more weight on it, and returning part of it to Eve orbit to dock with a Kerbin return vehicle. Manual flying instructions are included. As-built, to get MechJeb to properly handle the launch requires setting control to the OKTO2 under the chair on top.

I'll try it again, with all the chutes put into one stage. Might also try it with the chutes removed. If that works then I'll test with a 2 man can. If that works then I'll know what sort of fuel and engine power I need. This lander is too spread out and spindly, some reconfiguring to make it bundled tighter should work with my Eve mission plan.

[royying]

new version MJ don't show landing guidance blue marker when the predicted location is on the water

but pointing the predicted site on water is useful for me

I hope this feature will return in future version

[sojourner]

new version MJ don't show landing guidance blue marker when the predicted location is on the water

but pointing the predicted site on water is useful for me

I hope this feature will return in future version

That's due to the way KSP handles water now. The marker is under the water being drawn on the surface of the planet.

[Starwaster]

A couple of bugs to report in the latest dev (build 167) version. Or they might have started in an earlier version but I've been busy with Copernicus modeling so I haven't really noticed until I needed to dock these big ass parts.

After undocking (or possibly undocking then switching between the two craft with []) one or more of the two become uncontrollable by MJ2 (SmartASS, maneuver nodes or docking AP or anything where it needs to adjust attitude)

There's no errors in the output_log.txt during that time other than the ones informing me that there is 'no icon for X' (in a rather accusatory tone I might add, yes, I KNOW MJ2! I have to download them)

However in the attitude control panel I see -Infinity for the PID settings (Kp, Kd, Ki) and Tf setting autotunes to a value that is abnormal compared to what it usually sets for that particular craft. For instance, a very large craft (several hundred mt) might have a Tf assigned of 0.4 or a small craft might have one assigned of 1. Sometimes toggling RCS balancing a couple of times clears it but generally I have to exit to Space Port so that both craft unload.

I don't see this happen except for craft that I have recently undocked.

[Damaske]

I have been noticing a recent roll to one side on my rockets under ascent autopilot, And I've also noticed that Mechjeb does NOT control the ships roll at all. I feel that there need to be a lock to keep the roll locked in a certain potion, ( user selectable) so your able to keep the wings level to help provide lift during space plane ascents.

I've had space planes roll 90 degrees from wing level and then spin out of control due to mechjeb not keeping the wings level. Is there something that can be done aboot this or is it a "stock" issue and unfixable without many headaches and code cracking?

[MOARdV]

I don't see this happen except for craft that I have recently undocked.

I think this is a "feature" introduced in KSP 0.23 (not in MJ) where the command pod doesn't get reassigned after undocking. I think right-clicking on the command pod and pressing "Control from Here" fixed it.

[Starwaster]

I think this is a "feature" introduced in KSP 0.23 (not in MJ) where the command pod doesn't get reassigned after undocking. I think right-clicking on the command pod and pressing "Control from Here" fixed it.

Wow really? That sucks if that's what it is. I wonder what programmatic solutions are possible.... i.e. assigning one in the code if the attitude controller could detect that such a condition exists. But then there would be the question of where to control from? The most obvious choice would be the docking port that was previously docked. Or the root part if it's eligible. (usually is but you can't take that for granted)