Good-GYM: rep counting on a webcam with RTMPose, and an argument against your GPU

Dropping YOLO made the pipeline simpler, and the project says so

The most consequential change in the changelog is a removal, and it is dated 2025-06-07. Good-GYM dropped its YOLO models and all GPU support, moved to RTMPose alone for pose detection, added CPU runtime support, and is described as more compatible and easier to use as a result.

That direction has been kept. A later entry, 2026-03-04, added optional GPU acceleration for NVIDIA cards, so GPU support came back, but as an opt-in extra rather than as the default. The current state is one pose model, RTMPose, running on the CPU by default.

The stated reason for the CPU preference is quantitative rather than ideological. The RTMPose model in the project is small, and a real-time webcam loop also includes image capture, resizing, skeleton drawing, and interface refresh, so the inference is not the whole cost of a frame. On top of that, CUDA data transfer and scheduling overhead can make GPU inference slower than CPU inference for a pipeline this shape.

For a user that means the requirements list is short: Python 3.9, a webcam, and Windows, Mac, or Linux. The feature list names a PyQt5 interface and standard webcams with no special hardware required, and one of the listed properties is that it runs locally with full privacy, which for a webcam-based tool is the feature people usually care about most.

The GPU path exists, costs three gigabytes of disk, and is documented as a comparison tool

The optional acceleration route is described precisely enough to be useful, and precisely enough that the project clearly does not expect most people to take it.

The mechanics are a swap of the ONNX Runtime build. You uninstall the CPU package and install the GPU one, then add the CUDA runtime libraries through pip so that no manual CUDA Toolkit install is needed:

# 1. Replace onnxruntime with the GPU version
pip uninstall onnxruntime
pip install onnxruntime-gpu

# 2. Install CUDA runtime libraries through pip (no manual CUDA Toolkit install required)
pip install nvidia-cudnn-cu12 nvidia-cublas-cu12 nvidia-cuda-runtime-cu12 nvidia-cufft-cu12 nvidia-curand-cu12 nvidia-cusolver-cu12 nvidia-cusparse-cu12 nvidia-cuda-nvrtc-cu12

The resource numbers are given as two separate figures, and the distinction matters. The CUDA runtime packages take about 3 GB of disk space, while model inference itself needs about 500 MB of VRAM, so the documented bar is any NVIDIA card with 2 GB or more.

Two activation details are stated. The GPU Acceleration switch in the control panel only becomes available when CUDA is detected, and it is never enabled automatically, so a user who installs all of the above still has to turn it on. And the packaged executable is CPU only: GPU acceleration is available only when running from source.

That last constraint decides which install route a GPU user needs, and the project describes the GPU mode as mainly useful for your own testing and comparison rather than as a configuration you would run day to day.

Asynchronous pose detection was tried, and reverted for accuracy

The 2025-11-14 entry records a change that was undone, which is more informative than the changes that stuck. The project reverted to synchronous pose detection because asynchronous detection caused accuracy issues, and in the same entry it fixed a crash when switching from the statistics view back to the detection view.

Accuracy beat throughput here. Running detection asynchronously would let the interface stay responsive while a frame was being processed, which is the obvious win for a real-time webcam application. It also introduces a timing question: how stale is the pose you are counting against, and does that staleness shift an angle crossing enough to double count or miss a rep. For a counter whose entire output is a threshold crossing, that is a real accuracy cost rather than a cosmetic one.

The crash fix in the same entry points at the same structure. A statistics view and a detection view over one pipeline is a state machine, and a mode switch in a PyQt application is where a retained reference or an uninitialised buffer tends to surface.

The surrounding entries follow the same pattern of narrow, specific work. The 2025-06-12 entry optimised the exercise counter module, improved counting accuracy, and cleaned up the code structure. The 2026-06-29 entry optimised the desktop interface and the video streaming logic. These are the kinds of changes that only appear once a project is in use by people other than its author.

Every exercise is six fields in a JSON file, keyed to COCO 17 keypoints

Adding an exercise does not mean writing code. Since 2025-11-15 all exercise configurations live in `data/exercises.json`, and the point of that change is stated plainly: custom exercise types can be added or edited without changing code.

