Around January of this year, my friend Ben approached me about working on a project he’d been thinking about for awhile - a web application that would allow a user to track their barbell in lift using computer vision in order for new and intermediate lifters to get “objective advice” on their form. Particularly for people new to powerlifting, it’s very intimidating to ask other, obviously experienced people how to pick something up and put it down. If we could provide them a way to more safely evaluate their progress on their own it would reduce injury and keep newbies motivated.
The basic idea was simple and Ben already had a prototype. Using the OpenCV python package, we determined we would use the Hough Circle Detection to find the plate attached to the barbell. Once found, we simply had to go frame by frame and track the movement of the bar by seeing what direction the center of the plate had moved to get an understanding of how straight the line was. For all meatheads reading, forgive me for oversimpifying, but the closer the bar movement is to a straight line the higher quality the lift was. So we could measure quality of the lift by “straightness” of the bar path, and give basic diagnostic recommendations if someone were to err too much on any particular part of the lift. Simple stuff like “the bottom of your squat seems off because your hips are too tight”.
While that was easy enough to say, implementation was bound to be more complex. While Ben already had a hough tracking algorithm and a video it tracked effectively, we ignored a lot of edge cases in this idea for an application and dived in headfirst to work on it. How would videos be coming to us? What file format would we expect users to be submitting videos to us? What constraints would we place on the videos we’d try to track? One rep and the video stops? How do we know if a rep starts? There were plenty of hard questions that needed answering.
Instead we started with comparatively easy stuff. Flask or Django? MySQL or Mongo? React or Angular? These were questions we could answer pretty quickly. In fact, we committed to them before we really had any idea what our project would end up being. The idea was to get a minimum viable product as soon as possible - so we could start serving this application to users and seeing what they liked and what they didn’t. The end of this story was me accepting that was the right move to make but I definitely started with reservations.
I wanted to dive down into the computer vision of the problem - figure out how to track the bar, make the tracking more sophisticated, determine how to measure the quality and generally make our basic Hough algorithm smarter. I like algorithmic stuff like that, and having some machine learning experience I wanted to see if I could build a classifier to recognize which lift was being tracked. What was the point of building this whole web application around a product that didn’t work? Like most developers I wanted to do the stuff I thought was “cool” first.
Ben and our academic advisor on the other hand wanted us to get something built. Something we could show and people could use, even if the tracking portion was basic and dumb, it’d be a better experience than making a couple of really smart scripts that worked beautifully that absolutely nobody could use.
The truth is that it’s important to get small wins in the development of a project. Early on, development is quick and easy. Even if you’ve never made a registration page before, there are a million tutorials telling you how to do that. If you’ve never developed your own O-auth access to allow people to login with Google, there’s a lot of great resources available. That code gets written, it’s done, and it works. Each time a new one of these quick features is added, morale is boosted. The inspiration for an exciting new project can die out if you don’t see frequent progress and inspiration is a non-renewable resource. The smart move is using that inspiration to get started, because that’s always the hardest part.
As of last week, we finished all the basic parts of the application: database is plugged in with schema established, Login and registration work fine and the dashboard that makes up the UI is in place and functional. In fact, you can even upload videos! You know what it doesn’t do yet?
It still feels like a win though. Because we kept the development modular, the ability to plug in a tracking algorithm is a relatively straightforward thing. We can experiment with what works and what doesn’t while still being able to look at a finished product at the end of the day. We’re not slaving away at something that we can’t see. This is the hard part - the part where we try to create something all our own that no one’s made before. This is where Ben and I can’t just google the next step. It’s going to be a very difficult project and progress is likely to be pretty slow - but we’ve got something to look at and something to iterate on.
The lesson here is to move as quickly as possible from talking about abstract concepts and ideas and work on something now. Building something will always be more valuable than talking about it, and seeing that progress - even if it didn’t come from solving the “hard” problems - will motivate you when things get more frustrating. It’s a strategy I hope to apply to all my future projects.
If you want to see where it goes, check out Trackr on Github or check in to see new features over at trackr.ncf.space. I think having it live now is enough to guilt Ben and I into making the application worth using.