Example stock craft with similar maneuvering characteristics to many ships that MJ has problems with: https://dl.dropboxusercontent.com/u/203721/MJ%20Maneuver%20Example.craft

To illustrate one of the biggest problems with MechJeb's steering (after launching, of course - path 0, 50, 0, 75% always works well):

Set SmartASS to Surf, heading 90, pitch 0 and execute.
Wait for ship to stabilize, and roll so that ship is level with horizon.
Leave RCS off, or disable it now.
Change Surf to heading 270, pitch -45 and execute.

Expected behavior: Simple (albeit slow) pitch down maneuver, rotating the ship through a 135 degree arc around the pitch axis. (Pitch control should reverse after traversing 67.5 degrees to avoid overshooting.)

Actual result: Pitch up and yaw left or right, combined with about 45 degrees roll, until target is on or near the ship's yaw plane. Continued yaw maneuver, most likely missing the target and sweeping back around in an arc, possibly overshooting several times. Total travel arc of 180 degrees or more even without counting the overshoot.

If the target orientation was a maneuver node (including automatic node execution) or "TGT +" instead of Surf, the ship tends to constantly roll left and right as well, and often starts off with a large, utterly pointless roll.

Since any two non-parallel vectors define a plane, MJ should simply be rotating the ship around the axis perpendicular to that plane. If that axis is not perfectly aligned with the ship's pitch or yaw axes, that shouldn't be a big deal either. The angle difference between that axis and the yaw or pitch axis, fed into the Sin and/or Cos functions, should be able to provide the appropriate yaw and pitch ratio. Scale both up proportionally so that the larger of the two reaches the max steering signal.

Then it's just a matter of getting it to quit overshooting the target heading by up to 90 degrees. Update 4/21: The moment of inertia calculations (#59) seem to be responsible for the inaccuracies leading to most steering overshoot. With the latest dev build and symmetric pod torque or enough RCS control, it can completely eliminate overshoot, so the PID controller itself is clearly working just fine in that regard.

Thanks for describing this issue so thoroughly. I can reproduce the behavior you described even in the latest dev builds, so I hope we have time to look into it soon.

I just want to comment that suggested way might not be the most efficient way to perform a rotation, since most craft have very non-uniform PMIs (principal moment of inertia), and this has a potencial for overshooting as well as overusing RCS if it's used to perform a rotation. The most efficient way is to perform largest amount of rotation around axis with lowest PMI (which usually is roll axis for more or less conventional rockets), and since MJ is a plugin it can actually calculate such a maneuver as if I remember correctly there is a way to retrieve PMI of current vessel from within a plugin (Vessel::MOI). At it's most basic level, moment of inertia along some axis indicates how hard the vessel tried to keep its' current angular velocity around that axis, so the less moment is, the easier (read - less torque and possibly RCS) is required to change angular velocity. Also due to the "binary" nature of RCS thrusters (they are either on at full thrust, or off at zero thrust) it actually make sence to first roll (again provided that MI around roll axis is lowest) until one of the principal axes is aligned with desired rotation, and after roll is completed use just these thrusters to complete operation. BUT it assumes that RCS thrusters are aligned along principal axes which is the best practice among experienced rocket builders, but obviously not all of KSP players, so probably MJ should calculate "moment arms" for all installed RCS thrusters and use these that provides for optimal rotation.

I have a few things to say in response to your post.
1st, I completely agree, some ship designs are more efficient either yawing, or pitching, and if mechjeb could be aware of that, it'd make it more efficient. But sometimes you don't want your ship to roll, such as if you're trying to line up with a station to dock as square as possible or if you need to keep panels facing the sun. To solve this, it'd be awesome if we could have "Snap to X°" and "Hold roll" to solve these problems respectively.

2nd, regardless of top speed, if starting at stationary you accelerate 50% of the way, then decelerate the other 50%, you will wind up stationary. This is, I believe, what the OP is referring to. There may be some errors in his thinking, but the concept sound. If implemented, I suggest couple of user inputs. Labeled "Speed" and "Aggressiveness", these would me multipliers affecting the target top rotational speed, and what % of the time it should coast on it's angular momentum respectively. Altering these two values would let us adjust mechjeb for either massive or tiny craft.

3rd, The OP appears to be posting as to make a record of the undesirable effects of having the pitch roll and yaw controls unaware of one another's actions, and suggesting a way to solve this. While his suggestion may not be optimal, it is certainly better than the current system.

