| C1 | When describing performance, either use words that are widely understood to have a precise technical meaning or provide a definition yourself (i.e., say what you mean). |
| C2 | Use italic upper-case “K” and “L” to denote the gain matrices for linear state feedback and linear observer (unless you clearly explain some alternative notation). |
| C4 | Specify both the “of what” and “with respect to what” when talking about derivatives (including Jacobians). |
| C5 | The abstract should provide a summary of key quantitative results (with actual numbers) that were obtained. Placeholders can be used in drafts when final results aren’t available yet. |
| C6 | Do not provide unnecessary information about the computer, programming language, application, etc., that you used for implementation. |
| C7 | Theory should be in the Theory section, not also in the Introduction, the Experimental Methods, etc. |
| C8 | Provide enough information about the system to be controlled — including a clear description, a schematic, and a citation, for example — so that readers will understand even if they have not previously seen or worked with that system. Make sure all information provided is correct. (Note that it is usually best to describe the system exactly once, early in your report.) |
| C9 | Linear state feedback should be negative (i.e., “-Kx” and not “Kx”) unless you clearly explain why you are taking a non-standard approach. |
| C10 | We strongly recommend that you follow the four-step process described on the course website (see Reference > State space models > How do I put a system in state space form?) to linearize the equations of motion. The order of this process, in particular, is important. For example, you cannot define the state “x” or input “u” of the state-space model without having first chosen an equilibrium point, because “x” and “u” are defined in terms of this equilibrium point. If you choose not to follow this four-step process, you must explain clearly and justify rigorously whatever alternative process you are using. |
| C11 | Our method of deriving a state space model requires linearizing about an equilibrium point that is both constant and known in advance. Any other method should be clearly explained and justified. |
| C13 | Be specific enough about your methods so that another engineer could reproduce them. |
| C14 | Only the real or imaginary part of an eigenvalue can be positive or negative, not the eigenvalue itself. |
| C15 | You must state (e.g., via pole placement, LQR, etc.) and justify your choice of gain matrix (e.g., by showing if the resulting closed-loop system is stable). |
| C23 | Variables must be defined in the text immediately before or after they are used, even if they are listed in the Nomenclature (that list is for reference — it collects all of the variables that are defined and used in the rest of the report). |
| C24 | Use specific criteria instead of subjective terms (e.g., good or bad, best or worst, etc.). |
| C30 | When plugging numerical values into a symbolic expression, either say what those values are (i.e., give the actual numbers) or provide a reference to where those values can be found (e.g., the course website, a github repository, code submitted as one of your final deliverables, etc.). |
| C33 | Our convention is to denote the state, input, and measurement of the nonlinear system by “m”, “n”, and “o” and to denote the state, input, measurement of the linearized system (i.e., the state-space model) by “x”, “u”, and “y”. If you use a different convention, you must make that clear. Whatever notation you choose must clearly distinguish between the state, input, measurement of the nonlinear system and the state, input, and measurement of the linear system — these things are (in general) not the same. |
| C36 | Either clearly describe and rigorously justify any methods used or cite a reference that does this for you. Note that it is almost always better to cite a reference, if the method is not new and if a reference is available. In particular, it is likely impossible to provide a complete description of a method like eigenvalue placement or LQR in the context of a 6-page report (the reference page on the course website provides a minimally complete description, which is already too much for you to include) — use a citation for these sorts of things. |
| C37 | Nomenclature must list all variables used in the report along with their units enclosed in parentheses (unless a variable is dimensionless). |
| C40 | Do not define any given variable more than once in the Nomenclature. |
| C45 | If eigenvalue placement is used, you must clearly state and justify your choice of eigenvalue locations. (Eigenvalues must have negative real part and — if they have non-zero imaginary part — must be in complex conjugate pairs, but otherwise their location is an engineering decision. They could have zero or non-zero imaginary part, they could have a real part that is more negative or less negative, they could all be at the same location or could be at different locations, etc.) |
| C46 | The gain matrix for linear state feedback K must have as many rows as there are inputs and as many columns as there are states. The gain matrix for linear observer L must have as many rows as there are states and as many columns as there are measurements, |
| C47 | Experiments must be described in enough detail that they could be understood and repeated by a colleague. |
| C49 | The length of each simulation must be stated. |
| C50 | The initial conditions for each simulation must be stated. If they were chosen randomly, specify how they were selected. For example, if chosen uniformly, specify the range; if drawn from a normal distribution, specify the mean and variance. |
| C51 | While it may be appropriate to describe experiments that were used to iterate on your control design, there must be a comprehensive set of experiments that validate your final control design (where “final” means “after you have stopped making changes”). |
| C52 | Quantitative results from many experiments (meeting the minimum project requirements, if such requirements are specified) — presented in figures and/or tables — should be used to support claims made in your report about the extent to which your control system “works” (however you have chosen to define that word). Results from only one experiment or a small number of experiments do not provide sufficient evidence in general. |
| C53 | You should make clear what “success” means (i.e., what it means for your controller to “work”), for example by providing a quantitative measure of performance. |
| C54 | Words like “optimal,” “optimized,” “optimization,” etc., must not be used without first defining a quantity that is being maximized (e.g., a reward) or minimized (e.g., a cost). |
| C60 | The number of simulations performed must be stated and meet the minimum project requirements, particularly if these simulations are used to produce aggregate results (e.g., mean or standard deviation). |
| C65 | Experimental Methods should describe the experiments that were performed and should not present results. Results and Discussion should present the results that were obtained and should not describe the experiments. |
| C69 | Be specific about methods used. (For example, instead of saying that you “did calculations,” say what you calculated and how you did it. Similarly, instead of saying that you “wrote code,” say what it was that you implemented.) |
| C71 | Equations must be consistent with what is described in the text. (For example, if some eigenvalues in an equation do not have negative real part, the text should not claim that all eigenvalues have negative real part.) |
| C73 | If you present a result in Results and Discussion, you must describe the experiment that produced it in Experimental Methods. If you describe an experiment in Experimental Methods, you must present the results of that experiment in Results and Discussion. |
| C75 | Clearly define non-standard functions before they are used (e.g., “\lambda (A - BK)”). |
| C76 | If you apply LQR to design a controller, you must state and justify your choice of weights Q and R. (Remember that LQR computes K given Q and R — it doesn’t compute Q and R or otherwise tell you what these weights should be.) If your control system includes an observer, then these requirements apply to the dual LQR that determines the observer gain L as well. |
| C78 | If any work other than your own is used in your report (i.e. lecture notes, code, course website, textbook, articles, etc.), it must be cited in the References section. |
| C79 | Sources listed in the “References” section must be referenced within the text at least once. |
| C80 | The (nonlinear) equations of motion that describe the system to be controlled must be presented and correct. If these equations of motion are not already in standard form, then the process of putting them in standard form must be described and the result must be correct. |
| C81 | The choice of equilibrium point must be stated and correct. That is, assuming the equations of motion are written in standard form as $\dot{m} = f(m, n)$, the equilibrium point must be a choice of $m_e$ and $n_e$ for which $f(m_e, n_e) = 0$. The choice of equilibrium point must also be justified (making clear if other equilibrium points exist or if yours was the only possible choice). |
| C82 | The definition of the state x, the input u, and the measurement y in the state-space model that is produced by linearizing the equations of motion about an equilibrium point must be specified and must be correct. That is, assuming the equations of motion and measurement are written in standard forms as $\dot{m} = f(m, n)$ and $o = g(m, n)$ and given a choice $m_e$ and $n_e$ of equilibrium point of the state m and the input n, the state, input, and measurement in the state-space model must be $x = m - m_e$, $u = n - n_e$, and $y= o - g(m_e, n_e)$. Equivalently, $n = u + n_e$ and so forth. |
| C83 | The method of computing the matrices A and B that define the linearized dynamic model (e.g., expressions in terms of Jacobians) must be given and correct — a citation is insufficient. If you choose to show these matrices in your report — either the full matrices with numbers, or the structure of these matrices (e.g., which elements are zero or non-zero) — then these results must also be correct. If your control system includes an observer, then these requirements apply to the matrices C and D that define the linearized sensor model as well. |
| C84 | The elements of the state $m$, input $n$, and measurement $o$ of the (nonlinear) equations of motion and measurement, when written in standard forms as $\dot{m} = f(m, n)$ and $o = g(m, n)$, must be clearly defined. |
| C85 | The rank of the controllability matrix (or, some alternative measure like its determinant or its smallest singular value) must be stated, and the correct conclusion must be drawn about whether or not the state space model is controllable. |
| C86 | The final version of a report must be complete (e.g., it must not still include placeholders). |
| C87 | The description of variables and other quantities in the report must be correct. For example, $w_x$ denotes the $x$ component of angular velocity in a body-fixed reference frame and is not the same as the time derivative $\dot{\phi}$ of the roll angle. Similarly, the $\psi$ is a yaw angle — part of an Euler angle sequence (likely body-fixed), which is one way to represent the orientation of a rigid body or equivalently to parameterize a rotation matrix — and is not a “principal axis value.” |
| C88 | The controllability matrix has as many rows as there are states, and as many columns as the product of the number of inputs and the number of states. It is computed by horizontally stacking B, AB, etc. |
| C89 | The “f” in the expression $\dot{m} = f(m, n)$ that describes equations of motion in standard form should be referred to as a “vector-valued function” and not as “a vector” or “a matrix.” While it is acceptable to refer to “the function f” in text, it is unacceptable to say “f = …” rather than “f(m, n) = …” in an equation. The “g” in the expression $o = g(m, n)$ that describes a nonlinear sensor model should also be referred to (and denoted) as a vector-valued function. |
| C91 | The report must not mischaracterize technical concepts by using incorrect, ambiguous, or unusual language to describe them. For example, the thing that is produced by linearizing the equations of motion is a “dynamic model” and not a “model for the controller.” Similarly, the thing that is produced by linearizing the measurement equations is a “sensor model” and not an “observer model.” |
| C92 | References must be cited to support claims — for example, “attitude control is a critical challenge in modern space systems” or “a star tracker measures the positions of stars… and compares them to a known catalog” — for which you do not provide evidence (e.g., with derivations or experimental results). |
| C93 | The (nonlinear) measurement equations that describe output of sensors must be presented and correct. (e.g., In DP 3, the measurement equations for each individual star and those for all stars must be distinguished and represented using different notations.) If these measurement equations are not already in standard form, then the process of putting them in standard form must be described and the result must be correct. |
| C94 | We strongly recommend that you follow the three-step process described on the course website (see Reference > State estimation > How do I linearize a sensor model?) to linearize the measurement equations. Remember that this process not only results in the computation of “C” and “D”, but also in the definition of “y”. If you choose not to follow this three-step process, you must explain clearly and justify rigorously whatever alternative process you are using. |
| C95 | The observability matrix has as many columns as there are states, and as many rows as the product of the number of outputs and the number of states. It is computed by vertically stacking C, CA, etc. (or by horizontally stacking C^T, (CA)^T, etc., and taking the transpose of the result). |
| C96 | The choice of actuators (e.g., the placement of reaction wheels on a spacecraft) and of sensors (e.g., the location of stars to be tracked) must be made before proceeding with model-based controller and observer design, because the dynamic model (used for controller design) and the sensor model (used for observer design) depend on these choices. A reason for these choices must also be given (e.g., why put a wheel here instead of there, why track three stars instead of five stars, etc.). |
| C97 | The rank of the observability matrix (or, some alternative measure like its determinant or its smallest singular value) must be stated, and the correct conclusion must be drawn about whether or not the state space model is observable. |
| C98 | If the true state is not known, the linear state feedback should be associated with the state estimate — i.e., use $-K \hat{x}$ instead of $-Kx$. |
| C99 | The description of experimental methods must be self-consistent. For example, you cannot say both that initial conditions were random and that initial conditions were not random (i.e., were chosen to be something in particular). In addition, the sum of frequencies should be equal to the total number of samples in histogram. |
| C100 | If the control system includes an observer, the choice of initial state estimate must be specified. |
| C101 | The review in the appendix “from the perspective of one or more of your cat-pilots” must be provided (e.g., prefaced by “stakeholders say”). It must not simply be a repeat of what was said previously (e.g., in the conclusion). |
| C102 | If the control system includes an observer, then the report must provide evidence — presented in figures and tables — both that the observer works (e.g., by looking at error in the state estimate) and that the controller works (e.g., by looking at error in the state). |
| C103 | If the control system includes an observer, then the report must distinguish between error in the state (i.e., the difference “x - 0” or “x - x_des”) and error in the state estimate (i.e., the difference “xhat - x”). Otherwise, any reference to “error” is likely ambiguous. |
| C104 | The report must contain plots that are substantively different from those generated by template code. The plots in the template code are provided only as a starting point and are, in general, not acceptable for use in your report. Even if you modify their style (e.g., to avoid covering plot lines with legends or to label variables in legends with their python names and not with mathematical symbols), these template plots are unlikely to provide useful information. There will always be another choice of plot that is much more useful and much more effective than a template plot. |
| C105 | The report must contain figures and tables that are both meaningful and conceptually correct. For example, a histogram showing the distribution of time until failure does not directly show whether your controller and observer work, since there may be cases where the simulator runs without early termination even if the controller and observer fail to work (e.g., the cat pilot fails to dock). |
| C106 | Provide any method (e.g., reference tracking) that enables the drone to fly through rings. |
| C107 | If reference tracking is used, state and justify how the desired state of the nonlinear system (e.g., m_des) is chosen. This includes correctly specifying all elements of m_des, specifying your values for the desired positions p_x, p_y, and p_z in DP4 (at least for illustrating reference tracking in the Theory section, assuming a single desired position—such as a ring—is given), and explaining why you chose them. |
| C108 | Correctly define the desired state of the linear system (e.g., x_des = m_des - m_e). This includes correctly specifying all elements of x_des, identifying which of them can be changed (i.e., the state variables that can be tracked), while clearly distinguishing m_des from m_e. |
| C109 | The dimensions of Q and R when applying LQR to design a controller must be correct: Q must be a square matrix of size equal to the number of states, and R must be a square matrix of size equal to the number of control inputs. The similar requirements apply to the dual LQR used to design an observer: Q must be square with dimensions equal to the number of states, and R must be square with dimensions equal to the number of measurements. |
| C110 | In DP4, the report must provide evidence — presented in figures and tables — of how fast your drone completes the race (e.g., with a histogram of completion times). |
| C111 | In DP4, the report must provide evidence — presented in figures and tables — of how long it takes for your controller to run (e.g., with a histogram of computation times). |
| C112 | In DP4, the report must identify and diagnose failures (e.g., in the body text, or by visualizing a table categorizing failures and showing how frequently each type occurred) in Results and Discussion. These failures should be in the final design, not failures of an intermediate design that were fixed in the final design. |
| C113 | In DP4, the report must contain “at least four figures [or tables, if justified] of aggregate results from at least 100 simulations.” Remember that a plot with a single trajectory (or a small number of trajectories) is not a plot with “aggregate results.” |