Darwinbots Forum
Code center => Bugs and fixes => Topic started by: Elite on June 15, 2006, 11:23:02 AM
-
Here's what's working:
.tie
.deltie
.tienum
.fixlen
.sharenrg and other sharing commands
.tieloc
.tieval
.fixang
Here's what's not working:
.tielen1-4
.tielen
.tieang1-4
.tieang
But the sysvars .tieang1-4 are really useful for organising MBs
Also, the vision grid doesn't show ties underneath it, which is kinda annoying
There also seems to be no limit to the number of ties a bot can have, which might pose a problem for fixing the tie ports
EDIT: In fact, the limit is 9 ties
-
.tielen and .fixang should be working - I tested them pretty well a couple of versions back - but they won't work until you have multi status which doesn't happen until you've had a tie for 20 cycles. This is how it should work as PY explained it to me so thats what I did.
The 1-4 sysvars have been on my list for a few versions, just haven't got to them. Note that they also won;t work until you are multi. I honestly don't know if they work today or not. If you have a bot which uses them, that would help me test.
-
Yeah, you're right, .fixang does work
But .tieang1-4 and .tielen1-4 should work on soft ties too, shouldn't they?
As I see it, for the length and angle fixing sysvars you only need:
.tieang1-4
.tieang
.tielen1-4
.tielen
These would fix ties in particular angles and lengths, setting them to zero would cancel the effect, making the ties flexible again. If you want to set a tie angle to 0 just use 1256
And I think they should work on soft ties too, since then you can ready MB structures faster
-
What do you think of this for a revised tie system:
.tie
.deltie
.delport
.tiepres
.tiepres1-4
.numties
.tienum
.readtie
.tieloc
.tieloc1-4
.tieval
.tieval1-4
.sharenrg
.sharenrg1-4
.shareslime
.shareslime1-4
.shareshell
.shareshell1-4
.sharewaste
.sharewaste1-4
.tieang1-4
.tieang
.tielen1-4
.tielen
New sysvars are in bold. I'll explain:
.delport allows you to delete a tie port, so 1 .delport store would delete the tie in tie port 1
.tiepres1-4 allows you to read back to tie phase of the tie on each tie port
.tieval1-4 and .tieloc1-4 are tieportized versions of the originals, allowing for easier tie-feeding and better manipulation of MBs
There are also tieportized versions of the sharevars so that you can share independantly rather than with all, but keeping the originals, which affect all tie ports
What do you think?
-
I worry about
1) Adding tons of new highly specific sysvars
2) Only being able to address 4 ties rather than all 10 or N in a given cycle
3) Mechanisms for mapping ties to tieports to the 1-4 sysvars and the genome complexity of this
4) The future when there may be more than 10 ties allowed *See footnote
5) Future morphological features which may also require similar addressing of N possible components
Hows this for an idea. There are special vector sysvars for which the behaviour of .store, .inc and other operators change. Instead of storing a single value off the stack in a single mem location for example, they store N values off the stack into a vector of N "virtual mem locations".
Instead of
10 .tielen1 .store
20 .tielne2 .store
30 .tielen3 .store
40 .tielen4 .store
we do
10 20 30 40 4 .tielenV .store 'V for Virtual or Vector
we could also do
10 20 30 40 50 60 70 80 90 9 .tielenV .store
The number on the top of the stack indicates the number of locations to store I.e. If you wanted to change some tielens but not others, maybe we use a negative number to indicate no change. I.e.
-1 20 -1 40 -1 60 -1 80 -1 9 .tielenV .store
only changes ties with IDs 2,4,6 and 8
If we follow this route, we only need add one new sysvar for each sysvar for which we want to have vector addressing:
.tielenV
.tielocV
.tievalV
.sharenrgV
.
.
This has the advantage that if we decide to increase the maximum nubber of ties for example, no new sysvars need be added. We continue to support the current 1-4 sysvars for compatability, but these superset them.
Thoughts?
*I want to allow ties to nowhere in some future version. Think of them as spikes or spines. We need to implement tie collision detection first, but you can imagine a bot growing long spines to keep shot bot preditators out of range...
-
I like this a lot Eric.
You might need to increase the size of the stack though if we go this route. I can see some pretty complex stuff around the corner where 30 or 4 numbers could be stacked with mathematical operators to acheive some pretty spectacular dynamic combinations of effects.
-
You've got some great ideas Eric
Generally, there has to be some way of manipulating multiple ties at once. For example, if I want to change the length of four ties I shouldn't have to:
1 .tienum store
10 .tielen store
then next cycle
2 .tienum store
20 .tielen store
Instead, it should be something simple like (using your idea):
10 20 .tielenV store
That way you can quickly and simply manipulate multiple ties
*********
Another thing, could we have a sysvar .birthtie that reads back 1 when a bot is attached to another bot via a birth tie
-
You can check out the New Tie Paradigm (http://www.darwinbots.com/WikiManual/index.php?title=New_tie_paradigm) for the C++ version. We should try bringing the two versions (2.4 and C++) together. I'm open to entirely scrapping the system I have there for a new one. I'm just saying let's be careful about creating a new system if it's just going to be supplanted a little later.
-
However, I don't see the point of .tieang, as it's just the same as .fixang, isn't it?
Just noticed this while re-reading the thread.
I have to point out that the two are definitely NOT the same. They serve an entirely different purpose.
Tieang was actually the first command that changed the angle of a tie just as Tielen was the first to change its length. The difference is that both these commands act on a temporary basis and will spring right back again as soon as they are able to.
Use of these commands allow a worm structure to "wiggle" and thus propel itself along. Check out Carlo's Vermis_P.
Also this
These would fix ties in particular angles and lengths, setting them to zero would cancel the effect, making the ties flexible again. If you want to set a tie angle to 0 just use 1256
And I think they should work on soft ties too, since then you can ready MB structures faster
If they work on soft ties then the ties aren't soft any more are they?
I don't have an objection to allowing ties to become hard faster at the expense of some energy perhaps.
Maybe .stifftie can be redesigned somewhat to fill this role. it never worked that well for its intended purpose anyway.
in summary, Fixang and Fixlen permanently change the default angle and length of a tie while Tieang and Tielen temporarily change the length and angle of the tie.
All tie commands can only work on a hardened tie since prior to that the whole system is soft, squishy and deformable. Additionally angles are free to be changed as much as you like during the initial non-hardened time.
-
Just noticed this while re-reading the thread.
I have to point out that the two are definitely NOT the same. They serve an entirely different purpose.
Tieang was actually the first command that changed the angle of a tie just as Tielen was the first to change its length. The difference is that both these commands act on a temporary basis and will spring right back again as soon as they are able to.
Use of these commands allow a worm structure to "wiggle" and thus propel itself along. Check out Carlo's Vermis_P.
Ah right, I get it, thanks for clearing that up
.fixang and .fixlen = permanent
.tielen and .tieang = temporary
.tieang1-4 act more like .fixang though, and likewise with .tielen1-4 ... I think that what's happening is that they're not getting reset and so are permanently forcing the tie to the value stored in them
Also this
If they work on soft ties then the ties aren't soft any more are they?
I don't have an objection to allowing ties to become hard faster at the expense of some energy perhaps.
Maybe .stifftie can be redesigned somewhat to fill this role. it never worked that well for its intended purpose anyway.
in summary, Fixang and Fixlen permanently change the default angle and length of a tie while Tieang and Tielen temporarily change the length and angle of the tie.
All tie commands can only work on a hardened tie since prior to that the whole system is soft, squishy and deformable. Additionally angles are free to be changed as much as you like during the initial non-hardened time.
Ok, so hardened ties only for setting permanent angles and lengths
Hold on, Endy's Alga Tier uses .tielen1 to violently fling other bots away from it, and it does this while the tie is soft, so you can change the length of soft ties?
I'm confused
I've got to do some experimenting in 2.37.6 ...
-
Yep PY, you're correct, .tielen .tieang .fixang and .fixlen only work once a tie is hardened, which takes 20 cycles
And the tie fixing commands are noticably different to the tie changing commands, the tie changing commands like .tieang spring back quickly, allowing for wriggling motions
-
I think the .tielen1 was an unexpected consequence, and PY really meant them not to work on birth ties.
-
On Tie Lengths and Angles
Replacing .tielen1-4 and .tieang1-4 in 2.4
I've had an idea inspired by Nums' use of commands in his new 2.5 tie paradigm
The problem with re-implementing the tie port commands like .tielen1 into 2.4 is that such a system is unmanagable when there is lots of ties
So how about these four commands to replace the sysvars .tielen1-4 and .tieang1-4
settielen
settieang
tielen
tieang
They affect the tie port on the top of the stack, so:
50 2 settielen
Would permanently set the length of the tie on tie port 2 to 50
And tielen and tieang would temporarily change the length for 'wiggling' motions, like the .tielen and .tieang sysvars
Alternatively, you could have positive numbers specify tie phases (number in .tie) and negative numbers specify tie ports (again, taken directly from Num's new tie paradigm)
What do you think?
-
.tieang1-4 act more like .fixang though, and likewise with .tielen1-4 ... I think that what's happening is that they're not getting reset and so are permanently forcing the tie to the value stored in them
Yeah .tieang1-4 does change the tie angles permanently as does .tielen1-4
maybe that was bad planning on my part to use this nomenclature instead of using .fixang1-4 but it's a little late to change it now.
I think the .tielen1 was an unexpected consequence, and PY really meant them not to work on birth ties.
Extremely unexpected. I thought I had applied all the safeguards to specifically prevent these controls working on birth ties.
-
They affect the tie port on the top of the stack, so:
50 2 settielen
Would permanently set the length of the tie on tie port 2 to 50
Numsgil and I actually had a discussion along these lines once before.
The general consensus was that making the system work with two numbers on top of the stack would be detrimental to evolutionary advances since it makes the chances of evolving a specific sequence a lot lower.
I could be wrong though. It was quite a while ago but as far as I remember that was the reason I used the tie controls the way they are now.
I would have no objection to switching them to the method you suggest as long as we can get a consensus decision among DB users.
Very few robots (probably all my own) have really utilized the tieport controls anyway.
-
I've been digging for old threads, and there's some great ideas down there
Numsgil and I actually had a discussion along these lines once before.
The general consensus was that making the system work with two numbers on top of the stack would be detrimental to evolutionary advances since it makes the chances of evolving a specific sequence a lot lower.
I could be wrong though. It was quite a while ago but as far as I remember that was the reason I used the tie controls the way they are now.
I believe that this is the discussion you are refering to:
New Tie Structures (http://www.darwinbots.com/Forum/index.php?showtopic=560)
And there's some more discussion here too:
Tieports (http://www.darwinbots.com/Forum/index.php?showtopic=1017)
Very few robots (probably all my own) have really utilized the tieport controls anyway.
Personally, I find them extremely useful. They are powerful because you can control multiple ties in one cycle.
-
I believe that this is the discussion you are refering to:
New Tie Structures
Yup that's the one. As you can see my idea was very similar to your own. Only difference is that I put my address variable on the stack after the command. Otherwise identical.
Personally, I find them extremely useful. They are powerful because you can control multiple ties in one cycle.
So do I.
Have you ever tried making a bot that crawls by swinging two arms forward and out, fixing them with fix pos then contracting and swinging them back to pull the main body forward.
You can stear it by moving one side or the other different distances.
I tried this once in combination with a trailing veggie for energy. I didn't really spend much time on it though. It was called T-Swimmer but I can't seem to find its code any more.
-
Yup that's the one. As you can see my idea was very similar to your own. Only difference is that I put my address variable on the stack after the command. Otherwise identical.
Yeah, I really think this would be a good idea. How about a poll to see what the general concensus is?
So do I.
Have you ever tried making a bot that crawls by swinging two arms forward and out, fixing them with fix pos then contracting and swinging them back to pull the main body forward.
You can stear it by moving one side or the other different distances.
I tried this once in combination with a trailing veggie for energy. I didn't really spend much time on it though. It was called T-Swimmer but I can't seem to find its code any more.
Sounds interesting. Using ties for movement is much overlooked, don't you think? It tends to be the realm of very developed and complex MBs.
It's been a while since I programmed some serious MBs so I think I'll give a tie-mover a go
I think I'll also give a new league a go - no movement commands allowed, only ties
-
Wow
Just take a look at this
This is just an early prototype, so it just moves continuously in a straight line, but it doesn't half look cool
-
When I run it the ties just dissapear.
-------------------------------
I'm relatively close to getting the C++ version tie friendly, if you'd like to clear your calender to start playing/testing it for me
I'm probably going to finish at the end of the month with a general release Alpha.
-
When I run it the ties just dissapear.
Unfortunately something in 2.4 prevents it from working
It only works in 2.37.6
I'm relatively close to getting the C++ version tie friendly, if you'd like to clear your calender to start playing/testing it for me
I'm probably going to finish at the end of the month with a general release Alpha.
I can have a go at programming a bot in your new tie system
The wiki says your new tie paradigm sysvar .tieangle is a read sysvar. Am I right in thinking that it will change the angle of a tie when you write to it?
-
Unfortunately something in 2.4 prevents it from working
It only works in 2.37.6
The swimming routine in 2.4 was never ported. It's commented out and still uses 2.36 physics. No acceleration forces are calculated in 2.4 due to tie actions on a fluid medium.
I noticed this in the source long ago and it's been on my list to port, but never high enough.
-
The wiki says your new tie paradigm sysvar .tieangle is a read sysvar. Am I right in thinking that it will change the angle of a tie when you write to it?
Nope. I'm not sure of the exact mechanics, but in order to change the angle between[ ties you'll need to use another command I'm still figuring out. Basically I'm trying to get it to work like muscles in the human body do, with ties being the bone.
To change the angle between a bot and a tie, you'd just need to unlock the bot, and the bot can swivel like a ball bearing.
The swimming routine in 2.4 was never ported. It's commented out and still uses 2.36 physics. No acceleration forces are calculated in 2.4 due to tie actions on a fluid medium.
I noticed this in the source long ago and it's been on my list to port, but never high enough.
I could never figure out the real life math. The way 2.37 handles swimming forces has some issues I'm not happy with. If you check that New Tie Paradigm page on the wiki you can see my best current guess. Sprotiel, I believe, thought I had it wrong and presents another method. They're not directly comparable, however, as we make different base assumptions (mine being more general).
-
This is just an early prototype, so it just moves continuously in a straight line, but it doesn't half look cool cool.gif
Sweet isn't it?
That is very much how T-Swimmer did it as well.
The difference was that he had a trailing veggie for energy.
-
I worked on a worm-like mb that used .setaim to move, but it doesnt have very precise food hunting ability. It swivels the head back and forth to approach the target (the tail follows the directions of the head in this sense), but while doing so it often loses sight of the target ^^
-
I had the same kind of problems with Inchworm. I managed to get it working reasonably well by using .dx and .sx to shuffle the head sideways in order to zoom in on food.
I wonder if a T kind of bot could do it by means of shortening and legthening the ties to each side of the T while the ends of it are anchored. I would really like to get away from any use of .sx, .dx, .up and .dn in the design.
-
I would be very interested in seeing an evosim with a MB that doesn't use .up, .dn., .dx, or .sx to move. Then turn the Movement Efficiency to 0 so that it can't devolve into single celled creatures.
I imagine the MB would still "break", but I'd love to see how it does so. My guess is that it would learn to use ties as slings to catupult themselves around the sim.