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

[allmhuran]

Before you critique this example for being a symmetrical setup

I certainly wouldn't be critiquing it for being symmetrical. I might suggest, however, that a more efficient design would not have the RCS thrusters at x and 3x, but rather at 3x only (or 3x and 3.1x, say), and that is the penalty you are paying in this case.

If you're buiding a large ship and you need to attach multiple sections together (and believe me, I know about building large ships), then there are a couple of solutions I have used that are better than just leaving RCS units everywhere. The first is to use a dedicated tug to move pieces into place. The second is to put the "required for assembly" RCS units on decouplers and jettison them once the assembly is completed, leaving only the efficient, high-torque units far from the CoM in place.

[allmhuran]

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.

This wouldn't actuallly be a complete solution, and ZRM's math post to some extent explains why, although in his post he was talking about translation.

Let's say you invoke RCS to bring about a roll, which is a rotation. Then you want to hold to the constraints that torque around the other axes are zero, and translation forces are also zero. I think you have an unstated premise that the first of those two sets of constraints is trivially met, but in fact this will not case for all designs. That is to say, it is possible to try to invoke a rotation that results in a secondary rotation around another axis, depending on your RCS thruster positioning, which is shown by Sean's example. ZRM's solution can in principle deal with and correct for this as well. A purely lever-arm-compensated one would not (whether it be the original dev implementation or a nearest-normalized one per my OP), at least not completely or in all cases.

[Comrade Jenkens]

I usually have ASAS on while translating to help keep the craft pointing the same way.

I'd also like to see a similar system with engines to help make VTOLs feasible for most of the community.

[ZRM]

I usually have ASAS on while translating to help keep the craft pointing the same way.

I'd also like to see a similar system with engines to help make VTOLs feasible for most of the community.

If you look at my mod, it is already doing that (partially). For engines without gimbals, the problem to solve is in fact a simpler one than the one for RCS. I am currently in the process of adding gimbal support (which unfortunately is a much more complex problem), which will truly make almost all VTOLs work properly. Currently the mod is restricted to specific styles of design due to the lack of gimbal support.

[ZRM]

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.

My solution can be modified to be inexact and so save on fuel usage while compromising slightly on accuracy. You just need to change each of the equality constraints to a pair of inequalities that specify the permissible range of deviation from the desired value, e.g. torque on the x axis must be between t + ε and t - ε, where t is the target, and ε is the permissible deviation.

Edited July 24, 2013 by ZRM

[allmhuran]

I actually like your solution the way it is, I would just want to have it as a flight-computer-supported solution. That is to say, you can choose to have perfect balance if you carry a flight computer with you (which is extra weight, would require power, can be less efficient, yadda yadda). But having an imperfect but still helpful partial solution still using a linear program at its core as a base function does seem like it would accomplish all of the objectives I would want to have. Of course exactly what the permissible deviation might be would require playtesting... or tweakables!

[ZRM]

I actually like your solution the way it is, I would just want to have it as a flight-computer-supported solution. That is to say, you can choose to have perfect balance if you carry a flight computer with you (which is extra weight, would require power, can be less efficient, yadda yadda). But having an imperfect but still helpful partial solution still using a linear program at its core as a base function does seem like it would accomplish all of the objectives I would want to have. Of course exactly what the permissible deviation might be would require playtesting... or tweakables!

Not to derail the thread, but by the Kerbal Gods (Devs?) I wish tweakables would be implemented soon. I know there are alternative solutions, as demonstrated by Modular Fuel System, but a built-in system in the stock GUI would be very helpful.

[sanity]

This Would Only help with Translation RCS control, If you are trying to use your rcs to turn, then the system falls apart, it would be an incredibly fuel inefficient as your RCS would be weakest were you want it to be strongest and strongest where it would have the least effect

EDIT: OP Method

Edited July 24, 2013 by sanity

[ZRM]

This Would Only help with Translation RCS control, If you are trying to use your rcs to turn, then the system falls apart, it would be an incredibly fuel inefficient as your RCS would be weakest were you want it to be strongest and strongest where it would have the least effect

I presume you are not referring to my solution? See my mod for proof that it handles rotation perfectly.

Reply to your edit: Ok, thought so.

Edited July 24, 2013 by ZRM
Reply to edit in post 33.

[rryy]

Quoted from another thread:

In 0.21, Precision Mode also enables RCS balancing. It reduces unwanted torque when using linear RCS by scaling their power based on their distance to the pivot for the given input. We made it enable only in precision mode because it does reduce the total power you can get out of the RCS. That's kind of the point of precision mode already, so we felt it made sense.

[allmhuran]

This Would Only help with Translation RCS control, If you are trying to use your rcs to turn, then the system falls apart, it would be an incredibly fuel inefficient as your RCS would be weakest were you want it to be strongest and strongest where it would have the least effect

EDIT: OP Method

Your most effective RCS units for rotation are always the ones which are the greatest distance orthogonally from the axis of rotation passing through the CoM. For translations the distance of each RCS unit from the CoM is irrelevant with respect to efficiency, but is relevant with respect to balancing output. In other words, it's always best to have your RCS units far from the CoM and as balanced as possible.

If you are saying that the method proposed would make the units furthest from the CoM the weakest: yes, that's true. But that is how the system was previously implemented and, apparently, how it is going to be implemented in 0.21 (see below). My adjustment is precisely to avoid the situation you are describing (loss of effectiveness of the units that should be most effective) by basing the scaling against whichever RCS unit is closest to the CoM rather than basing each one on its absolute distance from the CoM. In other words, using my adjustment your far-from-CoM units can still be putting out a lot of oomph simply by having all of your RCS units far away.

