When I change desired heading using the gimbal, the heading will always overshoot the target, and then try to correct and overshoot again at least 6-10 times before finally settling on the desired heading.
This seems much worse with RCS attached, and the rocket will seemingly flail around the desired direction for a long time before settling.
KSP used to have this problem until they improved their SAS system. Hope to see this in SR2.
Thanks!
@flyingmadpakke
Excellent point ... about Kerbin, ... wonk t'nod tsuj ew. (:
Even if you Google this stuff, Euler vector calculations will make your head spin (pun - sorry). I only sort-of understand how they function.
"Gimbal Lock" is an inherent weakness of Euler (vector) Rotations. The only way to counter it's occurrence is to not use it and go to radial or angular rotations. The Euler method is much faster and so ends up being used in a lot of game engines. A really good, first person example is the drone in Empyrion - a Unity Engine game. Angle the view down about 45° and rotate 180°. You will now be looking at the sky because (in this case) the 'X' axis locks with the 45° angled 'Z' axis. The programmer's frustration is, if you try to maintain the 45° angle on the 'X' axis the 'Y' axis begins to rotate and the drone would be upside down by the time it has turned 180°
The real cause of the trouble is that Euler Rotations, in 3D applications, use a "world" or global axis orientation as reference or a starting point. The calculation to go from pointing to one point on a sphere to another point get's into trouble if the calculation goes past 120° or -120°. This may not be in reference to the object's original orientation but to a "global 'up' " which compounds the problem. Notice that the Simple Rockets camera always maintains it's north orientation. In Kerbal space the camera can go wonky when you switch view type because it switches between a global referenced to a local referenced "up". In one view type the local is referenced by the planet being orbited, in another the reference is the vessel itself. If these referenced "up"s are beyond 120° you get wild swings of the camera until the program narrows the difference - one axis at a time - essentially, a PID loop.
You and I think linearly. An object to be rotated is a single mass and we can perceive the amount of change for it's three axis in an angular calculation we can do in our heads. An object in a 3D application is a group of vertex or points that describe the shape of the object. Their locations relative to the center of the object are mathematical vectors. Leonhard Euler's formula for vector rotations is used because it can rotate all those vertices with a single calculation or algorithm and maintain their positions relative to each other, maintaining the original shape.
@Captpkelly
Btw, sorry if my response is long and weird. I don't get drunk for personal reasons, but I don't need to, cuz I'm naturally in a chronic state of confusion and incoherence :P
@Captpkelly
You are right about what you say, but my point was that maybe you wouldn't need the feedback/loop part. Also, yes, I did assume the craft didn't have any initial rotation or spin.
The idea was for the game to do what I described, but only once, then go back to it's normal autopilot. In space it would be so close to the targeted direction, that the normal autopilot would be sufficient after the procedure. That's why I thought It would be a quick fix?
But you are right that you could also make a complete loop of my procedure, I guess you would have to test it in game to see what works best :)
I did not think much about that "gimbal lock" you describe, I guess I haven't noticed it.
Also, the yaw and pitch is definitely a problem. I don't know why but when I wrote my post I had forgot, the game can handle yawn pitch separately fine, but not together optimally, right?
So, actually the game does not yet have a good thrust balance, only when doing pitch/yawn separately. This must be added to the fix :)
From what I remember, the problem is an extension of this one. Some maneuvers require change in both pitch and yaw, but it's usually not the same amount of degrees. Say your craft overshoots yaw before pitch, it then tries to correct yaw by boosting in the opposite yaw direction, while still moving in the same direction for pitch. The result is also huge inefficient wavy arcs, but what do you think about this one?
Instead of going full throttle in both directions, the game could take the shortest change as a fraction of the longest, then use this to adjust the thrust in the shortest direction, such that the forces in both directions combines in a much more preferable way.
Also, if all this was fixed and the game had very good thrust balance, then depending on how frequent these balance calculations are done, it could more or less counter "gimbal lock".
Now completely off-topic, how can we be sure that Kerbin and Droo doesn't exist in the same universe? ;)
@flyingmadpakke
What you are describing IS a PID loop. It's a very simple one that would apply a correcting force that's consistent from one time to the next (which the RCS is or should be - the system is not throttled) and applied for a given time. The "loop" then has to calculate the time it will take to get to the set target and apply the same but opposite thrust to decelerate it. The loop also has to calculate WHEN to apply that deceleration thrust based on the mass's rotational momentum. The main feedback of your PID is the final angle or attitude of the vessel - "is it pointing to the set target"
As a programmer you have to duplicate all the decisions you make if you perform this manually.
1. How far am I turning?
2. How fast do I want to turn?
3. What is the shortest arc using two of the three axis from start point to finish point (something this program is very bad at figuring out - I know why, but that's a different discussion).
4. Is the vessel already rotating?
5. If it is, can I use the existing rotation or do I have to counter it?
6. Is the vessel heavier or lighter than the last time I made a correction?
7. Is Jebediah at the controls ... oh wait ... that's another universe.
You can do this manually "on the fly" without giving it much thought because you learn how your vessel responds, but the game has to go through this step by step every time you adjust the auto-attitude gimbals.
There's also an inherent problem with Euler Rotations used in 3D graphic applications ... and process controls ... called "gimbal lock" that causes the object being rotated to become disoriented in the axis not being rotated. This can be seen in this game when the vessel begins to rotate along it's length ('Y' axis ... well it's the 'Y' axis in MS Flight Simulator) when attempting to adjust only or both the pitch and/or yaw of a vessel - meaning the combination of thrusters used to begin the rotation may not be the same when it's time to stop the rotation.
There is no simple solution and the developer will have to spend many hours attempting to make this better in the game.
@Captpkelly
Pid loop is cool, but for me, this is primarily a problem with large crafts in space. In such an environment, I don't think a PID loop is 100% needed. The game already knows how to apply thrust to the relevant rcs thrusters to get your craft pointed in a targeted direction. Because you are in space, this thrust is the only relevant force. So, if the game applied say 10 seconds of rcs thrust, then it would only have to apply 10 seconds of thrust in the opposite direction to come to an almost stand still (small deviation because of spent fuel and probably navigational error).
This way the game really only needs to make calculations based on TWR, thruster balance and maybe circle perimeter. I think this could be a simpler quick fix that will cover this in 99% of all cases.
Currently you can set your direction to about halfway of your target, then the craft will stop pretty much on the target.
The game feels very tight except for this. I am sure this will be fixed soon.
I agree with this 100%.
Now ... To understand the difficult nature of programming this seemingly simple function, look up PID in process controls (proportional–integral–derivative). This is a "feed-back" loop used by a computer (normally one controlling some manufacturing process) to settle on a set target. This set target could be the thickness of the paper rolling off the mill (my working experience with a company called MeasureX), or it can be the orientation of a simulated space craft. A properly "tuned" PID will find it's target with little to no overshoot or oscillation around the target. The problem here is that as the mass of the space craft changes, by staging or expending fuel, the variables used to "tune" the feed back loop change, and an extremely complex algorithm is needed in addition to the main PID to alter these variables.
A PID is not easy to understand much less to "tune" - probably why it took KSP three years and a full programming team to tackle it.
@flyingmadpakke
(continued)
But Euler Calculations are based on radians or π (pi), not radials or angles. Our instinctive way to re-orient a space craft is complete gibberish to the computer when it's thinking in "Euler" math, so our simple solution to the problem is just not so simple for the computer.