Topic 3 — Implementation Roadmap & Milestones
With a clear brief and system architecture, the next challenge is time. This topic helps you break your capstone into realistic phases, choose high-leverage tasks first, and continuously de‑risk integration so you are not debugging everything in the final week.
3.1 Phasing Your Project
A practical capstone roadmap often follows four phases:
- Skeleton Phase (Week 1):
- Set up repository, ROS 2 packages, and simulation world.
- Implement “hello world” versions of each major subsystem (perception stub, planner stub, controller stub).
- Verify launch files start the full stack without crashing.
- Feature Phase (Weeks 2–3):
- Implement core features for perception, navigation, planning, and interaction.
- Focus on the happy path for your primary demo scenario.
- Robustness Phase (Week 3–4):
- Add failure handling, retries, and basic monitoring/logging.
- Address obvious bugs from early testing; stabilize core behavior.
- Polish & Demo Phase (Final Week):
- Improve demo script, visuals, and documentation.
- Avoid introducing large new features; focus on reliability and clarity.
Adapt these phases to your schedule, but keep the “skeleton first, polish last” principle.
3.2 Milestones & Checkpoints
Define concrete milestones with dates and testable outcomes:
- Milestone 1 — Stack Boots Successfully:
- All key nodes launch and communicate in simulation.
- Robot can move using basic teleoperation or scripted commands.
- Milestone 2 — End-to-End Happy Path:
- Given a simple command, the system completes a basic mission in simulation.
- Perception → planning → control all participate.
- Milestone 3 — Robustness & Recovery:
- Basic failure modes (blocked paths, missing detections) trigger safe fallbacks.
- Logs and metrics can be inspected to understand behavior.
- Milestone 4 — Final Demo & Report Ready:
- Demo script executed multiple times successfully.
- Documentation and slides (or report) drafted and reviewed.
Each milestone should be small enough to verify objectively (success/failure) rather than “feel” complete.
3.3 Task Breakdown & Ownership
Break milestones into tasks that can be assigned and tracked:
- Group tasks by subsystem:
- Perception, localization/mapping, planning, control, UX/logging, infrastructure.
- For each task, define:
- Owner (person or pair).
- Estimated effort (e.g., 2–4 hours, 1 day).
- Dependencies on other tasks.
Use a lightweight tool (GitHub issues, Kanban board, checklist in your repo) to track progress and avoid “hidden work.”
3.4 Risk Management
Identify high-risk elements early (new libraries, complex behaviors, multi-agent coordination, LLM integration) and front-load:
- Prototype risky components in small, isolated scripts or mini-labs.
- If a risk proves too large, adjust scope before it sinks the whole project:
- Simplify the environment.
- Reduce the number of robots.
- Remove non-essential integrations.
Make conscious trade-offs and record them in your project notes.
3.5 Mini-Lab: Build Your Roadmap
Goal: Produce a realistic, time-bound implementation plan.
Tasks
- Translate your architecture into 3–5 milestones and 15–30 concrete tasks.
- Assign owners and dates for each task (even if working solo).
- Identify at least three major risks and write a mitigation plan for each.
- Commit your roadmap as a markdown file in your repository.
Deliverables
- Roadmap document with phases, milestones, and tasks.
- Short risk assessment with mitigation strategies.
Summary
A thoughtful roadmap keeps your capstone on track and de-risked, turning an ambitious goal into a sequence of achievable steps. In the next topic, you will focus on testing, evaluation, and demo preparation to ensure your final presentation matches the quality of the underlying engineering.