RCS: Closest RCS unit to CoM gets 100% thrust, then scale down for lever arm

[allmhuran]

Not sure if this is, in fact, how RCS will be handled in 0.21, I heard that they are bringing back lever arm compensation.

I was just thinking that if *all* RCS thrusters are lever-arm compensated (by simply scaling them based on distance from CoM) then there would be no advantage to placing your RCS ports away from the centre of mass for additional torque. This would be a problem for larger ships.

So the solution, it seems, would be to have it so that the RCS unit *closest to the center of mass gets 100% thrust*, and then the rest are scaled down the further from the CoM they are compared to that RCS unit.

This would mean that if you did the "right thing" for big ships and placed *all* your RCS thrusters far from the CoM you would still get the benefit of additional lever-arm torque (since they will all be putting out close to 100% thrust), but lever arm compensation would still mean you would not get unbalanced RCS forces.

Anyone know if this is, in fact, what is going to be coming?

[Brenok]

I don't quite understand what you're proposing. Why would you want for distant RCS thrusters to get less thrust?

[allmhuran]

Yeah, sorry, it's a bit hard to explain.

RCS can create unbalanced forces depending on how you position the units. Here is a contrived example:

I have marked the RCS units A and B.

The distance from the CoM to A is, say, x.

The distance from the CoM to B is 3x.

If you are flying this vessel and try to translate to the right, both A and B will fire. But since B is much further from the CoM than A, this will introduce a torque that will cause the ship to yaw to the left while translating right. It won't hold orientation.

In an earlier version of KSP the force imparted by RCS units was subject to a divisor that was dependent on how far they were from the CoM, a technique dubbed "lever arm compensation". The idea behind this was that you did not need to perfectly balance your RCS units to get balanced forces. The implementation created a problem, though: if you put your RCS units very, very close to the CoM, then the divisor would be less than 1. As a result, the RCS unit force would be multiplied. An RCS unit that was 0.1 units of distance away from the CoM would put out a force equal to 100% / 0.1, or 1000% RCS force. You could actually make rockets with ridiculous thrust simply by getting your RCS units closer and closer to the CoM.

There is talk of bringing back lever arm compensation, which I think is a good idea. However, I'm not sure how it is going to be implemented. I heard, for example, that it would only be enabled in docking mode or some such.

Rather than put on such limitations (heck, I never use docking mode and don't really see the point of it), I propose that a better solution to the RCS overthrust bug would be to normalize RCS units based on whichever one is closest to the CoM. Taking that picture again, let's say that RCS unit "A" is (say) 0.5 units from the CoM. Since it is the closest unit to the CoM, it gets 100% thrust. Any other units are then normalized against this one. So since RCS unit B is 1.5 units from the CoM, it should output 1/3rd as much thrust as RCS unit A.

With this implementation, the further away your closest RCS port to the CoM is, the better. A such there are still design considerations to be made.

This method would retain the efficiency gains that clever designs can have when RCS units are placed far from the CoM without re-introducing the RCS overthrust problem. The fix is to base lever arm compensation on distance relative to the closest-to-CoM RCS unit instead of basing the compensation on the absolute value of the distance to the CoM.

Edited July 23, 2013 by allmhuran

[tntristan12]

AFAIK, this is planned. I could be wrong though. I would like to see it, however. It doesn't seem like it'd be *that* difficult to implement partially, if not fully.

[allmhuran]

A perfect implementation would be more complex than my contrived example: it would actually need to normalize for each axis based on the orthogonal distance of the active RCS units from the axis passing through the CoM. Taking my contrived picture, again, both units are actually equidistant from the long axis through the ship, which is the axis we care about if we wanted to impart a roll, for example.

However, I'm not sure going that far is necessary. Using a simpler, absolute distance from CoM irrespective of the direction of thrust imparted is probably still going to be of assistance, and leaves the player with some design challenges (a good thing IMO).

[stupid_chris]

Balancing RCS thrusters is planned. In fact, it's even on the do not suggest list if I remember correctly.

[allmhuran]

Per my original post, I am not asking if it is planned. I even stated that I had heard lever arm compensation was returning. I do not know how that was not obvious.

The question, or suggestion, is regarding the specific implementation details.

[allmappedout]

I have a feeling that the SAS upgrades will resolve a significant amount of the issues we're currently having, change or not.

[stupid_chris]

They removed in .18 because it caused RCS ports that were close to the CoM to get a ridiculous amount of power. I didn't hear about it being planned to come back any time soon. The new SAS logic will permit the SAS unit to not throttle the RCS units to the max at all time, but nothing concerning balancing them automatically as far as I know.

Just a small thing: if you intended to talk about specific details of implementation rather than suggesting it, the discussion tag would've been better than the suggestion tag

[allmhuran]

The inability of netizens to read is astonishing no matter how often one encounters the phenomemon.

[ZRM]

In the mean time, you can use my RCS balancing mod, as linked in my signature. RCS balancing is in fact much more complex than just lever arms - it's a Constrained Linear Program. My mod uses a mathematical solver to balance everything.

[stupid_chris]

The inability of netizens to read is astonishing no matter how often one encounters the phenomemon.

It's not because you're using fancy words that you can act like this. I did read your proposition, I know you said it shouldn't be scaled to give more thrust near the CoM, but just to scale it to get to 100% when it is at the CoM. I did get this. I simply stated why it was removed, and I really don't get why you are getting angry at me. I was being nice, so try being nice in return if you want people to actually listen to you and help you push your propositions further. You had no reason to snap at me like this.

Edited July 23, 2013 by stupid_chris

[allmhuran]

ZRM: Yes indeed, per an earlier post of mine the requirements of a fully balanced implementation are beyond the solution I have presented, but I think this solution provides the combined advantages of making RCS more balanced without causing any overthrust issues but, at the same time, does not remove all of the challenges from the player and leaves them with some important design choices for maximizing RCS torque and efficiency, which I think is important (but your mod is excellent at what it does!)

chris: That you felt the need to point out the overthrust problem with the previous implementation demonstrates that you have not, in fact, read the thread, because this exact problem with the previous implementation is the entire reason for this thread, it is something I have already described in detail in this thread, and the details of this alternative implementation as described in what I have written is designed specifically to overcome this problem while still allowing RCS to be somewhat autobalanced and giving builders an advantage if they build for efficient use of RCS. And I got angry because I hate repeating myself like this (I have to do it all the time at work and the frustration doesn't shake off straight away when I get home, sorry about that).

[ZRM]

ZRM: Yes indeed, per an earlier post of mine the requirements of a fully balanced implementation are beyond the solution I have presented, but I think this solution provides the combined advantages of making RCS more balanced without causing any overthrust issues but, at the same time, does not remove all of the challenges from the player and leaves them with some important design choices for maximizing RCS torque and efficiency, which I think is important (but your mod is excellent at what it does!)

My mod does not negate the need to design crafts well. You still need to make good choices to maximise efficiency, it's just that you will no longer have to fight the system while using it.

[hotcrazyfruit]

The inability of netizens to read is astonishing no matter how often one encounters the phenomemon.

This is the cancer that is killing the kerbal forum for me. The arrogance being thrown around is *astonishing*.

as per the topic of the thread, I disagree with this method of balancing RCS thrust particularly when considering space stations. If I am building a space station, I generally throw some RCS thrusters onto the first module. Each module I have after that will have reduced RCS thrust. I think there is a better way to do it, frankly.

All that needs to happen is that Torque to the left of CoM = Torque to the right of CoM yours DOES do this, however read on.

In your solution, if we have a thruster at x and 3x left of CoM, and the exact same to the right, the thrusters at x will give 1N and those at 3x will give just 0.33N. Total thrust would be 2.66N, rather than 4N if they all fired full; which they can since the craft is symmetrical.

Before you critique this example for being a symmetrical setup, remember there will be symmetries in rockets people build, where using the lever arm will cause these losses. The solution is to calculate the minimum torque on either side of CoM, and have the side with higher torque fire at the torque of the lower side. This will provide a balanced thrust, at maximum capability.

Nick

Edited July 23, 2013 by hotcrazyfruit

[goldenpeach]

A simple way to have both advantages:

When the RCS are used for translation,the RCS are lever-arm compensated.

When the RCS are used for rotation,the RCS aren't lever-arm compensated.

Another wayt is to make the compensation togglable by the user,in that way the user could choose to have lever-arm compensation for rotation.

[ZRM]

as per the topic of the thread, I disagree with this method of balancing RCS thrust particularly when considering space stations. If I am building a space station, I generally throw some RCS thrusters onto the first module. Each module I have after that will have reduced RCS thrust. I think there is a better way to do it, frankly.

All that needs to happen is that Torque to the left of CoM = Torque to the right of CoM yours DOES do this, however read on.

In your solution, if we have a thruster at x and 3x left of CoM, and the exact same to the right, the thrusters at x will give 1N and those at 3x will give just 0.33N. Total thrust would be 2.66N, rather than 4N if they all fired full; which they can since the craft is symmetrical.

Before you critique this example for being a symmetrical setup, remember there will be symmetries in rockets people build, where using the lever arm will cause these losses. The solution is to calculate the minimum torque on either side of CoM, and have the side with higher torque fire at the torque of the lower side. This will provide a balanced thrust, at maximum capability.

Nick

As I mentioned above, the proper way to calculate the correct thrusts is to solve the constrained linear system that represents the effects of each RCS port, instead of working with heuristics that only balance symmetrical crafts, or only balance in one axis. My mod KerbCom Avionics does this. The currently released version is slightly inaccurate in some cases due to floating point errors, but I have improved upon this greatly for the next version.

[Sean Mirrsen]

Indeed, the "lever arm compensation" thing is absolutely silly. What it combats is the tendency of spacecraft to drift or turn in unpredictable ways if the RCS thrusters aren't perfectly positioned. Or rather, that's what it supposedly combats, because... well let's see. I guess the HarrowJet is bound to be my go-to craft for any given theoretical explanation around here. It's a non-contrived, not-oversimplified, not-unrealistic example.

RCS thrusters litter the surface of this craft. There are thrusters on the nose, the wings, the sides of the engine pods, etc. Now, some thought actually went into constructing this one - it pitches and rolls pretty well. But it has a problem with yaw, seeing how most of its mass is in the rear, and the only thing way past the CoM to compensate the lever force of the nosecone RCS is the tail. Which is, for aerodynamic lift purposes, lifted high up. So whenever it tries to yaw, the extra bit of thrust from the tail elevation starts rolling it.

How does the lever arm compensation fight this? There is literally no way to somehow make the craft not roll by using less thrust - the only RCS units capable of effecting yaw on the HarrowJet are the ones on the nosecone (which is also a shuttlepod, so no it can't have those repositioned), and the ones on the tail - and the centerpoint between them is nowhere near the center of mass. If whichever system tried to calculate the necessary forces to prevent the craft from rolling while turning, it would inevitably come to the conclusion that neither thruster set could exert any force. If it had a fail-safe for that occasion, or just used a "less force from CoM" approach, it would just fail to do its thing.

But curiously, the solution already exists. In fact, we've had it for a long time, it was just a wee bit broken and we're getting it upgraded in the next update. A flight computer, which in this case is folded into the A/SAS, will attempt to maintain the orientation of the craft. It won't do this through fancy calculations (well, not of the positions and thrust of RCS blocks at least), but through the sheer determination to maintain orientation. It won't use less thrust, not on the thrusters performing yaw. But it will compensate with thrusters performing roll - it'll just gently roll the craft as you adjust yaw, preventing it from tilting sideways. That is the only solution we need here. It's nice and simple to use, and won't inhibit the craft's mobility.

Edited July 23, 2013 by Sean Mirrsen

[Anton P. Nym]

I use a simple expedient of putting a proportionate number of RCS packs depending upon distance from CoM: if one ring of RCS is "x" distance from CoM and another is "2x" away, I use twice the RCS packs on the first. It mostly works, though of course the current ASAS isn't terribly happy with that arrangement.

Modulating the thrust would be more elegant, of course. That, or introducing RCS packs of differing strength... but that way leads to parts-madness, I think.

-- Steve

edited to add: Or could RCS strength be one of the "tweakables" coming in a future update?

Edited July 23, 2013 by Anton P. Nym
adding a late thought

[hotcrazyfruit]

As I mentioned above, the proper way to calculate the correct thrusts is to solve the constrained linear system that represents the effects of each RCS port, instead of working with heuristics that only balance symmetrical crafts, or only balance in one axis. My mod KerbCom Avionics does this. The currently released version is slightly inaccurate in some cases due to floating point errors, but I have improved upon this greatly for the next version.

Could you briefly describe what exactly a constrained linear system is? I'm no mathematician however I do understand working physics quite well. Is there any chance that a constrained linear system is, at its working level, what I am describing? We're kind of working from opposite ends of theory here

[mythbusters844]

I remember on the livestream special that lever-arm compensation on translations for RCS would only be available in docking mode IIRC.

[stupid_chris]

chris: That you felt the need to point out the overthrust problem with the previous implementation demonstrates that you have not, in fact, read the thread, because this exact problem with the previous implementation is the entire reason for this thread, it is something I have already described in detail in this thread, and the details of this alternative implementation as described in what I have written is designed specifically to overcome this problem while still allowing RCS to be somewhat autobalanced and giving builders an advantage if they build for efficient use of RCS. And I got angry because I hate repeating myself like this (I have to do it all the time at work and the frustration doesn't shake off straight away when I get home, sorry about that).

Yes, I felt the need to point it again, even though you had mentioned it in your mile long post. And in no way was that a crime. I did so because it was bringing to the fact of why they removed it and why it was on the do not suggest list. Even though you had mentioned it. That's still no reason to snap off like this. Also, for further info to you: When someone posts in a or your thread, you shouldn't expect them to have read nothing more but the OP. If additional information is in a post further on, you can't expect them to read every one of them. So if you don't like repeating, don't start threads like this. Lastly, know this: if you are going to be arrogant like this to people who were being nice to you, you won't be appreciated here.

[FS3D]

Yes, I felt the need to point it again, even though you had mentioned it in your mile long post. And in no way was that a crime. I did so because it was bringing to the fact of why they removed it and why it was on the do not suggest list. Even though you had mentioned it. That's still no reason to snap off like this. Also, for further info to you: When someone posts in a or your thread, you shouldn't expect them to have read nothing more but the OP. If additional information is in a post further on, you can't expect them to read every one of them. So if you don't like repeating, don't start threads like this. Lastly, know this: if you are going to be arrogant like this to people who were being nice to you, you won't be appreciated here.

I concur with this.

[ZRM]

Could you briefly describe what exactly a constrained linear system is? I'm no mathematician however I do understand working physics quite well. Is there any chance that a constrained linear system is, at its working level, what I am describing? We're kind of working from opposite ends of theory here

I think I prefer thorough to brief. Though this explanation is not that long.

A constrained linear system is properly called a constrained linear program (CLP). I didn't call it that previously as you may have misunderstood the meaning of "program". In maths its meaning is entirely different to the meaning of a computer program.

A CLP is a set of linear constraints and a linear objective function. A linear constraint is an (in)equality of the form linear function = constant, linear function <= constant or linear function >= constant. And a linear function is a sum of multiples of its continuous real variables, e.g. f(x,y,z) = ax + by + cz, where x, y and z are the variables, and the constants a, b and c are the coefficients to multiply the variables by. The goal of a CLP is to find the value to give to each variable in order to maximise or minimise (depending on the problem) the objective function, while simultaneously satisfying the constraints. For example,

Maximise z = 15x + 10y, subject to:

x <= 2

y <= 3

x + y <= 4

(The solution, by the way, is x = 2, y = 2, z = 50)

Balancing RCS thrust is, at its heart, a very well formed CLP, just like the one above, but with more variables and more constraints. And no, it is not, at its working level, what you are describing, as you are only treating one set of special cases.

Edit: Actually, reading your post again, you might actually be getting sort of the right idea, though some of it is not quite clear to me. You may want to explain it again.

If you wish to maintain a specific thrust in a specific direction, with no rotation, you have exactly 6 constraints:

1. 0 net torque around the x axis
   
2. 0 net torque around the y axis
   
3. 0 net torque around the z axis
   
4. a net thrust in the x direction
   
5. b net thrust in the y direction
   
6. c net thrust in the z direction
   

where (a,b,c) is the desired thrust vector.

You also have the objective - to minimise the (non-vector) sum of the thrust of each port, so as to minimise fuel usage. The variables are the percentage values of each port's thrust.

You now need to determine the coefficients of the variables in the constraints, and the objective.

For directional thrust constraints, you calculate the component of each RCS port's thrust coefficient (maximum thrust * direction) in the required axis.

For rotational thrust constraints, you calculate the moment of that thrust coefficient around the required axis.

For the objective, you just sum the maximum thrust times each variable.

So now you just need to solve the system. Luckily there are several efficient algorithms for doing so. I have implemented 2 of these. One (known as the Primal Simplex Method) is available in the current released version of my mod. Look at the source for details.

Edit: By the way, my mod also solves for specific torque and thrust combinations, not just thrust. It also finds the range of torque and thrust the vessel can provide using other CLPs, so that values can be chosen for the final constraints that are definitely solvable.

Edited July 24, 2013 by ZRM

[allmhuran]

ZRM's solution is definitely the complete, flight-computer-esque solution. And of course, if anyone doesn't want to have everything worked out for them, they can simply not use the mod. So as far as it goes, it's a really excellent way to accomplish one of the goals here, which is to balance RCS output.

As per the point of the thread, we haven't heard what the actual implementation by the devs is going to be. The problem may be that a complete solution as described by Sean or by ZRM's mod can use monopropellant inefficiently (that is to say, some RCS jets may fire simply in order to compensate for the firing of other RCS jets) to achieve a perfectly balanced solution. A middle ground between what we have now, and a solution like that, is one that simply balances for distance from CoM, just like the original dev implementation, but tweaked to not create overthrust.

Yes, this would mean Sean's aircraft would still have control issues if relying purely on the simple balancing approach. But that's fine... if you want to design a craft that cannot inherently balance its RCS output no matter how much lever arm compensation is involved, then you can choose to wear the cost of a flight computer assisted RCS that burns more monopropellant. In other words, the best of both worlds can exist. I don't think there can be any objection to such a state of affairs.

Lastly, know this: if you are going to be arrogant like this to people who were being nice to you, you won't be appreciated here.

Thanks for your continuing non-contribution.