Hanning’s Status Report for October 25

What I did this week: I merged our previously separate modules into a single, working page so that Joyce’s and Yilei’s parts could run together. Specifically, I unified camera_setup.html, fingertip_detection.html, and the calibration app.js from index0927.html (yilei’s calibration file) into one loop: a shared camera pipeline (device picker, mirrored preview, hidden frame buffer for pixel ops) feeds both fingertip detection and calibration; the F/J calibration computes a keyboard quad (variable-width rows, height/top-bottom shaping), and I render the QWERTY overlay on the same canvas. I added a method switcher for fingertip sourcing (M1 landmark tip, M2 projection, M5 gradient with threshold/extension knobs), normalized coordinates so preview can remain mirrored while detection/overlay run in un-mirrored pixel space, and exposed simple text I/O hooks (insertText/pressKey) so detected points can drive keystrokes. I also cleaned up merge artifacts, centralized the run loop and status controls (live/landmarks/black screen), and kept the 10-second “freeze on stable F/J” behavior for predictable calibration. I’m on schedule this week.

What I plan to do next week: I’ll pair with Joyce to fold her fingertip detector into this pipeline, add basic stabilization/debounce, and wire tip contacts to the keystroke path (tap FSM, modifiers, and key labeling). The goal is to land end-to-end typing from fingertip events and begin measuring latency/accuracy against our targets.

Yilei’s Status Report for October 25

This week, I added layout controls (live sliders for overall keyboard height and the top-to-bottom row ratio with a reset to the default settings). I also implemented per-finger key tracking with on-screen annotations: each fingertip (thumb through pinky) is mapped to the key it’s over in the Mac layout, and the active key label is rendered at the fingertip.

I am on schedule. The main integration challenge is aligning coordinate frames and timestamps with Joyce’s tap decision output.

Next week, I will tune the relative horizontal positions to match a Mac keyboard more precisely (I tried typing a word and the layout still felt slightly off). I will also add a small tap-testing utility for my component: on-screen buttons for each finger that, when clicked, simulate a tap and emit the key associated with the video frame at the click timestamp. My goal is to start integrating this path with Joyce’s detected taps by the end of next week. Now that the HTML build runs on our phones, several details render differently, I will fix those in the following week.

Joyce’s Status Report for October 25

What I did this week

This week, I successfully resolved critical stability issues in fingertip tracking by replacing the Interest Box and Centroid Method with the highly effective Gradient-Based Tip Detection. The previous method, which relied on calculating a pixel centroid after applying a single color threshold within an ROI, proved unstable, especially when faced with varying lighting or white backgrounds, requiring constant manual tuning. The new method overcomes this by using a projection vector to actively search for the sharp color gradient (boundary) between the finger and the surface, utilizing both RGB and HSL data for enhanced sensitivity. I also started on the tap detection logic, although it still requires significant tuning and method testing to be reliable.

Scheduling

I am currently behind schedule. The time spent troubleshooting and implementing the new Gradient-Based detection method due to the previous method’s instability caused a delay. To catch up, I will compress the timeline for the remaining Tap Detection work. I will also collaborate closely with my teammates during the testing phase to ensure the overall project schedule stays on track.

What I plan to do next week

Next week’s focus is on finishing the basic tap detection logic to enable reliable keypress registration. Following this, my key priorities are to collaborate with my teammates for integrated testing of the full pipeline (from detection to output) and to produce a stable, functional demo version of the application.

Team’s Status Report for October 25

Most Significant Risks and Management
The primary project risk was that the HTML/JavaScript web app might not run on mobile devices due to camera access restrictions—mobile browsers require a secure (HTTPS) context for getUserMedia. This could have blocked essential testing for calibration, overlay alignment, and latency on real devices. The team mitigated this risk by deploying the app to GitHub Pages (which provides automatic HTTPS), converting all asset links to relative paths, and adding a user-triggered “Start” button to request camera permissions. The solution was verified to load securely via https:// and successfully initialize the mobile camera stream.

