DUECA/DUSIME
|
This section describes a large part of the SpacePlane model simulation that has been used as an example in this manual.
This simulation derived from an experiment implemented on the Human-Machine Systems lab of the Control and Simulation Division, Faculty of Aerospace Engineering The simulation model of the equations of motion of the spaceplane, including the control augmentation system, was programmed in one Simulink model. Using the Real-Time Workshop (RTW) toolbox, C code was generated for this Simulink model. Input of the RTW code are the pitch and roll stick inputs, and the output of the code is an output vector with all spaceplane motions.
The simulation was controlled with a control loaded side stick. This stick uses a hydraulic servo motor to simulate mechanical properties, in this case the mechanical properties of a passive (mass, spring and damper) stick.
Instrument display was done on a PC with a fast graphics card. The display is drawn using the output of the RTW model.
In addition to the display output, output to file was needed. The stick force and position data, and the spaceplane model output data, were recorded at a 50 Hz rate. Output to the control position of the experiment leader was also needed, during the run some key variables were shown in a window at the experiment leader's position, and key variables at certain points in the experiment (points along the pre-defined trajectory) were also shown and recorded. In this way it was for example possible to see the sink rate at touch down directly after a run.
Data Flow diagram
The first step in designing the simulation is setting up a (DUECA) data flow diagram. This diagram defines the modules used in the simulation, and the data (types) they send to each other.
The data flow diagram contains the following blocks:
A module MMSLabStick, which reads the input force on the stick (i.e. directly from hardware), calculates the dynamics of the stick simulation, outputs the result of this calculation to the stick (to hardware), and also sends out stick position and force over a channel.
A module SpacePlane, which reads the stick input (position), feeds that to the RTW model, makes an update of the model, and sends out the output vector of the model over a channel.
A module DisplaySpace, which reads the spaceplane output vector, and draws the instrument display.
A module NumericOutput, which reads the spaceplane output vector the stick position and force data, and prints these to a file.
These are all the modules that are needed from a model point-of-view. One other module is added for practical reasons. As will be explained in the following, the stick control loading and the spaceplane model run on different computers. The control loading has to run at a high update rate (2000 Hz), and it also produces data at 2000 Hz. The spaceplane model runs slower (50 Hz), and thus it needs every 40th output of the control loading model. Now, without modifications, DUECA would send the stick data at 2000 Hz to the other computers, where only 1/40 th of this data would be used. An additional routine, called RateReduction, which runs in the computer with the stick module, reads the stick data and writes with only 50 Hz.
The following model-related data types were communicated over the channels:
Here is the file input for the code generator:
(Type double) (EventAndStream PrimaryControls (double stick_roll ) (double stick_pitch ) (double roll_moment) (double pitch_moment) (double roll_rate) (double pitch_rate)) (EventAndStream SpacePlaneY (double Y 29 )) (Type int ) (Event DisplaySelect (int type ))
Here are all header and implementation files for the modules.
First the stick input:
These files use an auxiliary class PassiveStick, which is not included in this manual. Since the HardwareModule class is not complete yet, this uses the SimulationModule class.
The rate reduction class, which simply reads in the stick input and writes it back again. By specifying an update rate for its activity, it assures itself of reading only at the proper times, and writing with the proper TimeSpec.
The space plane module.
This module's calculations are based on a model that was implemented in SimuLink and converted with Real-Time Workshop. For the conversion you should specify the "real time malloc" option, this will enable the code to start up several instances of the same model in one program. A script called "correctSimulink", which is installed with the DUECA program, makes some small corrections to the generated Simulink code. Run this once on the RTW files.
The numeric output module.
The evaluator shows a window on the screen of the experimenter's PC, with current values and overview values. The windowing toolkit that is used is gtk+. With a GUI designer glade, it is easy to draw such a window. A few callback functions (which must have a "C" linkage specification) are written to handle the events from the interface.
You see that there is certainly some code writing in making a module. Fortunately, most of the code can be generated by the script "newModule". This script is installed with the dueca program. Run it with the name of your new module (e.g. MyModule), and it will produce a MyModule.cxx and a MyModule.hxx file. The comments in these files should guide you with the job of tailoring the module to your application.
The example simulation runs on 3 PC's, connected with fast ethernet. The division of modules over the PCs is as follows:
Node number 0 is the experimenter's PC. DUECA runs all administrative duties, and also reads the model data from the dueca.mod file, on node number 0. The following modules are implemented here:
Node number 1 is the control loading PC, running QNX. This PC does the control loading simulation, and it runs the rate reduction module. Since this is the fastest-running PC (cycle-time wise), it is the clock master.
Scheme is a full-fledged programming language, and therefore the model configuration file in fact contains a simple program. To make life a bit easier, we can define often-used variables in the model configuration file as Scheme variables. That is what this first part of the configuration file does:
Dueca itself also needs some modules. Here they are:
And then the modules for the spaceplane are created.
Notice the use of the "if (equal? this-node-id cl-node)" construction. All modules defined within the if statement are designated for that node. If this is not used, the modules will be created in all nodes in parallel, and this would certainly give channel conflicts.