This article explores the introduction and use of new control classes that focus as much on modeling as on control. The paper describes several aspects of design problems with an emphasis on how to keep the process pedagogically efficient. The introductory classes in newer engineering curricula, at MIT and elsewhere, seek to empower students by avoiding highly customized devices, and instead rely on collections of easily composed and readily available sensors, actuators, and micro-controllers. The 15-week on-campus modeling and control class begins with classical material, discrete- and continuous-time transfer function modeling combined with PID and lead-lag controllers. With a combination of guidance and insights gained from constructing their artefacts, students determine a set of experiments and measurements that inform a model. Then they focus on designing and testing controllers, while answering impromptu questions from the roaming staff members.
To win the hearts and minds of talented undergraduates, the introductory classes of most newer engineering curricula engage students in the design and construction of compelling physical artifacts (e.g. robots, vehicles, or medical devices). Then, having established context, the more mathematically-sophisticated follow-on classes are often taught more abstractly, with applications appearing only in idealized form. In revamping an upper-level control class, we decided to counter this trend, and give students more opportunities to learn how to formulate informative mathematical models of messy applications. Our new control class focuses as much on modeling as on control, with students solving weekly commodity-hardware-based design problems in order to learn transfer function and state-space approaches to modeling and control, in both continuous-and discrete-time. In this paper we describe several aspects of those design problems, with an emphasis on how we kept the process pedagogically efficient.
The introductory classes in newer engineering curricula, at MIT and elsewhere, seek to empower students by avoiding highly customized devices, and instead rely on collections of easily-composed and readily-available sensors, actuators, and micro-controllers. And regardless of specific artifact: electric vehicle, medical imager, or robot; these classes all strengthen student skill in designing, testing and debugging, while also stressing general engineering concepts such as decomposing designs into abstract blocks, or using standard interfaces to encapsulate subsystem behavior.
After a context-establishing introduction, and before a capstone or thesis project, what role should physical hardware play in subsequent engineering classes? When applications are deemed essential, is it sufficient to rely on simulation, as do an ever-increasing fraction of practicing engineers? One answer emerged as the result of revamping one of our upper-level control classes: students need more opportunities to learn how to formulate informative mathematical models from messy applications. To address this need, our control class is now based on weekly design problems associated with physical artifacts, and its focus is as much on modeling as on control. Our chosen physical artifacts are usually compelling to students, but they were chosen for another reason. It is only when faced with a messy artifact and a challenging goal that students learn how to formulate mathematical models that address design questions.
An Example: Building Hardware for an On-Line Class
In January 2016, we offered an experimental hardware-based on-line class in discrete-time feedback control. In the three-week long edX class, (https://www.edx.org/course/introduction-feedback-control-theory-mitx-6-302-0x), a small group of students (about 200 worldwide) purchased about $100 in parts, built a copter-levitated arm (shown in Figure 1A), and installed our browser-based graphical user interface (GUI). By using the GUI, students could interact with the copter-levitated arm in real time (shown on Figure 1C). The combination of the open-source software suite (shown in Figure 1B) and the textbook-sized hardware platform were then used for three feedback control labs.
In the first lab, students modeled the arm (with no feedback) using difference equations and used the model to explain why they could coax the arm to settle below the horizon, but not above. In the second lab, they controlled the propeller rotational velocity using proportional feedback, and estimated stability limits on the gain using a first-order difference equation model. In the third lab, students used a second-order difference equation model to determine proportional and derivative feedback gains so that the arm angle would accurately track a user input.
After the end of the third lab, we had students watch how their arm controller responded to rising and falling input step-changes. The following is a (slightly edited) version of an exchange posted on the edX discussion board after the third lab:
Student A: I noted an interesting behavior—if I set the angle to 12 or more, there was no oscillation on the positive side, only on the negative side. This was consistent across a range of (derivative gain) values. Is this behavior expected?
Student B: I noticed the same asymmetry. I think it due to the difference in speed of response in the two different directions.
When the arm is above the vertical and the desired angle switches to negative, the arm falls rapidly under gravity and overshoots. When the arm is below vertical and the commanded angle switches to positive, the motor cannot lift the arm as quickly as it falls and there is no overshoot. (ed.-For small changes in arm angle, thrust and gravity act interchangeably).
Staff: What did we learn about the effect of gravity when the arm is significantly below and significantly above horizontal? And in which case does the gravity act to decrease proportional gain, and in which case does it act to increase proportional gain? If you are careful about signs, you will have your explanation.
Student A: Very interesting!! That nicely ties this lab back to the first.
This exchange, a “teachable moment” about determining a model that explains unexpected behavior, would not have occurred if students were using a simulator instead of actual hardware, or a precision-machined and pre-characterized demonstration system instead of a ripped-apart toy quad-copter. This is because simulators and demonstration systems already adhere to a model. If we want students to learn how to build mathematical models that address particular questions, we have to put hardware in their hands, and then generate good questions. And designing feedback controllers generates great modeling questions.
The On-Campus Control Class, from Concept to Design in One Week
Our 15-week on-campus modeling and control class begins with classical material, discrete-and continuous-time transfer function modeling combined with PID and lead-lag controllers. After a midterm project, we switch to state-space modeling and control, and build up to LQR/ LQG techniques, again in discrete-and continuous-time. The selection of topics is an attempt to balance building intuition with presenting approaches used in modern practice. And in order to teach these ideas using physical artifacts, we chose a “half-flipped classroom” approach. At the beginning of each week, a key technical concept is presented in a live lecture. In a following live recitation, the concept is examined using detailed examples, and additional practice is provided using auto-graded on-line problems. At the end of the week, students participate in an instructor-monitored design lab, where they try to develop and demonstrate mastery of the week's concept, by modeling and controlling the given artifact. Students work in pairs to build, measure, and model the artifact, and then design and test a controller.
In a perfect week, students arrive in lab competent at using the lecture material. With a combination of guidance and insights gained from constructing their artifacts, students determine a set of experiments and measurements that inform a model. Then they focus on designing and testing controllers, while answering impromptu questions from the roaming staff members. But, if the lab description is too scripted or too vague, or if setting up the experiments gets too complicated or time-consuming, this pedagogically-effective scenario can easily devolve into a tedious or frustratingly-confusing experience.
For the experimental edX course mentioned above, we assembled a software suite intended to simplify the processes of running experiments, taking measurements, and testing controllers. The suite includes the popular open-source Arduino development environment, an intuitive, browser-based graphics package (see Figure 1), as well as an open-source Python program, host GUI, and customized low-overhead Ardui-no-host communication protocol. The software suite is easily installed on nearly any laptop, and almost all the edX students were able to use the GUI to quickly and easily interact with the copter-levitated arm in real time, both while running experiments, and while testing controllers. For example, students could change gains and other parameters, and then record immediate system reactions for later inspection.
For the 15-week on-campus class, we needed a much broader series of artifacts, to pair with progressively more sophisticated discrete-and continuous-time modeling and control approaches. Since feedback control is intended to correct non-ideal behavior, we chose commodity parts instead of high precision ones. This also kept costs low (comparable to a textbook), so students could easily afford to purchase their own, if they wanted to do so. We used a combination of LEGO motors and parts, standard magnetic and optical sensors, and toy quad-copter motors. We also developed a platform that supports a far broader and easily-expanded library of design labs by: enhancing our open-source browser-based GUI/Server software, switching to a higher-performance micro-controller (the Teensy 3.2), and using a specially-designed dual voltage-to-PWM (pulse-width modulation) driver board. The new experimental platform (shown in Figure 2) is easily constructed from a list of commodity parts (not a “kit”, but a list of parts readily available worldwide). The significant performance increase is partly due to the micro-controller (ARM Cortex-M4), which can easily maintain millisecond update rates when running dozen-state observer-based state-space controllers, and can burst-sample at near megahertz rates. In addition, the voltage-to-PWM driver board can convert analog signals into PWM signals at near megahertz clock frequencies.
Three Artifacts and the Associated Labs
Each technical concept has an associated design lab, and each lab involves modeling, but we reuse physical artifacts. This is partly to reduce construction time, and partly to contrast control strategies (such as comparing PID to LQR-based state-space control, as noted below). For each design lab, students implement their continuous-time controllers using simple op-amp circuits, and implement their discrete-time controllers by modifying lines of micro-controller code and re-uploading to the Teensy micro-controller.
The Copter-Levitated Arm
The copter-levitated arm, in which a light plastic arm is rotated by increasing or decreasing the thrust produced by a motor-driven propeller (extracted from a toy quad-copter) is a rich artifact. We use it in several labs, to cover several concepts. As shown in Figure 3, the copter motor is driven with high-frequency PWM, and the PWM pulse width is set by an analog voltage generated by a digital-to-analog converter on the Teensy micro-controller.
The copter-levitated arm has four easily measured or derived states: 1) the motor current, 2) the motor back-EMF (which can be estimated by measuring the motor current and the motor voltage), 3) the arm angle (which is measured using a Hall-Effect angle sensor), and 4) the arm rotational velocity (which can be derived by differentiating the angle sensor voltage).
Only the motor behavior from the copter-levitated arm is used in the first lab, which focuses on first-order systems. The thrust direction is reversed, so that the arm does not lift, and propeller rotation speed is estimated by measuring the motor back-EMF. In the first lab, students use proportional feedback to control the rotation speed, and design continuous-and discrete-time speed controllers. They determine parameters for a first-order model relating pulse width to speed, and then design a discrete-time controller using the micro-controller and a continuous-time controller using an op-amp. Students are then asked to examine the effects on maximum proportional gain and disturbance rejection when changing the discrete-time sample rates. During lab, students are asked to demonstrate that their extracted model predicts the stability limits on gain, and are also asked to explain the gain limits for the continuous-time controller.
For the second and third labs, the focus is on second-order systems, and on arm position control. Students create discrete-time models of the relationship between PWM pulse width and the arm angle. They use the system to learn about model extraction, poles and root locus plots. In these two labs, students explore the trade-offs between stability, disturbance rejection, and tracking errors for proportional controllers. They also examine how to improve performance using model-predictive and proportional-integral-derivative (PID) control.
Students return to the copter-levitated arm in the second half of the class, for the first lab on state-space control. Since the arm has four easily-measured states, they can design an LQR-based controller that results in far better performance than the PD controllers they designed earlier in the term, provided the LQR weights are selected carefully. And as a second step, students can add an integrator to the state space controller, to achieve accurate tracking without overshoot. When compared to the PID-controlled system designed earlier in the term, the performance improvement is dramatic, and is surprisingly compelling to students.
In order to motivate using observer systems and state estimation, we tried having students extend the single-propeller model, to create a state space model of a dual propeller system. Our idea was that since there are so many additional states, it would be easier to use an observer with state estimation. The example, in Figure 4 on the left, proved remarkably ineffective. The dual-propeller system becomes a very heavily damped second order system, so is very easy to control, if one drives both copters at very high speed, and makes small adjustments to the speed difference to position the system.
The Magnetic Levitation System
In the magnetic levitation system, shown in Figure 5, an electromagnet is used to suspend a metallic rod (with a rare-earth magnet tip) in mid-air, about a halfinch beneath the electromagnet bottom.
To hold the rod in a suspended position requires tight control of the electromagnet's field, because the system is innately unstable. That is, the attraction force between the rare-earth-magnet tipped rod and the electromagnet increases rapidly with decreasing separation distance. Without control, the two snap together.
As can be seen in the block diagram on the right side of Figure 5, the electromagnet, made using a steel carriage bolt inside a low-cost solenoid coil, is energized with the same high frequency PWM driver used above to drive the copter motor. But in this case, the PWM pulse width is set by the output of an operational amplifier, rather than by the micro-controller DAC. This is because the dynamics of the levitation system are so fast, and the signals so noisy, that it is far easier to stabilize the system with continuous-time control. Fortunately, the PWM pulse width is set by an analog voltage, an important feature of our custom driver board, as it allows us to switch more easily between discrete-time and pseudo-continuous-time control. We say pseudo-continuous-time because the PWM clock frequency places an upper limit on the frequency response of any pseudo-continuous-time system. However, since our board's maximum PWM clock frequency is one gigahertz, it is usually not an issue.
The first step in designing a feedback controller that can suspend the rod in mid-air is to determine how to sense the rod position. As can be seen on the block diagram on the right side of Figure 5 (which are inside the green bricks in the photograph on the left side of Figure 5), a pair of Hall-Effect sensors are used for that purpose. The two sensors measure the fields at the top and bottom of the coil, and their difference (in the diagram on the right of Figure 5, the circuit sums the sensor outputs, but one of the sensors is flipped) cancels the coil field. What remains is the field due to the proximity of the rare-earth magnet, and that field can be used to estimate the magnet (and therefore rod) position.
The magnetic levitation system was used in two labs, both related to using continuous-time control with lead and lag compensation. In the first of the two labs, students used physical insight to determine the structure of the differential equation model of the unstable levitation system, and then designed experiments to estimate the parameters of the model. Using the approximate model, students designed lead-compensated controllers using operational amplifiers, resistors and capacitors. Usually, since the model is approximate, the component values had to be “tweaked” until the system was stable, and could suspend the rod.
In the second magnetic levitation labs, students started by using the stabilized levitator to measure the frequency response of the closed-loop system, either using a frequency-sweeping utility that is part of the software suite we developed, or, since the system is continuous-time, by using standard test equipment for measuring frequency responses. Students constructed models by fitting rational functions to the measured closed-loop frequency responses, an approach often referred to as “grey-box” modeling. Then they backed out the open loop model. With the better model, some students were able to design a higher-performance controller using a combination of lead and lag compensation.
An Instrumented Flexible Arm
One challenge in using gearhead motors for position control is the issue of “backlash” (due to imperfect meshing of gears). In the instrumented flexible arm shown in Figure 6, the backlash is eliminated using rubber bands wrapped around the spindle of the motor. The motor in the flexible arm can be driven with high-frequency PWM, and sensed with an in-axis potentiometer at the driven end of the arm and with an optical distance sensor at the arm's end.
The arm can be made flexible or stiff, as can the rubber bands, leading to a wide range of modeling and control problems. As an elementary modeling problem, students can experiment with the impact of the rubber bands on the behavior of a stiff arm. As an advanced control problem and an example of black-box modeling, students extract a state-space model from the arm's frequency response, then design an observer-based state-space controller, using measured statistics for the state estimation.
The cost of commodity hardware is plummeting (the parts cost for all the above artifacts is less than a technical subject textbook), so it has never been easier to hand students collections of easily combined micro-controllers, sensors, and actuators that enable them to create extraordinary and inspiring artifacts. Yet, most upper-level control classes are still taught using simulation, or its near-equivalent, pre-characterized precision hardware. If we want students to view sophisticated mathematical modeling and control as a tool they can use in real engineering design, we need to develop modeling and control problems that use commodity hardware, ones that really challenge students to expand their understanding of sophisticated mathematical concepts, without burying them in rudimentary preliminaries. Such examples are not easy to find, but if more of us are looking, and sharing, the situation will change rapidly.