MATLAB Digest - May 2003

Applied Simulink Modeling Techniques for
Varying Signal Widths

(Part I.)

The first in a two-part series, this article details modeling techniques for designing Simulink simulations to handle varying signal widths. These techniques address common issues when algorithms need to be applied N times due to simulation parameters. The article uses an example (available for download from MATLAB Central), which is based on a simulation that includes an arbitrary number of vehicles. The feature of having an arbitrary number of vehicles directly translates to a simulation with an arbitrary number of states that, in turn, has the major challenge of accommodating varying signal widths within the simulation. There are various realizations of a given algorithm within Simulink, just as with any programming language. The methods discussed here will allow realizations to be independent of signal width, thus allowing varying width for various configurations of the simulation.

Along with recounting the history of the topic and introducing the simulation, this article addresses the following areas by providing examples and examining subsystems:

Exploiting inherent Simulink capabilities, such as bus signal usage, scalar expansion of inputs and parameters, and algorithm implementations independent of input signal width
Taking advantage of Simulink execution stages, including signal-specification blocks and block parameter evaluation
Using the DSP Blockset and inherent Simulink matrix capabilities
Applying Simulink looping constructs

These articles concentrate on the modeling techniques featured in "Building Multi-UAV Simulation Methods" [1], emphasizing the relevant Simulink (and Simulink add-on tools) capabilities.

Coming in the next issue of MATLAB Digest, Part II will discuss how to use Stateflow and Virtual Reality APIs to generalize Stateflow charts and VRML worlds.

Applying Collaborative Gaming Theory to the Motion of Unmanned Vehicles

Anderson and Robbins introduced "Formation Flight as a Cooperative Game" [2], which applies collaborative gaming theory to the motion of unmanned air vehicles. Collaborative gaming theory attempts to characterize the type of group dynamics exhibited in schooling fish, flocking birds, and herding land animals. The decisions that dictate each group member's motions can be based on instincts for each member. This set of instincts drives the decisions (or control input) for each group member. Each member's reaction to these instincts can be represented by mathematical expressions.

Anderson and Robbins discussed how unmanned air vehicles can interact and be controlled as a single group. The vehicles are allowed to move individually yet each aircraft's motion is based on the positions and motions of all aircraft as well as their positions relative to targets and obstacles. Collaborative control is thus defined as the application of collaborative gaming theory toward controls problems - or, in this instance, control of an arbitrary number of unmanned air vehicles. The set of instincts used in Anderson and Robbins and reproduced here are:

Collision avoidance
Obstacle avoidance
Target acquisition
Formation keeping

The benefits realized in migrating the existing Anderson and Robbins M-file based simulation to the Simulink environment was the subject matter of "Building Multi-UAV Simulation Methods" [1] and are briefly summarized here.

Easily changing between a large number of integration solvers
Using a graphical block diagram model to communicate model hierarchy and function as the executable specification
Adding a state machine using Stateflow
Driving a VRML world while the simulation executes
Generating code for a variety of purposes, such as RSIM for stand-alone batch simulation runs or embedded-code format for embedding the control logic on a microprocessor

Introducing the Simulation

Figure 1 represents the highest level of the simulation. The three subsystem blocks that form the feedback loop completely house all the dynamics and control of the simulation. These blocks are divided into these parts:

Part 1:	The vehicle(s), which takes commands as inputs and then outputs each vehicle state
Part 2:	The instincts, which take the states of all vehicles and then outputs the desired states for each vehicle based on the instinct calculations
Part 3:	The control law, which takes the desired and actual states and then computes the commands to drive each vehicle to the desired state

The commands generated in Part 3 are the inputs in Part 1, thus forming an autonomous loop closure that constitutes the multi-UAV simulation model.

Figure 1: Root level of the simulation. Click on image to see enlarged view.

The three subsystem blocks that form the loop in Figure 1 are valid for any number of vehicles and any number of obstacles/targets, allowing for varying signal widths inside them without resorting to changing the subsystem block structure (blocks and signal wiring). The various inherent Simulink features that follow help create subsystems that exhibit behavior independent of signal widths.

Exploiting Inherent Simulink Capabilities

Bus Signals

Using bus signals is a convenient way to group and pass sets of signals throughout the diagram, where at any point you can extract any desired subset of information. Simplifying the model visually and organizationally, bus signals are visible in the root level of the simulation (Figure 1), which are the inputs/outputs in the closed loop description above. For example, if you examine annotation A in figure 1, you will notice that the signal width states 9{45}. This information shows that nine signals are inside this bus, consisting of 45 total signal elements. Since the output of the vehicle block is the state vector information, you can deduce that there are five vehicles in the current view. It will be shown that by simply changing the number of vehicles, this signal will update accordingly; so, seven vehicles registers as 9{63}.

Scalar Expansion

Scalar expansion is the conversion of a scalar value into a non-scalar array of the same values. All core Simulink blocks have a set of characteristics listed in the documentation at the bottom of each block reference of which scalar expansion is one (see Gain block as an example). An upcoming example will show how this feature can help the Simulink programmer.

Taking Advantage of Simulink Execution Stages

A Simulink model executes in stages. The two main stages are initialization and simulation.

Initialization - In this phase, Simulink incorporates library blocks into the model; evaluates block parameters; propagates widths, data types, and sample times; determines block execution order; and allocates memory.
Simulation - Simulink then enters a simulation loop, where each pass through the loop is referred to as a simulation step. During each simulation step, Simulink executes each of the model's blocks in the order determined during initialization. For each block, Simulink invokes functions that compute the block's states, derivatives, and outputs for the current sample time. This continues until the simulation is complete.

Understanding the initialization stage is paramount to constructing simulations, such as this article's example. The following sequence of events occurs during the initialization stage.

Evaluating block parameters - At initialization stage start, all parameter fields in blocks are evaluated. Examples of parameter fields include the value of a Gain block, the value of a Constant block, and the initial condition in an Integrator block. These values can be any valid MATLAB expression that returns values accepted by the particular parameter field, including double, string, uint32, etc.
Propagating signal widths (and data types) - Simulink identifies all signal sizes and data types at this point by identifying any defined widths and propagating them forward as appropriate. Once that is complete, any unidentified widths may be resolved via back propagation and, if still left unidentified, they default to scalar doubles. If there are any conflicts after this propagation stage, an error results and the process halts, requiring the user to investigate the signal width propagation errors.
Allocating memory - The appropriate amount of memory for simulation is allocated at this time, considering all the required signals and variables for the simulation. This is why Simulink does not currently have dynamic signal widths during simulation. You must parameterize the simulation so that the correct amount of memory required for simulation is allocated at initialization.

Although an example was not extracted from this model, Signal Specification blocks give you more control over the diagram and propagation and help ensure (and define) proper initialization. These blocks give Simulink more information in the signal propagation stage. You should use them when possible and necessary.

The Simulink block parameter fields can be parameterized with any valid MATLAB expression. Signal Specification blocks ensure proper forward and backwards propagation by dictating signal properties instead of deducing them from the initialization stage. Without these blocks, debugging signal propagation errors can be difficult because the block location of the actual error and conflict may be caused by forwards or backwards propagation that was initiated far (in terms of model hierarchy) from the error itself.

Examining a Subsystem

The subsystem, vehicles/Instincts/Collaborative Instincts/target acquisition instinct calculations/desired heading and velocity capture, (shown in Figure 2) will help you understand how to use these features together to allow for varying signal widths by examining the following annotations.

Figure 2: Sample subsystem. Click on image to see enlarged view.

Block Parameter Evaluation

The block identified by annotation A is an example of using the block parameter evaluation. It is a Constant block with initthis('desired_vel',num_ac) as the expression entered in the parameter value field. INITTHIS is an M-file function written to return certain initial values based on two function arguments: variable to initialize and number of vehicles. This approach gives you complete access to MATLAB, including the benefits of its various toolbox commands and scripting language. This approach also lets you locate all initial-condition calculations from one area and takes advantage of the three steps in the Simulink initialization stage (introduced above). Those initialization steps are the evaluation of the block parameter, which in turn allows Simulink to propagate the signal width of the Constant block as 5x3 to other blocks, which then allocates memory according to a simulation run of five vehicles. All of this is accomplished automatically.

Bus Usage

Annotation B is an example of bus usage, which allows information to pass simply and concisely throughout the diagram. It shows how the state vector bus that came out of the root subsystem (Figure 1) can be routed anywhere that state information is needed. In this case, certain states that needed to calculate each vehicle's inertial velocity value are extracted at the time the calculation will occur.

Scalar Expansion of Inputs and Parameters

Annotation C shows various examples of scalar expansion. Scalar expansion is a property exhibited by many blocks that allow you to disregard signal-width or parameter-width issues because values are expanded appropriately to accommodate the necessary math operations. The two summation blocks are identical; yet notice that the signal widths entering both blocks show scalar expansion occurring on input signals for the case involving the subtraction of unity. Scalar expansion on block parameters is occurring for both Gain blocks in this subsystem, showing a single gain value applying to all block inputs.

Algorithm Implementation Independent of Input Signal Width

Annotation D shows an algorithm implementation using blocks that can be used for arbitrary lengths of input values. Points to notice are the three uses of the Math Function block as well as the Absolute Value block. These blocks perform a given operation on all inputs to them. Many users tend to use the Simulink Function block for similar operations, but that block is not appropriate for cases such as this because it takes a vector input and then references into it by element. It is not possible to generalize it on variable width inputs. Figure 3 shows how the algorithm associated with annotation E would appear in a Simulink Function block. You cannot modify this single block to allow the same mathematical operations occur to two input values of vel_error_mag.

