Jerry’s Status Report for 10/3

Accomplishments this week

This week, I moved from planning the equipment-state rules to testing a local prototype on recorded video. We divided the initial implementation by use case so each person can get one workflow working before we integrate them. I focused on the bench check, particularly whether someone is using the station and whether plates remain on the bar.

I gathered short recordings at a private gym with Harry, showing empty and occupied benches, with and without plates on the bar. I used these alongside public footage to inspect the prototype’s behavior. The tests exposed problems with camera angle, partially hidden equipment, and distinguishing plates on the bar from nearby equipment. I also developed a browser preview so I can compare the video with the system’s predictions and review mistakes more easily. These are preliminary tests, and I have not yet verified the full five-minute unattended scenario.

On the application side, I built a local path from timestamped observations to displayed station states and tested how it handles stale observations and simulated interruptions. This makes progress toward the dashboard and failure-handling work I planned last week, although integration with the other workflows remains unfinished.

I also submitted purchasing and inventory request forms for two cameras and a tripod to support live-camera testing and more consistent recording positions.

Schedule status and corrective actions

The recorded-video prototype and local display have progressed, but detection reliability and full integration still need work. Camera placement has a noticeable effect on the results, so I am prioritizing repeatable recordings and reviewing failure cases before expanding the setup. Jetson testing is still pending while Alan prepares the board. The current results are from laptop testing.

Deliverables for next week

Collect longer recordings from stable camera positions, including departure, return, and equipment-reset cases.
Improve the bench check using the errors found in the current recordings and evaluate it on separate footage.
Coordinate the observation format and displayed states with Alan and Harry.
Begin testing the camera-to-display path on the Jetson once it is ready.
Contribute the bench implementation, testing approach, and remaining risks to the design report.

Preliminary output on a private-gym recording showing an unoccupied bench with plates on the bar. This frame illustrates the prototype, not overall accuracy or a completed five-minute alert

Team Status Report for 9/26

