Fast and Spurious

You are not logged in.

Please Log In for full access to the web site.
Note that this link will take you to an external site (https://shimmer.mit.edu) to authenticate, and then you will be redirected back to this page.

Quick Reference

Serial Plotter Send Window Indices

Links

  • Software to install is described here.
  • Build instructions are here.
  • Sketch for this lab is here.

Task Summary

Week A

  1. FIND A PARTNER.
  2. Install Software.
  3. Build, Test, and Calibrate the Speed Control System (checkoff 1).
  4. Determine the roles of TICKSPERUPDATE , KFF, KP, REPEATS, FREQ, and AMP, and DisturbA (checkoff 2).

Week B

  1. Extract coefficients from data for a 1st-order difference equation model.
  2. Use model to inter-relate gains, update period, and stability. Compare with experiments (checkoff 3).
  3. Investigate how gains effect tracking error and disturbance rejection, design controller (checkoff 4).
  4. Collect experimental data for the postlab (as screenshots) (Checkoff 5)

Safety First

Please read the EECS Lab Safety instructions.

  • We will be building and debugging electrical systems. While everything we do in this subject is low-voltage, you should never modify or even touch a circuit without turning off its power.
  • We will be using small but very high speed motors. If our systems go unstable, parts can fly off in any direction. Please wear safety goggles when using the high-speed motors with spinning propellers.
Please sign the EECS Lab Safety form now! You will not be allowed to work in the lab (38-545) and get a grade in this subject unless you indicate that you have reviewed the safety instructions by signing the form.

Fast and Spurious

Introduction

The goal of this lab is to control the speed of a motor-driven rotor, while learning about

  1. Control system modeling,
  2. Feedback and Stability,
  3. Sample Rate Effects,
  4. Steady-state and Dynamic Tracking,
  5. Insensitivity to Disturbances and uncertainty,

As you will see, the issues associated with control will be obvious and direct, but the issues associated with modeling will be both pervasive and, unfortunately, subtle.

After constructing and testing the speed control system, you will collect data from which to calibrate a first-order difference equation model for the relationship between the Teensy-sketch-generated motor command and the measured rotor speed. You will then use this model to make reasonably good predictions about the interactions between sample rates, controller gains, stability, tracking errors, and disturbance insensitivity.

Then, in preparation for the post-lab, you will collect another data set, one specifically designed to expose inaccuracies in the first-order model. As part of the post-lab, you will derive, calibrate, and analyze an improved second-order model, and see if its predictions are better (spoiler alert, sometimes they are).

The take-away about modeling from this lab and post-lab is NOT (we repeat, NOT) that one model is good and the other is bad. As you will see in lab, a first-order model is accurate enough (and simple enough) to answer questions about the interaction between sample rate and stability, or feedback gain and disturbance rejection. But as you will see in the postlab, you'll need a second order model to accurately predict the stability limits on gain, or to predict waveforms near the stability limit.

So, The take-away from this lab and postlab about modeling? A good model is usually the simplest model that correctly answers your questions.

Installation and Construction.

We use the Arduino IDE 2.0 software (with modifications and a 6.310 specific library) to communicate with, program, and plot results from our 6.310 controller board (based on the Teensy 4.1 microcontroller). Throughout the term, you will be using this software-board combination, along with lab-specific hardware, to design and experiment with algorithms that control rotor speed, rotating arm position, and even magnetic levitation.

For the first checkoff please:

  1. Install the software described here.
  2. Build and test the speed control system as described here.

Checkoff 1:

Demonstrate your working and calibrated speed control system

  • In Mode0, show that the maximums of your signal are high enough, and the minimums are low enough.
  • In Mode1, try changing the motor speed using the potentiometer, what is the range of speeds.
  • What happens when you set the ticks per update to 1? How noisy is the speed measurement?
  • Demonstrate that you can reproduce the last experiment in speed assembly guide (at the bottom of the web page, on the right). What was a good disturber amplitude?

Speed Control

As the above abstract block diagram suggests, controlling the rotation speed of a spinning object requires three interconnected functions. Foremost of the three is an actuator that can be commanded to either accelerate or decelerate the object. Second, one needs a sensor to verify the object's speed. And thirdly, the focus of much of this class, one must design a controller that can determine effective actuator commands given the desired and measured speeds of the object.

Perturbations from Nominal

As you may have noticed when testing your speed-controlled rotor system, there is a nominal speed of 15 rotations/second (or 15RPS), and an associated nominal actuator command. All the other speeds and commands are offsets to these nominal values, so our system is more precisely described by the abstract diagram below. We formulated our speed control problem in terms of perturbations from nominal values partly because it is a natural fit to the common control problem, maintaining constant speed (think automobile cruise control). But more importantly for our purposes, relationships between perturbations are likely to be more linear, and therefore more easily modeled. And good models, as we shall see thoughout the term, are essential precursers to designing good controllers.

Abstracting from Structure

Below is a functional block diagram of our speed control system, based on its physical structures. What should be immediately clear is that the functional block diagram looks nothing like the abstract block diagrams above. For example, is the motor the actuator? Or is it the motor plus the H-Bridge drivers? Also, the combination of the white eight-bladed rotor and the optical sensor does not produce rotation speed, it produces a signal from which the speed can be deduced. So does the combination really form the sensor in our abstract model?

Whether the problem is software or hardware or some combination of the two, finding a good abstract model is often the central challenge in any engineering design. As we noted in the introduction, a good model has enough detail to accurately assess design tradeoffs, yet is simple enough to reveal alternative strategies. But, how does one find a model good enough to answer one's questions, if one needs the model to determine what questions to ask? And how does one find a model that reveals strategies one does not yet know?

Modeling, it is impossible to teach, but fortunately, not impossible to learn.

Connecting Structures and Abstractions

In the case of our speed control system, we can extract an abstract model like the one in section 3.1, provided we ignore the structural boundaries. The speed sensor is a combination of the rotor, the optical sensor, and the function getSpeed in the Teensy sketch (which converts the time between falling edges in the optical sensor output into speed estimates, see the next section). The actuator in the abstract diagram is a combination of the function hbridgeBipolar in the Teensy sketch (which converts a motor command into a pulse-width-modulated signal), the h-bridge driver, and the motor connected to the white rotor.

We summarize the connection between abstract model and structural implementation in the figure below.

The Controller Block

As we can see from the figure in the previous subsection, there is a small part of the Teensy sketch that corresponds to the speed-controller block in the abstract block diagram. The actuator command, motorCmd in the sketch, is computed from the nominal command, nomCmd in the sketch, the desired perturbation in rotor speed, omega_d in the sketch, and the measured perturbation in motor speed, omega in the sketch. To make the meaning of omega and omega_d clearer, consider the example plot below. The plot was generated by running the speed control system in control mode (MODE 1), with omega_d set to be a unit amplitude square wave, the controller gain Kff set to 0.025, and the square wave frequency set to \frac{1}{25}.

Below we show an incomplete block diagram for the controller, showing how the motor command is computed from the desired and measured rotational speeds, as well as the nominal command (which is just added in). The block diagram shows how K_p, the proportional feedback gain, effects the motor command, but does not show the effect of K_{ff}. Be prepared to show how to add K_{ff} to the block diagram at checkoff.

Sensing Speed

The optical sensor generates a pulse every time a white encoder blade passes underneath it. More specifically, the propeller reflects the infrared light from the led on one side of the sensor to the optotransistor on the other side of the sensor, and when bombarded with infrared light, the optotransistor turns "on". The "on" transistor effectively "pulls-up" the IN5 input on the 6.310 controller board, increasing the voltage from close to zero to nearly three volts. Once the propeller blade passes out from under the sensor, the optotransistor turns "off", the IN5 voltage is pulled back down to zero by a resistor ground (see the schematic in the assembly guide).

The negative change in the voltage on IN5 "interrupts" the microcontroller, which determines the time since the last negative change, and computes the rotational speed.

The signal generated by the optical sensor circuit is plotted below (notice the y-axis is normalized, so that 1000 corresponds to three volts), along with a diagram showing when interrupts are triggered on the Teensy 4.1, as well as when a control loop (which updates the motor command) executes. As the diagram should make clear, interrupts are generated every time a propeller blade passes under the optical sensor (eight times per rotation for our eight-bladed rotor), but the control loop only runs every m^{th} interrupt, where m is the setting of ticksperupdate. Note that when ticksperupdate is zero, m is set to the maximum value of 8.

Checkoff 2

Checkoff 2:

Demonstrate a working controller

  • Try changing the input frequency (using the send window with the FREQ index), what happens?
  • What happens when you set the input amplitude (using the send window with the AMP index) to a negative value?
  • How should K_{ff} be added to the controller block diagram?
  • How is changing K_{ff} different from changing K_p?
  • What happens when you use the send window with the REPEATS index to send values from one to five?
  • Try changing ticksperupdate using the TICKSPERUPDATE index in the send window (try every value from 1 to 8). For what value is the speed measurement noisest, and why? Does changing ticksperupdate change the effect of K_{ff} ? The effect of K_p?

STOP HERE FOR THE FIRST WEEK!!!!

Difference Equation Modeling.

Recall that when calibrating the speed control setup, we adjusted the potentiometer to find a constant motor command, C_0 (nomCmd in the Teensy sketch), that produces the desired steady-state rotational speed, \Omega_0 (Omega0 in the sketch). Then, using lower case letters to denote perturbations from from these steady-state values,

c[n] = C[n] - C_0 \;\;\; \omega[n] = \Omega[n] - \Omega_0 \;\;\; \omega_d[n] = \Omega_d[n] - \Omega_0
where c[n] (corresponding to cmd in the sketch) is the perturbation in motor command, \omega[n] (corresponding to omega in the sketch) is the perturbation in measured rotational speed and \omega_d[n] (corresponding to omega_d in the sketch) is the desired perturbation in rotational speed.

Using a first-order difference equation model, we can relate perturbations in motor command to perturbations in rotational speed

\omega[n] \approx \omega[n-1] + \Delta T \cdot \left( \beta \omega[n-1] + \gamma c[n-1]\right),
where \omega[n] is the perturbation in motor angular velocity in RPS, \Delta T is the sample period, and c[n] is the perturbation in motor command. Note that since the sample period is dependent on the motor speed, and the motor speed is being perturbed, we are ignoring the perturbations in \Delta T. Instead we will assume \Delta T \approx \frac{1}{\Omega_0} (assuming the angular velocity is in units of RPS).

One way to generate responses from which to calibrate the linearized model is to use the AMP index in the send window to set the maximum value of omega_d to a few percent of the nominal speed, then use the KFF index to set K_{ff} so that omega reaches a steady-state that matches omega_d (once you set the input frequency low enough using the send window and the FREQ index).

For the above senario, and in steady-state, \omega[n] = \omega[n-1]= \omega_d[n]. Since

c[n] = K_{ff}*\omega_d[n],
there is a lot of fortuitous cancellation, yielding a simple relation between \beta and \gamma.

You can derive a second relation involving \beta and \gamma by examining the immediate (rather than steady-state) behavior of the perturbed rotational velocity, \omega[n], in response to the step changes in \omega_d[n]. And the analysis of \omega[n] dynamic behavior will simplify if you exploit the fact that the system is linear, and that both \omega and \omega_d are in steady-state before the step change.

Notice that there are two coefficients to estimate (\beta and \gamma), and two types of information in the step responses, how fast the measured speed changes and its steady-state value.

In the next checkoff, you can test your model to see if you can predict the stability properties when you use feedback control.

Checkoff 3:

Determine \gamma and \beta for your system.

  • Be ready to show us how you found the two parameters.

Using Feedback Control.

If you set the K_{ff} to zero, and set the K_p to a nonzero value, the c[n] for your system becomes,

c[n] = K_p*(\omega_d[n] - \omega[n])
and the system will only be stable for a certain range of K_p. Use similar values with the AMP and FREQ indices as you used for model calibration, and watch the step responses as you slowly increase K_p (using the send window and the KP index). Determine when your system goes unstable and see if your experiments match predictions from your calibrated model.

Then use the TICKSPERUPDATE index in the send window to set the ticksperupdate to 4, then 2 and then 1. How will you change \Delta T in your difference equation model to reflect the changes? For each value of ticksperupdate, find the value of K_p for which the system is stable, and see if your experiments match your updated models.

Now set the DisturbA value to 0.5 (on line 14 of the Teensy sketch), and repeat the above experiments. How does the disturbance response change with increasing K_p? Can you use your model to predict how the disturbance response should change with K_p (hint, if you use a very low input frequency, the disturbance response will achieve steady-state, simplifying the analysis).

Checkoff 4:

Be ready to show us both steady-state errors and disturbance rejection, and you should be able to use the difference equation model, and its natural frequencies as a function of K_p , to explain the disturbance rejection and stability.

  • How does the ticksperupdate affect the range of stable K_p values. Do your experiments match predictions from your model?
  • How does ticksperupdate affect disturbance rejection?
  • What parameters give you the best performance? What are your error metrics?
  • Would it help to use a combination of K_{ff} and K_p. Will that help reduce steady-state error? Will it help improve disturbance rejection?

Collecting data for the postlab.

Set ticksperupdate back to 8 (or 0), set DisturbA back to zero, pick the same frequency and amplitude for the input as you used in the model calibration, and examine the step response for values of K_p that are close to the stability limit. Then use the send window with the REPEATS index and a value of 3, to force the plotter to plots each point four times. These repeated plots will createa flat section for each sample, and make it easier to see the number of samples per period when there are oscillations. Look closely at step responses that oscillate before settling, could they be produced by a first order system? You should take screen shots of your results, you will need them for the postlab.

Then try setting ticksperestimate (NOT ticksperupdate!!) to 1 using the send window with the TICKSPERESTIMATE index, and increase K_p until the step response is almost unstable. Then try setting ticksperestimate to 2, then 3, and then 4. You should take screen shots of your results, you will need them for the postlab.

Checkoff 5:
Something is not right, but the effect is subtle. Get the checkoff to get some some hints.