Mindfulness Wheel

rxyan2@wm.edu

Mindfulness Wheel
Ran Yang

Abstract

In PHYS 351, Scientific Instrumentation, our final project is meant to be both fun and mind-opening. This fall we will build a dual-rotor Mindfulness Wheel—a quiet instrument that hears a simple human cue and returns it as smooth, measured motion. We will use careful electronics and clear firmware to shape an experience that brings attention back to the heart, like wind over water, without pretense and without appealing to anything outside ourselves.

Turning Toward the Heart

We may open our minds in different ways. In space: each year we look beyond the United States and learn from another culture—Italy, Japan, the Netherlands and more. We do this to broaden perspective as part of a holistic undergraduate education. Seeing through another lens changes what we notice and how we build. In purpose: we choose work that can matter to ordinary life, not only to laboratories and factories. This year we turn to 轉經輪—Zhuǎn Jīng Lún. See Figures below

Zhuǎn Jīng Lún is often called a “prayer wheel,” but the philosophy beneath it is quieter than the English suggests. Within Tibetan Vajrayāna, which sits inside the wider Mahāyāna tradition, short lines—often associated with Avalokiteśvara/Guanyin—are written many times on a hidden scroll. One turn of the cylinder is treated as many gentle recitations. The motion is not a plea to an outside power; it is a return inward, a way to come back to the heart so attention can rest in compassion. Tibet’s high plateau—among the highest places on Earth—gave the device a physical home; the practice of “turning toward the heart” gave it a lasting one. It is religion, philosophy, and daily habit braided together: a way to steady the mind through rhythm.

Monumental wheel installation in Qinhai. — Handheld form of *Zhuǎn Jīng Lún*.

There are many forms of this device. Some are small, handheld cylinders turned gently as one walks; others line monastery corridors in long arrays so you can pass slowly and set each wheel in motion with your palm. And there are monumental versions as well: in Qinghai, a giant wheel in the Guide/Guìdé area is water-driven by the Yellow River, a local landmark often cited as one of the largest of its kind.¹ ² The point is not rarity but presence: wheels large and small, solitary and in corridors, woven into everyday life.

William & Mary gives every student a liberal-arts education for good reasons: we cannot learn only STEM. Humanities, philosophy, and the arts are not extras; they shape how we see and what we make. That spirit was on full display when the Dalai Lama visited campus in 2012 to speak on compassion ³ (see Figure below), a theme rooted in Tibetan Vajrayāna’s devotion to Guanyin (Avalokiteśvara), the Bodhisattva of Compassion.

Photograph unavailable: the Dalai Lama at William & Mary in 2012.

His Holiness the 14th Dalai Lama at William & Mary (2012). Source: W&M News.

A brief cultural note from the heart of high-energy physics: in front of CERN stands a bronze statue of Shiva as Nataraja, the cosmic dancer. It is not there as theology, but as a symbol of rhythm, creation, and dissolution—themes that many physicists find resonant with the cycles we model in nature.⁴ For our class, it is simply another reminder that science does not float above culture; it moves through it.

Photograph unavailable: Shiva as Nataraja at CERN.

Shiva as Nataraja at CERN. A cultural symbol of rhythm and transformation placed at CERN (The European Organization for Nuclear Research), Geneva.

Whatever your path—industry, research, medicine, startups, teaching—your skills should travel widely. It would be narrow to imagine engineering only as another rocket or another robot. Those are wonderful, but your tools can also support calmer classrooms, steadier hands, and kinder homes. Technology can serve ordinary needs with the same rigor we bring to laboratories.

The teachings that inspire Zhuǎn Jīng Lún resonate with modern psychology and neuroscience around mindfulness, attention, and mental wellness. Repetition organizes noisy systems. Breath pacing and gentle focus can shift autonomic balance and stress markers. A short, well-timed message can interrupt a ruminative loop. None of this requires belief in an outside agency; it asks only that we test what helps a mind settle and a body soften. In that way, the old practice and contemporary science meet on common ground.

And so we will build a Mindfulness Wheel—a secular, dual-rotor instrument that listens for a human cue and answers with balanced motion—so that users can come back to their own heart to find peace, kindness, compassion, and a more durable happiness. It will be made from off-the-shelf materials, guided by careful electronics and clear firmware, and finished with a user experience that is gentle and honest. What turns here is not a plea; it is attention itself, returning to where it begins.

Deliverables & Evaluation

Minimum Requirements (the 60%)

A. Motion & Control

Dual concentric rotors (inner & outer), coaxial and mechanically safe.
Bidirectional capability on each rotor (CW & CCW).
Commanded cycle: a single user action triggers both rotors to complete $\geq 2$ full rotations each, in opposite directions; support direction swap by command.
Usability window: one command cycle normally completes within $\leq 60$ – $90$ s (coast allowed).
Counting accuracy: instrumented rotation counting with logging ( $\leq 1\%$ error over 100 rev in bench test).

B. Input & Mapping

Creative input channel (e.g., voice phrase, clap cadence, light pattern, gesture, capacitive touch). Users do not type a number; instead, features are deterministically mapped to counts/speeds and used to seed a pseudo-random routine (same input $\rightarrow$ same outcome).
Evidence: log input features $\rightarrow$ seed $\rightarrow$ resulting rotations/speeds to CSV/serial for verification.

C. Interface & Experience

UI minimum: command-line/serial menu plus Start/Stop and a physical E-stop; clear status indicators (LEDs/audio) while spinning.
Affirmation on stop: present one of $\geq 6$ positive, mindfulness-aligned messages (display/audio/light). Tone must be genuinely supportive (no irony/sarcasm).
Product identity: define a concise name (and optional tagline) for the instrument that reflects its purpose and mindfulness framing.
Target user & usability: choose one specific primary user group (not “everyone”) and design for their ease-of-use. Give 2–3 core use cases (e.g., kindergartners learning kindness, stressed college students pre-exam, divorcing couples seeking calm) and show a brief usability check (heuristic walk-through or tiny user test).

D. Build & Materials

Off-the-shelf structure (PVC/wood/acrylic/cardboard/metal stock) with tidy wiring, strain relief, labels; minimal 3D printing only if essential.
Approved vendors: Amazon, Mouser, Digi-Key, Adafruit, SparkFun, Home Depot, Lowe’s (others require approval).
Safety: guarded moving parts, proper power regulation/decoupling, fusing as appropriate.

Documentation

User’s Manual $+$ Technical Appendix are required deliverables. Beyond completeness, we will assess clarity, accessibility for your chosen user, and creative engagement (visuals, data storytelling, a welcoming quick-start).

Design Depth (the 40%)

Your creativity is evaluated on how thoughtfully you transform a human signal into a complete experience. In particular:

Creative Input Modality & Features. The input method is your canvas (e.g., short spoken phrase, clap cadence, breath pacing, light pattern, capacitive touch, gesture). Extract clear features (tempo, amplitude, duration, spectral cues, light–dark ratio, etc.) and explain them briefly in the UI or README.
Input $\rightarrow$ Motion Mapping (both rotors). From those features, deterministically compute:
1. Rotation directions for each rotor (CW/CCW), including any direction schedule (e.g., inner reverses at mid-session, outer holds).
2. Speed profile(s) for each rotor (e.g., constant, ramp, breath-synced oscillation), including min/max limits and smoothing.
3. Rotation counts for each rotor (inner & outer may differ).
Use a pseudo-random element that is seeded by the user’s features so the experience feels varied yet is reproducible for the same input (same input $\rightarrow$ same seed $\rightarrow$ same outcome).
End-of-Session Message & Medium. Map the same user-seeded features (or seed) to the selection of a positive, mindfulness-aligned message and its form (text on OLED, light pattern, tone/chime, or short audio). Curate at least six messages; tone must be genuinely supportive. Show in your README how the mapping works (e.g., calm inputs bias toward calming messages).
Transparency & Evidence. Clearly visualize or log the chain: input features $\rightarrow$ seed $\rightarrow$ (dir/speed/count) per rotor $\rightarrow$ message choice. Provide a lightweight UI readout or a post-run summary so a non-expert can see that the motion and message came from their input.
Engagement & Fit for Target User. The whole interaction (input, motion feel, message, visuals/sound) should feel inviting and appropriate for your declared primary user group (not “everyone”). We judge how coherent and engaging it is for that user.
Control Quality & Finish. Smooth starts/stops, minimal overshoot, quiet operation, robustness to small disturbances; tidy build and labels; optional GUI with presets and summaries earns credit when it enhances clarity.

Project Grading Considerations

Details & Policies

Individual. Assessed by instructor/TA using: (i) weekly attendance & lab engagement; (ii) evidence of role ownership (named tasks shipped by you); (iii) weekly peer evaluations; (iv) repo activity & media (photos/videos) you contributed; (v) professionalism, safety, teamwork.

Demo & Design. Your live Demo Day score uses the rubric above. Important: To earn any Design Depth points, the device must first satisfy all Minimum Requirements (Passing Core) at the demo. Non-mindful or sarcastic messaging, or unsafe operation, will reduce this component.

Documentation. Submit one PDF: a User’s Guide (for your declared audience) and a Technical Appendix. We grade completeness and clarity, plus creative engagement (inviting quick-start, visuals, data storytelling). The guide must be genuinely mindful in tone (no irony/sarcasm), and must reflect the product name and specific user group chosen in your proposal.

What “counts” each week

