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

[smjjames]

Hm, I'm seeing something that might be part of the puzzle of why landing AP isn't working so well.

Yes I know I'm trying to land a stock spaceplane, but that has nothing to do with what I'm seeing. The trajectory is supposed to start at atmosphere entry, right? So, how come it's starting seconds away from my ships current location up around 195km? This is why I was confused about the trajectory because it appeared to be indicating atmospheric entry but it's starting well above the atmosphere.

Also, to answer my earlier question, it's trying to land like a regular lander XD The regular landing AP anyway, not spaceplane guidance.

[futrtrubl]

In latest dev builds "Limit to terminal velocity" is mostly fixed. At least, it does not try to limit to some funny speeds like 95m/s. But one annoying behavior remains.

When I start the gravity turn, drag of the vehicle increases, so MJ turns the engine off. This is understandable, but on vehicle with small lift it means that I will turn much slower than possible, and the speed drops considerably.

I understand that it is hard to decide what to count as a "terminal velocity" at high angles of attack. May be you should implement a feature in Accent Guidance to temporary disable "Limit to TV" on early stages of gravity turn?

How high an angle of attack are you doing at the start of your gravity turn?

[WissNX01]

I haven't quite gotten used to the new areo effects, but it would be nice if certain values of the ascent path editor were selectable, like the turn start velocity. Anyway, good work on this as always.

[smjjames]

I haven't quite gotten used to the new areo effects, but it would be nice if certain values of the ascent path editor were selectable, like the turn start velocity. Anyway, good work on this as always.

You can if you unselect automatic altitude turn. I've made that mistake before with not realzing that feature.

[khearn]

I mean, a feature that calculates optimal trajectory for a rocket standing on the ground to reach a desired point on the surface of the same body. Would be very cool for:

1. Missions to "measure a temperature flying above 18000m above ..."

2. Make a lander to jump to other points of the moon instead of using rovers.

Ideally it could look like landing gudance UI: you just select a desired point on a map or enter coordinates, and whoosh! May be there can be options to minimize dV or to have apoapsis no lower than X km.

Effectively it is a combination of accent guidance and landing guidance. At least, as I understand, it could massively reuse algorithms from both. For example, landing guidance already can calculate a landing point with consideration for planet rotation, and accent in a right direction would be the same gravity turn, you just have to end it much earlier than during orbital accent.

I've thought of this, too. I just didn't ever get around to asking for it. This would be really useful for lots of contracts, both on the Mun/Minmus, and on Kerbin. It's obviously not as high priority as getting things working with the new aero model of course, but it would be really nice to have later on.

Thanks again for all the work you put into this, sarbian. It really makes the game a lot better.

Keith

[smjjames]

Question Sarbian, are you able to use a quicksave if I upload just the quicksave or do I have to upload the whole file?

[sarbian]

a quick save is just a save with a different name, anything works

[smjjames]

Okay cool.

Here's my Pol testing.

Ship: http://sta.sh/0z1b3yt4bmq (pure stock. It's just a lander, so you'll have to use hyperedit or build a launcher. The ship is already in orbit around Pol in the save.)

quicksave plus output log: http://sta.sh/010z4aw3xrqe

Landing coordinates in case MJ forgets them: 4 45 53 N 161 8 38 W

Turn on RCS and small manuevers using RCS.

Attempt 1:

The initial burn down was okay, but then it seemed to keep correcting for like over 10 minutes, seemed to have trouble keeping up with Pols rotation or something.

The period after that until about 700m were fine.

When it got to around 700 meters and after it finished killing horizontial velocity, it started doing the somersault thing and got stuck in that loop until around 150m since I decided to just let it do it's thing. I tried turning off the gimbal and it didn't help. May have something to do with me using the mainsail, which is OP for Pol.

From 150m onwards, it landed normally. Although it didn't extend landing gear for some reason even though I had it on, maybe because I toggled it earlier.

Attempt 2:

MUCH better than the first attempt, went normally until about 700m when it started doing the somersault again. At around 500 something, I aborted the AP and restarted it in an attempt to reboot it, which only resulted in it spamming an exception, didn't even try to do anything, killed the AP soon after the engine exploded on impact.

Attempt 3:

A rerun of attempt 2, except that I decided to try and have it land somewhere when it got into that loop, which only resulted in it going into the same loop as it did twice before. Flipped between the two AP modes a few times which only resulted in either error spam or locked in a somersault loop, then blasted the engine a bit to give it a different velocity to chase, which didn't fix either problem. Then I decided to just ram the ship into the ground since it was being buggy in either direction.

Also, I did one attempt at Tylo earlier and it landed perfectly, ran out of fuel JUST as I landed, but hey, it's Tylo.

Edit: Actually, the first one may have been made a bit screwy by Hyperedit since I sent a new craft to Ike and it was showing some odd behavior, plus the resource tab on the toolbar broke, so I decided to restart and when I came back, that behavior was gone. I'll just have to exit and relaunch the game whenever I do that before testing.

Tested Ike four times and as perfect as it can get for each one. Onwards to Duna! Travelling there normally because, you know, moon of Duna.

