Around 7-8k Feet with any of my 7 engine craft (example linked below) it starts to slowly wobble into a complete loss of control. MJ 1 did not do this, and the craft is atleast well enough balanced for me to handfly without any issue. (not sure how to attach craft file)

If you stick the craft file on http://pastebin.com/ and give the link here we'll take a look at it.

Please post your ascent profile settings as well -- your ascent path as well as all of the settings in your Ascent Guidance window.

I must be blind, but I cannot see how to attach a file to paste bin
Would you like me to simply copy and paste the file?

Ascent Profile: Orbit alt 125, heading 90, inclination 0
prevent overheat is on
Limit to terminal ON
Limit acceleration: OFF
Corrective: Does it on both
Auto stage on

Ascent Path: 15km turn, 125 end, 0 angle 40% shape.

You don't attach a file to pastebin, you paste text into it. A .craft file is a text file, so you can just open it with a text editor and paste its contents in pastebin.

http://pastebin.com/UkL7fU33
Ship isn't the most beautiful, however I can fly it so mj2 shouldn't have trouble....

I just tested this craft, and this appears to be another case of the problem I described in this post:
http://forum.kerbalspaceprogram.com/showthread.php/12384-PLUGIN-PART-0-19-Anatid-Robotics-MuMech-MechJeb-Autopilot-v2-0-4?p=573311&viewfull=1#post573311
Probe cores often do not have enough roll control to keep a heavy rocket from spinning around its axis. When the craft has rolled so that its attitude differs sufficiently from the attitude MechJeb is trying to maintain, the control signals it calculates are misaligned with the ship's orientation, leading to a widening spiral around the desired axis (often looks like a spinning top precessing as it loses speed). This occurs, to the best of my knowledge, with all functions (not just the ascent autopilot).

I've discovered a useful workaround. If you hold down Q or E (preferably the one which would try to cancel out your rolling motion, but MJ doesn't really care which) then Mechjeb will not only stay in control, I've had it regain control within seconds of holding the key, even after it had started to go into one of these 'death spirals'. It seems that the user input causes the attitude controller to continually reset its desired orientation, keeping it in synch with the ship's actual orientation, which avoids the problem of the misalignment of control axes around the roll axis.

@Tallinu, thanks very much for describing your findings. They helped point me and r4m0n in the right direction, and while we have some more testing to do (on the change I just submitted), I think we'll have this fixed in the next release.

That's awesome. You're aware that it wasn't only the ascent autopilot affected by this? In space, using SmartASS to 'kill rot' for example, if it can't keep the ship rolled the way it wants it suffers the same issue. Will the changes you made help in that scenario, where it IS trying to keep the ship rolled a certain way? Also, in cases where "roll doesn't matter", will it still be attempting to counteract what roll the ship does pick up?

Video demonstration: http://youtu.be/vazlbKL-2tk
Craft used: https://dl.dropboxusercontent.com/u/203721/MJ%20Death%20Spiral%20Example.craft

Apologies for the messenger beeps during the video. -_-

Reproduction steps:
First, launch to orbit (100-300km tested with 0/50/5/90, all ascent AP options enabled) and jettison launch stage.

Test 1:
Engage Surf 0/0 OR Turn to a known heading and engage Kill Rotation
Throttle to approx. 1/3 (the large tick just below the E)
Wait as oscillations begin to occur despite SAS
When MJ disables SAS, ship begins to veer off course

Expected behavior: Ship remains on course despite inability to control roll axis.

Control: Use SAS to maintain course instead of MechJeb. Expected behavior results.

Test 2:
Stabilize ship
Disable SAS and SmartASS
Throttle to 100%
Wait until ship is spinning rapidly
Cut throttle and engage Kill Rotation
As spin slows enough to lose gyroscopic stabilization effect, ship begins to veer off course
When rotation is finally halted, ship returns to original course

Expected behavior: Ship remains on course throughout rotation-dampening.

Control: Engage SAS instead of Kill Rot. Expected behavior results (although SAS integrator apparently 'winds up' several turns worth of rotation, and then 'unwinds' by rotating ship in the opposite direction several times before finally stopping).

Best bug report ever. =) Thank you very much for the video and the craft. I'll try to perform the same test soon.

You're welcome. :)

My best guess, as I believe I said in that forum post (darn you, forum maintenance), is that all three control axes are decoupled, and it isn't doing anything to put the error and/or the maneuvers needed to correct that error (something like that) into the ship's frame of reference.

Resetting the PID controller keeps the error small so that the difference between what's being calculated and what should be getting calculated is minimal, but it's probably not the best solution.

I'd gone through some of the code and tried to figure out what did what, but it's been something like ten years since I last worked with Euler angles and quaternions, not to mention the unfamiliar codebase... Best I can describe what I think should be done to fix this is: Create some kind of 2D vector out of the yaw / pitch error and normalize it (instead of clamping them independently like it is now, I could follow that much), then rotate that vector by the roll error (or probably its negative). I don't know if any of that is useful or relevant to how you're handling the calculations, though.

Anyway, glad I could be of help, and I hope it's not too hard to solve the problem!

I didn't know this affected killrot — I've only observed this problem on ascent. Hopefully we can test the killrot behavior soon.

I just recorded a brief video demonstrating it, and I'm uploading it to youtube. I probably should've lowered my screen res though, it's going to take half an hour to send, heh.

Tallinu, not to undermine your epic bug reports (as a professional developer myself I would love to have my QA guys to be as thorough as you are when it comes to bug reports!), I think what happens is MJ caclulates the required steering rotation and then "memorizes" it and keeps trying to match it without realizing that, due to rotation, axis that used to point "up" doesn't point "up" that anymore, while MJ seemingly thinks that it still does. I had the same exact issue with my wild fantazies around BobCat's Energia LV - I could fly it manually with ASAS without an issue, but using MJ in any variation - be it ascent AP, or Surface ASS - ends up in "death spiral" at the end of powered flight.

You've just said basically the same thing I said. :) It doesn't account for the fact that the ship's roll changes the direction it needs to steer.

Maybe mechjeb could be made reactive in this scenario? While it knows what SHOULD be needed in terms of intakes, if intake air still isn't enough maybe it could open more intakes than it thinks it needs until the issue is resolved?

Did you mean to put that comment under issue 52?

Logic could be:

If [IntakeAir] < [25% of IntakeAirMax](in terms of the actual resource values upper right)
then symmetrically open closed intake with smallest [IntakeOpenDrag]

If [IntakeAir] > [75% of IntakeAirMax]
then symmetrically close open intake with smallest [IntakeOpenDrag] unless main logic calculates it is needed

Yes, I know this could cause some intakes to "flutter" open and closed rapidly, but it would only happen when the intakes are sufficiently angled away to cause this problem in the first place, and I can't think of any major impacts it would have on the game other than solving an issue people have when pitching too hard or something.

oops, yep. I'll go repost that there.

2.0.7 is out now, so I'm closing this.