A Question About Reaction Control Systems

[Deus Zed Machina]

I'm developing a game of my own based around spaceflight, and a physics problem came up that I'm not sure how to solve. In short, I need to figure out how to distribute thrust across multiple RCS thrusters such that the net force lines up with a spacecraft's center of mass. 

This haphazard assembly of default Unity shapes is the spacecraft in question, and the little cubes are the RCS thruster blocks. Currently, they all push with a force of 100 Newtons along the x, y, and/or z axes depending upon which keys the player is pressing. Since the lower blocks are closer to the center of mass than the upper ones, the net force applied by the thrusters when I try to move the ship horizontally is actually slightly above the center of mass, causing the whole thing to rotate. I could manually set the center of mass or move the lower thrusters so they're lined up properly, but I'd rather figure out how to eliminate this rotation without doing either since that would give me more flexibility when I design other ships to add to the game. 

So how would I calculate the amount of thrust the lower blocks should apply such that the ship doesn't rotate?

[DDE]

Try to tag the people behind RCS Build Aid, MechJeb and Throttle Control Avionics among others.

[StrandedonEarth]

It would be a simple question of leverage and torque, T=FD where F is the force applied and D is the distance from the CoM. If you have a thruster pushing 100N at 1m from the CoM, then the thruster on the other side needs to provide the same 100Nm of torque to balance it.

[PB666]

 

https://en.wikipedia.org/wiki/Moment_of_inertia#Newton's_laws <---Read this

/wiki/Moment_of_inertia#Motion_in_space_of_a_rigid_body,_and_the_inertia_matrix .

These describe the phyics of motion for object whose application force vectors do no go through the center of mass (IOW they are not translation accelerations but rotational accelerations)

I would add to that the math is very complex and you need at least one error detection. M = momentum, r= rotational

δM_r/dt + δM_object/dt = V_exhaust * mass flow

