Tie Forces

[Numsgil]

As I promised for too long and didn't do, here's the tie forces problem for a tie moving through a medium:

Let's pretend the tie is a solid block of length L;  It's mass is considered to be the mass of the two bots it connects plus it's own mass, which is uniformly distributed along the length.  So it's sort of like a dumbell in mass distribution.

m1 = 1st bots mass
m2 = 2nd bots mass
mL = mass of rod

Thus total mass = m1 + m2 + mL

The position vector of the center of mass of this rod is going to be:

x1 = position vector of bot 1
x2 = position vector of bot 2

xc = (m1*x1+m2*x2)/(m1+m2)

The velocity of the center of mass is going to be:

v1 = velocity vector of first bot
v2 = velocity vector of 2nd bot

vc = (m1*v1+m2*v2)/(m1+m2)

Okay, that's all pretty standard.  First I'd like to show Carlo's Algorithm:

1.  v3 = (v1+v2)/2
2.  you = (x2-x1)
3.  Force Magnitude = Ft = swim constant * (v3 x you) (that's a cross product).  I assume you all remember the swim constant in the physics panel?  This is what it did.
4.  Force's vector to apply to bots is Ft * <uy, ux> (that is, it's reverse of you).

Now, I don't know if you caught it or not, but there is small error in this algorithm:

1.  Assumes drag on the tie is linearly related to velocity.  It is not under certain circumstances.

2.  Does not slow a tie that is rotating about its center since the average velocity is zero, even though most of the tie is moving.  This is the one I found most disturbing.

I seem to have several pages of notes at this point, and I'm not sure what all they do.  Let me reread them and post later today about what things I tried that I was having trouble with.

Basically, just to keep you interested, I was going to calculate the force on a subsection of length, called dL, and then integrate it across the length L.

[Numsgil]

Okay, second part:

The force on a cylinder moving through a liquid is Av^2*length where:

v = velocity perpindicular to the cylinder.
A = density of liquid * Cd(v) * radius of cylinder
Cd = Coefficient of drag, between [0,1], and is sort of a black science in the real world.   It is dependant on velocity.  I have a piece wise function for determining it.

I was thinking that I'd take A * integral(V(dl)^2*dl) where V(dl) = velocity of tie at some length dl and dl is the integrating factor for length along tie.

But I get bogged down in the math, and my head explodes.  What a mess.

I can find a good enough approximate value for A I believe.  The hard thing is figuring out how to handle the v^2*length thing.

Right now, this is what I'm doing (using the stuff I defined above):

a = v1 x you
b = v2 x you

V(dl) = a + (b-a)/L * dl
which is simply the equation for a point-slope line with y intercept a and slope (b-a)/length.

[PurpleYouko]

But I get bogged down in the math, and my head explodes. What a mess.

My head exploded a long time ago. That is why I never really got into tie physics. It is a complete nightmare  :wacko:

[Numsgil]

I tried it again today during class.  I thought the 3 months since I worked on it would give me perspective.

Instead I just re-realized how incredibly difficult the damn problem is.

If nothing else, I can always use Carlo's old algorithm.

[Botsareus]

If nothing, thats the most brillient peace of string phyz I ever read. Working on it already. If I have qustions I let you know

[Botsareus]

1. (assumes that velosity is linary related)
2.) (does not slow down rotation )(tricky)

I assume the code should slow down velosity as well....

vxle = (.vx + rob(p).vx) / 2  'average x velocity
          vyle = (.vy + rob(p).vy) / 2  'average y velocity
            anle = angle(.x, .Y, rob(p).x, rob(p).Y)  'Angle between robots
            anve = angle(0, 0, vxle, vyle)            'Angle of vector velocity
            ancm = anve - anle                        'Combined angle
          vea = Sqr(vxle ^ 2 + vyle ^ 2)            'velocity along vector
          lle = Sqr((.x - rob(p).x) ^ 2 + (.Y - rob(p).Y) ^ 2)  'distance between robots
          lle = Sqr((.x - rob(p).x) ^ 2 + (.Y - rob(p).Y) ^ 2)  'distance between robots
          cd = ' Numjil has a piece wise function for determining it. plug it in Num
          'instead of simopts.physswim I use "density of fluid"
          cnorm = Sin(ancm) * vea * lle * (density of fluid * cd * radius of cylinder)
          'ok we got the cnorm, now we need to stick pie in there to figure out circumferantial(does this word exsist yet?) movment related to senter. as in:
          fx = cnorm * Sin(anle) / 800
          fy = cnorm * Cos(anle) / 800
          .axnew = .ax + fx
          .aynew = .ay + fy
ang1 = 'Get the angle between vector(.axnew,.aynew) and vector(vxle,vyle )
ang2 = 'Get the angle between vector(.ax,.ay) and vector(vxle,vyle )
distanceangle = '(ang1 - ang2) be sure to do modulation correctly
'diameter = lle therefor:
'lle*pi / distancerotated = 360 / distanceangle 'assuming this is angle not radiants
                                                                                       or what ever the hell
distancerotated = lle*pi * distanceangle / 360
'OK OVER HERE PLUG FRICTION OR WHAT EVER THE HELL ElSE WE NEED TO PLUG
'YOU HAVE TO ASSUME THAT IT DOES NOT SLOW DOWN ANY ciruler related -
'movment, so:
resultdistancerotated = distancerotated * (density of fluid * cd * radius of cylinder)
'
newangledistance =  resultdistancerotated * 360 / (lle*pi)
newang1 = '(ang2 - newangledistance) be sure to do modulation correctly
'once you have that you use vector(vxle,vyle ) + newang1vector*lle/2
fx = '!!!!
fy = '!!!!
          .ax = .ax + fx
          .ay = .ay + fy
'good luck cpu

Now you will see that I pluged in (density of fluid * cd * radius of cylinder) twice for bouth circuler movment and  movment in agreement. You might wana devide bouth by 2 to get the avrage or it might work more accuratly as is. Still this is the way I see it, test it let me know if it worked at all.

[Numsgil]

That's the code to Carlo's old swim forces, right?

Yeah, it took me a long time to decipher it.  The way I listed it above is more elegant mathematically speaking, and has the exact same logic.  Don't ask me questions about Carlo's code, because it makes my brain hurt.

Well, I suppose if you really want to know, I could look at it again.  Just not now.

Anyway, as I mentioned above, the force of Drag on a cylinder is: density of fluid * Cd * radius of cylinder * velocity perpindicular to cylinder ^ 2 per unit length.  Carlo's code, by the way, assumes that density of the fluid, Cd and radius of the cylinder are all calculated and constant, and stored in the swim factor.  Problem is Cd is a crazy function that can only really be constructed experimentally, and is a bitch to model.

Here's what Cd looks like for spheres and cyliders.  Gawk and awe at its subtle complexity.


For slowly moving objects, something called viscous drag is in effect.  This is things like a plastic marble sinking in water.  The fluid follows a nice, smooth path and it ends up that the Cd changes such that it cancels out one of the velocities and Drag force is linearly proportional to velocity.  This is the left part of the graph.

So Carlo's Algorithm works just fine for modelling, say, single celled creatures in water.  But it fails at modelling faster flows, which are called turbulent.

Turbulent flows are things like airplanes flying through air.  There is alot of random widgets (not a technical term) in the air flow, and it doesn't follow a smooth path.  In such a case the force is quadratically related to velocity.  This would be the right part of the graph.

This is why it requires roughly double the horsepower to make a car go relatively little faster at higher speeds.  The faster you go, the harder and harder the medium pushes you back.

If you want to do independant research on this, here are technical terms you can look up:

viscous drag
turbulent drag
bluff body
Coefficient of Drag (or Drag Coefficient)
Drag Equation

[Botsareus]

ok I get it now , check out original post.

However I don't see how this is swimming: It seems thats it is a resolting tie force of 2 forces on seporate robots. This forses are produced by .up .dn .sx .dx commands as far as I know.

There might be a unified approch to apply your fircition to bouth circuler and non sirculer changes at the same time as follows:

          vxle = (.vx + rob(p).vx) / 2  'average x velocity
          vyle = (.vy + rob(p).vy) / 2  'average y velocity
            anle = angle(.x, .Y, rob(p).x, rob(p).Y)  'Angle between robots
            anve = angle(0, 0, vxle, vyle)            'Angle of vector velocity
            ancm = anve - anle                        'Combined angle
          vea = Sqr(vxle ^ 2 + vyle ^ 2)            'velocity along vector
          lle = Sqr((.x - rob(p).x) ^ 2 + (.Y - rob(p).Y) ^ 2)  'distance between robots
          cnorm = Sin(ancm) * vea * lle 'No factor
          fx = cnorm * Sin(anle) / 800
          fy = cnorm * Cos(anle) / 800
          fource = (fx^2 + fy^2) ^ 0.5
          reducedfource = fource * (density of fluid * cd * radius of cylinder)
          .ax = .ax + fx*reducedfource / fource
          .ay = .ay + fy*reducedfource / fource

However, bouth the long way , and the short way are experimental and might not work correctly

(you know: why did I have to come up with the long way first, short way is so mutch easyer. I would of came up with the short way and never had to worry about plogging arround no pi)
 :D Bau 2005

[Numsgil]

I'm not good with code (not good at reading it, I can write it just fine), and I hate trying to decipher non-vector math into vector math.  (the purest form). Give me a few hours on this to see what sort of algorithm you're using.

For future reference, my brain cannot just look at code, especially code with silly variable names (vxle being a prime example), and just figure out what it does.  My brain works on algorithms.  First do A, then do B, etc. where A and B are relatively high level operations.  Just food for thought.  If you think in terms of code I suppose there's going to be a communication gap.  What does everyone else think in?

Anyway, why is this swimming you ask?  Well, first you have to ask yourself how something swims.  It wiggles, but how does it wiggle.  And then ask yourself in what direction this wiggle produces force.  Probably not entirely in the direction you think.

There are two directions a tie/bone can produce force.  Along it's length vector and perpindicular to it.  Along it's length vector forces are produced by how stiff the tie/spring is.  It's a simple -kx displacement spring problem.

Perpindicular to the tie comes from resistive forces of the medium.  That's it!  Only two sources, and in two distinct directions.

To be honest, I was going to make a bot that swam so I could explore this question a while ago, but the physics were off.  Once the physics are working right, I'll be trying to again understand the mechanics of swimming.

It's actually deceptively complicated.

[Numsgil]

Okay, I see what you've done, you've taken Carlo's old algorithm and attempted to modify it, as I had suspected.

*Sigh* okay, let's see here...

Nope, I have no idea what you're attempting to do.  PLEASE post your algorithm, and your reasoning.  No code.  Code can burn in Hell.

Anyway, you're still suffering from the same pitfalls that Carlo's algorithm has.  You're assuming that you can use the average velocity to calculate forces, but you can't.  It's not possible.  Well, it's not correct anyway.

Arg I hate this problem!

Last, but not least: this should only calculate drag.  Other functions calculate friction, etc.  Drag is not friction.  Only worry about drag.

[Numsgil]

I think I see what you're doing now.  You're applying a damping force, right?  Anyway, it won't work.  There will still be times when the forces cancel when they shouldn't.

[Ulciscor]

I never did understand Mechanics; I think I lack the 'common sense' needed to work out all the forces and stuff. Stats and pure I am fine with.

[Botsareus]

There will still be times when the forces cancel when they shouldn't.

Nice.

WHEN?

P.S.

I can see the long way canceling out: ( I tend to think less write more code)

But the short way should work like butter. When is it canceling out in there?
Once again short way says dont apply it to the cnorm , but apply it to each spesific robot seporatly.

[Numsgil]

You're forgetting something crucial:

1.  Force is equal to velocity squared * length * A, which Carlo's algorithm doesn't use.  This isn't a terribly difficult thing to fix.  However, it means you can't find the average of the velocities and use that.

For instance, suppose f(x) = x^2.  What is f(2)?  f(4)?  Take the average of that.  Does that equal f(3)?

No, it does not.  f((x1+x2)/2) does not necesarily equal (f(x1)+f(x2))/2   If you don't understand why that matters, you're not understanding the problem to begin with.

2.  what happens when the velocity of bot1 and bot2 are equal but opposite?  Let's have one's velocity be (5,0) and the others be (-5,0), and let's suppose the tie is along the y axis.

Well, their average is (0,0), which would imply no forces are created.  But obviously two bots tied and spinning around their center of mass should slow down in a thick medium.
That's really the crux.  You can't use the average.  One solution is to find where velocity equals zero (if it does at all) on the tie, and break the tie into parts.  First calculate the force on the part that's positive, then on the part that's negative.

Oh, and here's a fun little bit I forgot.  Since the drag force is distributed evenly along the tie, you can't just dump it into either bot.  The drag will apply torque to the bots.  And that, my friends, is just too much for my little mind to handle.

Does length cancel out?  Maybe it doesn't.  I don't know.

Maybe I'll go ask one of my math teachers.

[Botsareus]

Doh I thought you ment spring fourses that are currently abserved by the tie itself (witch is stiff).

I get back to you after collage, but: I beleave the fource appyed on the robots is there fource as a whole (2 robots together) so its nothing wrong with plugging it the way it is now. , I need to write a simulation to really see whats going on....