P00 - Edge Computing Group Project

This is a group-based, semester-long project focused on the design, implementation, and evaluation of an edge computing system.

This course is organized around a single end-to-end edge system that you build as part of a project team, iteratively. Most weeks contribute directly to the project, and each class meeting reserves group work time for it. The intent is to make design decisions measurable and defensible.

This course treats edge computing as a systems engineering problem shaped by constraints. You are expected to design and build an end-to-end system that runs on real hardware and interacts with real data. Success is defined by what you can demonstrate, measure, and explain with evidence.

Timeline at a Glance

The course meets Mondays, 3:00–5:30 PM. Milestones 0, 1, and 2 fall on regular class meeting dates. The Final Project session is neither a Monday nor at the usual hour — it is scheduled in the final examination period on Wednesday, December 9, 2026, 1:00–3:00 PM. Note that it ends at the time class would normally start.

Neither Student Wellness Day (Wed 11/25) nor the Thanksgiving recess (Thu–Fri 11/26–11/27) falls on a class day. The last day of instruction is Fri 12/04. The Week 15 session sits in the final examination period (12/07–12/11) and is scheduled by the registrar for Wednesday, December 9, 1:00–3:00 PM — it follows neither the regular Monday meeting day nor its 3:00 PM start. Arriving at the usual class time means arriving as the session ends.

How Milestones Are Submitted

Every milestone has two parts, and both are graded:

1. An in-class presentation on the milestone date.
2. A repository snapshot containing the core project artifacts — an annotated Git tag, pushed to GitHub, marking the exact commit your team presented.

The presentation is how the team communicates; the snapshot is what makes the claims checkable.

Tagging a milestone

Tag the commit you present, then push the tag. From your repository root, the full sequence for Milestone 1 is:

git add -A
git commit -m "Milestone 1 submission"
git tag -a milestone1 -m "Milestone 1 as presented"
git push origin main
git push origin milestone1

Use the tag names milestone0, milestone1, milestone2, and finalProject.

• Confirm the tag exists with git tag -l and inspect it with git show milestone1.
• It must also appear under the Tags tab of your repository on GitHub — that is where it will be graded from.
• The -a flag creates an annotated tag, which records an author and a timestamp. That timestamp is what establishes when the snapshot was taken. A lightweight tag (git tag milestone1, with no -a) records neither and is not sufficient.
• Moving or re-creating a tag after the deadline changes that timestamp and is visible in the repository history. A milestone is graded on the state of the repository on its due date, so re-tagging afterward does not change what is graded.

If no tag is in place on the due date, the milestone is graded from the project's main branch instead. Tag whatever exists at the deadline rather than waiting for the work to feel finished. A team that does not tag is still graded — just from main, rather than from a snapshot the team chose deliberately and can speak to during the presentation.

Group Structure and Expectations

• Groups consist of ~4 students (any mix of graduate and undergraduate students allowed) [one group may have five members].
• Teams have been assigned.
• Groups may self-select. Teams must be formed no later than Week 03, Monday, September 14, 2026.
• Students not on a team by that date will be assigned to one by the instructor.
• Each group must designate one spokesperson:
  • Primary point of contact (POC) with the instructor
  • Responsible for official communication and for confirming milestone tags are pushed
• Teams document member roles as part of Milestone 0, and keep that record current in the repository.

All group members are expected to contribute meaningfully. Team coordination is an assessed outcome of this course, which is why group work time is scheduled inside the class block — teams are not expected to find common availability outside it, and attendance during that segment matters as much as during the lecture.

Project Scope and Data Sources

Projects must focus on edge computing.

• Build custom data generators (synthetic sensors, simulated streams, etc.)
• Use instructor-provided data, including:
  • Live video streams
  • Live sensor sources
  • Pre-recorded video datasets
  • Sensor logs

If additional hardware, datasets, or infrastructure are required, groups must contact the instructor as soon as possible.

Required System Characteristics

