Chapter 16: Capstone Control Project

Lesson 1: Problem Definition and Metrics

This lesson explains how to translate a high-level robotic task into a mathematically precise control problem suitable for a capstone project. We formalize the robot model, control objectives, constraints, and performance metrics (time-domain and norm-based) and show how to encode them in code so that later chapters can focus on controller design, implementation, and evaluation.

1. Role of Problem Definition in a Capstone Project

By the time of a capstone project, you have seen many controller structures (PD/PID, computed-torque, impedance, MPC, adaptive, etc.). However, none of them is meaningful without a clear, rigorous statement of:

  • the plant (robot) and environment model,
  • the inputs and outputs,
  • the constraints and safety set,
  • the control objective (regulation, tracking, force control, etc.), and
  • the metrics used to judge success.

We summarize a fully specified capstone control problem as a tuple

\[ \mathcal{S} = (\mathcal{P}, \mathcal{U}, \mathcal{Y}, \mathcal{X}, \Phi, J, \Gamma) \]

where:

  • \( \mathcal{P} \) is the plant model (robot + environment),
  • \( \mathcal{U} \) admissible inputs (joint torques, motor voltages, etc.),
  • \( \mathcal{Y} \) measured outputs (joint angles, end-effector pose, contact forces),
  • \( \mathcal{X} \) state space and initial conditions,
  • \( \Phi \) constraints and safety requirements,
  • \( J \) performance metric(s) or cost functional(s),
  • \( \Gamma \) admissible controller class (e.g., PD, MPC, adaptive).

In later capstone lessons, you will choose \( \Gamma \) and design the actual controller. In this lesson, we focus on \( \mathcal{P}, \mathcal{U}, \mathcal{Y}, \mathcal{X}, \Phi, J \).

flowchart TD
  H["High-level task (e.g. 'pick and place')"] --> P["Formal plant model P"]
  P --> IO["Define inputs U and outputs Y"]
  IO --> OBJ["Specify control objective (tracking, regulation, force)"]
  OBJ --> CON["List constraints and safety conditions"]
  CON --> MET["Choose metrics J (time-domain, energy, robustness)"]
  MET --> CLS["Select controller class Gamma (next lessons)"]
        

2. Mathematical Specification of the Robot Plant

We assume the robot manipulator dynamics are already known from Robotics: Kinematics and Dynamics, and earlier control chapters. For an \( n \)-DOF rigid manipulator in joint space, a standard model is

\[ \mathbf{M}(\mathbf{q})\ddot{\mathbf{q}} + \mathbf{C}(\mathbf{q},\dot{\mathbf{q}})\dot{\mathbf{q}} + \mathbf{g}(\mathbf{q}) + \mathbf{F}_v \dot{\mathbf{q}} + \mathbf{F}_c \operatorname{sgn}(\dot{\mathbf{q}}) = \mathbf{B}\big(\tau + \tau_d\big) \]

where:

  • \( \mathbf{q} \in \mathbb{R}^n \) is the joint configuration,
  • \( \mathbf{M}(\mathbf{q}) \) inertia matrix,
  • \( \mathbf{C}(\mathbf{q},\dot{\mathbf{q}}) \) Coriolis/centrifugal terms,
  • \( \mathbf{g}(\mathbf{q}) \) gravity vector,
  • \( \mathbf{F}_v, \mathbf{F}_c \) viscous and Coulomb friction matrices/vectors,
  • \( \tau \) control joint torques,
  • \( \tau_d \) unknown disturbances (e.g., unmodeled loads),
  • \( \mathbf{B} \) actuation map (often identity in fully actuated joints).

A state-space representation is obtained by defining \( \mathbf{x} = [\mathbf{q}^\top \; \dot{\mathbf{q}}^\top]^\top \) and treating \( \mathbf{u} = \tau \) as the input:

\[ \dot{\mathbf{x}} = f(\mathbf{x}) + g(\mathbf{x})\mathbf{u} + d(\mathbf{x},t), \qquad \mathbf{y} = h(\mathbf{x}), \]

where \( f \) and \( g \) follow from the manipulator equations and \( d(\mathbf{x},t) \) collects disturbances. For capstone problem definition, you must state:

  • the exact form (or approximation) of \( f, g, h \),
  • which states are measured (joint encoders, force/torque sensors, etc.),
  • which disturbances are modeled explicitly or treated as unknown.