Figure 3: Sample function block approach.

DSP Blockset and Inherent Simulink Matrix Operations

The DSP Blockset complements and extends inherent Simulink matrix capabilities for many applications, including those outside signal processing. Matrix signals were used extensively throughout this simulation in conjunction with the DSP Blockset, which helped in validating particular algorithms for variable signal widths. The subsystem shown in Figure 2 is also an example of using matrix signals extensively.

The DSP Blockset contains matrix operations that are often found in signal processing applications, yet those same matrix capabilities are useful in many other applications. The Matrix Sum block from the DSP Blockset appears as annotation F in Figure 2. Simulink itself has substantial matrix capabilities that include the scalar expansion features discussed above, as well as blocks for matrix operations, such as matrix concatenation (annotation G, Figure 2).

Statistics on library usage were extracted from the example model (see commands SLDIAGNOSTICS, LIBINFO) to show relative use of the DSP Blockset in comparison to all other blocks in the simulation. DSP blocks constitute approximately 60% of all library blocks (96 total) in the model. Moreover, approximately 99% of the library blocks relate to a matrix capability. For a detailed breakdown of which blocks were used in our example and number of occurrences, see Appendix A.

Applying Simulink Looping Constructs

Looping constructs is another approach to parameterizing Simulink diagrams to handle variable signal widths. You should attempt to vectorize operations whenever possible (just as in MATLAB m-coding and annotation E in Figure 2) to compensate for the computational inefficiency associated with loops. When that option is not available, as in the following example, there are other options available to the Simulink programmer, such as For and While Iterator blocks.

This multi-UAV application uses looping constructs because pieces of the control algorithms are a function of parameters such as number of vehicles, number of obstacles, or number of targets. These varying parameters do not change the simulation model structurally, but do call for repetitive calculations across signal data. The particular example shown in Figure 4 will be reviewed.

Figure 4: Looping construct example. Click on image to see enlarged view.

In Figure 4, the main element is a For Iterator block labeled "Distance from Obstacles Calculator," which calculates the distance from each vehicle to each obstacle. The output of this For Iterator block will be referred to as the distance matrix. Inspecting the signal widths visible in the figure reveal there are five vehicles and three obstacles in this simulation run. The For Iterator block is parameterized with the number of vehicles (num_ac) and the initial distance matrix [3x5] as two of its three inputs. The operations within "Distance from Obstacles Calculator" are:

The distance to each obstacle is calculated for each vehicle. This is a scalar value that is calculated within a nested For Iterator (not shown).
This scalar value populates an element column wise of the final distance matrix.
Once a column that houses how far a given vehicle is from each obstacle is complete, it is written to the corresponding column of the final matrix.
This is repeated for all vehicles until the final matrix is fully populated, and becomes the output of the For Iterator shown in Figure 4.

Using looping constructs repeats a given set of calculations that are parameterized on a number of vehicles and/or obstacles. The repeated calculations are housed within the looping construct block itself (the For Iterator in this case).

This article reviewed various applied modeling techniques for handling varying signal widths within a Simulink simulation. This topic was chosen in response to customer questions regarding the many applications available in using these methods. The goal was to help demonstrate some of these techniques using Simulink in a real-life example. There are instances when more than one approach could be used for any given algorithm, just as with any programming language. Appearing in the next issue of MATLAB Digest, Part II will show examples using the Stateflow and VR APIs for the same reason.

References

[1] Lluch D., "Building Mutli-UAV Simulation Methods," Paper No. AIAA-2002-4495, AIAA MST, 2002
[2] Anderson M., Robbins A., "Formation Flight as a Cooperative Game," Paper No. AIAA-98-4124, AIAA GNC, 1998

Appendix A

To locate and inspect applications of these blocks, use the Simulink Finder (or FIND_SYSTEM). The field to search against is 'ReferenceBlock'. For example, find_system('vehicles','ReferenceBlock','dspmtrx3/Extract Diagonal').

Total blocks in model:	706
Total blocks linked to libraries:	96 57 39
DSP library related: (10 unique blocks) All other libraries: (4 unique blocks)	96 57 39
DSP library related:	57 5 5 48 6 2 8 16 10 1 5 4 1 3
dspindex: (1 unique blocks) Multiport Selector dspmtrx3: (7 unique blocks) Create Diagonal Matrix Extract Diagonal Matrix Scaling Matrix Sum Matrix Multiply Permute Matrix Transpose dspstat3: (2 unique blocks) Maximum Minimum	57 5 5 48 6 2 8 16 10 1 5 4 1 3
Other libraries:	39 14 16 8 1
simulink/Math Operations/Matrix Concatenation simulink/Math Operations/Reshape simulink/Signal Attributes/Signal Specification vrlib/VR Sink	39 14 16 8 1

Products & Services	Industries	Academia	Support	User Community	Company