Progress this week
This week we worked through the design report feedback and began moving our workflows onto the Jetson Orin Nano. Each of us revised our part of the design to make system behavior and testing procedures clearer, and to separate measured
Harry got the squat-rack workflow running on the Jetson with recorded video. It reached the same accuracy as on the laptop, so it is the first of our workflows to run end to end on our intended hardware. Jerry continued improving the bench workflow, focusing on camera-view alignment and matching plates to the correct working bar. On the evaluated footage, his changes resolved 9 loading decisions that the bench workflow previously could not decide, without adding any incorrect ones. He also looked at cutting unnecessary rack model calls and began preparing model dependencies for the Jetson. Alan set up the treadmill pose model on the Jetson, revised the treadmill behavior based on the feedback, and explored ways to reduce update delay. Alan and Jerry also tested difficult treadmill views together.
We have not yet run all three workflows together on one Jetson or completed a live camera-to-tablet test.
Risks and responses
Running all three workflows on one Jetson is still our largest technical risk. Harry’s offline run shows that at least one workflow keeps its accuracy on the board, but we still have no measurements of memory, latency, or throughput, either for each workflow alone or for all three together. Next week each of us will profile our own workflow on the Jetson, and then we will run all three together. If the combined workload misses our update targets, these are our backup plans:
- Check each station less often, or stagger the checks so the stations take turns.
- Use lower input resolution or frame skipping. Alan is already testing these for the treadmill.
- Reduce model calls where possible. Jerry is already doing this for the rack.
- Switch to smaller or optimized models if the steps above are not enough.
Bench accuracy is still the weakest of the three checks. The recent improvements are limited to the footage we evaluated and do not show general reliability yet. Jerry will test them on more views and harder plate configurations next week. If bench accuracy stays low, we will have the bench check return unknown more often rather than give wrong answers, because incorrect alerts cost users more than unknown readings.
Live camera behavior is a new risk now that we are on hardware. Processing could fall behind incoming frames, which would make statuses stale. We will measure this directly in the live tests.
We still need longer recordings and more footage set aside for final evaluation, especially for the five-minute unattended wait on the rack. Confirmation for recording at the UC gym is still pending, so for now we are relying on the apartment gym.
Design changes
We did not make a major change to the system design this week. The feedback revisions made the requirements and testing procedures more specific without changing the block diagram or system spec. The update-delay and model-call reductions are still being tested locally. If we adopt any of them, we will report the change and its accuracy cost once we have Jetson measurements.
Schedule
Moving to hardware is behind our earlier plan. The design report revisions took time this week, and only the rack workflow has run on the Jetson so far. Our updated near-term schedule:
- Week of October 26: run each workflow on the Jetson with recorded footage and then a live camera, and measure memory, latency, and throughput for each.
- Week of November 2: run all three workflows together on one Jetson, measure combined performance, and apply the backup plans above if needed.
- After that: complete the live camera-to-tablet path for the interim demo.