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

[AndreyATGB]

Only explanation I can think of is that you're controlling the craft from the wrong place. Burning downwards is supposed to lower your apoapsis and rise your periapsis which sounds like what's happening with you. Is the navball also pointing downwards or just the ship?

[Ratzap]

You should never use autoconfigure with FAR anyway, and you should be flying FAR with RSS.

Regarding burns, a suggestion Sarbian was going to look into was cutting off a hair early and fine-tuning with RCS. It is bad news for landings, though, you're quite right.

I never do and I'm using all the mods specified except engine ignitor (that's just masochistic). I should have added that I'd set the turn start at 32km, end at 100km, left it at 40% and it was set to climb to 32,786km for a geo sat. It got out to about 130km then dipped the nose down - I can only assume it wanted to get better use of the gravity turn? No idea, anyway it plunged into the atmosphere and I went 'welp, doing it manually then'.

The landing was pretty damn comical. I'd quicksaved prior to the descent as I had a feeling I'd be doing it again manually but I wanted to see. The course corrections went a bit jerky but it got there eventually and the descent path was spot on - it really nailed the co-ordinates nicely as per normal KSP. It's just the hover and final descent where it needs low power that it went nuts. Swinging in ever wider circles as it desperately tried to compensate for the previous overcompensation. Thankfully it seemed to call it quits after a while and just went for it - up, down, left, right .....argh! The lander bounced, rolled over, I pulled the legs up and got the roll stopped with it pointing upwards then put the legs back down. Nothing fell off so perfect landing right?

RSS definitely confuses MJ2 in some areas.

I don't recall having a problem with ascent with regards to atmospheric height however. I just edited the ascent path / ascent profile / whatever-it's-called-that-I-can't-quite-remember and either set it to auto or I manually set the desired flight path destination altitude and end turn altitude.

If it says 69 that's just because the default configuration is set that way. It's capable of dealing with different atmospheric heights or it couldn't handle Laythe, Eve or Duna properly.

I always manually set the parameters for the ascent as MJ doesn't (or didn't) take the ships landed altitude into account on Duna for instance.

It's a pity because ascent takes 15 minutes and it's the least complex 'milkrun' type part of KSP once you get it set up. Something MJ is ideal for - do that for me while I make coffee

[NathanKell]

I should have added that I'd set the turn start at 32km, end at 100km, left it at 40%

There's your problem right there.

