applications-doc.sgml

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

access to any of these data objects.  This is reasonable for
small-scale, centralized control systems, because it makes their
<link linkend="interaction">interaction</link> a lot
simpler and efficient. The most typical case is where the Generator,
Sensor, Estimator and Servo can be brought together in one single
function block.</para>
</listitem>

<listitem>
<para>
Every feedback control application needs some sort of deterministic
and periodic task execution. Traditionally, control system programmers
directly use RTOS primitives such as periodic threads with static
scheduling priorities. However, the Kernel decouples the
<emphasis>specification</emphasis> of a 
<emphasis role="strong">real-time behaviour</emphasis> from its
<emphasis>implementation</emphasis> on a real-time operating system.
So, Application Builders configure each of the Component functions to
have one of the following real-time modes offered by the Kernel:
<anchor id="rt-modes">
 <itemizedlist>

 <listitem>
 <para>
 <anchor id="behaviour-non-interruptable">
 <emphasis role="strong">Non-Interruptable.</emphasis>
Functions with this real-time mode have the highest priority in the
Kernel, and run with hardware interrupts disabled. Hence, functions
should only use this real-time mode in very few, extremely
time-critical cases.
 </para>
 </listitem>

 <listitem>
 <para>
 <anchor id="behaviour-non-pre-emptible">
 <emphasis role="strong">Non-Pre-Emptible</emphasis>
These functions run with the same highest priority, but after the
<emphasis>Non-Interruptable</emphasis> functions, and with the
hardware interrupts enabled.
 </para>
 </listitem>

 <listitem>
 <para>
 <anchor id="behaviour-pre-emptible">
 <emphasis role="strong">Pre-Emptible</emphasis> functions run with
the second highest priority: the execution of these functions can be
pre-empted by the <emphasis>Non-Interruptable</emphasis> and
<emphasis>Non-Pre-Emptible</emphasis> functions.
 </para>
 </listitem>

 <listitem>
 <para>
 <anchor id="behaviour-soft-real-time">
 <emphasis role="strong">Soft-Real-Time</emphasis> functions run at
lower priorities.
 </para>
 </listitem>

 </itemizedlist>
In most implementations of the Kernel, the above-mentioned real-time
modes map quite straigthforwardly to real-time threads in the RTOS:
 <itemizedlist>

 <listitem>
 <para>
The <emphasis>Non-Interruptable</emphasis> and
<emphasis>Non-Pre-Emptible</emphasis> functions run in a thread that
gets the highest scheduling priority of all application threads.  This
thread is called &ldquo;zero-time thread&rdquo; in the reference
Orocos implementation, because it executes those functions that have
to finish in zero time, i.e., without any possible interruption from
elsewhere.
 </para>
 <para>
Within this zero-time thread, the
<emphasis>Non-Interruptable</emphasis> functions run with interrupts
disabled.
 </para>
 </listitem>

 <listitem>
 <para>
The <emphasis>Pre-Emptible</emphasis> functions run in a
lower-priority thread,
called the &ldquo;zero-latency thread&rdquo;, because it should
execute those functions that have to finish before a given deadline,
i.e., with the minimum possible latency on that deadline. 
 </para>
 </listitem>

 </itemizedlist>
<para>
Note that the Application Builders assign real-time modes to
<emphasis>functions</emphasis>, and that they do not come in direct
contact with <emphasis>threads</emphasis>. The reason is that
particular implementations of the Kernel can opt to provide the
desired real-time behaviour by other means than by
using threads. For example, timers or tasklets; without using
a real-time operating system at all, executing everything in one loop,
with the highest-priority functions first; or executing the
above-mentioned real-time modes in, respectively, Interrupt Service
Routines, Deferred Service Routines and Asynchronous Service Routines.
</para>
</listitem>

<listitem>
<para>
The above-mentioned decoupling between the specification of the
real-time <emphasis>behaviour</emphasis> on the one hand, and the
<emphasis>sample frequencies</emphasis> on the other hand, in
combination with the fact that both pieces of information are
<emphasis role="strong">configured at run-time</emphasis>, force
Application and Component Builders
<emphasis role="strong">not to use direct knowledge</emphasis> of the
sample frequency and the real-time behaviour in their code. (With the
exception of <emphasis>Non-Interruptable</emphasis> functions, because
these can typically only use a very limited subset of the Kernel API.)
The Builders should use a configuration
<emphasis role="strong">property</emphasis> instead.
</para>
</listitem>

<listitem>
<para>
Multiple instances of the generic Kernel structure are combined in
more complex 
<anchor id="multi-level">
<emphasis role="strong">architectures</emphasis>. The
most common architecture at the real-time control level is
<emphasis role="strong">hierarchical</emphasis>, as depicted in
<xref linkend="fig-two-level-control-pattern"> and
<xref linkend="fig-two-level-control-pattern-component">.
</para>
<para>
<anchor id="real-time-interaction">
The arrows running from right to left between both levels of these
architectures denote &ldquo;asynchronous&rdquo; data access between
priority levels. The difference between
<xref linkend="fig-two-level-control-pattern"> and
<xref linkend="fig-two-level-control-pattern-component"> is that
the former architecture applies to applications in which both levels
require <emphasis role="strong">real-time interaction</emphasis>: a
Component in the highest level needs information from one particular
Component in the lowest level. In the latter case, an
<emphasis>image</emphasis> of the whole low level is passed to the
high level via the Reporter Component of the lowest level, which is by
default a non-real-time Component.  This approach is more suitable for
networked distribution; the former is appropriate for implementation
of the controller on one single computing node.
</para>
<para>
The advantage of the real-time architecture is tighter
synchronization between lower and higher level; the disadvantage is
that the lowest level cannot run in its most efficient implementation,
because the data access from the higher level is typically
<link linkend="applications-kernel-inter-exchange">asynchronously</link>.
However, if the frequency of the inner loop is an integer multiple of
the frequency of the outer loops that require asynchronous data
access, the implementation <emphasis>can</emphasis> be done without
locking; it is even possible to run both levels in the same thread.
</para>
</listitem>

</itemizedlist>
</para>
<para>
<figure id="fig-two-level-control-pattern" float="1" pgwide="0">
<title>
Application of the control Kernel concept in a two-level hierarchical
architecture, with <emphasis>real-time</emphasis> data exchange
between both levels.
</title>
<mediaobject>
<imageobject>
<imagedata fileref="../pictures/two-level-control-pattern.png" format="PNG">
</imageobject>
<imageobject>
<imagedata fileref="../pictures/two-level-control-pattern.eps" format="EPS">
</imageobject>
</mediaobject>
</figure>
</para>
<para>
<figure id="fig-two-level-control-pattern-component" float="1" pgwide="0">
<title>
Application of the control Kernel concept in a two-level hierarchical
architecture, with <emphasis>non-real-time</emphasis> data exchange.
</title>
<mediaobject>
<imageobject>
<imagedata fileref="../pictures/two-level-control-pattern-component.png" format="PNG">
</imageobject>
<imageobject>
<imagedata fileref="../pictures/two-level-control-pattern-component.eps" format="EPS">
</imageobject>
</mediaobject>
</figure>
</para>

</section>


<section id="kernel-application">
<title>Kernel applications: generic control systems</title>
<para>
Talking about &ldquo;Kernel applications&rdquo; seems to be a
contradiction, since previous sections suggested to consider the Kernel as an
&ldquo;empty&rdquo; placeholder that accepts application-dependent
functionality. However, there is already a lot of useful things that
one can implement in the Kernel, and that is completely independent of
any particular application: PID servos for SISO and MIMO systems; gain
scheduling; digital signal processing algorithms; one-dimensional
setpoint interpolation, and synchronized N-dimensional setpoint
interpolation; etc.
Roughly speaking, the difference with real Applications is that at
this Kernel level, the signals have no physical dimensions, and have
just generic names such as &ldquo;X&rdquo;.
</para>

</section>

</section>


<section id="applications-kernel-applications">
<title>Applications</title>

<para>
This Section gives an overview of the Application Builders' task in
specifying an application; the following Sections give concrete
application examples.
</para>

<section id="applications-tasks">
<title>Tasks of the Application Builders</title>
<para>
Application Builders do not <emphasis>implement</emphasis> an
application, but <emphasis>specify</emphasis> and
<emphasis>integrate</emphasis> it. (Compare this job to that of
computer motherboard manufacturers.) That means the Application
Builders take decisions for all of the following:
<orderedlist>

<listitem>
<para>
The <emphasis role="strong">architecture</emphasis> of the
application, <emphasis>i.e.</emphasis> deciding about the data flow in
the system. 
</para>
<para>
If the architecture is 
<link linkend="multi-level">multi-level</link>, the Application
Builders have (i) to decide which higher levels need real-time access
to data objects from lower levels (because this influences the data
flow in the application), and
(ii) to choose distinct names for the same Components in
the various instantations of the Kernel structure
(<emphasis>i.e.</emphasis> the <emphasis>Generator</emphasis> name
should be used only once; so,
<xref linkend="fig-two-level-control-pattern"> gives a misleading
picture).
</para>
</listitem>

<listitem>
<para>
The <emphasis role="strong">objects</emphasis> to be stored in
the Data Objects of the Kernel, or, in other words, the
<link linkend="ports">Ports</link> of all Components.
</para>
</listitem>

<listitem>
<para>
The <emphasis role="strong">events</emphasis> that Components generate
and/or react to.
</para>
</listitem>

