applications-doc.sgml

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

The implementation of the application must make sure that such a
configuration Command is executed in a safe way,
<emphasis>i.e.</emphasis> the Components are brought in a state in
which they can be (re)configured. The reconfiguration could have
<emphasis role="strong">hot-plug semantics</emphasis>: the outer loop
is reconfigured while the inner loops keep on running their control
loops in hard real time, using the last data Command they received
from the outer loop.
</para>
</listitem>

<listitem>
<para>
<emphasis role="strong">Power configuration.</emphasis>
The ActuatedAxis must first power its drives before it can execute
motion commands. Similarly, it has to power-off the drives at the end
of the motion tasks.
</para>
</listitem>

<listitem>
<para>
<emphasis role="strong">Homing.</emphasis>
Many ActuatedAxis applications do not use absolute position sensors,
such that the system must first move to find its &ldquo;zero
position&rdquo;. The exact sequence of motions and events that are
needed for the homing depends on the hardware setup of the
application. But they all have a similar sequence of actions:
 <orderedlist>

 <listitem>
 <para>
Power-on the system, after the human has made sure that it is in an
appropriate position for homing.
 </para>
 </listitem>

 <listitem>
 <para>
Move &ldquo;fastly&rdquo; towards an end switch. The reaching of the
switch triggers an event, for which the handler has been registered
before the start of this motion.
 </para>
 </listitem>

 <listitem>
 <para>
Reverse the motion direction and move &ldquo;slowly&rdquo; towards
the end switch. The reaching of the switch triggers an event, for
which (another) handler has been registered before the start of this
motion. This second motion aims at a higher accuracy of setting the
zero position.
 </para>
 </listitem>


 </orderedlist>
</para>
</listitem>

</itemizedlist>
</para>

</section>


<section id="actuated-axis-data-flow">
<title>Data flow</title>
<para>
commands, generator setpoints, control state (position, velocity,
force, &hellip;), configuration state (What functionality runs in
which Component? What functionality is available in each Component?)
</para>

</section>

<section id="actuated-axis-events">
<title>Events</title>
<para>
<itemizedlist>

<listitem>
<para>
<emphasis role="strong">Motion events.</emphasis>
<emphasis>MotionStateEndReached</emphasis>: the Generator triggers
this event, to signal the other components that it is now generating
setpoints for this particular motion state. The other Components can
adapt their functionality accordingly; <emphasis>e.g.</emphasis> the
servo can increase the integral action of a PID, or the estimator can
switch to a velocity estimator that works best for slow velocities.
</para>
</listitem>

<listitem>
<para>
<emphasis role="strong">Hardware events.</emphasis>
<emphasis>PowerOn</emphasis>, <emphasis>PowerOff</emphasis>,
<emphasis>EndSwitchReached</emphasis>, 
</para>
</listitem>

<listitem>
<para>
<emphasis role="strong">Component configuration events.</emphasis>
<emphasis>GeneratorReachedStateX</emphasis>,
<emphasis>TriggerGeneratorStateTransitionA</emphasis> (and similar
events for the other Components and other &ldquo;A's&rdquo;).
</para>
</listitem>

<listitem>
<para>
<emphasis role="strong">Application configuration events.</emphasis>
Application has reached state X; trigger Application state transition;
etc.
</para>
</listitem>

<listitem>
<para>
<emphasis role="strong">Error events.</emphasis>
<emphasis>PowerFailure</emphasis>;
<emphasis>MinimalPositionExceeded</emphasis>,
<emphasis>MaximalPositionExceeded</emphasis>, and similar events for
velocity, current, force, power, etc.;
</para>
</listitem>

</itemizedlist>
</para>
</section>


<section id="actuated-axis-functions">
<title>Component functionalities</title>
<para>
PID; gain scheduling; motion profiles; Kalman Filters for velocity or
position; etc.
</para>

</section>


<section id="actuated-axis-behaviour">
<title>Behaviour</title>
<para>
The innermost loop that runs in software uses the 
<link linkend="behaviour-non-pre-emptible">Non-Pre-Emptible</link>
real-time mode.
(<link linkend="behaviour-non-interruptable">Non-Interruptable</link>
isn't necessary in most cases.) The outer loops are
<link linkend="behaviour-pre-emptible">Pre-Emptible</link>,
<emphasis>or</emphasis> they are synchronously executed by the
innermost loop, at integer multiples of its sample times.
</para>

</section>


</section>


<section id="applications-xyz">
<title>XYZ</title>
<para>
An XYZ device is a set of one, two or three ActuatedAxis devices, with
the following more specific features: the axes are 
<emphasis role="strong">prismatic</emphasis> and
<emphasis role="strong">orthogonal</emphasis>, and the application
adds <emphasis role="strong">precise synchronization</emphasis>
between the different ActuatedAxis devices.
The data objects in the XYZ control level are
<emphasis role="strong">Cartesian</emphasis>: they indicate positions
in the real world, independently of the coordinates of the axes.
</para>

<section id="xyz-architecture">
<title>Architecture</title>
<para>
The architecture follows from the application description above: XYZ
is a control loop around a set of ActuatedAxis controllers. Because of
the precise synchronization needs, both layers have
<link linkend="real-time-interaction">real-time interaction</link>.
</para>

</section>


<section id="xyz-commands">
<title>Commands</title>
<para>
The <emphasis>steady state</emphasis> Command is a desired position or
velocity (in 1D, 2D or 3D).
The <emphasis>Component configuration</emphasis>,
<emphasis>Power configuration</emphasis> and
<emphasis>Homing</emphasis> are similar (not identical!) to those
of the <link linkend="actuated-axis-commands">ActuatedAxis</link>,
but the latter adds <emphasis>synchronization</emphasis> between the
homing tasks of all axes.
</para>

</section>


<section id="xyz-data-flow">
<title>Data flow</title>
<para>
Similar to the highest level of the
<link linkend="actuated-axis-commands">ActuatedAxis</link>, but the
objects (position, velocity, force, &hellip;) are now Cartesian.
</para>

</section>

<section id="xyz-events">
<title>Events</title>
<para>
Again similar to those of the highest level of the
<link linkend="actuated-axis-commands">ActuatedAxis</link>, but the
axis synchronization for the homing needs its own extra 
<emphasis role="strong">Home</emphasis> Command, whose handler
collects the homing events of the individual axes, and whose completer
waits until all axes are homed before declaring the XYZ device homed
by firing the <emphasis role="strong">XYZHomed</emphasis> event.
</para>
</section>


<section id="xyz-functions">
<title>Functions</title>
<para>
The Generator performs interpolation in the Cartesian space; 
algorithms are typically not much more complex than the 
<link linkend="actuated-axis-commands">ActuatedAxis</link> algorithms,
because the Cartesian task can only 
<emphasis role="strong">translate</emphasis> the end-point of the XYZ
device. Advanced Generators take the
<emphasis role="strong">dynamics</emphasis> of the device into
account; in this case, the Generator must have knowledge of the device
kinematics and hence it must have access to some data objects of the
underlying ActuatedAxis controller.
</para>
<para>
The Servo also operates on Cartesian objects. Often, it will
execute independent servo algorithms on each of the
<emphasis>coordinates</emphasis> of the Cartesian motion objects.
</para>
<para>
The Effector transforms the result into 1D instantaneous
and independent setpoint Commands for the ActuatedAxis controllers; it
needs to know the exact <emphasis role="strong">kinematics</emphasis>
of the XYZ device; these kinematics remain hidden in the Effector
as a &ldquo;hot spot&rdquo;.
</para>
<para>
If not empty, the Estimator is not much more complex than the
ActuatedAxis Estimator, because of the &ldquo;orthogonal&rdquo; nature
of the XYZ application.
</para>

</section>


<section id="xyz-behaviour">
<title>Behaviour</title>
<para>
The XYZ level should run with the same real-time behaviour as the
top-most level of the ActuatedAxis application it works with.
</para>

</section>


</section>


<section id="applications-pointing-device">
<title>PointingDevice</title>
<para>
Very similar structure as
<link linkend="applications-xyz">XYZ</link>, but now running on top of
rotational ActuatedAxis applications.
</para>
<para>
This means that some functionalities become a bit more complex,
because orientational motions have a more involved mathematics than
pure translations. Conceptually, however, everything remains the same
with respect to the XYZ application.
</para>

</section>


<section id="applications-serial-manipulator">
<title>SerialManipulator</title>
<para>
The serial connection of a number of
<link linkend="applications-actuated-axis">ActuatedAxis</link>
objects, with revolute joint axes for robots, or prismatic and
revolute axes for 4D or 5D machine tools. So, it has more complex
Commands, Data objects, Component functionalities and Events than
the <link linkend="applications-actuated-axis">ActuatedAxis</link> and
<link linkend="applications-xyz">XYZ</link> applications, but 
the same Architecture and Behaviour.
</para>

<section id="serial-manipulator-data-flow">
<title>Data flow</title>
<para>
</para>

</section>


<section id="serial-manipulator-functions">
<title>Component functionalities</title>
<para>
</para>

</section>


</section>


<section id="applications-pkm">
<title>PKM (Parallel Kinematics Machine)</title>
<para>
Same Commands, Behaviour, Architecture, Data objects and Events as the
<link linkend="applications-serial-manipulator">SerialManipulator</link>,
but other Component functionalities, depending on the kinematics.
</para>

<section id="pkm-architecture">
<title>Architecture</title>
<para>
</para>

</section>


<section id="pkm-data-flow">
<title>Data flow</title>
<para>
</para>

</section>

<section id="pkm-events">
<title>Events</title>
<para>
</para>
</section>


<section id="pkm-functions">
<title>Component functionalities</title>
<para>
</para>

</section>


<section id="pkm-behaviour">
<title>Behaviour</title>
<para>
</para>

</section>


</section>


<section id="applications-mobile-manipulator">
<title>MobileManipulator</title>

<section id="mobile-manipulator-architecture">
<title>Architecture</title>
<para>
</para>

</section>


<section id="mobile-manipulator-data-flow">
<title>Data flow</title>
<para>
</para>

</section>

<section id="mobile-manipulator-events">
<title>Events</title>
<para>
</para>
</section>


<section id="mobile-manipulator-functions">
<title>Component functionalities</title>
<para>
</para>

</section>


<section id="mobile-manipulator-behaviour">
<title>Behaviour</title>
<para>
</para>

</section>


</section>


</article>