Included page "clone:symbrion-ec" does not exist (create it now)
Minutes Meeting in Amsterdam (2012-6-4) - 22 Jun 2012 13:28
At the start of June we had another cluster meeting in amsterdam. You can find a pdf of the minutes here: Minutes Meeting June 4.
In the minutes relevant parts of the presentations that were given are included in the hope that this clarifies the discussions somewhat.
Tags: | Comments: 0
Minutes for meeting in Stuttgart (2012-1-11) - 12 Jan 2012 16:03
Reader's guide
- Search for string "[!]" in all the text to quickly jump to IMPORTANT elements (e.g. discussion, todo, open questions, etc.)
- Organization: (1) summary of decision (2) exhaustive notes
- [DECISION] tag marks ''real'' decisions. The rest is important information.
MORNING DECISIONS
Sub-task 2 (organism controller)
- Yaoyao has to provide same measurements.
- [!] should be done within one week
Sub-task 3 (internal rewards)
- [DECISION]: Stick with distance for the demo
Sub-task 4 (simulation)
sub-task 4.1 (libor)
Threaded implementation
- [!] Libor organizes a test check whether sensor updates are synchronized
- Motivation: threaded controllers speed up the simulation (if only a little).
IR sensors: Currently a binary output with respect to a predefined threshold distance
- [!] make it proportional (integer values)
Docking:
- [!] Info: we agree on assuming that it is 2D planar docking
- [!] Info: both cells need to agree to be docked to perform docking, no protocol yet. currently: all single robots are always ready and claiming they want to connect. Ie. two close candidates will connect.
- TODO: Discussion Libor/Vojta
Requirement wrt. evolutionary runs (target: to render a video for demo)
* [!] we have to evaluate the requirements in terms of number of evaluation wrt. evolution.
* [!] ??WHO/WHEN??
Integration of energy simulation
* [!] [DECISION]: assume linear decrease of energy
* Goal: over-simplify (we dont need precise modeling for now),
Running the simulator on a server
- We cannot go without GPU as OpenSceneGraph strongly relies on it. Too costly to re-program.
- [!] [DECISION]: We have to go with a GPU machine
Sub-task 4.2 (Jean-Marc)
- Exchange of genome btw organisms:
- [!] [DECISION] : Lamarckism (but homog/heterogeneous is just a feature wrt. implementation - ie. it's your pb)
- Decision: who is responsible within other subtasks (for implementation)
- [!] [DECISION] : Task 1 will nominate someone by monday 2pm.
- Task 3 is already done
- Task 2 is Jean-marc
- Berend is available for some coding if needed
- [!] [DECISION]: Will use Stuttgart SVN (everything is already there), not launchpad
AFTERNOON DECISIONS
Global discussions and decisions
Agreement on organization
- (1) [Swarm including egg] —(2)> [Organism] --(3)——> [Moving organism]
- Swarm incl. egg
- Recombination, variation of body shapes
- Morphogenesis:
- Explicit_1 (Wenguo/Christopher)
- Explicit_2 (YaoYao.1)
- Implicit_1 (Ronny)
- Implicit_2 (YaoYao.2)
- Implicit_3 (Michèle)
- towards moving organisms
- AHHS (Graz)
- GRN (Yaoyao)
- CPG (Jean-Marc/Evert/Florian)
- Swarm incl. egg
- Also, can be reformulated as a cycle:
- birth => learn to walk => (foraging) => reproduce
- We do not do foraging in the demo
Questions
- what will be in the report ? what will be presented as a demo ? outcome as paper(s) ?
- [!] PROPOSITION / DECISION:
- Morphogenesis:
-
- DECISION: two methods (1 explicit, 1 implicit)
- DECISION: the explicit is Wenguo/Christopher
- DECISION: decision for the implicit option will be taken by the sub-task people and is due on monday 2PM "[!]"
- Michèle will send a message reminding the indicators (deadline: tonight)
- All are asked to fill the figures by friday afternoon for each implicit approaches
- A skype meeting will be organized to choose which implicit approach is selected - friday afternoon
- note: this is a pragmatic choice to target the demo based on what is available now.
- note: all other approaches will be reported in the Report, incl. possible comparaison.
-
- moving organism
-
- AHHS/GRN/CPG are kept for the report, then decision will be made for the demo *just after the report*
- decision for the demo could be one of them, or (part of) all of them (with meta-gene selection)
- we will also do the combo version (meta-gene version)
-
- Morphogenesis:
Various Questions/Remarks:
Q: how to change the view in robot3D?
A: ''press the button'' in robot3D
Recommendations/Requirements:
Building blocks for morphogenesis:
- Magic transportation (then true docking)
- What is in the message for the recruitee when to arrive and with which orientation
- [!] Berend is managing a dedicate System Description for the Evolutionary Task Force. (general source information)
- everybody should contribute (what have you done, how it works)
- Provide *detailed* description of experimental conditions.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=-=-= RAW-NOTES:BEGIN =-=-=
=-=-= RAW-NOTES:BEGIN =-=-=
=-=-= RAW-NOTES:BEGIN =-=-=
=-=-=-=-=
[Gusz presentation]
Past and present:
- mid-october: Evolution Cluster is acted, goal: integrated demo before the 4th review meeting
- 2-3 november: kick-off meeting, 4 sub-tasks, agreement on working protocol & targets (demo & joint papers). Planned weekly skype meeting (thursday morning)
- 11 january: review of progress, planning or research towards demo & joint publication(s)
Future:
- early march 2012: Annual progress report
- mid-april 2012: review meeting presentation
- Summer 2012: conference paper(s)
- Fall 2012: journal paper(s)
- Winter 2012/2013: big journal paper (Nature, Science, PNAS ?)
=-=-=-=-=
=-= SUB-TASK 1 : MORPHOGENESIS [Michele] =-=
General Introduction
- Agreed:
- viable shape
- number of robots [2-10]
- test for evolvability and controllability
Group 1: wenguo@UWE, christopher@UT
- explicit representation
- implemented in Robot3D, nested with Stage simulator ==> ? ==> robot3d is just for visualization
- demo with 25 robot - ?
- video shows *recruiting*, not evolution
- ie. this shows birth from egg to organism
- Discussion: Robot3D with nested Stage "[!]"
- ok for Swarm
- if swarm and organisms: must be extended, not that easy. (emulate 3D organisms as obstacle in Stage, running mixed controller in Robot3d (from Robot3d or from Stage)).
- note on robot3D: all features are there (incl. radio communication)
- evolution of Wenguo's representation
- Christopher did some tests, not with robot3d — preliminary tests (fitness: biggest one), sounds ok.
- pending: do it in robot3d
Group 2: Graz (Markus, Ronny)
- genotype is linear in the complexity of organisms (not size)
- not tested wrt. viability
- variation operators: point mutation, crossover, transposons (planned)
- evolved: target pattern, symmetries, etc.
- tested:
- netlogo, robot3d
- no recruiting for the moment, only focus on direct assembly (focus: recombination, mutation, explicit fitness function for shape)
Group 3: Ghent (yaoyao)
- inspired by genetic regulation
- two versions: centralized, decentralized
- variation: gene dupl., adaptive mut.
- properties: one-to-many, explicit
- assume: position/orientation sensing
- Discussion : how to dock with real robots? camera alignement? (ubisense will not be precise enough). Docking is not working in robot3D - how to do it?
Group 4: INRIA (michele)
- Stochastic Cellular Automaton
- implicit, stochastic, ration pheno/geno=1.2
- evolvability is fine
- limits: controllability
- tested on robot3D (teleport?)
- Q?: variability of shapes, controllability, efficiency of locomotion
SUMMARY:
- five different approaches
- explicit: wenguo, yaoyao.1
- implicit: yaoyao.2, michele, ronny
- assessing development:
- wenguo is 0 week away from robot3D (assuming stage is ok)
- graz is 1 week away from robot3D
- yaoyao is 2 weeks away from robot3D
- michele is 0 week away from robot3D (assuming magic teleportation is ok)
=-=-=
=-= SUB-TASK 2 : ORGANISM CONTROLLER [Juergen] =-=
task: control the behavior of the robot organism
General introduction:
- starting point:
- cpg (evert)
- cpg (florian)
- grn (yaoyao)
- ahhs (jurgen)
- proof of concept: integrate in robot3D
- Now:
- CPG (evert, florian, jean-marc)
- GRN (yaoyao)
- AHHS (jurgen)
- robot3d is used in experiment, approaches
Demo/Experiments:
- Arena: flat, surrounded by walls, 50x50 KIT-robot sizes
- organisms and eggs in arena
- organism pool: i, I, T, H
- each robot organisms operates on its own genome
- genomes are collected and transmitted all the time
- if an egg is in sensor-range, it is fertilized
- a genome embeds all three sub-genomes for the three competing method
- the choice of organism (i,I,T,H) is *fixed* per organism
- one genome value chooses among the three sub-genomes
Roadmap:
- scenario file incl. organism and eggs (Jean-marc, finished)
- communication org to egg (still open)
- communication btw ctls in the org (parly finished, all)
- teleporting of robots to egg for organism (still open)
- meta-controller with ctl-template (finished, Jean-Marc)
Group 1: Graz (juergen)
- AHHS
- online evolution (ie. evaluation of a solution starts from whereever the robot is), fitness: travelled distance (explicit)
- robust to noise, though there is no reevaluation.
- integration in robot3D, genome stored as one string
- still todo:
- collecting all genomes to write it to the eggs
- evaluation of the fitness seems corrupt (…?) — localization problem …?
Group 2: Ghent (Yaoyao)
- GRN approach (similarities with Floreano's AGE)
- first test with robot3d
- learns to walk in Robot3d (which morpho?)
Group 3: INRIA+STUTT+VU (Jean-Marc, Evert, Florian)
- oscillator + NN = sensory information to motor outputs
- IR-sensors[1-8] => [[NN]]=> amplitude, phase shift, frequenscy, angle offset => [[CPG]] => hinge angle
- weights of NN are optimized
- heterogeneous approach — one genome per robot
- cf. also homogeneous approach. (one genome per organism)
- no central clock, but start at the same moment (cheating in the simulation)
- results with heterogeneous approach
- running in robot3d
- mu+1 is used
- did it for snake with 6-modules
- "Q: homogeneous may be better, but need synchronization information (such as transmitting info from one block to the the other)"
- "Q: average distance travelled for the same organisms"
SUMMARY:
- three different approaches, overarching system including all these methods
- no obligation of choosing now
- all three approaches have been tested, Juergen's and Jean-Marc's also have experimental results.
- Yaoyao has to provide same measurements also. => one week "[!]"
=-=-=
=-= SUB-TASK 3 : INTERNAL REWARDS [Evert] =-=
task: internal rewards…
- Results with webots, open and closed arenas
- QI (gps and/or sensorimotor space), distance, learn, random —- compared on distance travelled within small intervals
=> for small intervals: QI, learn, random are more or less the same wrt. distance travelled. Far from distance.
=> for smaller intervals: similar.
(note: i'm not sure about this part, please refer to slides)
- used a ''GPS'' emulation with 10cm error
- QI is not that good because …? possibly because envt is not rich enough (but also relates to QI coverage wrt. epsilon value) "[!]"
=-=-=
=-= SUB-TASK 4 : SIMULATION [Libor] =-=
task: … implementation and speed issues
Group 1: Libor
- what's new in the simulator (since october @york)
- messaging system
- radiomessages: broadcast to all (zigbee) —- possible issue with bandwidth
- organism/messages: to physically connected neighbors
- controller/agent outfit
- from: threadless implementation
- to: threaded implementation (// performance)
- motivation: to solve a problem of synchronized sensor update — should tested further "[!]"Libor organizes a test "[!]"
- may improve the speed, "[!]" but remain to be tested "[!]" (ie. physics still runs on a single core, which is the main thing)
- IR sensors
- single beam irradiation pattern
- beam heading corresponds to robot body orientation
- Binary output with respect to a predefined threshold distance — "[!]" make it proportional (double or float value)
- Docking
=> Remark: based on position on the cells at the moment, plan for camera-driven docking with real robots "[!]"
=> "[!]" we agree on assuming that it is 2D planar docking
=> note: both cells need to agree to be docked to perform docking, no protocol yet. currently: all single robots are always ready and claiming they want to connect. Ie. two close candidates will connect. "[!]"
- LED not used (failing LED guidance system at the moment)
- Document online (symbrion-ec wiki)
- Speed issues
- close to real-time to 10 times slower.
- "[!]" we have to evaluate the requirements in terms of number of evaluation wrt. evolution.
- Simulation outlook
- support - priority #1
- integration of energy simulation
- "[!]" DECISION : assume linear decrease of energy —- goal: over-simplify (we dont need precise modeling)
- proposal : use time till last charge as indicator, implement it as a new sensor (battery level sensor), decrease linearly through time.
- server for final experiments - suggestions
- one server: 12 CPUs, 40GB RAM
- no video card available (no GUI, no GPU), remains questionnable.
- target headless simulator would be great but…
- "[!]" We cannot go without GPU as OpenSceneGraph strongly relies on it. To costly to re-program (and possibly, it would be slower). We have to go with a GPU machine.
- other pending tasks: on-board sim, sampling-based planning method for organism control/collision avoidance (lacking manpower due to priorities on simulation)
Group 2: Jean-Marc (with Berend, Vojta, Anne, Lutz) (talk done in the afternoon, reported here for consistency)
Done:
- meta-controller
- communication btw organisms, within organism
- CPG controller, heterogenous
- space for other controller
Todo:
- echange of genome btw organisms: once an organism is born, and then die, do we keep the evolved controller (lamarckism) or send the initial one (baldwin).
=> "[!]" Decision : Lamarckism (but homog/heterogeneous is just a feature wrt. implementation - ie. it's your pb)
- egg calling morphogenesis process
Questions:
- Who is responsible within other sub-tasks?
=> "[!]" …?
- Use launchpad?
=> "[!]" [DECISION]: will use Stuttgart SVN (everything is already there)
…
=-=-=-=
SUMMARY OF MORNING:
- many cross-talks, team spirit
- Gusz is happy, others agree
=-=-=-=-=-=
AFTERNOON SESSION
[Swarm including egg] —(1)> [Organism] --(2)——> [Moving organism]
(0) swarm incl. egg
- recombination, variation of body shapes
(1) morphogenesis:
- Explicit_1 (Wenguo/Christopher)
- Explicit_2 (YaoYao.1)
- Implicit_1 (Ronny)
- Implicit_2 (YaoYao.2)
- Implicit_3 (Michèle)
(2) towards moving organisms
- AHHS (Graz)
- GRN (Yaoyao)
- CPG (Jean-Marc/Evert/Florian)
Also, can be reformulated as a cycle:
- birth => learn to walk => (foraging) => reproduce
- we do the first two
Evolutionary Components
- representation (genome)
+ body
+ controller
- variation
+ mutation
+ crossover
- fitness def for selection
QUESTIONS
- what will be in the report ?
- what will be presented as a demo ?
- outcome as paper(s)
PROPOSITION / DECISION: ""[!]""
- AHHS/GRN/CPG are kept for the report, then decision will be made for the demo *just after the report*
- decision for the demo could be one of them, or (part of) all of them (with meta-gene selection)
- we will also do the combo version (meta-gene)
- morphogenesis:
- Decision: decision for ONE solution will be taken by the sub-task people and is due on monday 16th "[!]"
- note: this is a pragmatic choice to target the demo based on what is available now.
- note: all other approaches will be reported in the Report, incl. possible comparaison.
Report demo paper 1
(=>choice)
Wenguo/C ?
Yy.1 ?
Ronny ? ?
Yy.2 ?
Michele ?
AHHS +
GRN +
CPG +
Combo + ?
Open questions:
- trade-off btw favoring all in //, or arbitrarily selection some
Additional decisions of morphogenesis (target: report) "[!]" :
- Michèle will send a message within the next 3 days reminding the indicators
- All are asked to give feedback by monday "[!]"
- Then, all are asked to fill the table wrt. their approach and indicator
=-=-=-=-=
=-=-= RAW-NOTES:END =-=-=
=-=-= RAW-NOTES:END =-=-=
=-=-= RAW-NOTES:END =-=-=
** Additional notes from the coordinator intervention **
19/1: senior meeting
review meeting:
- 2-4th may, Stuttgart - confirmed?
- required presentation of the planned outcome
- mass production should have begin by the review meeting
- BUT some results from production should be available at the review meeting (4-5 people more, target 10-15 robots (5 each))
- target: mass-production is finished in june/july
- message:
- dont speak about prolongation
- simulation is good, but without hw support, will not be accepted
- joint ownership for the robots (agreement will be proposed)
- no shifting of the budget.
- distribution will be decided in great assembly
end.
Tags: | Comments: 0
Minutes Converence Call, November 17 - 18 Nov 2011 10:48
Global Task:
- Each leader writes a paragraph on the progress before Sunday night.
Synchronize the experiments in each subtask so that people do comparable experiments
- Every group holds a private skype when necesarry
- Important thing is that experiments are comparable
Subtask 1: Morphogenesis
- Wenguo has improved his representation to include different connection rotations and heterogeneity
- Yao: done some experiments in its simulator; working with Ronny to integrate his findings.
Tasks:
- Michele: Before sunday evening, paragraph summarizing progress.
- Wenguo: Create mutation, crossover. He will send them to Christopher who will help make them good
Subtask2: Organism Control
- Until November 30 everyone can use their own simulator
- By December 15 the solution should be running in Robot3D
- We postpone the decision until December 15th, as we need to be able to compare them and for that they need to run in the same simulator
- Everyone needs to be careful that 2 weeks to port your code may be short, so you should look into porting it sooner.
Tasks:
- Juergen: Before sunday evening, paragraph summarizing progress.
- Everyone: Send a short text (max 5 - 10 lines) on the progress you made
- Juergen has an implementation in his own simulator and will implement On-Line On-board evolution there first, and then move on to Robot3D
- Evert has an implementation in Wiibots and will first implement the inclusion of sensors there, and then move on to Robot3D
- Florian does not have his own simulator and will work in Robot3D immediately
- Yao has an implementation in his own simulator and will move toward Robot3D
- Ronny has an implementation in his own simulator
Subtask3: Internal Reward
- They will adapt an implementation of the QI to create a Static version of QI.
Tasks:
- Evert: Implement (he plan to do that before the week-end)
- There will be an internal discussion after the skype.
- Evert: Before sunday evening, paragraph summarizing progress.
Subtask 4: Simulator
- There are still some bugs that Lutz and Vojta are working on.
- For instance the plugin threads are currently faulty
- The target platform for now will be Ubuntu 11.04.
- Any bugs reported should be from this platform
- Report any bugs to Vojta
- We will organize a number of tutorials on using Robot3D
- First tutorial will be somewhere next week.
- Topics will include
- Getting, Compiling and Running Robot3D
- Where to write your controller code, and how to use it in the simulator
- Some examples
- Libor and crew have created a component which measures how fast/slow the simulation is compared to real time
- Several scenarios have been conceptualized and will be implemented
- First results somewhere next week (Wednesday?)
- Libor will investigate whether a publication can be made on the simulator
- The simulator may be a legacy of the project with desirable characteristics
Tasks:
- Berend: Before sunday evening, paragraph summarizing progress
- Berend: Confer with Anne and Vojta about bug-reporting and tracking!
Tags: minutes skype-meeting | Comments: 0
Minutes Converence Call - 10 Nov 2011 15:51
SUB-TASK 1: MORPHOGENESIS
Goal
To test the feasibility of the representation.
Spokesperson
- Michele (INRIA)
Partners
- Wenguo: explicit representation, task: create and test evolvability
-
- Christopher will help Wenguo with building operators for the explicit representation.
-
- Ronny: we have a genome which is evolvable and can build an organism. Tested in simulation.
-
- Yao will work with Ronny
-
- Inria, implicit representation, task: test evolvability
Other
What a good representation requires, depends on the size of the experiment/organism.
To bootstrap the evolution, we may need an alphabet of shapes; I, H, X, L, T.
- Ronny: A predefined alphabet may make it hard for evolution to find other shapes.
Initialization phase
For each representation we need to:
- Know which percentage of individuals is viable, when the genome is initialized randomly
- How long it takes to complete a shape
- Define crossover and mutation
- Know which percentage of offspring viable after crossover/mutation
-
- The means for:
- Explicit: Is the expression well-formed?
- Implicit: does it converge
-
The upper-bound on the size of organism is: 4-10.
Procedure
Everyone creates an experiment in their own simulator and sends their plan to Michele. Michele compiles this into a workplan?
SUB-TASK 2: ORGANISM CONTROL PARAMETERS
Goal
The goal is to compare CFG and AHHS and GRN (Yao-yao).
Task: walk, recognize the walls.
Spokeperson
- Juergen.
Partners
- Juergen (AHHS)
- Evert (CPG),
- Florian (CPG)
- Yao-yao (GRN)
Procedure
Evert sends an e-mail and organizes things.
SUB-TASK 3: INTERNAL REWARD
Goal
The goal is to re-calibrate the controller when a new shape is created; this recalibration is a nested optimization problem (on-line learning).
In order to optimize, we cannot use a external measure, so what is then criterion?
Options:
- Distance
- QI from the traces
- evolved QI (learning weights on the sensori-motor states) ** this might be too ambitious **
Spokesperson
- Evert
Partners
- Evert
- Michele
- Christopher
Procedure
Evert sends an e-mail and organizes discussion
SUB-TASK 4: SIMULATOR
Goal
Benchmark the simulator to get a feel for how large an experiment we can run in what time.
Spokesperson
- Berend
Partners
- Berend
- Anne
- Lutz
- Libor
Scenario
- Test#3: loose modules wandering, organisms moving randomly. Empty space with walls.
- Anne: appropriate sensors;
Other
Christopher: Do we keep all sensors on everywhere, or do we turn off sensors that are useless in simulator?
- For now we keep them all on, this is probably needed for AHHS anyway.
Berend: We will also simulate computational effort of crossover and mutation, to make the test as realistic as possible.
SCENARIO
- Procreating requires moving around.
- Egg receives 2 DNA; then becomes active and recruit others.
- A cell is an egg or a free cell.
-
- Whether a robot is an egg or a free cell is fixed at the start of the simulation
-
- An organism has a maximum lifetime (to be set later).
- An egg does not move
Tags: minutes skype-meeting | Comments: 0
Minutes Kick Off Meeting - 03 Nov 2011 16:21
Evolutionary Task Force
Amsterdam, november 2-3 2011
people:
Michèle Sebag, Marc Schoenauer, Gusz Eiben, Evert Haasdijk, Juergen Stradner, Anne van Rossum, Berend Weel, Florian Schlachter, Wenguo Liu, Jean-Marc Montanier, Remco Tukker, Nicolas Bredeche
TODO:
- description of agenda for each task-force (deadline: Friday, nov. 11th)
- weekly executive summary (by Gusz)
WEEKLY NET MEETING: THURSDAY 11:00 CET.
- Every Thursday
- At 11:00 CET
- Skype or Mumble?
SUB-TASK FORCES
- individual control parameters INACTIVE/IGNORED
SUB-TASK FORCE #1 : morphogenesis control parameters
- Explicit (UWE+UT?) vs. Implicit (Graz and TAO) representation of the shape
- First step: explorative
- Sub-Task Force: UWE, INRIA, (+ Ronny@Graz)
- Deadline: NOV. 30
Ronny | Wenguo | INRIA | |
evolvable | + | - | . |
tested on robot | ? | + | . |
SUB-TASK FORCE #2 : organism control parameters
- First step
- CPG(evert)
- CPG(florian)
- AHHS
- we forget, for the moment, about the joint AHHS-CPG architecture (AHHS as sensor info manager)
- This sub-task force: berend, juergen, florian, anne
- Deadline NOV. 30
AHHS | CPG(evert) | CPG(florian) | |
online-evolv. | - | + | - |
sensor inputs | + | - | + |
tested | + | +? | + |
SUB-TASK FORCE #3 ''internal reward (during lifetime learning)''
- people: VU, INRIA, UT?
- investigation of curiosity as internal reward.
- Deadline: NOV. 30 for exploration
SUB-TASK FORCE #4 ''benchmark of simulator''
- people: Anne/almende, Berend
- Benchmarking the simulator
- nb and size of organisms, nb of cells, test scale up
- test #1: swarm of cells
- test #2.a: organism, snake
- test #2.b: organism, H-shape
- test #3: swarm of organisms and cells (simulate the expected content of video)
- Deadline: 16/11 (2 weeks from now)
Decisions for DAY 1
General considerations
- general:
- there are 4 stages: egg, growth, organism (ie. static body shape), dying.
- only organisms transmit genomes
- only eggs that are not aggregated can receive genomes
- open question:
-
- no fitness? environment-driven evolutionary adaptation (no fitness function / reproductive advantage)
- implicit fitness? curiosity-driven, no ground truth
-
- swarm-mode:
-
- there will be no evolving swarm of single robots
-
- we’re skipping tasks evolutionary swarm mode: all robots are either an egg or in search of an organism to join.
-
- use pre-defined behaviors (random walk, red light tracking, …)
- there will be no evolving swarm of single robots
-
- organism-mode
- we start with small organisms
- development process in 2D; organism is expected to ‘stand up’ and move in 3D
- there will be no evolving swarm of organism — no direct mating among organisms. The only mating is through organism planting seed in unused eggs.
Decisions for DAY 2
- Agreement on scenario 1
- parameters, general: how many cells/eggs, % eggs, size of arena, communication range, egg's timeout-to-restart, lifetime
- parameters, in organism mode: time/trial (=tau), #trials, duration of learning wrt. lifetime
- unlimited energy
- walls
- fixed nb of free cells and eggs
- initial shapes
- Agreement on various issues:
- an egg re-becomes an egg after organism death
- body and mind evolve together
- mind may adapt during lifetime (eventually by evolution/learning)
- mind may be trasmitted in a lamarckian fashion… or not.
-
- Lexicon: organism = body + mind/brain = shape + controller
- controller
- evolutionary timescale
-
- control parameters (''narrow sense'')
- lifetime adaptation mechanisms
-
- init points (inherited vs. random)
- hyper-parameters
- internal reward
-
- options: (1) distance (2) traces (2.a) QI (2.b) evolved-QI
- start simple: distance, even though may not be correlated with survival
-
-
-
-
- Conceptual boxes:
- box #1: build candidate shape
- box #2: build candidate controller
- box #3: morphogenesis
- box #4: epigenetics learning
What can be shown in the demonstration video / Requirements
- in simulator:
-
- video is ON for all experiments, we record EVERYTHING
- record logs, for each time steps:
-
- random seed for each log
- compilation version(s) of everything (simulator, controller, etc.)
- position of each cells
- input and output values
- for every new organism: record the description of shape and controller
-
-
Looking at the demo / visual outcome and impact expected:
- observed:
-
- number of shapes
- size
- distances
- when
-
- tools
-
- clustering
- genealogy
- behavior as in physical trajectories
- behavior as in sensory-motor space
- behavior as in response test
-
- monitoring
-
- show the robot physical trajectories
- datamining the log
-
Tags: minutes | Comments: 0
Outline of Experiments - 31 Oct 2011 12:12
Introduction
Imagine an arena filled with Symbricator robots that move around, feed (charge their batteries), and evolve their controllers. This evolution is invisible from the outside, since the birth of a new controller takes place inside a robot. As time progresses, some robots aggregate into organisms, each consisting of several robot modules, and each with its own distinctive shape. These organisms move; some aptly, some only just starting to learn how to move their limbs. They also feed and evolve their shapes and controllers. This evolution is partly visible from the outside, since the birth of a new organism is a clearly observable event: we see individual robots aggregating into a new organism.
Under the hood, organisms carry a genome that encodes their shape and their controller. To reproduce, organisms need to find an ‘egg’ - an individual stationary robot module, perhaps a remnant of an old organism - which they can fertilise with their genome. An egg that has been fertilised by two different organisms performs crossover on the two genotypes and mutates the result. The new genotype is the basis for a new organism that will be born through a process of morphogenesis, initiated by the egg. The egg calls out to available modules, broadcasting the shape of the new organism and asking them to join to construct it. In response, modules in the vicinity move towards the egg to start a complicated dance, where more and more of them dock together to form the required shape. After a while the dance stops, and a new organism is born.
Meanwhile, an existing organism - maybe one of the parents of this new organism - has come to the end of its life: now it is time to disassemble. It lies down and its individual modules detach; some of them drive away in search of a forming organism that they will become part of, some drive away a small distance, spreading themselves out to become eggs to be fertilised, and some revert to their swarm behaviour.
As you can see, the idea is to use a swarm of robots to create a population of organisms and have these organisms evolve on a different level than the swarm. This constitutes two steps:
- The evolution of organisms from a swarm through some environmental pressure;
- The reproduction and evolution of organisms.
These two steps can be separated and step 1 can be - for now - replaced by a shortcut using a pre-programmed drive to create organisms. For the purposes of this task force, we propose to tackle these two steps separately, and focus first on organism reproduction and evolution, as this is the more exciting and challenging goal. In that case, there is no evolving swarm behaviour, but robots are hardwired to seek out and connect to forming organisms, or to become stationary and await fertilisation.
For the experiments, we want to implement an evolutionary process based on a “clean” reproductive advantage, without using an explicit fitness function. Such a reproductive advantage for organisms can stem from two sources in this scenario. Firstly, the ability to move: moving around, an organism can find more eggs to fertilise before its time runs out and it ‘dies’1. We propose that the fertilisation range is limited, so that moving really is a necessary skill to find eggs and so procreate. Secondly, it can stem from the ability to feed - to dock with and charge from sockets or batteries. Feeding allows an organism to walk about longer (because organisms die when their energy runs low) and so encounter more eggs to fertilise. In the first set of simulation experiments, we can decide to assume unlimited energy for the robots. This would simplify the problem and require only the evolution of moving skills.
Regarding moving skills two cases can be further distinguished: simple movement (gait) without any target and directed movement. The latter seems necessary for feeding, as organisms should detect power sources and go there to charge.
To be able to run these experiments, decisions need to be made about 1) the type of controller for the modules; 2) the type of controller for the organisms; 3) the genetic representation of organism shapes (body) and controllers (mind); 4) the environment of the experiment; and 5) the simulator.
For all these decisions we have to take into account that Symbrion adaptation has to embed on-line, on-board (OLOB) evolution. This is a technical necessity as well as the reviewers’ demand (cf. “without hands”). This means that the controllers for individual robots (in swarm mode) as well as the controllers of organisms and the shapes of organisms should be OLOB-evolvable: using only those reproduction, selection, and fitness evaluation mechanisms that are executable "in vivo" on/by the robots, without an external oracle.
Food for thought
Here are a few issues that need consideration for the success of this experiment; some may already have answers, while some are very open.
- When deciding to use a certain type of robot controller, organism controller, and organism shape representation OLOB-evolvability is an essential evaluation criterion. In the extreme: if a certain type of robot controller, organism controller, or organism shape representation is not OLOB-evolvable, then it is not suitable for these experiments.
- Is it important or even desirable to use the same controller for modules in swarm mode and organism mode?
- What will be the representation of the robot body and mind?
- Will these representations be part of the same genome, and thus undergo crossover and mutation at the same time?
- Will the morphogenesis of organisms be a self-organising process, or will it be a predefined process guided by a shape defined (maybe indirectly) by the representation?
- Will there be a task for modules in swarm mode?
- Will the organism need to have lifetime learning? What kind?
- Will the environment determine the emergence of organisms, or will this be pre-programmed?
Tags: | Comments: 0
York Meeting - 28 Oct 2011 14:02
Task Force
At the general assembly in York in October 2011 Guszti Eiben presented a plan for the evolutionary computing task force within the Symbrion project. The goal of this task force is the implementation of Grand Challenge 2 (GC2) of the Symbrion project: Origin of Species and the Emergence of Self-regulation through Open-ended Evolution
The plan is to leverage the expertise of the partners involved, to design the implementation of GC2 within the next few months. Realise this design in simulation a few months later, and realise it in real hardware a year later.
The general assembly agreed on the merrits of this plan and several partners have signed up to join this cause. The slides that Guszti Eiben presented during the general assembly can be found here.
Involved partners
Vrije Universiteit Amsterdam | VU |
Universität Graz | GRAZ |
Universität Stuttgart | USTUTT |
University of the West of England | UWE |
Eberhard Karls Universität Tübingen | UT |
Institut National de Recherche en Informatique et Automatique | INRIA |
Flanders Institute for Biotechnology | VIB |
Czech Technical University | CVUT |
Almende B.V. | Almende |
Tags: progress task-force | Comments: 0