Integrating Control Concepts in an Embedded Systems Design Course

Integrating Control Concepts in an Embedded
Systems Design Course
Manuel Jimenez, Gerson Beauchamp, Reinaldo Mulero, Maria Gonzalez
Department of Electrical and Computer Engineering
University of Puerto Rico at Mayaguez
Mayaguez, PR 00681–9000
Abstract—This paper describes a project experience in a microprocessor interfacing course, where computer engineering (CE)
and electrical engineering (EE) students were joined to develop
a project designing and implementing a Digital Controller for a
Three Degree of Freedom Helicopter (3DOFH). This is a highly
non-linear problem brought in by the EE students from the
Process Instrumentation and Control Laboratory (PICL). Besides
serving as the course project for the students, the motivation
for taking such a project was to create a base platform using
embedded microprocessors where control students could acquire
signal conditioning and embedded software design skills in a
more realistic platform than that provided by virtual instrument
environments. This paper describes the course setting, design
approach, and experience gained by the students, establishing a
collaboration modality that could be emulated to bring multidisciplinary projects into traditional courses.
I. I NTRODUCTION
In a typical embedded system design course, students are
expected to successfully apply learned concepts through a
design project. The Microprocessor Interfacing (MI) course at
UPRM is a technical elective for Computer Engineering (CE)
and Electrical Engineering (EE) majors with such characteristics. In this course, students learn how to solve engineering
problems by designing, testing, and implementing embedded
systems prototypes to meet the quality and requirements of a
real life problem. A key aspect of projects is to induce students to interact with other disciplines outside the traditional
scope of EE/CE courses while learning about interfacing and
embedded systems design.
This paper describes the experience of joining, through
a microprocessor interfacing project, students from electrical engineering (EE) specializing in control with peers in
computer engineering (CE) specializing in software. In our
program, these areas run in parallel, with control EE students
rarely taking the interfacing course and virtually no CE
students taking control courses. The problem they chose to
solve as project consisted of designing and implementing a
digital controller for a Three Degree of Freedom Helicopter
(3DOFH). This is a highly non-linear problem assigned to
EE control students in the Linear Systems Analysis course.
In that course, students solve the problem mathematically
and verify its characteristics via a virtual instrumentation
environment. The motivation for taking such a project was
to create a base platform using embedded microprocessors
where control students could acquire signal conditioning and
978-1-4673-5261-1/13/$31.00 ©2013 IEEE
embedded hardware and software design skills in a more
realistic platform than that provided by virtual instrument
environments.
Several works in recent literature have reported diverse
experiences with either educational objectives or aiming at
resolving specific application problems dealing with control
system models and their implementation on specific hardware
controllers [1], [2], [3]. Although these and other similar
articles provide insight into the design of control systems, none
of them focuses on the interdisciplinary experience and cross
learning achievable by joining educational and implementation
objectives in a classroom experience.
The rest of this document describes the educational setting
and course structure where this experience took place. Next
we provide details into the design of both the embedded system hardware and software components and their integration.
Moreover, we discuss the control system design process. The
last sections summarize the most important project outcomes,
analyzing the lessons learned in this experience by both,
students and instructors.
II. E DUCATIONAL S ETTING
A. Program Structure
The Microprocessor Interfacing (MI) course is currently
offered as a technical elective for both computer and electrical
engineering majors. Both programs are five-year long with
about 165 credit-hours each. Each program requires students
taking at least eighteen credits-hours in technical electives.
These elective courses define their emphasis areas.
In the computer engineering (CE) program the emphasis
areas include hardware & embedded systems (HWES), digital
signal processing (DSP), and software & computing (SWCS).
In the electrical engineering program (EE) students choose
their electives in one of five areas that include electronics,
control, power systems, electromagnetics, or communications.
The MI course is a valid technical elective for both programs, but is mainly taken by CE majors who declare their
emphasis area in HWES and EE majors concentrating in
electronics. Some students from either program in areas other
than HWES or electronics also take this course in preparation
for their senior design experience course, particularly when
they plan to develop projects that will use embedded systems
techniques.
Students enrolled in the MI course are either in their last
sophomore term or in their first semester as seniors. The
course has as prerequisites the first course in Microprocessors,
which is a core in both programs. Students are also required
to have completed a course in programming languages and
in digital electronics. These requisites ensure that students
taking MI have fundamental knowledge in programming in
both assembly and high-level languages, microprocessor-based
systems, and understand the electronic structure of digital gates
and drivers.
The MI course is offered in both spring and fall terms,
with an enrollment of 20 to 30 students per term, typically
distributed as 75% to 80% CE students and the rest are EEs.
B. Course Structure
The interfacing course has as an objective making students proficient in specifying, designing, and prototyping
microprocessor-based embedded system. To achieve this objective, the course takes students through a tri-folded approach
that combines classroom lectures, structured laboratory exercises, and a semester-long project.
1) Classroom Activities: As part of the classroom activities, students learn the fundamentals of how to develop
microprocessor-based embedded applications. Discussed subjects include the architecture of embedded systems, design
constraints, embedded systems life-cycle, interfacing and configuration of embedded peripherals, signal styles in traditional
and serial buses, hardware prototyping techniques, embedded
software design techniques, and concepts of real-time systems.
2) Laboratory Activities: In the laboratory, students work
in teams of two or three members on a set of six pre-defined
exercises. These exercises are completed before they delve into
implementing hardware for their projects in synchronization
with the subjects discussed in the classroom. The objective
of these laboratories is for students to become familiar with
the specific microprocessor they will use for their projects.
The laboratory topics include the usage of processor’s specific
hardware and software development tools, using laboratory
instrumentation, and exercises using embedded support peripherals that include general-purpose I/Os, interrupts, timers,
low-power modes, serial interfaces, and data converters.
C. The Course Project
The project consists of a student proposed problem to be
solved as an embedded system application. Students, working
in teams of three or four members, submit a project proposal in
the third week of classes. Proposals are structured following a
set of guidelines published in the course web site. All problems
proposed for the project must include four components in their
solution, listed as follows:
a. Microprocessor-based meaning the solution must use a
microprocessor performing non-trivial tasks.
b. Communication implying the system ability to communicate with another system.
c. User Interface allowing humans to somehow interact with
the designed system.
d. Control scheme each system must have some form of
control scheme within the application context.
Proposals are evaluated by the instructor and returned to the
student with comments aimed at making the project feasible
to be completed within the semester. Thereafter, in four additional stages, students go through the process of progressively
developing a solution by a) developing an architectural design
and software macro-model, b) a circuit design and software
plan, c) implementing a building-block-level prototype and
firmware, and d) system integration and application software.
For the architectural design stage, students use the problem
specifications described in their proposals to develop a blocklevel diagram of their solutions and describing their hardware
and functional descriptions. In this stage students also decide
the processor to be used for their project, based on the system
requirements. At this point, the architectural description is
partitioned among group member, allowing each student in
the group to contribute in the hardware and software design
components of the project.
The circuit design stage assigns specific hardware and/or
components to the functional blocks forming the system
architecture to produce a schematic diagram of the system.
This stage incorporates electrical and timing calculations to
assess the correctness of the hardware design. A software plan
based on the functional description of the previous stage is also
developed.
Using commercial off-the-shelf components and a development kit of the selected processor, students develop working
prototypes of each functional block in their designs and their
firmware and provide the instructor a demonstration of the
level of progress achieved so far.
The last stage is devoted to system integration and software
application integration. All functional component prototypes
are integrated according to the architectural design earlier
developed. The application software developed for the system
is also installed. The functional prototype is transferred to a
printed circuit board, packaged, and a working demonstration
provided to the instructor.
D. Course Evaluation
The course evaluation reflects the organization of activities
as students receive credit for exams related to classroom
lectures, performed labs, and project related activities.
Students complete one mid-term and one final exam mostly
covering the material discussed in the classroom. Both are
written tests, designed to assess the individual student proficiency in concepts and design criteria.
For the laboratory work, each lab session includes two or
three exercises in interfacing and programming related to the
discussed subject and completed by the students over a period
of a week.
Each project stage is documented in a progress report
discussed with the instructor in a group fashion. Students
also take an individual oral examination after completing their
prototype. This evaluation assesses the individual level of
proficiency achieved by each group member in terms of the
completed project.
At the end of the semester, students prepare a comprehensive written report of their project, documenting all stages of
their designs and their prototypes. They also offer an oral
presentation in front of their classmates about their project.
This presentation is open to the academic community as well,
and includes a live demonstration of their working prototypes.
Some teams have used their projects to enter and successfully
compete in local and national design contests.
III. T HE 3DOFH S YSTEM
The integrative experience reported in this paper is based on
the work developed by a mixed group of EE and CE students
who took the MI course and proposed as project designing
and prototyping an embedded system for the digital control
of a Three Degree of Freedom Helicopter (3DOFH). The
3DOFH is a highly non-linear mechanical system emulating
a stationary helicopter with two vertical propellers capable of
rotating the structure in three different axes providing elevation
(ε), jaw travel (φ), and pitch (θ) (see Figure 1).
The mechanical assembly is composed of a leveled arm
mounted on a rotating base. At one end of the leveled arm
is the helicopter part containing the two DC motors and
propellers. By individually controlling the amount of power
being sent to the DC motors, the horizontal arm can rotate
around its center axis. This action produces a pitch angle
θ proportional to the thrust vector forces developed by the
voltage applied to the motors.
Since the DC motors alone cannot produce sufficient thrust
to elevate the level arm, a counter weight is located in the
opposite side of the helicopter to help these forces in the elevation (ε). With the right amount of pitch (θ) in the helicopter
part, the system is able to rotate in the base part producing a
travel angle (φ). The system has an three optical encoders to
measure each angle: elevation, pitch, and travel. The objective
of this system is to maintain a desired position and respond
to disturbances with a desired control characteristics.
The system operates by establishing a set-point (ε, φ, θ) via
either a keypad or joystick. Once the set-point is reached, it
must be kept in that position by the digital controller even in
the presence of external perturbations and the inherent system
noise. Figure 1 shows a conceptual diagram of the 3DOFH
system denoting the motors, encoders, relative element positions and the controller.
The 3DOFH problem is traditionally assigned to EE control
students in the Process Instrumentation and Control Laboratory (PICL). Its purpose is to provide students with an
experience in the usage of linear state-space control systems.
A custom designed platform is provided in the PCIL that
incorporates the motors and sensors as shown in Figure 1.
For their PCIL project, control students linearize the system and proceed to implement it via a data acquisition
card interface connected to a personal computer running a
MATLAB/Simulink program. This virtual instrument setup
runs on an ideal software environment where real world
Fig. 1. Conceptual diagram for a 3DOFH system.
limitations and disturbances are not present. When using this
approach, important details about sensors, motor interfaces,
signal conditioning, and driver requirements are hidden from
the students. This approach, although beneficial for novice
control students, may limit the ability of advanced students
to implement control system solutions in actual scenarios like
those found in courses like the capstone design experience or
in industry practice [4].
IV. T HE 3DOFH
AS AN
MI P ROJECT
The 3DOFH as an MI project represented an excellent
scenario to bring out the hidden details in the implementation of a digital control system, while combining elements
from electrical and computer engineering disciplines. With
EE students bringing their background in control systems and
CE students providing their expertise in digital hardware and
software design for the same problem made for a convenient
interdisciplinary experience.
To develop a successful solution, the students from both
areas needed to work as team and acquire technical knowledge
from each other’s disciplines. The computer engineering students had to learn the basics of a closed-loop control systems,
concepts of negative feedback, and compensator design. This
basic understanding was necessary for the CE student to
develop the appropriate embedded software to configure the
microcontroller (MCU) peripherals.
The next sections describe the approach followed to implement the 3DOFH system as an embedded systems application.
The description sheds light into how the concepts from both
disciplines interbreed to produce a working solution to the
problem.
A. Design Approach
The design of the digital controller for the 3DOFH project
was partitioned into three main tasks. The first task was devoted to the hardware structure of the digital controller. As part
of this task, a system block diagram was created, defining the
controller architecture, a suitable processor selected, and the
interfaces necessary for connecting the sensors and the MCU
were designed. This stage also included the user interface
hardware and the power supply system.
The second task consisted in the control system design.
Here, the mathematical model of the system was obtained
and the LQR compensator was designed. In the third task
the embedded software was designed. Here, the algorithms
for all MCU peripherals including timers, pulse-width modulation (PWM) modules, analog-to-digital converters (ADC),
and quadrature encoder peripherals (QEP) were configured,
and integrated with the Control Algorithm to yield a complete
implementation. Below we provide additional details about
each of these tasks.
B. Digital Controller
The digital controller module is the most important block
of the system. It serves two fundamental purposes: first, it
implements a control algorithm based on linear state-space
design to reach and keep a given set-point. To this end the
module incorporates signal conditioning circuitry, a dual motor
driver, and a power supply subcircuit. The second controller
function is to provide for a user interface that allows for
configuring the controller parameters and directly interacting
with the 3DOFH. The user interface integrates an LCD, a 4x3
keypad, and an analog, two-axis joystick. Figure 2 shows a
block diagram illustrating the hardware components of the
digital controller.
tors, receiving and amplifying the PWM signals sent from the
MCU. The encoder-signal condition circuit (ESCC) attenuates
the quadrature signals received from each of the encoders
mounted in the axes of the 3DOFH assembly. The power
circuit, not illustrated in the controller diagram, provides and
distributes power to each of the components of the digital
controller.
Communication between the M3 and C28 cores occurred
through a dual-ported, shared memory block embedded in the
C2000 chip.
The controller operation allows an user to either operate the
system with a set default gains hardcoded in the controller’s
firmware or to specify via the user interface, a custom set of
values defining a linear state-space design compensator.
C. Control System Design
The mathematical model of the three-degree of freedom
helicopter (3DOFH) is based on the work by Ishitobi and
Nishi [6]. The model is obtained from the sum of forces and
momentums of the 3DOFH that results on a set of nonlinear
state equations that describe the system behavior as shown
below.
ε̈ =
ρ1 cos(ε) + ρ2 sin(ε) + ρ4 (Vf + Vb )cos(θ)
(1)
θ̈
ρ5 cos(θ) + ρ6 sin(θ) + ρ8 (Vf − Vb )
(2)
ρ10 (Vf + Vb )sin(θ)
(3)
=
φ̈ =
This set of equations describes the system behavior in terms
of angular positions (ε, θ, and φ) and the motor voltage inputs
Vf and Vb . The terms ”ρi ” are parameters related to the
mechanical properties of the system.
To design the controller, the system state equations were
linearized to obtain a state-space representation of the form
Fig. 2. Block diagram for the 3DOFH digital controller.
At the heart of the controller is Texas Instruments C2000
MCU. In particular, a Concerto F28M35H52C1 MCU was
used [5]. The F28M35x Concerto MCU was a convenient
selection as it provides a dual-core architecture incorporating
an Arm Cortex M3 core operating as subsystem master, and a
TMS320C28x core serving as subsystem control. The M3 core
in the 3DOFH system was configured to partially control the
user interface functions via the keypad and display modules.
The C28 core was devoted to all control functions, including monitoring the quadrature encoder peripheral (QEP) and
managing the motor drivers through PWM signals. In addition,
the C28 was in charge of sampling the analog signals from
the joystick.
The motor driver on the right of the diagram (DRV8412)
implements a dual H-Bridge driver to handle the two DC mo-
ẋ(t)
=
Ax(t) + Bu(t)
(4)
y(t)
=
Cx(t),
(5)
where x(t) = [x1 , x2 , x3 , x4 , x5 , x6 , x7 , x8 ]T is the state
vector, ẋ(t) is the derivative of x(t), u(t) = [u1 , u2 ]T is the
input vector, y(t) = [x1 , x2 , x3 ]T is the output vector, and A,
B and C are constant matrices of appropriate dimensions. The
3DOFH state variables were assigned as follows:
TABLE I
S TATE VARIABLE ASSIGNMENTS .
∫
x4 = ε̇ = ẋ1
x7 =
x2 = θ
x5 = θ̇ = ẋ2
x8 =
x3 = φ
x6 = φ̇ = ẋ3
u1 = Vf , u2 = Vb
∫
ε=
∫
x1 = ε
φ=
∫
x1
x2
Notice that two additional state variables, x7 and x8 , were
added as the integrals of x1 and x3 . This state augmentation
was performed to eliminate the steady-state error in elevation and travel. The system was linearized by applying the
Jacobians to (1), (2), and (3). The resulting linear state-space
constant matrices in the continuous-time domain were:


