| SimMechanics™ | |
| On this page… |
|---|
About Dedicated Hardware Targets for Stewart Platform Simulation For More Information About xPC Target™ Software Adjusting Hardware for Computational Demands |
Note This study requires experience with code generation and dedicated hardware deployment. To complete it, you need to have installed the following products, besides MATLAB®, Simulink®, and the SimMechanics™ product: Working first through the preceding case study, Generating and Simulating with Code, is strongly recommended. |
A common step after generating and compiling code from a model is to download the compiled executable to a computer dedicated to running just that application. For a model with a control system, you can download the complete model as a unit or separate the controller and plant into different executables on different computers. You can also execute the controller part as embedded code on a dedicated computer that controls an actual plant. Such application deployments are known as hardware in the loop or rapid prototyping [8].
xPC Target software and Real-Time Workshop allow you to generate and compile code from a SimMechanics model and download it to a computer with an IBM PC-type processor. xPC Target software acts as another target within Real-Time Workshop and requires a fixed-step solver. You can use xPC Target software to implement controller-plant models in many configurations [9].
This case study outlines some model conversion-downloading applications based on the Stewart platform modeled with SimMechanics blocks.
Consult the xPC Target documentation for full instructions on downloading and running executable code in different configurations.
This study requires mech_stewart_xpc, as well as the initialization M-files.
Simulation with a fixed simulation time is subject to the basic tradeoff between accuracy and speed. (See Improving Performance in the Running Mechanical Models chapter.) You can make a simulation more accurate by reducing its step size, but at the expense of creating more time steps and slowing down the real clock time. You can speed up the simulation by increasing the time step size, but you risk losing enough accuracy that the simulation fails to converge.
A typical requirement for code running on dedicated processors is that the simulation run in real time. That is, the compiled code should run with
A finite number of steps (requiring fixed-step solvers)
Execution time no longer than the physical time being simulated
These requirements are particularly critical for controller code.
With SimMechanics models, the accuracy-speed tradeoff is acute. SimMechanics simulation is computationally intensive and become even more so the more closed loops and constraints you add.
With dedicated processor execution, reducing the step size ultimately leads to processor overload. The processor needs more clock time to execute a step than the solver time step allows.
In SimMechanics simulations, convergence failure resulting from too large a time step typically appears as a failure of your simulation to respect constraint tolerances, assembly tolerances, or both.
Simple SimMechanics models require central processor speeds in the mid-hundreds of megahertz (MHz) range. More complex models such as the Stewart platform (with 36 degrees of freedom, as well as 5 independent closed loops and 40 constraints arising from cutting those loops) demand more processor speed, starting in the low gigahertz (GHz) range.
You have two ways to alleviate the conflict between accuracy and speed in real-time simulation.
Increase the processor speed. This allows you to reduce the solver step size while keeping the clock time unchanged.
Break up a complete model into parts, each simulated by its own model downloaded to and executed on a different processor.
Both approaches are complicated by additional factors, such as memory caching and bus speed. Real-time simulation distinguishes between the sample time in signal buses and the solver step size.
Caution Sample time must be a positive integral multiple of solver step size. For SimMechanics models, avoid making sample time larger than step size to prevent simulation convergence failures. |
As a trial of running the Stewart platform simulation on dedicated hardware, here you convert a model to code, then download it and run it on an external PC-type computer. The model requires a processor of speed approximately 2 GHz or faster, and a separate target computer monitor.
Consult the xPC Target documentation for details on preparing the target computer, establishing the host-target connection, and interacting with the target from the host.
The results here were obtained with host and target PC-type computers, each with a 3 GHz Pentium 4 processor and 1 gigabyte of RAM, communicating with each other by an RS-232 connection.
To set up the connection and start the target, you need an RS-232 cable and a blank, formatted floppy disk. The target requires a floppy disk drive. You can observe target simulation on a target monitor, your host monitor, or both.
Connect the host and target computer to one another with their respective RS-232 ports and a cable.
Insert the prepared xPC Target boot disk into the target PC floppy drive. Start the target computer.
After the target has finished booting, confirm the host-target connection.
For this example, you use a variant of the code generation model presented in the preceding study, Generating and Simulating with Code.
The model contains xPC Scope blocks for observing the simulation results later. The Scope type for each is Target. Thus they will appear on the target PC after you download the compiled code.
The controller and plant work with the default Simulink 64-bit floating double data type. To test the effect of the type conversion needed for passing signals on a hardware bus, the model also contains subsystems that convert these floating doubles to fixed-point integers, then back to doubles.
The data conversion truncates the controller-plant data and changes the simulation behavior somewhat. It is critical to test the impact of such changes before deploying the code to hardware.
Open this model, mech_stewart_xpc. Update the diagram (Ctrl+D). The vector signals now appear as wide lines and display their data types.
Stewart Platform with Control Reference Trajectory for xPC Target™ Simulation
Open the Force Conversion and Length Conversion subsystems. Each subsystem converts a vector signal from floating doubles to 16-bit integers (typical of hardware buses) and back to doubles. These subsystems mimic the effect of hardware buses communicating between controller and plant.
Before the data are converted to integer format, they must be converted from floating to fixed point, truncating the floating double signals. The Data Type Conversion blocks that change doubles to fixed points apply scaling to ensure that information lost to truncation is "small," as defined by the force and leg length numbers typical of this simulation. These scalings are set in the Data Type Conversion block dialogs.
Run the model and observe the motion. Afterward, close the Scope.
The difference between this Stewart platform simulation and earlier ones is clear in the Leg Forces scope trace, which exhibits a small level of "noise" after the initial transient has passed. This "noise" is due to data truncation when the floating doubles are converted to fixed point.
In the next steps, you convert the model to code and download it to the target.
Confirm the solver step size (dt1) and sample time (dt2) by entering
dt1, dt2
at the command line. The values are 5.0 milliseconds (ms).
Check the code generation target selection in Configuration Parameters, under the Real-Time Workshop node, Target selection > System target file. The target selection is xpctarget.tlc.
Under the Real-Time Workshop node, check the xPC Target options entry. Leave these default settings.
On the Real-Time Workshop panel, click Build to start code generation.
Follow the progress on the command window, as Real-Time Workshop generates and compiles the model, then downloads it to your target computer. When the download is complete, you see the four empty xPC Target scope windows on the target monitor.
The xPC Target interface creates an object called tg that allows you to control the application on the target machine.
Using the xPC Target interface, start the target application.
The target computer monitor displays the execution. In the Command Window, the xPC Target interface summarizes the execution results.
Stop the target application. The Command Window displays the execution summary. The target scopes display the simulation results.
xPC Target software allows you to observe simulation in various ways. The xPC Target documentation explains the details.
In the first run, you observed target-type xPC scopes on the target monitor.
You can change the Scope type of one or more xPC scopes to Host and observe them on your host computer instead.
The xPC Target interface also allows you to connect and display such scopes while the simulation is running. You can make connecting and displaying scopes during simulation easier by changing the stop time to infinity (inf).
You can make your simulation more accurate by reducing the solver step size. But by requiring more steps, you also make the simulation more intensive. If the solver step size drops below the task execution time (TET), the target processor cannot keep up with the simulation and suffers CPU overload.
The xPC Target summary in the Command Window indicates if CPU overload has occurred when you start or stop target object (tg) execution.
Test for CPU overload by reducing dt1 and dt2.
dt1 = 0.0025; dt2 = 0.0025;
You can understand how close to, or how far into, CPU overload your model is by comparing the TET with the solver/sample time.
If the TET value is smaller than the sample/solver time, the target processor is able to keep up with the solver.
If the TET value is larger than the sample/solver time, the target processor cannot keep up with the solver. CPU overload halts target execution.
You can keep reducing the solver/sample time until you cause CPU overload. This point is the limit of your target processor with this model. You can work around CPU overload by
Using a faster processor. The ratio of TET to sample time indicates roughly how much faster the processor needs to be.
Increasing the solver/sample time. Be sure not to increase it too much, to avoid simulation convergence failures.
See Adjusting Hardware for Computational Demands preceding.
Typical goals of downloading compiled code to a dedicated computer are
Simulating controller and plant in real time
Embedding a discretized version of the controller code on a dedicated computer that controls an actual plant
Controller and plant communicate through a hardware bus configured with a specific data protocol. The xPC Target block library contains communication blocks based on a variety of data protocols matching common hardware buses. In realistic applications, the controller is often already discretized (simulated with discrete states) and requires no conversion from floating point.
The plant simulation remains continuous (not discrete) to better imitate the actual physical system.
Caution You cannot use discrete states with SimMechanics blocks in your model. Discretizing a controller requires separating controller and plant into different models. |
Choose a model and hardware configuration depending on your needs.
Separate controller and plant into different subsystems that communicate through a physical bus interfaced with xPC Target bus blocks, rather than Simulink signal lines. To run such a model on a target requires the target to have the corresponding hardware card and bus cable.
Separate controller and plant into two different models that also communicate through a physical bus interfaced with xPC Target bus blocks. You then download the two models to two separate targets that communicate through a bus cable connected to the corresponding hardware cards.
Once you separate controller and plant into different models, you can discretize the controller.
Embed the controller on a dedicated target that controls an actual Stewart platform. The target and platform communicate through a bus or other I/O hardware corresponding to the blocks used in the controller model.
Real-time simulations are restricted by the tradeoff between accuracy and speed and limited by target execution time and maintaining convergence. You need to ensure that your memory caching and bus, not just your processor(s), are fast enough to cope with SimMechanics computational demands. See Adjusting Hardware for Computational Demands preceding.
| Generating and Simulating with Code | Block Reference | |
| © 1984-2008- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |