Majiir

I\'d say he\'s a theologian. An 'extreme conservative' would probably just go farther on some issues than I would, but Glenn Beck went in a totally different direction.

Now all we have to do is add a way to assemble, launch and fly ships to this Mun! Oh, wait... :-[

Deodorant. I\'ll be the best-smelling apocalypse survivor ever.

It\'s a bad picture, but it\'s working properly. The top and bottom thrusters (relative to the picture) are both thrusting left. The left one is thrusting down, and the right one is thrusting up. There\'s a little erroneous thrust showing up in other places because the parts jostle around a little bit and their positions don\'t stay perfectly static. [EDIT] I had a thought about the winglets. They could easily be modified to react to the translation inputs. Stick a set of winglets at the top and bottom of the ship, and you\'ve got lateral force. The plugin would need to check that enough winglets exist in the right places, because you don\'t want a translation command to flip the vessel over, but I think I can cook something up. This might be turning into a distinct plugin...

I made a custom RCS block which ignores control input and accepts commands from plugin code. You\'ve got to extend RCSModule, override onCtrlUpd() and be sure to not call the base method. Also override onPartFixedUpdate(), and in this method construct a fresh FlightCtrlState object with your desired controls. (These can be stored in properties or something.) Call base.onCtrlUpd() with that state, and then call base.onPartFixedUpdate(). I think the same will work for the stabilizer fins. [EDIT] Success! Take a look: If you look closely (it\'s a bad shot, I know) you can see that the pitch/yaw/roll controls are all zero, the RCS thrusters are pitching the ship, and the fins are rolling it. This, of course, left the ship nearly impossible to control even with my flight computer, but I think it\'s a sound proof of concept. Currently, this is my code for issuing the commands: (Ignore the vessel.transform.rotation bit for now.) foreach (var part in vessel.parts) { if (part is SmartRCSModule) { ((SmartRCSModule)part).InputRotation = vessel.transform.rotation * new Vector3(0.5f, 0, 0); } if (part is SmartControlSurface) { ((SmartControlSurface)part).InputRotation = vessel.transform.rotation * new Vector3(0, -0.5f, 0); } }

I sometimes hear people say 'I\'m not a conservative or a liberal. I just use common sense.' The problem with this is that common sense isn\'t common. I think that most differences between liberals and conservatives come down to their respective interpretations of liberty. When you don\'t agree on that, you just can\'t find philosophical common ground, because your policy is designed to accomplish what you believe is inherently right and what someone else believes is inherently wrong. When you consider this, the U.S. founding fathers seem ever wiser for creating a country that allows those different philosophies to exist (in the states) as one nation. In my opinion, a scientific approach to politics can work, but only if you\'re brutally honest with yourself about what your underlying philosophy is. If you find that difficult, maybe that should be a clue that you need to revise your philosophy. How can you be proud of your policies if you aren\'t proud of their core principles?

Imagine that you trace a marker along the navball whenever you rotate. The most efficient rotation will appear to be a straight line on the ball. Some control laws, especially those that use Euler angles, will make a meandering path. The roll problem is something else entirely. Imagine you have a symmetrical ship and you want an autopilot to hold it at 5 degrees pitching north. That\'s a pretty small change, and you don\'t want the autopilot to also roll your ship all the way around to align with some arbitrary horizon that it picked. You just care about the pitch and heading. I\'m trying to figure out a way to analytically find a setpoint that won\'t issue a roll command. One thing you can do is only activate RCS thrusters if the attitude controller wants more torque than the SAS or fins can provide. You could also supply the attitude controller with some parameters for how it should behave, since the fastest control action isn\'t usually as fuel-efficient. Regarding fins, I think you need a constant input because you\'re in atmosphere, not because you\'re controlling fins. Imagine using fixed fins and SAS to keep the ship pitched over slightly; you\'ll still need a constant torque because your heading and velocity are different, and the fins are torquing you back. All that said, it wouldn\'t hurt to give fins the same treatment as RCS, and only move them when SAS isn\'t enough. (You could even attempt to move fins as few times as possible, or as smoothly as possible, using SAS torque to cover the difference. It would make a big visual impact, since fins currently jerk all over the place.) Actually, I\'m not sure integral windup is the problem. Remember, when the ship is approaching the ASAS target point, the error in angular momentum is the opposite sign of the integral. In other words, as you get closer, you\'re already ticking down the integral. The moment you hit where you want to be, the integral term is already zero. Most of the oscillation problems are actually caused by the proportional term, since the PID\'s constants aren\'t tuned to account for the torque or inertia of the vessel. They\'re just some arbitrary constants that Harvester determined were 'good enough' for most ships. There are also problems caused by the derivative term; most notably, if you\'re only spinning slightly and you activate ASAS, you\'ll 'jerk' in a random direction for a moment. Integral windup is a problem when you\'re spinning very quickly in a heavy ship with little torque. When you activate the ASAS, you might actually spin around a few times before it slows you all the way down, and now the integral term has accumulated several revolutions worth of angular momentum change. In order to wind that down, it needs to make a few revolutions back, and since the ship is heavy and the PID isn\'t tuned for the ship\'s characteristics, you get integral windup in the other direction for a while. Eventually, the proportional term and angular drag work it all out, but it can make already difficult-to-control ships a real challenge to fly. I think you\'re right about this; the SSME gimbals couldn\'t angle 'down' in the same way. I don\'t know about the Energia, but it was sufficiently different. (It had two engines, and its carrier rocket had eight, some/all of which were liquid.)

I used that phrase to describe the way some mischaracterize me. I think my use was fair, and I wasn\'t making a statement about bible-readers.

So I don\'t think the dot product can help us with the roll-minimization problem. You can use a quaternion dot product to find the angle between two quaternions, but roll doesn\'t change the angle, it changes the direction of the vector component. I\'ll have to think about this in a different way.

I\'m born/raised in Vermont, and currently living/working in Massachusetts, so it seems we\'re in similar situations. To be honest, I always liked it that way. I\'ve had lots of exposure to ideas I disagree with, and it\'s given me good reason to really think hard about my positions. I spent a few years in a conservative part of Colorado (albeit at a mostly liberal school) and it was boring. It\'s not that people agreed with me—they usually didn\'t—it\'s that nobody cared much at all. Nobody really felt strongly about much of anything, or if they did, they had no reason other than 'I was raised that way.' I think that\'s a common criticism that conservatives, but being in the northeast, I can tell you liberals aren\'t any better. I don\'t know how recent this phenomenon is, but both poles are very dogmatic. I occasionally have to remind one of my liberal friends that he\'s a smart guy who doesn\'t have to follow the party lines all the time.

I like to think I\'m one of them. Most people are a bit of a mixed bag politically, and there isn\'t a precise label for everyone. I\'m a conservative, but I\'m also an outspoken atheist. I oppose abortion and the death penalty, but I think both should be up to the states. Simultaneously, I think the second amendment (of the U.S. constitution) has been too broadly interpreted, and that may well not be up to the states. I think my views are compatible, but whenever they make me 'in' with one crowd, others make me 'out' with that same crowd. I was watching some videos from the Reason Rally that was recently held in Washington DC, and the speakers talked as if all atheists are liberals, and that all reasonable people would arrive at those same liberal conclusions. This is false. So, next time you assume that a conservative is a bible-thumping idiot, think twice. I think what U.S. politics lacks is ideological consistency, and that\'s something I like to bring to the table. There are a lot of ways to combine ideas from both sides as traditionally defined, and my views represent just one of those ways. Has anyone else felt like a 'misfit' along the usual political lines, either in the U.S. or another country?

The problem with moving bodies at different rates is that someone might be on a trajectory with a planned intercept. If you accelerate the planet, moon or vessel that someone\'s trying to rendezvous with, they\'ll miss their target. Consistently.

KSP uses procedural techniques to generate its terrain. Might there be a way to generate height information without making the game render it, and then levels of accuracy and detail can be simulated based on spacecraft attitude? I suspect that generating terrain information isn\'t nearly as computationally expensive as putting it onto a mesh and rendering it. I wonder if we can increase the level of detail on a PlanetQuadTreeController without making it render that detail? Maybe some of the PQS classes have something for us?

Okay, I\'m digging into this rolling thing a bit. The Wikipedia article on conversion between quaternions and Euler angles, the following equations are given: I think our axis for a roll would be [0, 1, 0] giving us the following: The angle range is double what you might expect because there are two quaternion representations for any given rotation. Now, since we don\'t care about roll, we can feel free to apply any rotation from this set to our quaternion setpoint. Our goal is to find a q_r such that the angular distance between q (above) and q_v (the current orientation of our vessel) is minimized. Stated a different way, we want to minimize the following quaternion product: I\'m just not sure how to determine the 'distance' between two quaternions, or a meaningful 'angular magnitude' of a quaternion. Various sources indicate that the dot product is or isn\'t acceptable. Any ideas?

Yes, it\'s much like a PD. I think the eta term (the second epsilon term) is important, though. Somehow. Don\'t ask me how. [EDIT] I should mention that only the part I\'ve pulled out resembles a PD. There\'s a lot more in there that I completely ignored (for lack of understanding it) which I believe makes the controller aware of the spacecraft\'s torque and inertia characteristics. Thanks for reminding me of this; I need to include this in my original post. I think we need to approach this from the math side. We don\'t want to approach a given quaternion and simply ignore the roll commands; that could lead to instability (as I\'ve found out the hard way). What we\'re really doing is specifying an entire set of quaternions, any of which we\'d be happy with. This set is essentially any of the quaternions that result when the desired quaternion is rolled any which way. Now we need a way to determine which quaternion(s) in that set are 'easiest' to reach. This may be a simple minimization problem, but without a good understanding of optimal pathing, I\'m not sure we can tackle this quite yet. [EDIT] I\'ve got a working list of sources I\'ve been looking at here. I\'ll throw up good PDF links later, but Google should be able to find those.

Ah, I see. Still, Mono.

I\'m interested in both, but you can\'t have either without a solid foundation. I spent a couple weeks working on a landing computer, but I got very frustrated that some things (attitude control, drag modeling, etc.) were so complex. The community at large seems only to have scratched the surface of these core components. That depends. If there\'s a way to manually fire RCS without using the fly-by-wire controls, then yes, I think it can be done. (By the way, I strongly suspect it\'s possible to do exactly what, since the RCS thruster class exposes thrust levels for each of its axes. At the very least, a replacement RCS class could do it.) Plugins can both monitor user input and override it, so you could split off the RCS logic and only use the fly-by-wire controls for capsule SAS, which is a much simpler model. You might run into trouble if your part\'s fly-by-wire delegate runs after some other autopilot\'s, but since there are only a handful of autopilot plugins anyway, it should be pretty easy to have them integrate with your plugin when it\'s present. Out of curiosity, in what ways do SAS, RCS and fins need to be treated differently? (I mean, not flapping fins around while in orbit would be great, but that\'s sort of harmless.)

This paper seems to imply that an asymptotically stable controller will necessarily follow an optimal path. I don\'t really see how that\'s true, but it\'s worth noting anyway. Most literature seems to stress various kinds of stability, and doesn\'t make much reference to pathing. It occurred to me that there\'s at least one easy way to implement rate control as I described it. If we already have a linear controller where ? (angular velocity) is one of the components, we can substitute ??, the difference between the current and desired angular velocity. If the controller has the right angular velocity but lags behind, the error quaternion component(s) should correct it as normal. If the target orientation isn\'t actually moving, the controller will pull in the direction of the target angular velocity, but this is a user (and by that I mean user code) error. Such a construction would, however, probably invalidate any assumptions of stability that we can derive from literature.

I like it! I override the ASAS all the time for my plugin projects, so I\'d love to use this (even if it\'s only for myself to see).

Alright, I found the paper. I took equation (10) from this paper: http://www.ajc.org.tw/pages/paper/5.3PD/9FR-02-18.pdf Now, I\'m definitely missing a lot of the insights from that paper, but it\'s still progress! There are four constants (?, a, b1, b2). ? is angular velocity, ? is the vector part of the error quaternion, and ? is the scalar part. For some reason, this works really well. I\'m working on compiling a list of some more resources that might help us here.

You just need Mono. Java is silly (not to mention the only way to run Java code in a KSP plugin is to use something like IKVM, which would run on Mono anyway).

The same color can be seen as either orange or brown. It depends on the surrounding reference 'white' color.

I think there\'s a Part.RequestFuel() method, or something along those lines. That should consume fuel in the same way that engines do, so if your fuel-dump part is above some tanks, it probably won\'t pull fuel from them. (You might be able to call RequestFuel() on another part, though.)

(I couldn\'t help the puns.) Some of the most popular plugins seem to be autopilots. Whatever these plugins do, they all share at least one common component: an attitude controller. Why? Because if you\'re an autopilot, you need to be able to steer! While working on an autopilot plugin of my own (precision descent controller) I found that the attitude control problem is much more complicated than I had originally expected. It\'s easy to come up with primitive solutions, but these have problems that seriously limit their potential uses. The following is a (probably incomplete) list of features than an ideal attitude controller has: [li]Orientation control - This is the core function of an attitude controller. The user (which is usually some other code) tells the attitude controller to put the ship at a specified orientation.[/li] [li]Stability - There are various mathematical definitions of controller stability, and they\'re important. We don\'t want our ships to oscillate or spin out of control.[/li] [li]Disturbance rejection - KSP is a simple simulator, but there are still some disturbances to account for. Angular drag can be accounted for ahead of time, but things like collisions or floating-point errors can\'t be predicted.[/li] [li]Disturbance compensation - I put this in a different category because it\'s a slightly different problem. Imagine you grapple another ship with some lander legs, and then you make an orbital burn. The second ship is slightly off-center. A plugin can\'t compensate for the offset center of mass, so your attitude will always be slightly off. A proper attitude controller will detect (usually through error integration) that it must apply additional torque in order to stay on course.[/li] [li]Optimal pathing - This is where simple (usually Euler angle-based) attitude controllers really fall short. When we\'re adjusting the orientation of the ship, we want to take the shortest path to get there. It\'s quicker, which is always good, but it\'s also more stable. If you\'re launching and you want to roll your ship 180 degrees, a simple attitude controller might pitch you 90 degrees forward, yaw around 180 degrees, and then pitch 90 degrees up. That\'ll crash your ship.[/li] [li]Speed - Some maneuvers require a quick attitude change, so our controller should make reasonable use of available torque.[/li] [li]Rate control - Suppose you want to spin in a controlled way. The user code might set a moving orientation target, but many controllers will lag a set distance behind, depending on how fast the target is moving. An ideal controller allows the user to specify a target rate.[/li] [li]Roll ambivalence - Sometimes, we only care about where we are on the navball, and we\'re happy to let our roll do whatever we (or the pilot) want. I believe this is a minimization problem, and that we can\'t simply ignore the roll commands. (More details in this post. Thanks The_Duck for reminding me of this issue.)[/li] Now, let me be clear: this is only a wish list. Even to get just a few of these, we need to dig into some pretty heady academic papers. I\'ve read through a few myself, but unfortunately I don\'t have any formal training in control systems, so some of it goes over my head. Let\'s take a look at an existing (KSP) attitude controller and see how it stacks up. (If none of this paragraph makes sense, just skip to the last sentence.) Since MechJeb is pretty popular, I\'m going to pick on it. The MechJeb 'Smart A.S.S.' accepts a target orientation (as a quaternion) and computes the orientation change required to move from the ship\'s current orientation to the desired orientation. After this, it breaks down a little; Euler angles, angular velocity and angular acceleration are combined in an attitude-control PID, with some special cases where the error quaternion is slerp\'d. The result is that MechJeb can make large-angle changes, but it can be unstable and makes a convoluted path. I tried my hand at something smoother. (I can\'t find the paper I derived the control law from, but I\'ll grab it from my laptop sometime.) This control law was quaternion-based and avoided Euler angles completely. It also made absolutely no sense to me. I don\'t know how or why it works, but it does. The pathing isn\'t completely optimal (I don\'t think) but it\'s pretty damn near close. It\'s fast. It\'s stable, both subjectively and in at least one mathematical sense. I didn\'t understand enough of the paper to properly calibrate the controller for the ship\'s moment of inertia, but the results were pretty good even so. I think MechJeb and some other plugins would immediately benefit by implementing the controller as-is, but I think we can do better. As a first milestone, I propose creating an attitude controller with the following of the above features: [li]Quaternion-based orientation control[/li] [li]Disturbance rejection (in other words, don\'t pilot blindly)[/li] [li]Optimal pathing[/li] [li]Optimal settling speed, within a threshold (this means our controller should measure available torque and the ship\'s moment of inertia and fly accordingly).[/li] The first two are easy; a simple PID can do it. The second two are much more challenging, and will require some math-fu. I think it\'ll pay off, though. Who\'s up for helping? 8)

You definitely need to separate before warping. I met in low Kerbin orbit, then again near apoapsis to boost periapsis, then again near periapsis after entering Mun SOI. (I was on an escape trajectory at this point.) Rendezvous is time-consuming, but if you\'re close enough to maneuver with RCS, it\'s pretty fast. You need to give yourself time to dock before you reach your burn target, though. I find I can do a full Mun mission with a reasonably heavy craft using less than one RCS tank; it just takes some care with the controls. (Precision mode is your friend.)