[ec2m] Physics engines
Adam Rotaru
adam_rotaru at yahoo.com
Sun Nov 11 10:52:08 PST 2001
--- Colm Massey <colm_massey at yahoo.co.uk> wrote:
> What do you mean when you say 'with evolutionary
> algorithms in mind'?
Hi to everyone,
Inspired by the not-so-recent-anymore discussion
on this list, I put together a list of requirements
which would be nice from a physics engine used for
ALife experiments. Most of them are obvious, and
there
are probably many which I have not thought of. As
this
list includes people with experience with ALife work
and various physics engines, I would appreciate any
comments to my list. 'Any' include comments like
'this is utter nonsense' too!
cheers,
Adam
Requirements for a Physics Engine for Artificial
Life Experiments
Physical Requirements
* Rigid bodies. Simulator supports rigid bodies.
Simulated objects have volume, orientation (3 DOF),
angular acceleration
(3 DOF), rotational inertia, etc.
* Articulated bodies. Bodies composed of multiple
linked object
can be simulated. The simualtor preserves the
relative position
of linked objects, using hard (preferred) or soft
constraints.
Joints can be of several types (hinge,
ball-and-socket, etc.), and
also support joint limits.
* Ground plane, friction. Collisions between objects
and a ground
plane are detected and handled. Normal forces and
friction forces
are also simulated.
* Water, drag. It is possible simulate objects
immersed in fluid,
or viscious gas. Drag forces are simulated.
* Multiple bodies. The simulator should be able to
represent multiple
distinct articulated bodies within the same scene.
* Collision detection. The simulator should offer
support for
collision detection and/or collision handling between
object.
It should be possible to differentiate among
collisions occuring
between objects of the same body, or objects of
different bodies,
or more generally, between objects from the same or
different classes.
* Stability. Some physical simulation integration
methods can produce
unstable solutions. Instability occurs especially in
conditions with
high velocities or large forces (e.g., large contact
forces).
Evolutionary experiments are likely to discover such
problems in the
simulator for two reasons:
(1) evolution can exlpore a wide variety of dynamic
behaviours, and
(2) because evolution ususally optimizes against some
physical constraints,
it is more likely to produce solutions which are close
to some
the limit cases, which are more likely to lead to
instability.
Instability is an important issue, because it can
cause the
evolution algorithm to abort or produce completely
wrong results.
If a physical engine cannot guarantee stability in all
circumstances,
it should at least offer a way to detect when an
instable state occurs
as early as possible.
* Speed. The speed of the simulation is also
important, as avolutionary
experiment usually require a very large number of
simulation steps.
However, stability should not be sacrificed for speed.
* Accuracy. Accuracy of the simualation is important,
but probably
less important than stability. Numerical accuracy can
be very important
in an egnineering simulation, but less important in an
ALife simulation.
It is important that the simulation obeys a consistent
set of rules,
but the details of the rules are less important. For
example, it is
important that an almost-vertical standing stick start
to fall down
in the direction of the initial deviation, but it is
not so important
if it reaches the ground in 20 or 25 simulation steps.
However, the set of rules obeyed also includes
higher-level rules such
as 'the total energy of a closed system is constant
(never increases)',
otherwise evolution produces solutions which exploit
inconsistencies.
Some requirements for experimentation
* Simulator independent of graphics display. It is
common that a
physics engine is tightly integrated with a graphics
engine,
or at least has a preview facility. In a typical
evolutionary experiment,
displaying the simulation is not required for most of
the evolution,
only for some final results, so it should be possible
to run the
simulation with no display whatsoever. Another reason
is that the
artifical world might contain elements which are not
part of the
physical simulation, but should be displayed (e.g.,
energy balls).
Since these objects are not part of the simulator, it
cannot draw them.
* Repeatability. If the same initial conditions are
specified and no
forces are applied, the simulator should produce
exactly the same end result.
If the same initial conditions are specified and the
same sequence of
forces are applied, the simulator should produce
exactly the same end result.
Note that even the most minuscule deviations would be
intensified
throughout the simulation. Exact repeatability is
achieved if the
simulator uses no numbers which are random, or depend
on some other
entity not included in the global simulation state
(e.g., current system load).
Random numbers can be used if the random nuber
generation is completely
controlled (the initial seed is part of the initial
global state).
* Save/load complete scene. Convenient way to save
and later load
the complete simulation state. Continuing a saved
state should produce
the same results as if the simulation had not been
interrupted.
Some requirements for the API of the library
The following operations should be supported:
- specify complete scene (morphologies, connections,
body parameters)
-- done once, initially
- specify forces (effectors) -- frequently (every
simulation step).
- query positions, orientations, for display and input
for control
-- frequently.
- update morphology (break links, new parts) --
occasionally.
Adam Rotaru-Varga, 2001.11.11.
This document may be reproduced with no restrictions
in any form.
__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com
Received: from [131.215.34.116] (helo=floating.idyll.org)
by idyll.org with esmtp (Exim 3.03 #1)
id 1632hS-0006j9-00
for ec2m-list at old.alife.org; Sun, 11 Nov 2001 14:03:34 -0800
Received: from postoffice2.mail.cornell.edu ([132.236.56.10])
by floating.idyll.org with esmtp (Exim 3.22 #1)
id 1632hW-00026f-00
for ec2m-list at alife.org; Sun, 11 Nov 2001 14:03:38 -0800
Received: from PICASSO ([128.84.137.123])
by postoffice2.mail.cornell.edu (8.9.3/8.9.3) with SMTP id RAA08845;
Sun, 11 Nov 2001 17:03:31 -0500 (EST)
Reply-To: <Hod.Lipson at cornell.edu>
From: "Hod Lipson" <hl274 at cornell.edu>
To: "Adam Rotaru" <adam_rotaru at yahoo.com>, <ec2m-list at alife.org>
Cc: <russ at q12.org>
Subject: RE: [ec2m] Physics engines
Date: Sun, 11 Nov 2001 17:04:12 -0500
Message-ID: <NBENLCMAIEIELJOFNHHOMEHLCBAA.hl274 at cornell.edu>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <20011111185208.28065.qmail at web10004.mail.yahoo.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: ec2m-list-admin at alife.org
Errors-To: ec2m-list-admin at alife.org
X-BeenThere: ec2m-list at alife.org
X-Mailman-Version: 2.0beta2
Precedence: bulk
List-Id: Evolution of Creature Controllers and Morphologies <ec2m-list.alife.org>
two other requirements:
1: Can handle kinematic loops. Most solvers can only handle tree structures.
If you need to simulate more general architectures, the solver should handle
kinematic loops as well as chains. For an example of a creature with several
kinematic loops see
http://www.demo.cs.brandeis.edu/golem/creatures/crab/crab.mpg
2: (Technical) The solver should be fail gracefully in case of singularities
or other computational errors so that the evolutionary process would be able
to identify bad designs.
-- hod
Hod Lipson
Prof. of Mechanical & Aerospace Engineering
and Computing & Information Science
Cornell University, 216 Upson Hall, Ithaca NY 14853, USA
Office: (607) 255 1686 Lab: 254 8940 Fax: 255 1222 Email:
Hod.Lipson at cornell.edu
http://www.mae.cornell.edu/lipson
> -----Original Message-----
> From: ec2m-list-admin at alife.org [mailto:ec2m-list-admin at alife.org]On
> Behalf Of Adam Rotaru
> Sent: Sunday, November 11, 2001 1:52 PM
> To: ec2m-list at alife.org
> Cc: russ at q12.org
> Subject: Re: [ec2m] Physics engines
>
>
> --- Colm Massey <colm_massey at yahoo.co.uk> wrote:
> > What do you mean when you say 'with evolutionary
> > algorithms in mind'?
>
> Hi to everyone,
>
> Inspired by the not-so-recent-anymore discussion
> on this list, I put together a list of requirements
> which would be nice from a physics engine used for
> ALife experiments. Most of them are obvious, and
> there
> are probably many which I have not thought of. As
> this
> list includes people with experience with ALife work
> and various physics engines, I would appreciate any
> comments to my list. 'Any' include comments like
> 'this is utter nonsense' too!
> cheers,
> Adam
>
>
>
>
> Requirements for a Physics Engine for Artificial
> Life Experiments
>
>
> Physical Requirements
>
> * Rigid bodies. Simulator supports rigid bodies.
> Simulated objects have volume, orientation (3 DOF),
> angular acceleration
> (3 DOF), rotational inertia, etc.
>
> * Articulated bodies. Bodies composed of multiple
> linked object
> can be simulated. The simualtor preserves the
> relative position
> of linked objects, using hard (preferred) or soft
> constraints.
> Joints can be of several types (hinge,
> ball-and-socket, etc.), and
> also support joint limits.
>
> * Ground plane, friction. Collisions between objects
> and a ground
> plane are detected and handled. Normal forces and
> friction forces
> are also simulated.
>
> * Water, drag. It is possible simulate objects
> immersed in fluid,
> or viscious gas. Drag forces are simulated.
>
> * Multiple bodies. The simulator should be able to
> represent multiple
> distinct articulated bodies within the same scene.
>
> * Collision detection. The simulator should offer
> support for
> collision detection and/or collision handling between
> object.
> It should be possible to differentiate among
> collisions occuring
> between objects of the same body, or objects of
> different bodies,
> or more generally, between objects from the same or
> different classes.
>
> * Stability. Some physical simulation integration
> methods can produce
> unstable solutions. Instability occurs especially in
> conditions with
> high velocities or large forces (e.g., large contact
> forces).
> Evolutionary experiments are likely to discover such
> problems in the
> simulator for two reasons:
> (1) evolution can exlpore a wide variety of dynamic
> behaviours, and
> (2) because evolution ususally optimizes against some
> physical constraints,
> it is more likely to produce solutions which are close
> to some
> the limit cases, which are more likely to lead to
> instability.
> Instability is an important issue, because it can
> cause the
> evolution algorithm to abort or produce completely
> wrong results.
> If a physical engine cannot guarantee stability in all
> circumstances,
> it should at least offer a way to detect when an
> instable state occurs
> as early as possible.
>
> * Speed. The speed of the simulation is also
> important, as avolutionary
> experiment usually require a very large number of
> simulation steps.
> However, stability should not be sacrificed for speed.
>
> * Accuracy. Accuracy of the simualation is important,
> but probably
> less important than stability. Numerical accuracy can
> be very important
> in an egnineering simulation, but less important in an
> ALife simulation.
> It is important that the simulation obeys a consistent
> set of rules,
> but the details of the rules are less important. For
> example, it is
> important that an almost-vertical standing stick start
> to fall down
> in the direction of the initial deviation, but it is
> not so important
> if it reaches the ground in 20 or 25 simulation steps.
> However, the set of rules obeyed also includes
> higher-level rules such
> as 'the total energy of a closed system is constant
> (never increases)',
> otherwise evolution produces solutions which exploit
> inconsistencies.
>
>
>
> Some requirements for experimentation
>
> * Simulator independent of graphics display. It is
> common that a
> physics engine is tightly integrated with a graphics
> engine,
> or at least has a preview facility. In a typical
> evolutionary experiment,
> displaying the simulation is not required for most of
> the evolution,
> only for some final results, so it should be possible
> to run the
> simulation with no display whatsoever. Another reason
> is that the
> artifical world might contain elements which are not
> part of the
> physical simulation, but should be displayed (e.g.,
> energy balls).
> Since these objects are not part of the simulator, it
> cannot draw them.
>
> * Repeatability. If the same initial conditions are
> specified and no
> forces are applied, the simulator should produce
> exactly the same end result.
> If the same initial conditions are specified and the
> same sequence of
> forces are applied, the simulator should produce
> exactly the same end result.
> Note that even the most minuscule deviations would be
> intensified
> throughout the simulation. Exact repeatability is
> achieved if the
> simulator uses no numbers which are random, or depend
> on some other
> entity not included in the global simulation state
> (e.g., current system load).
> Random numbers can be used if the random nuber
> generation is completely
> controlled (the initial seed is part of the initial
> global state).
>
> * Save/load complete scene. Convenient way to save
> and later load
> the complete simulation state. Continuing a saved
> state should produce
> the same results as if the simulation had not been
> interrupted.
>
>
>
> Some requirements for the API of the library
> The following operations should be supported:
> - specify complete scene (morphologies, connections,
> body parameters)
> -- done once, initially
> - specify forces (effectors) -- frequently (every
> simulation step).
> - query positions, orientations, for display and input
> for control
> -- frequently.
> - update morphology (break links, new parts) --
> occasionally.
>
>
>
> Adam Rotaru-Varga, 2001.11.11.
> This document may be reproduced with no restrictions
> in any form.
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Find a job, post your resume.
> http://careers.yahoo.com
>
> ______________________________________________________
> This message was sent through the ec2m mailing list.
>
> Use the "Reply" function of your email software to
> reply to the sender only. Use "Reply to all" (or
> similar) to send your reply to the whole list.
>
> To unsubscribe from this list, follow the instructions
> at http://www.alife.org/mailman/listinfo.cgi/ec2m-list
Received: from [131.215.34.116] (helo=floating.idyll.org)
by idyll.org with esmtp (Exim 3.03 #1)
id 163C3W-00088i-00
for ec2m-list at old.alife.org; Mon, 12 Nov 2001 00:02:58 -0800
Received: from postbox.dai.ed.ac.uk ([129.215.41.196])
by floating.idyll.org with esmtp (Exim 3.22 #1)
id 163C3d-0008Ol-00
for ec2m-list at alife.org; Mon, 12 Nov 2001 00:03:05 -0800
Received: from lenny (lenny.dai.ed.ac.uk [129.215.41.49])
by postbox.dai.ed.ac.uk (8.9.3/8.9.3) with ESMTP id IAA09096;
Mon, 12 Nov 2001 08:02:25 GMT
Date: Mon, 12 Nov 2001 06:30:18 +0000 (GMT)
From: John Hallam <john at dai.ed.ac.uk>
To: Adam Rotaru <adam_rotaru at yahoo.com>
cc: ec2m-list at alife.org, russ at q12.org
Subject: Re: [ec2m] Physics engines
In-Reply-To: <20011111185208.28065.qmail at web10004.mail.yahoo.com>
Message-ID: <Pine.GSO.4.10.10111120627240.2271-100000 at lenny.dai.ed.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: ec2m-list-admin at alife.org
Errors-To: ec2m-list-admin at alife.org
X-BeenThere: ec2m-list at alife.org
X-Mailman-Version: 2.0beta2
Precedence: bulk
List-Id: Evolution of Creature Controllers and Morphologies <ec2m-list.alife.org>
Here are a couple of comments:
On Sun, 11 Nov 2001, Adam Rotaru wrote:
> Requirements for a Physics Engine for Artificial
> Life Experiments
>
> * Repeatability. If the same initial conditions are specified and no
> forces are applied, the simulator should produce exactly the same end
> result. If the same initial conditions are specified and the same
> sequence of forces are applied, the simulator should produce exactly
> the same end result. Note that even the most minuscule deviations
> would be intensified throughout the simulation. Exact repeatability
> is achieved if the simulator uses no numbers which are random, or
> depend on some other entity not included in the global simulation
> state (e.g., current system load). Random numbers can be used if the
> random nuber generation is completely controlled (the initial seed is
> part of the initial global state).
This is infeasible. You can get repeatable results on a given
platform but the integration of complex dynamical systems using floating
point apporximations is not portable in principle.
Licensing requirements:
The software should be licenced so as to permit its use in
massively parallel environments without problems (e.g. no pay-per-instance
counted licenses) for those of us who like to task-farm the fitness
evaluations in evolutionary experiments.
More information about the EMBody
mailing list