3. Formal Statement of Control Objectives

Most robotic tasks can be expressed as regulation or tracking in joint or task space.

3.1 Joint-space tracking objective

Let \( \mathbf{q}_d(t) \) be a desired joint-space trajectory. Define error

\[ \mathbf{e}_q(t) = \mathbf{q}(t) - \mathbf{q}_d(t), \qquad \dot{\mathbf{e}}_q(t) = \dot{\mathbf{q}}(t) - \dot{\mathbf{q}}_d(t). \]

A basic tracking objective is:

\[ \lim_{t\to\infty} \mathbf{e}_q(t) = \mathbf{0} \quad \text{and} \quad \mathbf{e}_q(t) \text{ remains small for all } t \ge 0. \]

3.2 Task-space tracking objective

Using the forward kinematics \( \mathbf{x} = \phi(\mathbf{q}) \), let \( \mathbf{x}_d(t) \) be the desired end-effector trajectory. Define

\[ \mathbf{e}_x(t) = \mathbf{x}(t) - \mathbf{x}_d(t). \]

For a capstone project, it is good practice to state the objective as a set of inequalities, e.g.

\[ \|\mathbf{e}_x(t)\| \le \varepsilon_{\text{track}} \quad \text{for all } t \in [0,T_{\text{task}}], \]

where \( \varepsilon_{\text{track}} \) and \( T_{\text{task}} \) are design parameters that become part of the project specification.

3.3 Force / impedance objectives

If the project involves contact, a typical impedance objective is

\[ \mathbf{M}_d \ddot{\mathbf{x}} + \mathbf{D}_d \dot{\mathbf{x}} + \mathbf{K}_d(\mathbf{x} - \mathbf{x}_d) = \mathbf{F}_{\text{ext}}, \]

where \( \mathbf{M}_d, \mathbf{D}_d, \mathbf{K}_d \) are desired inertia, damping, and stiffness matrices. The control objective is to make the closed-loop dynamics approximately match this virtual impedance relation.

4. Constraints and Safety Requirements

Capstone projects must be safe and physically feasible. You should explicitly encode:

  • joint and workspace limits,
  • actuator limits,
  • velocity/acceleration bounds,
  • safety-critical sets (e.g., avoiding forbidden regions).

4.1 Hard constraints

Example hard constraints in joint space:

\[ \mathbf{q}_{\min} \le \mathbf{q}(t) \le \mathbf{q}_{\max}, \qquad \|\dot{\mathbf{q}}(t)\|_{\infty} \le \dot{q}_{\max}, \qquad \|\tau(t)\|_{\infty} \le \tau_{\max}. \]

In a safety-critical design (Chapter 13), such constraints are encoded via control barrier functions. For the capstone problem definition, you must at least specify the numerical values of these bounds.

4.2 Safety sets

A general way to express safety is through a safe set

\[ \mathcal{C} = \{\mathbf{x} \in \mathcal{X} \mid h_i(\mathbf{x}) \ge 0, \; i = 1,\dots,m\}, \]

where each \( h_i \) encodes a safety condition (for example, minimal distance to obstacles). The capstone specification should describe \( h_i \) explicitly enough that it can be implemented in code (e.g., as analytic formulas or as a signed-distance oracle).

5. Performance Metrics — Time-Domain and Integral Criteria

In Chapter 1 you saw classical time-domain specs like overshoot, settling time, and steady-state error. A capstone project should also define integral performance metrics to compare different controllers quantitatively.

5.1 Classical specs revisited

For a scalar tracking error \( e(t) \), assume a step-like task. Then:

  • Overshoot: \( M_p = \dfrac{\max_{t \ge 0} |e(t)|}{|r_{\text{step}}|} \times 100\% \).
  • Settling time \( t_s(\varepsilon) \): smallest \( t \) such that \( |e(\tau)| \le \varepsilon |r_{\text{step}}| \) for all \( \tau \ge t \).
  • Steady-state error: \( e_{\text{ss}} = \lim_{t\to\infty} e(t) \) (if it exists).

5.2 Integral error measures

