Building a Device Is the Easy Half · Lodovico Cortelazzo

0.54 m/s.

That is the number on the screen after a heavy squat. It looks precise. Two decimal places, units and all. You rack the bar, glance at your phone, and decide whether to add weight or stop the set.

I trained with commercial VBT sensors for years. Every time I looked at that number, the same questions came up. Where does it actually come from? How accurate is it? And if it’s not always accurate, how do I know when to trust it and when not to?

Nobody gave me an answer. The device measured, the app displayed, and whatever happened in between was a black box.

So I opened the box. Then I built my own.

This is the story of ODKI, an open velocity-based training sensor. Not an article about firmware, though there is some firmware in it. It is about the decisions behind a product: what to build, what to leave out, what to give away, and what I am still learning.

Why an IMU, and why that was the easy part

There are two main ways to measure bar velocity. Linear position transducers use a cable attached to the bar and measure how far and how fast it moves. Inertial sensors sit on the bar and measure acceleration and rotation.

I chose the IMU. Not because it is the best technique on paper — cable devices are generally the reference — but because the hardware is simple. No moving parts, no cable, no spring mechanism. A microcontroller, a sensor, a battery, a few magnets.

That simplicity is exactly what makes it interesting. When the hardware is easy, all of the difficulty moves into the algorithm. Anyone can glue an accelerometer to a barbell. The challenge is making the numbers mean something.

And IMU sensors have limits. I found them the hard way.

The squat session that broke the numbers

If you want to know how a sensor behaves, use it. A lot. So I did squats. Set after set, rep after rep, watching the numbers.

At first, everything looked fine. Then I noticed: the longer the session went on, the less accurate the data became. Not suddenly. Gradually. Rep after rep, the numbers drifted away from reality.

This is the fundamental problem of every IMU. To get velocity, you integrate acceleration over time. Any small error in the acceleration, from sensor bias, noise, or an imperfect orientation estimate, gets integrated too. Integrated errors don’t cancel. They accumulate.

The classic fix is to force the velocity back to zero whenever the sensor thinks the bar is still. It works, until it doesn’t. When stillness is detected at the wrong moment, the reset creates a jump in the signal. You swap one error for another and hide it behind a clean-looking number.

So I made a decision that shaped the whole firmware: velocity is never force-reset. Instead, the moments when the bar is truly still are used to measure the drift. Once the drift is known, it is removed retroactively from the rep that just happened. More complex. Adds a small delay before the final number is ready. But the number you see is corrected, not patched.

That still didn’t fully answer my original question. No algorithm is perfect, and pretending otherwise is exactly what made me distrust the devices I used before. So every rep ODKI reports comes with a quality score: a measure of how clean the data behind it was. The sensor doesn’t just give you a number. It tells you how much that number deserves your trust.

That is the answer I was looking for when I started. It took building the whole thing to get there.

ODKI app showing velocity per rep and quality score across a set.

Publishing everything

ODKI’s algorithm is documented stage by stage. The Bluetooth protocol is public domain, so any app can talk to the sensor. The firmware and the hardware design are available for anyone to read and build.

People ask if I’m afraid of being copied. I never had doubts about this.

Fear of being copied limits development far more than copying ever would. It makes you slower, more secretive, more defensive. You spend energy protecting ideas instead of improving them.

There was a second reason. A sensor on a barbell looks like a simple object. A small box with a light on it. Publishing the algorithm was the clearest way to show how much engineering sits behind something that looks this simple. You don’t have to take my word for it. You can read it.

One line I did draw: the project is source-available, not fully open source. Students, makers, and enthusiasts can build their own for free or buy one at a reasonable price. What I didn’t want is a company taking the work and selling it. Openness for the people who learn from it, yes. A free R&D department for someone else’s product line, no.

A price built for two people

ODKI costs €129, case included. That number came from a calculation: materials plus the time it takes to build one.

Which led to a design principle I didn’t expect to matter so much. During the design phase, I kept looking for the solution that would let me build a unit in the least time, with the least effort. Fewer parts. Fewer steps. Nothing fiddly.

It turns out this helps two people at once. It helps me, because assembly time is cost. And it helps anyone who wants to build their own at home: fewer parts and fewer steps means someone with no background in electronics can follow the process without getting lost. The magnetic mount is a good example: three magnets, no straps, no clips. Seconds to attach to the bar.

Designing for the user is standard advice. Designing for the person who has to build it at 11pm is less common. It pays off.

What I chose not to build yet

This is the part that rarely makes it into project write-ups.

ODKI does not recognise your movement technique. It cannot tell a good squat from a bad one. The app has no database, no long-term data management, no processing of training history. These are features I want. They are all on the roadmap.

But not now.

Right now I am focused on one thing: the algorithm that tracks the phases of a lift. When the rep starts, when the bar changes direction, when it ends. Everything else builds on top of that. If phase detection is wrong, technique recognition will be wrong too. A beautiful database will just store wrong numbers very neatly.

It’s tempting to add features. Every one of them makes a demo look better. A product with ten half-working features is worse than a product with three that work. So for now, ODKI does the essentials and does them properly.

The same logic drove the app. I started on Android, because native Android development was the most straightforward path for me. Then I moved to Flutter, so there is one codebase for both Android and iOS. The iOS app is in testing now.

What testers are teaching me

ODKI is in testing with real users. This is where the project became genuinely humbling.

The feedback is never about the things I spent the most time on. Nobody has commented on the drift correction. People talk about the interface, and about what they want it to do.

One recent request: a velocity threshold. Set a minimum bar speed, and when your reps drop below it, the app tells you to stop the set. It’s a core idea in velocity-based training, and it came from a user, not from me. That’s exactly why you put a product in other people’s hands.

Testing has also shown me where the algorithm still fails. The clearest case: when the bar is dropped to the floor at the end of a deadlift. The impact confuses the rep detection, because the firmware doesn’t yet filter out a shock of that kind. In my own squat sessions I would never have found it. Real users lift differently from how you imagine they lift.

The real reason this project exists

I know how to build a product. Give me a problem and I’ll get to a working device. What I have much less experience with is everything that comes after: pricing it, positioning it, deciding who it is for, deciding what to say no to, listening to users who care about completely different things than you do.

ODKI is how I’m learning that part. The sensor was the easy half.

Where this goes next

The firmware now answers the question I started with. You can see where the number comes from, and you can see how much to trust it.

The next questions don’t have a datasheet. Who needs this most? What will they pay for? Which features on the roadmap actually matter, and which ones only look good in a demo?

I don’t have those answers yet. But the fastest way to find them is the same as with the squats: use it, measure it, and don’t hide the parts that don’t work.

The sensor, the algorithm, and everything behind both are at odki.tech.