geometry-doc.sgml

机器人开源项目orocos的源代码

   <para>
A 3-by-3 matrix in 3D, and a 2-by-2 matrix in 2D, whose columns are
the coordinates of the <link linkend="vector">unitVector</link>s along
the directions of a <link linkend="frame">Frame</link>, expressed in
the &ldquo;world frame&rdquo;.
   </para>
  </listitem>
 </varlistentry>
 <varlistentry>
 <term>
   <anchor id="euler-angles">
   <parameter>EulerAngles</parameter>
 </term>
  <listitem>
   <para>
EulerAngles are only relevant in 3D. There, they represent a total
rotation as a sequence of three rotations about
<emphasis role="strong">&ldquo;moving axes&rdquo;</emphasis>.
That is, a rotation about one axis, say &ldquo;X&rdquo;, is executed;
this rotation moves the &ldquo;Y&rdquo; and &ldquo;X&rdquo; axes of
the  &ldquo;world frame&rdquo;, so the next rotation is performed
about one of these new &ldquo;Y&rdquo; or &ldquo;Z&rdquo; axes.
Hence, there are <emphasis role="strong">twelve</emphasis> possible
sets of Euler angles: XYX, XYZ, XZX, XZY, YZX, YZX, YXY, YXZ, ZYX,
ZXY, ZXZ, ZYZ.
   </para>
   <para>
In the case that the first or second rotations move the subsequent
rotation axis close to one of the previous rotation axes, the total
rotation is represented by components about two almost parallel axes,
and this is
<emphasis role="strong">numerically badly conditioned</emphasis>. The
conditioning is even absolutely bad (<emphasis>i.e.</emphasis> a 
<emphasis role="strong">singularity</emphasis> occurs) if two axes
coincide.
   </para>
  </listitem>
 </varlistentry>
 <varlistentry>
 <term><parameter>RollPitchYaw</parameter></term>
  <listitem>
   <para>
Rotations about <emphasis role="strong">fixed</emphasis> axes, in the
sequence &ldquo;X&rdquo;, &ldquo;Y&rdquo; and &ldquo;Z&rdquo;.
   </para>
   <para>
In principle, there are also twelve possible rotations about fixed
axes, but only <parameter>RollPitchYaw</parameter> is commonly used.
It is very well conditioned numerically as long as the rotation angles
are &ldquo;small&rdquo;, <emphasis>i.e.</emphasis> much less than 90
degrees, because in that case two subsequent rotation directions line
up.
   </para>
  </listitem>
 </varlistentry>
 <varlistentry>
 <term>
  <anchor id="equivalent-angle-axis">
  <parameter>angleAxis</parameter>
  </term>
  <listitem>
   <para>
The rotation is represented by representing the axis of the rotation
(<emphasis>i.e.</emphasis> a directed
<link linkend="line">Line</link>) and the angle (one scalar).
   </para>
  </listitem>
 </varlistentry>
 <varlistentry>
 <term>
  <anchor id="quaternion">
  <parameter>quaternion</parameter>
  </term>
  <listitem>
   <para>
A four-parameter representation, which is the smallest one that
doesn't have representation singularities. Its
&ldquo;disadvantage&rdquo; is that it is <emphasis>double
covering</emphasis>: each rotation has two different coordinates.
   </para>
  </listitem>
 </varlistentry>
 <varlistentry>
 <term>
  <anchor id="rotation-matrix-multiplication">
  <parameter>multiplication</parameter>
  </term>
  <listitem>
   <para>
Composition of rotations corresponds to multiplication of two rotation
matrices. For Euler angles, composition is a bit more involved, and
multiplication or addition of the numerical values has no meaning. 
   </para>
  </listitem>
 </varlistentry>
</variablelist>
</para>

</section>


<section id="displacement">
<title>Displacement</title>
<para>
Consider the same rigid body in two different configurations, but, in
contrast to the <link linkend="rotation">Rotation</link> case, no
point connected to the body
must remain in the same position in space. One can prove that there
exists a <link linkend="line">Line</link>
such that the body can be moved from its first configuration to its
second configuration, by a <emphasis role="strong">rotation
about that line, and a translation along that line</emphasis>.
Hence, this displacement can be <emphasis>represented</emphasis> by a
<link linkend="screw">Screw</link>.
</para>
<para>
A Displacement can be given the same active and a passive meanings
as for a <link linkend="rotation">Rotation</link>.
So, the following properties are required to define a Displacement:
</para>
<variablelist>
<title>Symbolic property</title>
 <varlistentry>
 <term><parameter>active</parameter>, <parameter>passive</parameter></term>
  <listitem>
   <para>
Only in the case of a <parameter>passive</parameter> Displacement, the
generic <link linkend="symbolic-class">symbolic information</link>
about the <link linkend="geometric-port">geometric Port</link> to
the reference <link linkend="frame">frame</link> is relevant.
   </para>
  </listitem>
 </varlistentry>
</variablelist>
<variablelist>
<title>Physical properties</title>
 <varlistentry>
 <term><parameter>inversion</parameter></term>
  <listitem>
   <para>
The inversion of a given Displacement is another Displacement. The
screw axis is the same, the rotation angle about the line and
displacement along the line are the inverse of the original values.
Or, equivalently, the Screw is reversed.
   </para>
  </listitem>
 </varlistentry>
 <varlistentry>
 <term>
  <anchor id="displacement-composition">
  <parameter>composition</parameter>
  </term>
  <listitem>
   <para>
The composition of two Displacements is another Displacement, and
again it is a
<emphasis role="strong">multiplicative</emphasis> operation, and 
<emphasis role="strong">not additive</emphasis>.
   </para>
  </listitem>
 </varlistentry>
</variablelist>
<para>
Many different
<emphasis role="strong">coordinate respresentations</emphasis> exist
for Displacements: one combines the different representations of a
<link linkend="rotation">Rotation</link> with that of a 
<link linkend="point">Point</link>. The 
<link linkend="htmatrix">Homogeneous Transformation Matrix</link>
representation has a unique place, because it faithfully represents
the multiplicative property of Displacement composition,
<emphasis>and</emphasis> the representation has no numerical
singularities.
</para>

</section>

</section> <!-- geometric-primitives -->


<section id="geometric-database">
<title>Geometric database and engine</title>
<para>
Complex and dynamic applications need more than just the
symbolical and numerical information contained in the geometric
classes of the previous sections:
<itemizedlist>

<listitem>
<para>
<emphasis role="strong">Topology.</emphasis> The topological
information of the geometric objects involved in an application
describes how the objects are
<emphasis role="strong">interconnected</emphasis>. This
interconnection information is, in general, a
<emphasis>graph</emphasis>, but most real-world constructions have
more specific structures: serial, parallel, tree-like, etc.
</para>
<para>
Every interconnection information implies a set of 
<emphasis role="strong">constraints</emphasis> between the coordinates
of the objects involved in the interconnection. A constraint can
sometimes be a source of more complex calculations (because one has to
take into account the influence of the constraints when moving an
object), but sometimes it also allows for more efficient calculations
(<emphasis>e.g.</emphasis> most robot structures have efficient
routines to calculate their forward and/or inverse kinematics).
</para>
<para>
The topological structure of one single robot or animated figure is
sometimes called a <emphasis role="strong">skeleton</emphasis> or
<emphasis role="strong">armature</emphasis>. The
&ldquo;connection&rdquo; of all objects to the
&ldquo;(fixed) world&rdquo; is called the
<emphasis role="strong">scene (graph)</emphasis>.
In graphical user interfaces, properties of the objects in the
scene can be browsed or changed via a graph-like interface, in which
each node contains the information of one geometric primitive in the
scene.
</para>
</listitem>

<listitem>
<para>
<emphasis role="strong">Relative feature relationships.</emphasis>
The topogical structure is used to keep track of the coordinates of
all geometric primitives, whenever one or more objects are moved in the
scene. Users of an application are typically interested in knowing
the relative position and/or motion of two or more system
<emphasis>features</emphasis>, <emphasis>i.e.</emphasis> particular
parts of the geometric primitives that are relevant to the currently
executed task.
</para>
<para>
The geometric database should also allow
<emphasis role="strong">scripting</emphasis> and
<emphasis role="strong">programming</emphasis>,
<emphasis>i.e.</emphasis> user-defined functions that calculate
on-line the feature relationships that users are interested in. For
example, a function to find the closest points on two object surfaces;
or a function to calculate the distance between points on the
end-effector of two different robots.
</para>
<para>
The combination of the <emphasis>geometric data</emphasis>
(topological and numerical), the
<emphasis>scripting functions</emphasis> defined on tha data, and the
corresponding (graphical) user interface, is 
called a <emphasis role="strong">geometric engine</emphasis>.
</para>
</listitem>

<listitem>
<para>
<emphasis role="strong">Non-geometric properties.</emphasis>
The geometric database is important to calculate the kinematic
information in the system, but often an application also needs 
other information:
 <itemizedlist>
 <listitem>
 <para>
 <emphasis role="strong">Visualisation</emphasis>: What is
the shape of each object? Its texture? Its color? All this
&ldquo;flesh&rdquo; around the skeleton is to be stored independently.
Applying the &ldquo;flesh&rdquo; is sometimes called
<emphasis role="strong">rigging</emphasis>.
 </para>
 </listitem>
 <listitem>
 <para>
 <emphasis role="strong">Input/Output</emphasis>: What process
provides the data to move an object or a skeleton? What process
collects the latest information on the object (for on-line or off-line
&ldquo;reporting&rdquo; and &ldquo;monitoring&rdquo;)?
 </para>
 </listitem>
 </itemizedlist>
</para>
</listitem>

</itemizedlist>
The connections between all the different kinds of object information
described above can be implemented with the
<ulink url="decoupling.html#INTER-CONNECTION-DECOUPLING">Object-Port-Connector</ulink>
software pattern, in order to provide maximal decoupling.  This
pattern leads naturally to a <emphasis role="strong">graph</emphasis>
data structure for the geometric database: 
<itemizedlist>

<listitem>
<para>
Each geometric primitive is a <emphasis role="strong">node</emphasis>
in the graph.
</para>
</listitem>

<listitem>
<para>
The graph's <emphasis role="strong">edges</emphasis> represent topological connectivity.
</para>
</listitem>

<listitem>
<para>
Each node has its own physical and numerical
<emphasis role="strong">properties</emphasis>.
</para>
</listitem>

<listitem>
<para>
The overall graph has (a hierarchy of)
<emphasis role="strong">sub-graphs</emphasis> that represent 
<ulink url="kindyn-doc.html#KINEMATIC-CHAIN-INTERFACE">kinematic chains</ulink>,
constraints or feature relationships.
</para>
</listitem>
                                                                                
</itemizedlist>
</para>

</section> 


<section id="implementation-issues">
<title>Implementation issues</title>
<para>
There are a couple of important decisions that must be taken by the
library implementors:
<itemizedlist>

<listitem>
<para>
<emphasis role="strong">Namespaces</emphasis>: most of the data
structures and method calls are valid in 1D, 2D and 3D spaces. Hence,
the introduction of corresponding namespaces can make the programming
easier, because the (most often) redundant space dimension information
need not be included in the method and data structure names.
</para>
</listitem>

<listitem>
<para>
<emphasis role="strong">Alternative representations</emphasis>: most
physical properties can be mathematically represented in more than one
way. Hence, in principle one should provide all method calls in
different forms, where each form uses another representation. For
example, the
<link linkend="frame-move-method"><function>move</function></link>
method to displace a <link linkend="frame">Frame</link> could take an
<link linkend="htmatrix">homogeneousTransformationMatrix</link> as
argument, or a <link linkend="vector">Vector</link> together with a
set of <link linkend="euler-angles">EulerAngles</link> or a
<link linkend="quaternion">quaternion</link>.
</para>
<para>
This problem of alternative argument lists could be solved by
<emphasis role="strong">overloading</emphasis>.
</para>
</listitem>

<listitem>
<para>
<emphasis role="strong">Alternative algorithms</emphasis>: many
method calls can be implemented in more than one way, and the user can
often want to be able to explicitly choose which algorithm is used.
</para>
<para>
This problem of alternative argument lists could be solved by the
<emphasis role="strong">strategy software pattern</emphasis>: the same
method call is <emphasis role="strong">configured</emphasis> to use a
particular algorithm at run-time.
</para>
</listitem>

</itemizedlist>
</para>

</section>


</article>