Parametric Design
A long term goal of the Biodynotics Institute in the original proposal was to develop systematic design approaches for the passive and active components of a robot in response to given performance objectives.
Background: By systematic design I mean the ability to synthesize, automatically or by following a well defined process, a design that statisfies certain functional and physical requirements. The state of the art is more advanced in the controls domain of robotics than it is for their mechanical design. More Generally, design synthesis is more advanced for digital electronics and software design than it is for mechanical design. There has been much discussion about this in the mechanical design research community.
... more to come
Relationship between SDM and mechanical design synthesis
Pointers to other stuff...
--
MarkCutkosky - 20 Feb 2004
Email discussion from
DanKoditschek with additions from
AlRizzi and others regarding relationship between CDL (Creature Description Language) and materials/shape paramerization:
Date: Fri, 20 Feb 2004 04:10:58 -0500
Subject: Relationship of CDL to SDM
Guys,
I had meant to get this out days ago to rev up the chat in advance of Mark's SDM talk today
... but.... sorry .... hopefully now is better than tomorrow ...
>On February 13 at 01:01:30, G. Clark Haynes wrote:
> Dan,
Clark,
First some reactions to your response, then, afterward some further
reactions to Al's comments.
>
> Regarding an integration of the CDL with SDM, I think that you may be
> misinterpreting the scope of the simulation system, at least as I see
> it.
>
Certainly, no relationship to SDM was ever placed in your mandate so in
that regard I am of course completely misrepresenting its intended scope
:)
> The purpose of the simulation system is to provide us with macro-scale
> simulations of our robots. Compliance and properties like sticky
> surfaces will be simulated by lumping their parameters together as much
> as possible, making the simplest/fastest simulations possible.
>
> This is because, in my view, we have two principle components in our
> target audience for the simulation system:
>
> 1) behavior developers - the simulation system will provide them with
> a tool to write robot code without actual robots, as well as to simulate
> code pre-run, a la SimSect.
>
> 2) macro-scale robot designers - the simulation system will provide
> necessary feedback on robot designs regarding critical design elements
-
> things like body mass, leg/foot designs, pad stickiness, etc.
Although our sponsors might not always be entirely convinced of this,
there is of course a third (and in the long run more important)
potential audience: people (like us) trying not merely to build the next
exciting gadget but to develop the science of robot systems design.
Those who would like to try to begin to develop a theory that yokes 1) &
2) together in a more or less reasonably parametrized manner and yet is
capable of modeling some degree of reality in what can actually be
built.
To the extent roboticists have come to understand that control
algorithms reside partly in software & electronics, and partly in the
tuned morphology of the robot body, to that same extent are we urgently
in need of such a joined parametrization. Since there are too many
possibilities rather than too few, the only satisfactory way to make
progress is in numerical simulation. Hence the possibility that we might
begin to have a design environment wherein control components might be
associated with morphological building blocks is too intriguing to let
go without a struggle.
>
> Unfortunately, I don't think that the CDL and the simulation system as
a
> whole will be useful /design/ tools for the micro-scale robot
designers,
> just excellent feedback tools. In my discussions with Al, Uluc, and
> others, we have never considered doing simulations of whole feet (ie -
> modeling every single compliant element, etc); we are instead aiming
for
> models that will encompass the general properties of our pedal
> structures.
>
Right - the challenge is to see if we can find a way to make the
sensor/control abstraction hierarchy fit up to the morphology
abstraction hierarchy in a sensible way. Note that the link to the right
PCM "module" would also need to be in place, so this is even
worse/harder/further-from-present-reality than we've stated.
Although there is a pretty clear dynamical systems abstraction hierarchy
inherited from 300 years of physics and 100 years of applied mathematics
thinking, we are just beginning to have ideas that could lead to a true
(i.e., theoretical constructs that actually can produce working
machines) sensor/control abstraction hierarchy.
Similarly, I have the feeling listening to Mark that he and people like
him are just beginning to develop a morphology abstraction hierarchy
related to what can be built.
> I don't think it's likely that the tried-and-true CAD systems will be
> replaced by the CDL any day soon. Other comments?
>
> -Clark
>
So my point was not that our CDL should or even could be any kind of
front end for an SDM CAD. Rather, the opposite - that we might be able
to represent aspects of his emerging SDM CAD "macros" within the cruder
but representative lumped world of CDL/PCM. I.e., that Mark may likely
have his hands on certain SDM "recipes" (e.g., a parametrized class of
limb shapes endowed with a parametrized family of compliant flextures
and rigid interstices) that can be lumped up into a CDL/PCM
representation which we might then use as a "limb macro" to build our
simulations.
I'm really looking forward to hearing from Mark much more about the
availability of these "recipes" and to your reactions about how readily
they might be "crudified" into a CDL macro.
Now, following on Al's comments
> -----Original Message-----
> From: arizzi@benedict.msl.ri.cmu.edu
> [mailto:arizzi@benedict.msl.ri.cmu.edu]
> Sent: Friday, February 13, 2004 12:31 PM
> To: kod@umich.edu
> Cc: G. Clark Haynes; 'Alfred Rizzi'; 'Uluc Saranli'; Robert Full
(Robert
> Full); 'Mark C'; 'Jonathan Edward Clark'
> Subject: Re: Relationship of CDL to SDM
>
> Dan,
>
> I think the key "problem" with achieving the level of integration you
> aspire toward here is that CDL and the Arachi simulation tools
> fundamentally require lumped parameter representations. SDM
> manufacturing (as I understand it) exploits carefully chosen
> distributed material properties to effect designs that have "good"
> lumped parameter behavior while avoiding the inherit complexity of
> discrete components and assembly. However, unless Mark understands
> these types of designs in ways I can not yet imagine, I do not think
> it is yet possible to automatically translate between these two
Yes, I think as usual you are right on the money: to what extent does
Mark presently have "recipes" at his disposal that accomplish via the
right mix of distributed material properties some finitely parametrized
family of lumped properties that are reasonably reliably prescriptive. I
had the feeling browsing/listening-in on some of his earlier papers &
discussions that he was on the way toward at least crude recipes of this
kind.
I'll be keen to hear from him how much this is true or not.
> seemingly disparate domains. Beyond this, SDM manufacturing and
> design offers the opportunity to use structures for multiple purposes
> -- e.g. imagine a flexure that can also serve as a traction pad --
> modeling such structures at a resolution that inherently is capable of
> capturing such performance is probably beyond our capabilities or
> desires.
>
> -Al
>
Here I think I disagree: it's clearly beyond our capabilities, but
square on with our (most broadly & grandly construed) needs & desires.
In fact, I think the need is far worse, and scarier: we not only have to
yoke the multiple mechanical purposes into our representation, but also
somehow attach up the controls methods used to deploy those multiple
purposes. Truly beyond our reach right now, but truly, I think where we
have potentially the most to learn from and pay back our friends in
biology (whose systems come endowed with presently indecipherable
multiply recursively yoked parametrizations called "genes")