Good-GYM: an RTMPose exercise counter that runs on a CPU webcam

The problem Good-GYM takes on, and who it is actually for

Counting repetitions by hand is the part of a workout that people get wrong. You lose track during a set, you count a half rep, and the number you write down is a guess. Good-GYM attacks that narrow problem: a webcam feed goes in, a repetition count comes out, and the count is derived from a pose model rather than from a button press.

The README positions the project around real-time exercise counting, multiple exercise support (squats, push-ups, sit-ups, dumbbell movements), and a PyQt5 interface with skeleton visualization and angle measurement. It also states that everything runs locally, which matters if you do not want workout video leaving your machine.

The audience is narrower than the feature list suggests. This is a desktop tool for one person in front of one camera, not a class management system or a coaching platform. The README recommends the iOS app over the desktop build for convenience, which tells you where the maintainers think the better experience lives. The desktop Python app is the version you run when you want to read the code, change the exercise set, or avoid installing an app from the App Store.

RTMPose on CPU: the architecture after YOLO was dropped

The changelog records a deliberate simplification. On 2025-06-07 the project dropped YOLO models and all GPU support, moved to RTMPose only, and made CPU runtime the default. GPU acceleration came back later, on 2026-03-04, but as an optional path rather than the assumed one.

That ordering explains the shape of the code. The repository top level separates app/, core/, ui/, models/, and data/, with exercise_counters.py sitting at the root. Pose estimation produces keypoints in COCO 17 format, which the README documents with an index diagram covering nose, eyes, ears, shoulders, elbows, wrists, hips, knees, and ankles. Counting logic then works on angles derived from those keypoints.

The data flow is a synchronous loop. The changelog for 2025-11-14 states that asynchronous pose detection was reverted to synchronous because of accuracy issues. That is a real trade-off, and the maintainers chose correctness over throughput. If you are looking for a pipeline that decouples capture from inference, this is not it, and the project says so in its own history.

The GPU section is unusually candid. The README argues that GPU is generally not recommended because the RTMPose model is small and the pipeline also spends time on image capture, resizing, skeleton drawing, and UI refresh, so CUDA transfer and scheduling overhead may make GPU inference slower than CPU inference. It puts CUDA runtime packages at about 3 GB of disk and model inference at about 500 MB of VRAM. Those are the project's own figures, not measured benchmarks.

Installing Good-GYM from source and counting your first set

The README targets Python 3.9 and a webcam. If you do not want a Python environment at all, the project publishes a Windows portable package, Good-GYM-Portable.zip, on GitHub Releases, and build_portable.ps1 in the repository is the script used for reproducible Windows portable builds.

For source installs, the README gives this sequence. The virtual environment step is not optional in practice, because onnxruntime and PyQt5 are heavy dependencies and you do not want them in your system interpreter.

git clone https://github.com/yo-WASSUP/Good-GYM.git
cd Good-GYM
python -m venv venv
.\venv\Scripts\activate
pip install -r requirements.txt
python run.py

On macOS or Linux the activation line is source venv/bin/activate instead. requirements.txt pins opencv-python>=4.5.0, PyQt5>=5.15.0, numpy>=1.19.0, onnxruntime>=1.10.0, rtmlib, tqdm, pyinstaller>=5.0.0, Pillow>=8.0.0, and requests>=2.25.0. The onnxruntime line carries a comment noting it is CPU only and that GPU users should install onnxruntime-gpu instead.

After python run.py the README describes a PyQt5 window with a live skeleton overlay and angle measurement. The first useful thing to do is not to start counting. It is to open data/exercises.json and read the entries, because that file is where the exercise types live. The README states that all exercise configurations are managed there and that custom exercise types can be added or edited without changing code, using the COCO 17 keypoint index reference to pick the joints that define the movement. If the counter double-counts a repetition, the thresholds in that file are wrong for your camera angle.

Where Good-GYM breaks down