Perhaps its still not clear, so let me do a comparison:

Original dev implementation: RCS thrust = 100% / absolute distance from CoM (subject to overthrust problem when absolute distance from CoM was less than 1)

Updated dev implementation: RCS thrust = 100% / (if absolute distance from CoM < 1 then 1 else absolute distance from CoM) (avoids overthrust problem by introducing a maximum threshold of 100%, but still makes distant RCS units weak)

Proposed implementation: RCS thrust = 100% / (distance from CoM / distance of nearest RCS unit from CoM). This avoids overthrust problem (since the nearest RCS unit would put out 100% / distance of nearest unit / distance of nearest unit, ie, 100%). But it also allows your RCS units far from the CoM to be putting out 100% thrust if they are, in fact, the closest units to the CoM. IE, you get an advantage if you are smart with your RCS placement, which is as it should be.

In 0.21, Precision Mode also enables RCS balancing. It reduces unwanted torque when using linear RCS by scaling their power based on their distance to the pivot for the given input.

So they're not doing a full solution per ZRM, rather still limiting it to lever arm compensation. And so the crux of the OP is indeed relevant. If all RCS units are scaled based on their absolute distance from the CoM (which seems to be implied by the quoted statement) then there is no thrust advantage to placing your RCS units far from the CoM (since they will be scaled down). This is why I made the suggestion to normalize against the unit which is closest to the CoM. IE, if *all* of your RCS units are far from the CoM then they can all be putting out nearly 100% thrust.

Edited July 24, 2013 by allmhuran

[hotcrazyfruit]

Hey, ZRM, do you think it is possible to implement a system where by selecting "control from here" on any given part, you could re-program the ship to rotate about that point?

Perhaps we have similar ideas but with slight variances, as I do not see how the solution I will describe below could be wasteful as pointed out by allmhuran regarding ZRM's solution. I apologize in advance for any confusion that may be imparted within the description, I can be bad at spitting idea's out >_>

I will refer to the 4 directions (x left, x right, y up, y down, about the CoM) as arms.

What I was intending to say was that whichever arm had the least torque moment would be firing maximum, with the other three arms firing to match this torque moment during translation, such that the net torque across all axes is 0. I believe your math solution would end up with a similar scenario, however I am slightly confused as to why the solution would be wasteful as pointed out by allmhuran. If each arm is only putting out the torque moment of the arm with the least, there is no compensating to be done. It would be a nice perfect push in whatever direction.

Edited July 24, 2013 by hotcrazyfruit

[ZRM]

Hey, ZRM, do you think it is possible to implement a system where by selecting "control from here" on any given part, you could re-program the ship to rotate about that point?

Yes, very possible. Not that much work on top of my existing mod, either. I did have it on the roadmap for my mod at one point, but engine balancing has sort of become the main priority.

Perhaps we have similar ideas but with slight variances, as I do not see how the solution I will describe below could be wasteful as pointed out by allmhuran regarding ZRM's solution. I apologize in advance for any confusion that may be imparted within the description, I can be bad at spitting idea's out >_>

I will refer to the 4 directions (x left, x right, y up, y down, about the CoM) as arms.

What I was intending to say was that whichever arm had the least torque moment would be firing maximum, with the other three arms firing to match this torque moment during translation, such that the net torque across all axes is 0. I believe your math solution would end up with a similar scenario, however I am slightly confused as to why the solution would be wasteful as pointed out by allmhuran. If each arm is only putting out the torque moment of the arm with the least, there is no compensating to be done. It would be a nice perfect push in whatever direction.

In calculating the required RCS thrusts to satisfy each of these 'arms', you must remember that they are practically never independent. Changing the RCS thrusts to reach the required torque on one 'arm' will in practice inevitably change the torque on the other arms, as RCS ports are practically never perfectly aligned or parallel to each other, especially on designs with sloped surfaces. You would never get a 'perfect push'.This is where the need for a solver comes in. The 'inefficiency' of my solution is that it always finds a perfect solution, possibly at the expense of expending more fuel to counterbalance imperfect port layouts. However, as I explained in post 30, my solution can be modified to accommodate a range of permissible deviation from the perfect solution. So any perceived 'inefficiency' is removed.

[hotcrazyfruit]

In calculating the required RCS thrusts to satisfy each of these 'arms', you must remember that they are practically never independent. Changing the RCS thrusts to reach the required torque on one 'arm' will in practice inevitably change the torque on the other arms, as RCS ports are practically never perfectly aligned or parallel to each other, especially on designs with sloped surfaces. You would never get a 'perfect push'.This is where the need for a solver comes in. The 'inefficiency' of my solution is that it always finds a perfect solution, possibly at the expense of expending more fuel to counterbalance imperfect port layouts. However, as I explained in post 30, my solution can be modified to accommodate a range of permissible deviation from the perfect solution. So any perceived 'inefficiency' is removed.

I understand what you are saying, however shouldn't the snap to angle tool in the VAB be good enough to ensure ports are parallel to each other and so forth? (as well as a minimum of design quality to ensure you don't have RCS ports at weird angles).

I do not understand, however, the notion that changing the RCS thrust on one arm will change the others in a way that breaks the solution. That part just doesn't add up in my mind :S

[DannySwish]

I haven't looked too closely at this thread, so my apologies if this is already known or irrelevant by this point, but after the KSP-TV livestream a few days ago (or whenever), in the chat, C7 mentioned that he was working on the whole lever arm thing at that very moment.