Wanted: Math genius - balance a lever with a moving fulcrum

[Fengist]

Ok, here's the mathematical description of my problem. I have a basic lever that I'm trying to balance. I'm looking for a formula (for a non math genius) to plug into C#. The lever has mass on both ends and a fulcrum somewhere in the middle. I can add and subtract to the total mass of both (equally) and/or move any amount of mass, repeatedly, from one end to the other. I can get the distance of either mass to the fulcrum. The problem is, as I move the mass, the fulcrum (CoM) moves too. So the standard lever calculation (M1 x D1 = M2 x D2) won't work.

Here's the data I can get:

M1 - Mass of one side

M2 - Mass of the other side

D1 - Distance from M1 to the CoM

D2 - Distance from M2 to the CoM

A1 - Altitude of M1

A2 - Altitude of M2

And I can probably come up with other numbers if it'll make the calculations easier.

There are other parts on the vessel that do add mass but it's insignificant enough that if I can get it close to balance, SAS can hold it there.

KSP description of the problem:

I have a Submarine. I have between 0 and 40 tons of ballast at the bow and the stern. I'm trying to even the keel by moving the ballast between the two.

Here's a sample of my output so you can see the CoM moving. In this output, every 2 seconds I'm moving 0.25 tons back and forth between P1 and P2 depending on altitude. If the altitude is higher, I move 0.25 tons to that part from the other.

Px Distance is the distance of each part to the CoM P1 is the bow, P2 is the stern.

The pitch is apparently +1 for up, -1 for down (FlightGlobals.ActiveVessel.ctrlState.pitch). Oddly, you can see it pass through 0 but the altitude of the parts doesn't seem to agree with that.

The numbers after the 'Autokeel Running' are the altitude of the two parts (below sea level) P1 and P2 respectively

You'll notice as mass is moved from P2 to P1, the altitude of P1 decreases and... so does it's distance to the CoM.

Thanks in advance.

Oh, and I forgot the mention. This 'lever' could be moving forward, backward, turning, diving, etc.

10/9/2015 9:27:49 PM: P1 Distance: 22.78061
10/9/2015 9:27:49 PM: P2 Distance: 39.16152
10/9/2015 9:27:49 PM: pitch: 1
10/9/2015 9:27:49 PM: [Maritime Pack] Autokeel Running-347.5625 -408.625
10/9/2015 9:27:51 PM: P1 Distance: 22.50758
10/9/2015 9:27:51 PM: P2 Distance: 39.43423
10/9/2015 9:27:51 PM: pitch: 1
10/9/2015 9:27:51 PM: [Maritime Pack] Autokeel Running-345.125 -406.75
10/9/2015 9:27:53 PM: P1 Distance: 22.23421
10/9/2015 9:27:53 PM: P2 Distance: 39.70741
10/9/2015 9:27:53 PM: pitch: 1
10/9/2015 9:27:53 PM: [Maritime Pack] Autokeel Running-342.8125 -404.625
10/9/2015 9:27:55 PM: P1 Distance: 21.96077
10/9/2015 9:27:55 PM: P2 Distance: 39.98074
10/9/2015 9:27:55 PM: pitch: 1
10/9/2015 9:27:55 PM: [Maritime Pack] Autokeel Running-340.5625 -402.375
10/9/2015 9:27:57 PM: P1 Distance: 21.88637
10/9/2015 9:27:57 PM: P2 Distance: 40.05509
10/9/2015 9:27:57 PM: pitch: 1
10/9/2015 9:27:57 PM: [Maritime Pack] Autokeel Running-338.375 -400.25
10/9/2015 9:27:59 PM: P1 Distance: 21.61186
10/9/2015 9:27:59 PM: P2 Distance: 40.32959
10/9/2015 9:27:59 PM: pitch: 1
10/9/2015 9:27:59 PM: [Maritime Pack] Autokeel Running-337 -398.625
10/9/2015 9:28:01 PM: P1 Distance: 21.33866
10/9/2015 9:28:01 PM: P2 Distance: 40.60279
10/9/2015 9:28:01 PM: pitch: 1
10/9/2015 9:28:01 PM: [Maritime Pack] Autokeel Running-336.1875 -397.5625
10/9/2015 9:28:03 PM: P1 Distance: 21.06656
10/9/2015 9:28:03 PM: P2 Distance: 40.87495
10/9/2015 9:28:03 PM: pitch: 1
10/9/2015 9:28:03 PM: [Maritime Pack] Autokeel Running-336 -396.9375
10/9/2015 9:28:05 PM: P1 Distance: 20.79544
10/9/2015 9:28:05 PM: P2 Distance: 41.14615
10/9/2015 9:28:05 PM: pitch: 1
10/9/2015 9:28:05 PM: [Maritime Pack] Autokeel Running-336.4375 -396.5625
10/9/2015 9:28:07 PM: P1 Distance: 20.52509
10/9/2015 9:28:07 PM: P2 Distance: 41.4166
10/9/2015 9:28:07 PM: pitch: 1
10/9/2015 9:28:07 PM: [Maritime Pack] Autokeel Running-337.25 -396.1875
10/9/2015 9:28:09 PM: P1 Distance: 20.25548
10/9/2015 9:28:09 PM: P2 Distance: 41.68639
10/9/2015 9:28:09 PM: pitch: 1
10/9/2015 9:28:09 PM: [Maritime Pack] Autokeel Running-338.625 -395.75
10/9/2015 9:28:12 PM: P1 Distance: 19.98667
10/9/2015 9:28:12 PM: P2 Distance: 41.95547
10/9/2015 9:28:12 PM: pitch: -0.4172428
10/9/2015 9:28:12 PM: [Maritime Pack] Autokeel Running-340.5625 -394.9375
10/9/2015 9:28:14 PM: P1 Distance: 19.71875
10/9/2015 9:28:14 PM: P2 Distance: 42.22372
10/9/2015 9:28:14 PM: pitch: -1
10/9/2015 9:28:14 PM: [Maritime Pack] Autokeel Running-343.0625 -393.5625
10/9/2015 9:28:16 PM: P1 Distance: 19.45182
10/9/2015 9:28:16 PM: P2 Distance: 42.49113
10/9/2015 9:28:16 PM: pitch: -1
10/9/2015 9:28:16 PM: [Maritime Pack] Autokeel Running-346.3125 -391
10/9/2015 9:28:18 PM: P1 Distance: 19.18616
10/9/2015 9:28:18 PM: P2 Distance: 42.75744
10/9/2015 9:28:18 PM: pitch: -1
10/9/2015 9:28:18 PM: [Maritime Pack] Autokeel Running-350.5 -386.6875
10/9/2015 9:28:20 PM: P1 Distance: 18.92196
10/9/2015 9:28:20 PM: P2 Distance: 43.0225
10/9/2015 9:28:20 PM: pitch: -0.5546433
10/9/2015 9:28:20 PM: [Maritime Pack] Autokeel Running-355.75 -380.125
10/9/2015 9:28:22 PM: P1 Distance: 18.65931
10/9/2015 9:28:22 PM: P2 Distance: 43.28622
10/9/2015 9:28:22 PM: pitch: -0.6652656
10/9/2015 9:28:22 PM: [Maritime Pack] Autokeel Running-362.3125 -370.75

Edited October 10, 2015 by Fengist

[steuben]

you have too many variables. a side effect of thinking in code rather than thinking math or physics

try this:

assuming your system is closed. no ballast from the outside or changing length of craft.

D2+D1 = L which is the length of your ship

M2+M1 = B which is the total amount of ballast

means your equation becomes

(L-D1)*(B-M1) = D1*M1

[Diazo]

I don't think there's enough info there to help, I would comment on two things though.

1) FlightGlobals.ActiveVessel.ctrlState.pitch is the input command being passed to KSP, it has no relation to what is going on in the game world. Pressing 'W' will put this at 1, 'S' at -1. I'm assuming what is printing there is what the SAS is passing to get a partial number like that.

2) When you talk about distance to CoM moving on a 'fixed' reference point, I would suspect that you are getting bad data somewhere. KSP has a very confusing co-ordinate system and if you could post the code you are using that would let us double check that for you. (Or are you are using CoM and fulcrum interchangebly? Those two things are not the same.)

D.

[Fengist]

you have too many variables. a side effect of thinking in code rather than thinking math or physics

try this:

assuming your system is closed. no ballast from the outside or changing length of craft.

D2+D1 = L which is the length of your ship

M2+M1 = B which is the total amount of ballast

means your equation becomes

