applications-doc.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>
    Orocos Applications
  </title>
  <author>
    <firstname>Herman</firstname>
    <surname>Bruyninckx</surname>
    <affiliation>
      <address>
        [e-mail]
      </address>
    </affiliation>
  </author>
 <copyright>
  <year>2003</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="applications-doc.xml">XML file</ulink>.
</holder>
 </copyright>


 <abstract>
 <para>
 <emphasis role="strong">Abstract</emphasis>
 </para>
 <para>
This document describes what an <emphasis>Application</emphasis> is 
and how building an application must be
prepared to fit in the generic realtime feedback control Kernel.
Some general applications are discussed in more detail.
</para>
<para>
The subsequent steps in the implementation of an application are: (i) to
describe the &ldquo;family&rdquo; of applications that the current
implementation can or should cover; (ii) to determine the architecture
of the application; (iii) to fill in the Data Object interfaces; (iv)
to decide what functions are needed in all Components, and what
real-time behaviour they require; (v) to determine the
<emphasis>control flow</emphasis> of the application; and (vi) to implement the Component
functions.
</para>
 </abstract>

 <revhistory>
  <revision>
    <revnumber>0.01</revnumber>
    <date>August 13, 2003</date>
    <authorinitials>HB</authorinitials>
	 <revremark>
Initial release: gives overview of Kernel design and programming
interface; lists most common motion control applications, without much
detail; explains the complementary roles of the Kernel Builders, the
Application Builders, and the Component Builders.
    </revremark> 
  </revision>
  <revision>
    <revnumber>0.02</revnumber>
    <date>August 16, 2003</date>
    <authorinitials>HB</authorinitials>
	 <revremark>
Added more details for a set of most common applications.
    </revremark> 
  </revision>
  <revision>
    <revnumber>0.03</revnumber>
    <date>January 20, 2004</date>
    <authorinitials>HB</authorinitials>
	 <revremark>
Introduced &ldquo;families&rdquo;, and &ldquo;Kernel
applications&rdquo;. More details on (a)synchronous data exchange.
    </revremark> 
  </revision>
 </revhistory>

</articleinfo>


<section id="applications-introduction">
<title>Introduction</title>
<para>
An <emphasis role="strong">application</emphasis> is a piece of
software that <emphasis role="strong">(advanced) end-users</emphasis>
can work with: the software runs on the end-users' particular
hardware; it offers a programming language and (graphical) user
interface targeted to the end-users' goals; it provides configuration
options that are relevant in the end-users' context; etc.
</para>
<para>
The &orocos; project is not in the first place about providing a
particular set of applications, but rather on providing the
<emphasis>infrastructure</emphasis> to build applications.
In this respect, &orocos; is designed to be a &ldquo;plug-in&rdquo;
framework, in which different applications are developed as plug-ins
into the same <emphasis>Kernel</emphasis> framework. 
However, &orocos; does have already a couple of applications, which
serve as examples from which to start other applications. Over time,
the applications database will hopefully grow, by contributions from
users.
</para>
<para>At the lowest (&ldquo;real-time&rdquo;)
control level, the current state of &orocos; is as follows:
<itemizedlist>

<listitem>
<para>
&orocos; provides a generic <emphasis role="strong">Kernel</emphasis>
that can be used for all real-time or non real-time 
<emphasis role="strong">feedback control</emphasis>
applications. The Kernel code is the responsibility of the
<emphasis role="strong">Kernel Builders</emphasis>: they take care
of the interfaces to the underlying operating system and hardware;
they provide a programming interface that is more familiar to control
application builders than the powerful but hence often dangerous
(real-time) operating system primitives; they take care about how to
best implement
&ldquo;boring stuff&rdquo; like efficiency, distributability, mutual
exclusion, and, possibly, CORBA support; and they provide a set of
example applications.
</para>
</listitem>

<listitem>
<para>
The Kernel offers a plug-in interface for the
<emphasis role="strong">Application Builders</emphasis>. The
Application Builders' first
responsibilty is to design an application by providing
<emphasis role="strong">concrete specifications</emphasis> (interfaces
and functionality) for all
plug-ins, targeted to the application's goals. So, they specify what
the application will functionally be able to do, what data it will
accept and generate, and how end users can interact with this data and
functionality.
</para>
<para>
The second responsibilty of the Application Builders is 
<emphasis role="strong">to integrate</emphasis> the whole
application; i.e., the Component Builders (see below) provide
implementations of the above-mentioned specifications, and the
Application Builders must make sure that the whole set of
implementations really works together as specified. In this part of
the job, topics appear such as distribution over a network, and
filling in the
<anchor id="hot-spots">
<emphasis role="strong">hot spots</emphasis>. These hot
spots are those parts of an application instantiation that do, in
general, not port between instantiations of the same application
(i.e., from one serial robot manipulator to another serial robot
manipulator); they consist mainly of device drivers for the particular
hardware of each instantiation, wrappers to the operating
system used in the instantiation, kinematics of robots, etc.
</para>
<para>
The first result of the Application Builders' work is independent of
the concrete system (the &ldquo;instantiation&rdquo; of the
application): the application is fully specified, but still without
implementation code.
The second result of the Application Builders' work is fully
integrated and implemented code; this part is
<emphasis>very</emphasis> dependent on the concrete system.
Because of this fundamental difference in dependencies, it is a good
idea to keep both responsibilities of the Application Builders
<ulink url="decoupling.html">decoupled</ulink>, even in tightly
integrated systems.
</para>
</listitem>

<listitem>
<para>
An application must have code in each of its Kernel plug-ins,
<emphasis role="strong">implementing</emphasis> the functionality of
that application, as specified by the Application Builders. The
concrete implementation of the application functionality is the
responsibility of the
<emphasis role="strong">Component Builders</emphasis>, who are
experts in the specific component functionality they are implementing.
They have to know only a minimum about what is going on in the rest of
the application or in the Kernel, and certainly not about how all
those other things are implemented.
</para>
<para>
Especially in research environments, it is useful to allow the
possibility to replace one particular component implementation with
another one. The Kernel was designed with this functionality of
dynamic re-configuration of plug-in implementations in mind.
</para>
</listitem>

</itemizedlist>
Of course, in many real cases, the same people play the roles of
Kernel Builder, Application Builder and Component Builder, at
different times and with different levels of involvement. 
</para>

</section>


<section id="applications-kernel">
<title>The Kernel</title>
<para>
This Section describes the structure and the programming interface of
the Kernel, but only at a level of detail that is appropriate for
Application and Component Builders. More details of the Kernel design,
properties and implementation are described in
<ulink url="kernel-doc.html">another document</ulink>; this document
focuses on how <emphasis>to use</emphasis> the Kernel infrastructure.
</para>
<para>
<xref linkend="fig-control-pattern"> depicts the 
<emphasis role="strong">structure</emphasis> of the
Kernel: the rectangles are &ldquo;Components&rdquo;, the ovals are
&ldquo;Data Objects&rdquo;, and the arrows indicate read and write
accesses. Basically, specifying an application means specifying the
contents of the Data Objects, as well as the function blocks
in the Components.
</para>
<para>
<figure id="fig-control-pattern" float="1" pgwide="0">
<title>
 Structure of the generic feedback control Kernel.
</title>
<mediaobject>
<imageobject>
<imagedata fileref="../pictures/control-pattern.png" format="PNG">
</imageobject>
<imageobject>
<imagedata fileref="../pictures/control-pattern.eps" format="EPS">
</imageobject>
</mediaobject>
</figure>
</para>
<para>
<figure id="fig-port-data-object" float="1" pgwide="0">
<title>
Data Objects (ovals) are responsible for the deterministic
distribution of information between Components. 
</title>
<mediaobject>
<imageobject>
<imagedata fileref="../pictures/port-data-object.png" format="PNG">
</imageobject>
<imageobject>
<imagedata fileref="../pictures/port-data-object.eps" format="EPS">
</imageobject>
</mediaobject>
</figure>
</para>

<section id="applications-kernel-exchange">
<title>Interaction between Components</title>

<para>
In the context of this document, the important thing is to know how
the various Components can <emphasis role="strong">interact</emphasis>
<anchor id="interaction">
with each other.
Components are designed and implemented independently of each other,
except for the following complementary forms of interaction:
<itemizedlist>

<listitem>
<para>
<emphasis role="strong">Data flow via Data Objects.</emphasis>
<xref linkend="fig-port-data-object"> shows the data exchange
concept offered by the Kernel. Each Component has a number of 
<anchor id="ports">
<emphasis role="strong">Ports</emphasis> through which it communicates
data. Multiple Ports of the same Component can be connected to the
same Data Object. And one Data Object can be connected to multiple
Components.
</para>
<para>
The Kernel offers support for efficient and deterministic data
exchange, which takes place through standardized
<parameter>Set_&hellip;</parameter> and
<parameter>Get_&hellip;</parameter> methods on all Data Objects.
The Component Builders do not have to worry about low-level
responsibilities such as locking and transparant network distribution.
</para>
</listitem>