The schema is small enough to read in full. Each entry carries a Chinese and an English name, a `down_angle` and an `up_angle` as thresholds in degrees, a left and right triple of keypoint indices used to compute those angles, an `is_leg_exercise` boolean that affects counting logic, and an `angle_point` triple used to draw the angle lines on the video. A worked example uses 120 and 170 degrees with left keypoints 5, 7, 9 and right keypoints 6, 8, 10.

The indices are the COCO 17 keypoint format, and the documentation prints the layout as an ASCII figure numbered 0 to 16, starting at the nose and running down the shoulders, elbows, wrists, hips, knees, and ankles. Anyone adding a movement therefore has to know which body joints define its angle, and the figure is there to make that lookup possible without reading the detector's source.

The built-in set covers squats, push-ups, sit-ups, and dumbbell movements among others. The two angle thresholds plus the leg flag is a small state machine: count a rep when the joint angle passes below one threshold and back above the other. That is why motion accuracy recognition needed a separate feature on the project's list, since a threshold pair can tell you a rep happened without telling you the rep was well formed.

The phone app is positioned as the better product, not the companion

The download section leads with the iOS app and says why, which is an unusual thing for a desktop-first project to do. The stated case is that using a phone is more convenient, that the mobile version has more features, that it has voice prompts, and that the interface is more user friendly.

The comparison is not close by that account. The desktop build is a PyQt5 application driven by `run.py`, the mobile version is a native app, and the project is telling you that the latter has the larger feature set. The most recent entries line up with that: mobile support was added on 2026-03-28, and the desktop work since then has been interface and streaming optimisation rather than new capability.

Two further items are open on the project's own checklist. Motion correction prompts are unchecked, and voice interaction control is unchecked. The second is interesting given that the mobile app is described as already having voice prompts, which suggests voice on the desktop is a separate control feature rather than the same thing.

The six completed checklist items are a useful summary of scope: multi-language interface, improved pose detection accuracy, more exercise types, custom exercise templates, motion accuracy recognition, and mobile app support. So a user arriving today gets all of those, and the two things they do not get are the ones that would require understanding whether a movement was performed correctly.

Two install routes, and one PowerShell script behind the portable build

There is a route for people who do not want to configure Python, and a route for people who want to modify the project. The first is a packaged Windows executable, `Good-GYM-Portable.zip`, published on the GitHub releases page on 2026-07-02, which is also the date of the single release tag v0.1.0 and of the last push to the repository.

The second is the source route, and it is a standard virtual environment setup:

git clone https://github.com/yo-WASSUP/Good-GYM.git
cd Good-GYM

# Create a virtual environment
python -m venv venv
# Activate on Windows
.\venv\Scripts\activate
# Or on Mac/Linux
source venv/bin/activate

# Install dependencies
pip install -r requirements.txt

Then `python run.py` starts it. The requirements file is nine packages, and one of them carries a comment that carries the GPU decision again: `onnxruntime>=1.10.0` is marked CPU only, with a note that the GPU build is installed separately. The rest are OpenCV, PyQt5, numpy, rtmlib which is the pose library, tqdm, pyinstaller, Pillow, and requests.

The portable build is reproducible rather than hand assembled, which is the point of the last changelog entry. A `build_portable.ps1` script was added on the same date as the release, so the zip is something you can regenerate with one command on Windows. That is a PowerShell script rather than a shell script, which reflects where the packaging target is.

The source layout matches the responsibilities: `app/`, `core/`, and `ui/` for the application layers, `models/` for the pose model, `data/` for the exercise definitions, `assets/`, and the exercise counter module at the top level. The project ships an English and a Chinese README.

Editorial conclusion

This suits someone with a laptop and a webcam who wants repetition counting and skeleton feedback without an account, a subscription, or a GPU, and who is willing to accept that the counting logic is angle thresholds rather than pose classification. It is a poor fit if you need form correction, since motion correction prompts are still unchecked on the project's own list, and a poor fit if you want the GPU path, which exists but is only reachable when running from source. Before you install, check three things: which surface you want, since the project positions the iOS app as the more convenient option with more features than the desktop build; whether you need custom exercises, which means editing `data/exercises.json` and mapping COCO 17 keypoint indices rather than writing code; and that the packaged Windows executable is CPU only, so a GPU user has to run from a source checkout. There is one release, v0.1.0 from 2026-07-02, and the last push carries the same date.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. yo-WASSUP/Good-GYM on GitHub