As someone who spent the first two years out of college designing a full mouth electric toothbrush as the lead mechanical engineer, unfortunately making one in your garage is unlikely to go well. Bristling (or tufting as it’s known in the industry) is pretty much only done at very high volumes—minimum order quantities don’t go lower than 100,000 (or at least they didn’t back in 2010⁄11). One of the reasons our toothbrush didn’t make it to market was that there’s no established method for prototyping small quantities of tufted products because at this point they’re so commoditized. The one functional prototype we made was produced by harvesting bristle bundles from off the shelf toothbrushes and hand gluing them to the prototype using food-safe super glue. The next step was going to be dropping a couple million on custom tooling for a trial run of thousands of brushes 😭
Nate Sharpe
I can see this being automated given the visual capabilities in the latest models along with a healthy dose of input from existing practitioners. Do detailed teardowns of different products across many different industries, with images of each component and subassembly along with detailed descriptions of those images (what the parts are, what they’re made of, how they were made, what purpose they serve as a whole and what purpose various features are serving). This could then start to create the textual training data to then allow the models to generate such information themselves in the opposite direction. And in fact this closely resembles how mechanical engineers often build up experience (along with making things, building them, and seeing why they don’t work like they thought they would).
There are obvious approaches that haven’t been well explored. For example, we can create a lot of data using simulations, although there will be a gap between simulation and reality.
For the specific field(s) in question here (mechanical parts/products), I think there’s really three mostly separate domains—design, prototyping, and high volume manufacturing. The latter two seem easier to me (how to make a thing or a million things given an input picture/drawing/CAD), but the former (given a product spec, design a thing that satisfies the product requirements) is a much larger space of potential solutions and seems harder to have tight feedback loops (especially since you need to solve the “make it” domains first if you want testing to be fully automated).
instead, documenting this granular, real-world knowledge is impractical and inefficient.
I would add that unlike software and law, that work directly with text that is then easily shared, searchable, and intrinsically composed of a finite set of discrete tokens, people working with the physical world cannot easily share or search amongst the infinite set of continuously variable physical features. As a mechanical engineer, I’ve often bemoaned the lack of a “stack overflow for product design” or similar, and I think this is a big part of why such a thing doesn’t exist. While in principal you could describe in text everything that you’re doing, that doesn’t provide any value in and of itself and thus when combined with other hurdles like confidentiality and time constraints, very little domain knowledge ends up in a place where everyone can access it.
Thanks Malcolm, I’m glad you found it valuable!