DIY haptic input knob: BLDC motor + round LCD

Two answers: (i) late stage capitalism: who cares about going through a 400 pages spec sheet to try and reverse engineer the ludicrous Chinglish [1] in which all non-mainstream manuals are written today (wanted to declare war on China by myself when parsing through a Xinje PLC manual recently) when you could be fired at any time, a health emergency can bankrupt you, you generally feel more and more powerless, from your daily life to the once-in-a-lifetime-but-happening-every-week events such as economic crises, pandemics, wars, automated labor, x-flation, climate change, and so on and so forth. (ii) product refinement: we no longer are interested in a few lines of assembly which barely show two lines and a dot moving on the screen [2], we want that feeling, silky smooth user experience which some companies spend billions to provide, but very few individuals can offer by themselves, examples would be something in the tier of Bartosz Ciechanowski [3], scottbez1 [4], or Chris from Clickspring [5], for a more hardware bent. [1] [link] [2] [link] [3] [link] [4] [this video] [5] [link]

I made a rotary input device that provides software-defined "virtual" detents and end-stops, implemented using a BLDC gimbal motor. It can dynamically switch from completely smooth unbounded rotation, to having detents with configurable spacing and strength and "end-stops" that spring back if you try to rotate past them. [this video] It's got a round LCD on the front of the knob (wired and supported via the hollow shaft of the motor) and uses the flex of the PCB and strain gauge sensors (in the latest revision, simply SMD resistors whose resistance changes when stretched) to detect when the knob is pressed down. It's open source hardware and software - [link] HN folks might appreciate that it communicates with host software on the computer via protobuf-encoded USB serial messages -- nanopb is awesome for embedded C protobuf support, and having the defined schema, autogenerated serialization code, and compile-time type safety is so much nicer than ArduinoJson or hand-written binary protocols! I'd love to get it hooked up to some real software eventually (video editors or home-assistant control are my 2 main ideas), but it's really just been a fun project to tinker with and try out some new ideas and parts I've never used before.

I'm not convinced it is that easy. Cars traditionally have very generic button clusters, like [0]. It is even very common to have dummy buttons in there. Combine that with today's cars where those buttons are hooked up to some MCU to send a CAN message instead of being hardwired to a function-specific cable in a giant loom, and it is suddenly quite easy to change button functionality quite late in the design process for basically zero cost: you just need a slightly different label print and a small firmware patch! Or, if you want to be 100% flexible, go with the ATM approach where physical buttons are placed next to an icon shown on a screen[1]. All of the flexibility and all of the tactile feedback! You can even go for a multi-level layout, with a top row of mode selection buttons, a bottom row of mode-specific function buttons, and perhaps even a big fat dial with haptic feedback[2]. Or even go all-out Elgato Stream Deck[3]. And sure, the fact that slapping in a giant touchscreen lets them decouple UX design from physical controls is going to play a big role. But it is by far the laziest and least user-friendly way of doing so. If that's the best you can come up with, you probably shouldn't be doing UX design at all. [0]: [link] [1]: [link] [2]: [this video] [3]: [link]