Darwinbots Forum
Code center => Suggestions => Topic started by: Numsgil on October 04, 2005, 06:03:15 PM
-
Say you're a bot. Right now, you can spin and spin in any direction in any amount for free. This isn't quite realistic. A better system could be formed.
Currently the system works like: Assume the bot is in a vacuum. What mechanism does it use to turn? well, the best answer is probably small compressed air cannons placed 90 degrees to either side of the bot. These fire in tandem such that a net torque is produced. This torque starts the bot spinning. These same cannons stop the bot at a designated angle. This all happens betwen cycles.
Thus, bots have zero rotational velocity at any given cycle.
Question:
Do we want to keep it so that bots have zero rotational velocity during each cycle? If we don't, then bots keep spinning after they 5 .aimdx store indefinately at some rotational speed. This speed would slow down if they gain mass. If we do, then a bot that is constantly spinning will be charged a much larger value of energy than need be for the starting/stopping.
There are pros and cons here. Old bots would be broken if we have rotational momentum hold over between cycles. .aimdx and .aimsx might need to be rewritten entirely to be the amount of energy you want to spend to spin instead of the amount of spin you want...
However, we would get to use some new physics things, and sneaking up on a bot from behind becomes a useful strategy, implying more stratagy in the hunt.
I'll write two different proposals for each method, so we can all see how they differ.
-
I like the new system, it is better for evolution sims. But all you guys designing bots will have a difficult time...
(http://img117.echo.cx/img117/5600/smile0034db.gif)
-
I am increasingly wanting to pull the program in one direction, while the older bots try and stop me. Trying to make the changes backwards compatible is quite a challenge.
I would favor changing turning to be applying energy to cause your bot to turn. I'd love to have everything in the simulation using the new physics stuff. While it's different from the old version, it makes adding new physics things quite natural and easy.
On the other hand, it usually involves me spending several hours re-learning my calc based physics stuff.
Are there any Newtonian Physicists in the house?
-
This is what I've come up with:
The cost to turn a bot is:
4/5 *mass * radius * pi^3 * abs(delta aim) / 1256
where delta aim is aimdx - aimsx.
That gives rather large values for turning however. I'll double check my work later tonight.
-
[ABE] Message posted before the last one by Nums.
A more backward compatible method will be to assume that rotations include a rotational acceleration and a rotational deceleration at the correct point. This rotation can be charged for proportional to the bot's mass.
I like this system as it maintains the present system for doing stuff like precise angled MB construction.
However I also like the idea of using rotational momentum as that would allow a bot to continue rotating forever at a very small initial cost.
How about we use BOTH systems?
Keep the old way but add a small mass-anglechange-proportional charge for rotations.
Add new rotation commands that just add rotational acceleration without stopping at the other end. Cheaper to start rotating than .aimsx but less precise control as to the end point. This will work just like .up and .dn in that it applies a known amount of force which will be translated into motion by the program based on the mass of the robot.
Should be pretty easy to implement.
-
That gives rather large values for turning however. I'll double check my work later tonight.
Sounds kind of expensive. We should aim a pretty low costs for rotation. Something like 1 point of energy for 1 full rotation (1256) of a bot with mass 1 and diameter 100
Fat bots will obviously cost a lot more, as will large bots.
-
The above assumes a bot accelerates then decelerates between each cycle.
I got it from constructing a function for theta with resepect to time. THen differentiating it. Then again, to get alpha. Then using Force(t) * radius = I * alpha(t).
Force(t) = moment of inertia of a sphere / r * alpha(t).
abs(Force) = I / r abs(alpha(t)
Then I integrated abs(Force) over 0 to 1.
Point is I think that's an accurate physics function, assuming that bots turn using the same efficiency with which they move around, and that their little engines are strapped to either side of the bot for maximal torque.
-
I don't disagree with your formula. It looks pretty accurate from a cursory glance.
All I am suggesting is to apply some kind of scale factor constant to keep total costs managable.
-
Okay, here's a better system with easier math that I'm sure works:
Each bot gets a new variable which is it's angular velocity. It holds over between cycles, however, the .aimdx, .aimsx commands still work relative to no turning.
So a bot that wants to spin at a constant speed would do 5 .aimdx store every turn still.
Each bot is charged:
.002 * mass * radius * abs(new desired angular velocity - old angular velocity)
and new angle = old angle + new desired angular velocity) (That's a Euler approximation for you numerical analysis types).
nrg for the turn. I can show the work process I used to get this if you like, or not. Rest assured, it's an accurate mathematical model.
Now, say you aren't moving at all. Then you do 5 .aimdx store, then do nothing. What are you charged and when?
Well, the first turn you're charged .002 * mass * radius * (5-0) = .6 nrg for a normal bot.
Second turn, you're charged .002 * mass * radius * abs0-5) = .6 nrg for a normal bot.
So constantly spinning becomes a very good strategy still for when there's nothing to eat, since you're only charged for starting the spin and ending it. But turning constantly and drastically in combat uses alot of nrg. Trying to turn 90 degrees would cost nearly 38 nrg, and then another 38 nrg if you stop turning the turn after.
I think I'll also add a new component to a shot's vector that comes from the bot turning. If you're spinning really fast, the bullet is going to veer off from what you'd expect it to do if you weren't spinning. Like a sling.
-
Trying to turn 90 degrees would cost nearly 38 nrg, and then another 38 nrg if you stop turning the turn after.
That is horribly high :(
Charging this much to rotate a bot is going to make building a Multi-bot prohibitively expensive since each segment of a 6 part bot will have to make several turns that will total at least 720 degrees.
That is the only way I could make Hexagonis build his MB body and he isn't even cross tied. Adding that would make at least another 360 degrees.
720 degrees times 6 robots makes a total cost of 1824 energy just to form its structure.
If we implement this cost regime then we can pretty much say goodbye to large MBs altogether.
If you multiply the whole system by a factor of 0.01 (or possibly even 0.1) then it might be affordable otherwise the costs are just going to destroy any chance of MBs evolving or even being designable.
-
But that cost is trying to do the whole turn in a single cycle. If you take, say, 5 cycles to turn, then the cost becomes: 7.5 nrg to start the spin, another 7.5 to stop.
If you take 10 cycles, then it becomes 3.8 to start and 3.8 to stop.
That's all for bots of 1000 body. Smaller bots can turn much easier. Huge behomoths are more difficult.
We've been letting bots spin for free, which isn't realistic. If we charge, and implement it correctly, we can incorporate it into the rest of the physics engine. Maybe have off center collisions produce spin. Things like that.
-
I think I'll also add a new component to a shot's vector that comes from the bot turning. If you're spinning really fast, the bullet is going to veer off from what you'd expect it to do if you weren't spinning. Like a sling.
Will it also fly away faster? :) or farther :)
-
Faster, yes, if done right. And hence farther too. The hard part would be in aiming it correctly.
-
How about we keep the bots turning the same way. But charge them more for doing bigger turns proportional to the mess and everything. We can even trow in deselaration only the bot has to calculate its turn with the deselaration in mind. I basicaly want to save up on pointless dna in the bots.
MB = Easy
-
That's more or less what I'm suggesting.
The apparent behavior from the bots would be unchanged. Bots would operate exactly like before. Only the costs would be different. And the angular velocity would effect some interesting physics things. Otherwise identical.
MB = Easy
how so?
-
MB = easy in the sense that the robot does not have to look at its envirment and mess and everything before comming up with the magical number of the turn it has to make.
How is it not easy, thats the qustion:
Charging this much to rotate a bot is going to make building a Multi-bot prohibitively expensive since each segment of a 6 part bot will have to make several turns that will total at least 720 degrees.
And how did it work before?
-
Presently bots are not charged any nrg for turning.
-
Here is roughly what a cross tied 4 part MB has to do in order to form.
- Bot 1 gives birth: Bot 2 is born
- Bot 1 spins to face outward. a turn of 135 degrees: Bot 2 rotates 90
- Bot 2 gives birth: Bot 3 is born.
- Bot 2 rotates 135 degrees: Bot 3 turns 90 degrees
- Bot 3 gives birth: Bot 4 is born
- Bot 3 rotates 135 degrees: Bot 4 turns 90 degrees
- Bot 4 fires a tie at bot 1
- Bot 4 rotates 135 degrees
- All 4 bots rotate 180 to face the middle then fire ties.
- All 4 bots rotate 180 to face outward again.
- Voila ---- Cross tied 4 part MB
It might be possible to make only 2 of the bots turn inward to form the cross ties but if it is then I haven't managed it yet.
Total rotations for all bots?
2250 degrees of rotation!
Remember all this energy has to come from one parent bot and each successive parent in the series will be rotating with a significant portion of this mass so the expense will be astronomical.
Also this scenario is calculated for only 4 bots. Try 6 or 8 and it will become almost exponentially more expensive to make big MBs
The way this is suggested it will cost several hundred energy for an average sized bot to make one complete rotation.
IMO the cost of rotations should be extremely low, something on the order of 1-5 energy for a full rotation depending on mass and size.
It isn't practical to make a series of smaller rotations or to start a slow rotation then stop it later in order to conserve energy. If we do that then the ties harden way before we can build the structure. It is already very difficult to get everything done in the time scale allowed.
-
Ah, you see, that's the challenge :P
Maybe what you need to do is start the bots spinning at a constant rate. That's free. Make it the GCD of all the angles a particular bot needs to do. Maybe something like 45 degrees/cycle.
That would cost something like 18 or 19 energy to start, and then 18 or 19 energy to stop. (Or you could never stop).
It's a challenge. I'm not disputing that. But remember that as your MB starts dividing, it's mass and radius will both go down.
After a single division, I think the cost to turn goes to like 40% of what it was.
-
Of course the best way to deal with it is just to put your formula into the program then allow the user to adjust the actual costs from the control panel. That way anyone who really doesn't like being charged to rotate can tun it to zero. B)
-
What about reducing costs of rotation for tie-connected bots? We can reason that since they have a leverage, then it is easier to start and stop rotation for them than for free-floaters. In fact, what about splitting the torque and turning a tie-connected bot into the opposite direction?
-
Yeah, I'll probably add a costs bit into the program:
Cost for translational impulse
Cost for rotational impulse
I'd like to rework the cost panel entirely sometime in the future. Set it up so you can charge any amount for any thing the bot can do.
-
What about reducing costs of rotation for tie-connected bots? We can reason that since they have a leverage, then it is easier to start and stop rotation for them than for free-floaters. In fact, what about splitting the torque and turning a tie-connected bot into the opposite direction?
I'd have to figure out the physics. If you're applying force on the tie to start yourself spinning, you're also going to cause the tie to start rotating as well... as you stated...
Lots of fun physics with ties :D
Every thing you can do with a tie is really complicated physics.
-
You seem to enjoy it though!
-
I love solving the problems. That is, having the solution in hand. The actual process makes me vomit in frustration.
-
Okay:
cost for turning will be .002 * mass * radius * delta angle * cost per turn impulse.
Cost per turn impulse is a new option in the Costs page. For F1 standard, I propose we set it equal to that for translational movement, which is .05 I believe.
That would make all the costs I quoted above 20 times larger than what you'd get.
-
I see nothing wrong with making expansive MBs.
A.)
Look at humans. When a baby is born its small,[you] then it eats and eats [/you]and grows like clockwork.
B.)
All I think we have to do is balance the costs to make them more natural. In real nature its not so hard to go MB. Is it?
-
Well, it took billions of years for nature to figure out how to form multicellular organisms, so I'd say it's hard.
Of course, as with all life, you only have to figure something out once. After that it self propogates.
-
Well the theory is turning is the cheapest kind of movment you can make anyway.
And Num how about my pm about keeping it backwords compatble for 1/3 a year more? Don't make me start a poll you know ( :evil: scary face :evil: )
NUM = :sly:
....
:(
-
I'm unlikely to make the program become backward incompatible. Backwards compatibility is somewhat elegant IMO.
That said, I think I'm going to redesign viruses, which might make older bots that don't *.thisgene .mkvirus break.
-
That said, I think I'm going to redesign viruses, which might make older bots that don't *.thisgene .mkvirus break.
AND WHAT IF A ROBOT DOES NOT USE *.thisgene .mkvirus ? I THINK EVEN THEONE DOES NOT USE IT. (what does that do anyway?, are you saying all robots have to use viruses now?)
-
*that might make old VIRUS bots that don't use *.thisgene .mkvirus store BE UNABLE TO SHOOT VIRUSES*
-
*.thisgene .mkvirus
So theone does not use viruses at all but:
Does *.thisgene .mkvirus mean (for a laugh) does it mean:
Hi, I am going to check if the *thisgene command works now. Ok it seems to work we are currently in gene 3. Ok, going to faze two making a virus.
Or does it mean somthing else?
-
If you mean that since *.thisgene becomes the only value that .mkvirus accepts as legitimate... Yeah, that does seem a little pointless.
Maybe we could change it to .mkvirus accepting any positive value, and just assuming the correct gene was chosen (namely the gene that called it.)...
You know, maybe I should make .mkvirus work like *.thisgene, and update every new gene, so multiple viruses can be made in a single cycle.
-
What if you don't want to pass the ".mkvirus" command? you just want to stick some new dna in there.
-
New DNA in where?
-
In whatever the virus hits presumably.
This is a good question.
There may be times when you simply want to fire out a chunk of DNA that isn't a complete, self-replicating virus.
-
Hmm... well, I guess you'd have to figure that out, wouldn't you :P
The idea is that I don't want a virus to enter a cell, then force all other genes in that cell to produce viruses, and thus be unable to be executed, giving the virus a monopoly over the cell.
-
This seems to be an empty topic to me, so I'm going in to see if I can figure out why.
-
Haha! Old posts Fixed again.
BTW, I've implemented this in the C++ source with an optional cost for turning field. You can set it to 0 to use old school free turning.