For vector error \( \mathbf{e}(t) \in \mathbb{R}^p \) on \( t \in [0,T] \), typical metrics are:

\[ J_{\text{ISE}} = \int_0^T \mathbf{e}(t)^\top \mathbf{e}(t)\, dt, \qquad J_{\text{IAE}} = \int_0^T \|\mathbf{e}(t)\|_1 \, dt, \]

\[ J_{\text{ITSE}} = \int_0^T t\, \mathbf{e}(t)^\top \mathbf{e}(t)\, dt, \qquad J_{\text{ISU}} = \int_0^T \mathbf{u}(t)^\top \mathbf{u}(t)\, dt. \]

Here, \( \mathbf{u}(t) \) is the control input (e.g., joint torques). \( J_{\text{ISE}} \) penalizes large errors strongly, while \( J_{\text{ITSE}} \) emphasizes long-lasting errors more. \( J_{\text{ISU}} \) measures energy or effort usage.

In a capstone project, you should specify exactly which of these are used to compare controller variants in later lessons.

6. Norm-Based and Robustness-Oriented Metrics

Robust control (Chapter 7) and optimal control (Chapters 9–10) naturally employ norm-based metrics. For a stable closed-loop system with error signal \( \mathbf{e}(t) \), define the \( L_2 \)-norm

\[ \|\mathbf{e}\|_{L_2} = \left( \int_0^{\infty} \mathbf{e}(t)^\top \mathbf{e}(t)\, dt \right)^{1/2}. \]

If a reference \( \mathbf{r}(t) \) is input to the closed-loop system and \( \mathbf{e} = T_{er}\mathbf{r} \), a natural metric is the induced operator norm

\[ \|T_{er}\|_{2} = \sup_{\mathbf{r} \in L_2, \mathbf{r} \ne 0} \frac{\|\mathbf{e}\|_{L_2}}{\|\mathbf{r}\|_{L_2}}. \]

In the frequency domain, this corresponds to the largest singular value over frequency of the transfer matrix from \( \mathbf{r} \) to \( \mathbf{e} \). While you may not compute this analytically in a capstone project, you can approximate it numerically from simulations or using tools from earlier optimal control lessons.

Another robustness-oriented metric is the maximum sensitivity \( M_s \), defined via the sensitivity transfer function \( S(j\omega) \):

\[ M_s = \sup_{\omega \in \mathbb{R}} \|S(j\omega)\|_{\infty}, \]

which gives a bound on how disturbances and modeling errors are amplified. For capstone purposes, one can select a target upper bound \( M_s^{\star} \) (e.g., between \( 1.2 \) and \( 2.0 \)) and use simulation tools to estimate whether the designed controller respects this bound.

flowchart TD
  MET["Candidate metrics J1, J2, J3"] --> T1["Time-domain (ISE, IAE, settling)"]
  MET --> T2["Control effort (ISU)"]
  MET --> T3["Robustness (Ms, induced norm)"]
  T1 --> SEL["Selected metric set for project"]
  T2 --> SEL
  T3 --> SEL
        

7. Multi-Objective Cost Functions and Trade-Offs

Realistic control design rarely optimizes a single metric. Instead, one combines several objectives, for example tracking precision and control effort. A common continuous-time cost functional is

\[ J(\mathbf{u}) = \int_0^T \Big( \mathbf{e}(t)^\top \mathbf{Q}_e \mathbf{e}(t) + \tilde{\mathbf{u}}(t)^\top \mathbf{R} \tilde{\mathbf{u}}(t) \Big)\, dt, \]

where:

  • \( \tilde{\mathbf{u}}(t) = \mathbf{u}(t) - \mathbf{u}_0(t) \) is the deviation from a nominal input,
  • \( \mathbf{Q}_e \succeq 0 \) and \( \mathbf{R} \succ 0 \) are weighting matrices,
  • \( T \) is the task horizon.

This is the same structure that appears in LQR/iLQR (Chapters 9–10), but here we emphasize its interpretation as a capstone metric.

7.1 Constrained vs weighted formulations

Suppose you care primarily about tracking error but want to limit control effort:

\[ \min_{\mathbf{u}} J_{\text{ISE}}(\mathbf{u}) \quad \text{subject to} \quad J_{\text{ISU}}(\mathbf{u}) \le \bar{E}. \]