k-caret is a unit vector normal to the plane of rotation (don't worry about it in a 2-d system of acceleration).
Because rotations can be described in three axes (minimally 2, in the roll plane of XY and δ(Z/r)/dt at Z=0

Define position as R = (0,0,0) and r = pXYZ = SQRT(pX² + pY² + pZ²) the position vector components in a object specific coordintate system
Define unit vectors [i = x,y,z] iu = pi/pXYZ
Each thruster has a set of 6 position vectors and a position magnitude (δr).
Define a global coordinate system in which any translational motion of R can be translated into the global coordinate system as subcomponent vectors of acceleration that also where the component vectors a[i = x,y,z] is the additive of all subcomponents a_thrust + a_gravimetric + a_aerodynamic It is neccesary to carry both positions and velocity vectors. Where [iu = Xu, Yu, Zu the unit position vectors] and 0 and 1 are starting and ending times of the interval. change of velocity attributed to gravity is  0.5g(-iu₀)*δT + 0.5(-iu₁)*δT and the change of position caused by gravity  approximates to 0.375g(-iu₀)*δT² + 0.125g(-iu₁)*δT² in each of the three directions. If done properly this will take care of the translational aspects.

For computational reasons convert back to Keplerian Elliptical when needed (Such as during warping).

For rotational aspects use the objects coordinate system

Ic = the moment of inertia about point R (0,0,0)

where alpha is the angular acceleration about R and omega is the existing angular rotation about R in the existing plane.
If the added motion is purely rotational, for example all energy is conserved in Ic*w if the craft is not rotating and thrust is applied then it becomes torque resulting in angular motion. YOu will need to use vector math to determine the Θ and φ components and direction.

There are two directives, 1 is to push and the other is to roll (assume we want to roll in any of three axes). In the push directive set up 12 points (double cube) (sensors) and test the push balance, tone the RCS output for  each set. pushes 12 points because user can combine 1X, 1Y and 1Z to generate composites that are rotated 45 degreees to each axis (like firing LK and H simultaneously in KSP) When inputs H, or HK or HLK each thruster will respond at different levels. To roll you want to balance along the axis of rotation thrusters.

  I forgot to add to this yesterday, this is how to interconvert between two coordinate systems ( I had a much longer post that I shortened to stick to the relevant posts, but I cropped to much)

The translational thrust must be converted from the ships axial based coordinate system to the global coordinate system.

 

 

Edited December 26, 2017 by PB666
inserted the wrong formula in the wrong place, doh

[sevenperforce]

Spoiler

24 minutes ago, PB666 said:

https://en.wikipedia.org/wiki/Moment_of_inertia#Newton's_laws <---Read this

/wiki/Moment_of_inertia#Motion_in_space_of_a_rigid_body,_and_the_inertia_matrix .

These describe the phyics of motion for object whose application force vectors do no go through the center of mass (IOW they are not translation accelerations but rotational accelerations)

I would add to that the math is very complex and you need at least one error detection. M = momentum, r= rotational

δM_r/dt + δM_object/dt = V_exhaust * mass flow
Because rotations can be described in three axes (minimally 2, in the roll plane of XY and δZ/dt)

Define position as R = (0,0,0) and r = pXYZ = SQRT(pX² + pY² + pZ²) the position vector components in a object specific coordintate system
Define unit vectors [i = x,y,z] iu = pi/pXYZ
Each thruster has a set of 6 position vectors and a magnitude.
Define a global coordinate system in which any translational motion of R can be translated into the global coordinate system as subcomponent vectors of acceleration that also where the component vectors a[i = x,y,z] is the additive of all subcomponents a_thrust + a_gravimetric + a_aerodynamic It is neccesary to carry both positions and velocity vectors. Where [iu = Xu, Yu, Zu the unit position vectors] and 0 and 1 are starting and ending times of the interval. change of velocity attributed to gravity is  0.5g(-iu₀)*δT + 0.5(-iu₁)*δT and the change of position caused by gravity  approximates to 0.375g(-iu₀)*δT² + 0.125(-iu₁)*δT² in each of the three directions. If done properly this will take care of the translational aspects.

For computational reasons convert back to Keplerian Elliptical when needed (Such as during warping).

For rotational aspects use the objects coordinate system

Ic = the moment of inertia about point R (0,0,0)

where alpha is the angular acceleration about R and omega is the existing angular rotation about R in the existing plane.
If the added motion is purely rotational, for example all energy is conserved in Ic*w if the craft is not rotating and thrust is applied then it becomes torque resulting in angular motion. YOu will need to use vector math to determine the Θ and φ components and direction.

There are two directives, 1 is to push and the other is to roll (assume we want to roll in any of three axes). In the push directive set up 12 points (double cube) (sensors) and test the push balance, tone the RCS output for  each set. pushes 12 points because user can combine 1X, 1Y and 1Z to generate composites that are rotated 45 degreees to each axis (like firing LK and H simultaneously in KSP) When inputs H, or HK or HLK each thruster will respond at different levels. To roll you want to balance along the axis of rotation thrusters.   

 

Yeah, exactly what he said.

[Zeiss Ikon]

To simplify a lot of the math, for this specific situation, you need to reduce thrust from thruster blocks in inverse proportion to the distance of their thrust line from the COM.  So, with two sets of thruster blocks, one 2 m from the COM and the other 3 m from COM, you need to reduce thrust of the latter set by 1/3 to prevent inducing rotation when you translate up/down or left/right (but not fore/aft, assuming the layout is symmetrical around the roll axis).

Now, when you want to rotate, won't want to compensate this way -- say with the same layout as above, symmetrical on the roll axis but one set further aft of the COM than the other set if forward of it.  If you compensate for distance when you pitch up, you'll be applying more upward thrust with the forward set than downward force with the lower set, and you'll add a translation "upward" along with your pitch up.  Applying identical thrust will still rotate the craft around the COM. it just won't mix translation you hadn't commanded.

[kerbiloid]

And to make the RCSing smooth (accelerating on start, decelerating on finish) you'd better use PID-loops or so, like the guru recommend.

[Boris-Barboris]

On 25.12.2017 at 11:19 AM, Deus Zed Machina said:

I could manually set the center of mass or move the lower thrusters so they're lined up properly, but I'd rather figure out how to eliminate this rotation without doing either since that would give me more flexibility when I design other ships to add to the game.

Since the actual control problem is quite complex, and it's solution does not (I assume, since it's you who is designing crafts) increase the gameplay value of your game, you can just abstract it away by one net torque to some big part of your craft. The control problem can be solved. Just assume that is it solved and already implemented in all your crafts by the lore, and just tune the net torque value for your likings\balancing.

A lot of performance problems of KSP could be partially mitigated by such simplifications. IMHO, you want to solve a problem you don't need to solve.

[PB666]

1 hour ago, Boris-Barboris said:

Since the actual control problem is quite complex, and it's solution does not (I assume, since it's you who is designing crafts) increase the gameplay value of your game, you can just abstract it away by one net torque to some big part of your craft. The control problem can be solved. Just assume that is it solved and already implemented in all your crafts by the lore, and just tune the net torque value for your likings\balancing.

