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.