general-dynamics-doc.sgml

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

<emphasis>position</emphasis> (<emphasis>integral</emphasis>
of velocity), and <emphasis>acceleration</emphasis>
(<emphasis>derivative</emphasis> of velocity).
</para>
<para>
Changes in <emphasis role="strong">stored</emphasis> energy are
mathematically represented by the
<emphasis role="strong">ordinary differential equations</emphasis>
(ODEs) of Newton's Law (relationship between force and acceleration),
and Hooke's Law (relationship between force and position). The
relationship between force and velocity corresponds to
<emphasis role="strong">dissipation</emphasis> of energy
(&ldquo;damping&rdquo;, such as friction).
</para>
<para>
The joint interconnections between impedances introduce
<emphasis role="strong">algebraic constraints</emphasis>: a joint puts
constraints on the relative force and velocity of the mechanical
objects it connects.  The <emphasis>causality</emphasis> (i.e.,
whether the force or the velocity is the <emphasis>input</emphasis> of
the constraint equation, or the output) of joint constraints is not
defined by default.  Also dampers and motors are represented by
algebraic constraints, but then in the form of
<emphasis>input/output conditions</emphasis>.
</para>
<para>
The set of all ODEs and algebraic constraints together is called a set
of
<emphasis role="strong">Differential-Algebraic Equations</emphasis>
(DAE).
</para>
<para>
The algebraic constraints are often the result of a
&ldquo;low-resolution&rdquo; modelling: ideal
(&ldquo;kinematic&rdquo;) constraints such as a
<emphasis>revolute joint</emphasis> or a
<emphasis>point&ndash;plane</emphasis> contact are in the physical
reality approximations of more complex (and typically much faster!)
dynamics , i.c., flexibilities in the joint and the contact. Ideal
sources (i.c., motors) or sinks (i.c., dampers) of energy have their
own dynamics, when modelled in more detail. And, in order to be
complete, the modelling should be extended to include thermodynamics!
However, more complete dynamic models typically have a much larger
number of parameters and differential equations (but less algebraic
constraints!). So, exchanging algebraic constraints for more
parameters and differential equations seems to be a small or even
negative gain, but, in practice, all DAE solvers introduce
&ldquo;elasticities&rdquo; behind the screens anyway, in their
iterative numerical algorithms.
</para>
<para>
The physical and mathematical properties of the above-mentioned
mechanical domain components (impedances, joints, motors), as well as
their interconnections in the form of special families of
<emphasis>kinematic chains</emphasis> are described in
<ulink url="kindyn-doc.html">another document</ulink>.
</para>

</section>


<section id="dynamic-systems-general">
<title>General dynamic systems</title>

<para>
The discussion for mechanical systems can be completely repeated for
other dynamic systems, such as electrical or pneumatic networks.
This fact is the basis of general mathematical approaches such as
system theory or Bond Graphs.
</para>
<para>
In Bond Graph terminology, a complex dynamic system consists of
energy storing/transforming/dissipating elements, connected by
energy-conserving &ldquo;bonds&rdquo;. The bonds contain two
complementary &ldquo;signals&rdquo;,
<emphasis role="strong">effort</emphasis> and
<emphasis role="strong">flow</emphasis>, whose product is energy.
Current and velocity are examples of flows in, respectively, the
electrical and mechanical domains; voltage and force are the
corresponding efforts.
</para>
<para>
Complex systems consist of the interconnection of simple elements.
The same system can be modelled by different interconnection
structures. For example, the Bond Graph interconnection structure of
an electrical network looks quite different from the &ldquo;iconic
diagram&rdquo; structure (i.e., using icons for resistors, sources and
coils). Of course, the various structures can be transformed into each
other.
</para>
<para>
Each form is most appropriate for different aspects of the whole
problem; e.g., iconic diagrams are more &ldquo;user-friendly&rdquo;
than an equivalent Bond Graph structure, which is more appropriate to
derive the system's DAEs. Moreover, one particular system
can often be represented by different structures, even of the same
type; for example, the Norton and Thevenin equivalents of the same
electric network are both iconic diagrams, using the same elements but
(at first sight) another interconnection structure. Of course, the
physical information in the alternatives is exactly the same.
</para>
<para>
In summary, any dynamic system can be modelled and simulated with the
four
<link linkend="dynamic-systems-modelling-simulation">above-mentioned</link>
components: elementary objects with their constitutive relationships;
interconnection structures; sets of DAEs; and numeric algorithms to
solve these DAEs. The different domains only differ in the terminology
and some details of the constitutive relationships; all other aspects
are shared by all domains.
</para>