Changes to System Design
The system has transitioned to a Gradient-Based Tip Detection method, addressing the core limitations of the previous Interest Box and Centroid Method. The earlier approach calculated the contact point by finding the pixel centroid within a fixed Region of Interest (ROI) after applying a single color threshold. While effective in controlled conditions—especially with stable lighting and a dark background—its performance degraded significantly under variable lighting or background changes. This dependency on a fixed threshold required constant manual tuning or complex adaptive algorithms. The new method overcomes these issues by projecting a search vector and detecting sharp color gradients between the fingertip and surface using a robust combination of RGB and HSL data. Although initially explored, the method’s improved calculation of color transitions now makes it more consistent and reliable. By focusing on the physical edge contrast, it achieves stable fingertip contact detection across diverse environments, enhancing both accuracy and practicality.

Updated Schedule
Joyce has spent additional time refining the fingertip detection algorithm after finding that the previous method was unstable under certain lighting and background conditions. Consequently, she plans to compress Task 4 (Tap Detection) into a shorter period and may request assistance from teammates for testing to ensure that project milestones remain on schedule.

 

Team’s Status Report for October 18

Most Significant Risks and Management

The primary risk identified was Fingertip Positional Accuracy, specifically along the keyboard’s depth (Z-axis). Previous geometric methods yielded significant positional errors, which threatened the system’s ability to distinguish between adjacent keys (e.g., confusing Q, A, or Z) and thus made reliable typing impossible. To manage this risk, our contingency plan was the rapid implementation of the Pixel Centroid Method. This technique calculates the statistically stable Center of Mass (Centroid) of the actual finger pixels, providing a highly stable point of contact that successfully mitigates the positional ambiguity risk.

Changes to System Design

A necessary change was introduced to the Fingertip Tracking Module design. We transitioned from geometric projection methods to an Image Processing Refinement Pipeline (the Pixel Centroid Method). This was required because the original methods lacked the vertical accuracy needed for key mapping. The cost was one additional week of time, but this is mitigated by the substantial increase in tracking stability and accuracy, preventing major integration costs down the line.

Updated Schedule

No significant changes have occurred to the overall project schedule.

Part A global factors
Across developing regions, many users rely primarily on smartphones or tablets as their only computing devices, yet struggle with slow or error-prone touchscreen typing due to small screen sizes or limited literacy in digital interfaces. By using the built-in camera and no additional hardware, our system provides a universally deployable typing interface that can work on any flat surface. It’s more practical for students, remote workers, and multilingual users worldwide. For instance, an English learner in rural India could practice typing essays on a table without needing a Bluetooth keyboard, or a freelance translator in South America could work comfortably on a tablet during travel. Because all computation happens locally on-device, the system can function without internet access, which is essential for regions with limited connectivity, while also ensuring user privacy. This design supports equitable access to digital productivity tools and aligns with sustainable technology trends by reducing electronic waste and dependence on specialized hardware.

Part B cultural factors
HoloKeys is designed to fit how people learn and use technology in classrooms, libraries, community centers, and travel settings. Because QWERTY is the most widely used layout, the interface aligns with familiar motor patterns and reduces training time. Instructions and tutorials are written in plain, idiom-free text that can be easily translated into other languages. Visual overlays are adjustable (font size, key size, contrast), allowing users to tune the interface to their needs. Because expectations around camera use vary, HoloKeys defaults to privacy-forward behavior: clear camera active indicators, no recording or image retention by default, and concise explanations of how and why the camera is used.

Part C environmental factors
Unlike traditional hardware keyboards, our solution requires minimal physical manufacturing, shipping, or disposal, thereby reducing material waste and overall carbon footprint. The system relies primarily on existing mobile devices, with only a small stand or holder as an optional accessory. This holder can also serve as a regular phone or tablet stand, further extending its lifespan and utility. By minimizing the need for new electronic components and leveraging devices users already own, our design helps reduce electronic waste and promotes more sustainable technology practices.

Part A was written by Hanning Wu, part B was written by Yilei Huang and part C was written by Joyce Zhu.

Hanning’s Status Report for October 18

This week I added a calibration instructor and a small finite-state machine (FSM) to the camera webpage. The FSM explicitly manages idle → calibrating → typing: when a handsDetected hook flips true, the UI enters calibrating for 10 s (driven by performance.now() inside requestAnimationFrame) and shows a banner with a live progress bar; on timeout it transitions to typing, where we’ll lock the keyboard pose. The module exposes setHandPresence(bool) for the real detector, is resilient to brief hand-detection dropouts, and keeps preview mirroring separate from processing so saved frames aren’t flipped. I also wired lifecycle guards (visibilitychange/pagehide) so tracks stop cleanly, and left stubs to bind the final homography commit at the typing entry.

