Hardware-in-the-Loop Control System Development

using MATLAB and xPC

Daniel J. Burns Armando A. Rodriguez ∗

Department of Electrical Engineering

Center for System Science and Engineering

Arizona State University

Tempe, AZ 85287-7606

May 26, 2002

Keywords: Realtime hardware control, xPC, Simulink, cart-pendulum, realtime operating system

Abstract

This paper describes the process for control system design using the actual plant for design verification,commonly known as “Hardware-in-the-Loop” (HIL) controller design. The general considerations forHIL design are presented in the context of a cart-pendulum controller implementation. Controller designand simulation is performed in Simulink, and the simulated plant is quickly replaced with blocks thatcommunicate to the hardware cart-pendulum system and compiled into realtime executable code usingxPC – a Simulink toolbox and realtime operating system.

Contents

1 Hardware-in-the-Loop Design Overview 21.1 Hardware Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Software Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2.1 Writing HIL Software using Event-Driven Operating Systems . . . . . . . . . . . . . . 31.2.2 Writing HIL Software using Realtime Operating Systems . . . . . . . . . . . . . . . . 3

1.3 Hardware-in-the-Loop Design of a Cart-Pendulum Controller . . . . . . . . . . . . . . . . . . 4

2 Mathematical Model 52.1 Cart-Pendulum System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 DC Motor and Geartrain Dynamics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 Combining Cart-Pendulum and Motor Subsystems . . . . . . . . . . . . . . . . . . . . . . . . 92.4 LQR Controller Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Implementation of Real-Time Control System 103.1 xPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2 Building the Software Model in Simulink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.3 Compiling and Executing Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Experimental Data 114.1 Simulated data vs. collected data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

∗Associate Professor

5 Summary 11

1 Hardware-in-the-Loop Design Overview

The process of designing a control system with hardware-in-the loop (HIL) presents additional challengescompared to design for simulation or future implementation. For example, the controller must run on sometype of realtime computer that can guarantee scheduled I/O, take derivatives at fixed timesteps, and processthe control algorithm all within the sampling rate of the controller loop. Hardware considerations such asprocessing power requirements and interfacing analog and digital signals must be considered. Additionally,software requirements and programming concerns need to be addressed prior to design.

1.1 Hardware Considerations

The design of a HIL system typically consists of the following hardware components:

software development computer This computer hosts the software editor, compiler, debugger, and oc-casionally a simulator (e.g. Microsoft Visual Studio, Watcom C/C++, or Mathworks’ MATLAB andSimulink).

software execution computer This computer runs the code generated by the development computer anddirectly interfaces to the plant. It can be as complex as a dedicated multi-processor computer, or assimple as an embedded DSP or microcontroller (such as the Basic Stamp). The software developmentand execution computers are often the same machine.

signal conditioning circuitry This subsystem filters, amplifies, attenuates or formats signals sent be-tween the plant and the software execution computer. This principally consists of discreet components(resistors, capacitors, op-amps, etc.).

plant is the system to be controlled.

In the design of a HIL control system, the software development computer runs high-level editors, com-pilers or even automatic code generators (such as Matworks’ RealTime Workshop). Since development isconducted “offline,” minimal requirements are imposed except those required to operate a graphical userinterface (GUI) and compile code in a reasonable period of time. In the case where the software develop-ment computer is also used for execution, significant requirements are placed on the processor due to themanagement of both the realime I/O and the demanding user interface.

Additionally, the plant must be interfaced to the software execution computer, often requiring the con-version of digital signals to analog. (Several daughter boards for a PC are available that feature digitalI/O, A/D, D/A, timers, counters and other options. See products from National Instruments, Burr-Brownor Keithley Metrabyte for more information.) Development software that supports these I/O boards willreduce design time and allow the programmer to focus on control system performance. Additionally, itmay be advantageous to implement the software on embedded microcontrollers. These chips offer completesolutions in a single integrated circuit and may contain onboard A/D converters, digital signal processingcapability, hardware interrupts and pulse width modulation outputs. Products from Texas Instruments, Na-tional Semiconductor and Microchip Technology are able to be programmed in a high-level language (suchas C) and execute realtime code in a very small package.

Once a suitable hardware interface is selected, proper signal conditioning is required. Analog filtering ispreferably done in hardware to relieve computational burden of the digital signal processor (DSP) or centralprocessing unit (CPU). However, hardware signal conditioning is less flexible than that done in software dueto the dependence on discreet components. At a minimum, a low-pass filter on the plant’s analog sensorswill limit high-frequency noise associated with A/D conversions and electromagnetic interference induced onsensor wires.

2

1.2 Software Considerations

Developing the software to run the control system can often be the most complex and time-consumingportion of the design phase. Care should be exercised in selecting efficient and effective operating systemsand development tools. The designer should also be aware that tools exist which automatically handle theintricacies associated with writing realtime multi-rate code and allocating complex system resources.

The operating systems on which the software execution computer runs is divided into two types: realtimeand event-driven. Realtime operating systems such as VxWorks, QNX, LabView Real-Time, and xPCexecute code at fixed time intervals. The necessary computer resources to execute a particular section ofcode are arranged by the realtime operating system such that the code is completed before the next sectionis scheduled to be run. Guarantees can be made in realtime operating systems as to how quickly code canbe executed, or whether scheduled events can be serviced. For example, computers that control industrialprocesses such as nuclear power stations require valves that direct cooling water to be opened or closed atscheduled periods. If this valve were not opened at exactly the proper time because the operating systemwas processing another, less critical task, serious implications to plant safety arise.

Event-driven operating systems (such as Microsoft Windows 95/98/NT/2000/XP, Linux, and BSD) aremeant to only respond to external inputs such as those from the user. However, it is possible to achieve apsuedo-realtime behavior from an event-driven operating system by intelligently using software timers andinterrupts to force the system to execute code at fixed rates. However, the results of such work are oftenunpredictable because the servicing of interrupts cannot be guaranteed to be completed within a given time.The problem is compounded by the fact that these operating systems are typically graphical in nature andoften multi-tasking, implying that several applications or graphical tasks could be demanding processor timeduring critical points in the operation of the plant.

1.2.1 Writing HIL Software using Event-Driven Operating Systems

This section will be filled in with more detail later. –DB

Because event-driven operating systems are the most common type and development tools are widelyavailable, it is tempting for a designer to select this OS for the software execution computer.

Advantage: runs on familiar operating systems using familiar tools. Adequate for hardware that doesnot require execution at high sampling rates. If the designer decides to write code ‘from scratch,’ severalconsiderations need to be taken into account including operating system type (real-time vs. event-driven),programming language, and available hardware support for the chosen platform.

1.2.2 Writing HIL Software using Realtime Operating Systems

Controllers developed with graphical methods such as those used with Simulink or Matrix-X are not easilyported to event-driven operating systems; realtime controllers and scheduling are difficult to program. Todo so, designers must be adept at coding software for execution on the hardware, requiring input andoutput synchronization, and at the same time solving differential equations in real-time. (It is one thingto understand how a fourth-order Runge-Kutta differential equation solver operates, it is quite another toimplement such a solver for execution in real-time.) Designers can too easily get lost in coding software andmiss out on important concepts in controller design and real-time system operation.

Several software packages have attempted to automatically generate control code for execution on hard-ware, but these packages have significant limitations. For example, Mathwork’s MATLAB has featuredReal-Time Workshop for a number of years. This software takes graphical control block in MATLAB’sSimulink and compiles it for execution under various environments such as DOS protected mode or Vx-Works. Unfortunately, Real-Time Workshop only includes a few hardware drivers, requiring users to developmost of their own hardware-dependent drivers. While this alleviates the burden of differential equationsolvers, it does not allow users to move easily from controller simulation to actual hardware. Additionally,

3

Figure 1: The Cart-Pendulum system is shown above. The controller was designed with hardware-in-the-loop.

Real-Time Workshop relies on target operating systems for real-time resource allocation and system I/O,providing flexibility, but making concessions to allow for multiple operating system compatibility.

However, a newly available toolbox for MATLAB and Simulink (versions 6.0 and greater) allows users tomove from simulation to hardware on Mathworks’ real-time operating system that includes numerous librariesof supported hardware. This software package, called “xPC,” allows users to compile graphical Simulinkmodels that include blocks to interface with specific hardware I/O, and these models are downloaded to thetarget hardware running the proprietary xPC realtime operating system.

xPC’s blocks for Simulink and its real-time operating system allow rapid development of controllers andcan be used to quickly progress from controller design to simulation to implementation.

In general, a rapid code-developing platform should provide a basic set of features for the user. An in-tuitive graphical interface is required to clearly show signal flows. Additionally, the package should supportnative simulation and analysis tools (e.g. simulating the response of a model to step commands, plottingthe frequency response, etc.) Perhaps most importantly, the package should be directly linked to the oper-ating system (either DOS-protected mode, VxWorks, or some other proprietary OS) so that direct resourcemanagement can be achieved. Fortunately, Mathwork’s xPC toolbox creates embedded code that runs onthe xPC real-time kernel, which manages processor usage, memory allocation, and system I/O in real-time.

1.3 Hardware-in-the-Loop Design of a Cart-Pendulum Controller

The rest of this paper will focus on the hardware-in-the-loop design of a cart-pendulum control system,shown in Figure 1. In the modeling section, a mathematical representation of the cart-pendulum systemis developed (based on Ogata, et al. [2]) which also includes a model of the cart’s electric motor. Thesystem inputs, outputs and states are identified, and transfer functions are developed from applied motorvoltage to cart position and pendulum angle for the single-input, multiple-output system. A linear quadraticregulator (LQR) controller is used to control the system (although other types of controller are easily substi-tuted). Simulation is conducted using MATLAB and Simulink for controller verification and determinationof expected system performance.

After an analytic model is derived and simulated, a section is presented that describes how to modify theSimulink model to be suitable for execution under xPC – surprisingly little alteration is required. The hard-

4

Figure 2: Cart-pendulum subsystem.

ware considerations mentioned above are addressed, and the software development and execution computersare identified.

Finally, data is collected under xPC, highlighting the performance of a dedicated real-time operatingsystem. Collected data is compared to simulated data, which shows very good correlation.

2 Mathematical Model

In this section the mathematical model for the cart-pendulum system is developed, including the dynamicsof the DC motor. The nonlinear equations of motion for the cart-pendulum system (with a generic forceapplied to the cart) are linearized and presented as a ‘subsystem.’ The dynamics of the motor and geartrainare also derived as a subsystem, and the two subsystems are combined into a single model. Our modellinggoal is to express the system as a four-state, single-input, dual-output state-space model with the motorvoltage as the system input and the cart position and pendulum angle as the system outputs. To designthe controller, numerical values for the various system parameters are substituted and an LQR controller isdesigned using appropriate weighting matrices.

2.1 Cart-Pendulum System

The cart-pendulum system is shown in Figure 2, and the variables used in the analysis are summarized inTable 1.

The nonlinear equations of motion for the cart-pendulum system are derived from Newton’s Second Law.

(M + m)x + ml cos(θ)θ −ml sin(θ)θ2 = F (1)

ml cos(θ)x−ml sin(θ)θx + mθl2 −mgl sin(θ) = 0 (2)

5

Variable Units Value Descriptionx m – position of cart on track from center (positive to the right)θ radians – angle pendulum makes with the upright equilibriumM kg 0.455 mass of the cartm kg 0.210 mass of the pendulumlp m 0.6096 length of the penduluml m 0.3048 distance to pendulum’s center of gravityg m

s2 9.81 gravitational accelerationF N – force applied to the cart (via the DC motor)

Table 1: Cart-Pendulum system parameters.

To find the pendulum’s vertical equilibrium point (with the cart stationary), we set x = θ = x = θ = 0and we find that

Feq = 0 (3)

sin(θeq) = 0 (4)

which gives the equilibrium values.

xeq = x (any value of x) (5)

θeq = kπ k = 0, 1, 2 . . . (6)

Next, we linearize equations (1) and (2) about the equilibrium values. Variables perturbed about theequilibrium point are defined with a Taylor series (terms second-order and higher are ignored). For example,the cart position, velocity and acceleration are

x = xeq + δx + H.O.T.s ⇒ x = xeq + δx (7)

x = xeq + δx + H.O.T.s ⇒ x = δx (8)

x = xeq + δx + H.O.T.s ⇒ x = δx (9)

The pendulum angle, angular velocity, angular acceleration and force are defined by a similar Taylorseries.

θ = θeq + δθ (10)

θ = δθ (11)

θ = δθ (12)

F = δF (13)

Substituting the expansion for θ from equation (10) into sin and cos, and using the double-angle trigono-metric expansion leaves

sin(θ) = sin(θeq + δθ) = sin(θeq) cos(δθ) + cos(θeq) sin(δθ) (14)

cos(θ) = cos(θeq + δθ) = cos(θeq) cos(δθ)− sin(θeq) sin(δθ) (15)

Assuming the pendulum moves through small angles, sin(λ) ≈ λ and cos(λ) ≈ 1 give

6

Figure 3: DC motor and geartrain subsystem.

sin(θ) = sin(θeq) + cos(θeq)δθ (16)

cos(θ) = cos(θeq)− sin(θeq)δθ (17)

Substituting the linearized variables in equations (7) – (17), into (1) and (2) leads to the followingequations of motion (after ignoring higher order terms such as (δθ)(δθ))

(M + m)δx + ml(δθ) cos(θeq) = δF (18)

ml cos(θeq)δx + ml2δθ −mgl sin(θeq)−mgl cos(θeq)δθ = 0 (19)

Using the desired equilibrium values of θeq = 0 and Feq = 0 into (18) and (19), and dropping the ‘δ’prefix for brevity yields the final linearized model for the cart-pendulum system.

(M + m)x + mlθ = F (20)

mlx + ml2θ = mglθ (21)

2.2 DC Motor and Geartrain Dynamics

The DC motor is coupled to an output gear, which engages the track as a rack-and-pinion system. Figure 3shows the DC motor and geartrain subsystem to be modeled. Often DC motors are simply modeled as aconstant energy conversion system, i.e., voltage or current is directly proportional to torque output. Whilethis may be acceptable for certain applications, the bandwidth required for the control of a cart-pendulumsystem requires a more robust model. The following derivation explains how a permanent-magnet DCmotor with inductance and back-emf can be approximated over a frequency range appropriate for the cart-pendulum. The variables used for this analysis are summarized in Table 2.

A permanent-magnet DC motor is often modeled with the following second-order equation.

7

Variable Units Value DescriptionV volts – motor input voltageI amps – motor armature current

Rm ohms 2.6 motor armature resistanceLm henrys 18e-5 motor armature inductanceKm

N−mA 0.00767 motor torque constant

r meters 0.00635 radius of output gearKg – 3.7 gear ratio (driven gear/driving gear)ω rad

sec – angular velocity of output gearωm

radsec – angular velocity of motor shaft

T newton-meters – torque output of gear trainTm newton-meters – torque output of motor

Table 2: DC motor and geartrain system parameters.

V = LmdI

dt+ IRm + Kmωm (22)

The last term contributes a voltage that is proportional to the angular velocity of the motor – this isthe so-called back-emf. Before we can manipulate this equation further, a few preliminaries need to beestablished.

The torque from the output gear is related to the motor torque by the simple equation,

T = KgTm (23)

Substituting in the motor torque constant introduces the motor current.

T = KgKmI (24)

The torque produces a force on the cart given by,

F = T/r (25)

Solving for the current,

I =Fr

KgKm(26)

Also note that due to the geartrain,

x = rω (27)

x =rωm

Kg(28)

ωm =Kg

rx (29)

Working with Equation (22) in the s-domain, we substitute the relations derived above.

8

V (s) = LmIs + IRm + Kmωm (30)

=F (s)rLm

KgKms +

F (s)rRm

KgKm+

KgKm

rX(s) · s (31)

= F (s)[r(Lms + Rm)

KgKm

]+

KgKm

rX(s) · s (32)

F (s) =[

KgKm

r(Lms + Rm)

]V (s)−

[KgKm

r(Lms + Rm)

]KmKg

rX(s) · s (33)

Finally, we note that motor armature inductance is very small and can be ignored without affecting therobustness of the model.

F (s) =(

KgKm

rRm

)V (s)−

(K2

gK2m

r2Rm

)X(s) · s (34)

Now we have an expression for the force applied to the cart as a function of motor input voltage. The rightterm is proportional to angular velocity, and because it is negative, the back-emf causes causes an oppositeforce as compared to the force induced by the input voltage. For small velocities this term is negligible andcan be ignored. However, the bandwidth required to balance the inverted pendulum necessitate higher cartvelocities and therefore the controller must compensate for the motor back-emf.

2.3 Combining Cart-Pendulum and Motor Subsystems

Note that the force output from the motor gear system in equation (34) is the same as the force appliedto the cart derived in equation (20). Equating these two forces allows the combination of the motor modelsubsystem and the cart-pendulum subsystem. Equations (20) and (21) become

(M + m)x + mlθ =(

KgKm

rRm

)V (t)−

(K2

gK2m

r2Rm

)x (35)

mlx + ml2θ = mglθ (36)

Solving for x. We divide equation (36) by l and rearrange to solve for mlθ to substitute into equation (35).This eliminates θ and leaves

(M + m)x + mgθ −mx =(

KgKm

rRm

)V (t)−

(K2

gK2m

r2Rm

)x (37)

x =(

KgKm

MrRm

)V (t)−

(K2

gK2m

Mr2Rm

)x− mg

Mθ (38)

Also, define the new variable β as follows

β ,KgKm

r(39)

and we have

x =(

β

MRm

)V (t)−

(β2

MRm

)x− mg

Mθ (40)

Solving for θ. We solve equation (36) for x and substitute into equation (35) to eliminate x.

9

gθ − lθ +mlθ

M + m=

β

Rm(M + m)V (t)− β2

Rm(M + m)x (41)

θ =β

Rm(M + m)(

mlM+m − l

)V (t)− β2

Rm(M + m)(

mlM+m − l

) x− g(ml

M+m − l)θ (42)

θ =β

Rm[ml − l(M + m)]V (t)− β2

Rm[ml − l(M + m)]x− g(

mlM+m − l

)θ (43)

θ =β

RmMlV (t)− β2

RmMlx− g(M + m)

Mlθ (44)

Using the final expression for x and θ in equations (40) and (44) we can stack the variables in a matrixin state-space form. Defining the state vector as

x =

θ

θxx

(45)

we have the state-space model of the cart-pendulum system with the motor dynamics included.

x =

θ

θxx

=

0 1 0 0

g(M+m)Ml 0 0 β2

RmMl

0 0 0 1−mg

M 0 0 − β2

RmM

θ

θxx

+

0

− βRmMl

0β

RmM

V (46)

Comments This state-space representation is a four-state model with motor voltage as the input. Theterms in the 2,4 and 4,4 locations are the contributions of the motor’s back-emf and are required for adequateperformance from the controller. The model developed is the same model presented in [2], with the exceptionof the addition of the back-emf terms and the force-to-voltage conversion terms in the B matrix, which isβ/RmM .

2.4 LQR Controller Design

LQR controller design.

3 Implementation of Real-Time Control System

In this section we describe the implementation of the control system.

3.1 xPC

• xPC description

• relation to MATLAB, Simulink

• xPC advantages

• xPC operational overview (i.e., target vs. host computer)

• xPC settings

10

Figure 4: data plot.

3.2 Building the Software Model in Simulink

describe the zero initial conditions block

3.3 Compiling and Executing Code

4 Experimental Data

In this section we describe the implementation of the control system.

4.1 Simulated data vs. collected data

The following plots compare simulated data and experimental data captured using XPC. The data wasrecorded using 500Hz sampling. The reference command was set to be a square wave at 0.2 meters amplitudeand 0.1 Hz An constant gain controller designed using LQR methods was used to control the systems. Thedesigned closed loop poles were -21.007 +/- 19.862i and -1.145 +/- 1.062i.

The simulation data was created using a nonlinear cart based inverted pendulum similair to Ogataand Quanser references. Additionally, the model included a DC motor model and model representing thequantizing and sampling effects of the National Instruments DAQ board.

Note:Red Plots represent Reference Commands

Blue Plots represent Simulink Simulated SignalsGreen Plots represent Experimental XPC Measured Signals

5 Summary

Summarize the damn work.

References

[1] Test this bib item.

[2] K. Ogata, Modern Control Engineering, Prentice Hall, Englewod Cliffs, NJ, 1990.

11

Figure 5: data plot.

Figure 6: data plot.

12