motion-api.sgml

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

<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V4.1//EN"
	"docbook/dtd/4.1/docbook.dtd" [
<!ENTITY orocos "<acronym>Orocos</acronym>">
]>

<article>

<articleinfo>
  <title>
   Motion API
  </title>
  <author>
    <firstname>Herman</firstname>
    <surname>Bruyninckx</surname>
    <affiliation>
      <address>
        Herman.Bruyninckx(at)mech.kuleuven.ac.be
      </address>
    </affiliation>
  </author>
  <author>
    <firstname>Johan</firstname>
    <surname>Rutgeerts</surname>
    <affiliation>
      <address>
        Johan.Rutgeerts(at)mech.kuleuven.ac.be
      </address>
    </affiliation>
  </author>
  <author>
    <firstname>Wim</firstname>
    <surname>Meeussen</surname>
    <affiliation>
      <address>
        Wim.Meeussen(at)mech.kuleuven.ac.be
      </address>
    </affiliation>
  </author>
 <copyright>
  <year>2003&ndash;2004</year>
  <holder>Herman Bruyninckx &mdash;
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU General Public License
(<ulink
 url="http://www.fsf.org/copyleft/gpl.html">http://www.fsf.org/copyleft/gpl.html</ulink>), 
where the <emphasis>source code</emphasis> of the document is the 
<ulink url="motion-api.xml">XML file</ulink>.  </holder>
 </copyright>

 <abstract>
 <para>
 <emphasis role="strong">Abstract</emphasis>
 </para>
 <para>
This document describes the
<ulink url="deep-shallow-api.html">application programming interface</ulink>
(&ldquo;API&rdquo;) for the
<emphasis role="strong">motion specification</emphasis> of
one single rigid body, and of &ldquo;motion devices&rdquo; driven by
<ulink url="kindyn-doc.html">kinematic chains</ulink>,
<emphasis>i.e.</emphasis> robots and machine tools.
The motion API contains the instructions that program a
motion controller to move the rigid body or the device's tool from point
&ldquo;<emphasis>A</emphasis>&rdquo; to point
&ldquo;<emphasis>B</emphasis>&rdquo;.
In addition, the API includes specifications for motions that are
generated on-line via sensor inputs; for example, force- or
distance-controlled &ldquo;compliant motion&rdquo;, visual servoing,
potential-field based motion, etc.
 </para>
 <para>
<ulink url="interpolation-api.html">Another document</ulink> discusses
the basic algorithms and the corresponding API for motion
<emphasis>interpolation</emphasis>.
(A forthcoming document will discuss how the specified motions can be
<emphasis>controlled</emphasis>.)
 </para>
 </abstract>

 <revhistory>
  <revision>
   <revnumber>0.01</revnumber>
   <date>May 24, 2003</date>
   <authorinitials>HB, JR, WM</authorinitials>
  </revision>
  <revision>
   <revnumber>0.02</revnumber>
   <date>July 22, 2003</date>
   <authorinitials>HB</authorinitials>
   <revremark>
   </revremark> 
  </revision>
  <revision>
   <revnumber>0.03</revnumber>
   <date>August 10, 2003</date>
   <authorinitials>HB</authorinitials>
   <revremark>
Heavily reworked. Put more structure and content in the motion
planning and motion interpolation sections.
   </revremark> 
  </revision>
  <revision>
   <revnumber>0.04</revnumber>
   <date>August 21, 2003</date>
   <authorinitials>HB</authorinitials>
   <revremark>
Added more details for trapezoidal acceleration interpolator, and for
the interpolator API.
   </revremark> 
  </revision>
  <revision>
   <revnumber>0.05</revnumber>
   <date>August 26, 2003</date>
   <authorinitials>HB</authorinitials>
   <revremark>
Started to incorporate figures and code for some interpolators.
   </revremark> 
  </revision>
  <revision>
   <revnumber>0.06</revnumber>
   <date>April 19, 2004</date>
   <authorinitials>HB</authorinitials>
   <revremark>
Exported the material in interpolation to a
<ulink url="interpolation-api.html">separate document</ulink>.
Added 
<link linkend="synchronized-path"><parameter>SynchronizedPath</parameter></link>,
<link linkend="motion-task"><parameter>MotionTask</parameter></link>.
Extended the data, execution and configuration flow discussion.
   </revremark> 
  </revision>
 </revhistory>

</articleinfo>

<section id="overview">
<title>What is &ldquo;motion&rdquo;?</title>
<para>
Robots and machine tools are basically <emphasis>motion
devices</emphasis>: they have
several motors with which their wheels, sliders and/or joints can be
moved, and the goal of these motor motions is to position one or more
of the device's &ldquo;<emphasis role="strong">tools</emphasis>&rdquo;
(or &ldquo;<emphasis role="strong">end effectors</emphasis>&rdquo;) 
in a prescribed way in the environment. This text is about a
programming interface to instruct the device to
perform a desired motion, or a set of subsequent motions, for one or
more of its tools.  These tools can be
attached in various places on the device's body, and need not
necessarily <emphasis>act</emphasis> on the environment: they can also
be sensors, or interface apparatus (speaker, screen, animated face,
&hellip;) to interact with people.
</para>
<para>
In the simplest case, the specification of a desired motion need not take
into account on which machine the motion will be executed. But, in
general, the following aspects of the device do 
<emphasis role="strong">influence the execution</emphasis> of the
motion specification:
<itemizedlist>

<listitem>
<para>
the <ulink url="kindyn-doc.html">kinematics</ulink> of the device. For
example, the programmer wants to avoid to come close to the kinematic
singularities; or he wants to optimize the energy consumption or 
another <emphasis role="strong">optimization criterion</emphasis>.
</para>
</listitem>

<listitem>
<para>
the <ulink url="orocos-control-kernel.html">controller</ulink> of the
device.  For example, for a device that runs under
<emphasis>impedance control</emphasis>, the
executed motion depends not only on the desired motion
geometry, but also on the the virtual impedance that the robot
controller tries to mimic.
</para>
</listitem>

<listitem>
<para>
the <emphasis role="strong">sensors</emphasis> with which the device
can inspect its environment allow the device to adapt its actions to
what it &ldquo;sees&rdquo;, i.e., it calculates its next motion
setpoint taking into account the acquired sensor information.
</para>
</listitem>

</itemizedlist>
This text talks about the &ldquo;simple&rdquo;
<emphasis role="strong">motion specification interface</emphasis>,
<emphasis>i.e.</emphasis> without taking into account the
device-specific aspects that influence the
<emphasis>execution</emphasis> of the specified motion.
</para>
<para>
The following Sections explain the two major complementary categories
of motion specification: the motion is specified in
<link linkend="joint-cartesian">joint space or in Cartesian
space</link>, or the motion setpoints come 
<link linkend="planning-interpolation">from a planner or from an
interpolator</link>.

</para>


<section id="joint-cartesian">
<title>Joint space vs. Cartesian space</title>
<para>
Motion specification must take into account the following two
complementary sets of physical properties:
<itemizedlist>

<listitem>
<para>
<emphasis role="strong">Joint space properties.</emphasis>
These are the properties of the relationships between end-effector
motion or force on the one hand, and the corresponding joint motion
and force on the other hand. That is, the <emphasis
role="strong">internal</emphasis> motion properties of the kinematic
chain, irrespective of what task the device must perform. 
</para>
</listitem>

<listitem>
<para>
<emphasis role="strong">Cartesian space properties.</emphasis>
These are the properties of the
&ldquo;<emphasis role="strong">external</emphasis>&rdquo; motion task
that the device is asked to perform, <emphasis>i.e.</emphasis> the
properties of the motion of (one of) the tools or end-effectors from
&ldquo;<emphasis>point A</emphasis>&rdquo; to 
&ldquo;<emphasis>point B</emphasis>&rdquo;, without reference to the
kinematic structure of the device that will perform the motion.
</para>
</listitem>

</itemizedlist>
The execution of a given specified motion is, in general, influenced
by the following two important factors:
<itemizedlist>

<listitem>
<para>
<emphasis role="strong">Constraints.</emphasis>
The specified motion for a tool on the machine could be
<emphasis role="strong">impossible</emphasis> to
generate by the device, because of: mechanical
joint limits; limits on the forces that can be generated by the
motors; singularities of the chain; collisions between links of the
kinematic chain and itself or other objects in the environment; etc.
</para>
</listitem>

<listitem>
<para>
<emphasis role="strong">Redundancy.</emphasis>
The specified motion could be generated by the kinematic chain in
<emphasis role="strong">multiple ways</emphasis>.
</para>
</listitem>

</itemizedlist>
Constraints and redundancy occur in both joint space and Cartesian
space, and are often mathematically tackled by optimizing
<emphasis>cost functions</emphasis>; for example, move with minimal
kinetic energy; minimize deviation from nominal position by attaching
virtual springs between the links and their nominal positions; etc.
Of course, these cost functions look differently in both spaces. And,
in addition multiple cost functions could be applied at the same time.
</para>
<para>
The joint space motion properties are discussed in more detail in
<ulink url="kindyn-doc.html">another document</ulink>, while
this text discusses Cartesian motion specification.
</para>

</section>


<section id="planning-interpolation">
<title>Planning vs. Interpolation</title>

<para>
Motion specification (in both joint space and Cartesian space) has two
complementary faces:
<itemizedlist>

<listitem>
<para>
<emphasis role="strong">Planning</emphasis>
(&ldquo;path planning&rdquo;, &ldquo;trajectory generation&rdquo;,
&hellip;) determines a sequence of desired Cartesian
<emphasis role="strong">via-points</emphasis> 
(or <emphasis role="strong">key frames</emphasis>) for
the tool whose motion is planned. A via-point is a combination of
position, velocity and/or acceleration of a
<emphasis>reference frame</emphasis> attached to the tool.
</para>
<para>
Planning is typically performed
<emphasis role="strong">off-line</emphasis> and in
<emphasis role="strong">non-realtime</emphasis>
(<emphasis>i.e.</emphasis> it is not strictly
synchronized with the servo controllers on the device's motors), and 
via-points are &ldquo;far apart&rdquo;. How far is
&ldquo;far&rdquo; depends on the application. In 
<emphasis role="strong">sensor-driven</emphasis> motions, the
generation of the next via-point is done on-line, based on the
information coming from the sensors.
</para>
</listitem>

<listitem>
<para>
<emphasis role="strong">Interpolation</emphasis> takes the
&ldquo;coarse-grained&rdquo; via-points
coming from the planning, and generates a sequence of 
&ldquo;fine-grained&rdquo; intermediate motion setpoints, that are
given to the motor controllers in a <emphasis>synchronous</emphasis>
way, <emphasis>i.e.</emphasis> one new setpoint at each control
instant. So, interpolation is an
<emphasis role="strong">on-line</emphasis> and 
<emphasis role="strong">realtime</emphasis> process.
</para>
</listitem>

</itemizedlist>
By definition, planning takes place in Cartesian space, but
interpolation is often performed in joint space: the 3D or 6D
via-points coming from the planning are transformed in desired joint
positions (and, possibly, also velocities and accelerations), via the
kinematic chain's
<ulink url="kindyn-doc.html">inverse kinematics</ulink>, and then the
interpolation takes place in each of the 1D spaces corresponding to
the joints separately.
Users can be interested in synchronizing the timing of all individual
joints' 1D interpolations; <emphasis>e.g.</emphasis> all joints must
start, stop, accelerate or decelerate at the same instant in time.
</para>
<para>
This document does not discuss 
<emphasis>planning algorithms</emphasis> (it assumes that the via-points or key
frames are generated &ldquo;somewhere&rdquo;, and are available to be
used in the method calls described in this document), or
<ulink url="interpolation-api.html">interpolation</ulink>. The
document <emphasis>does</emphasis> specify the contents of the
<link linkend="motion-classes"><parameter>ViaPoint</parameter></link>
software class used to contain the motion data and process it. 
</para>

</section>


</section> <!-- motion -->


<section id="motion-classes">
<title>Motion classes</title>
<para>
The simplest motion specification allows the programmer to specify
motions for which the target positions
(&ldquo;<link linkend="via-point">via-points</link>;
&ldquo;key frames&rdquo;) are known at the time of programming. A
&ldquo;<link linkend="path">path</link>&rdquo; is a sequence of
via-points that the tool has to move through.
</para>
<para>
Path and via-point programming is sufficient for most Cartesian motion
applications, including those where the motion target is defined
on-line, <emphasis>e.g.</emphasis> on the basis of sensors, or of
interactive human input by means of some form of a
&ldquo;joystick&rdquo;.
</para>
<para>
This section also presents specification primitives for sequences of
paths, as well as synchronized paths for more than one end-effector.
</para>


<section id="via-point">
<title><parameter>ViaPoint</parameter></title>
<para>
A via-point contains all or part of the following information:
<itemizedlist>

<listitem>
<para>
<emphasis role="strong">Geometry</emphasis>: the position and
orientation of the via-point. This information is mathematically
represented by a point or a reference frame.
</para>
</listitem>

<listitem>
<para>
<emphasis role="strong">Constraints</emphasis>: the
velocity and/or acceleration information the moving tool should have
when reaching the via-point. Or, alternatively, the time instant at
which the via-point must be reached. Or, in more advanced
applications, indications about the desired &ldquo;distance&rdquo; to
an objects seen by the sensors. &ldquo;Distance&rdquo; can also mean
&ldquo;force&rdquo;, in case the motion is physically constrained by
contact with the environment.
</para>
<para>
In some tasks, the timing is less important than the geometry, such
that the velocity and acceleration at the via-point can be considered
to be &ldquo;timeless&rdquo;, <emphasis>i.e.</emphasis> they determine
the &ldquo;tangential&rdquo; information at the via-point (the desired
tangent direction and the desired curvature, respectively).
</para>
</listitem>

<listitem>
<para>
<emphasis role="strong">Events</emphasis>: the application programmer
can be interested in being able to fire events when a given via-point
is reached, in order to enable other tasks
<emphasis role="strong">to synchronize</emphasis> with the ongoing
motion. Some examples are: opening or closing of a gripper when a
certain via-point is reached; taking a measurement; starting the
motion of another machine; signaling to the motion
<emphasis>controller</emphasis> that the ongoing motion towards
the via-point has reached its final destination, such that it can, for
example, adapt its control action.
</para>
</listitem>

</itemizedlist>
The information in a via-point is allowed to be
<emphasis role="strong">partial</emphasis>, in the sense that it does
not specify all the available degrees of freedom for the
&ldquo;end-effector&rdquo; that executes the motion. This
&ldquo;redundancy&rdquo; creates opportunities to optimize the specified
motion in ways that are not foreseen or not relevant at the time of
specification. This optimization is the job of the
<ulink url="interpolation-api.html">interpolator</ulink>.
</para>

</section>


<section id="path">
<title><parameter>Path</parameter></title>