Code center > Suggestions
Tie Forces
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....
--- Quote ---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
--- End quote ---
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:
--- Quote --- 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
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version