A lot of performance problems of KSP could be partially mitigated by such simplifications. IMHO, you want to solve a problem you don't need to solve.

To do that the fuel tanks would have to be zero centered in their construction and be mounted on either side of the center of mass. It does not exactly have to be this, you could have 3 tank. 2 on the side and one on top of the CoM. Or 4 tanks where the center of mass lies between the pairs. The problem is that if you don't have an RCS balancer you will rotate as fuel is used unless the fuel is balanced on the normal to the plane of thrust. I would make the argument that the easiest ship to RCS balance is a cube (particularly the way KSP physics works) where each of the RCS units is at a vertex. Each of the fuel tanks is on a side, the thruster is on the bottom and a balancing mass on the top.

In actuality, this is the way it will have to be implemented as you say. There are two vector physics, the translational, those that go into global coordinate system, and the rotational, those that go into the crafts coordinate system. When many thrusters are fired the translational acceleration vectors need to be parsed out of the total vectors and applied to spacecraft motion in the scenery, the rotational accelerations need to then be applied.

CoM is 0,0,0 . . . . .a force 1 is applied 0,1,0 at 2,0,0 and force 2 is applied 0,1,0 at -1,0,0. The total translational force is 0,1.5,0 and this needs to be converted into the sceneries coordinate system. The remaining 0.5 of force goes into rotating this ship around its Z axis, therefore the scenery translation vectors are only moment vectors, and change as thrust is applied. Its pretty hair trigonometry.

Why accumulating forces along vectors has to be done? Because if you fired force 1 and then force 2, force 1 would principally rotate the ship one direction and force 2, while moving the ship a little would primarily rotate the ship back. When applied together they assume both shared and individual characteristics. Judging how KSP handles the problem, the solution for space stations is not robust, its clear when sections are joined certain RCS should be modulated. I don't know what the clock cycle trade-offs are but they certainly could have invested more into this aspect of the game. 

I should also point out that the last equations that I added are not correct, the will only work if you move the ship Z axis is  tangent to the elliptical. I am working on this problem myself and haven't found the precise set of equations for 3D translation of an object in the elliptical, I do have something currently working on the computer, but .. . . . 

Edited December 27, 2017 by PB666

[Boris-Barboris]

1 hour ago, PB666 said:

To do that the fuel tanks would have to be zero centered in their construction and be mounted on either side of the center of mass

PhysX allows to apply torque directly. Without applying any forces. Whatever you apply it to, it will simply rotate, no matter how complex, without translation side effects. Unless of course it's so big that PhysX solver fails to conserve momentum.

1 hour ago, PB666 said:

Why accumulating forces along vectors has to be done?

you don't need forces at all for OP's case.

Edited December 27, 2017 by Boris-Barboris
typo

[PB666]

1 minute ago, Boris-Barboris said:

PhysX allow to apply torque directly. Without applying any forces. Whatever you apply it to, it will simply rotate, no matter how complex, without translation side effects. Unless of course it's so big that PhysX solver fails to conserve momentum.

you don't need forces at all for OP's case.