I’m on schedule. Next week, I’ll integrate this web framework with Yilei’s calibration process: replace the simulated handsDetected with the real signal, feed Yilei’s pose/plane output into the FSM’s “commit” step to fix the keyboard layout, and run end-to-end tests on mobile over HTTPS (ngrok/Cloudflare Tunnel) to verify the calibration→typing flow works in the field.

current webpage view:

Yilei’s Status Report for October 18

This week, I added all the remaining keys and organized them to resemble a Mac keyboard. I expanded the layout to include the full number row, punctuation, Return, Shift, Delete, Space, arrows, and the Mac modifiers.

Although I didn’t finish as much as I had hoped (I also intended to add a feature to adjust the keyboard’s vertical scale (height)), I am still roughly on schedule. The calibration and overlay are functionally complete enough that I can wrap those controls next week without slipping the overall plan. To stay on track, I’ll start with a basic scaling slider and polish it after integration.

Next week I hope to add a slider to adjust the keyboard height and another to adjust the top-bottom ratio. In parallel, I’ll start working on the tap-decision logic and outline a testing plan for my tap-decision component by itself. The goal is to validate my decision module independently, then integrate with the actual tap-detection signals that my teammate is building toward the end of week 7.

 

Joyce’s Status Report for October 18

 What I did this week:

This week, I successfully resolved critical stability issues in fingertip tracking by implementing a new and highly effective technique: Pixel Centroid analysis. This robust solution moves beyond relying on a single, unstable MediaPipe landmark. It works by isolating the fingertip area in the video frame, applying a grayscale threshold to identify the finger’s precise contour, and then calculating the statistically stable Center of Mass (Centroid) as the final contact point. This system, demonstrated in our multi-method testing environment, includes a crucial fallback mechanism to the previous proportional projection method, completing the core task of establishing reliable, high-precision fingertip tracking.

Scheduling:

I am currently on schedule. The stability provided by the Pixel Centroid method has successfully mitigated the primary technical risk related to keypress accuracy.

What I plan to do next week:

Next week’s focus is on Task 4.1: Tap Detection Logic. I will implement the core logic for detecting a keypress by analyzing the fingertip’s movement along the Z-axis (depth). This task involves setting a movement threshold, integrating necessary debouncing logic to ensure accurate single keypress events, and evaluating the results to determine if complementary tap detection methods are required.

Joyce’s Status Report for October 4

What I did this week:
This week, I worked on implementing the second fingertip tracking method for our virtual keyboard system. While our first method expand on the direct landmark detection ofMediaPipe Hands to detect fingertips, this new approach applies OpenCV.js contour and convex hull analysis to identify fingertip points based on curvature and filtering. This method aims to improve robustness under varied lighting and situations when the color of the surface is similar to skin color. The implementation is mostly complete, but more testing, filter coding and parameter tuning are needed before comparing it fully with the MediaPipe approach.

Scheduling:
I am slightly behind schedule because fingertip detection has taken longer than expected. I decided to explore multiple methods to ensure reliable tracking accuracy, since fingertip detection directly impacts keypress precision. However, I plan to decrease the time spend on some minor tasks originally planed for the next few weeks, and potentially ask for help from teammates to catch up.

What I plan to do next week:
Next week, I will finish the second method, and test and compare both fingertip tracking methods to evaluate accuracy and responsiveness, then refine the better-performing one for integration into the main key detection pipeline.

Team’s Status Report for October 4

We made a design adjustment: The camera needs to sit at a different angle than originally planned. To find a suitable angle for our current gesture recognition model, we’ll first use an adjustable, angle-changeable device holder to test several angles, then commit by purchasing or fabricating a fixed-angle holder once we identify the ideal angle.
Current risk we found: Mobile devices couldn’t open the HTML directly (no real web origin, only Microsoft edge can open, but blocks the camera access)
Mitigation: We now host the page on a local server on the laptop and connect via the phone over the LAN (real origin/permissions work), with HTTPS or a tunnel available if needed.

Schedule updates: Junyu scheduled an additional week for fingertip recognition shifts out because the this task takes longer than expected since we want to test multiple different methods to ensure accuracy, and fingertip detection is curial to the accuracy of key detection. Hanning’s task for week3 and week4 switches to align with Yilei’s calibration process. Yilei reports no schedule change.

current schedule: