Darwinbots Forum
Bots and Simulations => Bot Tavern => Topic started by: Bluchrome on January 31, 2010, 12:12:58 PM
-
I took a long break from darwinbots. Just reintroduced myself yesterday and I started a little bot to get re-familiarized with DNA programming. For the most part everything is working OK. Except there's a gene activating when it shouldn't. Here is the gene along with the other relevant ones:
Some defines
[div class=\'codetop\']CODE[div class=\'codemain\' style=\'height:200px;white-space:pre;overflow:auto\']
def specIDloc 972
def specID 310
def sthreshold 20 'Distance at which the effects of the tracking gene gets deactivated and the feeding gene activates
(These aren't contiguous)
This sets the species' ID
[div class=\'codetop\']CODE[div class=\'codemain\' style=\'height:200px;white-space:pre;overflow:auto\']
'Set spec
cond
*.robage 0 =
start
.specID .specIDloc dup .memloc store store
stop
The problem gene is in this section
[div class=\'codetop\']CODE[div class=\'codemain\' style=\'height:200px;white-space:pre;overflow:auto\']
'Scan eyes
cond
*.eyef 0 =
*.memval *.specIDloc = or
start
.up 10 *.velscalar sub sgn 0 floor mult dup inc inc
*.timer 9 mod 4 sub .focuseye store
stop
'Center eye5 on prey
cond
*.eyef 0 !=
*.memval *.specIDloc !=
*.focuseye 0 !=
start
*.focuseye 140 mult .aimdx *.robage sgn mult store
0 .focuseye store
stop
'Track prey
cond
*.eye5 0 >
*.memval *.specIDloc !=
0 *.focuseye =
start
*.refvelup 50 add .up .sthreshold *.eye5 sub sgn 0 floor mult store
*.refxpos *.refypos angle .setaim *.robage sgn mult store
stop
The problem is the track prey gene gets activated even when eye5 'sees' the same species (despite the *.memval *.specIDloc != condition), and starts to chase it.
The only thing preventing it from continuously tracking it's own species is that the scan eyes gene is still activated and changes the focuseye the next cycle. So it results in intermittent tracking (of its own species) every 9 cycles. This bot works fine for non-specs and even though it doesn't shoot it's own species (the feed gene doesn't activate for conspecs), it is a wasteful behaviour and I really can't see why this gene is activating. I've used to console to evaluate the conditions and in the cycle that the track gene gets activated it shows that *.memval = 310 and *.specIDloc = 310. Also is *.timer capped at 32000 like *.robage?
BTW: The eyes' position and width have been changed to provide even 360 deg. vision
-
Well timer isn't capped, it'll start over, although I'm not sure where it starts and which way it counts. (If you're using mod it won't matter)
As for the other issue I can't see anything wrong anywhere, so can't help ya.
-
Thanks for trying. It's really frustrating but I'll fiddle with it until it works (hopefully).
-
You need to check if the value of the memory location was what you expected it to be at the time of activation, but if you use the console to just check *.memval and *.specIDloc you may get fresher values than what the gene saw.
Stick something like this in front of the gene in question:
cond
start
*.memval .test1 store
*.specIDloc .test2 store
stop
-
I thought those sysvars where populated before the DNA even began executing. Its a surety that *.memval is equal to *.specIDloc or the scan eyes gene would not activate in that cycle. This is truly puzzling, I wonder if it has anything to do with instabilities in the beta version (or some detail I'm overlooking). In any case, if I can't find a cause/solution I'll just rewrite the conspec system
-
Nothing is spontaneously changing itself. It's just that the console is not an ideal debug tool. It reads the memory values between cycles. If you want to look at what they were during the DNA execution, you need to pull that kind of trick.
-
Ok I'll go try that out now. Let you know the results
-
I think I see the prob. Apparently the updating of eyef, memval lag behind the actual position of the focuseye (so my results lead me to conclude)
Here's what I did:
[div class=\'codetop\']CODE[div class=\'codemain\' style=\'height:200px;white-space:pre;overflow:auto\']'Scan eyes
cond
*.eyef 0 =
*.memval *.specIDloc = or
start
.up 10 *.velscalar sub sgn 0 floor mult dup inc inc
*.timer 9 mod 4 sub .focuseye store
*.memval 991 store
*.specIDloc 992 store
*.eyef 993 store
stop
'Center eye5 on prey
cond
*.eyef 0 !=
*.memval *.specIDloc !=
*.focuseye 0 !=
start
*.focuseye 140 mult .aimdx *.robage sgn mult store
0 .focuseye store
stop
'Track prey
cond
*.eye5 0 >
*.memval *.specIDloc !=
0 *.focuseye =
start
*.refvelup 50 add .up .sthreshold *.eye5 sub sgn 0 floor mult store
*.refxpos *.refypos angle .setaim *.robage sgn mult store
*.memval 994 store
*.specIDloc 995 store
*.focuseye 996 store
stop
'Gene X
cond
start
*.memval 997 store
*.specIDloc 998 store
*.eyef 999 store
*.focuseye 1000 store
stop
And I followed the memory changes in the robot DNA dialog box.
*ASB means as seen by.
(ASB scan eyes) (ASB track gene) (ASB Gene X)
memv sID eyef memv sID focus memv sID eyef focus
--------------------------------------------------------------------------
0 310 0 0 310 0 0 310 0 -1
0 310 0 0 310 0 0 310 0 0
310 310 9 0 310 0 310 310 9 1
Now the target bot was only visible in one eye (eye5) yet its ID only shows up in memval when focuseye = 1
Also eyef (when focuseye = 1, i.e. when eyef should = eye6) is equal to what eye5 is. Throughout everything I ensured that only eye5 could see the bot so it pretty conclusively shows that the updating lags (since at no point eye6 = 9).
The formatting changed from me typing to after it posted, so the columns of the table don't align as they should Sorry about that.
[edit] While I make no assertions about when these stores occur (I think that's irrelevant) the last quadruplet is guaranteed to have been taken at the same time.
-
Not sure if you know already from your post, but make sure you understand that the entire DNA is executed before any action is taken by the bot.
-
Yeah, sound like the issue is simply that *.eyef is showing you the content of the current focus eye, but changing the value in focuseye won't have an effect till the beginning of the next cycle. (Nothing will happen mid cycle, the focus eye will not change and the value of eyef will not be updated till the cycle ends)
I think theres a post somewhere describing the sequence in which the commands are executed, but I'm fairly sure that focuseye takes effect before vision is updated (Generaly commands that affect vision or orientation will probably be executed before most other actions)
(My only remaining question on that matter is what happens when 2 bots are trying to affect eachothers .memloc or .memval location through ties... Does someone have priority or do they take turns going first?)
-
Yeah, sound like the issue is simply that *.eyef is showing you the content of the current focus eye, but changing the value in focuseye won't have an effect till the beginning of the next cycle. (Nothing will happen mid cycle, the focus eye will not change and the value of eyef will not be updated till the cycle ends)
I think theres a post somewhere describing the sequence in which the commands are executed, but I'm fairly sure that focuseye takes effect before vision is updated (Generaly commands that affect vision or orientation will probably be executed before most other actions)
(My only remaining question on that matter is what happens when 2 bots are trying to affect eachothers .memloc or .memval location through ties... Does someone have priority or do they take turns going first?)
It's probably whichever bot is first in the array. I once tried to make a conspec system where bots would read each others' .timer locs, and a similar problem came up.
-
O I see where I went wrong, the scan eye gene updated focuseye before the track gene had a chance to execute (and test it in the conditilon). So the solution is to put the gene which modifies the focuseye (scan eyes) after all genes which use it in a condition....duh . Thanks guys, I kinda feel embarrassed at this oversight.
-
Yeah, sound like the issue is simply that *.eyef is showing you the content of the current focus eye, but changing the value in focuseye won't have an effect till the beginning of the next cycle. (Nothing will happen mid cycle, the focus eye will not change and the value of eyef will not be updated till the cycle ends)
I think theres a post somewhere describing the sequence in which the commands are executed, but I'm fairly sure that focuseye takes effect before vision is updated (Generaly commands that affect vision or orientation will probably be executed before most other actions)
(My only remaining question on that matter is what happens when 2 bots are trying to affect eachothers .memloc or .memval location through ties... Does someone have priority or do they take turns going first?)
It's probably whichever bot is first in the array. I once tried to make a conspec system where bots would read each others' .timer locs, and a similar problem came up.
Does that mean the older bot would have priority? Not sure how the bots are aranged...
-
Does that mean the older bot would have priority? Not sure how the bots are aranged...
It might be by age. It might also stick the bots into the first empty slot available. In any case, it's an icky situation.
-
It's the first available slot generally. It's not supposed to matter, but there are a lot of edge cases to look at.
If you find a case where you think the problem is caused by ordering of bots in the bot array, log it as a bug in the bugs and fixes forum. Can't guarantee that it'll get looked at any time soon, but that's the best way to at least keep track of known issues like that.