Under mild regularity conditions, there exists some \( \lambda^{\star} \ge 0 \) such that the solution also minimizes the weighted sum

\[ \min_{\mathbf{u}} \Big( J_{\text{ISE}}(\mathbf{u}) + \lambda^{\star} J_{\text{ISU}}(\mathbf{u}) \Big). \]

Idea of proof: This is a continuous optimization problem to which Lagrange multiplier theory applies. The Lagrangian

\[ \mathcal{L}(\mathbf{u},\lambda) = J_{\text{ISE}}(\mathbf{u}) + \lambda \big(J_{\text{ISU}}(\mathbf{u}) - \bar{E}\big) \]

is minimized at a saddle point \( (\mathbf{u}^{\star},\lambda^{\star}) \), so that \( \mathbf{u}^{\star} \) is a minimizer of the weighted sum for \( \lambda = \lambda^{\star} \). In a capstone project you usually do not prove such theorems rigorously, but the concept motivates the practice of tuning weights \( \mathbf{Q}_e, \mathbf{R} \) to explore trade-offs.

8. Python Lab — Computing Metrics from Simulation Data

Assume you have simulated a controller in joint space using a robotics library such as roboticstoolbox or a custom simulator. Given time samples t, desired trajectory q_d, actual trajectory q, and torques tau, we can compute the metrics defined above.


import numpy as np

def compute_errors(q, q_d):
    """
    q, q_d: arrays of shape (N, n_joints)
    returns e, e_norm2
    """
    e = q - q_d
    e_norm2 = np.sum(e**2, axis=1)
    return e, e_norm2

def compute_time_domain_metrics(t, e_scalar, eps=0.02, r_step=1.0):
    """
    e_scalar: 1D array of tracking error for a single joint.
    eps: settling band as fraction of step amplitude.
    r_step: step amplitude (for overshoot and steady-state error).
    """
    dt = np.diff(t)
    # overshoot
    Mp = np.max(np.abs(e_scalar)) / abs(r_step) * 100.0

    # steady-state error (last sample)
    e_ss = e_scalar[-1]

    # settling time: first instant after which error remains within eps*|r|
    band = eps * abs(r_step)
    settled_idx = None
    for k in range(len(e_scalar)):
        if np.all(np.abs(e_scalar[k:]) <= band):
            settled_idx = k
            break
    t_s = t[settled_idx] if settled_idx is not None else np.inf

    return {"Mp_percent": Mp, "e_ss": e_ss, "t_s": t_s}

def compute_integral_metrics(t, e_norm2, u):
    """
    e_norm2: ||e(t)||^2 at sampled times.
    u: array of shape (N, n_joints) with control torques.
    """
    # ISE
    J_ISE = np.trapz(e_norm2, t)

    # IAE (using L1 norm)
    e_norm1 = np.sum(np.abs(e_norm2**0.5), axis=0) if e_norm2.ndim > 1 else np.abs(e_norm2)
    J_IAE = np.trapz(e_norm1, t)

    # control effort (ISU)
    u_norm2 = np.sum(u**2, axis=1)
    J_ISU = np.trapz(u_norm2, t)

    return {"J_ISE": J_ISE, "J_IAE": J_IAE, "J_ISU": J_ISU}

# Example usage with simulated data (e.g. from roboticstoolbox)
# t, q_d, q, tau = simulate_controller(...)
# e, e_norm2 = compute_errors(q, q_d)
# metrics_td = compute_time_domain_metrics(t, e[:, 0])  # first joint
# metrics_int = compute_integral_metrics(t, e_norm2, tau)
      

In a capstone repository, you should implement a reusable metrics module like this and call it from multiple controller experiments (PD vs computed-torque vs MPC vs adaptive, etc.).

9. C++, Java, MATLAB/Simulink, Mathematica Metric Implementations

The same metric definitions can be realized in C++ (e.g., with Eigen and ROS), in Java (e.g., with EJML), in MATLAB/Simulink (using the Robotics System Toolbox), and in Wolfram Mathematica for symbolic and numeric analysis.

9.1 C++ (Eigen + ROS-friendly)


#include <vector>
#include <Eigen/Dense>

struct TimeDomainMetrics {
    double Mp_percent;
    double e_ss;
    double t_s;
};

TimeDomainMetrics computeTimeDomainMetrics(
        const std::vector<double>& t,
        const std::vector<double>& e_scalar,
        double eps = 0.02, double r_step = 1.0)
{
    const double band = eps * std::abs(r_step);
    double Mp = 0.0;
    for (double e_val : e_scalar) {
        double abs_e = std::abs(e_val);
        if (abs_e > Mp) Mp = abs_e;
    }
    Mp = Mp / std::abs(r_step) * 100.0;

    double e_ss = e_scalar.back();

    int settled_idx = -1;
    for (size_t k = 0; k < e_scalar.size(); ++k) {
        bool all_within = true;
        for (size_t j = k; j < e_scalar.size(); ++j) {
            if (std::abs(e_scalar[j]) > band) {
                all_within = false;
                break;
            }
        }
        if (all_within) {
            settled_idx = static_cast<int>(k);
            break;
        }
    }
    double t_s = (settled_idx >= 0) ? t[settled_idx] : std::numeric_limits<double>::infinity();

    return {Mp, e_ss, t_s};
}

double trapz(const std::vector<double>& t,
             const std::vector<double>& y)
{
    double acc = 0.0;
    for (size_t k = 1; k < t.size(); ++k) {
        double dt = t[k] - t[k-1];
        acc += 0.5 * dt * (y[k] + y[k-1]);
    }
    return acc;
}

double computeISE(const std::vector<double>& t,
                  const std::vector<Eigen::VectorXd>& e)
{
    std::vector<double> e_norm2(e.size());
    for (size_t k = 0; k < e.size(); ++k) {
        e_norm2[k] = e[k].squaredNorm();
    }
    return trapz(t, e_norm2);
}
      

9.2 Java (EJML-based)


import org.ejml.simple.SimpleMatrix;
import java.util.List;

public class ControlMetrics {

    public static double computeISE(List<Double> t,
                                    List<SimpleMatrix> e) {
        int N = t.size();
        double acc = 0.0;
        for (int k = 1; k < N; ++k) {
            double dt = t.get(k) - t.get(k - 1);
            double e2k   = e.get(k).dot(e.get(k));
            double e2km1 = e.get(k - 1).dot(e.get(k - 1));
            acc += 0.5 * dt * (e2k + e2km1);
        }
        return acc;
    }

    public static double computeISU(List<Double> t,
                                    List<SimpleMatrix> u) {
        int N = t.size();
        double acc = 0.0;
        for (int k = 1; k < N; ++k) {
            double dt = t.get(k) - t.get(k - 1);
            double u2k   = u.get(k).dot(u.get(k));
            double u2km1 = u.get(k - 1).dot(u.get(k - 1));
            acc += 0.5 * dt * (u2k + u2km1);
        }
        return acc;
    }
}
      

9.3 MATLAB/Simulink

In MATLAB, you can post-process simulation data (from Simulink or ode45) as follows:


function metrics = compute_metrics(t, q, qd, tau)
% t: Nx1 time vector
% q, qd, tau: Nxnjoint arrays

e = q - qd;
e2 = sum(e.^2, 2);
u2 = sum(tau.^2, 2);

J_ISE = trapz(t, e2);
J_ISU = trapz(t, u2);

% overshoot and settling time for first joint
e1 = e(:,1);
r_step = 1.0;
Mp = max(abs(e1)) / abs(r_step) * 100;

eps = 0.02;
band = eps * abs(r_step);
settled_idx = find(all(abs(e1(end:-1:1)) <= band), 1, "last");
if isempty(settled_idx)
    t_s = inf;
else
    t_s = t(settled_idx);
end

metrics.J_ISE = J_ISE;
metrics.J_ISU = J_ISU;
metrics.Mp = Mp;
metrics.t_s = t_s;
      

In Simulink, similar metrics can be evaluated using blocks such as MATLAB Function, or by logging signals to the workspace and calling this function after each simulation run.

9.4 Wolfram Mathematica

Mathematica is convenient for symbolic and numeric evaluation of cost functionals:


(* Example: scalar error e(t) = Exp[-a t] *)
Clear[a, t];
e[t_] := Exp[-a t];

JISE[a_?Positive, tFinal_?Positive] :=
  Integrate[e[t]^2, {t, 0, tFinal}]

(* L2 norm over [0, Infinity) provided a > 0 *)
L2Norm[a_?Positive] :=
  Sqrt[Integrate[e[t]^2, {t, 0, Infinity}]]

(* Numerical evaluation for a = 1, tFinal = 10 *)
JISE[1, 10] // N
L2Norm[1] // N
      

In a capstone report, you may use Mathematica to obtain closed-form expressions for metrics in simplified models (e.g., 1-DOF joint) and compare them with numerical simulation.

10. Problems and Solutions

Problem 1 (ISE for an Exponential Error): Consider a scalar tracking error \( e(t) = e^{-\alpha t} \) for \( t \ge 0 \), with \( \alpha > 0 \). Compute the infinite-horizon integral squared error \( J_{\text{ISE}} = \int_0^\infty e(t)^2\, dt \) and the \( L_2 \)-norm of the error signal.

Solution:

We have \( e(t)^2 = e^{-2\alpha t} \), so

\[ J_{\text{ISE}} = \int_0^{\infty} e^{-2\alpha t}\, dt = \left[ -\frac{1}{2\alpha} e^{-2\alpha t} \right]_{t=0}^{\infty} = \frac{1}{2\alpha}. \]

The \( L_2 \)-norm is

\[ \|e\|_{L_2} = \left( \int_0^{\infty} e^{-2\alpha t}\, dt \right)^{1/2} = \left(\frac{1}{2\alpha}\right)^{1/2}. \]

Thus, larger \( \alpha \) (faster decay) reduces both the ISE and the \( L_2 \)-norm, quantitatively capturing the benefit of faster error convergence.

Problem 2 (Trade-Off Between Tracking and Effort): A controller for a single joint produces error \( e(t) \) and torque \( \tau(t) \). Consider the two metrics \( J_1 = J_{\text{ISE}} \) and \( J_2 = J_{\text{ISU}} \). Suppose controller A yields \( (J_1,J_2) = (1,4) \) and controller B yields \( (J_1,J_2) = (1.5,2) \). For which ranges of weight \( \lambda \ge 0 \) does the weighted sum \( J_{\lambda} = J_1 + \lambda J_2 \) prefer A or B?

Solution:

For controller A, \( J_{\lambda}^A = 1 + 4\lambda \). For controller B, \( J_{\lambda}^B = 1.5 + 2\lambda \). We compare:

\[ J_{\lambda}^A \le J_{\lambda}^B \quad \Leftrightarrow \quad 1 + 4\lambda \le 1.5 + 2\lambda \quad \Leftrightarrow \quad 2\lambda \le 0.5 \quad \Leftrightarrow \quad \lambda \le 0.25. \]

Therefore:

  • For \( 0 \le \lambda \le 0.25 \), controller A has smaller weighted cost.
  • For \( \lambda > 0.25 \), controller B is preferred.

This illustrates how the weight \( \lambda \) encodes the subjective preference between tracking and effort in a capstone project.

Problem 3 (Formal Capstone Specification for a 2-DOF Planar Arm): Consider a planar 2-DOF arm tracking an end-effector trajectory \( \mathbf{x}_d(t) \in \mathbb{R}^2 \) over \( t \in [0, T] \). Joint limits are \( q_{i,\min} \le q_i(t) \le q_{i,\max} \) for \( i = 1,2 \), and torque limits \( \|\tau(t)\|_{\infty} \le \tau_{\max} \). Write a complete problem definition including plant, objective, constraints, and a single metric \( J \) of the form in Section 7.

