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

 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,
 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
 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
 > whole will be useful /design/ tools for the micro-scale robot
 > 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
 > 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
 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:
 > []
 > Sent: Friday, February 13, 2004 12:31 PM
 > To:
 > Cc: G. Clark Haynes; 'Alfred Rizzi'; 'Uluc Saranli'; Robert Full
 > 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
 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")

This site is powered by the TWiki collaboration platformCopyright &© by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback