In a robotics capstone, the System Design Review (SDR) is the point where the team must demonstrate that the proposed architecture (mechanical, electrical, sensing, computation, and control) can satisfy the previously defined requirements. Formally, we can collect the requirements into an inequality-constrained set:

\[ \mathcal{R} = \left\{ \boldsymbol{\theta} \in \mathbb{R}^p \;\middle|\; g_j(\boldsymbol{\theta}) \leq 0,\; j = 1,\dots,m \right\}, \]

where \( \boldsymbol{\theta} \) is a vector of design parameters (controller gains, sampling periods, gear ratios, sensor resolution, etc.) and \( g_j \) encode constraints such as:

• Closed-loop stability constraints on eigenvalues or poles.
• Performance constraints on overshoot, settling time, and steady-state error.
• Real-time constraints on computational load and sampling periods.
• Reliability constraints on expected failure rates of critical components.

At SDR, the team must show that the current design vector \( \boldsymbol{\theta}_{\text{SDR}} \) lies inside \( \mathcal{R} \), or at least inside an approximate feasible set \( \tilde{\mathcal{R}} \) that accounts for modeling uncertainty:

\[ \boldsymbol{\theta}_{\text{SDR}} \in \tilde{\mathcal{R}} \subseteq \mathcal{R}. \]

This lesson explains how to derive such constraints from the robot architecture and how to organize them so that a design review is a rigorous, defensible checkpoint rather than a purely qualitative discussion.

A capstone robot can be abstracted as an interconnection of subsystems: mechanical structure, actuators, sensors, and computing/control. At the level of linear control, a common abstraction is a continuous-time state-space model for the closed-loop system:

\[ \dot{\mathbf{x}}(t) = \mathbf{A}\mathbf{x}(t) + \mathbf{B}\mathbf{r}(t), \quad \mathbf{y}(t) = \mathbf{C}\mathbf{x}(t), \]

where \( \mathbf{x} \) stacks states from each subsystem and \( \mathbf{r}(t) \) is a reference or command. For an SDR, we often decompose:

\[ \mathbf{x}(t) = \begin{bmatrix} \mathbf{x}_m(t) \\ \mathbf{x}_a(t) \\ \mathbf{x}_s(t) \\ \mathbf{x}_c(t) \end{bmatrix}, \quad \mathbf{A} = \begin{bmatrix} \mathbf{A}_m & \mathbf{0} & \mathbf{0} & \mathbf{0} \\ \mathbf{0} & \mathbf{A}_a & \mathbf{0} & \mathbf{0} \\ \mathbf{0} & \mathbf{0} & \mathbf{A}_s & \mathbf{0} \\ \mathbf{0} & \mathbf{0} & \mathbf{0} & \mathbf{A}_c \end{bmatrix} + \Delta \mathbf{A}, \]

where the diagonal blocks model local closed loops (e.g., motor current loop, velocity loop) and \( \Delta \mathbf{A} \) captures coupling (e.g., sensor delays, computational jitter, unmodeled dynamics).

In many early-stage designs, the coupling is small, and \( \mathbf{A} \) is approximately block diagonal. A basic result then provides a simple SDR stability check:

Proposition 1 (Approximate modular stability).

Assume \( \Delta \mathbf{A} = \mathbf{0} \); then \( \mathbf{A} \) is block diagonal, and its eigenvalues are the union of the eigenvalues of the subsystems:

\[ \sigma(\mathbf{A}) = \sigma(\mathbf{A}_m) \cup \sigma(\mathbf{A}_a) \cup \sigma(\mathbf{A}_s) \cup \sigma(\mathbf{A}_c). \]

If all eigenvalues of each block have strictly negative real part, i.e.,

\[ \max_{\lambda \in \sigma(\mathbf{A}_k)} \operatorname{Re}(\lambda) < 0 \quad \text{for all } k \in \{m,a,s,c\}, \]

then the origin is an asymptotically stable equilibrium for the full system.

Sketch of proof.

For block diagonal \( \mathbf{A} \), the characteristic polynomial factors as the product of the characteristic polynomials of the blocks:

\[ \det(\lambda \mathbf{I} - \mathbf{A}) = \prod_{k \in \{m,a,s,c\}} \det(\lambda \mathbf{I}_k - \mathbf{A}_k). \]

Thus, the roots of the full polynomial are exactly the roots for each block. If every block is Hurwitz (all eigenvalues have negative real part), then all eigenvalues of \( \mathbf{A} \) lie in the open left half-plane, which implies asymptotic stability for the LTI system.

At SDR, you cannot ignore \( \Delta \mathbf{A} \), but this decomposition motivates the idea that each local loop should be stable with some margin before integration.

Many capstone performance requirements can be mapped to classical second-order closed-loop metrics. Consider a dominant second-order mode with closed-loop transfer function

\[ G_{\text{cl}}(s) = \frac{\omega_n^2}{s^2 + 2\zeta \omega_n s + \omega_n^2}. \]

For a step input, the standard formulas for overshoot \( M_p \) and settling time \( T_s \) (for the 2 % criterion) are:

\[ M_p = \exp\!\left( -\frac{\pi \zeta}{\sqrt{1 - \zeta^2}} \right), \quad T_s \approx \frac{4}{\zeta \omega_n}, \quad 0 < \zeta < 1. \]

Suppose the design requirements specify:

• Overshoot at most 10 %: \( M_p \leq 0.10 \).
• Settling time no more than 1.5 s: \( T_s \leq 1.5 \).

These become nonlinear inequalities in \( \zeta \) and \( \omega_n \):

\[ \exp\!\left( -\frac{\pi \zeta}{\sqrt{1 - \zeta^2}} \right) \leq 0.10, \quad \frac{4}{\zeta \omega_n} \leq 1.5. \]

Taking logarithms of the first inequality yields

\[ -\frac{\pi \zeta}{\sqrt{1 - \zeta^2}} \leq \ln(0.10) \quad \Rightarrow \quad \frac{\pi \zeta}{\sqrt{1 - \zeta^2}} \geq -\ln(0.10). \]

Solving numerically gives \( \zeta \gtrsim 0.59 \). The second inequality gives

\[ \omega_n \geq \frac{4}{1.5 \zeta}. \]

Thus, the SDR can state performance feasibility as: choose controller gains such that \( \zeta \geq 0.6 \) and \( \omega_n \geq \frac{4}{1.5 \zeta} \). Any design failing these inequalities does not meet the spec.

Similar inequalities can be written for steady-state error, e.g., for a type-1 system tracking a step of magnitude \( A \), the position error constant \( K_p \) must satisfy

\[ e_{\text{ss}} = \frac{A}{1 + K_p} \leq e_{\max} \quad \Rightarrow \quad K_p \geq \frac{A}{e_{\max}} - 1. \]

The SDR must also verify that the chosen sampling period and computing hardware can sustain the control and perception loops. For a digital controller with sampling period \( h \), a common rule is that the closed-loop bandwidth \( \omega_c \) satisfies

\[ \omega_c h \leq \alpha \pi, \quad \text{with } 0 < \alpha < 1, \]

where \( \alpha \) is a safety factor (for instance, \( \alpha \approx 0.2 \) for 10 samples per period at the crossover frequency). This inequality enforces that the sampling frequency is sufficiently higher than the closed-loop bandwidth.

Additionally, for each periodic task \( i \) in the control software (e.g., control loop, sensor fusion, logging), with worst-case execution time \( C_i \) and period \( T_i \), define the utilization

\[ U = \sum_{i=1}^n \frac{C_i}{T_i}. \]

For some scheduling strategies, a sufficient feasibility condition is \( U \leq U_{\text{max}} \) for a known constant \( U_{\text{max}} < 1 \) (depending on the scheduler). At SDR, the team should present a table of \( C_i \), \( T_i \), and the resulting utilization to show that the CPU can safely support all real-time tasks.

For critical functions (e.g., emergency stop, safe power cutoff), the SDR should quantify reliability. Consider components with independent exponential failure distributions and rates \( \lambda_i \). The reliability of component \( i \) at time \( t \) is

\[ R_i(t) = \exp(-\lambda_i t). \]

For a series structure, where all components must function, the system reliability is

\[ R_{\text{series}}(t) = \prod_{i=1}^n R_i(t) = \exp\!\left( - t \sum_{i=1}^n \lambda_i \right). \]

For a parallel redundant structure with two components (\( i=1,2 \)) where either can perform the safety function, the reliability is

\[ R_{\text{parallel}}(t) = 1 - \prod_{i=1}^2 (1 - R_i(t)) = 1 - \left(1 - e^{-\lambda_1 t}\right) \left(1 - e^{-\lambda_2 t}\right). \]

At SDR, one can present computed values of \( R_{\text{series}}(t_0) \) or \( R_{\text{parallel}}(t_0) \) at a mission time \( t_0 \) and compare them to a minimum acceptable reliability \( R_{\min} \). If

\[ R_{\text{system}}(t_0) \geq R_{\min}, \]

then the reliability requirement is met; otherwise redundancy or component choice must be revisited.

Beyond computations, the SDR is a structured process. The diagram below summarizes a typical flow from requirements to review outcomes.

flowchart TD
  RQ["Requirements and constraints finalized"] --> ARCH["Proposed system architecture & interfaces"]
  ARCH --> MODELS["Control models, timing analysis, reliability estimates"]
  MODELS --> CHECKS["Quantitative checks vs. specs"]
  CHECKS --> DOCS["Compile SDR package (slides, report, tables)"]
  DOCS --> MEET["Hold review meeting with faculty and peers"]
  MEET --> OUT1["Approved with \nminor actions"]
  MEET --> OUT2["Conditionally approved \n(major redesign items)"]
  MEET --> OUT3["Not approved \n(fundamental issues)"]
        

The SDR package should clearly trace each requirement to the specific model, analysis, or test that demonstrates feasibility.

Python, with libraries such as numpy and python-control, can be used to automatically verify control performance requirements (e.g., overshoot and settling time) for a candidate controller.

import numpy as np
import control as ctrl  # python-control library

# SDR specifications
Mp_max = 0.10      # max overshoot (10%)
Ts_max = 1.5       # max settling time (seconds)

# Candidate closed-loop transfer function (second-order approximation)
zeta = 0.7
omega_n = 4.0
num = [omega_n**2]
den = [1.0, 2.0*zeta*omega_n, omega_n**2]
G_cl = ctrl.TransferFunction(num, den)

# Step response and performance data
t, y = ctrl.step_response(G_cl)
info = ctrl.step_info(G_cl)

Mp = info["Overshoot"] / 100.0
Ts = info["SettlingTime"]

print(f"Overshoot: {Mp:.3f}, Settling time: {Ts:.3f} s")

if Mp <= Mp_max and Ts <= Ts_max:
    print("SDR check PASSED: performance requirements satisfied.")
else:
    print("SDR check FAILED: redesign controller gains.")
      

Such scripts can be extended to test a grid of controller gains and produce a feasible region in parameter space, which can then be summarized in SDR documentation.

8.1 C++ (Eigen) — Stability Check for a State Matrix

C++ with Eigen is common in robotics stacks using ROS. Below is a minimal example checking whether a continuous-time state matrix \( \mathbf{A} \) is Hurwitz (all eigenvalues have negative real parts).

#include <iostream>
#include <Eigen/Dense>

int main() {
    Eigen::Matrix2d A;
    A << 0.0, 1.0,
          -2.0, -0.5;

    Eigen::EigenSolver<Eigen::Matrix2d> es(A);
    Eigen::VectorXcd eigvals = es.eigenvalues();

    bool stable = true;
    for (int i = 0; i < eigvals.size(); ++i) {
        if (eigvals[i].real() >= 0.0) {
            stable = false;
        }
    }

    if (stable) {
        std::cout << "A is Hurwitz: SDR stability check PASSED\n";
    } else {
        std::cout << "A is NOT Hurwitz: SDR stability check FAILED\n";
    }
    return 0;
}
      

8.2 Java — Encapsulating Requirements and Checks

Java appears in some robotics platforms (e.g., educational robotics). The following sketch encodes performance requirements and a simple evaluation against measured data.

public class SdrChecker {
    private final double mpMax;
    private final double tsMax;

    public SdrChecker(double mpMax, double tsMax) {
        this.mpMax = mpMax;
        this.tsMax = tsMax;
    }

    public boolean check(double mpMeasured, double tsMeasured) {
        return mpMeasured <= mpMax && tsMeasured <= tsMax;
    }

    public static void main(String[] args) {
        SdrChecker checker = new SdrChecker(0.10, 1.5);

        // Example: results from an experiment or simulation
        double mp = 0.08;
        double ts = 1.2;

        if (checker.check(mp, ts)) {
            System.out.println("SDR: requirements satisfied.");
        } else {
            System.out.println("SDR: requirements NOT satisfied.");
        }
    }
}
      

8.3 MATLAB/Simulink — Using stepinfo

MATLAB is widely used for control analysis; Simulink can represent the robot control architecture graphically and feed into an SDR.

% SDR specifications
Mp_max = 0.10;
Ts_max = 1.5;

% Candidate second-order closed-loop transfer function
zeta = 0.7;
omega_n = 4.0;
num = [omega_n^2];
den = [1, 2*zeta*omega_n, omega_n^2];
Gcl = tf(num, den);

info = stepinfo(Gcl);
Mp = info.Overshoot / 100.0;
Ts = info.SettlingTime;

fprintf("Overshoot: %.3f, Ts: %.3f s\n", Mp, Ts);

if Mp <= Mp_max && Ts <= Ts_max
    disp("SDR check PASSED: performance requirements satisfied.");
else
    disp("SDR check FAILED: adjust controller gains.");
end

% In Simulink, connect the plant and controller blocks,
% run a step response simulation, and call stepinfo on
% the logged output signal for automated SDR checks.
      

In this lesson, we viewed the System Design Review as a mathematical and organizational checkpoint for a robotics capstone. We represented the robot as an interconnected linear system, related performance requirements to damping ratio and natural frequency, imposed timing and utilization constraints for real-time feasibility, and introduced simple reliability models for critical subsystems. We also sketched how Python, C++, Java, and MATLAB/Simulink can automate these checks. In your own projects, translating informal requirements into explicit inequalities and then verifying them with models and code is a key habit of professional robotics engineering.