Landed on Duna twice and landed just fine, within 100m. Also found out that some of my drogue chutes glitched out due to thinking they were stowed, when they aren't. Second landing was slightly rough at about 1.something m/s (as opposed to 0.5) as it didn't quite slow down enough. I blame chute sheneinighans on that one.

For Duna, one thing that I'm noticing is that it actually shows the trajectory at the beginning of the atmosphere rather than the wierdness I've seen at Kerbin. I'll test out Kerbin later. I think I'll launch it normally this time.

Heres the quicksave used and the output log so that you have data on that: http://sta.sh/026hxiuswi6c

Edited May 5, 2015 by smjjames

[ITOS]

BREAKING NEWS!

I just noticed that I get different landing prediction and trajectories depending on if the autopilot is on or off!

It seems like the prediction is pretty much accurate when the autopilot is off but very wrong when it is on.

[SemMaxim]

How to disable all dependencies from buildings levels and tech tree? I want that all functions be available from beginning.

[Sarxis]

The way terminal velocity is being calculated now since the 1.0 upgrade is odd to me. The terminal velocity decreases a lot once my rockets are reaching higher acceleration. Is this due to it factoring in dynamic pressure?

-edit-

I 'm not sure what that was now. Seemed to happen with a specific craft - other rockets were fine.

Edited May 6, 2015 by Sarxis

[acerola]

How to disable all dependencies from buildings levels and tech tree? I want that all functions be available from beginning.

Edit the part.cfg for AR202. Look for "unlockTechs" and set it to

unlockTechs = start

on all the features.

Edit: this removes the tech requirement, but not the building requirement.

[fairytalefox]

Hello sarbian. It is not an actual feature request, I'm just wondering: is it possible to make MJ to drop fairings automatically on some condition (maybe at some height or dynamic pressure or something like that)? Sorry if already asked.

[futrtrubl]

BREAKING NEWS!

I just noticed that I get different landing prediction and trajectories depending on if the autopilot is on or off!

It seems like the prediction is pretty much accurate when the autopilot is off but very wrong when it is on.

http://i60.photobucket.com/albums/h18/ItosAtio/screenshot2_zpsbuihsqsd.jpg

That is by design. With the autopilot off it is showing you where you will impact the surface or perhaps where you will land if you suicide burn. With the AP on it shows where the AP will land you taking into account all the burns it will do.

Edit: Actually, the first one may have been made a bit screwy by Hyperedit since I sent a new craft to Ike and it was showing some odd behavior, plus the resource tab on the toolbar broke, so I decided to restart and when I came back, that behavior was gone. I'll just have to exit and relaunch the game whenever I do that before testing.

It has been stated before that HyperEdit will cause issues as MJ won't be notified that the body being orbited has changed and so it won't configure itself properly. A work around is quicksave+reload and maybe some scene changes.

Edited May 5, 2015 by futrtrubl

[acerola]

In the maneuver node editor, is it possible to add or remove one orbit, similar to the stock button?

If not possible, than I would like to suggest that feature.

[smjjames]

It has been stated before that HyperEdit will cause issues as MJ won't be notified that the body being orbited has changed and so it won't configure itself properly. A work around is quicksave+reload and maybe some scene changes.

I didn't get it when it was stated before, but I'm definetly aware of it now. A quicksave+reload appears to do the trick. I saw that same somersault thing all three times, so, that's independent of whatever sheneinighans hyperedit causes. Probably should actually fly the ship to Pol to 100% eliminate hyperedit doing something wierd.

Could use some tips on gravity braking at Jool.....

[ITOS]

That is by design. With the autopilot off it is showing you where you will impact the surface or perhaps where you will land if you suicide burn. With the AP on it shows where the AP will land you taking into account all the burns it will do.

I am under a different impression: The landing prediction is where you will land with no further input even when the AP is on. This is evident by how the AP makes adjustments and corrections to place the landing prediction marker on top of your target.

[Galane]

Here's a bug. The target selection list defaults to the KSC pad. When I click the Set button next to it I get the popup text Target N/A. I have to click the Set button a second time before it will actually set the KSC pad coordinates.

I built a new lander from scratch last night. 1 central Poodle and four T30's. Land Somewhere (with heating 'splosions disabled) got it down safely. Yea! Squad majorly nerfed the Poodle and LV909 darnit! What am I supposed to use for powered landing, a Skipper? (They also made the big Kerbodyne engine weaker than the Mainsail at sea level and in vacuum, while also being much heavier. The stock Learstar now has a TWR less than 1!)

I tried the same lander from the same orbit to land at KSC. Landing Guidance decided to incline the orbit to about 45 degrees and increased the Apoapsis to get a Mun encounter.

screenshot0 KSP 1.0.2 by g_alan_e, on Flickr

Since I mentioned the Learstar... Swap the KR-2L out for a Mainsail and it can fly, but unfortunately MechJeb's differential throttle can't handle it now as it is built. Instead of using the engines on the shuttle to add enough thrust to keep the craft balanced, it cuts their throttle way back and the Mainsail down to next to zero, and proceeds to fly into the ocean. Setting force roll to 180 (in both boxes) doesn't help.

