|
An Abdula graph |
version 1.0
Francois Faure, 1999
Abdula is a C++ software library for the simulation of articulated solids. It has been developed within the European PAVR project. It has been designed to be used as a stand-alone program as well a part of a bigger application.
The current distribution includes:
Currently, Abdula's most interesting features are:
The limitations are:
You need 30 Mb disk space.
Two example programs are provided.
Abdula allows you to model and simulate scenes including articulated solids. A scene is modeled using a graph (see figure below). The graph can include different kinds of objects:
|
An Abdula graph |
Declarations in solid.h
A solid is a moving coordinate system with mass and velocity. Its position and velocity are defined with respect to the inertial frame (the ground).
Position is recursively set through parent joints. A solid has necessarily a (possibly unconstrained) joint on top of it.
Velocity is defined in the ground coordinate system.
The mass center is assumed to be at the origin, and the main inertia axes aligned with the axes of the local coordinate system. The mass is thus fully modeled using four values: mass, Ixx, Iyy, Izz.
Contact surfaces can be recursively attached to a solid. At each time step, collisions between solids are checked and contact joints modeled if necessary.
Declarations in joint.h
A joint binds a solid to antoher solid or to the ground. Joints are modeled using two coodinate systems, each of them attached to one solid, as illustrated in figure below. Constraints act between these two coordinate systems. A constraint enforces a null relative motion along a given direction. Six independent directions can be used: translations along i,j,k and rotations along i,j,k. Various combinations can be used to model joints. For example, the constraints associated with a PointJoint (a point attached to another point) are ti,tj,tk. The constraints associated with a pin joint (one rotation allowed) with axis i are ti,tj,tk,rj,rk.
The parameters transP, rotP, and transC, rotC are used to model the position of the joint with respect to the parent and the child.
 |
Geometric parameters of an Abdula joint. |
Velocity is defined along the axes of the coordinate system attached to the parent solid.
A variety of joints is defined in Abdula. Deriving new joints is straightforward (see joint.h). A special kind of joint is ContactJoint. It acts between two ContactSurfaces and prevents them from interpenetrating.
Declarations in contact.h
ContactSurfaces define volumes which can not intersect with each other, except if they belong to the same solid. Currently, three basic contact surfaces are implemented: ContactSphere (volume inside), ContactSphereExt (volume outside) and ContactPlane (bounded plane with normal along x, volume below).
A ContactSurface can be added to another. This defines a hierarchy which can speed up the collision detection process (see ProximityCheck). The base class ContactSurface has no shape, but it can be used to gather surfaces within a common bounding box.
Examples:
Declarations in force.h
Forces define "soft constraints" which act on one solid (UnaryForce), on a pair of solids (BinaryForce) or within a joint (JointForce). Constant, elastic and viscous forces are supported.
Examples:
Declarations in articulatedGroup.h
ArticulatedGoup is responsible for animating the objects. It basically handles constraint solution, time integration, and collision detection/modeling.
Moreover, it includes some global physical parameters such as gravity or air damping.
Constraint solution consists in enforcing the constraints associated with the joints. Since dynamics is a second-degree process, there a three levels at which the constraints can be enforced:
Acceleration and velocity are associated with linear equation systems. Constraints on positions are associated with a nonlinear equation system, which is solved iteratively using a series of linear equation systems (Newton algorithm).
Constraints in acyclic articulated bodies are solved in linear time. On top of this process, closed loop constraints are handled by a conjugate gradient (CG) iterative algorithm. The CG stops as soon as one of the following criteria is met:
This results in a tunable trade-off between accuracy and computation speed. An additional parameter limits the number of iterations within the Newton algorithm used to enforce position constraints.
As explained before, low accuracy results in "wrong" integrated values. Physical quantities such as energy and momentum are conserved, but the positions may not meet the constraints. This drift due to low accuracy is controlled the same way as the drift due to numerical integration (see section Time integration).
A variety of integration schemes is provided, ranging from Euler to fifth-order adaptive Runge-Kutta. Moreover, time integration can be performed on maximal coordinates (solid coordinates) or generalized coordinates (joint coordinates). Generalized coordinates avoid constraint drift within acyclic bodies. However, drift still appears within closed loops, and the simulation might be less physically accurate.
Drift is a generally unavoidable artifact due to numerical integration. Two initially connected solids would progressively drift apart from each other. Abdula provides the user with two ways of maintaining this drift within acceptable values:
Collision detection is performed at the end of each integration step. Pairs of possibly colliding surfaces are computed by the ProximityCheck, then tested more precisely. When two surfaces interpenetrate, a ContactJoint is created, and the associated constraint error is computed. The geometric constraint solution algorithm is then applied. However, this may result in new collisions, and so on. A parameter is used to limit the number of collision propagations.
Contact joints are automatically deleted when necessary.
Declarations in contact.h
Since intersection computation can be quite expensive, a ProximityCheck object is used to filter out pairs of surfaces whose bounding boxes do not intersect. When called using the getPairs() method, it returns a list of pairs of possibly colliding surfaces.
Currently, only one kind of ProximityCheck is implemented, called DummyCheck. Basically, it tests all pairs of bounding boxes. However, it makes use of hierarchical bounding boxes. Lower level bounding boxes are considered only if their upper-level bounding boxes do collide.
Declarations in abBase.h
Base class for all Abdula nodes. The method view() can be used to specify additional non-physical data which can be used by a viewer. The method useView() can be used to specify which other node's view should be used, in order to avoid unnecessary replication.
Declarations: parser.h (input), *.h (output)
Abdula can read from and write to VRML-like scripts (see the .abd files). Complex scripts including loops or test must be written in C++.
Declarations in abdula2iv.h
The inventor interface library is used to generate an Inventor subgraph out of a given ArticulatedGroup, and to update its numerical values. Currently, it does not support in-the-fly insertion and deletion of new Abdula nodes. The root of the Inventor subgraph is either an IvArticulatedGroupTree or an IvArticulatedGroupFlat. The former uses joint coordinates to recursively update solid positions. The latter directly uses world coordinates.
Abdula can be freely used for non-commercial purposes. Otherwise, contact the author.
Francois Faure, last update 05/08/1999. Send bug reports, comments and suggestions to francois@cg.tuwien.ac.at.
