general-dynamics-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>
    Modelling of Complex Dynamic Systems
  </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="general-dynamics-doc.xml">XML file</ulink>.
</holder>
 </copyright>


 <abstract>
 <para>
 <emphasis role="strong">Abstract</emphasis>
 </para>
 <para>
This document describes the software design for complex
dynamic systems, where the complexity comes from the interconnection
of multiple simple dynamic components. In the context of &orocos;,
complex kinematic chains are the focus point, but the presented design
covers also other physical domains with lumped-parameter systems:
electrical, hydraulic, pneumatic networks, etc.
</para>
<para>
The design covers the following aspects: the modelling of the
(physical) properties of elementary system building blocks; the
modelling of their interactions; the generation of the mathematical
equations that represent the system's dynamic behaviour; and the
calculation of the time-variations of all relevant system variables.
</para>
<para>
In addition to the modelling of the energy-exchange and
&ldquo;signal&rdquo; properties of a complex dynamic system, the
design also covers graphical representations and
&ldquo;factory-based&rdquo; construction and maintenance.
</para>
 </abstract>

 <revhistory>
  <revision>
    <revnumber>0.01</revnumber>
    <date>July 13, 2003</date>
    <authorinitials>HB</authorinitials>
	 <revremark>
Removed the corresponding section from the 
<ulink url="kindyn-doc.html">kinematics and dynamics</ulink> document,
and started this document. First draft of the description of the
properties of complex systems.
    </revremark> 
  </revision>
  <revision>
    <revnumber>0.02</revnumber>
    <date>August 12, 2003</date>
    <authorinitials>HB</authorinitials>
	 <revremark>
Heavily reworked. More structure about modelling and simulation.
Introduced the Software Patterns and Factory sections. 
    </revremark> 
  </revision>
 </revhistory>

</articleinfo>


<section id="introduction">
<title>Introduction</title>
<para>
There is a huge difference between designing and using software for a
simple, small-scale and a complex, large-scale
application.  In simple applications,
the developers can build software components that they can
oversee completely, have full access to, and in which they can make
direct method calls on all the objects that live in the system.
However, in the case of a complex system, the developers do not have a
full overview of the whole system, they can not know or access all of
the code, and users interconnect components in multiple ways
(including &ldquo;component-based&rdquo; access over a network, i.e.,
without linked objects).
</para>
<para>
Therefore, complex systems need 
<emphasis role="strong">more extensive infrastructural support</emphasis>
than simple systems, in order
(i) to guarantee that components are interconnected correctly by
construction,
(ii) to allow bookkeeping during the execution of algorithms working
on the complex system, and
(iii) to simplify the construction of complex systems by end users.
This document describes such infrastructural support, basing its
discussions on
<link linkend="dynamic-systems-sofware-patterns">Software Patterns</link>
wherever possible, because these represent proven solutions to common
design problems.
</para>


<section id="dynamic-systems-modelling-simulation">
<title>Modelling and Simulation</title>

<para>
<emphasis role="strong">Modelling</emphasis> of a system consists of
making a mathematical abstraction of the system; the model must
represent the system's phenomena that the developers are interested
in, at an &ldquo;appropriate&rdquo; level of detail. The major aspects
of modelling are: 
<orderedlist>

<listitem>
<para>
the dynamic properties of each member of the set of
<emphasis role="strong">elementary objects</emphasis>.
</para>
</listitem>

<listitem>
<para>
the <emphasis role="strong">connectivity</emphasis> between these
elementary objects.
</para>
<para>
Each connection between two objects introduces a
<emphasis role="strong">constraint</emphasis> on the dynamic
properties of both objects.
</para>
</listitem>

</orderedlist>
</para>
<para>
The literature on <emphasis>Bond Graphs</emphasis>, and the
documentation on the
<ulink url="http://www.modelica.org">Modelica</ulink> project, contain
a lot of relevant information about these two modelling aspect.
Modelica publishes domain-independent software specifications, as well
as domain-dependent libraries. (But there is no source code or design
documentation available on the web site.) 
</para>
<para>
<emphasis role="strong">Simulation</emphasis> of a system consists of
using the system's model, specifying boundary conditions and initial
values, and calculating the (time-varying) values of the system
variables one is interested in. The same model can be used for many
different simulation purposes, depending on the system variables the
user is interested in, and on the boundary and initial values.
The major aspects of simulation are: 
<orderedlist continuation="continues">

<listitem>
<para>
the <emphasis role="strong">generation</emphasis> of a correct and
efficient set of
<emphasis role="strong">mathematical equations</emphasis> that
faithfully represent the modelled system.
</para>
<para>
All (&ldquo;lumped-parameter&rdquo;) physical systems are represented
by a set of 
<emphasis role="strong">ordinary differential equations</emphasis>,
accompanied by a set of 
<emphasis role="strong">linear algebraic constraints</emphasis>.
Knowing the
<emphasis>interconnection structure</emphasis> of the elementary
objects in the system, helps tremendously in generating a
set of equations that is as computationally efficient as possible.
</para>
</listitem>

<listitem>
<para>
the numerical <emphasis role="strong">integration</emphasis> of these
equations (i.e., calculating the time variation of all relevant
variables).
</para>
<para>
The engineering literature has spent a lot of efforts on finding
general-purpose approaches to efficiently solve such a given set of
mathematical equations, without knowing where they come from. For
example, look up the concepts of Kron's <emphasis>tearing</emphasis>,
or Paynter's <emphasis>reticulation</emphasis>.
</para>
</listitem>

</orderedlist>
</para>
<para>
In many small-scale projects, developers often combine the modelling
and simulation steps (or the above-mentioned sub-aspects of both
steps), because they only have one simulation goal, and they can fully
comprehend the whole system and the whole application in their minds.
However, for complex systems, this is not the case anymore, so, a more
structured approach is needed, with four separate tasks: elementary
object properties; interconnection of elementary objects; generation of
the set of equations of an interconnected system; and solving this set
of equations. An absolutely necessary first step is to fully
<ulink url="decoupling.htnl">decouple</ulink> modelling and
simulation, as outlined above. This documents
<emphasis role="strong">only discusses the modelling.</emphasis>
The properties of the elementary building blocks for complex robotics
systems are discussed in
<ulink url="kindyn-doc.html">another document</ulink>; this document
focuses on the
<emphasis role="strong">interconnection aspects</emphasis>.
</para>

</section>


<section id="dynamic-systems-physical-control">
<title>Physical systems and control systems</title>

<para>
Complex dynamic systems combine both real-world,
&ldquo;physical&rdquo; objects, and virtual &ldquo;control&rdquo; (or
&ldquo;signal processing&rdquo;) objects.
</para>
<para>
The elementary objects in physical systems have properties (or
<emphasis role="strong">constitutive relationships</emphasis>)cribed
by laws of physics: Newton's laws, Kirchoff's laws, etc.
Hence, the interconnections between physical objects carry real
<emphasis role="strong">energy</emphasis>.
</para>
<para>
In control systems, on the other hand, the outputs of an elementary
controller block can be <emphasis>any</emphasis> function of its
inputs. Hence, their constitutive relationships are algorithms.
For example, the
Fast Fourier Transform of a set of physical signals can form an
elementary control block in its own. So, the interconnections in
a control system consist of (energy-less) information
<emphasis role="strong">signals</emphasis>.
</para>
<para>
Physical systems and control systems differ only in the
<emphasis>origin</emphasis> of their constitutive relationships, but
the resulting mathematical representation is a similar set of DAEs in
both cases. Both systems also have similar software needs and
properties for the <emphasis>interconnection</emphasis> of their
elementary building blocks.
</para>

</section>


<section id="mechanical">
<title>The mechanical domain</title>
<para>
Before discussing the software design of 
<link linkend="dynamic-systems-general">general dynamic systems</link>,
this Section briefly explains the modelling needs in the
so-called mechanical domain, i.e., robots, machine tools, etc.
</para>
<para>
Mechanical devices of any complexity can be constructed (in a
<emphasis>lumped-parameter</emphasis> model, at least) by
inter-connecting impedances (springs, dampers, and inertias, i.e.,
&ldquo;rigid bodies&rdquo;), joints and motors.
Rigid bodies and springs can <emphasis>store</emphasis> energy
(kinetic and potential energy, respectively); motors are
<emphasis>sources</emphasis> of energy; dampers (e.g., friction)
<emphasis>dissipate</emphasis> energy; and transmissions and
joints with which all these mechanical components are
<emphasis>connected</emphasis> are ideal
<emphasis>transformers</emphasis> of mechanical energy.  In fact,
dissipators and sources are also transformers, but from one domain to
the other; e.g., a damper transforms mechanical energy into thermal
energy, and a motor is a source of mechanical energy, derived from
electrical energy. These inter-domain transformers are often called
<emphasis>gyrators</emphasis>.
</para>
<para>
<emphasis role="strong">Velocity</emphasis> and
<emphasis role="strong">force</emphasis> are the basic 
properties that define mechanical energy: the product of velocity and
force is <emphasis>power</emphasis>, i.e., the rate of exchange of
mechanical energy.  Velocity has two natural complementary properties: