Tie Forces

[Botsareus]

Num, I am planning to use DB 2.34.x and virmus_P to simulate this thing: will it work or what should I use?

Please give me the source code and density value for this: (density of fluid * cd * radius of cylinder)

(I have no clue for the equation of cd)

Therefor, I can simulate the whole thing and get it over with.

P.S.

I think its going to be f((x+y)/2) and not (f(x)+f(y))/2 because the tie itself is part of the firction also. I think we should use this.

This: (f(x)+f(y))/2  means that the tie is some kind of external fource acting on the bodys after they already moved thorugh the space.


I am also not sure If I solved the circuler friction problem correctly, all will be done once I have a simulation and see the best result.

[Numsgil]

1.  You can just have a constant Cd value for experiments.  Basically, it's Av^2 * length, where A has Cd in it, so go ahead and just make up a number for A.  It doesn't matter terribly much.

2.  Not friction, drag.  Let's get that terminology fixed right now.  Because you can have both in 2.4, and they operate differently.

3.  I have the spring forces already done.  That's things like one bot oscillating back and forth with another.  This is drag forces, which are things like two bots orbitting around each other.

4.  And you can't just use angular momentum friction either (that is, applying a resistive force to their angular momentum), since friction works independantly of velocity, and tehrefore can't be used to model drag.  There's at least 3 different resistive forces that are possible.  One is independant of velocity, one is linearly dependant, and the other is quadratically dependant.

This: (f(x)+f(y))/2 means that the tie is some kind of external fource acting on the bodys after they already moved thorugh the space.

No, you have it wrong.  What it implies is that the slope/derivative is not constant.  Ie: some non linear function.  Which is exactly what we have here.  Force does not have to be a linear function.  It does not have to be a * b.  It can be anything it wants.

Force = A * velocity^2 per unit length.  You can't average velocity, then square.  You'll get a different answer then if you first square the velocity, then average.  That's the problem here.

But the real problem is that each piece of the tie is moving at a different velocity.  If the tie was moving at a constant velocity all over, you could just square that velocity.  But it doesn't, so you can't.

The answer here is integration, which I'm sure is above your head.  The problem is the integration confuses me.

It's not going to be any average of anything.  I explained that it can't be that, because the relation is quadratic.  You can only average linear functions.  Well, average and get a good answer anyway.  I suppose you can do anything you want.  It just won't be right.

Remember: this function only takes into account drag.  And then must apply that force to the bots, since they're the ones that actually move.  Other forces are done in other functions.

Check out how physics are done in 2.4 to see what I mean.

If any of the terms I am using are unfamiliar, please go look them up.

[Botsareus]

Yea well I am not exactly sure how you want to intergrate it , If I knew I would of been able to help. For my pupreses I would of left it a.) get avrage velosity b.) apply "friction".  actualy my thing would look like:

((all the movment and gravity and sutch forses avraged) apply to tie forses avrage for all seporate ties) apply friction or drag or what ever the heck.

P.S.

Over all I think you have a more realisitc picture in you head , and I dont want to ruin it for you by proposing a more simpler but easyer to code picture.

However, I will make a quick test bot because I still dont beleave that a bots do not deselarate while moving in a circles the tie at the midpoint.

And see how vermis_P behaves in 2.34 after gravity and all is applyed to it.

[Endy]

Slightly off topic but is this "math error" why the bots will sometimes fall downward if their tie is exactly horizontal and why they seem to like rotating mbs so much?

This does make me curious how the bots will behave once we get the physics working right.

[Botsareus]

...


Ok I seem to find no tie / swimming codes at all in 2.34... There is nothing to see num, you should of atleast tryed to use the old code in combination with your freacky forces, but since you wrote everything like a pro vector physisist I can see why you have trouble of just sticking it in there with all the nice code.

Bots DO terminate rotation:

'2.37.4 spins like butter , stops spinning like butter, respects tie like butter... what more do you need?
'Extract from Shen's


def job 50
def fixtie 51

' - Gene 1 -
' Fix the Tie
cond
   *.multi 1 =
   *.fixtie 1 =
start
 1 .tienum store
 314 .fixang store
 300 .fixlen store
 30 .stifftie store
 0 .fixtie store
stop

' - Gene 2 -
' Head ties to Tail and gets ready for fixing
cond
   *.robage 0 =
start
 1 .tie store
 1 .job store
 1 .fixtie store
stop

' - Gene 3 -
' Lone bot repros the Head bot and gets ready for fixing
cond
   *.numties 0 =
   *.robage 0 !=
start
 50 .repro store
 2 .job store
 1 .fixtie store
stop

' - Gene 4 -
' Start Repro Loop
cond
   *.nrg 5000 >
   *.multi 1 =
start
 1 .deltie store
stop

cond
*.robage 100 <
start
 10 .up store
stop
end

My work here is done. (or is it?)

[Numsgil]

Slightly off topic but is this "math error" why the bots will sometimes fall downward if their tie is exactly horizontal and why they seem to like rotating mbs so much?

This does make me curious how the bots will behave once we get the physics working right.