You don't need forces to translate, but you do need to rotate, at least the mass of the fuel is a variable, so that had to be factored into the rotation.

This is a problem with KSP as I mentioned. In KSP if your fuel tank is zeroed at the bottom, thats were the parts CoM is even when full, the fuels CoM is at the bottom. So according to proper physics (oxymoronic) the acceleration needs to be derived from the application of force divided by the accumulation of mass times their forces at different radii. These are applied to the parts zero vector. That resulting vector is what you need, but the way its calculated is a joke.

Most folks don't realize this until you built a fair number of parts, I always want my parts surface attach to be zeroed along the X-axis, but on aerodynamic side mounted tanks this is often far the center of volume which is where you want the fuels center of Mass to be applied.

[Boris-Barboris]

Just now, PB666 said:

You don't need forces to translate, but you do need to rotate

I'm afraid you got it reversed. Net force translates. Net torque rotates. In PhysX\Unity torque does not need a force to exist.

1 minute ago, PB666 said:

In KSP if your fuel tank is zeroed at the bottom

I don't understand you, what do fuel tanks CoMs have to do with the topic?

 

[PB666]

See the equations in the first, in reality the newtonian equations are for particles, the assumption that any mass can be broken into particles, this to deal  with the fact that rotating objects are not cylinders but have complex 3-D shapes. So when a craft rotates its fuel is on one side of the tank, when it moves forward its on the bottom, when it reverses the fuel moves to the front. KSP applies all the intertia at a single particle at the parts zero. It treats it as a point mass. (This is a science forum, not a parts modding forum).

The forces that translate are easily wiped clean simply by taking the starting acceleration and multiplying it by mass_o/(mass₀ - δmass/₂). Its not so easy with rotations, if done properly the calculation is much more complex. Second thruster output is in Newtons, which is a force. [The equations I listed showed how to convert the force to torque and I do mention torque]

 

Edited December 27, 2017 by PB666

[kerbiloid]

Unikely excessive accuracy is required in a computer game.

[PB666]

26 minutes ago, kerbiloid said:

Unikely excessive accuracy is required in a computer game.

Start building mods and find out, I actually had to go back into blender, change the zero on some of my parts to keep very odd things from happening.

[Boris-Barboris]

54 minutes ago, PB666 said:

KSP applies all the intertia at a single particle at the parts zero. It treats it as a point mass.

Not true in the slightest. Each part with a rigid body (so every one but the smallest utility ones) has it's own inertia tensor.

[PB666]

22 minutes ago, Boris-Barboris said:

Not true in the slightest. Each part with a rigid body (so every one but the smallest utility ones) has it's own inertia tensor.

Its inertial physics are at its 0,0,0 and treated as a point mass.  If you want I can prove it to you.

Take a size2 fuel tank in blender whose perimeter is centered at 0,0,0, move its zero out to X = 11.125  This can be done by moving the 3-D cursor to -11.125, 0, 0 and in object mode setting the zero to the 3-D cursor. In the game X becomes -X. In the game set its attachment point to X = 12.5, 0, 0 compare the original part to the modified part note the hang of the tank once on the launch.

The inertial physics does not care about part shape or where you imagine the fuel to be, it only cares where that parts designated center is, if you move that center 10 meters out, it will be as if the tank had a 10 meter pole attaching it to the craft. It assumes that all the fuel is at the point designated as the center.

Edited December 27, 2017 by PB666

[kerbiloid]

48 minutes ago, PB666 said:

Start building mods and find out, I actually had to go back into blender, change the zero on some of my parts to keep very odd things from happening.

Started, just with Wings3d instead of Blender. Still sure that a computer game doesn't need a precise solution.

[Boris-Barboris]

Just now, PB666 said:

Its inertial physics are at its 0,0,0 and treated as a point mass

Part's center of mass is set by default to 0,0,0 (wich is overridable via cfg iirc). Physics engine does not treat the part as a point mass.

3 minutes ago, PB666 said:

It assumes that all the fuel is at the point designated as the center.

No. https://docs.unity3d.com/ScriptReference/Rigidbody-inertiaTensor.html

 

