The Machine that Broke My Heart

It didn't track calories. It tracked bites. The problem we were attacking was eating awareness and frequency. It might've been possible to track food types too but we didn't get that far.

(Was it a "beep to remind you not to snack" device, rather than a calorie tracker?)

Yes.

Even a tool like this was useful enough that people repeatedly and independently, on their own initiative, asked us to build it for them. They were all from the same demographic: women, often stay-at-home, between the ages of 30 and 50. Their problem, as they saw it, wasn't eating calorie-dense food. It was frequent unconscious snacking.

I read it as "beep to remind you to log what you're eating".

Your description of the invention is precisely correct. Cross posting on the EA forum is a good idea.

I'd enthusiastically do part-time contract work to help make a machine like this happen again, for the right price (which might be surprisingly high or low, depending on one's expectations). It'd be way faster and cheaper for a company to hire me than to do it themselves from scratch. It'd be less risky too. My mental model is that the bottleneck on a project like this is good founders/executives. It is a question of leadership and will.

My time is limited. I had more important things to do.

The LCSS algorithm (from which WarpingLCSS is an optimization) operates on a sequence of discrete symbols such as letters or nucleotides. This is in contrast to a neutral network whose natural inputs come from a continuous vector space. IMU data is continuous. We needed to bucket it before feeding it into LCSS. The random forest buckets continuous data into discrete categories. We tried support vector machines too but random forest classification worked better.

We should continue this conversation privately in either Less Wrong private messages or email.

We kept the software. It's somewhere on the cloud in a VCS. Not sure about the data. This was an embedded system. The hardest, most frustrating part to maintain was hardware integration. The prototype was a specific wearable device attached to a specific laptop. I erased that laptop and gave it away to a relative.

In a perfect world, I'd redo this project as a contractor for an established wearables company. I'd do the machine learning, they'd do the hardware and we'd outsource the data annotation to Mechanical Turk. (Data collection is easy. The data bottleneck is annotation.) But that takes industry connections I don't have.

I don't recommend anyone use that actual literal hardware we used. Hardware advances fast and some of the components we used are no longer manufactured by Nordic Semiconductor. It would be better to start from scratch with new hardware. The hardware was not complicated. It was just an industry-standard IMU attached to an industry-standard microcontroller attached to a battery, a vibrating motor and a charging light.

If someone wants to take on this project the thing to steal from my experience would be the machine learning architecture. That's where all the hard technical challenges were. I think I have left behind enough hints in my story to save them 80% of the algorithmic work. Anyone competent enough to pull this project off could probably muddle through the remaining 20% on their own, but I recommend they hire me instead.

Not on an Apple Watch. At least, not on an Apple Watch the one time we tried porting our code to it. But it's theoretically possible to implement the algorithm on any wearable with an IMU which meets basic power efficiency requirements and which let's you run raw C close to the metal. Apple didn't let us run the app with the necessary privileges.

In the very beginning we wrote our software for Android smartwatches but that approach caused several problems.

1. Our customers almost never had an Android smartwatch already. They bought whatever hardware we told them to. We earned $0 per sale even though Android smartwatches cost several times more money for our customers to buy. Customers kept asking us to make our own devices.
2. Many of our customers were iPhone users. Android smartwatches do not integrate optimally with iPhones.
3. Google kept changing the API, the user interface and the update/installation process. They even changed the name.
4. Smartwatches were frustratingly power inefficient in ways we could not alter.
5. Manufacturers frequently discontinued the smartwatch models we used, including discontinuing software updates, which eventually bricked them.
6. The smartwatches weren't standardized enough that we could write software once and it would run well on all varieties.

The problem is that no wearable platform good enough was already owned by enough of the population. As counterintuitive as our approach might seem to a software developer, it made more sense for us to manufacture our own hardware.

Only eating with a fork. A full system would require more data than that. We tested on real people in real-world conditions who were not part of the training dataset. If someone ate in a different style we could add just a little bit of annotated training data for the eating style, run the toolchain overnight and the algorithm would be noticeably better for that person and everyone else. The reason why I'm so confident in our algorith was because ① it required very little data to do updates and ② I had lots of experience in the field which meant I knew exactly what quality level was and wasn't acceptable to customers.

To update the code in response to user feedback we would have to push the new code. Building an update system was theoretically straightforward. It was a (theoretically) solved problem with little technical risk. But it was not a problem that we had personally built a toolchain for and the whole firmware update system involved more technical maintenance than I wanted to commit myself to.

I appreciate your supportive encouragement. This story took place over a year ago. I have had plenty of time to wrestle with the competing values. This wasn't the first time I chose to abandon a project which potentially could have helped people at scale. I have limited resources. I have to make hard decisions. I like making hard decisions [LW · GW] because the act of facing hard decisions implies I'm living life to the fullest.

I don't think I need Karpman's Drama Triangle right not but I do see the connection. It definitely would have helped me if I had read it ten years ago, but that is an unrelated story I do not expect to ever publish.

Why the heck is this at -5, am I missing something here? Tentatively upvoted unless someone tells me why this should be so far down.

[edit: Though I disagree with the downvotes, I now understand them due to the explanations in child comments]

Is the implication that this story is a rescuer -> victim arc?