• Rather than my previous ideas to later tack-on a file format on top of whatever interface I choose, I think it makes more sense to design the CDL as a file format (an actual language, per se). Then, there is only one set of code that interfaces with the Arachi DE, which I will code, whereas everyone else will simply define CDL files which get interpreted and used by the interface to Arachi DE. Besides, some hard-to-code funtionality automatically falls into place if I input creatures from file, rather than define them in a C-like syntax.

• The interpretation of these files will invariably be a slow process, but it only has to be done once per simulation. That 1 or 2 seconds will be minute compared to the the necessary to run a simulation.

• While it would be nice to support third-party file formats (STEP, ADAMS, WM, etc), it's probably not a feasible goal at this point of time. For our project, we need only a small subset of functionality of other programs, and we would prefer certain tasks to be as easy as possible. Defining our own language achieves this in the easiest possible way.

• There are several key concepts to the Creature Description Language:
  • Defining geometries is done through using predefined functions. Defining rotations and translations can be done as easily using predefined functions.
    • It is always possible to define your own functions, to simplify the writing of input files.
    • As well, since common components tend to be reused throughout different designs, it is possible and highly suggested to write your creatures using several modular files, rather than a single file.
  • To define moveable connections between geometries (connecting body primitives, as described in the DesignReviewCDL), you simply need to define a joint. In order to control a joint, you give it a name. In order to make it into a passive joint, you specify the parameters of its compliance.
  • Unlike using the C++ interface to Arachi DE, which uses a procedural interface, the CDL defines a small subset of a functional language. Changes in the order of statements have no effect on the outcome. The application of operators is distributive.

I'm working on a few sample files to flesh out the ideas for the CDL. Below are three files. The first defines some common transformations that would be useful for all definitions. The second defines a single leg. The third shows how to use the transforms and leg description to attach them all together in a single body. Note that none of this is implemented. I am simply designing a spec that my implementation will adhere to.

Rotation RotationZ(angle) {{
  Cos(angle),  Sin(angle), 0,
 -Sin(angle),  Cos(angle), 0,
       0,          0,      1,
}}

Rotation RotationX(angle) {{
  1,    0,           0,
  0,  Cos(angle),  Sin(angle),
  0, -Sin(angle),  Cos(angle),
}}

Rotation RotationY(angle) {{
  Cos(angle),  0,  Sin(angle),
     0,        1,      0,
 -Sin(angle),  0,  Cos(angle),
}}

Object Leg(l) {{ % x points along the leg (since Z is DOF)
  Block(l,l/10,l/10);
}}

% Y points forward in robot frame
Object RHex(w,l,h) {{

  % alias to simplify leg length assignment
  myleg = Leg(l);

  % alias to apply leg easily
  ApplyLeg(x,y,name) = Translation(x,y), RotationY(PI/2), 
                       RotationZ(PI), RevoluteJoint(name,0) {myleg};

  % define the center mass of the body
  Translation(-w/2,-l/2,-h/2) { Block(w,l,h); }

  % legs on left side of body
  ApplyLeg(-w/2,-l/2,L1);
  ApplyLeg(-w/2,   0,L2);
  ApplyLeg(-w/2, l/2,L3);

  % legs on right side of body
  ApplyLeg( w/2,-l/2,R1);
  ApplyLeg( w/2,   0,R2);
  ApplyLeg( w/2, l/2,R3);

}}

If you have any questions, comments, or suggestions, please feel free to post them here, or send me e-mail.

-- ClarkHaynes? - 23 Oct 2003