(L-D1)*(B-M1) = D1*M1

That's the theory I'm working on now but I'm having to put in some effort to reduce the accuracy of the calculations. Calculating the length twice I get both

61.9436302185059

And...

61.9439220428467

And with that many decimal points, if I transfer the resource often it creates or evaporates the resource. So, I'm working on that.

- - - Updated - - -

I don't think there's enough info there to help, I would comment on two things though.

1) FlightGlobals.ActiveVessel.ctrlState.pitch is the input command being passed to KSP, it has no relation to what is going on in the game world. Pressing 'W' will put this at 1, 'S' at -1. I'm assuming what is printing there is what the SAS is passing to get a partial number like that.

2) When you talk about distance to CoM moving on a 'fixed' reference point, I would suspect that you are getting bad data somewhere. KSP has a very confusing co-ordinate system and if you could post the code you are using that would let us double check that for you. (Or are you are using CoM and fulcrum interchangebly? Those two things are not the same.)

D.

Thanks, that explains the odd results I'm seeing with the pitch.

Yes, I'm using CoM and the fulcrum interchangeably. I'm assuming the CoM would be the fulcrum. If not, then where would the fulcrum be? Center of Buoyancy?

When I get the code a bit more solidified I'll post it. But for now, I'm finding the distance to the CoM via:

Vector3.Distance(Part1.transform.position, FlightGlobals.ActiveVessel.CoM)

Edited October 10, 2015 by Fengist

[Fengist]

Ok, here's what I came up with but it's way off.

totaldistance - vessel length

total mass - mass of both resources (1 unit = 1 ton)

P1length & P2length - distance to the CoM for that part

p1goal2 - the amount of resource the part should have to achieve balance.

p1difference - the difference between how much resource Part1 should have and how much it does have (i.e. the amount to transfer from Part2).

decimal totaldistance = decimal.Round((decimal)Vector3.Distance(Part1.transform.position, FlightGlobals.ActiveVessel.CoM) + (decimal)Vector3.Distance(Part2.transform.position, FlightGlobals.ActiveVessel.CoM),2);

decimal totalmass = decimal.Round((decimal)MPFunctions.GetResourceAmount(Part1, "CompressedWater") + (decimal)MPFunctions.GetResourceAmount(Part2, "CompressedWater"),2);

decimal P1length = decimal.Round((decimal)Vector3.Distance(Part1.transform.position, FlightGlobals.ActiveVessel.CoM), 2);

decimal P2length = decimal.Round((decimal)Vector3.Distance(Part2.transform.position, FlightGlobals.ActiveVessel.CoM), 2);

decimal p1goal = decimal.Round((totaldistance - P1length) * (totalmass - (decimal)MPFunctions.GetResourceAmount(Part1, "CompressedWater")),2);

decimal p1goal2 = decimal.Round((decimal)MPFunctions.GetResourceAmount(Part1, "CompressedWater") / p1goal,2);

decimal p1difference = decimal.Round(p1goal2 - (decimal)MPFunctions.GetResourceAmount(Part1, "CompressedWater"),2);

int id = MPFunctions.GetResourceID(Part1, "CompressedWater");

Part1.TransferResource(id, (float) p1difference);

Part2.TransferResource(id, (float) -p1difference);

MPLog.Writelog("TD: " + totaldistance + " TM: " + totalmass + " p1goal: " + p1goal2 + " p1difference: " + p1difference + " P1amt: " + MPFunctions.GetResourceAmount(Part1, "CompressedWater") + " P2amt: " + MPFunctions.GetResourceAmount(Part2, "CompressedWater"));

MPLog.Writelog("P1 CoM distance: " + Vector3.Distance(Part1.transform.position, FlightGlobals.ActiveVessel.CoM) + MPFunctions.GetResourceAmount(Part1, "CompressedWater") + " P2 CoM distance: " + Vector3.Distance(Part2.transform.position, FlightGlobals.ActiveVessel.CoM) + MPFunctions.GetResourceAmount(Part2, "CompressedWater"));

Events["ActivateEvent"].active = true;

Events["DeactivateEvent"].active = false;

And here's the log output.

10/10/2015 10:32:43 AM: TD: 61.95 TM: 44.45 p1goal: 0.05 p1difference: -30.55 P1amt: 0.0500000230968531 P2amt: 40
10/10/2015 10:32:43 AM: P1 CoM distance: 19.246330.0500000230968531 P2 CoM distance: 42.7001540
10/10/2015 10:32:54 AM: TD: 61.95 TM: 40.05 p1goal: 0.00 p1difference: -0.05 P1amt: 2.23517950814767E-08 P2amt: 40
10/10/2015 10:32:54 AM: P1 CoM distance: 50.950742.23517950814767E-08 P2 CoM distance: 10.9996340
10/10/2015 10:32:55 AM: TD: 61.95 TM: 40.00 p1goal: 0.00 p1difference: 0.00 P1amt: 2.23517950814767E-08 P2amt: 40
10/10/2015 10:32:55 AM: P1 CoM distance: 51.015912.23517950814767E-08 P2 CoM distance: 10.9334740
10/10/2015 10:32:55 AM: TD: 61.95 TM: 40.00 p1goal: 0.00 p1difference: 0.00 P1amt: 2.23517950814767E-08 P2amt: 40
10/10/2015 10:32:55 AM: P1 CoM distance: 51.022242.23517950814767E-08 P2 CoM distance: 10.926740
10/10/2015 10:32:56 AM: TD: 61.95 TM: 40.00 p1goal: 0.00 p1difference: 0.00 P1amt: 2.23517950814767E-08 P2amt: 40
10/10/2015 10:32:56 AM: P1 CoM distance: 51.026592.23517950814767E-08 P2 CoM distance: 10.9221540
10/10/2015 10:32:56 AM: TD: 61.95 TM: 40.00 p1goal: 0.00 p1difference: 0.00 P1amt: 2.23517950814767E-08 P2amt: 40
10/10/2015 10:32:56 AM: P1 CoM distance: 51.028862.23517950814767E-08 P2 CoM distance: 10.9198240
10/10/2015 10:32:56 AM: TD: 61.95 TM: 40.00 p1goal: 0.00 p1difference: 0.00 P1amt: 2.23517950814767E-08 P2amt: 40
10/10/2015 10:32:56 AM: P1 CoM distance: 51.030392.23517950814767E-08 P2 CoM distance: 10.9182740
10/10/2015 10:32:56 AM: TD: 61.95 TM: 40.00 p1goal: 0.00 p1difference: 0.00 P1amt: 2.23517950814767E-08 P2amt: 40
10/10/2015 10:32:56 AM: P1 CoM distance: 51.033832.23517950814767E-08 P2 CoM distance: 10.9149140
10/10/2015 10:32:57 AM: TD: 61.95 TM: 40.00 p1goal: 0.00 p1difference: 0.00 P1amt: 2.23517950814767E-08 P2amt: 40
10/10/2015 10:32:57 AM: P1 CoM distance: 51.036422.23517950814767E-08 P2 CoM distance: 10.9124440
10/10/2015 10:32:57 AM: TD: 61.95 TM: 40.00 p1goal: 0.00 p1difference: 0.00 P1amt: 2.23517950814767E-08 P2amt: 40
10/10/2015 10:32:57 AM: P1 CoM distance: 51.038842.23517950814767E-08 P2 CoM distance: 10.9101240
10/10/2015 10:32:57 AM: TD: 61.95 TM: 40.00 p1goal: 0.00 p1difference: 0.00 P1amt: 2.23517950814767E-08 P2amt: 40
10/10/2015 10:32:57 AM: P1 CoM distance: 51.041242.23517950814767E-08 P2 CoM distance: 10.9077940
10/10/2015 10:32:58 AM: TD: 61.95 TM: 40.00 p1goal: 0.00 p1difference: 0.00 P1amt: 2.23517950814767E-08 P2amt: 40
10/10/2015 10:32:58 AM: P1 CoM distance: 51.046062.23517950814767E-08 P2 CoM distance: 10.9029440

Edited October 10, 2015 by Fengist

[steuben]

That's the theory I'm working on now but I'm having to put in some effort to reduce the accuracy of the calculations. Calculating the length twice I get both

61.9436302185059

And...

61.9439220428467

And with that many decimal points, if I transfer the resource often it creates or evaporates the resource. So, I'm working on that.