The most important limitation is that the project does not correct your form. The README's future development list has motion correction prompts and voice interaction control as the two unchecked items. Everything else on that list is marked done. So a user expecting the app to tell them their knee is caving inward will not get that, and the feature list should be read as counting plus visualization, not coaching.

The second limitation is camera geometry. Angle-based counting is sensitive to where the camera sits relative to the body. A squat filmed from the front and a squat filmed from the side produce different projected angles for the same physical movement, so a threshold set for one view will misfire on the other. The README does not document a calibration step, which means you are tuning data/exercises.json by trial.

Third, the packaged Windows build is CPU only. The README states this explicitly: the EXE supports CPU mode only, and GPU acceleration is available only when running from source. If your reason for wanting GPU was faster inference in a distributed binary, that path is closed.

Fourth, this is the wrong tool for anything multi-person. The counting logic is built around a single skeleton and a single exercise configuration at a time. A gym floor with several people in frame is outside what the README describes.

How Good-GYM differs from MediaPipe-based rep counters

The obvious alternative is a MediaPipe Pose based counter, which is the common shape of this kind of project: MediaPipe for landmarks, a small state machine for counting, and a web or desktop front end. The difference is in the model and the runtime story rather than in the counting idea.

Good-GYM uses RTMPose through rtmlib and onnxruntime. That combination gives it a single, explicit inference backend that you can swap for onnxruntime-gpu with two pip commands, which is why the GPU instructions are so short. A MediaPipe-based counter typically ties you to the MediaPipe runtime and its own model bundle, and swapping accelerators is not a two-line change.

The second difference is configuration surface. Good-GYM moved exercise definitions out of code and into data/exercises.json, per the 2025-11-15 changelog entry. Many comparable projects hard-code the joint triplets and angle ranges for each exercise in Python. If you want to add a movement without touching code, that file is the reason to pick this project over a typical fork.

The third difference is the packaging. Good-GYM ships a Windows portable ZIP built through build_portable.ps1, plus an iOS app on the App Store. A MediaPipe demo often stops at a Python script. That said, the README itself recommends the iOS app over the desktop build, so the desktop packaging is a fallback for people who will not or cannot install the app.

Maintenance, upgrade cost, and the MIT licence

The repository is not archived. The last push was on 2026-07-02, which is also the date of the v0.1.0 release and the Windows portable package. The changelog shows a steady stream of dated entries through 2026, with the 2026-06-29 entry covering desktop UI and video streaming logic and the 2026-07-02 entry covering the portable build script.

Upgrade cost is low but not zero. There is no plugin API and no database schema, so an upgrade is a git pull plus pip install -r requirements.txt. The thing that can break your setup is data/exercises.json, because it is your file once you edit it. A pull that changes the expected keys in that file will not merge cleanly with your custom exercises, and the README does not document a migration path for it.

Dependency churn is the other cost. onnxruntime and rtmlib both move, and the GPU instructions name eight nvidia-* packages that must stay consistent with each other and with your driver. The README does not pin versions for those, only for the core requirements.

The project is MIT licensed per the repository metadata and the LICENSE file at the top level. MIT is permissive, so redistribution and modification are broadly allowed with the licence text retained. One thing worth checking yourself rather than assuming: the iOS app is distributed through the App Store separately from the repository, and the README does not state which licence covers that binary. This is a description of what the repository says, not legal advice.

Editorial conclusion

Adopt Good-GYM if you want a local, CPU-only rep counter you can extend by editing data/exercises.json, or if you want to read a small PyQt5 plus RTMPose pipeline as a reference. Do not adopt it if you need form correction or voice feedback, both of which the README still lists as unchecked future work, or if you need a packaged GPU build, since the README states the EXE supports CPU mode only. Before committing, verify that your webcam feed produces stable COCO 17 keypoints at your camera angle, because the counting logic depends on the angle thresholds you configure per exercise, and check the LICENSE file for the MIT terms you are actually relying on.

Frequently asked questions

Official sources

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