4th, I'm sorry, but the statement about the "binary nature" of the RCS thrusters is flat out wrong. Just because the inputs are binary, doesn't mean everything is. Ways to prove this statement: connect a joystick and observe the RCS plumes when you push the stick over part way compared to when you push it all the way; use precision controls to yaw/pitch/roll lightly and observe RCS plumes (notice control indicator position), then repeat the action, but holding the the input for an aggressive attitude change (compare RCS plume and control inputs; begin undamped attitude change on massive ship (No sas, or anything else active). Activate A.S.A.S (not regular Sas) and observe the decreasing plume sizes as the ASAS as it nears it's goal.

Asmi: Thanks for pointing that out. In terms of RCS fuel, it's possible that it's not be the most efficient. It might depend on the orientation of RCS and such. But it would generally be the fastest and least likely to cause unintended problems. If you're in an atmosphere or near another ship or station, rolling could have consequences including collision or loss of control.

If someone's crazy rocket design could change pitch at rate X and yaw at rate 10X, then it might be useful to have an option to roll to use the more effective yaw axis (although a better option would likely be to redesign the rocket). However, this should be an "opt-in" type of option rather than a default behavior, if implemented at all. And then there's the fact that MechJeb doesn't wait for a roll maneuver to complete before beginning to yaw and/or pitch toward the target heading/elevation, so unless it was altered to do so if that option was enabled, it would still need to figure out the proper directions to yaw/pitch while the desired axis was not fully in line with the required rotation axis.

We must also consider what happens with a side-mounted docking port or other part that can be "controlled from here". Suddenly the inertia for each axis could be very different. This could be useful or detrimental, depending on the situation.

Aquilux: While those suggested options sound good, consider what happens if you yaw left 90 degrees, pitch up 90, then yaw right 90. You're back on your original heading and elevation, but you've rolled 90 degrees right even though you haven't "rolled" at all. Defining an arbitrary frame of reference relative to which your roll would be measured for the purpose of snapping to or holding would simply lead to strange, often undesirable behavior, especially as you orbit around the reference body and the horizon plane shifts. I think it would be better to simply keep the ship's roll axis stable when possible and avoid using it unless particular maneuvers make it necessary.

On the other hand, adding a 'roll' field with a checkbox to Surf could be useful as long as pitch wasn't near 90 or -90 and the behavior of the control axes was appropriate to the desired maneuvering to get there.

2: Correct. I like the idea of being able to configure a max angular speed or acceleration, especially if it's based on the ship's actual maneuvering properties, inertia, etc. It might be possible to achieve this through PID tuning but as I've said, I have yet to do anything but worsen its behavior via manual "tuning"... If some kind of auto-tuner could be created, or these options implemented in some other way, that'd be awesome.

3: Any ideas to improve what I've suggested are welcome, I don't claim to be an expert. :) Changes to behavior should be user-friendly and/or optional, as appropriate, of course.

4: Speaking of RCS, I wonder if the RCS balancer module could be used to do things like keep the throttle low on the RCS ports for those constant back and forth oscillations that SAS likes to do, only ramping it up if it continues applying a force in a certain direction, perhaps? For some ships, such an "RCS Damper" might be all it takes to cut wobble significantly without losing maneuvering power, like a 'fine control' mode for SAS...

Speaking of stability, I think instead of being reactive (by trying to fix instability) MJ should attempt to be proactive to the extent possible by trying to prevent this insability to occur in the first place. If I remember correctly, there is a way to control thrust vectors of each engine individually, and so this can be used to compensate for imperfection in engine placement. Specifically in your craft if these "rotating" engine would be gimbal-capable MJ could just steer thrust vectors to prevent this issue from occuring.

I feel like I didn't clarify this well enough.

1. With the "Hold roll" option, it wouldn't do anything that "Kill rot." doesn't already do. In fact, the easiest way to implement this (in my opinion) would be to let the "Kill rot" module activate and deactivate independently from the other buttons. When another module is running simultaneously, "Kill rot" would treat the other mechjeb inputs as if they were from the pilot. At any time, the user could deactivate it without affecting any other module, letting the ship roll freely as it does now. (this would also be in context if it was available while other systems such as the maneuver node, assent, and landing autopilots. Active it would prevent free rotation, disabled the ship may rotate as it is pitches and yaws.)

2. I was thinking of something similar to the way mechjeb uses the translatron to control vertical speed during landing. After identifying the vector by which it will affect it's attitude, the angular distance is measured, and a speed curve is produced (similar to the pitch vs altitude of the assent path editor). As RCS thrust is applied, mechjeb tracks the angular speed. When it reaches that speed it stops thrusting, and when it exceeds it, it applies thrust to slow it down. Aggressiveness would adjust the steepness of that curve (like the X% slider on the assent profile editor), and max speed would control the top of that curve (like the "turn end" variable in the same editor). This would give users more control over mechjeb's behavior, and give them more of the responsibility for the correct behavior of their craft (reducing how much mechjeb can be blamed when things go wrong). Maybe a third value, "Deadzone", should be added. similar to on a joystick or other game controller, this would add a zone within which mechjeb would not send attitude control signals (basically mechjeb calling it "close enough"). A "Deadzone" of this sort could, when set properly by the user, minimise if not totally eliminate the "jiggle" that mechjeb is famous for burning through RCS fuel with.

