Prototyping and subsystem development

Between the critical design review and full integration lies the longest and busiest part of the term: building and testing each subsystem. The goal is not only to make each part work but to make each part work to its interface, so that integration in lesson 7 becomes assembly rather than redesign. This lesson covers prototyping strategy, mechanical, electrical and software development practices that suit a capstone, bench testing of subsystems against their requirements, and the practical business of buying parts: the bill of materials, lead times, currency, shipping, duties and spares.

A prototyping strategy

Prototypes answer questions. A useful habit is to state the question before building: "Will the gripper hold a crushed can when the arm swings at full speed?" or "Does the chassis clear a 5 cm ridge of sand?". Different questions need different fidelity. Low-fidelity prototypes, such as cardboard mock-ups, foam-core mounts or a gripper taped to a broom handle, answer questions about size, reach and basic function in hours. Medium-fidelity prototypes, such as 3D-printed parts and breadboarded electronics, answer questions about performance. High-fidelity prototypes use final materials and manufacturing methods and answer questions about durability and reliability.

Capstone teams often jump straight to high fidelity because it looks impressive, and then discover a basic problem after a week of machining. Iterating cheaply first is faster overall. Team Tern printed six gripper finger designs in two weeks, testing each on a tray of beach sand with real litter collected from the site. The final fingers, with a slight scoop shape and a silicone pad, came from the fourth iteration; the fifth and sixth were attempts at grasping wrappers that the team ultimately parked as a should-have.

Mechanical development

Mechanical work in a capstone usually involves CAD, rapid fabrication and a small amount of machining or outsourcing. Good practice starts with a master assembly model that includes every major component, even as simple envelopes, so that interferences and cable routes are visible. Designing for the fabrication methods actually available saves time: if the lab has a laser cutter and 3D printers, a chassis of laser-cut aluminum or plywood plates joined by printed brackets may be more practical than a welded frame. Tolerances matter for printed parts, which typically need clearance of 0.2 to 0.4 mm for sliding fits, and for bearings and shafts, which need proper fits from datasheets.

Robots that work outdoors need attention to the environment from the start. Tern's chassis keeps electronics in a sealed enclosure with cable glands, uses sealed bearings on the wheels, routes the lidar cable away from the wheels, and mounts the RGB-D camera behind a replaceable clear window that can be wiped of sand. Sand and salt are abrasive and corrosive; stainless fasteners and covered connectors cost little and prevent many field failures. Ingress protection ratings, such as IP54 for dust and splash protection, give a common language for enclosure requirements.

Strength and stiffness checks should be done before parts are made, using the hand calculations from earlier courses or a quick finite element analysis. The arm mount, for example, must resist the moment from the arm at full reach with a payload, plus dynamic loads when the robot drives over bumps. A quick check with a safety factor of at least two on yield is usually sufficient for a capstone prototype, but the assumptions and results should be written down for the CDR package.

Electrical development

Electrical work in robotics capstones causes a disproportionate share of failures and hazards. Every robot should start with a power architecture drawing showing the battery, main fuse, emergency stop, distribution, converters and loads, with wire gauges and fuse ratings chosen for the expected currents. Lithium batteries require particular care: use a battery management system, charge with the correct charger in a designated area, store and transport them according to your institution's rules, and never leave them charging unattended. ROB-200 lesson 2 covered battery chemistry and protection; the capstone is where those rules are tested in practice.

The emergency stop deserves special attention. It must remove power from the actuators directly, through a contactor or a safety relay, rather than by sending a message to software. It should be a latching red mushroom-head button on a yellow background, reachable from outside the robot, and resetting it must not by itself restart motion. Tern has one emergency stop on the robot and a wireless emergency stop carried by the operator; the wireless unit uses a heartbeat, so loss of signal also stops the robot. ROB-450 lesson 3 explained how to think about the reliability of such safety functions.

Wiring quality is a major source of intermittent faults, which are among the hardest problems to diagnose. Use crimped connectors with the correct tool, strain relief, labeled wires, consistent color coding and a wiring diagram kept up to date. Breadboards are fine for early tests but should not ride on a moving robot. Many teams move to a simple custom printed circuit board or a perfboard with screw terminals once the circuit is stable; small PCB orders are inexpensive, but allow for one to three weeks of fabrication and shipping, which makes them a long-lead item.

Software development

Software can and should progress before the hardware exists. ROB-360 lessons 5 and 6 covered simulation; in a capstone, a simulated version of the robot lets the navigation and perception leads develop and test their code from week 3. Team Tern built a simulated beach world with a sloping sand plane, a boardwalk, picnic tables and randomly placed litter models, and a simplified robot model with the same sensors and topics as the real robot. When the real chassis arrived in week 7, the navigation stack ran on it after two days of tuning rather than two weeks of debugging.

Each software component should have unit tests for its core logic and a simple integration test that launches it with recorded data. Recorded datasets, captured with ros2 bag during early field visits, are invaluable: Chloé recorded camera data on the beach in week 3 with a handheld rig and used it to train and evaluate the litter detector long before the robot could drive there. Keeping a held-out test set, recorded on a different day, gives an honest estimate of detector performance and prevents the overfitting that makes a detector look excellent in the lab and fail in the field.

