Progress this week
This 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 costs
Our 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 mitigation
- Hardware: 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 steps
Parts 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 considerations
Part A: Public health, safety, or welfare
Written 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 factors
Written 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 factors
Written 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.