Accomplishments this week

Much of my week went into combining and revising the design report. I worked through the architecture, state and timing rules, diagrams, schedule, and testing plan so that the report describes one consistent system. I also checked claims against the evidence we actually have, especially where laptop measurements or short clips could sound like completed Jetson or gym results.

I continued diagnosing the bench workflow on recorded and public footage. Its current 172 observation development bank has 96 correct full-state results, 47 wrong, and 29 unknown. The errors include trouble associating a person with the right bench and deciding whether plates are attached to the working bar. I tried several bounded changes and kept the failures documented instead of treating a better result on one view as a general fix.

For the report, I checked whether image subtraction could provide a simpler loaded-bar test. The existing bank lacks the sleeve regions and bare-bar references needed for a matched comparison. A separate, previously calibrated session gave promising load-only results, but its thresholds were chosen on that same session. I also timed the actual bench perception models on my laptop CPU: the median check took 325 milliseconds across 48 timed calls. That does not include the full camera-to-tablet path or tell us how fast the Jetson will run.

Schedule status

The report and bench diagnostics progressed, but bench accuracy is still below our target. We have not shown a reliable full five-minute bench event or run the workflow on the Jetson. I need to focus on the failures that affect the complete station state, then check changes on separate footage.

Deliverables for next week

• Review the remaining person-to-bench and bar-attachment errors against the recorded frames.
• Test a focused change on separate footage and keep the current baseline for comparison.
• Collect or prepare approved bare, loaded, and return scenarios, including a full unattended period.
• Agree on the shared output format and help connect the bench workflow to the tablet service.
• Run the bench workflow on the Jetson when the board setup is ready.

Posted by Harry since Jerry doesn’t have his laptop right now

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.

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.

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.