<listitem>
<para>
<emphasis role="strong">Control flow via Events</emphasis>.
The Kernel offers support
for the &ldquo;firing&rdquo; and &ldquo;handling&rdquo; of events.
Components use events to notify other Components that a certain fact
has happened, without it having to know these other Components
explicitly, and without having to synchronize with them explicitly.
</para>
<para>
Some events are standardized by the Kernel, such as those used for
(re)configuration; the application-dependent events are specified by
the Application Builders.
</para>
</listitem>

</itemizedlist>
Applications should not use any other means of interaction. The
temptation may be high for an Application Builder to provide
&ldquo;shortcut&rdquo; interactions, but everything that bypasses
the structures offered by the Kernel leads to
non-deterministic and non-maintainable implementations. (If Application
Builders do have very good arguments to introduce other interaction
primitives, they should contact the Kernel Builders and discuss the
addition of these new primitives to the Kernel!)
</para>

</section>


<section id="applications-kernel-inter-exchange">
<title>Interaction within one single Component</title>

<para>
Data exchange takes place between functions in Components: function
``<emphasis>A</emphasis>'' in Component ``<emphasis>X</emphasis>''
needs to have data from function ``<emphasis>B</emphasis>'' in
Component ``<emphasis>Y</emphasis>''. As in this simple example,
these functions are often in <emphasis>different</emphasis>
Components, and the Data Objects' support in the Kernel then takes
care of the mutual exclusion needed in asynchronous data exchange. But
it is also possible that different functions in the
<emphasis>same</emphasis> Component want to exchange data. If both
functions have the same
<link linkend="rt-modes">real-time mode</link>, the fact that they run
in the same Component is sufficient to guarantee mutual exclusion when
accessing the common data. But if the functions have a different 
real-time mode, they most probably run in different threads, so
mutual exclusion synchronization is necessary. The fundamental
difference between both situations is that in the latter, each access
to the shared data should be made through the safe
<parameter>Set_&hellip;</parameter> and
<parameter>Get_&hellip;</parameter> methods supported by the Kernel.
</para>
<para>
Alternatively, the Kernel implementation of these 
<parameter>Set_&hellip;</parameter> and
<parameter>Get_&hellip;</parameter> methods could take into account
from which Components they are called and avoid the locking or network
transparancy when it is not needed. Of course, this approach requires
software support during the building of the application; this support
is a long-term goal of &orocos;.
</para>
<para>
This document uses the name 
&ldquo;<emphasis role="strong">function blocks</emphasis>&rdquo;
for (the largest) sets of Component functions that, as a group, require 
asynchronous data exchange, and this data exchange is localized at the
start and end of the function block. That means that a function block
can be implemented by a Component Builder without having to worry
about the context the code is used in. The name
&ldquo;function block&rdquo; is, not by coincidence, the same as used
in <emphasis>Programmable Logic Controllers</emphasis> (PLCs).
</para>
<para>
<xref linkend="fig-port-component"> depicts a situation in which two
different &ldquo;function blocks&rdquo; in the same Component access a
shared data object through a <parameter>Port</parameter> that is only
connected inside the Component. For the Kernel, this
&ldquo;special&rdquo; situation is not special at all: it doesn't
require any added functionality from the Kernel, because the
&ldquo;asynchronously safe&rdquo;
<parameter>Set_&hellip;</parameter> and
<parameter>Get_&hellip;</parameter> methods have to exist in the
Kernel anyway. So, both function blocks can be combined into one
single larger function block.
</para>

<para>
<figure id="fig-port-component" float="1" pgwide="0">
<title>
Asynchronous data access through Ports within one single Component.
</title>
<mediaobject>
<imageobject>
<imagedata fileref="../pictures/port-component.png" format="PNG">
</imageobject>
<imageobject>
<imagedata fileref="../pictures/port-component.eps" format="EPS">
</imageobject>
</mediaobject>
</figure>
</para>

</section>


<section id="applications-kernel-use">
<title>Applying the Kernel structure</title>
<para>
The Kernel structure of <xref linkend="fig-control-pattern"> is a
<emphasis role="strong">conceptual model</emphasis>. In
concrete applications, this model can be used in various ways:
<itemizedlist>

<listitem>
<para>
Some Components are left empty. This means that the corresponding Data
Objects are &ldquo;short-circuited&rdquo;. The
<emphasis>Estimator</emphasis> is one of these Components that are
needed only in advanced applications, and hence will be left
empty in most systems.
</para>
</listitem>

<listitem>
<para>
Some Components are taken together in one single Component,
<emphasis>i.e.</emphasis> the data exchange between these Components
takes place in the same thread, and no external Components require