Very possibly.  Physics in older versions are very screwy.  They all didn't work through the same channels.  Some moved bots through acceleration, some just poofed them there, etc.

The new physics are a little less strict in what can happen.  Bots can overlap for a cycle or two, bots can dissapear under the screen for a few cycles, etc.  But it gains in robustness what it loses in accuracy.

[Numsgil]

Yes, they will stop rotating, but that's because theres drag on the individual bots.  Go into the code and get rid of everything but tie drag, and they'll never stop.  Of course, you'd have to uncomment Carlo's code, but I think you see my point.

Remember, I'm not as concerned about orbitting bots as I am with getting the physics right for bots to be able to swim.

I think I solved the problem.  We'll see what turns up.  I end up with:

Drag force on a bot is: A/12*length^2 (a^2+2ab+3b^2)


Had to use Maple to integrate the thing, then simplify.

[Botsareus]

OK , you beat me to the post of  some incurgment so if it works:CONGRADULATIONS! NUM!  :D


Yes, they will stop rotating, but that's because theres drag on the individual bots. Go into the code and get rid of everything but tie drag, and they'll never stop. Of course, you'd have to uncomment Carlo's code, but I think you see my point.

Possible Solution:

We can see the change in angle due to tie, movment velosity changes to rotation velosity  due to tie. Velosity is reduced as it is supposed to.

Now all you need is the exact formula for convirting velosity into rotation. Since on wider radios the angle changes less drasticaly anyway. It might be change in position per cycle (without applying linkfource) as the radios, then mesure the circumefrance segmant from the original angle to the angle resolting due to ties.

[Endy]

Glad you figured it out, although my brain refuses to make much sense of the math :wacko:

Would it be possible for MB's to be moved a bot at a time rather than all at once? I'm not sure of the programming constraints, but it still seems DB has problems moving large MB's in torroidal mode. Should also make it more realistic since bots couldn't abuse the edges anymore

[Botsareus]

We can use the clone bot method , when half a bot exsist on bouth sides of the screen, a bot is cloned into two (or four in rear cases) to simulate bouth edges of the screen. Integrating them to work as 1 and applying the whole consept to the errays is another story.


Here is how it looks with a MB:

O---C| end of screen

C clone = } we get beggining of screen|}--O

resulting in a bot O----C}-----O were C} = O , C  and } are seporate bots when painted , painted only half way.

Tie senerio

O--a--|end of screen
beggining of screen|---b--O

--a-- and --b-- are the same tie used twice, witch is basicaly what num will explain in the next post (although I think we should clone bots as well, wana illabirate?):

[Numsgil]

Glad you figured it out, although my brain refuses to make much sense of the math :wacko:

Would it be possible for MB's to be moved a bot at a time rather than all at once? I'm not sure of the programming constraints, but it still seems DB has problems moving large MB's in torroidal mode. Should also make it more realistic since bots couldn't abuse the edges anymore

I have it on my to do list.  Basically I'd need to make it so that ties can span across the torroidal screen.  Which means I'd have to rig up some modular math in all kinds of fun places.  I estimate it'd take like a day and a half of work max.
I think= I've figured it out.  Until I actually program it, I can't be sure.

[Endy]

I'm not sure it'd be an issue for individual SB's, They don't really gain anything from some such a slight movement advantage. The MB's however can literally hip hop across the screen. I'm mainly concerned with my huge giant size MB's with thousands of bots moving at once. It's also bad having "fixed" bots of MB's being moved simply because a member has passed over the edge.

Modular math...icky.

Wish you luck :)

[Numsgil]

Okay, I have a real quick question, and tehn I think I have this thing solved:

Can you calculate the torque with any pivot, or do you have to use a specific pivot to calculate from?  Like, say, the center of mass?

[Botsareus]

the great, but whats a pivot? better: whats torque

 :P

... so mutch for helping num with the tie forses ...

Although this does remind me about building airoplains, you have to build it arround the center of gravity otherwise it will be unbalanced...

[PurpleYouko]

Can you calculate the torque with any pivot, or do you have to use a specific pivot to calculate from? Like, say, the center of mass?

One problem I always had with torque is that it is a bit of a misnomer. It isn't really torque at all. Real torque is a twisting force applied to something that is able to rotate  about its axis. Like the drive shaft in a car.
In DB, torque appears to be the acceleration force applied to a robot on one end of a tie (at right angles to the direction of the tie), imparted when the robot on the other end of the ties spins back after a rotation. This isn't really torque at all.

In order to make this work accurately the force (or acceleration) created by a robot spinning back after a rotation (WRT the tie) needs to be split between the robots on either end of the tie in such a way that they both recieve an equal change in momentum but in opposite direction. That is not equal acceleration but a calculated force based on the distance from the centre of mass between the two bots.
I think that at present the force is only applied to the robot at the other end of the tie and not on the robot actually spinning. I may be wrong about this though. it has been a while since I messed with this stuff.

DB torque is kind of awkward since it has to be applied to every tied bot after each and every direction change. Also springyness of bot to tie needs to be adjustable in some way, just like the stiffness and damping of the tie itself needs to be adjustable. My sysvar "stifftie" started us in the right direction but we have a long way to go still.