3. The "Snap to roll" is more of a docking enhancement, and an opt-in not opt-out. Specifically, it's something that many have been asking for and I am providing suggestions on how it could be done. My thought is that there would be a button that would be categorised under "Docking". Similar to the symmetry button in the editor, when active this would cycle from 2x "symmetry" through 3x 4x 6x 8x 12x, and so on (180°, 120°, 90°, 60°, 45°, 30°...). This value would then be applied around the roll axis of whatever part you are controlling from, your docking port for example, and would attempt to match the roll to a multiple of the designated value when referring to it's target, such as the targeted docking port. Activating this would be similar to activating "Kill rot" in that the user input would override it, allowing the ship to be commanded to a new roll value in relation to it's target, but when the user stops manually rolling (lets go of the controls) it would attempt to align itself to whatever multiple is actively closest. (To clarify further, actively closest means the closest at this point in time, so if it overshoots and continues on, another multiple could become the closest, ant it would attempt to halt there. This works best if my second clarification is taken into account). This would help users align their docked craft more accurately in the way some other autopilots allow.

I just saw your new post and it reminded me of something I had been trying to puzzle out. Maybe the RCS balancer already draws off of this, but if not, take a look here: http://imgur.com/a/13BuS I have a few more pages where I attempt to expand on my work and make it able to handle more exotic RCS placement, but it's not finished.

This could be useful with main engine controls as well. Sometimes RCS vectoring SAS and flaps can't save you, or you don't have room/∆V for any/enough of those systems/fuel. What you often DO have in those situations are 2 or more engines with their thrust vectors offset from the center of mass (similar to the RCS problem). If there was a way to have one engine throttle down while another throttled up, you could get attitude control along the planes that are parallel to the thrust vectors and pass through the center of gravity. Not only that, but if you could use throttling to pitch and yaw, then you could use vectoring to apply not only roll, but also translation forces, which would be perfect to use in controlling a hover without having to tilt for horizontal motion.

Alas it looks like this will be more of a pipe dream, at least until you guys are less busy with ironing out the wrinkles in mechjeb 2.0, considering how much work it looks like it'll be to do this.

Aquilux: I didn't realize you were thinking of "snap to" in the context of "relative to a targeted vessel", which of course makes excellent sense. It would be a different way of looking at the problem than ORDA's absolute selections or even a specifiable rotation offset. The latter could still be a desirable option, especially for perfectionists like myself who carefully align the docking ports "just so", but a 'snap to' like this would be a more flexible option for when you simply want things to be square, and would rather have easier manual control over (or don't care about) which particular angle a ship is attached at so long as it IS square. Or triangular. Or whatever your craft / station symmetry happens to be. This should probably go in its own issue though, if it doesn't already exist.

As for the first point, aside from the fact that when it comes to coding, what seems easiest may in fact be not so easy, there's also the fact that current behavior in most cases, at least in most modules and in the prior version, is not to let the ship roll freely but to maintain the starting orientation to whatever extent is compatible with the maneuvers being performed. That is to say, the roll aspect of the ship's orientation is preserved. "Kill Rot" differs from other autopilot functions only in the fact that it tries to maintain the ship's starting orientation when it is first engaged, rather than some other predefined or customized orientation. What you're suggesting would effectively be a "attempt to maintain a roll rate of zero, but do not worry about 'un-rolling' whatever error may creep in". I'm not sure I see a point to that.

As for your last post and Asmi's: Using engine gimbals to roll the ship (I believe it's called "Control Authority") is something that the engines have to support via part module, as far as I know. There are a couple of plugins out there to accomplish it, although one of them is apparently bugged and turns the ship the wrong direction. They both require adding a module or replacing the gimbal module on the engine parts to work. But it could be that it's possible to add that functionality without that. I don't know. Again, though, that's a separate issue from the steering bugs. (I'd love to find out if it's possible for something like MechJeb to do that, though!)

Has there been any further conversation about how best to resolve the "roll" issue with MechJeb attempting to hold to a certain roll even when unneeded? The MoI change above was amazing at providing control, but MechJeb still trying to roll craft when unneeded is causing additional problems.

This behaviour just destroyed my spacecraft on ascent: I went from vertical to 30 degrees pitch due East. MechJeb gave control inputs to send me heading 45 and pitch 15, then it tried to go back over to heading 90 and pitch 30 but all this strange slewing around ended up tearing my spacecraft apart.

My reaction was of course to try to debug this. Reading the SmartASS code is complicated; lots of stashing state to be used from one callback to the next, I can't quite puzzle out the data flow. However, I'm highly suspicious of the Quaternion.LookRotation calls. Why use LookRotation rather than FromToRotation?

Closing this as an old MechJeb issue. Many MechJeb issues have had little interest in years, have been fixed for years, do not include adequate replication steps, refer to old problems which are no longer applicable, or are difficult to determine what the problem is. This issue is being closed for one of those reasons. We apologize for any inconvenience, but keeping the TODO list tidy helps the developers.

If this bug/issue is still a problem, please open a new issue. For bugs please try to include a Minimal, Complete, Verifiable Example that explains all the steps required to replicate the issue. A link to the KSP.log file should be ideally included, but is often not sufficient information. Screenshots or short videos are often the best way to show a bug.

This is probably also a dup of #1050