----------------------------------------------------------------------------------------------------------------------------------------
Semester Project Report
Iterative Product Engineering: Evolutionary Robot
Design
By Dominic R. Frutiger
With the support and advice of
Josh Bongard (simulation) & Fumiya Iida
(prototyping)
Special thanks to
Prof. Markus Meier (Center for Product Engineering at
Swiss Federal Institute of Technology Zürich)
Prof. Rolf Pfeifer (Artificial Intelligence Laboratory
at University Irchel Zürich)
Kojiro Matsushita (media processing) & Nicolas Stohler
(software support)
-----------------------------------------------------------------------------------------------------------------
One of the most promising products of the future are robust autonomous agents of any kind. An important aspect is the artificial embodied agent, the robot: autonomous, situated, self-sufficient and therefore a robust tool for any purpose.
In the traditional approach to building robots, it is difficult to think about all its aspects before it is actually built, such as morphology, control structure, and placement of sensors and actuators. For this reason, human robot designers traditionally focus on the design of one sub-system at a time.
On the other hand, in nature, evolution works by adapting all aspects of an organism to its environment at the same time. The ideal principle of artificial growth is still unreachable, but the project described here tried to get a small step closer to it by using a highly iterative method for rapid and cheap prototyping of artificial embodied agents.
The work was done as a semester project in a time span of roughly seven weeks. It was carried out for the Center for Product Engineering (Swiss Federal Institute of Technology) at the Artificial Intelligence Laboratory at University Irchel Zürich. The overall goal was to evaluate how well such an iterative method works for rapid prototyping of complex systems and where its weaknesses and possibilities for improvement lie.
In the first, evolutionary computation was used to rapidly design and test robot morphologies in simulation, focusing on legged locomotion into one direction that did not have necessarily to do with patterns or morphologies found in nature. The software tool used was MorphEngine by J. Bongard. The algorithm developed a control structure for the agent (weight matrix of an artificial neural network) - perfectly adapted to its specific morphology.
In the second, a key-morphology that was simple, but interesting enough to be implemented in a prototype within one or two weeks had to be chosen.
In the third, several iteration steps between hardware considerations, the transfer of these boundary conditions into the software parameters and a cross-influenced adaptation of the morphology at both ends had to be made.
The result was a real prototype robot based on the evolved design and with a locomotion pattern similar to the one in simulation.
Since the transfer of an artificial neural network into a real robot is still a technological challenge and was beyond the scope of this work, the control structure had to be programmed in common programming languages like Assembler and C.
The project was quite a success, although there are still further iteration steps for the development of this specific agent possible to get an even better result – not to speak of other improvements concerning the method and the design tool in general. Related suggestions can be found at the end of this report.
With the knowledge of this project, the future production cycle for an agent of a similar complexity can be estimated to be less than four weeks, if well planned.
(The Design Tool Used For Simulation)
The used and tested software for the evolutionary design was MorphEngine (designed by Josh Bongard), and its graphical interface, MECreator (designed by Nicolas Stohler).
In the introduction of the MorphEngine documentation it says:
MorphEngine is an educational software package that allows the user to explore the workings of evolution on a PC, and see the results in a matter of minutes. The user first specifies the body of a creature, and what that creature should do. MorphEngine then designs a brain for your creature, known as a neural network, and then uses an algorithm based on evolution, known as a genetic algorithm, or GA, to refine the creature's brain so that it performs the desired task. The user can then view the behaviour of the evolved agent, as it moves about in a physically realistic, three-dimensional virtual environment.
MorphEngine was easy to install (especially with the GUI), but at the current stage of development picky with the combination of operating system and the graphics card: some serious troubles were encountered when trying to find a machine where the ME was fully supported by the processor and MEC by the hardware acceleration of the graphics card – unfortunate, but easy to be corrected and probably just bad luck.
The key module of MorphEngine is MathEngine Karma, a third party simulation environment. It is closed source, which could cause difficulties in judging the reliability of the simulation and which makes direct changes on the source impossible. MathEngine Karma shows the best performance on an Intel processor.
The design with MorphEngine was quick and easy, its capabilities sufficient for this project, yet the possibilities of evolution were still quite limited and could have been a bit wider: important features such as adaptive length of objects, mass distribution, spring parameters and noise were not implemented. Not to speak of the limitation of objects to sphere, cube and cylinder. The fitness function was limited to locomotion in one direction or following a light source.
The evolved ‘brain’ is a fully connected feed forward neural network, with a single layer of recurrently connected hidden nodes. For detailed information please refer to Bongard, J. C. & R. Pfeifer (2002b).
The plan was to begin with a large number of creatures of any kind (creative pool of different morphologies) as a first step while getting familiar with the software and its numerous evolution parameters.
It took between 15 minutes to 2 hours to create a creature of the first series, the evolution runs between hours and days - depending on the complexity of the creature and its neural controller.
Many of the creatures of the first series were engineered with a certain locomotion pattern in mind and featuring a relatively complex morphology. Their performance was often quite poor - mostly because it was hard to get a feeling for the appropriate evolution parameters, such as population size, number of generations, number of nodes in the hidden layer of the neural network , the seed number for the random number generator etc.
Not to speak of the infinite possibilities for variation in the morphology: the implementation of adaptive mass distribution and object length to the evolutionary process would certainly have helped a great deal, but was beyond the scope of this semester project.
A detailed record for each phenotype and its subtypes throughout its whole live cycle allowed keeping track of progress and drawbacks due to the specific parameter changes (including important evolution parameters and performance results).
The impact of these parameters was highly dependent of the specific morphology of a creature and could hardly ever be transferred from one agent to the other unless there was a high similarity of the phenotype. Therefore systematic approaches soon turned out to be of little use for the design procedure in general – experience and intuition became an important aspect of the design process.
For further details about evolutionary parameters in MorphEngine and general recommendations for their use please refer to the documentation:
Original MorphEngine documentation in English by Josh Bongard
German documentation for MECreator by Nicolas Stohler
The fittest variants did undergo several iterations of further development (changes of evolution parameters or morphology) until either a sufficient performance (locomotion in one direction) was reached or the creature was given up.
|
|
This is one of the first creatures. The underlying idea was, that it might show a rolling behaviour of some sort, thanks to its three actuated joints with about 180° of freedom. It turned out to be unfit – whether due to its morphology or to the evolution parameters was unclear, and the creature was soon given up. |
|
|
This design was based on the creature above. A major change was the movable mass added in the middle (pink). It made a slight dislocation of the center of mass possible. Three different configurations of the number of joints led to varying locomotion patterns: |
|
|
The dynamic biped locomotion pattern of the creature on the left was possible thanks to the two hinge joints (orange) and springs in the ‘feet’. This design could certainly have been improved – but a similar creature already existed in the lab. |
|
|
The idea behind the design on the left was some sort of controlled jumping behaviour. The nine joints (green) allow the ‘legs’ to fold inward while Motors and springs then theoretically allowed the creature to jump up from its stabilizing ‘foot’. The design turned out to be completely unfit at this state. |
|
|
The design of this creature included certain hardware considerations (space proportions for controller and motors etc.) Again, the design turned out to be relatively unfit due to its morphology – and after a couple of variations it was given up to move on with more promising creatures. |
(The Key-Phenotype Selection Phase)
Having a better understanding for the influence of the evolution parameters, the following series became much more promising.
While continuing with the invention of new creatures on one hand and the filtering for the more interesting and promising morphologies on the other, there were two sub goals for the next step in the design process: the first sub goal was to find the key-morphology for the future prototype, the second to test the capabilities of the design tool to support the engineer with surprising solutions.
The first sub goal was the selection of the key-phenotype for the future prototype out of the pool of the fittest. Three interesting morphologies were the subject of discussion: Titan, Athlete and Ape.
|
|
Titan05 & 06 The creature has 6 joints with motors and angle sensors and 3 touch sensors in the feet. Both directions were tested: with the red ball pointing forward (Titan05) and backward (Titan06). The evolved locomotion pattern were surprisingly successful: |
|
|
|
|
Click the pictures on the right to see the joint normals (green) and angles (red/blue dotted circles) in more detail. |
|
|
Athlete03 The creature has 2 shoulder joints with motors and angle sensors and 1 passive joint with a stiff spring (red ball) and no angle sensor. Apart from that there are 3 touch sensors in the feet (balls touching the ground). The evolved movement was basically a well balanced biped locomotion pattern: |
|
|
|
|
Click the picture on the right to see the joint normals (green) and angles (red/blue dotted circles) in more detail. |
|
|
Ape Series The Ape series included several variants with different combination of wrists, claws and above all the two different swinging strategies: Going backwards, releasing the rope (need for a wrist) and swinging about 270° around the shoulder axis (like a Gibbon) Going forward with the arms, always keeping the claw above the rope. More details about the variants and their joint properties can be found in the next chapter. |
The criterion was to find the best trade-off between simplicity and a dynamic locomotion pattern: simple to understand and to implement quickly with few resources, but dynamic in its locomotion at the same time - dynamic in the sense of not being stable in each timeframe, but showing a jumping or swinging behaviour.
Titan was moving successfully, but its thin spider-like legs and relatively complicated joint properties were considered to be too difficult for a real world implementation in less than two weeks.
Athlete on the other hand was simple and highly dynamic, but the concern was that the not-yet implemented noise in the simulation environment had supported such a perfectly balanced locomotion pattern and that it would be a difficult task to deal with the friction of a real world surface. Apart from that, a robot featuring a ‘similar’ principle already existed in the laboratory: Fumiya Iida’s robot called Stumpy .
The brachiating robot called Ape showed a satisfying dynamic behaviour and seemed to be a good choice for this project regarding its relatively simple morphology and control structure. Apart from that, the example from Toshio Fukuda and Jun Nakanishi (Nagoya University, Japan) was inspiring and no such thing was ever built in this Artificial Intelligence Laboratory (at the Institute Of Informatics at the University Irchel in Zürich, Switzerland).
The second sub goal was tested on the creature christened Titan07V:
It is hard for an engineer to think of a locomotion pattern for a leg configuration that is not present in nature. Another question during this first phase was therefore to prove the usefulness of evolutionary computation in such a situation and to see if it will come up with a solution. This aspect was tested with the three-legged creature Titan in the hope for a successful tripedal locomotion pattern.
|
|
TitanV07 The creature has 6 joints with motors and angle sensors and 3 touch sensors in the feet. The evolved locomotion pattern were surprisingly successful: |
|
|
|
|
Click the pictures on the right to see the joint normals (green) and angles (red/blue dotted circles) in more detail. |
The result was satisfying: as seen above, the creature moved successfully on its three legs over the virtual plain. The gate developed was not surprising from the evolutionary point of view: the jumping behaviour was obviously the most efficient one to go in a straight line without turning. Although successful, this locomotion pattern was not exotic enough for the second sub goal of finding surprising solutions. A new approach was to force the creature to move in changing directions by following a light source that was placed randomly for each generation.
The evolved locomotion pattern to follow a light source was more interesting from the engineering perspective, since it was not just a jumping behaviour, but a slower successful strategy of placing one leg after another.
(The Key-Variant Selection Phase)
After choosing the key-phenotype of an ape-like robot, the numerous variants had to be evaluated. Here a selection of the visually more obvious variants including all joint normals (green) and their angles (red and blue dotted sectors):
|
|
|
On the left two variants that were built with strategy 1 in mind: wrists allow to let go the rope and to grab it again after swinging the arms past the body. Click for joint details. |
|
|
|
On the left two variants that were built with strategy 2 in mind: just moving the arms forward on the rope (up to 90°). |
Different claws had to be introduced soon in all variants, because the creatures did not stay parallel to the rope and often simply fell down:
|
|
|
|
|
|
|
Interesting would have been the more
Gibbon-like swinging strategy 1: releasing the rope, swinging the arm backwards
- passing under the shoulder by describing a circle forward of roughly 270° -
and finally place the hand on the rope in front again - just like its older
brothers, the Brachiating Robots
of Toshio Fukuda and Jun
Nakanishi.
The problem with a behaviour like this was the extremely small probability that the evolutionary algorithm would come up with such a precisely timed action required for the wrists (release and placement of the hands) only through random weighting of neural connections. Therefore it was no surprise when those variants with actuated wrists seemed to be unable to put their hands on the rope again after releasing it once. Such behaviour might have been possible by introducing new biases in the algorithm - but again this was clearly beyond the scope of this project.
As a result, the simplest possible variant was selected for further development (mainly based on hardware considerations):
|
|
Locomotion strategy 2: Going forward with the arms (90° max), always keeping the claw over the rope. The shape of the claws was an open question for further investigation. Also the number and placement of possible passive joints etc. in the lower body (used for swinging behaviour). |
Up to this point in the project, the focus was on inspiration and promising key-phenotypes and their sub-variants. But now, with a real prototype in mind, the reliability of the simulated environment became important: the dynamics of a creature in a physical environment and therefore its locomotion pattern changes with the physical properties of the phenotype, such as scale and mass. Therefore it was important to simulate the agent at the exact same scale as the one the planned prototype was supposed to have.
In the MathEngine documentation (the simulation module in MorphEngine) it says:
There is no built-in system of units in Karma, which is not to say that quantities are dimensionless.
You may choose any system of units you feel comfortable with, either meter-kilogram-seconds, centimeter-grams-seconds or foot-pound-seconds.
However, you are responsible for the consistency of values you program into simulation and you will have to perform some dimensional analysis.
The parameters entered in MECreator (e.g. length and mass of a cylinder) did not explicitly indicate at what scale the simulation was working: a metric system of kilograms-meters-seconds was likely, but had to be verified now before proceeding with the design process.
In the source code of MorphEngine, the gravity was found to be set to the value 9.8, which could be interpreted as 9.8 m/s2. This meant that a value of 1.000 in the parameter mask of MECreator meant 1.0 kg or 1.0 m respectively, depending on the context.
As a result it was now necessary to scale the selected morphologies - with the actual height of about 3 meters and a couple of kilograms weight (!) - down to a more realistic size for prototyping of about 50 centimetres and 1 kilogram. The criteria here were motor forces, power supply, material strength and of course the space and resources in the laboratory - just to name the most important ones.
(The Environment-Testing Phase)
Unsure about the influence of the spring parameters that have to be defined with every joint, some systematic tests had to be done to ensure a plausible behaviour of the springs in the scaled simulation. There was no explicit plan to use springs in the prototype, and tests were necessary at this point to find out what parameters were needed at the new prototyping scale (<1m / <1kg) to simulate a smooth stopping behaviour.
This was important since the springs defined the behaviour at boundaries in every aspect: if the stiffness was chosen too high, the hinge was bouncing off the hinge limit as expected (normal spring behaviour), but if chosen too small, it the hinge would just pass its limit (undesired behaviour). Thus the spring parameters were also defining the situation where no spring was present at all.
Tests with a freely falling pendulum in the gravitational field showed that the springs cause a reasonable stopping behaviour at the hinge joint boundaries with a damping factor of 1.0 and a spring stiffness of 1000 at normal scale (as described in the MorphEngine documentation).
At the smaller prototyping scale (<1m / <1kg) a damping factor of 1.0 and a spring stiffness of 1.0 showed a satisfying stopping behaviour.
|
|
The test configuration was basically the situation visible on the left: The thinner horizontal cylinder acts like a pendulum and can turn around the axis of the thicker cylinder. The latter stays at a fixed position in space. Variations of this configuration were used for testing the precise influence of spring and motor parameters on the stopping behaviour etc. |
After running simulations on the prototype
scale (<1m / <1kg) and no longer the normal software environment scale
(>3m / >5kg), difficulties with the motor forces occurred. The simulations
on prototype scale showed unrealistic behaviour: either the creature was not
moving at all when realistic motor forces were chosen, or if bigger forces
where used to make the agent move the joints suddenly started to 'explode' in one second to come together
again in the next second and small objects were able to sink through each
other.
|
|
The screenshot on the left shows an anomaly of the simulation environment where object contact is no longer detected: The claw in front clearly ‘sinks’ through the rope. |
|
|
The screenshot on the left shows an anomaly of the simulation environment similar to an ‘explosion’: The fingers of the claw in the lower right has been torn apart (the light and dark orange cylinders). The same happened to the wrist in the upper left: the claw remains on the rope while the arm points into the air. |
Systematic tests were performed to learn more about the accuracy of the simulated motor force.
The used configuration was a variation of the one used to test the impact of the spring parameters: a motor with a specific force had to hold or lift a horizontal bar with a defined weight.
On normal scale (>3m / >5kg) the tests showed only an error of 10% above the calculated force, which was considered to be of acceptable accuracy.
But on prototype scale (<1m / <1kg), the exact same tests showed that the motor forces used in simulation did not correspond at all with the forces that would have been needed under realistic circumstances to hold or lift the same weight. The force had to be 14 times (1130%) bigger than calculated to hold or move the pendulum!
Thus the results of the current simulations were not realistic anymore and the conclusion was that the difference between simulation and reality was most likely a result of the shift from normal scale (>3m / >5kg) to prototype scale (<1m / <1kg). A design tool with insufficient simulation accuracy at the needed prototype scale would have been of little use - therefore something had to be done to improve the accuracy of MorphEngine.
(The Environment-Correction Phase)
In numerical mathematics there is always a trade-off between speed and accuracy. For the underlying numerical calculations of the simulation in MathEngine, the compromise was probably chosen for best performance at 'normal' scale (roughly >3m / >5kg) and not for the prototype scale used for this project (<1m / <1kg).
In the MathEngine documentation it says:
When two object collide, there will be some initial inter-
penetration. The amount of penetration depends on how fast the two objects were going before they collided.
After collision, Kea’s projection feature will push the objects apart to reduce the penetration to zero. However, sometimes Kea will push the objects too far, and the contact will be broken. This can be a problem, for example, when objects are resting on the ground.
When the contact is broken, the object will 'fall' a short distance into the ground, the contact will be re-made and the object will be pushed out again. This process can result in resting objects that jitter or twitch from time to time. (...)
Since Karma simulates physics numerically, with a discrete time-step, some collisions may not be detected. (...)
For the system, if there was no intersection between two models at a given time step then no collision occurred.
A likely solution to improve simulation accuracy was the increase of the number of calculation steps (frames) in one time cycle. To test this hypothesis, the size of the time-steps (the time delay between each frame) defined in the source code of MorphEngine was reduced increment by increment. The software had to be recompiled each time after a change. Then it was tested on always the same creature that had shown anomalies like exploding joints and object penetration in the original software version.
After reducing the time-step size by a factor of 4, no more visible anomalies (such as explosions and penetration) could be observed. The creatures were now moving smoothly even with reduced motor force. The force necessary for movement was reduced by a factor of 4 roughly – but still 14 times bigger than calculated. Thus the reduction of time-step size had no visible influence on the simulation accuracy for motor forces at this scale (<1m / <1kg).
(The Hardware Consideration Phase)
Since there was no realistic relation between defined motor forces and their resulting performance in simulation, reasonable parameters had to be found before proceeding with the development process.
The criterion was to use the lowest force and speed possible to keep the creature moving. This because the smaller a motor, the less weight it would have and the smaller its power consumption (and thus also the weight of the batteries) would be. Little weight of all components also meant that less force would be needed to animate the agent - and so forth.
Another difficult aspect was the estimation of the resulting dynamics of a moving creature and thus the forces involved (both motor forces and inertia), since the locomotion pattern is highly dependent on the morphology of the developed creature and since a heavy body can still be moved over a swinging strategy even if the motors are incapable of lifting and holding a limb steadily in every possible position.
Therefore the only obvious criterion to define motor force and speed in simulation without complex calculations or changes in the source code was to keep weights and thus all involved forces as small as possible. A morphology designed with this principle in mind guaranteed a security factor for the impact of real world hardware constraints and left the 'calculation' and possible solutions for movement patterns to evolution.
There were two different types of possibly suitable motors available in the laboratory at this point:
Medium Motor 2342 S012 CR / Gearhead 23/1 / Encoder 10BP16
Weight Total: 0.173 kg
Weight Motor: 0.088 kg
Size Total: L= 0.095 m
D= 0.023 m
REDUCTION RATIO: 14:1
Starting Voltage: 450 mV
Stall Torque: 80 mNm
Speed Constant: 713 rpm
Torque
Constant: 13.4 mNm/A
Current Constant: 0.075 A/mNm
Angular Acceleration: 140000 rad/sec2
recommended values for continuous operation:
speed: 7000 rpm
torque: 16 mNm
current: 1.4 A
Modeling: 2 Cylinders
Cylinder1 (Motor&Gearhead) 90% of mass
Weight: 0.156 kg
Length: 0.070 m
Diameter: 0.023 m
Cylinder2 (Encoder)
Weight: 0.017 kg
Length: 0.024 m
Diameter: 0.025 m
Small Motor 1727 U012 C / Gearhead 16/7 / Encoder 21B22
Weight Total: 0.0647 kg
Weight Motor: 0.028 kg
Size Total: L= 0.065 m
D= 0.017 m
REDUCTION RATIO: 43:1
Starting Voltage: 800 mV
Stall Torque: 11 mNm
Speed Constant: 700 rpm
Torque
Constant: 13.6 mNm/A
Current Constant: 0.073 A/mNm
Angular Acceleration: 91000 rad/sec2
recommended values for continuous operation:
speed: 7000 rpm
torque: 5 mNm
current: 0.42 A
Modeling: 1 Cylinder
Cylinder1:
Weight: 0.156 kg
Length: 0.065 m
Diameter: 0.017 m
The specifications for continuous operation for the bigger and heavier (0.173 kg) motor were (Torque T, Speed v):
T = 0.016 Nm * 14 (gear factor) = 0.224 Nm
v = 7000 rpm / 14 (gear factor) = 500 rpm
For the smaller and lighter (0.065 kg) one:
T = 0.005 Nm * 43 (gear factor) = 0.215 Nm
v = 7000 rpm / 43 (gear factor) = 162.8 rpm
It was clear, that the movement pattern (and the resulting dynamics) the evolutionary algorithm would come up with was unpredictable in detail, but certainly not continuous in the whole.
The listed stall torques (Ts - e.g. for holding a limb of a specific weight steady against the force of gravity) for the big motor where:
Ts = 0.080 Nm * 14 (gear factor) = 1.120 Nm
For the smaller and lighter one:
Ts = 0.011 Nm * 43 (gear factor) = 0.473 Nm
Because of all the cross-influence of forces, power consumption and battery weight, it was unclear what calculation model (lengths and weights) should be used to estimate the motor torque needed in the prototype.
Calculation showed, that the small motor would theoretically be sufficient to lift a limb with a battery pack (estimated weight of 0.3 kg and placed 0.15 m away from the motor axis) up to an angle of roughly 30° against gravity with the specification for continuous operation.
An angle of 30° was likely to be sufficient for movement - especially if gaining momentum through a swinging strategy. The stall torque would certainly be enough, including a considerable security factor.
Thus the decision was to plan and build the prototype based on the smaller and lighter motor with less power consumption.
The motor specification of the smaller model was known and ready to be transferred into simulation. But as mentioned above, the simulation an error by a factor 14 at the prototype scale (<1m / <1kg). In the worst case, the impact would have been a locomotion pattern evolved in simulation that was based on a motor strength several times bigger than the motor proven sufficient in calculation and planned to be used in the prototype.
This became an important aspect of the design method evaluation: would it be possible to transfer the locomotion pattern observed in simulation to a similar performance of the real prototype or would it fail due to an entirely different definition of the underlying motor force?
To keep this error as small as possible, tests were necessary to determine the motor parameters (torque and speed) that would be just sufficient to move the model swiftly up to an angle between 30° and 50°. The tests showed, that a promising behaviour could be achieved with a force of 7.5 Nm and a speed of 10 rad/s (above the calculated force by a factor of 14).
The chosen motor type combined with the controller board specifications (estimated 0.046 kg, one for each motor, > 5 Volt) defined the battery type to be used: two battery packs delivering 0.7 Amp at 6 Volt and a weight of 0.13 kg each.
The use of battery packs was planned for two reasons: in any case there was the need for a weight at the tip of the pendulum (end of the body limb) to allow a swinging strategy, but there was also the less logical wish to build an theoretically independent agent.
As mentioned before it was clear, that the lightest available materials should be used in the prototype to guarantee little mass and thus the sufficiency of the small motor type. A quick look in the workshop showed what kind of aluminium profiles etc. were available.
Having all component specifications (motors, controller boards, battery packs, bearings and the properties of aluminium likely to be used for arms and body) these parameters could be transferred to the creature in simulation as a second step in the simulation-to-reality iteration process.
No decision was made yet concerning the question of how many motors should be used in the prototype. The performance of the tested three phenotype-families (named M1, M2 & M3 according to the number of motors they include) and their variants (how many passive joints and where to place them) would show, which morphology would be the most suitable.
|
|
M1np-Variant (1 Motor) This variant of M1 has one motor in the left shoulder (with an angle sensor). The right shoulder forms a fix angle with the lower body. There are no other hinge joints. |
|
|
|
|
M1p-Variant (1 Motor) This variant of M1 has one motor in the left shoulder (with an angle sensor). The right shoulder forms a fix angle with the lower body. Apart from that, there is an additional passive joint right under the shoulder axis, including an angle sensor. |
|
|
|
|
M2np-Variant (2 Motors) This variant of M2 has one motor in each shoulder (with angle sensors). There are no passive joints. |
|
|
|
|
M2pd-Variant (2 Motors) This variant of M2 has one motor in each shoulder (with angle sensors). Apart from that, there is an additional passive joint in the middle of the lower body, including an angle sensor. |
|
|
|
|
M2pu-Variant (2 Motors) This variant of M2 has one motor in each shoulder (with angle sensors). Apart from that, there is an additional passive joint right under the shoulder axis, including an angle sensor. |
|
|
|
|
M3md-Variant (3 Motors) This variant of M3 has one motor in each shoulder (with angle sensors). Apart from that, there is an additional motor is in the middle of the lower body, including an angle sensor. |
|
|
|
|
M3mdp-Variant (3 Motors) This variant of M3 has one motor in each shoulder (with angle sensors). Apart from that, there is a additional motor is in the middle of the lower body and a passive joint right under the shoulder axis, both including an angle sensors. |
|
|
|
|
M3mu-Variant (3 Motors) This variant of M3 has one motor in each shoulder (with angle sensors). Apart from that, there is an additional motor right below the shoulder axis, including an angle sensor. |
|
|
|
|
M3mup-Variant (3 Motors) This variant of M3 has one motor in each shoulder (with angle sensors). Apart from that, there is an additional motor right below the shoulder axis and a passive joint in the lower body, both including an angle sensor. |
|
|
(The Prototype Selection Phase)
Out of those three families and their subtypes one specific variant was chosen to be implemented in the real world. The selection criteria were a trade-off between simplicity of the hardware design and a dynamic locomotion pattern.
It was no easy task to make a quick decision only based on visual input and a woolly quality criterion.
The choice was M2pd_g04 (random seed 5). This creature is relatively simple with two actuated shoulders and one passive joint in the middle of the body part, but shows a much more dynamic and regular locomotion pattern in simulation.
|
|
M2pd-Variant (2 Motors) This variant of M2 has one motor in each shoulder (with angle sensors). Apart from that, there is an additional passive joint in the middle of the lower body, including an angle sensor. |
|
|
Specifications of this (simulated) creature:
fingers (4x):
w = 0.003 kg
l = 0.030 m
r = 0.005 m
sensors (2x):
w = 0.006 kg
l = 0.015 m
r = 0.007 m
wrist (2x):
w = 0.006 kg
arms (2x):
w = 0.017 kg
l = 0.200 m
s = 0.010 x 0.008 m
controller board (2x):
w = 0.070 kg
s = 0.10 x 0.075 x 0.03 m
motor modelling (2x):
[medium weight]
cylinder 1 (Motor&Gearhead&Encoder)
w = 0.156 kg
l = 0.065 m
r = 0.009 m
motor bearings (2x):
w = 0.007 kg
------------------------------------------------------
1 shoulder total = 0.268 kg
------------------------------------------------------
body middle:
w bear = 0.010 kg
w axisl = 0.030 kg
w axisr = 0.030 kg
w add = 0.080 kg
legs (2x):
w =
0.017 kg
l = 0.150 m
s = 0.010 x 0.008 m
body joint mass:
w = 0.040 kg
Upper Tyco battery pack (reduced to ‘no battery pack’)
w = 0.001 kg
------------------------------------------------------
body tot = 0.225 kg
------------------------------------------------------
Lower Tyco battery pack:
w = 0.130 kg
s = 0.074 x 0.055 x 0.018 m
p = 6.0 V x 700 mAh
------------------------------------------------------
------------------------------------------------------
Total Mass Body Without Batteries:
0.761 kg
With lower Tyco battery pack:
0.891 kg
------------------------------------------------------
------------------------------------------------------
After deciding what creature would be implemented in the real world, engineering aspects had to be solved in detail: how to build stable shoulder joints, what kind of touch and angle sensors should be used and how should they be placed to design a light and robust prototype.
The more detailed design of the prototype took about half a day, the realization about three days. Many smaller problems were solved in process. All components had to be wired during the following days and minor adjustments had to be done on the shoulder sensors. The design proved to be robust, light and simple to disassemble for a possible repair.
Flat shoulders of a relatively high diameter with extremely flat bearings guaranteed stable arm positions (only one degree of freedom around the motor axis).
|
|
|
|
|
|
The only major change in the design compared to simulation concerned the placement of the battery packs: both were moved down to the end of the body - to be fully used for swinging purposes and simplifying the design.
The prototype is roughly 0.54 m high and has a total weight of 0.75 kg.
|
|
|
|
|
The controller boards used for the prototype were a creation of the lab. Each could control one motor, while reading eight inputs (sensors). The boards had an output for debugging (over 'printf' in C) and were theoretically able to communicate as master and slave (this feature was not used in the prototype).
The red circle in the picture of the backside of the controller board marks a scratched spot.
The boards used for the prototype were flawed (probably because of an incorrect blueprint): a surplus connection had to be broken to allow the motor to turn in both directions and not only one. It is mentioned here, because this problem might come up again.
The touch sensors in the claws were simple switches at the highest point, activated through the weight of the prototype itself. The shape of an open angle guaranteed the centered positioning and reliable activation (picture on the left).
|
|
|
The angle sensors were realized with simple potentiometers inside the actuated shoulders (picture above on the right) and in the passive body joint (pictures below). The picture of the open shoulder shows the flat red potentiometer at the axis and the cylinder bearing enclosing it.
|
|
|
|
-----------------------------------------------------------
Specifications of (real) prototype:
-----------------------------------------------------------
(Distances)
Distance Touch-Sensor – Body-Axis:
0.22 m
Distance Shoulder-Bearing - Shoulder-Bearing:
0.03 m
Distance Motor - Center:
0.02 m
Distance Body-Axis – Body-Joint:
0.15 m
Distance Controller-Center – Shoulder-Axis:
0.05 m
Distance Body-Joint - Tyco-Center:
0.12 m
(Weights)
Claw (incl. screws):
0.015 kg
Arm:
0.025 kg
Controller Board:
0.054 kg
Motor:
0.068 kg
Shoulder Plate and Ring:
0.017 kg
------------------------------------------------------
0.178 kg 2x
------------------------------------------------------
Ringbearing (center part):
0.009 kg 2x
Body (inner shoulder & ring, leg up&down, body-joint):
0.108 kg
------------------------------------------------------
0.126 kg
------------------------------------------------------
Tyco-Pack:
0.130 kg
------------------------------------------------------
------------------------------------------------------
Total Mass Body Without Batteries:
0.482 kg
with 2 batteries (Tyco):
0.742 kg
------------------------------------------------------
------------------------------------------------------
The prototype was finally fully constrained regarding weights, lengths and the resulting mass distribution.
The next step of the iteration process was a back-translation of these parameters into simulation to allow the evolutionary algorithm to exploit every new detail introduced, to ensure a realistic locomotion pattern and therefore to make a evaluation of the simulation-to-reality process possible.
|
|
The screenshot on the left shows the creature after adapting it to the new hardware constraints. The changes of mass and length are not visible, but it can be seen how both motor packs have been moved down to the tip of the lower limb as in the design of the prototype. The goal was to rerun evolution in the hope for a better exploit of the new physical givens. |
The results were not overwhelming: the steps of the creature relatively small, the maximum angle of the body from the vertical axis about 30° to 40° although the prototype was capable of reaching up to 60°-70° with a DC power supply of 8.3 Volt and 0.7 Amp at maximum when using both motors.
Better performance might have been possible to achieve through further optimization of evolution parameters - but at this point the project schedule dictated to proceed with the analysis and transfer of the observed locomotion pattern to the controller.
The programming period took several days - mainly because of frustrating errors that had nothing to do with the project itself: unpredictable compiler flaws (free version of Microchip MPLAB, the programming tool for the heart of the hardware controller: the PIC16F877), hardware corrections on the controller boards (a surplus contact that had to be broken, because it was preventing reverse motor movement), replacement of a fried transistor on one board and programming cable resistance that made an reliable upload temporarily impossible after changing its length.
To keep things simple, there was no direct communication planned between the two controller boards. A specially implemented starter-switch guaranteed a synchronized program start. Both boards read all sensors independently - implemented were two touch sensors in the claws (switches), two angle sensors (potentiometers) in the actuated shoulders, one angle sensor in the passive body joint and finally one starter switch. All other actions were controlled over simple 'while' and 'if-else' statements in C that made the boards wait for certain sensory inputs, such as switch contact or potentiometer thresholds.
The program is the same on both boards - a simple Boolean changed before compiling defines the board identification and makes distinction on board during program execution possible.
|
|
|
On the left the prototype and the needed infrastructure can be seen. The tool for programming the PIC16F877
on the controller board is
the Microchip
PICSTART Plus, the grey
box hanging on the right. The DC power supply is also visible behind the Notebook. |
With a couple of test routines, the behaviour of the sensors and the time delay needed to read them properly was evaluated. Below is a sample output from both boards that shows the pin map and the values they read independently (pA = potentiometer in shoulder A, tB = touch sensor in claw B, pin_pL = pin used for the potentiometer in the lower body joint, etc.):
BOARD A
pin_pA: p0
pin_pB: p3
pin_pL: p1
pin_tA: p4
pin_tB: p5
pin_tS: p7
pA_fwd:766, pB_fwd:763, pL_fwd:660
pA_mid:873, pB_mid:686, pL_mid:614
pA_bwd:567, pB_bwd:499, pL_bwd:599
tA_activ:717, tB_activ:1023
BOARD B
pin_pA: p3
pin_pB: p0
pin_pL: p1
pin_tA: p5
pin_tB: p4
pin_tS: p7
pA_fwd:728, pB_fwd:717, pL_fwd:641
pA_mid:807, pB_mid:654, pL_mid:589
pA_bwd:550, pB_bwd:475, pL_bwd:561
tA_activ:673, tB_activ:1012
The task was now to watch and interpret the behaviour controlled by a neural network in simulation into a similar behaviour on the prototype using the programming languages Assembler and C.
The analysis of the simulation showed clearly, that the creature achieved its movement by changing the center of gravity to the opposite side of the arm it was about to move. With this method, the friction in the moving claw was first reduced and finally totally lost so that the arm could be moved forward freely, while swinging with the weight of its lower body and gaining some momentum for the next ‘step'.
|
|
to see the agent moving. |
A similar locomotion pattern could be copied really fast, but only shortly before the deadline (due to the time delay caused by the ‘problems of infrastructure’ described before).
The controller basically executes the steps described in the following pseudo code.
The purpose of the initialization procedure in the very beginning (step 0) is to read and store sensory inputs for each position to use them as thresholds during program execution.
0. Wait for starter switch to be activated, then initialize variables that hold sensor thresholds by moving the body with the shoulder motors maximally forward and backward while reading sensors. Wait for starter switch again.
1. Start motors in order to move body forward: shoulder B (the one actuating the arm currently in front) with full power (it will only move the body) and shoulder A (the one currently in the rear) with reduced power (wait a moment until the center of weight has changed, then support B in moving the body forward)
2. Read angle sensor of shoulder A (the one currently in the rear) until middle position (defined during initialization procedure) is reached (necessary because the potentiometer is unfortunately not linear in this shoulder)
3. Now wait until maximum forward angle is reached (arm is not moving, only the body).
4. Push arm A backward for an instant with maximum force and then change the direction to forward (necessary because of the high friction between aluminium claw and rubber coated rope) while shoulder B still keeps the body and therefore the center of mass in front
5. Wait for touch sensor in claw A to lose contact while maintaining torque in both shoulders.
6. Wait for shoulder A to pass the middle position (because the angle was increased again when pushing A backward – the arm moving this time).
7. Wait while arms are closing in front (claw A remains in the air because the center of mass is under or in front of claw B now)
8. Let go by reducing the forces in both arms and change the weight to claw A (the one in the rear, but really close to claw B) without changing the direction
9. Wait for claw A to get in touch with the rope again (friction prevents A now from moving back where it just came from).
10. Continue with changing the weights now by switching the directions so that both shoulders push the body backwards now - A with maximum power, B with reduced power to prevent arm B from going forward to early.
11. Wait for claw B to lose touch.
12. Push B backwards with maximum force for an instant to gain momentum, then change direction to forward: arm B moves freely forward, while A keeps the mass in the rear.
13. Wait for claw B to touch the rope again.
14. Initial position is reached. Go to step 1 and repeat cycle.
|
|
Movies of the first steps of the prototype: (0.5MB – low quality) (0.7MB – low quality) Sensor initialization procedure (1.4MB - high quality) (0.9MB - high quality) |
Two slightly different versions of the controller code were used for the movies listed above. The difference was scarcely visible, but the performance was slightly improved.
The performance was reproducible, but it always took several tries to get there – most likely because of the unpredictable dynamic response of the rope under the weight of the prototype.
Another problem that complicated the programming process and might have been responsible for temporary unreliability is that fact that the values from potentiometer pA are not monotonously increasing. This could unfortunately not be repaired due to a stuck screw that holds the shoulder in position. It broke during the reassembling of the prototype after the first corrections.
The possible solution for future work on the prototype would be to change the arm positions: move arm A to the front, arm B to the rear, since only the angle of the arm in the rear changes significantly its angle – the arm in front has to keep a ‘constant knee’ forward.
|
|
On the left a detailed picture of the broken screw in the joint axis of shoulder A. If intact, it allows disassembling the prototype within one minute by simply removing the screw. This design makes an easy adjustment or replacement of the bearing or the potentiometer hidden inside the shoulder possible. |
[Further Adaptation & Verification]
An open question was the obvious difference of motor power between simulation and prototype. The angle of the ‘knee’ formed during the sensor initialization procedure is much bigger than possible in simulation (in a corresponding test configuration).
The difference in motor performance was anticipated. The tests during the development process had already shown a factor of 14 necessary for a realistic behaviour.
This observation was verified a second time by measuring the stall torque of the actual used motors (using the exact same power feed as on the prototype: 8.3V/0.45A)), entering the proper values (0.243Nm to lift 0.330kg in 0.15m up to 30°) into the simulation and re-evaluating the performance:
|
|
An experienced in the first test series, the entered realistic value was insufficient in simulation. The threshold was 1.000Nm – no reaction below this value. An angle of roughly 30° could be reached with a setting of 3.5Nm – still 14.4 times too much. On the left is the configuration visible that was used for the measurements. Calculation: 0.243Nm = 0.330kg x 0.15m x sin(30°)*9.8m/s2 |
|
|
In the code the input of only three sensors out of the possible five (in the virtual creature) were implemented.
This raised the question, if the performance in simulation would have been the same without the angle sensor pB in shoulder B (the one in front on the picture above) and without the angle sensor in the passive body joint pL. The easiest way to test this was to run a new evolution process with reduced sensors (it is not a trivial task to read and understand the weighting matrix of the neural network).
The reduction from 5 to 3 sensors in simulation led to a very poor performance in the first evolutionary run: the creature hardly managed to close its arms.
But the disappointing result might have more to do with the still far too weak motor performance. Future runs with a more accurate motor simulation and other evolution parameters will most probably lead to a successful locomotion pattern.
[Prototype Performance Analysis]
(The Simulation-Reality Gap: Environment)
The prototype was brachiating on a rope consisting of twisted steel wires coated with thin rubber, while in simulation a perfectly stiff bar was used. As a result a different quality of friction between claws (aluminium) and rope (rubber) occurred. The tense rope still had flexibility and its own dynamic response caused by the movements of the prototype. Therefore a cross-influence between the two objects – robot and rope – took place and distorted the locomotion pattern of the agent.
(The Simulation-Reality Gap: Performance)
The major difference between the locomotion pattern of virtual agent and the prototype lied in the fact that in simulation the creature seemed to form a 'knee' forward with its passive body joint by maintaining a constant torque in its shoulders throughout the whole locomotion cycle.
Such a behaviour was not implemented in the first program version of the prototype and it is doubtful whether it can be done with this hardware configuration: the current friction between claws and rope demanded a more dynamic swinging behaviour then observed in simulation to free the arms. This seemed only possible by using the whole body mass to get momentum – which was contradictory to the strategy of forming a constant ‘knee’.
The need for more momentum to overcome the real world friction described above ‘justified’ another not intended difference between prototype and simulation: the motor force of the real prototype was significantly higher than observed in simulation. The result was a stronger swinging behaviour that allowed locomotion despite the higher friction.
As mentioned before, the difference in motor performance was very likely due to some shortcomings in the simulation of motor force and speed. The tests during the development process had already shown an unrealistic factor of 14. This observation could easily be verified by measuring the stall torque of the actual used motors (using the exact same power feed as on the prototype), entering the proper values into the simulation and rerunning the evolutionary process.
Possible improvements of the prototype performance could be achieved with additional iteration steps – which would have exceeded the time span of this semester project:
The current controller code can certainly be optimized and tuned - including the use of more sensors than the actual three, according to the weighting matrix of the neural network.
A more thorough analysis of the weighting matrices of the neural network of the fittest variants was planned but not done in this project due to limited time resources. Such an analysis is not trivial, but could help a great deal with the interpretation of the locomotion pattern and the transfer of a similar control structure to the prototype.
Further iterations would include a more accurate simulation of the motor forces and material properties (e.g. friction between claws and rope), followed by a thorough analysis and implementation into the controller program. Apart from that, the dynamic properties of the rope could also be realized in simulation or avoided in the real world by using a stiff bar instead.
Another possibility to come back to the original plan of creating a independent agent would be the use of the battery packs as a power source and not just as weights for swinging – thus freeing the robot from all cables.
[Project & Design Method Evaluation]
(Project Progress Aspects: Definition of Quality & Success)
When I started with this project it was hard to anticipate how many iterations would be necessary for a satisfying result and how much time all those steps would require. As for most projects, it was especially hard to find a measuring rod to define quality and success (e.g. how dynamic must a locomotion pattern be in order to be considered interesting and representative enough for an implementation in the prototype and thus for the evaluation of the design method?). ‘Fortunately’, the time span was limited to roughly seven weeks for this semester project - which at least defined certain milestones when it was definitely time to move on.
In this specific project the criteria for the prototype selection was to find the best trade-off between simplicity and a dynamic locomotion pattern: both simple to understand and easy and fast to implement with few resources and dynamic in the sense of not being stable in each timeframe, but showing a jumping or swinging behaviour.
The brachiating robot showed a satisfying dynamic behaviour: it moved successfully forward on the rope by using all its power to overcome friction, the pattern was reproducible and close to the one observed in simulation. And above all it was a good choice for this limited time span regarding the relatively simple morphology and control structure that made a successful implementation possible.
(Simulation Environment Problems)
The design with MorphEngine was quick and easy, its capabilities turned out to be sufficient for this project, yet the possibilities of evolution were still quite limited and could have been a bit wider: important features such as adaptive length of objects, mass distribution, spring parameters and noise were not implemented. Not to speak of the limitation of objects to sphere, cube and cylinder. The fitness function was limited to locomotion in one direction or following a light source.
One of the main weaknesses of the software is the unpredictability of the impact of parameter changes to the evolutionary algorithm such as population size, number of generations, mutation rate and number of hidden nodes in the neural network etc. The solution space is infinite, systematic approaches go quickly beyond infrastructure and time resources.
The key module of MorphEngine, MathEngine Karma, is a third party simulation environment. It is closed source, which could cause difficulties in judging the reliability of the simulation - as encountered in this project with the motor parameters - and which makes necessary changes on the source impossible.
(Unsolved ANN-Transfer Problems)
A drawback in the project was the use of a programmed computer chip instead of an artificial neural network (ANN) – a problem that was impossible to examine further in the narrow time span of seven weeks.
Having no such possibilities for a direct transfer, the question arose, how well a resulting locomotion pattern in general can be understood and interpreted. It worked quite well in this relatively simple case of a brachiating robot, but how about more complex patterns when parallel processing is needed for real time performance?
A suggestion for a possible solution in this specific method of rapid prototyping is described under 'Suggestions & Visions'.
(Design Method Evaluation Aspects: Complexity & Inspiration)
A criterion for the usefulness of the design method was how much the software would support and inspire the design of highly dynamic locomotion patterns in general. This is one of the most important aspects: tools to inspire or solve complex dynamic problems of cross-linked movable objects and not just structures which are stable in each timeframe (e.g. locomotion with six legs or wheels) are rare.
As a matter of fact, the locomotion pattern found by the evolutionary algorithm was often highly dynamic assuming that the specific creature morphology supported such a solution.
The aspect of inspiration through evolution was tested in more detail with the three-legged creature called Titan. It is hard for an engineer to design a locomotion pattern for a leg configuration that is not present in nature. The goal was therefore to prove the usefulness of evolutionary computation in such a situation and to see if it will come up with a solution. And the result was satisfying: the creature moved successfully on its three legs over the virtual plain - although not extremely elegant from the human point of view.
(Design Method Evaluation Aspects: Engineering vs. Evolution)
One of the key problems was how to stay best on the narrow path between ‘unpredictable’ evolution and pure human engineering.
The first evolutionary strategy leads possibly to surprising solutions (e.g. Titan’s tripedal locomotion), but with no guaranties for convergence (e.g. a Gibbon-like swinging strategy that needs precisely timed actions to place its hands on the rope) or a reliable translation to a real world implementation (Athlete’s locomotion pattern).
The second strategy of pure biased engineering guarantees good convergence and a realistic chance of prototyping, but hardly any exploitation of the givens and unobvious possibilities of the specific morphology - thus wasting promising solutions that are mostly filtered by the human focus, but always ‘found’ by evolution.
In this method, the best approach was considered to be a highly iterative digital mockup, starting with a pool of ‘arbitrary’ morphologies and then going back and forth between adaptation due to hardware considerations on one hand and the surprising evolutionary exploit of new givens on the other. This approach came a tiny step closer to the ideal of artificial growth (widely regarded as the perfection of a parallel development process) by using both: evolutionary inspirations and human invention.
One may state that the solution the algorithm came up with was obvious, the exploitations of physical givens clear. This might be true in many cases, but it is also undeniable that such a tool could be a great help to an engineer or robotics scientist when evaluating quickly a new solution for a complex structure with many moving parts and a complicated mass distribution.
In total the project was quite a success despite all the difficulties encountered. The design process in simulation was easy, quick and inspiring, the iteration steps from virtual space to reality and vice versa could be done without major problems and brought real improvements in an astoundingly short time. The prototype worked well and gave great satisfaction to its human creator. With the knowledge of this project, the future production cycle for an agent of a similar complexity can be estimated to be less than four weeks, if well planned.
This chapter is based on the information found on homepages and articles of the corresponding project. Please refer to the original page for more precise information.
A famous and promising example of rapid prototyping is the Golem Project. The goal of the project is complete and autonomous co-evolution of controller and phenotype in a limited universe physical simulation, coupled to off-the-shelf rapid manufacturing technology (3D lithography).
The most important differences between the Golem Project and the project described in this report are:
Complete co-evolution is implemented in the Golem Project from the very start (compared to human design in MorphEngine).
In the Golem Project there is the possibility of automated rapid prototyping (only motors and actuaters have to be added manually). In this method every implementation in hardware is done by the engineer.
The mechanics in the Golem Project were simulated using quasi-static motion, where each frame of the motion is assumed to be statically stable. This kind of motion is rich enough to support various kinds of low-momentum motion like crawling and walking – but no highly dynamic locomotion patterns like jumping that are possible with MorphEngine.
Noise was added in the Golem Project to ensure the system does not converge to unstable equilibrium points, and to cover simulation-reality gap. Noise is not yet implemented in MorphEngine.
In the Golem Project material properties modelled correspond to the properties of the rapid prototyping material. In MorphEngine there is no possibility to define different material properties (e.g. needed during the last iteration steps).
Source: the Golem Project homepage
The team at Xerox Palo Alto Research Center (and other research groups all over the world) have another promising approach to rapid prototyping by using modular reconfigurable robots - experimental systems made by interconnecting multiple, simple, similar units.
The ability to change the shape could be of great value for adaptation to constantly varying tasks and environments. Modular reconfigurable robots are built up from tens to hundreds, and potentially millions, of modules. These, like cells in a human body, are few in type but many in number. Such robots are called n-modular systems (where n is the number of module types).
An n-modular system holds out three promises: versatility, robustness, and low cost. Its versatility stems from the many ways in which modules can be connected, much like a child's Lego bricks. The same set of modules could connect to form a robot with a few long thin arms and a long reach or one with many shorter arms that could lift heavy objects. For a typical system with hundreds of modules, there are usually millions of possible configurations, which can be applied to many diverse tasks.
To put together a useful system, solutions must be found to the complexities of programming a great many coupled, but independent, robotic units. Worse, as more modules are added, many of the programming issues get exponentially harder. These include controlling and coordinating modules to work together effectively and not collide or otherwise interfere with each other.
Robustness is born of the redundancy and small number of module types. The units diagnose themselves and each other and compensate for, replace, or reconfigure themselves around any that are malfunctioning.
Source: IEEE cover article by Samuel K. Moore and the homepage of Xerox PARC
(Modular Robots @ AI Lab Zürich)
This project is part of the European IST programme, and is called the HYDRA project. The hydra is a microscopic animal that is able to regrow parts of its body if they are damaged or removed. The name for this animal comes from the many- headed monster from Greek mythology by the same name.
The aim of this project is to explore, develop and build modular, robust robotic systems. The robots will be composed of individual modules that can perform some primitive behaviours on their own. The overall behaviour of the multi-unit robots will emerge from the way in which the modules are attached together; similarly, the functionality of the robot will be a product of the specific, and perhaps unique functionalities of the individual units.
Several current research projects underway in our lab, the Artificial Ontogeny, the Artificial Growth and the reconfigurable modular robot projects, will contribute to the initial stages of the HYDRA project.
Source: Hydra Page at Artificial Intelligence Laboratory, Zurich, Switzerland
(Simulation Environment: Improving Evolutionary Adaptation)
As mentioned before, a much more decisive improvement would be the extension of the design capabilities that are still quite limited: important features such as adaptive length of objects, material properties, adaptive mass distribution, adaptive spring parameters and noise are not yet implemented.
Features like those (and all the others supported theoretically by MathEngine, but not yet by MorphEngine) would make the design tool much more powerful compared to classic engineering tools where the human engineer defines everything.
(Simulation Environment: Improving Evolutionary Convergence)
Certain desired behaviour is not achievable at this point, since the probability that the evolutionary algorithm finds a solution within a couple of days is near zero (e.g. ape closing its hand at the exact right moment over the rope).
Interesting would be the implementation of more interfaces to introduce human bias into the system, e.g. several parallel fitness functions with different weights or a sequential procedure with the possibility to use already evolved genomes.
(Real-World ANN-Transfer For Rapid Prototyping)
The possibility of a direct transfer of a parallel processing artificial neural network (ANN) to the robot instead of the detour over a serial PIC could bring a real advantage. A simple and cheap solution for this problem in a laboratory might be a modular system of tiny standardized neuron-units (e.g. minimal programmable silicon chips) that could be easily interconnected with normal cables and hubs while being programmed within seconds (e.g. its response function and input/output weights) on a specially designed tool similar to the currently used Microchip PICSTART Plus programmer.
(Increased Adaptability Through Learning Capabilities)
If in addition learning capabilities are implemented on the prototype itself (in the hardwired modular ANN described above), the last optimization steps could be done on the agent by itself - an adaptability and accuracy never possible alone by human hardware analysis followed by a transfer of these parameters to simulation (as done in this project).
(Higher Modularity And Automated Production)
Merging methods for digital mockup based on evolution in a high-level simulation environment with highly modular components (see Xerox PARC and Hydra Project) that might be automatically manufactured and assembled (like in the Golem Project- or just like simple computer hardware) could lead to the perfection of automated rapid prototyping for robust, adaptive and ‘intelligent’ agents for any purpose.