XR for Engineering Team Project

Description

You will work in a team of 2–4 students (undergraduate teams separate from graduate teams) to design and develop an engineering-focused XR application using one primary modality, confirmed by Week 7:

  • VR Track
  • AR Track

Dual-modality projects are allowed but not required and should only be attempted if you can keep the scope manageable. Dual-modality work receives no automatic extra credit. Modality comparison in the proposal is for decision-making only—final implementation is still VR only or passthrough AR only. If you build a dual-modality project, you must still clearly identify one primary track for grading. Extra modality work is treated as scope extension, not a substitute for the required pillars.

Scope note: Do not build a full game, full factory, or oversized multi-system application. A polished, focused prototype with clear engineering value is better than a broad but unfinished concept.

Example Projects

The following examples illustrate the range of focused, engineering-centered XR projects that can be developed. They are provided for inspiration only; student teams should define their own engineering problem, users, scope, interactions, and technical approach.

Humanoid Robot Teleoperation

This project developed an XR-based interface for teleoperating humanoid robots, combining stereo visual streaming, AI-assisted perception, gesture-accessible safety controls, tactile sensing, and vibrotactile feedback. The system uses object detection, depth estimation, and edge visualization to support manipulation while transmitting fingertip force measurements from a robotic hand to wearable haptic gloves. Its engineering significance lies in improving operator situational awareness, dexterity, and safety for remote manipulation in hazardous, inaccessible, or unstructured environments, while highlighting practical trade-offs involving latency, tracking reliability, networking, and haptic fidelity.

VR Gearbox Assembly Trainer

This project created a complete VR training application for SEW Eurodrive’s gearbox assembly procedure, allowing technicians to practice realistic gripping, placement, heating, and striking operations within a controlled virtual workstation. A state-machine-driven workflow enforces the correct sequence, updates instructions dynamically, and provides visual and audio feedback without consuming physical components or requiring continuous expert supervision. The project demonstrates how VR can standardize industrial training, reduce material waste and equipment risk, and provide a reusable technical architecture for other complex manufacturing and maintenance procedures.

MR Radiation Detection

This project developed a mixed-reality radiation-detection training experience in which users operate a virtual Geiger counter to locate a hidden radioactive source within their physical surroundings. Distance-dependent sound, needle movement, visual danger indicators, randomized source placement, and multimodal instructions simulate the perceptual cues associated with real radiation-detection equipment. Its engineering value is the ability to provide repeatable, spatially realistic training for nuclear engineers and other personnel without exposing trainees to radioactive materials, while supporting scalable education in hazard identification and emergency preparedness.

Goals

  • Define and justify a real-world engineering problem suitable for XR intervention.
  • Apply key XR technical topics (Unity/C# scripting, VR locomotion/interaction/UI, or passthrough AR placement/anchoring/interaction, logic, feedback) appropriate to the chosen track.
  • Embed human-centered XR design principles throughout conceptualization, prototyping, and evaluation.
  • Perform at least two rounds of internal testing and validation to improve the XR experience.
  • Communicate design and technical decisions through documentation, presentations, and reflective analysis.
  • Assess team dynamics via structured peer evaluation to ensure accountability and balanced contribution.

Requirements

Your team must complete the following:

  • Confirm one primary track for grading by Week 7: VR or AR.
  • Define one engineering problem and target user group.
  • Implement one focused XR prototype addressing that problem.
  • Implement at least four technical pillars from the chosen track (see below).
  • Include one meaningful interaction loop.
  • Include one UI/status/instruction element.
  • Include one feedback mechanism beyond visuals, such as audio, haptic, or simulated feedback.
  • Apply at least three human-centered/XR design principles from Module A/A2.
  • Conduct at least two internal testing/validation rounds (see minimum expectations below).
  • Document findings and iterate based on them.
  • Submit milestone evidence through video, PDF reports, and final presentation.
  • Complete peer evaluation.

Minimum testing/validation expectations: Formal participant research (IRB) is not available for this course, so use internal testing only. Run at least 2 internal testing rounds with your team (teammate walkthroughs and self-testing are fine). For each round, briefly document the task tested, what you noticed, and any change you made afterward. TA/instructor or non-developer testers are welcome but not required.

Project Tracks

You do not need to permanently lock your modality in Week 3. In your proposal, identify a preferred track and briefly compare it against the alternative track. Final track selection is confirmed at the midterm prototype stage after you have had more exposure to both VR and passthrough AR workflows. Strongly consider the AR Track when your project benefits from augmenting a real workspace, physical object, lab setup, machine, workstation, printed marker, tabletop mockup, training panel, or physical workflow. Strongly consider the VR Track when the target environment is unsafe, inaccessible, too large, fully simulated, or better represented as a complete virtual training world.

Because passthrough AR is introduced later in the course, do not dismiss the AR Track too early. If your project involves physical context, real equipment, tabletop workflows, or anchored guidance, seriously evaluate passthrough AR before finalizing your direction.

VR Track

If you choose the VR Track, implement a focused immersive experience with:

  • VR locomotion/navigation or constrained movement.
  • At least one grab, socket, activation, inspection, or manipulation workflow.
  • World-space UI or spatial instruction panel.
  • Feedback through visual, audio, and/or haptic/simulated haptic cues.
  • Comfort and usability considerations.

Examples:

  • VR maintenance trainer.
  • VR assembly/inspection station.
  • VR robotics safety walkthrough.
  • VR logistics or workstation simulation.
  • VR for robot teleoperation.

AR Track

If you choose the AR Track, implement a focused passthrough AR experience with:

  • Passthrough AR scene setup.
  • Plane/raycast placement or scene/space-aware placement where supported.
  • Local anchor or anchoring/placement strategy where supported.
  • XRI controller, hand, ray, poke, grab, or world-space UI interaction.
  • Validation on headset hardware through Build and Run, link preview plus device validation, or supervised TA demo.

Examples:

  • Anchored maintenance overlay.
  • Workstation instruction panel.
  • AR for equipment inspection.
  • Safety/hazard visualization.
  • AR for human–robot/machine interaction.

Passthrough AR features such as anchors, scene data, hand tracking, meshing, and occlusion are provider/device/configuration dependent. Validate on actual headset hardware or through a supervised TA demo.

Required Technical Pillars

Implement at least four technical pillars from the list below. At least one must come from Interaction, and at least one must come from Feedback/UI.

VR Track Pillars

  • Interaction
    • Locomotion/navigation.
    • Grab/manipulation/socket workflow.
    • Activation/state-change system.
  • Feedback/UI
    • World-space UI or instruction panel.
    • Spatial audio.
    • Haptic or simulated haptic feedback.
  • Additional
    • Custom C# logic/state management.
    • Comfort/usability feature.
    • Performance/readability optimization.

AR Track Pillars

  • Interaction
    • Plane/raycast placement.
    • Local anchor or anchoring strategy where supported.
    • XRI controller/hand/ray/poke/grab interaction.
  • Feedback/UI
    • World-space UI or anchored instruction panel.
    • Spatial audio or haptic/simulated feedback.
  • Additional
    • Passthrough AR scene setup.
    • Custom C# logic/state management.
    • Tracking/registration validation.
    • Scene/space-aware feature where supported.

Evidence requirement: Include a Technical Pillar Evidence Table in the proposal, midterm report, and final report:

Technical pillar Where implemented Evidence shown Video timestamp
(fill in) (fill in) (fill in) (fill in)

In the Week 3 proposal, you may leave the video timestamp column blank or mark it as “planned.” By the midterm and final submissions, the table must include video timestamps or TA demo references.

Submission Model

Because Unity projects can become large and difficult to submit, the default submission model is demo-first: short videos, concise reports, and clear build/run documentation. Do not upload full Unity project folders to Canvas. Videos do not need to be professionally edited. A clear screen recording or headset capture with narration or captions is sufficient, as long as required features are visible.

Required submission approach

  • Reports and slides submitted to Canvas.
  • Demo videos submitted to Canvas or linked from Drive/OneDrive/YouTube/GT-supported storage.
  • Code/project files shared through one stable platform you choose:
    • Google Drive,
    • OneDrive,
    • GitHub,
    • GitLab,
    • Box,
    • or another approved platform.
  • GitHub is allowed but not required.
  • Do not submit Unity cache folders: Library/, Temp/, Obj/, Logs/, or full generated caches.

Fallback

If file upload, recording, or Unity packaging fails, submit the required report by the deadline and sign up for a brief TA demo. TA demos must be scheduled by the deadline. A TA demo is a fallback verification method, not an extension. The TA or instructor may request source files if a feature cannot be verified from the video, presentation, or report.

Team Accountability

  • Define roles by Week 3.
  • Roles may change, but document any changes.
  • Include individual contribution summaries in the final report.
  • Complete peer evaluations.
  • Instructor/TA may adjust individual grades when contribution is substantially uneven.
  • Every member of your team must participate in the final presentation unless excused.

Deliverables

Submit milestone evidence across Weeks 3, 7, 13, and 14—each stage adds required video, report, and presentation artifacts that build toward your final demo-first prototype in the confirmed track.

Week 3: Project Proposal

Define your engineering problem, preferred track, and scoped plan for instructor feedback before you build.

Requirements

  • PDF, ≤ 3 pages.
  • Preferred track: VR or AR.
  • One-sentence alternative concept in the other track.
  • A short modality decision rationale comparing VR and passthrough AR for the chosen engineering problem.
  • Current reason for the preferred track.
  • What evidence would cause you to switch tracks by midterm.
  • Engineering problem and motivation.
  • Target users/stakeholders.
  • Proposed interaction loop.
  • Four planned technical pillars (for the preferred track).
  • Human-centered/XR design principles to apply.
  • Success criteria.
  • Planned validation method.
  • Team roles and timeline.
  • Risk/scope control plan.

Project Plan

Include a project plan following the template below.

Requirement Team plan
Preferred track  
Engineering problem  
Target user  
Four technical pillars  
Core interaction loop  
Validation method  
Scope risk  

Modality Comparison

Briefly compare VR and AR for your problem in the table below. Instructor/TA feedback may recommend that you reconsider modality if your proposed problem appears better suited to passthrough AR or VR. The goal is not to force you into one track, but to help you choose the modality that best matches the engineering problem.

Modality option Why it fits the problem Main risk What we would need to test
VR      
AR      

Submit the proposal PDF through Canvas. You will receive feedback offline.

Week 7: Midterm Prototype

  • Final track confirmed: VR or AR.
  • One paragraph in the midterm report explaining why the final track was selected after comparing the two options.
  • Working partial prototype in the confirmed track.
  • Short video walkthrough, 4–5 minutes.
  • Midterm report, 2–3 pages.
  • Technical Pillar Evidence Table.
  • At least two implemented technical pillars.
  • At least one working interaction loop or partial interaction loop.
  • Preliminary UI/feedback element.
  • Initial internal testing plan or first internal testing round.
  • Known limitations and next steps.

Midterm does not need to be polished. It must show that the core technical direction works.

Week 13: Final System + Evaluation

Submit your working prototype with demo-first evidence that shows the implemented system, design choices, and what you learned from internal testing.

Requirements

  • Final demo video, 5–7 minutes.
  • Final report, 4–6 pages.
  • Final presentation slides.
  • Working prototype or supervised TA demo.
  • Technical Pillar Evidence Table with video timestamps.
  • Design Principle Evidence Table (see below).
  • Internal testing summary for at least 2 rounds (task tested, findings, and changes made in response).
  • Iteration summary: what changed after internal testing.
  • Build/run/deploy instructions.
  • Limitations and future work.
  • Individual contribution summary.

Design Principle Evidence

Document at least three human-centered/XR design principles from Module A/A2 and show where each appears in your prototype.

Design principle How applied Evidence
     

Filename Formats

  • Project_FinalReport_TeamName.pdf
  • Project_FinalSlides_TeamName.pdf
  • Project_FinalDemo_TeamName.mp4 or stable video link
  • Project_Reflection_TeamName.pdf (Week 14)
  • Project_GraduateResearchAppendix_TeamName.pdf (graduate teams)

Week 14: Reflection + Peer Evaluation

  • Team reflection, 1–2 pages.
  • Individual contribution statements.
  • Structured peer evaluations.

Peer evaluation may adjust individual grades if contribution is substantially uneven.

Project Files and Versioning

  • You may use any stable platform for code/assets.
  • GitHub is optional, not required.
  • Maintain some form of version tracking:
    • Git history,
    • dated ZIP snapshots,
    • clearly labeled Drive/OneDrive folders,
    • or another documented versioning method.
  • Your final project folder must include:
    • README or build/run guide,
    • source/project files needed to reproduce the prototype,
    • media links,
    • reports/slides or links to them,
    • known limitations.
  • Do not include Unity generated cache folders.

The grader should be able to understand what to open, how to run it, and what features to test within 10 minutes.

Graduate Team Research Extension

If you are on a graduate team, complete the full project plus a Research Position + Design Rationale Appendix. The goal is not to write a long literature review. The goal is to show that your team can use research to make better XR engineering design decisions, justify trade-offs, and evaluate the limitations of your prototype.

Your graduate work must visibly affect design, implementation, validation, or interpretation of results. It cannot remain only a paper summary.

1. Research Position

Choose one focused research position that connects directly to your project. A research position is a claim about how your XR system should be designed or evaluated, based on prior research and your project goals.

Examples:

  • For this maintenance task, anchored passthrough AR guidance should reduce context switching compared with a fully virtual trainer.
  • For this safety-training scenario, constrained VR locomotion is more appropriate than free movement because comfort and task focus matter more than environmental exploration.
  • For this inspection workflow, multimodal feedback is necessary because visual-only alerts may be missed during attention-demanding tasks.
  • For this assembly task, spatially located instructions should be placed near the physical or virtual work area, but not directly on top of the object being manipulated.
  • For this robotics-training prototype, interaction reliability is more important than interaction realism because the goal is procedural understanding.

The position should be specific enough that it can influence design decisions and be evaluated through your prototype.

2. Research Grounding

Use 3–4 peer-reviewed papers to support your research position. Papers should come from credible XR, HCI, human factors, visualization, robotics, manufacturing, training, simulation, or engineering venues such as IEEE VR, ISMAR, TVCG, CHI, UIST, DIS, ICRA, IROS, HFES, or comparable venues. At least two papers must have clear engineering relevance, such as manufacturing, maintenance, assembly, robotics, safety, healthcare engineering, infrastructure, product design, simulation-based training, or technical work support. Do not provide generic AI-style paper summaries. Instead, for each paper, include a short evidence note that identifies:

  • The research question or technical problem,
  • The method or study type,
  • The most relevant finding,
  • One limitation or boundary condition,
  • How the finding affects your project.

A good evidence note should show that your team read and understood the paper. It should mention concrete details such as the study task, prototype type, comparison condition, measured outcome, design factor, participant/task context, or technical limitation.

3. Design Rationale Table

Include the following table in the graduate appendix:

Research-supported design decision Supporting paper(s) How it appears in the prototype Trade-off or limitation
       

The table must include at least three research-supported design decisions. These decisions can involve interaction design, feedback, UI placement, locomotion, anchoring, registration, task flow, comfort, evaluation method, or technical scope.

4. Research-Informed Prototype Evidence

Show how the research position affected the actual project. This does not require building a second full variant. Provide evidence through one or more of the following:

  • A prototype feature,
  • A configuration choice,
  • A design change made after testing,
  • A comparison between two design options considered by the team,
  • A validation checklist,
  • Annotated screenshots,
  • A short video segment,
  • A before/after design explanation,
  • A limitation analysis grounded in research.

The evidence should answer: What did the research make you do differently?

5. Graduate-Level Evaluation Reflection

In addition to the core project testing requirements, include a short evaluation reflection that connects the research position to the prototype results. Address:

  • What did you test or inspect?
  • What evidence supports your research position?
  • What evidence challenges or complicates it?
  • What limitation prevents you from making a stronger claim?
  • What would a stronger future study or prototype need?

Do not present the course project as a formal research study. No IRB-level claims are expected. The goal is thoughtful interpretation of design evidence, not publishable results.

6. Graduate Research Appendix

  • Submit a separate appendix: Project_GraduateResearchAppendix_TeamName.pdf
  • Length: 3–5 pages maximum.
  • Include:
    • Research position,
    • 3–4 paper evidence notes,
    • Design rationale table,
    • Prototype evidence,
    • Graduate-level evaluation reflection,
    • Limitations.

The appendix should be concise, specific, and directly tied to your project. It should not read like a generic literature review.

Deliverable Checklist

Your team must submit:

  • Week 3 proposal PDF.
  • Week 7 prototype video + midterm report.
  • Week 13: Project_FinalDemo_TeamName.mp4 (or stable video link).
  • Week 13: Project_FinalReport_TeamName.pdf.
  • Week 13: Project_FinalSlides_TeamName.pdf.
  • Project files or stable project link.
  • README/build-run guide.
  • Week 14: Project_Reflection_TeamName.pdf.
  • Week 14 peer evaluations.

If you are on a graduate team, also submit:

  • Project_GraduateResearchAppendix_TeamName.pdf.
  • Research position.
  • 3–4 paper evidence notes.
  • Design rationale table.
  • Research-informed prototype evidence.
  • Graduate-level evaluation reflection.

Logistics

  • Form your team by Week 2.
  • Proposal due Week 3.
  • Midterm deliverable due Week 7.
  • Final deliverable due Week 13.
  • Reflection & peer evaluations due Week 14.
  • Submission via Canvas or linked platform.
  • Final presentations at end of term; every member of your team must participate.

Evaluation

If a claimed feature is not visible in the demo, report, TA demo, or project files, it may receive little or no credit.

Core (100 points)

Criterion Objective evidence Points
Engineering problem and stakeholder framing Clear problem, user/stakeholder, engineering value, and success criteria 10
Track alignment and scope control Final track confirmed by Week 7; VR or passthrough AR fits the problem; scope is focused and feasible 10
Technical pillar implementation At least four chosen technical pillars are implemented and shown with evidence 20
Core interaction loop Prototype supports one meaningful interaction workflow tied to the engineering problem 15
Human-centered/XR design principles At least three principles are applied and documented with concrete design evidence 15
Testing and iteration At least two internal testing rounds are conducted and lead to documented findings and changes 10
Communication and demo quality Final video/presentation clearly explain problem, solution, features, and impact 10
Documentation and reproducibility README/build-run guide, project organization, limitations, and media links are clear 5
Team process and peer evaluation Roles, collaboration, reflection, and peer evaluation show accountable teamwork 5

Graduate Requirement (25 points)

Criterion Objective evidence Points
Research position Clear, specific, project-relevant claim about XR design, implementation, or evaluation 5
Research grounding 3–4 credible papers are used; at least two have clear engineering relevance; evidence notes show concrete understanding rather than generic summaries 6
Design rationale At least three design decisions are explicitly connected to research findings and project constraints 6
Prototype/evaluation connection Research visibly affects the prototype, design choices, validation method, or interpretation of results 5
Reflection and limitations Appendix explains trade-offs, limitations, and what stronger future work would require 3

If you are on a graduate team, this graduate requirement is required—not optional extra credit. Your project grade includes the core rubric above plus these graduate criteria.