Firmware on the microcontroller should be kept small and deterministic: read encoders, run wheel velocity loops, enforce speed limits, monitor the safety inputs and heartbeat, and communicate with the main computer. ROB-320 covered real-time design. A useful safety rule is that the microcontroller stops the motors if it does not receive a valid velocity command within a timeout, such as 200 ms, so that a crashed ROS 2 node or a disconnected cable cannot leave the robot driving.

Bench testing subsystems

Before integration, each subsystem should be tested against its own requirements and its interfaces, on the bench. A bench test plan lists the tests, the setup, the pass criteria and the requirement each test verifies. Results are recorded with the configuration used. Testing to the interface is crucial: the drive subsystem should be tested by sending velocity commands over the serial protocol exactly as defined in the ICD, at the defined rate, and checking that odometry comes back at the defined rate and in the defined units. If each side passes its interface test, integration is far less likely to fail.

The bill of materials and purchasing

The bill of materials (BOM) lists every part with its quantity, supplier, part number, unit cost, lead time and status. It doubles as the cost budget and the purchasing tracker. Long-lead items, identified in lesson 5, are ordered first. Prices should include shipping, duties, taxes and currency conversion, which for international orders can add a third or more to the listed price. Teams should also budget for spares of parts likely to break or be lost, such as fuses, servo horns, gripper fingers and one spare motor driver, and for consumables such as filament, connectors and heat shrink.

# Landed cost of Tern's bill of materials (illustrative prices and rates)
items = [  # name, qty, unit price, currency, origin, lead time (weeks)
    ("gearmotor with encoder", 4, 62.00, "USD", "overseas", 3),
    ("motor driver",           2, 45.00, "USD", "domestic", 1),
    ("arm kit with servos",    1, 690.0, "USD", "overseas", 4),
    ("RGB-D camera",           1, 420.0, "USD", "domestic", 1),
    ("safety lidar scanner",   1, 1450., "USD", "domestic", 2),
    ("RTK GNSS kit",           1, 380.0, "USD", "overseas", 2),
    ("embedded GPU computer",  1, 610.0, "USD", "domestic", 1),
    ("LiFePO4 battery + BMS",  1, 310.0, "USD", "overseas", 3),
    ("chassis stock, hardware",1, 260.0, "USD", "domestic", 1),
]
fx = 1.37               # local currency per USD (illustrative; use 1.0 if you pay in US dollars)
ship = {"overseas": 0.08, "domestic": 0.03}   # shipping as a share of price
duty = {"overseas": 0.10, "domestic": 0.0}    # illustrative duty on overseas items
tax = 0.13              # illustrative sales tax applied to price + shipping + duty
total = 0.0; longest = 0
for name, q, p, cur, origin, lt in items:
    base = q * p * fx
    landed = base * (1 + ship[origin]) * (1 + duty[origin]) * (1 + tax)
    total += landed; longest = max(longest, lt)
    print(f"{name:24s} {base:8.0f} -> {landed:8.0f}")
spares = 0.08 * total; contingency = 0.10 * (total + spares)
print(f"landed parts {total:,.0f}; spares {spares:,.0f}; contingency {contingency:,.0f}; "
      f"budget needed {total + spares + contingency:,.0f}; longest lead time {longest} weeks")

gearmotor with encoder        340 ->      456
motor driver                  123 ->      144
arm kit with servos           945 ->     1269
RGB-D camera                  575 ->      670
safety lidar scanner         1987 ->     2312
RTK GNSS kit                  521 ->      699
embedded GPU computer         836 ->      973
LiFePO4 battery + BMS         425 ->      570
chassis stock, hardware       356 ->      415
landed parts 7,507; spares 601; contingency 811; budget needed 8,918; longest lead time 4 weeks

The landed cost is substantially higher than the listed prices, and with spares and contingency the budget needed is higher still. If the program provides a fixed budget, this calculation decides which parts can be bought new, which can be borrowed from the lab, and which must be descoped. Team Tern borrowed the safety lidar from the department's robotics lab, the single largest item, which brought the project within its budget. Purchasing usually goes through the department, which may have preferred suppliers, tax exemptions or rules about who can approve orders, so ask early how long approvals take.

Importing parts into the United States can trigger duties under the Harmonized Tariff Schedule, plus additional tariffs imposed under trade measures on goods from particular countries, collected by US Customs and Border Protection. The duty-free de minimis treatment for shipments up to USD 800 was suspended for all countries from 29 August 2025 and remained suspended in 2026, so even small orders from overseas suppliers may incur duties and broker fees. Trade measures changed repeatedly in 2025 and 2026, so check current rules and ask your department's purchasing office before ordering.

Lab safety during development

Building robots involves hazards: power tools, soldering fumes, lithium batteries, moving mechanisms, lasers and sometimes chemicals such as epoxies and solvents. Capstone teams must complete their institution's lab safety training, follow equipment-specific rules, and keep a simple hazard log for their own robot. When testing moving robots, keep a clear test area, assign a person to the emergency stop, and limit speed and force until the safety functions are verified. Lesson 9 covers the formal hazard analysis; the practical rule during development is that no one tests alone and no one tests a moving robot without an emergency stop in hand.

Chemical products used in the lab, such as adhesives, solvents and cleaners, fall under OSHA's Hazard Communication Standard, so teams should read the safety data sheets and labels before use and follow their institution's hazard communication training.