BROS-II standard: draft proposal 29 AUG 2004

Here is the BROS-II draft.

Herman
-- 
   K.U.Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.ac.be/~bruyninc> Tel: +32 16 322480
===================================================================

BROS-II  --- Basic Robotics Standards, Level 2
Interconnected robotics objects, with meta-information.
Herman Bruyninckx, 28 AUG 2004

This document is released in the public domain. The presented standards can
be used without any restriction, except that the names "BROS" and "Basic
Robotics Standards" can only be used to refer to the material in this
and related documents, and in later versions thereof.

Introduction
------------
Many objects in robotics consists of a collection of primitives from
BROS-I, with meta-information that identifies the object, and that
explains how to interpret the numerical data. For example, their
coordinates are expressed with respect to a particular frame, and they are
the coordinates of a particular object; or they have multiple possible
mathematical representations, and the meta information says which one is
used.

This level of the standard also uses meta-information to encode the
identity of objects, by means of a "string". Meta-information must be
interpreted before the numerical information in the object can be used; the
interpretation of the numerical information can depend on the content of
the meta-information.

Meta-information fits well in "file-based" data exchange (e.g., XML), but
it also allows "realtime" exchange provided that the meta-information is
first exchanged and interpreted in "non-realtime" mode, and then the
numerical data is exchanged and interpreted, possibly in "streaming mode"
(i.e., without interpretation and in continuous mode without a setup cost
for each exchange) in order to improve latency and/or bandwidth.

Most objects in this level of the standard are "composite": they consist of
the interconnection of multiple lower- or same-level objects. The
interconnection is encoded via the Object-Port-Connector pattern: each
object has a number of Ports, and Ports of the same type can be connected;
all the information about the connection is stored in a Connector object,
and not in one of the connected objects. (Which would lead to duplicated or
non-symmetric storage of the information about the interconnection.)

To Be Discussed:
The number and content of the objects to be included in this level of the
standard. In other words, everyhting :-)

Definitions
-----------

RigidBody:
  attributes:
   id: string
  properties:
   list of Ports:
    - Pose of the Port: defines where on the body the connection can be made
    - type of the Port:
       Mass: to attach inertia information.
       Shape: to attach geometrical form information.
       Feature: to indicate a geometric feature on the RigidBody.
       RigidBody: to connect to another RigidBody with a rigid connection.
       Sensor: to connect a sensor.
       MechanicalConstraint: to attach a motion constraint, such as a joint.
       Device: to connect to the Device the RigidBody belongs to.
   state:
       X: Pose of the body
      dX: Twist of the body
     ddX: AccelerationTwist of the body
       F: wrench on the body

MechanicalConstraint: Connector connecting two compatible Ports
  attributes:
   id: string
   dim: 1, 2, 3, 4, 5
   type:
     revolute, prismatic, helical, stiffness, damping, inertia, compliance,
     inversedamping, mobility, ground, ...
   constitutive relationship: F(states of connected RigidBodies)=0.
     e.g., stiffness matrix or function, damping matrix or function.
  properties:
   state:
       q: "position" in the constraint (has "dim" parameters)
      dq: velocity of constraint parameters
     ddq: acceleration of constraint parameters
       f: force in the constraint
   list of the Ports (of type RigidBody) the constraint is connected to.


FeatureConstraint: Connector connecting two Features; the interconnection
   is not physical, but represents a desired relative "motion" of Features on
   two or more RigidBodies.
  attributes:
   id: string
   dim: 1, 2, 3, 4, 5
   type:
     distance, orientation, relative desired motion, ...
   list of ports (of type Feature)
   constitutive relationship: F(features on connected objects)=0.
  properties:
   state:
       q: "position" in the constraint (has "dim" parameters)
      dq: velocity of constraint parameters
     ddq: acceleration of constraint parameters
       f: "force" in the constraint
   list of the Ports (of type RigidBody) the constraint is connected to.


JointPositions:
  attributes:
   id: string
   dim: number of joints
   type of each joint:
     revolute, prismatic, helical, gimbal, spherical, ...
  properties:
   q: vector of floats, representing the positions of all joints
 	  The order as well as the number of values in the vector depends on the
      kinematic chain definitions.
      Problem: how to represent multi-dimensional joints such as gimbals or
        spherical joints?
Similar definitions for JointVelocities, JointAccelerations, JointForces.

Device: connection of bodies and joints.
  attributes:
   id: string
   type: string. Indicates the family to which this device belongs; e.g.,
     6RSerial, DifferentiallyDriven, etc.
  properties:
   list of RigidBodies and Connectors. The order in the list is relevant,
     and has to be standardized in some way...
   root: pointer to the RigidBody or Connector which is to be considered as
     root of the Device's kinematic chain. Can be "NIL".
   list of tools: list of Features on the Device's RigidBodies that belong
     to the exported interface of the Device; i.e., tasks for the Device
     can make use of these Features.

World:
  attributes:
   id: string
  properties:
   list of Devices. The order is not relevant.



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click