Suggestion for Version 1.0 motion application API...

Request for comments.

This message contains a suggestion for a Version 1.0 API. Because we want
that API to cover everybody's needs, we invite you not to wait with
comments till it's too late... Take into account that it is an API for an
_application_, not for one particular control component.

This message summarizes the motion specification (= non-realtime data flow)
interface for (I think) all possible kinematic devices, with any number of
TCPs ("Tool Centre Point"), any possible motion interpolation, any possible
sensor feedback, and any possible control algorithm. The major motivation
behind this interface is that it is _small_ and can be made mandatory for
_all_ motion applications; the inevitable variability in motion
specifications is completely delegated to the _arguments_ of the interface:

 MyMotionApplication.Move ( ViaPoint );
 MyMotionApplication.Move ( Path );
 MyMotionApplication.Move ( SynchronisedPath );
 MyMotionApplication.Move ( MotionTask );

Each argument (ViaPoint, Path, SynchronisedPath, and MotionTask) contains
information about where and how to move, including events to be fired in
synchronisation with the motion.

A Path is a sequence of ViaPoints; a SynchronisedPath is a _parallel_ and
synchronised combination of Paths, one for each TCP for which a Path is
defined; a MotionTask is a sequence of Paths or SynchronisedPaths. These
composite trajectories have events associated to each of their "composition
instants", e.g. a MotionTask can fire an event whenever a Path in its
specification starts or finishes.

Instead of "ViaPoint", we could also have used the name "Frame", but this
latter name is too much coupled to Cartesian space; indeed, a ViaPoint can
also consists of joint space information!  The information in a ViaPoint
is: position (and orientation in Cartesian space), and possibly higher
order information such as velocities and accelerations.  Note the
"possibly" in the sentence above: a ViaPoint with only position and
orientation is a less specialized object than a ViaPoint that also includes
velocities; a ViaPoint can also encode _sensor-based_ specifications, such
as the desired force in a contact, or the desired distance from an
obstacle, etc., ...

The interface is for a motion control _application_ (considered as a
Component by itself) and _not_ for the Generator, Sensor, Estimator, and
Controller sub-components.  The functionalities ("behaviours") inside these
sub-components is configurable. For example, the Generator can contain
joint space interpolation and Cartesian space interpolation, and the switch
between both functionalities is made on line depending on the current
ViaPoint information. Or the Sensor + Estimator can produce tracking of any
of the available TCPs. Etcetera.
The configuration of these subcomponents does not belong to the data flow
interface given above, but to the execution and configuration flows (which
are not discussed here).

The interface follows the "Data Transfer Object" software pattern (Fowler,
2003): interaction between (client and server) Components is
_coarse-grained_, such that for distributed Components the _number_ of
method calls can be kept small. (Indeed, distributed systems have a high
relative cost of communication.)

Each argument is heavily overloaded: there is already the obvious
overloading seen in the four method signatures above, but then each of
these cases has many implementations itself, depending on the DOFs of the
device, the number of TCPs, the different kinds of information in a
ViaPoint, etc.
This is (I think) not so difficult to implement, by inheritance from
an abstract base class "Motion", in which the above-mentioned methods are
"pure virtual" member functions (i.e., semantically the same as "interface"
in Java):
   <http://www.parashift.com/c++-faq-lite/abcs.html>
   <http://home.wanadoo.nl/efx/c++-faq/virtual-functions.html>
Or does someone think that templates are better? I don't think so, because
adding a new ViaPoint class would then mean recompilation of the _existing_
code base, while that's not needed if the abstract interface is given a new
implementation...
  
Note that there is some implicit execution flow embedded in the Move
interface. For example, a Path that has one ViaPoint with Cartesian space
specification and a following ViaPoint with joint space specification
induces a change of interpolator in the Generator...
Do we forbid to mix ViaPoints of different types in a Path...?  Personally,
I do not see any reason for this restriction.

Are we really gaining something by having a small motion interface that all
motion applications can implement, if this simplicity in the method
signatures is offset by the run-time overhead and "not implemented" return
values occurring when the type of object in the argument list is not known
by the component implementation?  The last thing is probably not a problem,
because the parsing of a new Move command is not a hard realtime activity,
and the interface belongs at the _application_ level, where (non-realtime)
scripting and/or pre-processing of commands is commonplace.

What about "process-driven" tasks? I mean, tasks where the motion of the
robot are to a large extent determined by on-line measurements of an
ongoing process, such as welding, deburring, laser or water jet cutting,
etc.  In my opinion, these are covered too: these applications must provide
Generator/Estimator/Sensor components that know how to steer the process,
and the ViaPoints/Path/... argument of the Move command contains the process
parameters, not the process model (which is in the mentioned Components).

If you can think of any tasks that are not covered in the discussion of
this message, please let us know on the mailinglist! 

Herman

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