P00 - Gridiron Group Project

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

Groups will design and build a realistic edge computing application that integrates data sources, edge processing, and (optionally) external compute resources. Projects must emphasize latency, bandwidth, deployment realism, and system trade-offs, not just correctness.

This project requires working prototypes and demos, delivered incrementally through multiple milestones.

Group Structure and Expectations

• Groups consist of 4 students (any mix of graduate and undergraduate students allowed) [one group will have five members].
• There are 12 teams, enter names on the team sign-up sheet, put both First and Last Name.
• Groups may self-select until 02/04/2026 at 11:59 PM.
• After that date, remaining students will be assigned to teams by the instructor.
• Each group must designate one spokesperson:
  • Primary point of contact (POC) with the instructor
  • Responsible for official communication and submissions

All group members are expected to contribute meaningfully.

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
• Explicit latency, bandwidth, or reliability motivations
• A data pipeline involving ingestion, processing, and output
• Measurements or estimates supporting design decisions

Project Milestones

The project pitch is a 5-minute, closed-door presentation to the instructor only. Its purpose is to confirm that the project idea is well-motivated, edge-focused, and realistically scoped before significant implementation work begins.

This is not a demo. No code is required.

Pitch Objectives

By the end of the pitch, the group should clearly communicate:

• What the group wants to build
• Why edge computing is the right approach
• That the project is feasible within the semester
• That the group has a concrete plan to reach Milestone 1 and beyond

Feedback provided during the pitch should be incorporated into Milestone 1.

Required Pitch Content

1. Project Idea and Use Case
   • What problem are you addressing?
   • Who benefits from this system?
   • Why is this problem interesting or important?
2. Why Edge Computing
   • What constraints motivate edge processing?
     • latency
     • bandwidth
     • reliability
     • privacy
     • deployment realism
   • What would be worse or impossible with a cloud-only approach?
3. Proposed System Architecture
   • High-level architecture diagram
   • Data sources
   • Edge components
   • External or cloud resources (if any)
   • Expected data and control flow
4. Planned Milestones and Timeline
   • What will exist by Milestone 1?
   • What new capabilities will appear by Milestone 2?
   • What will be demonstrated at the final milestone?
5. Resources and Dependencies
   • Data sources (instructor-provided, custom, or both)
   • Hardware or infrastructure needs
   • External libraries, services, or APIs
   • Known risks or dependencies
6. Evaluation and Success Criteria
   • How will you measure success?
   • What metrics will you report?
     • latency
     • throughput
     • bandwidth
     • accuracy
     • resource usage
   • What evidence will demonstrate meaningful edge benefits?

5-Minute Time Breakdown (Strict)

Practice ahead of time. The pitch will be stopped at 5 minutes.

Slide Requirements

• Maximum of 5 slides total
• Required slides:
  1. Title and group members
  2. Problem statement and motivation
  3. Architecture diagram
  4. Milestone timeline
  5. Evaluation metrics and resources
• Slides should be visual and concise
• Avoid dense text

Deliverables

• Slide deck (PDF) Naming format: <GroupName>ProjectPitch.pdf

Goal: Demonstrate a concrete system concept and early functionality.

Deliverables

• Project motivation and use case
• Initial architecture diagram
• Mock-up or early prototype demonstrating data ingestion and basic processing
• Use of sample, simulated, or prerecorded data is acceptable

Goal: Demonstrate realistic progress toward deployment.

Deliverables

• Updated architecture diagram
• Nearly working demo using live data or realistic replay
• Demonstrated edge processing functionality
• Evidence of deployment realism (latency, bandwidth, throughput, etc.)
• Initial draft (DUE: 8:00 AM April 14, 2026) (Upload, e.g., bearsDraftReport.pdf):
  • Planned edge versus cloud split
  • Technologies used
  • Challenges you have encountered
  • Key risks you have to completing
• Slides (DUE: 8:00 AM April 14, 2026) (Upload, e.g., bearsSlides.pdf)

Goal: Deliver a polished, end-to-end edge computing system.

Deliverables

• Final demo (live or recorded)
• Final architecture diagram (in GitHub, PDF file)
• Sample inputs and outputs (at minimum described in report)
• Measurements and evaluation results (in report)
• Complete documentation (in GitHub, README.md file)
• Final written report (in GitHub, PDF file)
• Final presentation (in GitHub, PDF file)
• Final source code (in GitHub)
• Build, dependency, and environment files sufficient for another person to run or reproduce the system (for example, requirements.txt, environment.yml, Dockerfile, shell scripts, or equivalent)

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 drawing but gives overall length and level of detail.

This is a single group report submitted by the team (PDF file in GitHub).

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
    • resource usage (CPU, GPU, memory)
    • accuracy (if applicable)
  • Description of how measurements were collected
  • Experiments under different conditions or configurations
  • Clear connection between results and system design decisions
• 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)
  • 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

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

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

In addition, each student must submit an individual reflection (Upload (e.g. lastnameFirstnameProject.pdf)).

Final Presentation

The final presentation should prioritize demonstration and insight, not a full retelling of the report. You have 9 minutes total.

What to Focus on in Presentation

• System Demo (Primary Component)
  • 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)
  • 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 (Milestone 1)
• Detailed architecture walkthroughs (Milestone 2)
• Long lists of challenges, should only be discussed if they led to important design changes or insights

Suggested Time Breakdown (9 minutes total)

Practical Guidance

• Your demo should work immediately. Do not spend time setting it up live.
• If using a recording, keep it tight and narrated.
• Use at most 6–8 slides total.
• Assume the audience already understands your project at a high level.

Individual Reflection and Peer Evaluation

Individual Reflection (Required)

• Each student must submit a separate reflection
• 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.

Weekly Individual Progress Reports

Each student must submit a weekly individual progress report starting February 22, 2026 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.

Grading and Course Weight

The group project contributes 60% of the final course grade.

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

Evaluation Notes

• Milestones are graded as group submissions
• Individual grades may be adjusted based on:
  • Weekly progress reports (Fill out this form weekly!)
  • Instructor observations
  • Peer feedback
• Failure to contribute consistently may result in a reduced individual grade