Much effort is generally
used in building models in the control and other communities. In
relation to control two types of model are used, the design models
that are the basis for designing the control and the validation model
which is used for validating the design. The design model is normally
a simplified version of the validation model. It can be observed
regulaly that the effort of building the models is far greater than the
effort devoted to designing and validating the controller. This is
normally very apparent in student projects.
Good graphical model
building and simulation tools like for instance SIMULINK have been
available for a number of years makeing model building much easier,
but the status is the to much modelling is still done from scratch.
The reuse of models are often made difficult because of different
incompatible input/output convensions for the blocks and because
parameters are not easily changed. Often these are in-line parameters.
For instance the appearance of component libraries is not very clear.
Less widely used systems like Dymola and Omola has the concept build
in. Furthermore the transision from validation model to design model
and reverse is often difficult and time consuming. In order to make
the validation model more `correct' nonlinearites etc. has to be added
manually and are not easily removed.
The MSL can be seen an
attempt to introduce some features that (if available in new
simulation/modelbuidling language) will enhance the productivity of
model designers generally and through the MSL prototype implementation
in SIMULINK also as an attempt to set guidelines for building resuable
models specifically in this language. Finally some ways of improving
SIMULINK is suggested in view of the protoype implementation.
At the first glance
Simulink seems like a system well suited for modelling continuous
system. However if certain guidelines are not followed regarding the
structure the resulting models do not become very reusable. The
problems faced are choice of input/output signals for the blocks,
choice of level of granularity and finally the way parameters for a
specific component. has to be entered.
The concept behind MSL is to
suggest several new features that will enhance current modelling and
simulation tools. The implementation of the features are not linked to
the MATLAB/Simulink environment but could be implemented in other
The aim of the development
of the Mechatronics Simulink Library (MSL) has been the make a domain
independent library of component models to be used for modelling
electromechanical systems. The design should be able to use the blocks
without a detailed domain specific knowledge and the resulting models
should be well suited for solving control problems. The domain
specific knowledge is embedded in the Simulink blocks and makes it
useable for designers without much domain specific knowledge.
An important feature of MSL
is that the users can choose the component models from a library.
Typically the library contains a number of generic component models
and a number of models of the specific components that are available
to the designer. These component models eliminate the need to model
common components each time they are to be used in a system, likewise
it is not necessary to find the values of parameter in data sheets, as
the data for the different component types are contained in the
library. Furthermore the inclusion of new specific component models is
easy using the generic component models.
For some types of components
inputs and outputs are simple to choose, for instance in the case of
the potentiometer where the input is the shaft position and the output
is the voltage and the supply voltage can be treated as a parameter.
The problem is more difficult if a DC motor is considered where either
the armature current or the voltage can be seen as inputs and the
output could be the shaft speed for a given load intertia and torque.
The importance of a structured approach to choosing the input, output
and parameters is clear, because of the complications related to
changing component models and connecting different system models.
In the MSL system the
parameters are put into two different categories. One for parameters
that are typically constant and well determined for the component type
and one for the parameters that are less determined and that could be
changed in the course of the use of the model. The border line between
the two categories are not quite well defined, but it is rather easy
to move a parameter between the two categories through a modification
of the component model. All data in the first category are collected
in a database implemented as a m-function called msldata .
Data for new component types and new components are simply added using
a standard text editor to the m-file that makes up the database. All
information is kept in one place. The m-file is a function which is
called with the component type and name, for instance
The function is evaluated
in a local context in the mask of the Simulink block are the
parameters are therefore local. These values are taken from the
manufacturers data sheet.
Another important feature
of MSL is the possibility of changing the complexity of the model in a
simple fashion. Each component model reacts to the choice of different
parameters that indicate the desired complexity of the component. The
parameters are noise , saturation , friction
, quantisation and dynamics . The parameters
can be set for the individual components and for the whole system
model, which makes it very easy the evaluate the effect of a given
change of complexity.
There are problems with the
handling of algebraric loops in Simulink. Try tuning the simulation
parameters to get better performance or make a multi-componet model
like the one shown in mslsimplo .
The toolbox has been
compressed and packed into a "zip" file of approximately 62 kbytes.
Save the file as "msl.zip" when your browser prompts you and issue
the following commands to
"unzip" the file:
Go to the directory
where you want to put the toolbox
Please send an e-mail to email@example.com
register, I will send information about new releases.
Be sure that the msl dirctory is included in your
Run the matlab command: mslstat to open the
granularity window and setup som global variables
try switching friction on and off.
Please bear with us. This
is not a commercial product and thus we cannot spare the time for
supporting it. BUT, if you should find a major bug do let us know and
hopefully we can correct it in a future release.
We encourage all users of
the MSL to write us about their successes (and failures?). We are very
interested in hearing where the toolbox is used and for what type of
applications. Since your comments very well may influence future
releases of the toolbox this is also in your own interest!
related to modelling and the use of the MSL concepts are found in
The MSL features have
been used to create a model of the IAU Autonomous Guided Vehicle in
the context of the STVF sponsered project, Eventbased kalman
A mapping of the
efficiency of MATLAB, SIMULINK, RTW, and C coded models are
currently being looked into. This will also contain some guidelines
for the most efficient way of enchancing this efficiency.
The development of MSL was
mainly done in the context of the EU project COPERNICUS CP-10119 Dynamic
Control of Robotic Manipulators - Mechatronics Approach .
1994-2001 by Automation,
Ørsted·DTU, DTU Denmark
By using the toolbox the
user agrees to all of the following.
If one is going to
publish any work where this toolbox has been used, please remember
it was obtained free of charge and include a reference to at least
one of the documents referenced above.
Ole Ravn and IAU do
not offer any support for this product whatsoever. The toolbox is
offered free of charge.
The toolbox is
copyrighted freeware by Ole Ravn/Department of Automation, DTU. It
may be distributed freely unmodified. It is, however, not permitted
to utilize any part of the software in commercial products without
prior written consent of Ole Ravn, The Department of Automation,
THE TOOLBOX IS
PROVIDED "AS-IS" WITHOUT WARRENTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRENTIES OR
CONDITIONS OF MECHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. IN
NO EVENT SHALL OLE RAVN AND/OR THE DEPARTMENT OF AUTOMATION BE
LIABLE FOR ANY SPECIAL, INCIDENTAL, INDIRECT, OR CONSEQUENTIAL
DAMAGES OF ANY KIND, OR DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
DATA, OR PROFITS, WHETHER OR NOT OR/IAU HAVE BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES, AND/OR ON ANY THEORY OF LIABILITY
ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
MATLAB and SIMULINK are
trademarks of The MathWorks, Inc.
Trademarks of other
companies and/or organizations mentioned in this documentation appear
for identification purposes only and are the property of their
respective companies and/or organizations.