Hardware hacking can be extremely multidisciplinary. If you only know bits and bytes, but not solder and electrons, you’re limited in what you can build. The same is true for mechanical design, where the forces of stress and strain suddenly apply to your project and the pile of code and PCBs comes crashing to the ground.
In the first half of his workshop, Naman Pushp walks you through some of the important first concepts in mechanical engineering — how to think about the forces in the world that act on physical objects. And he brings along a great range of home-built Jugaad props that include a gravity-defying tensegrity string sculpture and some fancy origami that help hammer the topics home.
In the second half of the workshop, Naman takes these concepts into computer simulation, and gives us good insight into the way that finite-element analysis simulation packages model these same forces on tiny chunks of your project’s geometry to see if it’ll hold up under real world load. The software he uses isn’t free by any definition — it’s not even cheap unless you have a student license — but it’s nonetheless illuminating to watch him work through the flow of roughly designing an object, putting simulated stresses and strains on it, and interpreting the results. If you’ve never used FEA tools before, or are looking for a compressed introduction to first-semester mechanical engineering, this talk might be right up your alley.
Naman is a hacker and student who is currently working on a ridiculously inexpensive laptop-in-a-box for the Indian market, and a drone delivery startup. We’re sure we’ll be hearing more from him in the future.
If you want to play around with FEM try FreeCAD, its not that hard to set up FEM and newer versions provide example setups out of the box (0.19).
https://wiki.freecadweb.org/FEM_Module
There is also LISA https://lisafea.com/
Mechanical is *so* much harder than code and chips. 3rd dimensions, more possible interactions, inconsistent quality of materials, unavoidable costs of every element added, in terms of price, size, and weight, wear, and friction, high precision needed without fully automated and and standard ways to achieve it, it just goes on and on.
Code is forgiving. Unless it controls airplanes, you can just reboot if anything goes wrong. Hardware can break, but usually only in a few well known ways. Mechanical stuff has an incredible number of failure modes. Wires work just fine when bent. Soldered PCBs can take a beating. A clockwork can be destroyed with a few pounds of bending force.
As a non-ME, I think the first step of mechanical is to just don’t, and be glad you can use a digital solution instead. The second step is to not take any shortcuts or compromises when you do have to, and be sure to get everything exactly right, or it will be a nightmare.
Cheap counterfeit chips may work mostly fine for a decade, but that cheap counterfeit pushbutton with moving parts will probably be dead in a year of heavy use. The only thing in basic electronics that comes close is power circuitry, and even that is easier to get right than moving parts.
I don’t know how you guys deal with it!
Until all of the combinations have been tried, we will continue to empirically test them all.
Any doesn’t want more Legos in their toy box?
Hidden ESD damage, water ingress and corrosion, wire rot, flash corruption, oxidizing connectors, vibration, tin whiskers, tin pest, cold solders, wrong type of solder, leaking capacitors, electromigration, diffusion, BGA cracking, EMI… there’s a million ways the electronics hardware can just die on you or start misbehaving inexplicably without a fix. Then there’s a million ways the code can misbehave because of hidden bugs in the libraries you’re using, which are essentially black boxes because nobody has the time to wade through all that junk.
Mechanical failure modes are almost always due to something wearing out of spec, gradually, giving some indications and symptoms before it actually does so. Thanks to the design you can usually run the mechanism in “failure mode” for a long time before it actually becomes non-functional, like driving your car to a garage after the alternator belt starts squealing. It doesn’t just suddenly stop. Your Arduino’s RAM can flip a bit randomly and you’ll be none the wiser, until it reaches the wrong value and it does stop, completely.
https://www.scientificamerican.com/article/solar-storms-fast-facts/
>Extensive background radiation studies by IBM in the 1990s suggest that computers typically experience about one cosmic-ray-induced error per 256 megabytes of RAM per month.
I’ve had electronics fail in the field simply because the change in temperature between day and night gradually loosened a screw terminal. The device would shut down and stop responding, but when you went in and opened the box it would reboot normally and work like before because the shock of moving it would restore the connection, which would then fail again 2-3 days later. It becomes expensive to diagnose such problems because when you get there it “just works” and then it “just doesn’t”, and every time you have to drive 50 miles to try something else. The irony was that the device was supposed to have a self-diagnosing function so we wouldn’t have to do that, but it’s rather difficult to do remote diagnosis when the thing won’t respond to radio.
> Wires work just fine when bent.
Except when it’s a coax cable and putting a kink in it is causing attenuation and reflection…
Imagine a plant (eg. ocean vessel) that has 12 000 000 000 valves switching every nanosecond for years without need to service or replace a single one. That is how I see modern processors.