Solution:

  • Plant: 2-DOF manipulator with known dynamics \( \mathbf{M}(\mathbf{q})\ddot{\mathbf{q}} + \mathbf{C}(\mathbf{q},\dot{\mathbf{q}})\dot{\mathbf{q}} + \mathbf{g}(\mathbf{q}) = \tau \). State \( \mathbf{x} = [\mathbf{q}^\top \; \dot{\mathbf{q}}^\top]^\top \), output \( \mathbf{y} = \mathbf{x} \).
  • Objective: make the end-effector position \( \mathbf{x}(t) = \phi(\mathbf{q}(t)) \) track \( \mathbf{x}_d(t) \) so that \( \|\mathbf{x}(t) - \mathbf{x}_d(t)\| \le \varepsilon_{\text{track}} \) for all \( t \in [0,T] \).
  • Constraints: for \( i = 1,2 \), \( q_{i,\min} \le q_i(t) \le q_{i,\max} \), \( \|\dot{\mathbf{q}}(t)\|_{\infty} \le \dot{q}_{\max} \), \( \|\tau(t)\|_{\infty} \le \tau_{\max} \).
  • Metric: let \( \mathbf{e}_x(t) = \mathbf{x}(t) - \mathbf{x}_d(t) \). Choose

\[ J = \int_0^T \big( \mathbf{e}_x(t)^\top \mathbf{Q}_x \mathbf{e}_x(t) + \tau(t)^\top \mathbf{R} \tau(t) \big)\, dt, \]

with \( \mathbf{Q}_x = \operatorname{diag}(q_1,q_2) \succeq 0 \), \( \mathbf{R} = r I_2 \succ 0 \) chosen by the designer.

Problem 4 (Metric Selection Flow): A student proposes to compare controllers using only overshoot \( M_p \). Argue why this is insufficient for a manipulator tracking problem, and sketch a decision flow that leads to a richer set of metrics.

Solution:

Overshoot ignores long-term oscillations (captured by ISE/ITSE), control energy (ISU), and robustness margins. A better flow is:

flowchart TD
  ST["Start: choose metrics"] --> TR["Is transient behavior important?"]
  TR -->|yes| TD["Use Mp, ts, ess"]
  TR -->|no| TD
  TD --> EN["Is actuator effort limited?"]
  EN -->|yes| EF["Add energy metric ISU"]
  EN -->|no| EF
  EF --> RB["Is robustness to disturbances crucial?"]
  RB -->|yes| RO["Add norm-based metric (L2, Ms)"]
  RB -->|no| RO
        

Thus, for a manipulator capstone project one should at least use a combination of time-domain metrics and control-effort metrics, and possibly robustness metrics when disturbances and modeling errors are significant.

11. Summary

In this lesson you learned how to turn a high-level robotic task into a precise control problem specification suitable for a capstone project. We:

  • formalized the robot plant model and state/output definitions,
  • expressed control objectives in joint and task space, including impedance-type objectives,
  • encoded constraints and safety requirements as inequalities and safe sets,
  • defined time-domain and integral metrics (ISE, IAE, ITSE, ISU),
  • introduced norm-based and robustness-oriented metrics, and
  • implemented these metrics in Python, C++, Java, MATLAB, and Mathematica.

In the next capstone lesson you will use this specification to choose a controller architecture (PD, computed-torque, MPC, adaptive, etc.) and connect the abstract design goals to concrete algorithmic choices.

12. References

  1. Bryson, A.E., & Ho, Y.C. (1975). Applied Optimal Control: Optimization, Estimation, and Control. Hemisphere Publishing.
  2. Åström, K.J., & Hägglund, T. (1995). PID Controllers: Theory, Design, and Tuning. Instrument Society of America.
  3. Khalil, H.K. (2002). Nonlinear Systems (3rd ed.). Prentice Hall.
  4. Spong, M.W., Hutchinson, S., & Vidyasagar, M. (2006). Robot Modeling and Control. Wiley.
  5. Slotine, J.J.E., & Li, W. (1991). Applied Nonlinear Control. Prentice Hall.
  6. Boyd, S., & Barratt, C. (1991). Linear Controller Design: Limits of Performance. Prentice Hall.
  7. Skogestad, S., & Postlethwaite, I. (2005). Multivariable Feedback Control: Analysis and Design (2nd ed.). Wiley.
  8. Ortega, R., Loria, A., Nicklasson, P.J., & Sira-Ramirez, H. (1998). Passivity-Based Control of Euler–Lagrange Systems. Springer.
  9. Hespanha, J.P. (2009). Linear Systems Theory. Princeton University Press.
  10. Sontag, E.D. (1989). A “universal” construction of Artstein’s theorem on nonlinear stabilization. Systems & Control Letters, 13(2), 117–123.