The robotics capstone: purpose, teams and assessment

The capstone is where a robotics degree stops being a set of separate courses and becomes one piece of engineering. Over a single term, a small team takes a real problem, turns it into requirements, designs and builds a robot or robotic subsystem, tests it against those requirements, and shows it working in front of people who did not build it. Every earlier course feeds in: kinematics from ROB-210, sensing from ROB-220, control from ROB-300, estimation from ROB-310, real-time software from ROB-320, perception from ROB-330, mapping from ROB-340, planning from ROB-350 and the software pipeline from ROB-360. This course does not re-teach those topics. It shows how to combine them under time, budget and team constraints, and how to make the evidence of your work visible to examiners, partners and future employers.

The lessons follow the life of a capstone project in order. This first lesson sets out what a capstone is for, how teams are formed and run, and how the work is assessed. Lessons 2 to 4 cover the front end of engineering: defining the problem, writing requirements, generating concepts, running trade studies and holding design reviews. Lessons 5 to 8 cover execution: project management, prototyping, integration, and verification and validation. Lessons 9 to 12 cover safety and ethics review, demonstration and documentation, intellectual property and entrepreneurship, and finally reflection and career launch.

A running example: Team Tern

To keep the ideas concrete, the course follows one invented team through the term. Team Tern has five members: Ana leads mechanical design, Ben leads electrical and power, Chloé leads perception, Dev leads navigation and software integration, and Ema leads planning, testing and documentation. Their partner is Port Willow Parks, an invented municipal parks department that spends many staff hours picking up small litter, such as bottle caps, cans and food wrappers, from a sandy beach and its boardwalk. The parks department wants to know whether a small robot could patrol the upper beach at quiet times, detect litter, pick up common items and report what it found. The team's robot, also called Tern, is a four-wheeled mobile base with a low-cost arm, a depth camera, a lidar and an onboard computer running ROS 2.

Tern is deliberately ambitious enough to touch most of the degree: outdoor localization on sand from ROB-460, object detection from ROB-330, grasping from ROB-400, navigation from ROB-340 and ROB-350, interaction with members of the public from ROB-430, and a safety case from ROB-450. It is also deliberately constrained. The team has 13 weeks, a hardware budget, a shared lab and the usual demands of other courses. Many of the decisions you will see Team Tern make, such as cutting scope, choosing a simpler gripper or adding a test week, are the decisions every capstone team faces.

What a capstone is for

A capstone has three purposes that sometimes pull in different directions. The first is integration: proving that you can combine knowledge from many courses into a system that works. Many students discover that each subsystem works on its own bench but the robot does not work as a whole, because timing, power, mechanical tolerances and software interfaces interact. The second purpose is professional practice: working as engineers do, with requirements, reviews, schedules, budgets, risk management, safety analysis and documentation. The third purpose is evidence: producing artifacts, such as a design report, test data, a demonstration video and a code repository, that show what you can do.

Because of these purposes, a capstone is assessed differently from a problem set. Examiners care less about whether the robot achieves every stretch goal and more about whether the team made sound engineering decisions, tested honestly and can explain what happened. A robot that meets a modest set of requirements with strong evidence usually scores better than an impressive-looking robot whose performance is anecdotal. A team that discovers a fundamental problem in week 8, documents it, re-scopes sensibly and shows a working reduced system demonstrates more engineering maturity than a team that hides the problem.

In the United States, accredited engineering programs must include a culminating major engineering design experience under ABET's Engineering Accreditation Commission criteria, and student outcomes such as solving complex problems, applying design under constraints, communicating, recognizing ethical and professional responsibilities, working on teams and experimenting are commonly assessed through capstone work. The rubrics you see are often mapped directly to those outcomes.

Types of capstone projects

Capstone projects come from several sources, and the source shapes the work. Industry-sponsored projects come with a real client, real constraints and often a non-disclosure agreement; they are excellent preparation for professional practice but may limit what you can publish or keep. Community or public-sector projects, like Team Tern's work with a parks department, bring stakeholders who are not engineers and who care about cost, maintenance and public acceptance. Research-linked projects extend a professor's research; they can be technically deep but may have vague success criteria. Competition projects, such as a rover or autonomous vehicle competition, come with a fixed rule book and a hard deadline; lesson 11 covers them. Student-proposed projects give the most freedom but require the team to find its own stakeholders and to justify its requirements carefully.

Forming and running a team

Most robotics capstone teams have four to six members. Smaller teams struggle to cover mechanical, electrical, software and testing work; larger teams spend more time coordinating. Good teams balance skills but avoid rigid silos: each member should lead one area and support at least one other, so that the project does not stall when one person is sick or busy. Team Tern pairs Ana with Ben on the drivetrain and power, Chloé with Dev on perception and navigation, and Ema with everyone on testing.

In the first week, teams should write a team charter. PMP-120 lesson 4 covers charters in detail; for a capstone, a charter usually records the team's goals, each member's lead role and backup role, meeting times, how decisions are made, how work is tracked, how conflict is handled, what happens if someone misses commitments, and how the team will use the shared lab and equipment. The charter is not paperwork for its own sake. When a disagreement arises in week 9 about whether to rebuild the arm, the team can return to the decision rule it agreed on in week 1, for example, that technical decisions with schedule impact over one week are made by consensus after a short trade study, with the instructor consulted if consensus fails.

Effective teams meet regularly with a purpose. A short weekly planning meeting reviews progress against the schedule, updates risks and assigns tasks; two or three brief stand-ups during the week surface blockers. Meetings with the partner and the faculty advisor are scheduled well in advance with agendas sent beforehand. Every meeting ends with recorded decisions and actions with owners and dates. Lesson 5 covers the tools teams use for this.

How capstones are assessed

Assessment schemes vary between institutions, but most combine team deliverables, individual contributions and a final demonstration. Typical deliverables include a project proposal, a requirements document, design review presentations, a mid-term progress report, a final technical report, a demonstration, a poster or showcase presentation and a reflection. Weights are usually published in a rubric at the start of term; read it closely, because it tells you what evidence the examiners will look for. If the rubric gives 15 percent for verification and testing, then a test report with data, not just a demonstration, is expected.

Rubrics usually describe levels of performance, for example unsatisfactory, developing, proficient and exemplary, for each criterion. A proficient requirements document lists measurable requirements with verification methods; an exemplary one also traces each requirement to a stakeholder need and shows how requirements changed through the term with reasons. Reading the exemplary column before you start is one of the most effective things a team can do.

Individual marks and peer evaluation

Team projects raise a fairness problem: should every member get the same mark? Many programs adjust individual marks using peer evaluation. Each member rates every other member, and often themselves, on criteria such as contribution, reliability, quality of work and teamwork. The ratings are converted into a weighting factor that scales the team mark. One common method, often called WebPA after the tool that popularized it, normalizes each rater's scores so that every rater distributes the same total, which removes the effect of generous or harsh raters, and then sums the normalized scores each person receives.

# Peer evaluation: normalize each rater's scores, then compute weighting factors (WebPA-style)
import numpy as np
names = ["Ana", "Ben", "Chloe", "Dev", "Ema"]
# rows = rater, columns = ratee; scores 1-5 on overall contribution (illustrative)
R = np.array([
    [4, 4, 5, 4, 5],   # Ana rates everyone (including self)
    [5, 3, 5, 4, 5],   # Ben
    [5, 4, 5, 5, 5],   # Chloe (a generous rater)
    [3, 2, 4, 3, 4],   # Dev (a harsh rater)
    [4, 3, 4, 4, 4],   # Ema
], dtype=float)
norm = R / R.sum(axis=1, keepdims=True)        # each rater distributes a total of 1
received = norm.sum(axis=0)                    # total normalized score each person receives
factor = received * len(names) / received.sum()  # 1.0 = average contribution
team_mark = 82.0
for n, f in zip(names, factor):
    print(f"{n:6s} factor {f:4.2f}  individual mark {min(100, team_mark * f):5.1f}")
print("raw means:", np.round(R.mean(axis=0), 2))

Ana    factor 1.02  individual mark  83.3
Ben    factor 0.77  individual mark  63.0
Chloe  factor 1.12  individual mark  92.1
Dev    factor 0.97  individual mark  79.5
Ema    factor 1.12  individual mark  92.1
raw means: [4.2 3.2 4.6 4.  4.6]

The normalized factors are close to 1 for most members, which is typical of a functioning team; Ben's factor is noticeably below 1 because most raters, including Ben himself, scored him lowest. Chloé's generous ratings and Dev's harsh ratings no longer distort the result, because each rater's scores are scaled to the same total. Institutions often cap the adjustment, for example to between 0.8 and 1.1 of the team mark, and require instructors to review large deviations, because peer ratings can reflect personality clashes as well as contribution.

Peer evaluation works best as a feedback tool during the term, not only as a grading tool at the end. Many programs run a formative round in week 5 or 6, share anonymized feedback with each member, and give the team time to fix problems before the summative round. The other source of evidence about individual contribution is the project record itself: commit histories, task-tracker assignments, meeting minutes, lab notebooks and design review slides. A member who is quiet in meetings but authored most of the motor-control code will show up clearly in the repository. Keep your own contribution log from week 1; it makes the reflection in lesson 12 far easier and protects you if a dispute arises.

Expectations of professional behavior

Capstone teams work in shared labs, with expensive equipment and with outside partners, so professional conduct matters. Teams are expected to follow lab safety rules, book equipment fairly, keep partners informed, respect confidentiality, credit the sources of code and designs they reuse, and use generative AI tools within the rules set by their program. Many programs now allow AI coding assistants and writing tools but require disclosure of how they were used and hold students responsible for every line they submit. If you use an AI tool to draft a ROS 2 node, you must understand, test and be able to explain that node at the design review.

Engineering codes of ethics in the United States, such as the NSPE Code of Ethics and the codes of state licensing boards, require engineers to hold paramount the safety, health and welfare of the public, to perform services only in areas of competence and to act honestly. Although students are not yet licensed, capstone courses commonly assess professionalism against these codes, and lesson 12 explains how the capstone connects to licensure.