Design Notes for CDL in progress
This page details the development of the Creature Description Language (CDL), used for defining and interfacing robots with the Arachi Dynamics Engine (DE) and our supporting RiSE software.
Updates
March 12, 19
MarkCutkosky
Various materials posted by
ClarkHaynes for discussion in the Friday teleconferences.
Older notes...
As detailed in our initial action plan for Subgroup 4.1, there are four main sections of software to be written. RiSELib (RLB) and the Real Time Interface (RTI), organized by
UlucSaranli, will be legacy code updated from RHexLib and SimSect++. The Parameterized Contact Mechanics (PCM) will be organized by
JonathanClark and will provide programmers with methods to model complex surface interactions. The final category is the Creature Description Language (CDL), which will be used to codify a robot design.
In basic terms, the CDL will wrap and augment functionality from DE, offering a slightly easier interface, meant specifically for working with dynamic, dexterous robots. The main function of the CDL is to input geometries of robots and environments for use in simulation. The CDL interacts with the RTI by registering actuated degrees of freedom, as well as as with the PCM to apply surface models to robots and objects within the environment. Descriptions of each section of the CDL are described below.
1. Defining Robots - in the CDL, a robot is defined to be an object which can be controlled via the RLB and RTI.
- 1.1 Geometries - basic methods are used to define the geometry and dynamics of simple objects.
- 1.2 Body Primitives - after defining simple objects, methods can be used to link them together to become body primitives. In early versions of the CDL, each body primitive will be a single rigid object. Support will be later added to add passive compliance within body primitives.
- 1.3 Degrees of Freedom
- 1.3.1 Actuated - actuated links are active links between body primitives. By declaring an actuated link and associated parameters, the RTI can connect to and control that link of the robot. All actuated links must be named and registered with the RTI.
- 1.3.2 Compliant - compliant links are passive links between body primitives. In later versions, they will also exist within body primitives. Compliance can be defined using standard spring/damper models.
- 1.4 Input from File - support will be added so that all of the above characteristics can be defined within a simple text file, read for input when running a simulation.
2. Defining Environments - whereas a robot is a controlled object, environments consist of everything else. While SimSect++ offered only planar surroundings, it will be possible to engineer complex environments using the CDL, such as fractal landscapes climbing walls covered with textured surfaces, and an assortment of various test obstacles.
- 2.1 Shapes - objects within the environment are defined much the same as geometries of robots. They can also be linked together to form complex obstacles. There is no requirement that obstacles be fixed within the environment, so it will be possible to run a robot over a pile of bricks or up a crumbling field of talus.
- 2.2 Surfaces - while the dynamics are the most important part of a robot, surfaces are key to environment objects. Using mathematical models, as defined using the PCM, surfaces can be given special properties for their interactions with the robot.
- 2.3 Extraneous OpenGL - all of the above code defines the environment that the robot interacts with. For purpose of visualization only, support will be added to add superficial graphics to a scene. The sole purpose of this code is to beautify renderings for display purposes.
- 2.4 Input from File - support will be added so that all of the above characteristics can be defined within a simple text file, read for input when running a simulation.
3. Interaction with RTI - the CDL works directly with the RTI to set up the controlled joints. After joints are specified, joint limits and maximum forces/torques can be specified.
4. Interaction with PCM - with the CDL an object may be given the surface properties of predefined surfaces designed through the PCM.
Sample Code: purely theoretical design — I'm still hashing through some ideas and the code structure will probably change dramatically as I get used to the benefits/misgivings of using DE. I want to make sure the CDL does not recode anything that DE provides, and that it also enhances DE in any places it is lacking. Please take this with a grain of salt.
_declaring a simple robot_
// create a new robot. character string is unique identifier
CDL::Creature rise("RiSE");
// coordinates for body mass block, in robot coordinate frame
double vertices[6] = {-0.05,-0.10,-0.05,
0.05, 0.10, 0.05}
// add a block with mass 0.5 kg
rise.addGeometry(CDL_BLOCK, 0.5, vertices);
_building a body primitive, using the PCM_
// define a simple peg leg
CDL::BodyPrim * leg = new CDL::BodyPrim();
CDL::Object * foot;
// simple peg leg, with a sticky ball foot
double rad=0.01, len=0.10, legmass=0.05;
leg->addGeometry(CDL_CYLINDER, legmass, rad,len);
leg->frame.push();
leg->frame.translate(0.0, 0.0, 0.10);
foot = leg->addGeometry(CDL_SPHERE, 0.0, rad); // 0 mass foot
foot->setSurface("GeckoSticky"); // calls the PCM to add "stickiness"
leg->frame.pop();
_connecting body primitives_
// connect legs to body
CDL::Link * l;
CDL::Joint * j;
rise.frame.push();
rise.frame.translate(0.8, 0.42, 0.0); // front right of body
l = rise.connectBodyPrim(leg,"Leg1"); // this copies "leg" so it can be reused
j = l->joint.revolute(CDL_AXIS_X, "Leg1Joint");
rise.frame.translate(-0.8, 0.02, 0.0); // center right of body
l = rise.connectBodyPrim(leg,"Leg2");
... // and so on for all 6 legs
rise.frame.pop();
// declare the joint as active so it can be controlled
extern RTI::Controller controller;
controller.registerJoint(rise,"Leg1Joint");
controller.joint["Leg1Joint"].setMaxTorque(15);
controller.joint["Leg1Joint"].setBound(-M_PI/2, M_PI/2);
--
ClarkHaynes? - 28 Sep 2003