[PB666]

 

3 hours ago, Boris-Barboris said:

Part's center of mass is set by default to 0,0,0 (wich is overridable via cfg iirc). Physics engine does not treat the part as a point mass.

Let me use the correct word, its origin, the inertial part does. I've 'tested' it many times

3 hours ago, Boris-Barboris said:

No. https://docs.unity3d.com/ScriptReference/Rigidbody-inertiaTensor.html

Belief is a wonderful thing, I can post on the internet that I've seen a flying unicorn and someone will believe it. . . . .science is about testing, that's why we tend to be atheist.

The tank on the left has all the same cfg.file mass variables (empty and fuel) and physics as the tank on right. Except the origin for the left part is offest  6.25 from its center to the left and the attachment point is -7.219, the left tanks visible center is closer to the beam trusses than the ones on the right, and yet the left tank is acting like its further away, that is because to KSP, the tank is 6 meters further away. It took me 20 minutes to set up the image because the problem tank kept hitting the ground and blowing up, even with 1 truss it would fall over too fast to take a picture. To answer the question, you believe what Unity tells you or what your eyes and game experience tell you. I am telling you that the game uses the a parts origin to apply its inertia. I don't know about its drag cube, but its inertia is applied at the origin. Another issue with fuel tanks is hopping 1000 meters in the air, the larger the tank the higher it can hop. I could create a long list of non-physical launch pad behaviors.

Just go to blender and try it, when you have done it and ported it into the game we can discuss it elsewhere, but further discussion here is off-topic but to say that the game physics is not RL physics in many ways.

 

[K^2]

You guys are talking through each other. Every rigid body ever is simulated as a point mass + moment of inertia tensor. These aren't contradictory statements, because they describe two distinct degrees of freedom. You accumulate all forces as impulse against point-mass and all torque as change to the angular momentum.

@Deus Zed Machina: To solve a problem, first step is always to figure out the correct statement. Technically, what you have here is a Linear Programming problem. Fortunately, it's a very simple one, so you don't need a full LP solver.

We wish to match given torque subject to constraints that net force is zero and no thruster exceeds max thrust. Statements in bold will become equations.

1) Σ F_i x r_i = τ

2) Σ F_i = 0

3) 0 ≤ F_i ≤ F_{i max}

Here, F_i is thrust of i-th RCS, with F_{i max} being its max value, F_i = u_iF_i is the corresponding thrust vector (u_i being unit vector in direction of thrust), r_i is position of i-th thruster with respect to CoM, and τ is desired torque.

How do you solve that? Well, the thing that saves you from going full LP here is that the first two equations are just linear equations with F_i as your variables, and the saturation can be treated as happening one thruster at a time. Lets forget about saturation for a second and pretend that there is no maximum thrust. We just write down first two equations as a matrix equation.

T = RF

Here, T is a column matrix, containing x, y, z components of τ and 0. F is another column matrix containing F₁, F₂, F₃... The matrix R is the one you have to build from vectors r_i and u_i to match equations 1) and 2). You might have to write out these sums explicitly to see how the components fall into this matrix, then you can write a program to generate that matrix easily. If you don't know how to write down a system of linear equations as a matrix and solve it that way, look it up. You won't get anywhere in optimization without understanding that. Write some code to practice if you have to.

Now, you might notice that we have more equations than we have unknowns. Matrix R definitely isn't a square matrix. So we can't invert it. Fortunately, we don't have to. A Moore-Penrose pseudoinverse matrix can be constructed that solves this particular class of problems in a least-squares manner. If that's a bunch of babble to you, don't worry about it. Here's the formula to use.

F = R^T(RR^T)^-1T

Here, R^T is the transpose of R. So the entire numerical challenge is reduced to finding inverse of the (RR^T). Note that this is a square matrix, with number of rows and columns matching number of your individual thrusters. How do you find an inverse of a square matrix? Same way you do on paper. Surprisingly, perhaps, Gaussian Elimination is the best algorithm for it. Though, look up how to use Gauss-Jordan with pivots. It will greatly improve precision, and isn't much overhead. You can also probably just find a library that already does this part for you. Edit: I messed up here. RR^T is actually guaranteed to be 4x4, because it has dimensions of the constraints. You can still use Gauss-Jordan, but you can also find an explicit formula for 4x4 inverse matrix. It's not pretty, but it might be worth it to just hard-code that.

Finally, you have to deal with saturation. After you solve for F_i, odds are, you'll find some that are either less than 0 or greater than F_{i max}. There is a "correct" way of dealing with this in LP, but again, we're using simplicity of the problem. Take just one of these, one which is outside of the bounds  by greatest amount. Set it to the corresponding boundary. (So if F₂ < 0, say F₂ = 0) And add this constraint as a new row to matrix R. Only add one row per attempt. Once you expanded R with this extra row, run the whole thing again to generate a new list of F_i. Rinse and repeat. Edit: Adding a row here will make RR^T a 5x5 matrix, etc. There is nothing wrong with that, but then you'll have to go Gauss-Jordan way. Alternatively, you can treat F_i you are setting to a constant as a constant in 1) and 2) and re-compute R from that. Then RR^T is still 4x4, but matrix F will pick up some new terms. Both are totally acceptable ways, just depending on whether you prefer to have a hard-coded 4x4 inverse subroutine, or if you want to write a generic Gauss-Jordan.

After enough iterations, one of two things will happen. Either you'll find a list of F_i that satisfies your constraints, or you'll get to the point where R is already a square matrix (Edit: If you chose to go with R that always has 4 rows, you can just count constraints you've added. Condition you're looking for is the same, number of equations = number of variables), and the solution is still saturated. In that later case, it means that the desired amount of torque cannot be generated with the thrusters you have. Your best bet is probably to take the F_i you got as a result and just return these as the answer. It's not the right answer, but it's the "best" answer you can come up with, to match desired torque as closely as possible given thrusters you have.

Edited December 27, 2017 by K^2

[PB666]

2 hours ago, K^2 said:

You guys are talking through each other. Every rigid body ever is simulated as a point mass + moment of inertia tensor. These aren't contradictory statements, because they describe two distinct degrees of freedom. You accumulate all forces as impulse against point-mass and all torque as change to the angular momentum.

My point was that inertial changes caused by changes in fuel are related through the point mass of the origin of the part (as its position from the crafts center), and he got in an argument about Unity game engine. Ideally even if the point mass was set at a distance the fuel would be applied through the volume (as per the collider) but it is clear that this does not happen in the game. I have made over 100 parts and I have seen this behavior multiple times in the game. The problem was amplified by the fact that Unity and Blender use two coordinate systems and until you get it set in your head in blender that X = -X, Y =-Z and Z = Y and that you need to both plan for the parts CoG _AND_, if the part is fueled, a compromise state.

The part once it is fueled that would approximate the CoG when fueled favoring the empty CoG. Here are examples of a part that I had trouble with. 1) it was zeroed on the side attachment point (close to where boom attached), caused problems on large tanks because thrusters not under mass and was more difficult to control (origin moved to over thruster seat). If the origin is set to high, then radial detachment will cause a collision. 2) the pipe (boom) was zeroed on one end meaning that its CoM was right next to the craft or 5 meters from the craft. This caused problem in making satellites that had balanced rotations (booms CoM was later centered but attachement became a problem) 3) that conical tank was zeroed on the bottom, which created problems in predicting how structures would detach, particularly when upside down on bottom of stacks.

 

2 hours ago, K^2 said:

1) Σ F_i x r_i = τ

2) Σ F_i = 0

3) 0 ≤ F_i ≤ F_{i max}

I think you mean the 2) Σ τ_i = 0 All force in his scheme are applied along horizontal plane, presumably in the direction of the viewer  so. But yeah that is what you have to do. But don't forget that is for an object not already rotating in some other way, if it is, then there is a term missing in #1.

