I just downloaded Mechjeb 2.0.7 and tested it and when i build a simple rocket link to craft and set the ascent to Start turn at 0 end turn at 50 and a flight path angle of 5 and a turn shape of 75. It did every thing fine until stage separation now ruing on the smaller engie it did not correct for the lower thrust and did not point the nose up a little to raise the Ap and thus leading to my doom because the orbit was set for a very low 70 km orbite but still with Mechjeb 1.9.8 it allays worked it allays corrected to raise the Ap. http://www.mediafire.com/?oqqoixpv9uyba1o

Make sure you turn on the "corrective steering" toggle. This will turn on the behavior you are talking about where MJ points up to keep raising the apoapsis even when the thrust is low.

I can confirm this behavior using the craft and ascent path from jannikstarwars's post (and pretty standard ascent settings: prevent overheats, limit to terminal velocity, corrective steering, auto-stage 0.5 / 1, and auto-warp). I suspect the corrective steering option is irrelevant.

When the circularization node appears, it indicates a 983.2 m/s burn is needed. The problem is two-fold:

1. It waits longer than it should to do the burn, because the burn time is calculated based on currently available thrust. For this ship, at this point in the ascent, the ascent stage and its T45 have just 165 m/s of delta-V left, leaving the rest of the burn up to the much lower-thrust LV-909. But the burn time is calculated as if the T45 will be used for all of it.
2. The circularization burn is now done by executing a maneuver node, plain and simple. There's no correction for apoapsis falling, because all the ship is trying to do is burn in the direction of the maneuver node.

Fixing either (1) or (2) would probably address this issue.

Any situation in which the following are true is likely to result in a problem of this nature:
A fairly lengthy circularization burn is needed;
A stage is nearly but not quite expended when apoapsis reaches the desired altitude;
And the acceleration of the next stage is significantly lower than the preceding stage.

Let me take a moment to say that 70km is really not a good choice of orbit height - that's right on the border between atmosphere and space zones, and even the slightest deviations will prevent use of standard time warp and lead to atmospheric drag further degrading the orbit. The lowest I've ever seen or would expect to see used is 75km.

However, even when choosing a 75km orbit, the situation still causes this problem. There's enough of a burn required that the change in thrust moments after the burn begins results in a very lopsided orbit which still dips into the atmosphere at periapsis (67km in my test). Calculating the time for a burn of a certain delta-V in a way that incorporates the time remaining in each stage and the acceleration curve during the life of that stage would be a significant improvement in functionality.

Since circularizing an orbit while still within the atmosphere is a bit of an oxymoron, I think number 2 really shouldn't be considered a problem, at least for the ascent autopilot. Perhaps if aerobraking was involved, making sure the apoapsis gets to a certain height and maintaining it there until out of the atmosphere could be worthwhile, maybe with an optional circularization step once that apoapsis was reached... But would that even use a maneuver node?

It seems clear to me that number 1 would be the proper 'problem' to solve (whether it's done the way I described or not).

An additional note for Jannik, results from the test flights I ran, which you may find useful: It looks like you can avoid this issue AND save more fuel getting to such a low orbit with such a light craft by using ascent path 5, 40, 0, 80% with corrective steering disabled. (Yes, I'm obsessed with efficiency and had nothing better to do and a book to read.)

As a suggestion for the mismatched T/W issue on an interrupted burn, maybe mechjeb could use more than one maneuver node?

Let's say you need to burn 400m/s. Your current stage has 100m/s left @ a T/W ratio of 2.5 that'll burn for 10 seconds. You've set auto staging with delays of .5/1.5 pre/post separation, and your next stage has a T/W ratio of .8 where burning 300 m/s will take it 60 seconds. (random numbers are random) Have mechjeb set the first node to 100m/s, then a second one 12 seconds later for the other 300m/s, and have them centered around where you would have put them if they were one node. But then you'd have to adjust for the tapering off of thrust.

An even better method would be: Using the same values, subtract the first burn from the total ∆V calculate next stage burn time for remainder of ∆V. Add remaining burn time to staging delays and add that to the next stages' burn time you calculated (repeat this if it burns through more stages), then divide by two and burn ahead of the node by that long.

@gmcnew I just tested it again and this time i made sure corrective steering was on and it did it again. then i uninstalled Mechjeb 2 and installed Mechjeb 1.9.8 again and it made a perfect 70 km by 70 km orbit with the craft.
The old Mechjeb 1.9.8 dose correct for lower thrust by pointing up I just check. but 2.0.7 dose not do that even when i check the corrective steering box it still stays on the node and not above it to raise the Ap :(

@jannikstarwars - MechJeb 1 uses a different method for the circularization burn where it attempts to maintain vertical speed at zero until circularized. I've seen MJ1 get confused and just point horizontal sometimes when TWR changes (due to staging or engines running out of fuel) dramatically during the circularization. Apparently it was working okay for your craft with MJ1 but it's not always the case. Since MJ2 uses a different circularization method, the two reasons @gmcnew gave above are causing the issue. I like the suggestion @Aquilux made of splitting maneuver nodes up if TWR changes are expected during a burn.

I think splitting maneuvers into multiple nodes would just open another can of worms. With the calculations needed to figure out how to space the maneuvers out and the problems that inaccuracies in one maneuver would introduce into the second, etc...

Well then how about working the second part of the suggestion? That doesn't seem like too hard of a math problem considering I could do it on the fly with the data mechjeb already gives me, and I'm horrible at doing math in my head.

Yeah, that last paragraph is a specific method of "Calculating the time for a burn of a certain delta-V in a way that incorporates the time remaining in each stage" although I don't know if it takes into account "the acceleration curve during the life of that stage". (Quoting my previous post. :)

You guys are awesome, you know that? Improvements pouring down like cats and dogs. :D

@gmcnew wow you fix it already respect man

Thanks guys. =) I would emphasize the "improve" part of my commit comment — my change makes the problem less severe, but for the craft and ascent settings @jannikstarwars posted, you'll still end up with an orbit that reenters the atmosphere. As long as the circularization burn is done with a single maneuver node, I think the only way to avoid this problem is to give yourself more time for the c-burn, either by increasing your orbit altitude or by altering your ascent path so that your c-burn doesn't have to be as long.

Just found an interesting bug. I'll verify it, then post a new thread.

Here it is: #70

The ship link above is broken, so I've re-uploaded it: http://pastebin.com/zS8e3hcW

@Tallinu Oops, sorry, looks like you're right.

@gmcnew Wowzers, can't wait. :)

I think @gmcnew's improvement, which is included in the just-released 2.0.8, goes a long way towards dealing with this. I'm going to close the issue, but anyone should feel free to reopen it if they find 2.0.8 still has a problem with this.