0
0
0 1 0 0 0 0
 0
0
0 0 1 0 0 0 


 0
0
0 0 0 1 0 0 


 ρ2
0
0 0 0 0 0 0 


A=

 0 −ρρ106 ρ1 0 0 0 0 0 0 
 0

0
0
0
0
0
0
ρ4


 1
0
0 0 0 0 0 0 
0
1
0 0 0 0 0 0






B=





0
0
0
ρ4
ρ8
0
0
0
0
0
0
ρ4
−ρ8
0
0
0






1 0

 C= 0 1


0 0



Fig. 3. Closed-loop linear state-space diagram.
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0

0
0 
0
Matlab(R) was used to design the state-space feedback
gains for the system. The linear state-space system was first
discretized with a sampling period of T = 1ms. The feedback
gains were designed using the Linear Quadratic Regulator
(LQR). The LQR is an optimal control regulator that minimizes control effort and state-variable energy while resulting
in a stable closed-loop system [7]. The performance index to
be minimized was:
∫ inf
J=
(xT (t)Qx(t) + uT (t)Ru(t))dt,
(6)
D. Embedded Software Design
The embedded software was written in C-language using
Texas Instruments’ Code Composer Studio Integrated Development Environment (CCS-IDE). Although each MCU core
can be individually programmed, the master M3 core needs
to be programmed first to enable and make available the slave
C28 core and its assigned peripherals.
Figure 4 shows a high-level flowchart of the system software
organization. The system boots with the master M3 core,
which in turn boots and initializes the slave C28 core. With
both cores initialized all system peripherals required by the
application can be configured. Next, the program, still running
in the master core, waits for the user to select the controller
configuration parameters. In the last stage, the control and user
interface algorithms begin execution in their respective cores
and remain running until the system is powered-off.
0
where Q is a positive semi-definite matrix and R is a positive
definite matrix. These are weighting matrices for the state
and input vectors respectively. During the design of the LQR,
matrices Q and R were systematically modified to obtain the
best step response from a simulation. These matrices were
modified to shift the weights of the compensator to emphasize
the control of specific state variables. The resulting controller
was implemented in the form of a difference equation
u(kT ) = K[r(kT ) − x(kT )]
(7)
In equation (7), u(kT ) is the input vector, K is the controller
gain vector, r(kT ) is the system reference vector (joystick),
and x(kT ) is the state-variable vector. Notice that (7) is written
in the discrete-time domain with sampling period T . Figure
3 shows the control system block diagram. The 3DOFH is
represented in a linear state-space format in the continuoustime domain. The outputs of the system are sampled by the
QEP and discretized. Numerical differentiation was used to
estimate the velocities and numerical integration is performed
to obtain the state-variable integrals. These values are compared with the reference values sampled by the ADC and the
error signal produced is fed to the controller gain matrix. The
resulting input signals are used to adjust the duty cycle of the
PWM peripheral to control the DC motors.
Fig. 4. Top-level flowchart of system software organization.
The M3 core plays its role as master by booting the slave
C28 core and controlling the user interface.
The C28 slave core exerts control over the PWM channels,
ADC, and QEP inputs, and running the control algorithms.
Two PWM channels were enabled, one per motor, each with
its own 16-bit timer running at the C28 clock frequency. The
average DC voltage applied to the motors was controlled by
the duty cycle of their corresponding PWM outputs.
The optical encoder’s outputs were managed through three
on-chip quadrature encoder peripherals (QEPs). These allowed
for updating the position counters without CPU intervention.
The optical encoders in the 3DOFH have a resolution of
4096 counts per revolution. The QEP multiplies this value
by four, resulting in a a total resolution of 16384 counts per
revolution. The QEP counter was configured to initialize at
8,192, requiring the system to be pre-positioned in a balanced
state at start to allow for initiating the control algorithm with
a small, self correctable error.
The joystick, also managed via the C28 core, provides
two analog outputs for jaw and elevation. These outputs are
interpreted via the on-chip analog-to-digital converter only
after a user, in the configuration process, enables the joystick
to specify the system set point.
V. P ROJECT O UTCOMES
The students were successful in designing a controller,
hardware, and software for a 3DOFH system and producing
a working prototype of their design. The digital controller
had all the features that were proposed for the system and
its interfaces established the desired functionality. The user
interface module effectively allowed for selecting between
predefined or custom entered configurations and the joystick
provided for smooth set-point selection establishing the pitch,
jaw, and travel position of the system. While in operation, the
user interface also provided real-time feedback of the 3DOFH
angular position.
Stability was shown to be excellent for such a mechanical
system, with a settling time less than 4s and less than 20%
overshoot in response to a 90◦ step input in the travel angle. In
lab performed tests the system was observed to reach steadystate in less than three seconds when strong disturbances were
applied. The steady state error was also acceptable, about 0.09
radians as observed in the angular position feedback displayed
on the LCD.
VI. L ESSONS L EARNED
Through the implementation of a three-degree of freedom
helicopter project we were able to join computer and electrical engineering students from divergent areas in a crossfertilizing classroom experience. EE students learned about
software design, embedded systems and architectures, interfacing techniques, and multi-core systems. Computer engineering
students in turn, learned about closed-loop system, digital
control, linearization, system stability, and compensation.
They all were able to run a project from system conception
through to prototype demonstration, passing through stages
that included architectural design, circuit design, mathematical
modeling, hardware/software integration, circuit and mechanical assembly, and technical documentation.
The experience provided a platform where control students
could explore the details hidden in classical virtual instrument
implementations. Computer engineering students developed a
wider vision of the scope of applications that can be developed
using their electronics and software background combined
with knowledge from other fields.
From the instructors side, we interpret this experience as one
paving the way to establish a set of experimental platforms to
train control students on the details of implementing digital
control systems using real life constraints. We expect to use
this experience with computer engineering students to foster
cross-disciplinary applications where embedded techniques
provide solutions to complex, real-life problems.
VII. C ONCLUSION
The outcomes from this experience showed us that it is possible to combine in a learning experience concepts and practice
of traditional control system with those from an embedded system design course, enhancing the learning experiences of both
EE and CE students. CE students learned how to implement
digital closed-loop control systems on an embedded processor
with a net learning gain beyond that obtained through the
traditional open-loop systems they typically implement in their
projects. For EE students, this experience allowed them to
design and implement digital embedded controllers where real
world limitations are present, delve into the software and hardware design strategies, signal conditioning, communication
issues of an actual embedded implementation instead of the
classical virtual instrument environment used in most control
systems courses.
ACKNOWLEDGMENT
The authors would like to thank Texas Instruments Inc. for
their support to this project by providing the C2000 evaluation
kits, CCS-IDE, and several of the interface chips used for the
prototype implementation.
R EFERENCES
[1] YUXiao-zhou, ZHOUJun, and Z. Feng-qi, “The embeded flight control
system for davs,” 2nd International Symposium on Systems and Control
in Aerospace and Astronautics, pp. pp 1–5, 2008.
[2] L. Ferreira, E. Matos, L. Menendez, and E. Mandado, “Miles: A microcontroller learning system combining hardware and software tools,” in
Proceedings 35th Annual Frontiers in Education Conference, Oct. 2005,
pp. F4E–F4E.
[3] K. Yang, J. Zhang, W. LI, and L. Yang, “The software control system
design for robot based on avr mcu,” 5th IEEE Conference on Industrial
Electronics and Applications, pp. pp. 853–856, 2010.
[4] G. Beauchamp, M. Jim’enez, R. Mulero, and A. Ortiz, “Tradeoffs
implementing digital control systems for electrical engineering course
projects,” Proceedings of the Frontiers in Education 2012 Conference,
2012.
[5] I. Texas Instruments. (2013, April) F28m35x concerto microcontrollers (sprs742f). Available in world wide web at
http://www.ti.com/lit/gpn/f28m35e20b. Texas Instruments, Inc. [Online].
Available: http://www.ti.com/lit/gpn/f28m35e20b
[6] M. Ishitobi and M. Nishi, “Nonlinear adaptive model following control
for a 3-dof model helicopter,” Mechatronic Systems Simulation Modeling
and Control, pp. pp. 1–8, 2010.
[7] C. Philips and H. Nagle, Linear Quadratic Optimal Control. Prentice
Hall, 1995.