Every Monday by 2:00 PM the Team Lead submits the weekly report (progress, risks, task table with owners, photos, short clip(s), repo links, BOM updates). Each student must also complete the anonymous peer evaluation. Keep your README and media current—these artifacts support both Individual and Documentation scores.

Teams & Roles

Teams consist of exactly three students. Everyone wears more than one hats; define roles in your proposal. Below are my recommendations and you may add more.

Project Lead & BOM Manager: schedules, orders, risk log, weekly reports (also serves as PR/Documentarian).
Electronics Lead: schematics, power tree, motor/driver sizing, safety/E-stop.
Firmware Lead: drivers, state machine, control loop, data logging, repository hygiene.
Test & UX Lead: acceptance tests, calibration, UI/UX flow, affirmation set (often combined with Electronics or Firmware).
PR/Documentarian: weekly short video, photos, captions, YouTube uploads (often combined with Lead/BOM).

Timeline & Submissions

Project window: Mon, Oct 27 $\rightarrow$ Wed, Dec 10 (Demo Day / final exam block, 3 hours).
Weekly in-person build: All teams must be in Small 230 for project work.
Labs: Wednesday/Thursday labs as usual. For extra time, coordinate with a TA so the lab can be opened.

Weekly Expectations (every week)

In-person build: show up, work as a team, and check in with a TA.
Document your work: take photos and a short video clip ( ${<}60$ s) each week showing what changed (hardware, code, tests). Keep your README.md current and commit meaningful messages.
Peer evaluation: complete the anonymous peer evaluation sent each Monday (required individually).
Weekly Report (due Mondays, 2:00 PM; submit to Gradescope by the Team Lead) as a group submission:

5–10 sentence progress summary (what shipped, what’s blocked).
3+ photos and short video (s) link QR code (team YouTube channel).
Git links: latest commit hash + branch for firmware/electronics docs. Add rxyan2@wm.edu as a team member during setup.
Updated task table (task, owner, status, next step); unassigned tasks receive 0 credit.
BOM delta (new items, quantities, vendor links), ETA/lead times, and any non-standard vendor justifications pending TA approval.
Risk log (top 3 risks + mitigation) and upcoming test(s) for the week.

Project Proposal — Due Mon, Nov 3, 5:00 PM

Submit one PDF to Gradescope (by the Team Lead) and email the BOM to Kate (cc Jasmine). Include:

Project title & product name (concise; optional tagline).
Defined primary user group (not “everyone”)(e.g., young kitds learning kindness, stressed students pre-exam, couples seeking calm).
Team roster & roles/hats: list each member’s primary and secondary roles (Project Lead & BOM, Electronics Lead, Firmware Lead, Test & UX, PR/Documentarian). Make ownership explicit.
Concept overview: what you will build and why; which minimum requirements you will meet; any planned stretch goals.
Input modality & features: what the user does (voice/light/touch/gesture/breath, etc), which features you will extract, and how you’ll seed pseudo-randomness (same input $\rightarrow$ same outcome).
Input $\rightarrow$ motion mapping (both rotors): how features determine direction (CW/CCW), speed profile, and rotation counts for inner and outer rotors (include limits/smoothing).
UI/UX & affirmation plan: start/stop flow, indicators, and at least 6 positive, mindfulness-aligned messages; specify medium (text, light pattern, chime/audio) and mapping from the user seed.
Evidence plan: what will be logged and shown to the user (features $\rightarrow$ seed $\rightarrow$ (dir/speed/counts) per rotor $\rightarrow$ message); include a sample CSV schema.
Motion/control & safety
BOM v0.1 (email to Kate; cc Jasmine): vendor, part #, link, qty, unit cost, subtotal, lead time/ETA; justify any non-standard vendors.
Repos & channels: GitHub team repo URL (public or shared), team YouTube channel URL for weekly clips.
Project timeline with owners: week-by-week table or Gantt (task, owner, definition of done, due date). “We all did it” earns no points—each task must name an owner.
Top risks & mitigations: with concrete fallback steps.

Demo Day — Wed, Dec 10

Live demo, 8-minute talk + 4-minute Q&A. Slide template and exact format will be released separately.

Final Documentation — Mon, Dec 15, 11:59 PM

User’s Manual (for a non-expert operator) $+$ Technical Appendix (final BOM, wiring/power diagrams, control loop design & tuning, calibration, test results, limitations, future work) $+$ repo tag v1.0.

Notes

Project Proposal and BOM Due (submit to Gradescope): November 3, 2025, 5:00 PM
Final Project Demo (in person presentation): December 10, 2025, during final exam period
Final Documentation Due (submit to Gradescope): December 15, 2025, 2:00 PM

Version 1.0 Last updated: 2025

This document is a working draft and may be updated for clarity, safety, or logistics. Any revisions will be announced in class and posted to the Blackboard.