• At least one edge node performing non-trivial computation
• Clear justification for edge vs cloud processing — what runs where, and why
• Explicit latency, bandwidth, power, privacy, or reliability motivations
• A data pipeline involving ingestion, processing, and output
• Measurements or estimates supporting design decisions
• Execution on target or representative hardware, not only on a laptop

Core Project Artifacts

These are the artifacts the rubric is applied to. They grow in completeness across milestones, and the tagged snapshot for each milestone should contain the current state of all of them.

• Repository: reproducible builds, clear structure, and minimal setup steps.
• System design note: short architecture description (what runs where and why), including constraints and tradeoffs.
• Measurements: latency, resource use, and reliability metrics appropriate for your system.
• Deployment evidence: photos, logs, or data demonstrating the system running in a realistic or representative setting.
• Documentation: a README that an external reviewer can follow to run the pipeline and reproduce results.
• AI use record: an aiUse.md file at the repository root recording the prompts behind any AI-generated code, documentation, or presentation material, kept current as of each milestone tag. See Generative AI in Project Work below.

Project Milestones

Presentation lengths for each milestone will be announced once the number of teams is final. Plan on a short, tightly rehearsed talk and check the course website and Slack before your milestone week.

Presentation Order

Teams present in this order at each milestone, first to last.

Goal: Confirm that the project idea is well-motivated, edge-focused, and realistically scoped, and that the team is organized to deliver it, before significant implementation work begins.

This is not a demo, but it is not a paper exercise either: a repository scaffold with a working build is part of the deliverable. Feedback given at this milestone should be incorporated into Milestone 1.

Deliverables

1. Team, with documented roles
   • Members and the spokesperson
   • Who owns what, recorded in the repository
2. Scoped problem statement
   • The application scenario you are addressing
   • Who benefits from this system, and why the problem matters
   • The constraints that make it an edge problem — latency, bandwidth, power, reliability, privacy, or deployment realism
   • What would be worse or impossible with a cloud-only approach
3. Initial architecture sketch
   • Data sources
   • Edge components and target hardware
   • External or cloud resources, if any
   • What runs where, and the expected data and control flow
4. Hardware and software bill of materials
   • Devices, sensors, and accelerators
   • External libraries, services, runtimes, or APIs
   • Anything you need from the instructor, and known risks or dependencies
5. Repository scaffold
   • README and a working build
   • aiUse.md in place at the repository root
   • Tagged milestone0
6. How success will be measured
   • The metrics you will report — latency, throughput, bandwidth, accuracy, resource usage, power
   • What numbers would count as success
   • This matters: later milestones are evaluated against a target your team defined here.

Slide Guidance

• Keep the deck short — roughly five slides: team and roles, problem and motivation, architecture sketch, bill of materials, success criteria.
• Slides should be visual and concise. Avoid dense text.
• Naming format: <GroupName>Milestone0.pdf, committed to the repository.

Goal: An end-to-end pipeline on target hardware, even if thin.

This milestone is scoped as a range rather than a single bar:

• Best case: a partially working end-to-end pipeline running on target hardware, with baseline measurements already collected.
• Worst case: a well-defined end-to-end pipeline on target hardware with clearly defined measurement expectations — you know exactly what you will measure, how, and what numbers would count as success.

A vague plan with no hardware and no measurement definition satisfies neither case.

Deliverables

• In-class presentation
• Tagged snapshot: milestone1
• Updated architecture description — what runs where, and why
• Prototype demonstrating data ingestion and basic processing on target hardware
• Baseline measurements, or a written measurement plan naming the metrics, method, and targets
• Working build and README; aiUse.md current
• Use of sample, simulated, or prerecorded data is acceptable at this stage

Field testing is not expected at Milestone 1 and is not part of its rubric.

Goal: Evidence of execution in a realistic or representative setting.

As with Milestone 1, a range of outcomes is acceptable — but only when supported by evidence:

• Best case: the system runs in a realistic or representative setting with measured behavior under real conditions.
• Worst case: a clearly documented field attempt with observed failures, bottlenecks, and incomplete components, supported by logs, measurements, or traces.

In both cases, teams must provide a concrete iteration plan grounded in evidence. A field test that failed and was measured is worth more than a field test that was never attempted.

Deliverables

• In-class presentation
• Tagged snapshot: milestone2
• Updated architecture diagram
• Working or nearly working demo using live data or realistic replay
• Demonstrated edge processing functionality
• Deployment evidence: photos, logs, traces, or data collected from the field attempt
• Measured behavior under real conditions — latency, bandwidth, throughput, power, failure modes
• An iteration plan citing specific evidence from the field test
• Working build and README; aiUse.md current

Goal: A stable demo plus complete documentation, measurements, and a clear explanation of design choices — including what worked, what failed, and what you would do differently with additional time or resources.

The Week 15 session sits in the final examination period and matches neither the regular meeting day nor the regular time. It is scheduled for Wednesday, December 9, 2026, 1:00–3:00 PM, in the slot assigned by the registrar — two hours earlier in the day than class normally meets, and ending at 3:00 PM, when class would normally begin. Do not rely on habit for this one.

The Final Project is not covered by the last-day-of-instruction deadline that applies to homework; it is due at this scheduled presentation. Your finalProject tag must be pushed before the session begins at 1:00 PM.

Deliverables

• Annotated tag finalProject pushed to GitHub and visible under the Tags tab
• Final presentation and demo (live or recorded)
• Final architecture diagram (PDF in GitHub)
• Sample inputs and outputs (at minimum, described in the report)
• Measurements and evaluation results (in the report)
• Deployment evidence (photos, logs, traces, or collected field data)
• Complete documentation (README.md in GitHub)
• Final written report (PDF in GitHub)
• Final presentation slides (PDF in GitHub)
• Final source code (GitHub repository)
• Build and environment specification sufficient for another person to reproduce the system (requirements.txt, environment.yml, Dockerfile, or equivalent)
• aiUse.md complete and current at the repository root
• System verified to run on class resources

Project Rubric

All milestones and the final project are evaluated using a common rubric, with expectations increasing over time.

Not every milestone is evaluated on every category, because not every milestone asks for the same evidence:

Neither measurement nor field evidence is expected at Milestone 0. Field testing does not apply at Milestone 1, which asks for a prototype with baseline measurements rather than deployment in the field.

What each category means

• System design and architecture: clarity of the end-to-end system, including what runs where and why, and how design choices respond to constraints such as data size, computation, privacy, and power.
• Implementation and engineering quality: correctness, reliability, and maintainability, including reproducible builds and execution on target or representative hardware.
• Measurement and evaluation: appropriate measurements of performance, resource use, data movement, and power or energy where feasible, with interpretation that informs design decisions.
• Field testing and iteration: evidence of execution in realistic or representative settings, including observed failures, bottlenecks, and an iteration plan grounded in logs, traces, or measurements.
• Documentation and communication: documentation sufficient for a third party to reproduce results, and a clear explanation of assumptions, constraints, and design tradeoffs.

Qualitative Grading Guidelines

Grades reflect correctness, completeness, and engineering quality under realistic constraints. The rubric categories above are the primary evaluation lens.

A system that fails in operation but is supported by evidence, measurements, and analysis is evaluable and may receive a high grade. A submission that cannot be evaluated due to missing artifacts, evidence, or measurements will not.

• A-level: strong performance across all rubric categories; runs reliably on class resources; measurements are well-motivated and interpreted; design choices are defensible under stated constraints; documentation enables reproduction without instructor intervention; code is organized and maintainable.
• B-level: largely correct and complete, with one or more weaknesses in rubric execution (for example: limited measurement quality, unclear tradeoff justification, incomplete reproducibility details, or reduced robustness); documentation may require some instructor intervention to run.
• C-level: partially correct or incomplete pipeline; limited evidence of realistic testing; unclear ownership of design decisions; documentation insufficient for reproduction; weaknesses span multiple rubric categories.
• D/F-level: no evaluable system submission, missing core artifacts, absence of meaningful measurements or evidence of execution, or academic integrity violations.

Final Report

The final report should document the complete system, design decisions, and evaluation. Example report that has many of the components; it lacks performance and architecture drawings but gives overall length and level of detail.

This is a single group report submitted by the team, as a PDF in the repository under the finalProject tag.

What to Focus on in Report

• System Design and Architecture
  • Clear, well-labeled architecture diagram
  • Component-level description (edge, data sources, processing, outputs)
  • Data flow through the system
  • Justification of edge vs cloud placement
• Implementation Details
  • Key algorithms, models, or processing steps
  • How data is ingested, processed, and transmitted
  • Important engineering decisions (e.g., batching, scheduling, filtering)
  • Integration challenges and how they were resolved
• Evaluation and Performance Measurements (Primary Component)
  • Quantitative results:
    • latency
    • throughput
    • bandwidth and data movement
    • resource usage (CPU, GPU, memory)
    • power or energy, where feasible
    • accuracy (if applicable)
  • Description of how measurements were collected
  • Experiments under different conditions or configurations
  • Clear connection between results and system design decisions
  • Results measured against the success criteria your team defined at Milestone 0
• Field Testing and Iteration
  • What was deployed, where, and under what conditions
  • Observed failures and bottlenecks, with supporting logs or traces
  • What you changed in response, and what the evidence was
• System Trade-offs and Design Decisions
  • What decisions had the biggest impact on performance
  • Trade-offs (latency vs accuracy, bandwidth vs compute, edge vs cloud, power vs responsiveness)
  • Limitations of your approach
• Lessons Learned
  • Technical lessons about building edge systems
  • What worked well and what did not
  • What you would change with more time or resources

What to NOT Do in Report

• Do not only describe what the system does
• Do not include large amounts of unprocessed logs or raw output without analysis
• Do not omit performance measurements or evaluation methodology
• Do not rely only on qualitative claims without quantitative evidence
• Do not hide or omit a failed field test — document and measure it instead

Strong Reports Typically Include

• Comparisons between multiple system configurations
• Evidence supporting why edge computing was beneficial
• Analysis of bottlenecks and system limitations
• Clear figures, diagrams, and tables
• Reproducibility details (how to run the system)

Reproducibility Requirements

• All code must be available in GitHub
• Include sufficient instructions to run the system
• Provide dependency and environment specifications:
  • requirements.txt, environment.yml, Dockerfile, or equivalent
• Grading is done on class resources — verify your system runs there, not only on your laptop

Final Presentation

The final presentation should prioritize demonstration and insight, not a full retelling of the report. The time limit will be announced once the number of teams is final.

What to Focus on in Presentation

• System Demo (Primary Component — roughly half your time)
  • Live or recorded demonstration of the complete system
  • Clear walkthrough of input → edge processing → output
  • Explicitly highlight what runs at the edge vs external resources
• Lessons Learned (Primary Component — roughly a quarter)
  • What worked well and why
  • What did not work and why
  • What you would change with more time
  • Key insights about edge computing
• Key Design Decisions (Very Concise)
  • 1–2 important trade-offs
  • Examples: edge vs cloud placement, latency vs accuracy, bandwidth vs compute
  • Brief justification supported by results
• Evaluation Highlights (Very Concise)
  • Only the most important metrics
  • Focus on evidence that demonstrates the value of edge computing

What to NOT Focus on in Presentation

• Background or motivation (covered at Milestones 0 and 1)
• Detailed architecture walkthroughs (covered at Milestone 2)
• Long lists of challenges — discuss only those that led to important design changes or insights

Practical Guidance

• Your demo should work immediately. Do not spend time setting it up live.
• If using a recording, keep it tight and narrated.
• Keep the deck small — six to eight slides is usually right.
• Assume the audience already understands your project at a high level.
• You may be asked to explain and defend any part of your submission, including design choices, measurements, and specific code paths. On a team deliverable, any member may be asked about any part — including code they did not personally write or generate.

Individual Reflection and Peer Evaluation

Individual Reflection (Required)

• Each student must submit a separate reflection at the end of the term
• Reflections should include:
  • Individual contributions to the project
  • Technical challenges encountered
  • What you learned
  • Group dynamics and collaboration
  • How work was divided, coordinated, and completed
• Peer Evaluation:
  • Assign a score from 0–10 to each team member, including yourself.
  • Scores should reflect overall contribution, reliability, and impact on the project.
  • A score of 10 represents exceptional contribution and consistent engagement, while a score of 5 represents an acceptable baseline level of contribution.
  • Scores below 5 should indicate significant gaps in contribution or participation.
  • Scores should be assigned in a fair, honest, and professional manner based on observed contributions over the duration of the project.
  • Assigning identical scores to all team members is strongly discouraged unless clearly justified.
• Reflections should be written in a professional and constructive manner, focusing on clear communication, objective assessment, and respectful discussion of team dynamics.

Upload as a PDF (Upload here, e.g., lastnameFirstnameProject.pdf).

Weekly Individual Progress Reports

Each student must submit a weekly individual progress report starting Sunday, September 20, 2026 — the first Sunday after the team formation deadline — and continuing until the final presentation.

• Due every Sunday by 11:59 PM
• Must include:
  • Work completed
  • Progress made
  • Challenges or blockers
  • Planned work for the next week

These reports are used to assess individual contribution and participation.

Generative AI in Project Work

The governing standard is that you must be able to explain and defend every part of what you submit. Assume you may be asked to do so in a short oral check covering design choices, measurements, and specific code paths. If you cannot explain it, do not submit it.

The project is where you build a real system under real constraints, and AI assistance is permitted considerably more broadly here than on homework — on the condition that it is documented in the repository where anyone reviewing your work can see it.

• AI may be used to generate, refactor, and debug project code, to draft documentation, and to help design presentation material.
• The prompts must be committed to the repository. Maintain a file named aiUse.md at the repository root and record, as you go:
  • the date
  • which team member
  • the tool and version
  • what it was used for
  • the prompt text itself
  • what the team accepted, modified, or rejected
  This file must be current as of every milestone tag.
• Presentation material designed with AI must say so. If a deck, figure, or diagram was generated or substantially shaped by AI, note that on the slide itself or in the speaker notes, and record the prompt in aiUse.md.
• Generated code remains your team's responsibility. It must be understood, tested, and defensible exactly as if you had written it by hand, and it is graded on that basis.

Prohibited

• Generative AI may not be used to fabricate measurements, logs, deployment evidence, citations, or experimental results. Any reported outcomes must be real, reproducible, and attributable.
• Project code, documentation, or presentation material generated with AI may not be submitted without the corresponding prompts recorded in aiUse.md. Undocumented AI use in project work is treated the same as undisclosed AI use anywhere else in this course.

Note: homework is governed differently and more strictly — AI may help you solve it, but may not do it. See the syllabus.

Grading and Course Weight

The team project contributes 65% of the final course grade, for both undergraduate and graduate students:

Graduate students enrolled for 4 credit hours additionally complete an individual Graduate Project worth 10%. That is separate work, not connected to your team's system — see the Graduate Project.

All students are evaluated using the same project milestones and rubric.

Late Work and Missed Milestones

Milestones are not submitted in the ordinary sense, and the per-day late penalty that applies to homework does not apply to them. A milestone is graded on what exists at its due date:

• the tagged repository snapshot for that milestone, if your team has pushed one; or
• the project's GitHub main branch, if no milestone tag is in place;

together with your team's in-class presentation for that milestone.

A milestone with nothing to grade scores 0; partial work earns partial credit. A team that does not present forfeits the presentation portion of that milestone — the repository is still graded.

To have a submission, correction, grading issue, or late penalty reviewed, you must submit the Regrade and Late Penalty Review Form. This form is the only official channel for such requests. A Slack message or an email is not a substitute, and neither is speaking to the instructor after class.

Individual Grade Adjustment

• Milestones are graded as team submissions using the rubric above
• Individual grades may be adjusted based on:
  • Weekly progress reports (fill out this form weekly!)
  • Peer evaluation
  • Instructor observations, including engagement during scheduled group work time
• Failure to contribute consistently may result in a reduced individual grade