That's a stock craft that was barely usable in previous KSP versions (thought I was able to use Ascent Guidance to get it to orbit), now needs a major rework.

Edited May 5, 2015 by Galane

[Aldmehr]

It does if auto-staging is on. MJ uses the deltaV stats to know how much thrust and how long each stages last. If it need to stage it adds the staging time set in the auto-staging config. It times the burn so half the dv is spent before reaching the node, so you if you have staging with different engines you can have the burn start earlier or later than half the burn time.

The math itself could use some love (Someone provided a better solution) but it is good enough for now.

Studying the code, it appears to me the halfBurnTime calculation needs the love.

I'd propose the following:

In MechJebModuleNodeExecutor.cs method BurnTime(...

Remove these two sections:
                if (halfDvLeft > stageBurnDv)
                {
                    halfDvLeft -= stageBurnDv;
                }


                if (halfDvLeft < stageBurnDv)
                {
                    halfBurnTime = burnTime + halfDvLeft / stageAvgAccel;
                    halfDvLeft = 0;
                }

And replace the second section with this:								
                halfBurnTime += Math.Min(halfDvLeft, stageBurnDv) / stageAvgAccel;
                halfDvLeft = Math.Max(0, halfDvLeft - stageBurnDv);

I'm not set up to build and test this inside KSP, but with some quick code experiments it seems to produce more desirable halfBurnTimes across staging.

[sarbian]

I haven't quite gotten used to the new areo effects, but it would be nice if certain values of the ascent path editor were selectable, like the turn start velocity. Anyway, good work on this as always.

uh, did you try the checkbox that says "Automatic Altitude Turn" in the ascent path editor ?

That is by design. With the autopilot off it is showing you where you will impact the surface or perhaps where you will land if you suicide burn. With the AP on it shows where the AP will land you taking into account all the burns it will do.

No it is not. It is part of the bug and I noticed it a while ago but the source was a bit complex. I spent the evening fixing that and then the next problem that showed up.

I think that at one point of the 1.0 upgrade I cut some code wrongly and something is missing. The simulation itself is fine (and that was most of the work) but some of the landing logic is not working anymore.

Now :

- I released a new dev build with new KER code. This one should be the last. Please warn me if you see a some problem with the dv windows

- I reverted today change to the landing sim (it fixed some problem but broke things that worked)

- I added a warning message about landing on bodies with atmo. Bodies with no atmo works as well as before

- I ll fix the "no warp" for un-targeted landing tomorrow

- If nothing horrible is found by tomorrow I ll do a new release. That will allow user that don't follow the thread to get all the fix since the last one and will lower the amount of "noise" in the thread

- Then I redo the landing logic starting from the 0.90 code and maybe some brand new code for some section. And hopefully I end up with something that works.

Aldmehr : added in the last dev. Thanks

Edited May 5, 2015 by sarbian

[terahurts]

Sarbian, if I'm understanding correctly the landing AP should now be working for airless bodies but still has issues with ones with an atmosphere. Is that correct?

[smjjames]

No it is not. It is part of the bug and I noticed it a while ago but the source was a bit complex. I spent the evening fixing that and then the next problem that showed up.

I think that at one point of the 1.0 upgrade I cut some code wrongly and something is missing. The simulation itself is fine (and that was most of the work) but some of the landing logic is not working anymore.

Hm, any idea why the trajectory correctly started at the atmosphere for Duna and not Kerbin as I've observed before? I haven't tested out Kerbin, Eve, or Laythe yet with the lander. Going to actually launch it to the destinations though instead of hyperedit.

- I released a new dev build with new KER code. This one should be the last. Please warn me if you see a some problem with the dv windows

I'm noticing a bit of a discrepancy between KER and MJ using build 444. Is having a discrepancy okay? In build 442, it didn't have a discrepancy, so...

Edit: Just checked the same craft under build 442 and theres definetly no discrepancy between KER and MJ.

Edited May 5, 2015 by smjjames

[Aldmehr]

Aldmehr : added in the last dev. Thanks

I think you left in the first 'if' block section that should also have been removed. (in dev #444)

[porrohman]

The way terminal velocity is being calculated now since the 1.0 upgrade is odd to me. The terminal velocity decreases a lot once my rockets are reaching higher acceleration. Is this due to it factoring in dynamic pressure?

What do you mean? Yes, your rocket will throttle down more once it reaches terminal velocity, because you don't need as much thrust. As the atmosphere gets thinner at higher altitude, it should start throttling up again since less dense atmosphere= higher terminal velocity.

[Galane]

What do you mean? Yes, your rocket will throttle down more once it reaches terminal velocity, because you don't need as much thrust. As the atmosphere gets thinner at higher altitude, it should start throttling up again since less dense atmosphere= higher terminal velocity.

That's what the TV limit does, though it's rather harsh and overshooting up and down on the throttle when hitting TV speed. Sarbian has been getting that sorted, which is a very good thing. I'm sure I'll get to like the new aero, especially after I CFG up some better performing clones of the ultra-nerfed KR-2L, Poodle and LV-909.

Edited May 6, 2015 by Galane