Progress this weekThis week, we worked on the design-review presentation and went back through the professor and TA feedback from our proposal. They liked the use case, but wanted clearer reasons for our camera layout, processing approach, and quantitative requirements. We compared shared cameras with one camera per machine and worked through the cost, connections, setup, and processing needs. We also reviewed the slides against the assignment guidance and documented the questions we still need to resolve.
Our preliminary experiments covered the pretrained detector, simple image processing, equipment-state logic, inference timing, scheduling, and image transport. These used laptop measurements, generated images, public examples, and simulated inputs. They have not established performance in the UC gym or on the Jetson. The YOLO11n class list does not include weight plates, and the original state prototype exposed a case where a person lingering near a station delayed an unattended flag. We also tested equipment detection and segmentation on treadmill photos. A straight-on view gave clearer machine regions than a crowded diagonal view, but some masks included neighboring equipment. These results helped narrow what we need to test next.
We also worked on separating user requirements from subsystem requirements. The five-second treadmill target needs a budget for sampling, confirming a change, processing, and updating the dashboard. We are refining the accuracy justifications around incorrect availability and unnecessary staff trips. These are proposed budgets, not achieved response times.
Design changes and their costsOur working plan is shared cameras covering small, separate groups of machines. We are planning three selected views for the prototype, rather than claiming three cameras can cover an entire gym. More cameras could be added where clear coverage requires them. This reduces mounts, power connections, and feeds compared with one camera per machine, but we still need to confirm machine regions during setup. Keeping each machine in one camera group avoids cross-camera matching and double counting.
We used an estimated 10 treadmills, 6 squat racks, and 6 benches for the UC gym comparison. A dedicated-camera design would mean 22 camera installations. Even with inexpensive cameras, powering and connecting that many devices adds work. Shared views trade some setup and placement effort for fewer devices to maintain.
We plan to share the person/belongings detector across feeds and use separate equipment rules. We will start with PyTorch and add TensorRT only if measurements show a need. The unattended waiting period is a configurable five-minute starting point that still needs staff input and testing. For plates, we will compare simple image processing with a plate-specific method before committing to extensive training.
These changes require updates to the parts list, camera plan, timer rules, tests, and documentation. We will keep one current specification so older ten-minute settings and runtime assumptions do not conflict. The design review also delayed purchasing because the two camera approaches needed different hardware. The order is now behind, and we need to resolve it promptly.
Significant risks and mitigationHardware: The parts order is not submitted, and Jetson/camera availability is still unconfirmed. Harry will check inventory and loan options, update the parts list, and submit the missing items. Laptop work will continue while hardware is pending.
Gym access: Placement, recording, and demo approval remain open. Jerry will coordinate the request with the team. A controlled setup with consenting volunteers is our fallback.
Detection and visibility: Plates on a bar, stored plates, passersby, and blocked views can produce misleading results. Alan will test staged cases and camera angles before a larger labeling or training effort.
Incorrect flags: Jerry will test returns, passersby, brief detection errors, and stale or blocked views. Unreliable observations should produce an unknown state rather than show equipment as free. We also need to distinguish attendance at one station from someone using a neighboring station, so one person’s presence does not suppress another station’s flag.
Processing load: We have not shown that three feeds need a complex scheduler. Harry will compare simpler scheduling methods and measure update delay, memory, and gaps between equipment checks on the actual board.
Schedule and next stepsParts ordering and the recorded-feed prototype are behind the original September 25 target. The fake-data dashboard, camera-placement tests, and initial recording work also need to catch up. We have updated the schedule to keep laptop capture, vision tests, and application work moving in parallel.
The slides are due September 27. By the next report on October 3, Harry will submit the missing parts request and establish a timestamped single-feed laptop baseline, Alan will prepare an initial staged vision comparison and coverage test plan, and Jerry will build the fake-data dashboard and observation interface. The following week targets three-feed capture and board setup if equipment is available. The design report remains due October 9, with the treadmill MVP targeted for October 23. Any hardware delay will be stated clearly rather than treating laptop results as Jetson results.
Harry and Jerry will agree on station IDs, observation timestamps, and how camera failures are reported before connecting capture to the dashboard. That lets the application develop against fake observations while the capture and vision work continue.
Public health, safety, social, and economic considerationsPart A: Public health, safety, or welfareWritten by Alan Wang.
BenchGuard aims to make shared equipment easier to find and keep ready for use. Treadmill availability could save members a trip to another floor, while flags for unattended belongings or loaded bars could help staff decide where to check. We have not measured these benefits, and the system is not intended to prevent injuries or detect emergencies. Staff would inspect a flagged station before taking action.
Incorrect information can also cause problems. Showing an occupied treadmill as free wastes a member’s trip, while showing a free one as occupied hides equipment they could use. An incorrect unattended flag could lead staff to interrupt someone who is resting. A blocked or disconnected camera should therefore show unknown, and the dashboard should show how recent its information is. The waiting period gives people time to rest or briefly leave, although we still need to test whether five minutes is appropriate.
Clear equipment information may be particularly useful to members with limited time or those who find repeated trips between floors difficult. The display needs to make free, occupied, and unknown states easy to distinguish. We plan to process images locally and show equipment states rather than identifiable footage. Camera placement and recording still need facility approval and participant consent. The system would support ordinary staff checks, not replace them.
Part B: Social factorsWritten by Zhanming (Jerry) Liang.
People use gym equipment differently, and belongings do not always mean someone has finished or abandoned a station. BenchGuard would report what it observes, such as items remaining while nobody is visible, without identifying an owner or judging their behavior. Five minutes is a configurable starting point, not a gym rule. Staff would decide how to handle a flag.
This matters for people taking longer rests, sharing a rack, or working out with a partner. A person standing nearby might be a trainer or passerby rather than the station’s user. Our tests will include these cases and different rest patterns. Staff-facing wording should describe the equipment, such as “items remain at an unattended station,” rather than accuse a member of leaving a mess. The system would not automatically remove belongings, reserve equipment, or enforce gym rules.
Privacy also affects whether members are comfortable with the system. We do not plan to identify faces or track named people, and the dashboard does not need to show camera footage. Existing security cameras do not automatically give us permission to add ours or access their feeds. We need to explain where cameras point, what information is shown, and how any approved test recordings are handled. Keeping the output about equipment rather than individual behavior should reduce intrusion, but local processing alone does not remove all privacy concerns.
Part C: Economic factorsWritten by Yuehan (Harry) Hu.
BenchGuard could help staff spend less time checking already-clear stations and help members find available equipment. Those savings are not proven. Incorrect flags could create extra work, and frequent camera adjustment could cancel out the benefit. We plan to track useful and unnecessary flags, along with setup and maintenance effort, before claiming a financial return.
We will check course inventory before buying equipment. For our estimated 22 machines in the UC gym, one camera per machine would require 22 mounts, power connections, and feeds to maintain. Shared cameras reduce that installation burden, although confirming machine regions still takes time. Sharing the detector and starting with PyTorch also keeps initial deployment simpler. Course loans lower our spending, but a commercial installation would still need a computer, cameras, storage, mounts, cables, power, installation, and support.
Coverage matters as much as camera price. A cheaper, wider view is not a saving if it misses distant equipment or needs frequent correction. We will estimate cost per reliably monitored station from tested camera views, rather than assume three cameras cover the whole gym. Any estimate of staff-time savings should account for useful checks, unnecessary trips, and ongoing maintenance. We do not yet have enough evidence to claim a payback period or improved gym revenue.