</section>

</section>


<section id="dynamic-systems-constitutive-relationships">
<title>Constitutive relationships</title>

<para>
This Section lists the constitutive relationships of the elementary
objects from the various domains, with an emphasis on the mechanical
and electrical domains, because these are most relevant for &orocos;.
(See, for example,
<ulink url="http://www.modelica.org">Modelica</ulink> for more
detailed descriptions.)
</para>


<section id="dynamic-systems-mechanical-objects">
<title>Mechanical objects</title>
<para>
Mechanical impedances: spring, rigid body.
</para>
<para>
Constraints: revolute joint, prismatic joint, helical joint,
vertex-plane, edge-plane, edge-edge, plane-plane.
</para>
<para>
Sources: rotational motor, torque source, force source.
</para>
<para>
Sinks: damper.
</para>

</section>


<section id="dynamic-systems-electrical">
<title>Electrical objects</title>
<para>
Electrical impedances: coil, condensator.
</para>

</section>


</section>


<section id="dynamic-systems-interconnections">
<title>Interconnections of elementary objects</title>

<para>
The
<ulink url="decoupling.html#OPC-PATTERN">Object-Port-Connector</ulink>
concept models interconnections of elementary dynamic elements:
<itemizedlist>

<listitem>
<para>
The elementary <emphasis role="strong">Objects</emphasis> encode the
dynamics, in the form of the so-called <emphasis>constitutive
relationships</emphasis>.
</para>
</listitem>

<listitem>
<para>
Each <emphasis role="strong">Port</emphasis> on the Object
&ldquo;exports&rdquo; a couple of effort and flow
variables, i.e., it indicates a place where the Object can exchange
energy with other Objects.
</para>
</listitem>

<listitem>
<para>
A <emphasis role="strong">Connector</emphasis> makes an
inter-connection between two Ports, i.e., it links compatible effort
and flow variables of both Ports. This link gives rise to one or more
<emphasis role="strong">algebraic constraints</emphasis> between the Port
variables at both connected Objects.
</para>
</listitem>

</itemizedlist>
<xref linkend="fig-graph-opc"> shows an example of a
&ldquo;complex&rdquo; system constructed by interconnecting the Ports
on Objects, by means of Connectors. The arrows on the edges between
Ports and Connectors indicate the (arbitrarily chosen) direction of
positive energy (or signal) flow.
</para>
<para>
<figure id="fig-graph-opc" float="1" pgwide="0">
<title>
An interconnection structure with Objects (rounded rectangles), Ports
(small circles), and Connectors (ovals).
</title>
<mediaobject>
<imageobject>
<imagedata fileref="../pictures/graph-opc.png" format="PNG">
</imageobject>
<imageobject>
<imagedata fileref="../graph-opc.eps" format="EPS">
</imageobject>
</mediaobject>
</figure>
</para>


<section id="dynamic-systems-opc-hierarchy">
<title>Hierarchical models</title>
<para>
</para>

</section>


<section id="dynamic-systems-opc-visualisation">
<title>Visualisation connections</title>
<para>
</para>

</section>

</section>


<section id="dynamic-systems-sofware-patterns">
<title>Software patterns</title>

<section id="dynamic-systems-patterns-ops">
<title>Object-Port-Connector</title>
<para>
<ulink url="decoupling.html#OPC-PATTERN">Object-Port-Connector</ulink>
type checking, determination of dependencies, causality determination,
model reduction, connecting secondary properties, 
</para>

</section>


<section id="dynamic-systems-patterns-factory">
<title>Factory</title>
<para>

</para>
</section>
                                                                                
                                                                                
<section id="dynamic-systems-patterns-ccm">
<title>CORBA Component Model (CCM)</title>
<para>
CORBA component model: what is needed to make a piece of software
&ldquo;stand-alone&rdquo; in a larger complex, distributed system.
<emphasis>Middleware</emphasis> standard, that covers all the
recurring properties: name serving, network transparancy, state,
transactions, recovery, object browsing, &hellip;
</para>

</section>


</section>


<section id="dynamic-systems-api">
<title>API</title>

<para>
The modelling and simulation of complex, possibly multi-domain
dynamic systems needs a <emphasis>factory</emphasis> to support the
error-free construction of the systems by interconnecting simpler
systems.
</para>
<para>
NewChain, NewJoint, NewMotor, NewImpedance,
NewPort, NewConnector, ConnectPorts, DisconnectPorts, etc.
Lots of things still missing&hellip;
</para>

</section>

</article>