<listitem>
<para>
The <emphasis role="strong">functions</emphasis> (and 
function blocks) that must run in each Component.
</para>
</listitem>

<listitem>
<para>
The execution <emphasis role="strong">behaviour</emphasis> of all
Component functions. The Application Builders decide
(i) how many threads to use (<emphasis>if</emphasis> threads are
used&hellip;),
(ii) at what frequencies they run; and
(iii) which Component functions are run with what
<link linkend="rt-modes">real-time mode</link>.
</para>
<para>
The Kernel takes care of the concrete details of real-time
execution and scheduling, while the application concentrates on the
functionality.
The &ldquo;price&rdquo; to pay for this convenience is that the
Application Builders must strictly follow the structure imposed 
by the Kernel. This structure consists of only using the
predefined Components, and their standard interfaces. These interfaces
basically consist of <parameter>Set_&hellip;</parameter> and
 <parameter>Get_&hellip;</parameter> methods on the Data Objects.
</para>
</listitem>

</orderedlist>
So, after having taken all these decisions, all that is left to do is
to fill in concrete implementations of all functions. This is the
Component Builders' job, which is not within the scope of this
document.
</para>

</section>


<section id="applications-families">
<title>Application families</title>
<para>
The &orocos; project is all about providing <emphasis>generic
infrastructure</emphasis>, so re-use of developments at any level
should be aimed at. Hence, also the Application and Component Builders
must try to keep their work as general as possible, without
compromising on efficiency and intuitivity for their users. One of the
most practical (and easy) steps is to avoid all use of &ldquo;magic
numbers&rdquo; in the application code; these are numbers that have
only meaning for the particular application that the Builders are
working at. Instead, the Builders should try to come up with a
<emphasis role="strong">family</emphasis> of Applications and/or
Components (kinematics, servo algorithms, generators, estimators,
&hellip;). A family is determined by a set of algorithms that can be
given a
common <emphasis role="strong">property file</emphasis>, and the whole
family is uniquely defined by varying the property parameters. In
other words, a family can be given executable code that can be
reconfigured for any member of the family without recompilation, just
by setting the properties.
</para>
<para>
The borders of where we take stuff together to put it into a family
are defined by the &ldquo;simplicity&rdquo; of the property file. Of
course, this is not a deterministic statement, so discussion will
remain about what exactly constitutes a family.  Anyway, hierarchies
of families exist: a family deeper in the hierarchy has more efficient
implementations, but less members.
</para>

</section>

</section>


<section id="applications-actuated-axis">
<title>ActuatedAxis</title>

<para>
A very common application in the domain of motion control is that
of one single actuated axis. <emphasis>i.e.</emphasis> a revolute or
prismatic joint with a transmission and a motor. The joint axis has
mechanical limits, software and hardware end switches at one end or at
both ends, position or velocity sensors (encoders, resolvers,
potentiometers, laser distance sensors, &hellip;), force, current or
pressure sensors, etc.
</para>
<para>
Actuated axes come in different types: position control, velocity
control, force control, pressure control, current control.
</para>

<section id="actuated-axis-architecture">
<title>Architecture</title>
<para>
The typical architecture for an ActuatedAxis is a
<link linkend="multi-level">multi-level hierarchy</link>, with
so-called <emphasis>cascaded control loops</emphasis>: the inner loop
performs current control, the loop around that does force or velocity
control, and the outer loop provides position control. (In many
systems, the two inner loops are done in the hardware of the motor
drive units.) It is appropriate to choose sample times for the
outer loops that are integer multiples of the inner loop, such that
very efficient (because lock-less) &ldquo;asynchronous&rdquo; data
exchange can be provided.
</para>
<para>
The <link linkend="fig-two-level-control-pattern">Components</link>
in the Application are as follows.  The (data flow) Command is a
desired 1D position, velocity, force, current or pressure, and the
Generator performs simple interpolation between the incoming Commands
and the real-time Setpoints. The Controller is most often some
variation of the PID algorithm. The Estimator is usually empty, or
provides quite straightforward transformations, such as positions into
velocities (mind the discretization effects!), or pressures or
currents into forces.
</para>

</section>

<section id="actuated-axis-commands">
<title>Commands</title>
<para>
<para>
The previous section described the architecture with which to perform
<emphasis>steady state</emphasis> data flow (<emphasis>i.e.</emphasis>
the Command is a setpoint for the Generator), but the ActuatedAxis
application also has <emphasis>control flow</emphasis> properties. The
corresponding Commands are documented below; the exact syntax of the
Commands depends on the application.
<itemizedlist>

<listitem>
<para>
<emphasis role="strong">Component configuration</emphasis>: an
ActuatedAxis application can provide several algorithms for the
Generator, Servo, and Estimator, and provides Commands to the user to
make this selection. 
</para>
<para>