ah the collision of analog and finite digital spaces. you may have to surrender and do an approximation on the numbers. something like cint((D*1000+.5))/1000 will get rounded 3 decimal places to the right. which at most practical scales and some impractical ones gets you close enough for automatic controls to take care of the rest. after a certain point that many numbers just becomes noise in your signal.

supplemental info: https://en.wikipedia.org/wiki/Significant_figures, might be a good review for anybody watching.

[Diazo]

Okay.

First thing I notice is that you are assuming that the CoM of Part1, Part2, and the Vessel are all in line. I would be very surprised if this is the case.

Most likely they form a triangle and so P1Length + P2Length is greater then totalDistance, not equal to it like your math assumes.

If the 3 CoM's are in fact in a line, I don't see anything obviously wrong with a quick glance at the rest of the code.

D.

[Fengist]

ah the collision of analog and finite digital spaces. you may have to surrender and do an approximation on the numbers. something like cint((D*1000+.5))/1000 will get rounded 3 decimal places to the right. which at most practical scales and some impractical ones gets you close enough for automatic controls to take care of the rest. after a certain point that many numbers just becomes noise in your signal.

supplemental info: https://en.wikipedia.org/wiki/Significant_figures, might be a good review for anybody watching.

Yep... noise. So now I'm converting everything to a decimal 2.

- - - Updated - - -

Okay.

First thing I notice is that you are assuming that the CoM of Part1, Part2, and the Vessel are all in line. I would be very surprised if this is the case.

Most likely they form a triangle and so P1Length + P2Length is greater then totalDistance, not equal to it like your math assumes.

If the 3 CoM's are in fact in a line, I don't see anything obviously wrong with a quick glance at the rest of the code.

D.

Well, here's a quick look at the vessel, from a distance. It's pretty much in-line. The Part1 and Part2 are the bow and stern parts. Basically, I'm searching all the parts for the resource and as long as there's only two (I don't wanna even think about a lever with multiple masses and fulcrums) it tries to balance the sub.

But I see your point. That, I suppose I could adjust for that once I get even close with the math (pct of distance to CoM roughly = pct of distance between the parts). Right now, I'm not.

Edited October 10, 2015 by Fengist

[Diazo]

Alright, so close enough to inline.

Although I do see fins, do those have a ModuleAeroSurface or ModuleControlSurface attached? Those modules are weird and may cause lift throwing things off, even when "stationary".

Although something is screwy in your vectors:

10/10/2015 10:32:54 AM: TD: 61.95 TM: 40.05 p1goal: 0.00 p1difference: -0.05 P1amt: 2.23517950814767E-08 P2amt: 40
10/10/2015 10:32:54 AM: P1 CoM distance: 50.950742.23517950814767E-08 P2 CoM distance: 10.9996340

Totaldistance: 61.95 meters, P1 distance is 0.0000005095 meters, P2 is 10.99, that only comes to about 11 meters and no where close to 61.95 meters.

(I think the E-08 on the end is a negative scientific notation correct?)

So you need to get that straightened out first before worrying about balancing them out.

Somewhere on the forum there is a code snippet for drawing lines, I would draw 3 lines, one from each CoM and see ... is going on. My suspicion is that FlightGlobals.ActiveVessel.CoM is returning something strange but you need to confirm that.

D.

[Fengist]

Alright, so close enough to inline.

Although I do see fins, do those have a ModuleAeroSurface or ModuleControlSurface attached? Those modules are weird and may cause lift throwing things off, even when "stationary".

Although something is screwy in your vectors:

10/10/2015 10:32:54 AM: TD: 61.95 TM: 40.05 p1goal: 0.00 p1difference: -0.05 P1amt: 2.23517950814767E-08 P2amt: 40
10/10/2015 10:32:54 AM: P1 CoM distance: 50.950742.23517950814767E-08 P2 CoM distance: 10.9996340

Totaldistance: 61.95 meters, P1 distance is 0.0000005095 meters, P2 is 10.99, that only comes to about 11 meters and no where close to 61.95 meters.

(I think the E-08 on the end is a negative scientific notation correct?)

So you need to get that straightened out first before worrying about balancing them out.

Somewhere on the forum there is a code snippet for drawing lines, I would draw 3 lines, one from each CoM and see ... is going on. My suspicion is that FlightGlobals.ActiveVessel.CoM is returning something strange but you need to confirm that.

D.

Ah, all my vars in there make it confusing to even me. The p1difference is the calculated amount of resource to transfer - the amount it already has. If you look at the second line you copied, you'll see the two distances to CoM do come up to right around 61.95m

- - - Updated - - -

Yea, there's something strange going on. This simple test tells me that.

Here's the math that's coming up wrong.

Distance = Part1 distance to CoM + Part2 distance to CoM

Total Mass = Part1 resource amount + Part 2 rescource amount

Mass per length = Total Mass / Distance

Now if that's correct then

(Part 1 distance * Mass per length) + (Part2 distance * Mass per length) should = Total Mass

But it doesn't;

I'm getting 44.45 for the total mass of the resource but 57.28 for the Parts * Mass per length.

decimal totaldistance = decimal.Round((decimal)Vector3.Distance(Part1.transform.position, FlightGlobals.ActiveVessel.CoM) + (decimal)Vector3.Distance(Part2.transform.position, FlightGlobals.ActiveVessel.CoM),2);
decimal totalmass = decimal.Round((decimal)MPFunctions.GetResourceAmount(Part1, "CompressedWater") + (decimal)MPFunctions.GetResourceAmount(Part2, "CompressedWater"),2);
decimal P1length = decimal.Round((decimal)Vector3.Distance(Part1.transform.position, FlightGlobals.ActiveVessel.CoM), 2);
decimal P2length = decimal.Round((decimal)Vector3.Distance(Part2.transform.position, FlightGlobals.ActiveVessel.CoM), 2);
decimal MassU = decimal.Round(totalmass / totaldistance,2);
decimal p1goal = decimal.Round(MassU * P1length,2);
decimal p2goal = decimal.Round(MassU * P2length, 2);
decimal goaltotal = decimal.Round(p1goal + p2goal, 2);

Edited October 10, 2015 by Fengist

[Fengist]

Well, I've come to a conclusion. Diazo, you're correct. The CoM is not the fulcrum when submerged. I suspect it's a center of buoyancy but unfortunately, there seems to be no vessel.CoB.

[Diazo]

Ouch, that's going to make things tough.

I don't have a clue how buoyancy works in KSP and I don't remember ever seeing anything on the forums about it either.

I think you are in totally uncharted territory here so good luck.

D.

[Fengist]

Ouch, that's going to make things tough.

I don't have a clue how buoyancy works in KSP and I don't remember ever seeing anything on the forums about it either.

I think you are in totally uncharted territory here so good luck.

D.

Yea, thanks for the help. I've tried WorldCoM, vessel.transform, currentCoM, basically any Vecor3 attached to the vessel and none of those seem to be the center of buoyancy. And naturally, I googled it till there was nothing left to google... nothing worth mentioning.

I may have to go back to my original idea and just check part altitudes and 'guesstimate'

[AdmiralTigerclaw]

What you described in the op looks like your problem is actually that you're trying to ham-fist with algebra what should be done with calculus... As Calc is literally the "Mathematics of Change".

Now, I haven't touched true Calculus in over a year, but it almost looks like you need to break out differential equations for this mess. You've got variables who's behavior is based on the 'fulcrum', but where-in solving for the solution alters the fulcrum, which means it needs to be resolved, which alters it more, etc... If you try to do this conventionally, the algebra is going to turn into a feedback loop where you end up either eating processor time, or sacrificing resolution and getting unstable results.

Ugh... Get someone who's strong in practical calculus to go over the problem with you. I hope my comment at least gives you an idea of WHAT math you need to attack with.

[Fengist]

What you described in the op looks like your problem is actually that you're trying to ham-fist with algebra what should be done with calculus... As Calc is literally the "Mathematics of Change".

Now, I haven't touched true Calculus in over a year, but it almost looks like you need to break out differential equations for this mess. You've got variables who's behavior is based on the 'fulcrum', but where-in solving for the solution alters the fulcrum, which means it needs to be resolved, which alters it more, etc... If you try to do this conventionally, the algebra is going to turn into a feedback loop where you end up either eating processor time, or sacrificing resolution and getting unstable results.

Ugh... Get someone who's strong in practical calculus to go over the problem with you. I hope my comment at least gives you an idea of WHAT math you need to attack with.

I'm beginning to be afraid that you're correct. Unfortunately, my education in mathematics dates back well over 30 years and never advanced into Calculus or Trig. So, I'm working with what faulty algebra I have in my head and what Google can provide.

But, before I go digging into that mess... I'm trying to exhaust every algebraic solution possible. I am getting close, but not close enough.

I'm discovering that the CoM is in no way the fulcrum. After watching closely as I transferred the resource back and forth that it pivots in one exact spot. Now I know I read somewhere not to do this, but since I'm grasping at straws I thought I'd try... I put in FlightGlobals.ActiveVessel.findLocalCenterOfPressure() as the fulcrum and I got closer than I have with any other Vecor3. Using it, the best I could get was about a 45 degree down angle. Now since there's other ship mass involved (like rudders, dive planes, the bridge, the engine, liquid fuel and the parts themselves. ) this may actually be the center of buoyancy but....

Oh crap....

Now that I just spat that out I realize one of my problems. There's 600 units of LF close to the aft end of the ship in the 'generator' that I completely forgot about... crap... Now I have to start over from scratch looking for the fulcrum....

Crap!

Yea, so sometimes it does help to just start talking to others about problems when the brain fart hits. Off to coding...

[AdmiralTigerclaw]

I'm beginning to be afraid that you're correct. Unfortunately, my education in mathematics dates back well over 30 years and never advanced into Calculus or Trig. So, I'm working with what faulty algebra I have in my head and what Google can provide.

But, before I go digging into that mess... I'm trying to exhaust every algebraic solution possible. I am getting close, but not close enough.

I'm discovering that the CoM is in no way the fulcrum. After watching closely as I transferred the resource back and forth that it pivots in one exact spot. Now I know I read somewhere not to do this, but since I'm grasping at straws I thought I'd try... I put in FlightGlobals.ActiveVessel.findLocalCenterOfPressure() as the fulcrum and I got closer than I have with any other Vecor3. Using it, the best I could get was about a 45 degree down angle. Now since there's other ship mass involved (like rudders, dive planes, the bridge, the engine, liquid fuel and the parts themselves. ) this may actually be the center of buoyancy but....

Oh crap....

Now that I just spat that out I realize one of my problems. There's 600 units of LF close to the aft end of the ship in the 'generator' that I completely forgot about... crap... Now I have to start over from scratch looking for the fulcrum....

Crap!

Yea, so sometimes it does help to just start talking to others about problems when the brain fart hits. Off to coding...

I actually ended up discussing this thread with my father yesterday (His Credentials: Ex Navy, Ex Nuclear Engineer, Retired). He pretty much agreed, you need to break into some engineering math (Calculus) to solve this. Trust me, I know you want to find the algebraic solution to the problem, but believe it or not the algebra version is HARDER than the calculus. That's WHY calculus was created in the first place. I know that sounds a bit crazy, but after seeing clear cut examples of WHY you use it in place of algebra, I am telling you from experience that this is going to stymie you and then leave you with a piece of math 10 times more complicated than it needs to be, and fifty times longer.

So I really can't emphasize enough, you need someone who's got solid engineering experience under their belt, and knowledge of Calculus III or better (I'm pretty certain this problem is going to need an equation that's around or slightly above a Laplace Transform, well above simple integration, and likely a differential equation). So you might want to poke around some engineering, naval engineering, and math forums. Heck, my father mentioned that what you're trying to do is something the US navy has been doing since before we were twinkles in our parents' eyes. (Adjusting the balance of things like destroyers through ballast pumps and the like.)

I'm sure if you go asking around the right circles, there'll be a naval engineer who can help you.

[Fengist]

I (His Credentials: Ex Navy, Ex Nuclear Engineer, Retired).

Ah, a Nukeypoo... or push-button third as we called them. I was initially offered that as a job in the Navy, till they found out I was half deaf and the medical waiver said... no subs, no ionizing radiation... so they made me a journalist.

I realize you're probably right but either way I go there are some serious complications. If I go the algebra route, you're right, there's a ton of possible variables that go into it, especially since this is designed to be a modular sub and I really have no idea how the parts are going to be put together. If I go the calculus route, there's still a lot of unknowns, like how quickly the dive angles change when I do move the mass around. I know InfiniteDice solved this problem with his sub by simply moving mass back and forth until a balance was achieved, no real calculus or algebra, just guesswork. But, his sub stays pretty much the same when users assemble it.

[AdmiralTigerclaw]

Ah, a Nukeypoo... or push-button third as we called them. I was initially offered that as a job in the Navy, till they found out I was half deaf and the medical waiver said... no subs, no ionizing radiation... so they made me a journalist.

I realize you're probably right but either way I go there are some serious complications. If I go the algebra route, you're right, there's a ton of possible variables that go into it, especially since this is designed to be a modular sub and I really have no idea how the parts are going to be put together. If I go the calculus route, there's still a lot of unknowns, like how quickly the dive angles change when I do move the mass around. I know InfiniteDice solved this problem with his sub by simply moving mass back and forth until a balance was achieved, no real calculus or algebra, just guesswork. But, his sub stays pretty much the same when users assemble it.

My father was a reactor operator on the Stergeon... (Fast Attack Sub)

But anywho, that's part of fixing the unknown. The calculus equation does instantly what InfiniteDice does with his back and forth guessing. To begin with, you need at LEAST a Function. That instantly handles ID's guess and check since it solves for all points rather than trying to guess and sort. If that was it, you'd just need an F(x) (F of X) equals [bLAH] equation, and you'd be done. But because your 'fulcrum' point moves around, you have to plug that beast in and solve a recursive mess that constantly shifts as new values are plugged in.

Problem of course, if you use fixed points, you suffer inaccuracy much like how trying to find the area under a curved line suffers inaccuracy when you chop it into rectangular boxes and add the areas together. The workaround is to increase resolution by making the boxes smaller and smaller, but that exponentially increases the number of equations you need to do until calculations per unit time approach infinity. Do that and you'll melt your PC.

An Integral (Calc II) is an equation that literally goes 'Resolution = Infinity', and solves it in one shot, provided you bound the X axis of the curve between two points. (Otherwise, area IS infinity... You know, because lines never end. Well... Most lines. -X^2 + [Whatever] could get away with a limited area easily since area under the curve only counts above zero on the Y axis. At least, in any equation I've ever had to screw with.)

PM me if you're interested in a Skype conversation. I can edimacate you on the concepts of basic calculus in about an hour without any nasty equations. (Calculus is not as nasty as most would have you think. It's just intimidating because there are some extremely complex functions that don't play nice. And you need some pretty beastly equations to solve them. And it's the Algebra in said equations that kills you. At it's core, it's stupid simple to the point that after I finished explaining integration to a friend of mine after he roadblocked with his calc professor, his response was 'That's IT?!'. [Yes, that is it.])*

But back on topic, you have a function where you have the options to choose inaccuracy, PC melting recalculation, or finding someone who can teach you the function you need to use here. My father mentioned this particular problem should actually be no sweat for mechanical engineer.

*I should mention. I made As in my calculus courses and impressed my instructor. I really do mean it when the concept is simple. I got my score through a combination of remembering what I was doing at the core, and brute forcing my way through the algebra the nasty stuff threw at me. In terms of difficulty, Calc ranks: 'Tedious' And I'd know it even better, but I HATE Tedium.

[Fengist]

My wife and I were just discussing this little problem. While she doesn't quite understand it, she very often makes me think these problems out in new ways... and she once again succeeded.

I realized that figuring this out was simple (well, there is a sin or two in there) geometry...

I can get the distance between the two parts.

I can get the altitude of the two parts.

I can get the angle of the part compared to the planet's up direction.

Therefore, I need only to get the altitude of one part and find the angle toward the other part.

Transfer a small amount of fuel, wait a couple seconds for the sub to change it's dive angle.

Then, get the altitude and angle again.

I then have 2 angles and one side of a triangle. From that, I should be able to get the exact distance to the fulcrum. Once I have the fulcrum, I can get the total mass of the vessel and use the lever calculation to find out roughly how much mass is on each end and then, calculate how much needs to be moved to balance the lever.

If I repeat this calculation a few times, I should achieve balance.

Well, that's the theory anyway.

edit...

A theory that proved fruitless. Though I was able to get the angles needed and one side of the triangle, as I pitched the sub back and forth I was hoping to see a relatively constant distance to the fulcrum... instead, I got measurements that ran between 3 and 50 meters.

So, that didn't work.

Edited October 12, 2015 by Fengist

[flywlyx]

You are trying to find a static solution in a dynamic system.

You don't really need a accurate value and done it once for all, you just need a PID control and balance it as good as you can.