Jerry’s Status Report for 9/26

Accomplishments this week

This week, I organized a review of the instructors’ proposal feedback and the evidence behind our design choices. I used research and code-review assistance to examine camera coverage, recording permission, requirement justifications, alternatives to machine learning, and how the three checks share the local computer. I then compared these findings with Alan’s new design-review material to identify the changes needed for the presentation.

For my application and integration area, the main outcome is a clearer definition of the situations our equipment rules must handle. A blocked camera should not count as a reliable absence. One missed item detection should not restart an unattended timer. Someone walking past a rack should also be distinguished from a persistent presence at that station. The original prototype documents a case where a lingering person delays a flag, which reinforces the need for explicit tests.

I also coordinated preparation of the revised presentation, feedback-response document, purchasing instructions, and weekly-report drafts. This work gives the team a consistent set of requirements and separates completed experiments from estimates and tasks that still depend on hardware or permission.

Schedule status and corrective actions

The design review and integration planning have progressed, but the application implementation needs to catch up with the earlier goal of a dashboard driven by fake data.

I will build the smallest useful application path first: read a timestamped observation, update one treadmill or station, and display the resulting state. This can be developed without waiting for cameras or the Jetson. Once that path works, I will extend it to the unattended timers and connect it to Harry’s capture pipeline.

Deliverables for next week

Agree with the team on equipment states, the configurable five-minute waiting period, and how to handle unknown or outdated observations.
Build a dashboard using fake or recorded observations, showing treadmill availability and station flags without displaying live video.
Write tests for departure, return, passersby, brief detection mistakes, item removal, and blocked or disconnected cameras.
Define the observation format and timestamps with Harry so that the capture pipeline can connect to the application.
Coordinate the recording-permission request and track its actual status.
Save a small end-to-end demonstration and document its limitations for the October 9 design report.

Jerry’s Status Report for 9/19

Accomplished

I presented our proposal on Monday, so a good part of my week went into the slides, rehearsing, and preparing answers for questions on our timing numbers and on why we use a scheduler rather than one shared model.

My technical task this week was writing out the equipment states and timer rules, which is the logic the rest of the application is built on. A treadmill is available, in use, or unknown, and a rack or bench is in use, free, or flagged. I also wrote down the rules the timers follow, including when a timer starts, that it only runs while nobody is at the station, that a person returning resets it, and how a flag clears once the station is reset. Getting this written down early matters because both the detection work and the scheduling work feed into it, so we all need to agree on what a detection is supposed to mean. A couple of open questions came out of it too, like how long someone has to be in a zone to count as returning so a person walking past does not reset the timer.

Progress

On schedule. The states and timer rules were this week’s task and they are written up.

Deliverables

Start on the dashboard, beginning with a version running on fake data so we can see the treadmill count and station flags before any real detections exist. Write tests for the timer rules using made up detection sequences. Help with the design presentation slides.