</para><para>The iterative algorithms require extra specification in their methodcalls. Or, alternatively, they require a richerconfiguration API than the families with closed-form kinematics:<itemizedlist><listitem><para><emphasis role="strong">Initial position</emphasis>. This inevitablyis an initial <emphasis>joint space</emphasis> position, because aninitial Cartesian position is useless, since that's exactly theproblem one has to solve.</para></listitem><listitem><para><emphasis role="strong">Iteration method</emphasis>. Various iterationmethods exist.</para></listitem><listitem><para><emphasis role="strong">Iteration termination condition</emphasis>.Can be <emphasis>accuracy</emphasis> (stop when the differencesbetween subsequent iterations fall below a specified threshold), <emphasis>time</emphasis> (stop after a specified time interval haspassed), or <emphasis>iteration steps</emphasis> (stop after aspecified number of iterations).</para></listitem></itemizedlist></para></section></section><section id="architectures"><title> Kinematic families</title><para>An &ldquo;kinematic family&rdquo; (or, &ldquo;architecture&rdquo;)is a class that represents the common properties of a set of<emphasis>&ldquo;kinematic chains&rdquo;</emphasis> (robots andmachine tools). Each member of the set has the same geometricstructure, and this structure is such that it allows for<emphasis>ad hoc</emphasis> efficient and parameterizedimplementations of the kinematic and dynamic class interfacesdiscussed in the previous Sections.So, the <emphasis>interfaces</emphasis> described in the previousSections are the same for all families, but the<emphasis>implementations</emphasis> differ from family to family.</para><para>(The general kinematic chains, that lack such special geometricstructure, are treated in more detail in<ulink url="general-dynamics-doc.html">another document</ulink>.)</para><para>For example, most industrial robots have six revolute joints, of whichthree have axes that are intersecting in one point (forming a&ldquo;wrist&rdquo;), and two others have parallel axes. A second verypopular type of industrial robots with a serial topology are the<emphasis>SCARA</emphasis> robots, that have three subsequent parallelaxes.  And most machine tools have orthogonal translational axes.</para><para>The software entities in every kinematic family are of the followingthree complementary types:<itemizedlist><listitem><para><emphasis role="strong">Connectivity information:</emphasis> the parameterized representation of how the different rigid bodies,joints and reference frames of the architecture are inter-connected.In fact, this connectivity information <emphasis>defines</emphasis>the family.</para></listitem><listitem><para><emphasis role="strong">Device data:</emphasis> this is the object thatcontains numeric values for the above-mentioned parameters, and assuch represents one specific member of the family. For example, thegeometric and dynamic parameters of the KUKA KR 500, including jointlimits, encoder resolutions, motor inertias, etc.</para></listitem><listitem><para><emphasis role="strong">Interface implementations:</emphasis> theimplementations of the interfaces of the previous Sections,optimized for each particular architecture.</para></listitem></itemizedlist>The former two are encoded in family-specific internal datastructures. Of course, it would be useful to come up with somestandardized way of storing and processing this information.</para><para>The following subsections describe the particular properties of someof the most popular <emphasis>kinematic families</emphasis>. Differentkinematic chains are assembled in the same family, because thereexists a systematic, parameterized and efficient(<emphasis>ad hoc</emphasis>) method to represent all the kinematicchains of the family.</para><section id="kinematicserial"><title>KinematicSerial</title><para>This family has already been fully described by<xref linkend="fig-opc-link-joint"> and the accompanying discussion.The <parameter>KinematicSerial</parameter> family has very efficient<emphasis>numerical</emphasis> kinematics routines (i.e., with acomputational complexity that is linear in thenumber of joints), because it contains no loops; some serialarchitectures (see below) have even more efficient, analytic(&ldquo;closed-form&rdquo;) algorithms.</para></section><section id="kinematictree"><title>KinematicTree</title><para>An inter-connection of<link linkend="kinematicserial">KinematicSerial</link> structure, insuch a way that all joint axes are topologically inter-connected in a<emphasis>tree</emphasis>. (See <xref linkend="fig-tree-opc">.)Efficient numerical algorithms (linear in the number of joints) areknown for these architectures, but no analytical solutions. Theincrease in complexity with respect tothe serial case is twofold: (i) more complicated<emphasis>bookkeeping</emphasis> (the index of joints in a jointcoordinate vector doesn't indicate where the joint is located in thechain); and (ii) the <emphasis>dynamics</emphasis> involve couplingsbetween the different branches of the chain.<figure id="fig-tree-opc" float="1" pgwide="0"><title> A KinematicTree kinematic chain.</title><mediaobject><imageobject><imagedata fileref="../pictures/tree-opc.png" format="PNG"></imageobject><imageobject><imagedata fileref="../pictures/tree-opc.eps" format="EPS"></imageobject></mediaobject></figure></para></section><section id="kinematicgraph"><title>KinematicGraph</title><para>The most general kinematic structure: any sort of joints, at anyrelative positions and orientations, and with any topologicalinter-connections, including &ldquo;loops&rdquo;.(See <xref linkend="fig-graph-opc">.)These architectures require <emphasis>iterative</emphasis> numericalsolution algorithms, which are in general much less efficient than thelinear-time algorithms for serial and tree-structured chains. The needfor iteration arises from the existence of <emphasis>loops</emphasis>in the kinematic chain.<figure id="fig-graph-opc" float="1" pgwide="0"><title> A KinematicGraph kinematic chain.</title><mediaobject><imageobject><imagedata fileref="../pictures/graph-opc.png" format="PNG"></imageobject><imageobject><imagedata fileref="../graph-opc.eps" format="EPS"></imageobject></mediaobject></figure></para></section><section id="serial321"><title>Serial321</title><para>This is a <link linkend="kinematicserial">KinematicSerial</link>architecture with six <emphasis>revolute</emphasis> joints: a&ldquo;wrist&rdquo; with <emphasis>three</emphasis> revolute jointswith intersecting axes; an &ldquo;arm&rdquo; with<emphasis>two</emphasis> parallel axes; and a &ldquo;shoulder&rdquo;with <emphasis>one</emphasis> revolute joint whose axis is orthogonalto the axes of the &ldquo;arm&rdquo; set.<xref linkend="fig-serial321"> depicts a Serial321 kinematic chain, withan appropriate choice of reference frames that allows for intuitiveand efficient numeric kinematics equations.<figure id="fig-serial321" float="1" pgwide="0"><title> A Serial321 kinematic chain.</title><mediaobject><imageobject><imagedata fileref="../pictures/serial321.png" format="PNG"></imageobject><imageobject><imagedata fileref="../pictures/serial321.eps" format="EPS"></imageobject></mediaobject></figure></para><para>This is the architecture of most 6D industrial robots. And this is nocoincidence: this particular structure allows the <emphasis>most efficient</emphasis> implementations, it has its<emphasis>singularities</emphasis> at easily recognizable jointpositions, and it has eight easily recognizable<emphasis>configurations</emphasis> (i.e., different sets of jointangles that reach the same end-effector pose).</para><para>In order to specify an unambiguous API for this kinematic family, thefollowing (arbitrary!) conventions have to be documented:<itemizedlist><listitem><para><emphasis role="strong">Zero position.</emphasis><xref linkend="fig-serial321"> depicts the arm in its&ldquo;zero position&rdquo;, i.e., the position where all joint anglesare zero.</para><para>Most real robots with the Serial321 architecture will have theirposition sensor zero readings at a different position, such that anadaptation from real joint angles to modelled joint angles must beprovided.</para></listitem><listitem><para><emphasis role="strong">Frame placement.</emphasis>The positions of the frames on the arm are as in<xref linkend="fig-serial321">. There is a frame attached to each<emphasis>link</emphasis>, at the place where the joint towards the<emphasis>next</emphasis> link is attached. In addition, there is aframe attached to the fixed base, and to the end-effector (i.e., thelast link).In the zero position, all these frames are parallel, with their Z axespointing vertically upwards, and their Y axes pointing&ldquo;forward&rdquo;. That means that the joint axes lie either alongthe X axes or the Z axes of the frames.</para></listitem><listitem><para><emphasis role="strong">Base frames.</emphasis>The &ldquo;base frames&rdquo; are the frame attached at the firstjoint, and the frame attached to the fixed world. Both can bearbitrarily placed. The convention is to translate them over a givendistance with respect to the frame of link 1 (i.e., the frameindicated with the subscripts &ldquo;2&rdquo; in<xref linkend="fig-serial321">. </para></listitem><listitem><para><emphasis role="strong">End-effector frame.</emphasis>A similar reasoning holds for the frame attached to the end-effector:it is translated over a distance l<subscript>6</subscript> withrespect to the last link frame.</para></listitem><listitem><para><emphasis role="strong">Joint angle references.</emphasis>The positive direction of all joint angles is shown on<xref linkend="fig-serial321">. </para></listitem><listitem><para><emphasis role="strong">Configuration definitions.</emphasis>The Serial321 family has <emphasis>eight</emphasis> differentconfigurations, four of which are shown in<xref linkend="fig-serial321-configs">: two are caused by thedifference between <emphasis role="strong">forward</emphasis> (wristcentre point lies in the positive Y half-plane of the base frame), or<emphasis role="strong">backward</emphasis>; the two other are caused by<emphasis role="strong">elbow-up</emphasis> or<emphasis role="strong">elbow-down</emphasis> (i.e., joint 3 ispositive, respectively negative). The wrist causes two configurationstoo: <emphasis role="strong">flip</emphasis> or<emphasis role="strong">no-flip</emphasis> (i.e., joint 5 is positive,respectively negative). (Note that the total number of configurationsis the <emphasis>product</emphasis> of the binary configurationoptions mentioned above, i.e., eight is 2&times;2&times;2.)</para></listitem></itemizedlist></para><para><figure id="fig-serial321-configs" float="1" pgwide="0"><title> Four configurations of the Serial321 kinematic chain. (The twoconfigurations due to the wrist are not shown, because the differencebetween both would be hardly visible on this scale of image.)</title><mediaobject><imageobject><imagedata fileref="../pictures/serial321-configs.png" format="PNG"></imageobject><imageobject><imagedata fileref="../pictures/serial321-configs.eps" format="EPS"></imageobject></mediaobject></figure></para><para>There a various variations in this architecture, with basicallythe same geometry, but with the following differences:<itemizedlist><listitem><para><emphasis role="strong">Shoulder offset.</emphasis>The part of the arm from link 3 on is offset a bit along theX<superscript>2</superscript> axis of <xref linkend="fig-serial321">. </para></listitem>                                                                                <listitem><para><emphasis role="strong">Base-joint offset.</emphasis>The part of the arm from link 2 on is offset a bit along theY<superscript>1</superscript> axis of <xref linkend="fig-serial321">. </para></listitem>                                                                                <listitem><para><emphasis role="strong">Forearm eccentricity.</emphasis>The part of the arm from link 4 on is offset a bit along theY<superscript>3</superscript> axis of <xref linkend="fig-serial321">. </para></listitem>                                                                                </itemizedlist></para><para>With all the family-specific definitions and conventions presentedabove, one can specify the full kinematics and dynamics API for thisfamily: &hellip;</para></section><section id="scara"><title>Scara</title><para>This architecture has <emphasis>three</emphasis> revolute axes, withparallel, vertical joint directions; and a fourth, prismatic joint,whose axis coincides with the last revolute joint axis. </para><para>This is the architecture of most 3D industrial&ldquo;pick-and-place&rdquo; robots. </para></section><section id="serial6joints"><title>Serial6Joints</title><para>A serial architecture with six revolute joints, placed in arbitraryrelative positions and orientations.</para><para>This architecture doesn't have any closed-form efficiencies, butits members do all share common numeric algorithms.</para></section><section id="serial7Rshoulder"><title>Serial7RShoulder </title><para>This architecture is like the<link linkend="serial321">Serial321</link> architecture, but it has anextra (&ldquo;redundant&rdquo;) revolute joint, at the&ldquo;elbow&rdquo; of the Serial321 arm(<xref linkend="fig-serial7Rshoulder">).<figure id="fig-serial7Rshoulder" float="1" pgwide