A robotics capstone project is not just “build something cool”; it is a controlled engineering experiment on a physical system. Good scoping answers at least four questions:

1. What will the robot do (task definition)?
2. How well must it do it (quantitative performance requirements)?
3. With what resources (hardware, time, team size, budget)?
4. Under which assumptions (environmental and model assumptions)?

Mathematically, we will view a project as a tuple \( (\mathcal{T}, \mathcal{R}, \mathcal{C}, \mathcal{A}) \), where:

\[ \mathcal{T} \; \text{(task)}, \quad \mathcal{R} \; \text{(requirements)}, \quad \mathcal{C} \; \text{(constraints)}, \quad \mathcal{A} \; \text{(assumptions)}. \]

A well-scoped project is one where each element is explicit, internally consistent, and feasible for the available resources and prior knowledge (here: linear control and basic robotics concepts).

flowchart TD
  I["Initial idea (e.g. line-following robot)"] --> T["Formalize task: inputs, outputs, environment"]
  T --> R["Define measurable requirements (tracking error bounds, response times)"]
  R --> C["Identify constraints (budget, hardware, time, skills)"]
  C --> F["Feasibility check (control and resource)"]
  F -->|feasible| P["Write structured proposal"]
  F -->|not feasible| R2["Refine or down-scope idea"]
        

Let \( \mathbf{p} \in \mathbb{R}^n \) denote your vector of design parameters (e.g., controller gains, sensor choices, and mechanical options encoded numerically). A robotics project typically specifies a set of requirements \( \mathbf{r} \in \mathbb{R}^m \) such as maximum tracking error, maximum overshoot, and total mass.

\[ \mathbf{r} = \begin{bmatrix} r_1 \\ r_2 \\ \vdots \\ r_m \end{bmatrix}, \quad \mathbf{s}(\mathbf{p}) = \begin{bmatrix} s_1(\mathbf{p}) \\ s_2(\mathbf{p}) \\ \vdots \\ s_m(\mathbf{p}) \end{bmatrix}, \]

where \( s_i(\mathbf{p}) \) is the achieved performance quantity under design \( \mathbf{p} \). Typical requirement types are:

• Hard inequality constraints: \( s_i(\mathbf{p}) \leq r_i \) (e.g., maximum RMS tracking error).
• Equality constraints: \( s_i(\mathbf{p}) = r_i \) (e.g., fixed sampling time enforced by hardware).
• Soft preferences encoded via a cost functional.

We can define a constraint function \( g_i:\mathbb{R}^n \rightarrow \mathbb{R} \) by

\[ g_i(\mathbf{p}) = s_i(\mathbf{p}) - r_i, \quad g_i(\mathbf{p}) \leq 0 \; \text{for all hard constraints.} \]

The feasible set of project designs is then

\[ \mathcal{F} = \left\{ \mathbf{p} \in \mathbb{R}^n \; \middle| \; g_i(\mathbf{p}) \leq 0,\; i=1,\dots,m \right\}. \]

A minimal requirement for a reasonable capstone proposal is that \( \mathcal{F} \neq \varnothing \) is at least plausible given your skill level and time. While you will not fully solve the design optimization in the proposal, you should argue why nonempty feasibility is realistic.

Since you already know linear control, it is natural to express several requirements as closed-loop performance constraints. Consider a single-input single-output (SISO) plant modeled in state space:

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

with a state-feedback controller \( u(t) = -K\mathbf{x}(t) \). The closed-loop dynamics are

\[ \dot{\mathbf{x}}(t) = (A - BK)\mathbf{x}(t). \]

A typical requirement might be: “for a step reference in position, the output \( y(t) \) must track with < 5% overshoot and settling time < 2 s”. For a dominant second-order mode with damping ratio \( \zeta \) and natural frequency \( \omega_n \), standard approximations give

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

where \( M_p \) is the step overshoot and \( T_s \) the settling time. Requirements like \( M_p \leq M_p^{\max} \) and \( T_s \leq T_s^{\max} \) become inequalities linking your controller gains (through the eigenvalues of \( A - BK \)) to measurable behavior.

In your proposal, you should:

• state such bounds explicitly (e.g., “settling time ≤ 2 s”),
• indicate how you will estimate or verify them (simulation and experiments),
• connect them to parameters you will tune (e.g., \( K \)).

For tracking tasks, another common performance metric is the infinity norm of the tracking error \( e(t) = r(t) - y(t) \):

\[ \lVert e \rVert_{\infty} = \sup_{t \geq 0} \left| e(t) \right| \leq e_{\max}, \]

which expresses the maximum allowable deviation from the reference signal.

A project can be technically elegant yet infeasible within a semester. To formalize scope, represent your task list as \( \{T_1,\dots,T_N\} \), each with estimated effort \( h_j \) in hours. Let \( H_{\max} \) be the total available hours (team size times weekly hours times number of weeks).

\[ \sum_{j=1}^{N} h_j \leq H_{\max} \]

is a necessary feasibility condition. You can model uncertainty in these estimates by upper and lower bounds:

\[ h_j^{\min} \leq h_j \leq h_j^{\max}, \quad \sum_{j=1}^{N} h_j^{\max} \leq \gamma H_{\max}, \]

where \( \gamma \in (0,1) \) is a safety factor (e.g., 0.7) accounting for unforeseen difficulties. In a proposal, you should document:

• a table of tasks with optimistic and pessimistic durations,
• a clear indication of which tasks will be dropped or simplified if the schedule tightens,
• how responsibilities are divided among team members.

A good proposal is structured so that another robotics engineer could implement or review it. A typical outline for this course is:

1. Title and abstract (one-paragraph summary).
2. Problem statement: concise description of the robot, environment, and task \( \mathcal{T} \).
3. System description: high-level block diagram of mechanical, sensing, and control subsystems.
4. Mathematical model: simplified linear or piecewise-linear model sufficient to state control goals (even if approximate).
5. Requirements and metrics: the vector \( \mathbf{r} \) and the corresponding measurable \( \mathbf{s}(\mathbf{p}) \).
6. Approach: control strategy, sensing strategy, and software architecture at a high level.
7. Resources and schedule: task list, workload model, and milestones.
8. Risk analysis: key technical risks and mitigation strategies.

The next lessons in this chapter will go deeper into design reviews, milestones, and validation; in this first lesson, your goal is to understand how to make this outline mathematically meaningful and realistic.

flowchart TD
  S["Start proposal"] --> PS["Problem statement and task T"]
  PS --> MD["Simplified model (linear where possible)"]
  MD --> REQ["Define requirement vector r and metrics s(p)"]
  REQ --> AP["Choose control and sensing approach"]
  AP --> RES["Estimate resources and schedule"]
  RES --> RISK["Identify major risks and mitigations"]
  RISK --> REV["Internal review and refinement"]
  REV --> SUB["Submit written proposal"]
        

Often you must trade off several objectives: performance, robustness, and development effort. A simple way to capture this is via a scalar score or cost functional \( J(\mathbf{p}) \):

\[ J(\mathbf{p}) = \sum_{i=1}^{m} w_i \, \phi_i\big( s_i(\mathbf{p}), r_i \big), \quad w_i \geq 0, \]

where \( \phi_i \) penalizes deviation from requirement \( r_i \) (for example: \( \phi_i(a,b) = \max\{0, a-b\}^2 \) for a quadratic penalty on violation) and \( w_i \) are trade-off weights.

In a proposal, you are not expected to solve \( \min_{\mathbf{p}} J(\mathbf{p}) \) exactly, but you should:

• describe which objectives are most important (e.g., safety vs. tracking performance),
• mention what you would try to optimize in your controller tuning or design iterations,
• show that there is no obvious conflict that makes the project impossible (e.g., extremely high bandwidth with extremely low power).

As part of your project tooling, you can write small scripts that check whether a candidate design meets your current requirements. Below is a minimal Python example that stores requirements and evaluates a feasibility flag for simulated performance metrics.

from dataclasses import dataclass
from typing import Dict

@dataclass
class PerformanceRequirements:
    max_settling_time_s: float
    max_overshoot: float
    max_rms_error: float

@dataclass
class PerformanceMetrics:
    settling_time_s: float
    overshoot: float
    rms_error: float

def check_feasibility(req: PerformanceRequirements,
                      met: PerformanceMetrics) -> Dict[str, bool]:
    """
    Return a dictionary telling which constraints are satisfied.
    """
    return {
        "settling_time_ok": met.settling_time_s <= req.max_settling_time_s,
        "overshoot_ok": met.overshoot <= req.max_overshoot,
        "rms_error_ok": met.rms_error <= req.max_rms_error,
    }

if __name__ == "__main__":
    # Example numbers from a simple simulation of a line-following robot
    requirements = PerformanceRequirements(
        max_settling_time_s=2.0,
        max_overshoot=0.05,
        max_rms_error=0.02
    )

    metrics = PerformanceMetrics(
        settling_time_s=1.8,
        overshoot=0.04,
        rms_error=0.018
    )

    feasibility = check_feasibility(requirements, metrics)
    print("Feasibility report:")
    for key, ok in feasibility.items():
        print(f"  {key}: {'OK' if ok else 'VIOLATED'}")
      

In a robotics capstone, you can extend this script to load metrics from simulation logs or experimental data and automatically flag whether a design revision satisfies the current specification.

If your team uses C++ or Java for embedded or higher-level software, you can mirror the same idea in those languages. Below is a simple C++ header-only style snippet for feasibility checking:

#include <iostream>

struct PerformanceRequirements {
    double maxSettlingTime_s;
    double maxOvershoot;
    double maxRmsError;
};

struct PerformanceMetrics {
    double settlingTime_s;
    double overshoot;
    double rmsError;
};

struct FeasibilityReport {
    bool settlingTimeOk;
    bool overshootOk;
    bool rmsErrorOk;
};

FeasibilityReport checkFeasibility(const PerformanceRequirements& req,
                                   const PerformanceMetrics& met) {
    FeasibilityReport rep;
    rep.settlingTimeOk = (met.settlingTime_s <= req.maxSettlingTime_s);
    rep.overshootOk    = (met.overshoot      <= req.maxOvershoot);
    rep.rmsErrorOk     = (met.rmsError       <= req.maxRmsError);
    return rep;
}

int main() {
    PerformanceRequirements req {2.0, 0.05, 0.02};
    PerformanceMetrics met {1.9, 0.06, 0.018};

    FeasibilityReport rep = checkFeasibility(req, met);
    std::cout << "settlingTimeOk = " << rep.settlingTimeOk << "\n";
    std::cout << "overshootOk    = " << rep.overshootOk    << "\n";
    std::cout << "rmsErrorOk     = " << rep.rmsErrorOk     << "\n";
    return 0;
}
      

And a corresponding Java class structure for an application-level feasibility check:

public final class PerformanceRequirements {
    public final double maxSettlingTime_s;
    public final double maxOvershoot;
    public final double maxRmsError;

    public PerformanceRequirements(double maxSettlingTime_s,
                                   double maxOvershoot,
                                   double maxRmsError) {
        this.maxSettlingTime_s = maxSettlingTime_s;
        this.maxOvershoot = maxOvershoot;
        this.maxRmsError = maxRmsError;
    }
}

public final class PerformanceMetrics {
    public final double settlingTime_s;
    public final double overshoot;
    public final double rmsError;

    public PerformanceMetrics(double settlingTime_s,
                              double overshoot,
                              double rmsError) {
        this.settlingTime_s = settlingTime_s;
        this.overshoot = overshoot;
        this.rmsError = rmsError;
    }
}

public final class FeasibilityReport {
    public final boolean settlingTimeOk;
    public final boolean overshootOk;
    public final boolean rmsErrorOk;

    public FeasibilityReport(boolean settlingTimeOk,
                             boolean overshootOk,
                             boolean rmsErrorOk) {
        this.settlingTimeOk = settlingTimeOk;
        this.overshootOk = overshootOk;
        this.rmsErrorOk = rmsErrorOk;
    }
}

public final class RequirementChecker {
    public static FeasibilityReport check(PerformanceRequirements req,
                                          PerformanceMetrics met) {
        boolean settlingOk = met.settlingTime_s <= req.maxSettlingTime_s;
        boolean overshootOk = met.overshoot <= req.maxOvershoot;
        boolean rmsOk = met.rmsError <= req.maxRmsError;
        return new FeasibilityReport(settlingOk, overshootOk, rmsOk);
    }

    public static void main(String[] args) {
        PerformanceRequirements req = new PerformanceRequirements(2.0, 0.05, 0.02);
        PerformanceMetrics met = new PerformanceMetrics(1.7, 0.04, 0.025);

        FeasibilityReport rep = check(req, met);
        System.out.println("settlingTimeOk = " + rep.settlingTimeOk);
        System.out.println("overshootOk    = " + rep.overshootOk);
        System.out.println("rmsErrorOk     = " + rep.rmsErrorOk);
    }
}
      

These snippets are intentionally simple and language-agnostic. The important concept is that your proposal and your code agree on the exact numerical meaning of “meeting the specification”.

Many teams will prototype control behavior in MATLAB and Simulink. You can store requirements in a structure and write a small script that evaluates them from simulation results:

% Define requirements
req.maxSettlingTime_s = 2.0;
req.maxOvershoot      = 0.05;
req.maxRmsError       = 0.02;

% Assume you have already simulated your closed-loop system and have:
% t : time vector
% y : output vector
% r : reference vector (same size as y)

e = r - y;
rmsError = sqrt(trapz(t, e.^2) / (t(end) - t(1)));

% Simple settling time and overshoot estimation for a step response
y_final = y(end);
overshoot = (max(y) - y_final) / max(1e-9, abs(y_final));

% Settling time: first time after which |y - y_final| <= 0.02*|y_final|
idx = find(abs(y - y_final) <= 0.02 * abs(y_final), 1, 'first');
if ~isempty(idx)
    settlingTime = t(idx);
else
    settlingTime = Inf;
end

metrics.settlingTime_s = settlingTime;
metrics.overshoot      = overshoot;
metrics.rmsError       = rmsError;

feasibility.settlingTimeOk = metrics.settlingTime_s <= req.maxSettlingTime_s;
feasibility.overshootOk    = metrics.overshoot      <= req.maxOvershoot;
feasibility.rmsErrorOk     = metrics.rmsError       <= req.maxRmsError;

disp(feasibility);
      

In Simulink, your block diagram should be consistent with the linear models and specifications stated in the proposal. For this lesson it is enough to understand that requirements can be turned into explicit inequalities evaluated from simulation or experimental data.

In this lesson you learned how to translate an informal robotics idea into a structured project scope and proposal. We introduced requirement vectors and feasible sets, expressed performance in terms of closed-loop control metrics such as overshoot, settling time, and tracking-error norms, and modeled resources as simple inequality constraints on team workload. You also saw how small scripts in Python, C++, Java, and MATLAB/Simulink can encode and automatically check your specifications. These concepts form the foundation for the remaining capstone lessons, where you will design, implement, and validate your chosen mini-project.