Darwinbots Forum
Code center => Suggestions => Topic started by: Numsgil on September 13, 2005, 10:19:51 AM
-
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.
-
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.
-
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:
-
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.
-
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
-
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.
-
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.
(http://www.islandone.org/LEOBiblio/SPBI1GU5.GIF)
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
-
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
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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....
-
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.
-
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.
-
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.
-
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.
-
...
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?)
-
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.
-
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.
-
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.
-
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
-
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?):
-
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.
-
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 :)
-
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?
-
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...
-
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.
-
Oh, I hadn't even thought of the torque function in DB. That's almost a torsion spring. Not terribly difficult.
I think ties are on the verge of an overhaul, like what we talked about before. I'm still working on fixing some 2.4 bugs and adding mutations, though...
-
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.
I think you're right, this is basically what I've been seeing.