The problem with the above that when a craft is landing it is considered to be an dynamic equilibrium state (when velocity is nearly unchanged to the moment of landing) gravity is acting as a force and thrust is counter balancing that. In his craft design the tanks are not above the CoM so as they burn the thrusters (two top) would acclerate rotation. So even if you get balance at t₀ by the time you land at T₁ your craft has already rotated.

2 hours ago, K^2 said:

The matrix R is the one you have to build from vectors r_i and u_i to match equations 1) and 2). You might have to write out these sums explicitly to see how the components fall into this matrix, then you can write a program to generate that matrix easily. If you don't know how to write down a system of linear equations as a matrix and solve it that way, look it up. You won't get anywhere in optimization without understanding that. Write some code to practice if you have to.

2 hours ago, K^2 said:

How do you solve that? Well, the thing that saves you from going full LP here is that the first two equations are just linear equations with F_i as your variables, and the saturation can be treated as happening one thruster at a time. Lets forget about saturation for a second and pretend that there is no maximum thrust. We just write down first two equations as a matrix equation.

T = RF

 
Since he already knows the center of mass then if the thruster output is the same for all there is a horizontal plane B crossing  t_b1 and t_b2 that has distance b and there is another horizontal T plane crossing t_t1 and t_t2 that is t distance from the horizontal plane 0 going through CoM. The  Throttle % in which the _t1 and t_t2 thrusters are fired is 100*b/t since B is closer than T to O. Anyone can do that, but that fuel burn is going to be the problem, its an inertial issue not a thrust issue. Im trying to convince him that his setup is unstable, that he needs to move the origin of his fuel parts closer to plane O if he want a more permanent nonrotational equilibrium. He should have his RCS tanks centering the center of gravity.

                  

Edited December 28, 2017 by PB666

[K^2]

18 minutes ago, PB666 said:

I think you mean the 2) Σ τ_i = 0

I've misread the original problem statement. Yeah, if you want to have non-zero acceleration with zero torque, you'd flip the constraints around. I was writing the post under assumptions that he wanted to achieve the opposite. Non-zero torque with zero linear acceleration. The approach is identical, though.

18 minutes ago, PB666 said:

The problem with the above that when a craft is landing it is considered to be an dynamic equilibrium state (when velocity is nearly unchanged to the moment of landing) gravity is acting as a force and thrust is counter balancing that.

If there are any additional forces, they simply have to be added to the equalities and consolidated in the constants column along with desired torque or net force. Although, gravity will generate zero net torque if you use CoG for your datum, which makes the rest a lot easier.

18 minutes ago, PB666 said:

Since he already knows the center of mass the if the output is the same for all there is a horizontal plane B crossing  t_b1 and t_b2 that has distance b and there is another horizontal T plane crossing t_t1 and t_t2 that is t distance from the horizontal plane 0 going through CoM the ratio of % in which the _t1 and t_t2 thrusters are fired is 100*b/t since B is closer than T to O. Anyone can do that, but that fuel burn is going to be the problem, its an inertial issue not a thrust issue. Im trying to convince him that his setup is unstable, that he needs to move the origin of his fuel parts closer to plane O if he want a more permanent nonrotational equilibrium. He should have his RCS tanks centering the center of gravity.

Yeah, I did not make an assumption about all forces being co-linear. I'm assuming arbitrary placement of RCS thrusters, each without a gimbal, as is common for reaction control. Perhaps, that's overkill for OP.

 

Edit: Maybe I should just write a control systems module for Unity. This seems to be a topic that keeps coming up, and the math in it always takes a while to explain.

Edited December 28, 2017 by K^2

[Deus Zed Machina]

Hooo boy that's a lot of replies. Thanks, everybody! I think part of the problem is that the unity object containing the thrusters is actually scaled unevenly (more across the y axis than x or z) so the distance value of each thruster from the CoM doesn't reflect its actual distance.

@K^2 Yeah, a module might be nice, since I'm not too familiar with matrix math myself (though I'm currently in college for game design so I'm sure it'll come up in one of my CS classes). For now, though, I'll just work through it. How hard can linear programming be, anyway?

Edited January 30, 2018 by Deus Zed Machina