With FAR you need to start your turn when your vessel reaches ~100m/s (less if it's high TWR off the pad). For your average 1.5 sea level TWR rocket, that's about 1km. (If you're launching at 1.2g, which is safer, it's ~1.5km).

You set end and shape based on TWR throughout the flight, aiming to never be outside the little prograde marker. If you have a reasonable two-stage rocket (1.2->7, .9->6, say, for the TWRs of the two stages, noting the 1.2 is sea level and the rest vacuum) then maybe something like end at 150 and shape 60? Or even 100/45 if the upper stage has more punch. Anyway, tweak.

EDIT: From Ferram:

It depends a lot on your vehicle's design, but here are some guidelines that I've worked with:

Initial TWR 1.2: Vertical until 100 m/s, ~2-5 degree initial pitch, follow prograde (SLS w/ Pyrios Boosters, Saturn V)

Initial TWR 1.6: Vertical until 50 m/s, 5 degree initial pitch, follow prograde (Delta II 7925)

Try to hit 1 km/s when your velocity vector is headed down the 45 degree mark, usually out of the densest part of the atmosphere (somewhere above 20 km, but below 40 km).

Don't hit 1.5 km/s until you're above ~30 km. If you do, you're probably taking too shallow a trajectory or your initial TWR is too high. This won't waste fuel, but it does risk heating melting your rocket apart.

Look to have at least 2.5 km/s of velocity and an apoapsis of >90 km at first stage burnout if your second stage has an initial TWR of 0.9 and will provide most of the dV to orbit. If you're going to need to burn a complete third stage to get to orbit, make sure that your second stage has an initial 1.2 at this velocity.

You can get away with an initial TWR for a second stage (that gets into orbit) of 0.4 if your first stage burns out at ~4.5 km/s - 5 km/s. Generally, in this case you're sending something to another planet, the moon, or to GEO.

You want an orbit of ~190 km for lunar and interplanetary missions, and ~300 - 400 km if you're sending something to LEO. The higher apoapsis gives you mroe time to circularize.

Don't be afraid to burn upwards slightly and not follow prograde once you're out of the atmosphere. It can help buy you time to get extremely heavy payloads into space. Also, don't be afraid to circularize after apoapsis; most rockets do this actually, since the lower thrust engine allows the stage to weigh less and get more dV.

If you need practice getting into orbit, build a Titan II or a Falcon 9; both have abnormally high-thrust upper stages that will make getting into orbit easier, and then you can go for the lower-thrust upper-stage rockets where piloting is more difficult.

Edited January 28, 2014 by NathanKell

[ABZB]

Where can I find an explanation of the advanced SMART A.S.S. tab?

[CERVERUS]

Where can I find an explanation of the advanced SMART A.S.S. tab?

Here is: http://wiki.mechjeb.com/index.php?title=MechJeb_1_Manual

[Galane]

Only explanation I can think of is that you're controlling the craft from the wrong place. Burning downwards is supposed to lower your apoapsis and rise your periapsis which sounds like what's happening with you. Is the navball also pointing downwards or just the ship?

Control direction is fine. I always make sure it's aimed the right direction and I never put command parts on upside down, but in some cases I have stuck an OKTO2 on its side when I need remote control for testing or to drop one for a landing beacon. In those cases it's done because I need the docking port on top clear, and set as control.

That's not the case with this small Eve lander remnant or any other ship as it idles merrily away, shifting the orbit off center instead of making it circular and centered.

Here's a case of it doing that around Ike. Circular but off center. If Ike had an atmosphere, that orbit would be a bit of a problem. I got fed up with it failing to center the orbit and used Hyprtedit to knock it into place. It would do the proper burn, then change direction and start moving the orbit off center. IIRC this was with the dev build that fixed the bug where it would only use active engines at one end of a pair of ships docked nose to nose.

[ABZB]

Here is: http://wiki.mechjeb.com/index.php?title=MechJeb_1_Manual

Thanks, but that does not contain the information I am looking for - the use of the options such as Target Orientation, Inertial, etc.

[NathanKell]

The advanced tab offers you various vectors to align to, and the six cardinal orientations. So Surface_Forward is your surface velocity vector (and choosing Surface_Forward and forward will align you with surface prograde); Surface_North is towards the north pole, etc.

[sarbian]

Ratzap : nothing is hard coded (save the Ascent profile default ) so MJ should use RSS info in all situation. I did not test it much but other use it and I never got word of a problem before. You either triggered some special case or got a bug that got the AP stuck somewhere. As always having more info ( MJ version, dev release ?) and a save game helps a lot.

[BPI_Bel]

There's your problem right there.

With FAR you need to start your turn when your vessel reaches ~100m/s (less if it's high TWR off the pad). For your average 1.5 sea level TWR rocket, that's about 1km. (If you're launching at 1.2g, which is safer, it's ~1.5km).

You set end and shape based on TWR throughout the flight, aiming to never be outside the little prograde marker. If you have a reasonable two-stage rocket (1.2->7, .9->6, say, for the TWRs of the two stages, noting the 1.2 is sea level and the rest vacuum) then maybe something like end at 150 and shape 60? Or even 100/45 if the upper stage has more punch. Anyway, tweak.

EDIT: From Ferram:

This makes me wonder if it might be a better plan to have the ascent guidance work on velocity metrics instead of elevation. This would eliminate much of the oddity in FAR-related launches, since we would be able to follow Ferram's suggestion directly. I am not sure how it would affect non-FAR play, although I don't see how it would be a problem. Any thoughts?

[sarbian]

I have plan to code a new ascent profile that use a more "realistic" profile ( the quote are important since I can't do the same as real rocket without rewriting too much of the code).

You would set an turn start alt ( or speed ? ) and a % and MJ would incline the ship so that 100% is straight up and 0% is 1g up and the rest sideways. ( I don't like my wording here, does it makes sense ? I should draw something ...)

Comments ?

[diomedea]

I have plan to code a new ascent profile that use a more "realistic" profile ( the quote are important since I can't do the same as real rocket without rewriting too much of the code).

You would set an turn start alt ( or speed ? ) and a % and MJ would incline the ship so that 100% is straight up and 0% is 1g up and the rest sideways. ( I don't like my wording here, does it makes sense ? I should draw something ...)

Comments ?

As I am another follower of FAR, I use ascent with all precautions just as Nathankell explained in his post #5153. One of the main difficulties with MJ ascent autopilot is to find a profile that will not exceed a sustainable angle of attack (AoA) at any altitude. If it was possible to tell a new ascent autopilot a limit in the AoA (that varies with atmospheric density and speed), it would be better than start alt and %. Far better, for FAR users.

[AndreyATGB]

I have plan to code a new ascent profile that use a more "realistic" profile ( the quote are important since I can't do the same as real rocket without rewriting too much of the code).

You would set an turn start alt ( or speed ? ) and a % and MJ would incline the ship so that 100% is straight up and 0% is 1g up and the rest sideways. ( I don't like my wording here, does it makes sense ? I should draw something ...)

Comments ?

Sounds good and makes sense, the current ascent module is fine as long as I spend a few launches to tune it for each ship. I think it's important for the new one to be aware of stuff like FAR and RSS. I suppose it's the same thing just faster speeds but I'm not sure how to interpret your explanation 100%.

[sarbian]

Does it makes more sense ? For a rocket with a TWR of 1.5 taking off from Kerbin :

[AndreyATGB]

So 0% will always be whatever angle keeps vertical at 1g? If it can adapt to different designs and power/stages then it's both easier to understand and probably more efficient. How would it work in non-FAR KSP though? An early gravity turn just means wasting a lot of dV in the atmosphere.

[sarbian]

It would not replace the current system. It's one more ascent profile to select ( manual and auto are the two implemented now, but unless you look at the code you don't really see they are actually 2 different profile )

[diomedea]

@ Sarbian: the ascent profile as you seem defining it is just the trajectory that the rocket should follow. Being just a trajectory, the physical behaviour of the object is not considered, so it could be the same to launch a sphere instead of a tall cylinder. But a true autopilot must consider the forces applied and how to use or counteract them properly.

Sorry if what is below is rather basic, but I better show it or my thinking may not be understood. Pardon me, I grabbed one of your nice drawings and applied some forces to the rocket depicted in it, to show what I mean: drawing here.

There you see:

- Lift, applied to the center of lift (CL), of course along the opposite direction of the tangent to the trajectory. Lift is proportional to speed squared, so speed os a critical factor here. The angle of lift force in relation to the rocket axis is the angle of attack (AoA);

- Weight, applied to the center of mass (CM), of course on the local vertical;

- Thrust.

As CM and CL are far, this rocket will tend to capsize. AoA must be kept to a minimum here, so to remain within the ability of the rocket controls to keep it stable. There are two possible flight profiles possible for this rocket: vertical one up to such an altitude that lift will then be minimal when turning, or (if thrust allows) a very fast one, so that CL moves more towards the nose and AoA remains very small.

Therefore, I hope in a future MJ autopilot that will actually keep AoA under control.

[AndreyATGB]

I'm guessing what you're talking about is also FAR stuff since in the stock game it doesn't matter much if you have a high AoA. What you're describing would be nice indeed, but really I think the ascent module is fine for stock, acceptable for FAR and sarbian's suggestions will surely up it to fine with FAR as well. An option to limit AoA would be great, while following the optimal trajectory.

I think this will be the most difficult thing to do, MechJeb should keep AoA at a minimum while following a good trajectory. It's currently possibly to do this by playing around with the values until it works and I can't think of a way for MechJeb to calculate what the trajectory for a particular ship should be without pretty much simulating the whole ascent.

[diomedea]

@ AndreyATGB: Exactly. The only thing required is a limit on the AoA, to make a decent autopilot.

Indeed what I describe is very much FAR stuff, because stock KSP has only very primitive aerodynamics. But they exist in KSP too, as you can see CL and CM differing without having FAR: a wrong profile with a unbalanced rocket won't let reach orbit, you don't need FAR for that.

You say to be trying different values to find the correct profile. That is also what I must currently do. Most often, what spells disaster when trying profiles is MJ trying to steer the rocket sideways (mostly due to corrective steering), while it already has built a large speed and therefore lift. MJ doesn't care of AoA, lift, or air density to this end, it seems to maneuver the rocket as if it was outside of an atmosphere. So, the rocket does a couple loops, losing fuel and often speeding in a completely different direction then desired (even by MJ). And often the result is lithobraking, very kerbalish.

I am not actually asking MJ to calculate the optimum AoA for atmospheric flight, therefore I don't even want MJ to simulate an atmospheric ascent trajectory. I just need to have the possibility to make a setting, I would jell to MJ "stop pitching" when AoA is increasing way out of safety. Why can I have MJ deal with engines overheating and not with a simple AoA limiter?

[Caelib]

I use this mod occassionally and I really enjoy it -- thanks for making it. I would also like to say that I have been programming for almost 20 years and I've looked at the source code ... you are math GOD and a damn good programmer I am just curious, what do you do for a living?

[NathanKell]

The way I'd do the autopilot--although I'd ask Ferram and asmi (who AFAIK know this stuff best!)--is set a turn start speed, an initial turn pitch and azimuth, an AoA/Sideslip limit, and a final pitch limit.

Autopilot acts as follows:

1. Burn vertical until velocity > start speed, rolling to place +Z along azimuth

2. Pitch over (aka pull up, since +Z will be aligned with azimuth) until aligned with initial pitch/azimuth (pitching slower if necessary to keep AoA/sideslip below limit).

3. When velocity vector passes desired pitch, (unlock pitch and) follow it, but stay locked in azimuth (yawing to return to desired azimuth, limiting yaw to keep within sideslip limit, and rolling to keep +Z stabilized along azimuth line, aka vessel roll parallel to the surface).

4. Lock pitch again when pitch = final pitch limit.

An addition, for the circularize-after-apogee type of rocket, would be an "unlock pitch altitude", when >= that altitude, immediately pitch over to final pitch and stay there. Or perhaps key this to stage number?

This would allow a gravity turn until high enough apogee, then a horizontal burn to circularize. Since the switch from prograde to horizontal usually accompanies stage separation, it might make sense to key to that rather than a pure altitude thing, but altitude is probably more flexible.

Edited January 30, 2014 by NathanKell

[Galane]

There's something wrong with this image.

In the middle are two docking ports together. Around the big tank were six asparagus staged boosters. Right after the last pair drop, MechJeb lights the lander engines in the higher stage. Yes, all but the lowest engine in the list ARE in a higher stage.

Here I've manually shut down all 8 lander engines during the coast phase, which it completed and circularized properly using just the one mainsail.

There's no structural failure, no parts hanging around that have become disconnected. Just MechJeb ignoring that the lander engines are not in the same stage as the mainsail on the big tank, which had been running since launch. I carefully checked to make certain the decouplers for the final pair of asparagus boosters were not in the lander engine stage.

If I put a decoupler in place of the lowest docking port, in a stage all by itself, it doesn't do this improper engine activation - but for this launch I need that docking port because that big tank is going to become a fuel dump after it tops off the ship it's carrying the lander to dock with.

Dock the top of the lander to the Eve ship, top off fuel, undock tanker from the bottom of the lander and back it away with RCS, undock the lander then flip it around and dock its bottom to the top of the Eve ship.

Edited January 30, 2014 by Galane

[magnemoe]

Question is it an newer build than the 2.1.1 at the start page?

I have an weird bug, if undocking an unmanned probe from an manned one the execute maneuverer node function seems to be broken as in mechjeb does not control heading. Docking autopilot works think landing too.

[sarbian]

I use this mod occassionally and I really enjoy it -- thanks for making it. I would also like to say that I have been programming for almost 20 years and I've looked at the source code ... you are math GOD and a damn good programmer I am just curious, what do you do for a living?

Most of the code was written by R4am0n (and Anatid ? ). So most of the credit should go to them and the others contributor. I don't know what they do IRL but I know r4m0n do mod for other games.

As for me my work is not even remotely related to that. I work in performance/architecture java stuff for a bank (the boring type of bank)

NathanKell : thank for the input. I can't unlock an axis with the current code. I ll have to see how I can do that properly.

I'll see if I can make those without too much change in the code for now.

magnemoe : there is a link for dev version on the first post : http://jenkins.mumech.com/job/MechJeb2/

Edited January 30, 2014 by sarbian

[HoneyFox]

Does it makes more sense ? For a rocket with a TWR of 1.5 taking off from Kerbin :

http://www.sarbian.com/sarbian/MJ_Ascent_AP.png

This will be good for orbit circularization of an upper stage with decent TWR instead. And don't forget to cut the acceleration of gravity by the centrifugal effect especially when you have really high horizontal orbital velocity.

Edited January 30, 2014 by HoneyFox