A few years ago, I ordered the cheapest six-axis robotic arm from ebay for about $100 that came with basically no software or motor-driver boards, so I did it all from scratch with a PCA9685 board, a basic kernel driver and some very hacky scripts from user space.
One day I had some friends over for a glass of wine, and wanted to show off my creation. I invited them into my "lab" and placed my wine glass down on the desk so I could type a few commands with both hands.
My rudimentary software had some motion smoothing once it was up and running, but upon initialization, if the arm was significantly displaced from where it had been when it was turned off, the PWM board would instruct the motor to immediately "be" in a position that required the arm to travel clear across the desk in effectively as little time as possible.
In this case, where it had been previously happened to be where my wine glass was now, and the flimsy aluminum at high speed was enough to shear the stem from the glass and explode the bulb. Luckily the wine didn't get in any sensitive electronics, but I learned a valuable lesson about the difference between messing around with hardware vs software.
I used to do robotics, I can tell you that the fact that it was the cheapest or the most hacky does not matter in the least. Everything can and will go wrong, even the priciest and well documented part.
I used to have multiple clamps around the controller, message bus, the firmware and also a physical barrier, and yet would not feel safe with my fingers or person around moving parts.
Used to work in robotics. The QA folk were obviously very much sticklers for the full process of enabling the hardware interlocks before getting near the moving bits. One time a manager got mad at them for taking so long going through the full interlock process while repeating a failure mode. He therefore went up to the machine saying "look, it failed so it's stopped, that's how the code works!" At that point our beta version of our CI requisitioned that bot (as the interlock wasn't the only process corner that the manager was trying to cut the bot wasn't marked as reserved in the CI system), it started initializing and broke his arm.
I'm just glad that ultimately he was the only one who faced physical consequences for his poor choices. And thankful that the consequences weren't that bad at the end of the day; a broken arm is way better than a cracked open skull.
I worked for a car company. We had robots for mounting parts. Big robotic arm several tons of pressure possible. I was part of the maintenance team, we get an alert for a robot malfunctionning. Coming in the area we see screwdrivers cleverly placed in all the safeties. And a guy trying to tweak the robot that was slowly moving...
He was next to the robot (like his hip touching it) trying to do we never knew what with his hands on the robot. And the robot was moving of course all securities were disabled and it was in a kind of. debug/manual mode) He was also just an operator from the next stage of production, so he was not supposed to be here at all. We checked everything and ran the calibration and validation procedures and they went through so maybe he did repair it in the end.
I hope that the arm healed well, and that, after the painful demonstration, everyone in the organization was fully onboard with workplace safety protocol.
Yeah, the arm healed great, and whole situation (plus the subsequent "N Days Since a Limb Mangled" sign) contributed greatly to the manager's humility and respect for safety.
I don't work in robotics so I might be entirely off-base here, but surely the interlock process would consist of hitting an E-stop somewhere? What was this process that took long enough for said manager to get annoyed with?
You usually only hit the E-stop when the robot is moving in a way that could be dangerous. Safety interlocks are intended to minimize the probability of such a dangerous situation. The robot won't move unless all of the interlocks are outputting a "go ahead" signal. The most common interlock is a (switch/laser/hall effect sensor/whatever) that detects the door to the robot cell is closed.
Well yes I know that much, but surely having an e-stop pressed will stop the robot from moving, same as any of the other interlocks? And opening/closing a door or the like doesn't seem like something that takes a long time either...
A lot of the toxic pressure that pushed the manager in that direction still existed, but a light hearted floppy arm joke served well to remind everyone relevant of the state space of outcomes.
Yep. When I have to work with robots, it's from a distance and with as much safety equipment as possible. I've seen too many physical, hardware, and software failures to risk anything I care about. Hearing protection is also important. A hundred pounds or more of metal slamming into itself at high speed makes a deafening sound.
I’ve read a story somewhere, that someone trying to fix something in the toilet had to be in a position close to the toilet, then the lid accidentally fallen shut and the guy had his hearing damaged because the toilet bowl somehow concentrated the noise in one point where his head was.
It’s weird how even ordinary things can be dangerously loud.
When I was a graduate student making something in the machine shop, another user of this (excellent) departmental facility had just spent most of the day setting up his CNC milling job on the oldest, shittiest (and therefore least-time-pressured) 3-axis mill in the building. Whilst I was manually turning something on the lathe about 15 m away, he shut the door and pressed the 'go' button.
There was an absolutely almighty BANG, of the 'an explosion has just occurred' variety that made me very glad I wasn't actually cutting metal at that precise point in time. His g-code had an off-by-one error (I think) and it had dutifully picked up a ~20 cm HUGE flycutter, spun it at the speed of of a ~5 mm bull nose cutter, and driven it directly down into a piece of aluminium. The flycutter had broken and effectively welded itself to the aluminium, which had sheared down the middle, spun out, and hit the protective guards that completely encompass the machine. The person driving it (either a postdoc or graduate student) was maybe 40 cm away and saw this ~2 kg piece of metal bounce off a thick reinforced poylcarbonate guard directly at the level of his head.
Some small metal pressing machines for example have two buttons, one on each side of the machine. You have to push them both for the machine to operate. This means your hands can't be squished.
Or a dental x-ray machine has the final "run" button in the hallway so the nurse taking x-rays must go there to do it, so they don't get repeated exposure.
There's lots of safety mechanisms like this in manufacturing. I've also seen "light curtains" which are essentially 2 bars on either side of a hazard. If anything crosses that plane, the machine stops automatically. There are also pressure pads. For one type, you have to be standing on for the machine to operate so that you are in a safe location when it starts. For the other, the pad covers the danger area and the machine will not operate if there's any weight detected. Trying to think of any others I've run into. It's actually pretty interesting stuff. You've got to keep in mind that the operator is liable to be in a hurry, tired, stupid, or any combination thereof.
Another awesome safety system is the SawStop which uses the conductivity of skin to monitor for contact against the blade in a tablesaw. If it detects contact a small explosive charge goes off, instantly sending a block of aluminum into the path of the blade, stopping it dead. Even a serious accident like leaning with an elbow against a moving blade is likely to result in little more than the scratch from hitting a stationary sharp object rather than decapitation.
Sadly the inventor couldn't convince the tablesaw manufacturers to use his invention for cost and/or liability reasons so he had to make his own. Their tablesaws themselves are relatively expensive but cost per accident is $100 for the charge plus whatever the blade costs, so basically $200 to prevent serious injury or death.
Do you know what moisture level sets it off? I didn't even think about that - it's easy to take Southern California's weather for granted. Here it's either pretty much ready from the lumberyard or you got it right off the mill's truck so it has to sit for a few days/weeks.
The lobbying is off putting, yes, but at least his greedy self-interest would do some actual good instead of extracting evermore capital from everyone. Powertools inhabit this uncanny valley of dangerous equipment where they're cheap and accessible enough to the average joe (compared to CNC machining centers or forklifts or whatever) yet powerful enough to do some real damage. My understanding is that the primary reason the major manufacturers didn't want the SawStop wasn't cost but the fear that it would expose them to more liability by making the tools seem less dangerous. I really wish it achieves mass adoption so that the price drops even further.
Thankfully the patents are starting to expire in 2024. Nothing holds pack progress quite like the patent system.
The problem with causing $300 of destruction and lost work time vs possibly saving a limb is there's no fine woodworking operation or framing carpentry operation that requires a table saw. Technically if you feel unsafe working with a table saw you can do absolutely everything very slowly and tediously with a router or router table or bandsaw, or manual tools like a chisel and hammer. Anyone concerned about safety doesn't use a saw stop, they use an entirely different technology than a table saw. If you make a table saw too safe or too expensive to actually use, people will simply use something else. The death toll may or may not be lower...
From a marketing perspective, the people most likely to buy a saw stop because they're scared of table saws will save a lot of money by not buying either sawstop or table saw, and they'll cut dado slots using a hand held router (more dangerous in a different way) or break down plywood using a tracksaw (unholy expensive and many crushed foot injuries) or cut beveled edges on a router table or zillions of alternatives. Meanwhile the people who don't care about safety because they're not drinking on the job or they actually use the substantial amount of safety gear that makes a table saw perfectly safe OR they only do operations on the table saw that are inherently safe by nature (as opposed to relatively low risk operations, and some very high risk operations that people do anyway), will continue to save a lot of money by the combo of not being dumb and not buying sawstop. Finally the real dumb woodworkers who get drunk and get hurt or simply don't care, will continue to not care and not buy sawstop and will not live too much longer in a world either with sawstop or without table saws anyway, so its not like the world will net improve, the Darwin award winners will continue to win Darwin awards. So sawstop is a VERY hard sell.
A similar problem is well manufactured table saws are safer than homemade table saws. The concept of "put a round blade on a motor" is too simple to legislate out of existence. So making table saws illegal wouldn't eliminate table saws it would just mean the homemade ones will make table saws, on average, more dangerous.
Arguably, radial arm saws are more dangerous than table saws and "the marketplace" effectively eliminated those decades ago, so its not like the marketplace dislikes safety or whatever.
> Meanwhile the people who don't care about safety because
> they're [never doing unsafe things]
This sounds an awful lot like suggesting that skilled users of firearms don't care at all about safety because no one's going to deliberately do stupid stuff. It seems farcical to me. Just as with firearm safety rules, they're there to protect people from the rare moments when we are inadvertently NOT careful. History has shown that people DO do stupid stuff because they were thinking about something else, or were tired, or distracted -- hence why every firearm is treated as loaded, even if you unloaded it, and why weapon safeties exist.
For table saws, having a sawstop helps prevent situations that you don't have fill control over from having bad consequences. Of course you'd still use all the same safety measures you normally would without one.
Most firearms accidents happen during normal operations like carrying, cleaning, disassembly, and so on. In comparison table saws are extremely versatile and can do many operations some of which categorically prevent entire classes of accidents. For example I have a commercially made box cutting jig with various shields and guards and its not physically possible to stick my fingers in the blade during operation. If as you claim my mind drifted and I did stupid stuff, by physical design of the operation its impossible to hurt myself.
There's another class of accident involving equipment. Some people do not store firearms with trigger locks or unloaded in safes or whatever. Likewise there's an analogy with table saws where I don't rip small boards without a nice featherboard, riving knife, and some really nice plastic pushsticks. If as you claim my mind drifted, this time by use of tools it would still be physically impossible to hurt myself.
There is a class of inherently dangerous operations where no safety tools exist but the table saw is so versatile and flexible people can successfully do the operation... most of the time. My point is instead of spending more money to build a "better" tablesaw to do something dumb, simply invest the money in a COTS bandsaw or track saw or jigsaw hole cutting jig or chainsaw or planer or whatever crazy risky thing there's a better, faster, safer tool. You can do dangerous things with a table saw but there's always a better safer faster way to do it with a different tool. Taking away money by making the required table saw more expensive just means the woodworker will not be able to afford the superior even safer tool for the job.
Ha! You described me to a 't' and all that makes sense. As a programmer I didn't want to risk my fingers even with a SawStop cabinet so I invested the money in a Festool tracksaw and Domino instead. No crushed foot injuries yet but man I wish I had a tablesaw to cut thin pieces from stock that aren't wide enough to fully support the track.
Or they went about developing their own systems. Bosch made their own system that didn't involve slamming a brake into the blade, but SawStop decided to throw some money around and get an injunction against it.
All the evidence I've found is super cloudy, but early reports indicated Bosch's variant predated SawStop's release.
Luckily SawStop's patents expire in a few years so hopefully we'll see other safety mechanisms similar to SawStop without the downsides and greed.
I have no idea on the moisture levels that cause it to be set off, I just remember reading/watching a video about it because at first it seemed like technology that SHOULD be widely used and implemented. When I first learned about it I thought it was a great idea.
Current saw stop units do have an over-ride switch so that if you know you're going to cut questionable wood, you can disable the safety mechanism for a series of cuts. (The safety mechanism comes back on if you power the table saw off, then back on.) But of course you don't know advance for sure if the piece of wood in hand will trigger the safety mechanism or not.
Not everybody's cup of tea, but our ability to be 'present' is highly variable, both person-to-person, and one person over time. I'm a somewhat daydreamy sort of person, so I work to bring focus when I'm using power tools. As a hobbyist I walk out of my shop when I get tired, emotional, or otherwise distracted, but that's not an option for everyone.
The one at our *kerspace has tripped numerous times on damp wood, laser-cut wood, shiny laminates that didn't register as metallic but apparently it was a full moon that day or something, etc.
It's also saved a few legit fingers, so it's still a net win, but you've got to have pretty deep pockets to cover all the false trips.
It is true, laser cut wood and burnt wood in general also sets it off. However on all saw stop saws I've used you can disable the safety when you have to cut those materials.
One thing I'm still unsure of regarding table saws: is there really much risk of injury if you follow all of the typically recommended safety practices?
Every tablesaw injury I remember hearing about involved the operator failing to follow some of those guidelines.
This goes back to the basic point of safety work: Even the best trained, most attentive and careful operator can get into dangerous situations. There's no way to anticipate the moment that their attention might wander or some external circumstance might just force the situation.
Is there anyway to do it magnetically using inducted currents? I doubt you can stop the saw that way, but you should be able slow the blade down so it does not do as much damage.
A tablesaw goes through a finger as if it is nothing. Fingers can move at speeds of dozens of centimeters per second. So anything that takes longer a dozen microseconds to stop the blade will not be good enough to let you keep your finger.
Another one is machinery where you have to "enter" the machine to do maintenance. Think industrial ovens.
You're supposed to turn off the circuit breaker and lock it with your own personal lock that only you have the key to. That way no one can turn it on even if they wanted to.
I've heard no one, under any circumstances is allowed to take the lock off. If the person leaves after their shift and forgets to take it off for example, they have to come back in the middle of the night so to speak and take it off.
As someone else mentioned, that's a lockout-tagout procedure. Very common when doing any kind of maintenance on a machine. You isolate the power sources and place a personal lock on it to which only you have the key. It usually has your name and an ID number written on it. The lock cannot be removed by anyone else. If you, for instance, forget to take your lock off and go home, it's a very long process where they have to get someone high enough up the chain to get in contact with you and either get you to come back or confirm that you're safely a long way away from the machine before they can cut the lock off. This makes your management very unhappy and most places that I've worked will write you up for leaving while the equipment is still locked out if maintenance is finished and it's safe to operate.
It's not only electricity that needs to be isolated and locked out. A lot of machines use air pressure to operate moving parts, so in that case you'd have to isolate all electrical sources as well as the air. The machines I usually mess with require 2 locks. Some of the machines I've seen can require 6 or more locks to be fully locked out and safe to work on.
When I served on a submarine, tagout procedures were followed to the letter.
A typical maintenance period might require 100 or so separate tagouts, each of which could require anywhere from one to dozens of tags. Each duty watch was required to show up early enough to go through the entire tagout book and at least know the gist of what was in progress.
Finding a loose tag was an automatic all hands all work stoppage, until it was tracked down and resolved. No questions, even if your work was in a different compartment, or had no logical connection to what he tag was for.
Each new tagout request had to be signed off on by at least three people, sometimes all the way up to the captain and not just a foreman or supervisor but one or more shop heads.
Seawater system tagouts on a floating sub were serious business.
Not just equipment you have to enter. This is used in situations with "stored energy" or other systems that need to be turned off or otherwise disabled for safe maintenance. There are multi-lock hasps that can be used if multiple people have overlapping needs to lock out the system, and other devices such as valve handles covers, etc., that help with locking out components don't have a built-in place for a lock.
These make the worst horror stories I've read from various safety organizations. Tanks with gases (nitrogen is particularly sneaky), ovens, radioactive sources... If you want to learn about industrial risks based on real stories watch the CBS videos https://m.youtube.com/watch?v=f2ItJe2Incs
>one type, you have to be standing on for the machine to operate so that you are in a safe location when it starts
Of course, the weakness of a system like this being if middle management is demanding unachievable timelines and/or people in the shop are willing to cut corners, someone can leave a box of heavy stuff on the pressure pad to "save time." Absolutely right that all these systems need to be resilient to operator tiredness etc
If you want to manually operate an industrial robot via its controller, you usually have to squeeze a "deadman" switch or else the robot will engage its brakes. What's neat is that the deadman switch is a 3-position switch: They discovered that when people panic they either let go or squeeze harder, so both actions stop the robot.
Which makes it even more confusing. Were they preparing a sandwich on top of the server? Did they eat mayonnaise straight from the jar? The condiment plot thickens.
Oh, I have to introduce you to some of our finest subway sandwiches prepared by students that have no clue how to make sandwiches that don't spill all their innards as soon as they leave their hands.
Back when I was doing some hands-on practical training in electric engineering school, we had to design a control circuit on some breadboard, the kind that in high school would lit a couple of leds, and maybe make a light fade, but here it was driving a big-ass train engine boxed in a 1.5m x 1.5m x 3m steel cage, right next to the bench where we pieced the control device together, barely arms length away.
While conceptually the same, "theory" vs "practice" and "command" vs "power" suddenly takes a whole new meaning where you're suddenly pushing several orders of magnitude more power than a puny 9V battery could. The buzzing of a hundred amps ready to flow inches away was chillingly ominous. You get a strange urge to triple check, quad check even, design and calculations before flicking the switch.
As we all successfully started up our bench, the rumbling of a dozen of these bare protomachines revving up in a hangar was eerie. The thought of them sucking in such an amount of overall power from the grid dizzying. I rarely get cold-sweat and goose bumps, but this was one of these days.
The "Stuff Made Here" youtube channel was dealing with this recently when making a chainsaw robot. As you can imagine, it was kindof important. He ended up with a combination of a flashing "armed" light and an e-stop switch.
Something similar happened to me when I remote-controlled a buddy's computer. This was I guess in the early 2000s when disc drives were still a thing. Opening the drive knocked over a glass of wine and caused quite a mess... Noone hurt, but also spilled wine.
At my first job we once developed our own controllers with haptic feedback for our surgical training simulation. It was amazing how realistic the feel was.
The motors were quite powerful and there were a few close calls which really made you think.
It used to twitch violently as it was calibrating on initializing. Once, it reset and did that while testing. Luckily the person holding it managed to get his hands out of the handles on time.
Another tim the tip of one instrument had broken off and during initialization there was an error in the force applied in the direction along the shaft. It flew out like a rocket.
We had a scary and quite overspec'd arm acquired cheaply in the early history of a startup. We we're able to control it via the serial interface, but similarly to you we had no documentation and everything had been reverse engineered. The thing was surrounded by e-stops.
Back in 2002, I was getting a package with a brand new Pocket PC (smartphone without the phone, running Windows). And I really wanted to know when it was delivered, but the UPS guy would regularly leave packages on the porch without ringing the bell or anything.
This was before you could get delivery alerts or anything like that. But I had a spare laptop with an integrated webcam (wow!), and I'd figured out how to make it run actions on motion detection.
My plan was to point the laptop at the door, and eject the CD drive when it detected motion. The tray of the drive would push a water bottle off the table. That would land on a seesaw, which would launch a deck of cards in a hard plastic case at the door and make a very loud noise.
It's unclear why I couldn't just play a really sound on the speakers instead. Anyway, I tested the program by standing in front of the laptop and waving my hand.
It worked perfectly! The CD tray ejected, and I watched as the water bottle slowly rolled off the table. It dropped onto the seesaw...... and instantly launched a hard plastic deck at my face and got me right between the eyes.
Never again have I been in so much pain and also so excited about my code working perfectly at the exact same time.
This made me actually laugh out loud, it feels like some of the things I came up with as a teenager wanting to do robotics and automation but having no money or way to purchase things online, water bottles were actually a good way of powering things like opening curtains by dropping them on a string.
Also I like that even after you came up with "knock something off the table" you felt you needed a seesaw catapult thing and didn't just knock something off that could make the actual sound like a cake tin or bell or something.
> Also I like that even after you came up with "knock something off the table" you felt you needed a seesaw catapult thing and didn't just knock something off that could make the actual sound like a cake tin or bell or something.
It totally doesn't make any sense! I think I might have been fascinated with the idea of Rube Goldberg machines or something at the time. Or maybe I thought I could build a "security system" with it? Also it was summer and I was a bored teenager.
Anything with an actuator, really. I'm a controls engineer, we work with all kinds of hazards and it's my responsibility to run the risk assessment that makes sure no minimum-wage operator gets harmed because of our machine. People are the squishiest, weakest, most sensitive part of just about any shop, so there's a lot of risks to assess!
One key observation, though, when working with code is that the machine becomes so close to predictable that it's more dangerous than if it were unpredictable. A cordless handheld drill is hardly a tool that most people would call 'hazardous'. You turn the trigger, the thing rotates, grab the chuck and you can likely stall it. But that much energy in something driven by code is extremely dangerous, it's waiting for any of who knows how many conditions to take off, a common one is that putting your hands in/on something that seems to be not moving can 'make' a sensor and the machine will take off.
There are definitely two kinds of safety domains, one applies to manually operated tools where the operator of, say, a knife is responsible for their own safety - if they cut themselves, they're at fault, not the knifemaker. There's another kind of safety engineering where if the machine takes off 'by itself' while an operator is in the way it's the machine designer's fault for not stopping that from happening, the operator can't be expected to know what's going on.
The latter should become more common as computers continue to permeate everything we use - that cordless drill is no longer controlled by the operator with a trigger switch that connects power to a DC motor, it's a brushless motor driver with an analog input sensing the position of the trigger and the EMF of the motor, and the charge state of the batteries, and who knows what else. Bump a sensor and it might take off, you don't know why it does what it does.
I'll continue to make my automated cells as safe as I can, but don't trust code that's not so simple you can be confident of how it works.
> A cordless handheld drill is hardly a tool that most people would call 'hazardous'. You turn the trigger, the thing rotates, grab the chuck and you can likely stall it. But that much energy in something driven by code is extremely dangerous, it's waiting for any of who knows how many conditions to take off, a common one is that putting your hands in/on something that seems to be not moving can 'make' a sensor and the machine will take off.
A friend needed a valve cover gasket changed on his Honda, and his wife needed to use the car for her Uber runs that night. He came over and instead of our usual hand tools I put a socket adapter on my 20V drill to speed up disassembly. I handed the drill to him and told him "start on the lowest torque setting, and move up in small steps."
I turned around to grab more tools from the toolbox. A minute later, I heard a loud noise. I turned to see the car's windshield cracked and a shocked look on my friend's face.
My friend was used to his renter's power drill. He hadn't anticipated how much torque a modern contractor's drill outputs and set the torque to the maximum setting. On the third valve cover bolt, the drill had caught on the bolt head and spun my friend around, smashing the battery into the windshield.
There's a piece of paper taped to me toolbox called "List of things <friend's name> may not attempt unsupervised." It gained a couple of entries that day...
Recently I did what’s called the ‘big 3’ upgrade on my car’s wiring. You replace the oem wiring from your alternator, etc. with 1/0 gauge cable, thus allowing substantially more power through. This is for speakers. I made my own cables and was in the process of upsizing one of the battery lugs by drilling the hole bigger on a drill press. I was just holding the wire steady with my left hand while pulling the drill handle down with my right. The drill bit caught and spun the cable around, including somehow my hand in it, winding my hand up in the cable very tight against the still spinning drill. It’s a small drill press and didn’t have enough torque to keep spinning, but had the drill been stronger I’d have at least broken my hand if not worse. As it was my hand was swollen and scratched pretty good. When you make your living typing this really makes you think.
Having had this happen a few times, I'm pretty obsessive about workholding now. It's a shame that a good drill-press vise can cost almost as much as the drill press itself, because it's really important for safety.
You should image-search the term "radial drill" sometime. ;)
You don't need a high-dollar Kurt milling vise for a drill press, and you only need to constrain the part in one degree of freedom (rotation about Z axis). Just put a single fastener in your table and drop the slots in that vise over it. Gravity and quill pressure hold it in Z, the table holds it flat against rotation about X and Y, and you want it to have the ability to slide a bit in X and Y to let the drill find the center of your punch/pilot hole. If the drill catches, the torque will push against the stud and it can't move.
An impact driver (rattle gun) is much better for speeding up disassembly than a drill. They also don't apply anything like the same feeling of torque to the operator's wrist.
A lower power (e.g. 300Nm max) battery driver is great for when you have to undo lots of lower sized bolts, while it would be a little bit underpowered for wheel nuts or motorcycle fork retaining bolts.
You should be introduced to Italian single-sided-swingarm nuts. For example, my MV Agusta Brutale required 220 to 240Nm tightening. It would come loose with my battery-powered 300NM rattle gun, but only after a while. (Fantastic bike but I no longer own it. I'd rent another though.)
Ducati single-sided swingarm nuts can be similar, but I have not yet owned a Ducati.
They probably could have, had they been ready for it. Not everyone is the same weight and strength either so it could just be that it was out of their physical capabilities.
That is often the difference between home and tradesman tools. A tradesman can reasonably be expected to handle a bit more responsibility from their tools than the home handyman.
I imagine he was leaning over the engine bay, maybe holding the drill in one hand. So in that specific scenario, the tool was more powerful than he could control.
But that same drill might be asked to bore a large hole in a piece of wood, and the user would anticipate the amount of leverage they need to control it. Two hands, arms close to body, etc.
For drilling holes in soft materials like drywall and wood, or even softer metals like aluminum. I recently used that drill to drill into a motorcycle engine to remove a stuck rotor cover.
For a continuous drilling operation the torque is totally fine, the problem is abrupt changes in torque because of something catching. On drills without this feature that's what the torque limiting clutch is for.
Dunno about Bosch's implementation, but the Milwaukee one sucks. The drill/impact driver would strip the screw head, jerk your wrist, and then cut the power. I'd much rather have a mechanical clutch than than that one.
We actually had an older drill with the mechanical clutch with a stripped high gear that we kept around for driving screws instead of tossing because the new one was so bad.
Powerful electric drills will often come with an extra handle on the side (or a mounting point for one) so that you can brace them with both hands. It's up to the user to set an appropriate torque limit if they're only using one hand.
When I drill 30cm holes in fiberglass or wood, I place my leg next to the handle. That have saved my wrist many times as the tool bites to the material and send the drill in a circular motion.
One of the reasons I love to dable in the game Space Engineers is that you get to experiment with simulated physical equipment. Things often go wrong and boom (or Klang in SE parlance) and you often die or hurt yourself. You seen learn to program in steps for safety.
I remember in college (mech ENG BTECH) I had a coursemate who's day job was a programmer on the CNC side.
She mentioned that this had happened to a v high end CNC machine the cutting tool after a power cut went straight to the home position very $$$$$$$
At my place we had a computer controlled wave tank and as the guy I shared an office with said you could program the ram to go full travel in zero time which would have flooded the lab.
I wrote a layoff database for Nortel Networks from ~1998 to 2001.
The way I got my notice of termination was while I was running some tests on the production database and needed a "negative" so I searched for a userid that was not present in the database: my own.
When I saw my name in the list I called my manager and asked him what was going on.
He said "Alex, why don't you head on home for the day and I'll call you there"
I wouldn't say "hurt" though. Nortel went bankrupt and I got a great severance package.
... as part of the bankruptcy proceedings they sold the technology to a bigger company. A developer improved the application by automating it. It could now send emails to the right departments automatically. The developer entered his own email as a test and was promptly fired by the new software.
Everyone who worked on the machine are now gone, yet it continues to do what it was designed for. That is until I found myself on the path of the machine...
Fun fact: Swingline never made a red stapler, the one in Office Space was a prop produced for the film by the production crew. Office Space popularized it to the point where Swingline actually started producing red staplers after the release of the film to capitalize on the demand.
I mean more the "Why don't you ..." It's quite obvious that it's rethorical but it seems so nonsensical to put this into a question while camouflaging what is really going on.
As others have said, it's definitely a 'softening' of a request to make it more polite ('Go home' vs 'Would it be possible for you to go home?').
But I think there are some status games going on here, too. A subordinate would never use that phrasing with a superior.
While the phrase uses conditional language to 'soften' the request, it's also an imperative (an order) that's made to look like a request.
Try to imagine the boss saying this. How would they have said it - with an upward inflection at the end, as in a question like this one? Definitely not! The phrase would definitely end on a downward inflection, as in an order like 'Please go home'.
It's a curious turn of phrase that I'd suggest is particular to managers, parents, and other authority figures that need to maintain a veneer of respect for their subordinates. It also strikes me as uniquely American; I couldn't imagine a Brit or an Australian saying something like this (but happy to be corrected).
Don't feel bad :-) My 11 year-old son (a native English speaker) said the same thing to me just yesterday.
"Hey, bud. Why don't you pick up those two plastic containers and follow me."
"OK, but dad, it really confuses me when you say that. Can't you just say 'please pick up those containers'? It sounds like you're giving me an option but you're really not."
Until he said that, I had never given it a thought. But he takes things very literally, so I can see how it's confusing even though he knows what I mean.
(I don't know whether it has exactly the same set of connotations in Spanish as in English, but it doesn't seem like the king expected Chavez to do something other than comply.)
The "camouflage" here indicates an increase in the speaker's politeness level. Some languages use explicit terms or forms of address to do this; English, however, utilizes indirect phrasing to achieve this effect.
I'd say the purpose is more or less to show respect. By phrasing it as an idea or a suggestion, you give them the chance to (appear to) cooperate willingly.
Both people presumably do know what's really happening, and this is exactly why it's seen as unnecessary (and inconsiderate) to actually say it. There's no reason to call extra attention to something unpleasant.
No, "head" is a verb in this case. Related to "heading" (i.e. what direction a vehicle is pointed at while moving), I think, rather than the body part.
I can't find the etymology beyond words meaning the body part or "primary"/"main". There's no direct equivalent in German for example despite the shared etymology for the other meanings.
I would guess that it is related to the body part in a figurative sense in the same was as "face" (i.e. turn your body in a specific direction) though I have no idea how "put your head there" would come to me "go there". I wonder if this was before or after "heading" became a thing for ships (which generally move in the direction they "face", so the "heading", i.e. how the "nose" is aligned, could go on to become a verb).
EDIT: I'm not sure it's pars pro toto because I'm not sure it directly refers to the "head" in the sense of the body part rather than the "heading" which is not directly related to the actual body part when talking about vehicles like ships.
No. It's not "take your head home", with your head (a noun) being the part standing in for the whole, namely you.
Rather, "to head" is a verb that means (among other things) "to move in a specific direction". For example, an aircraft could be heading north.
Yes, "take your head home" would be pars pro toto, but it is not something people usually say (in particularly, that's not what GP (or GGP or whatever) said).
normally I'd think not very high, at least until the first round of layoffs are done and any potential bugs with the database/application have been worked out.
About seven years ago I got a bright idea to build a quadcopter. I had experience with little $25-50 drones that bumped around the house with their fragile one-inch propellers, which obviously qualified me to build and pilot something significantly bigger.
Off to Aliexpress and Banggood I went. I ordered a carbon-fiber chassis, big strong motors, ESCs, 3-inch propellers, a FrSky receiver, a Devention transmitter, an STM32-based controller, giant li-poly batteries, and all the cables and fasteners I needed. Over the coming weeks the parts trickled in. Finally once the whole kit had arrived, I assembled everything, connected the TTL serial, built the firmware, downloaded it to the controller, and like the brilliant software engineer I am, plugged in the batteries on my bench at home.
Nothing happened. Those of you who have blown off fingers wondering why the firecracker under the Coke can hasn't exploded yet can guess what I did next.
I examined the chassis closely and began fiddling with the cables and connectors. Again, like the brilliant software NOT HARDWARE engineer that I am.
Evidently, I fixed the problem. Which caused four gigantic propellers to begin whirling around my hands and face. And four brushless electric motors to emit their usual high-pitched whine, which today I instinctively hear as them saying to me "You god damned idiot. You are so ours."
I was not injured. But that evening, I came close to slicing at least a couple things off my body. I hadn't appreciated the scale of the thing I was building, or the inherent risk in debugging it once I'd slapped it all together. I shelved the project for years, eventually giving it to someone at work who claimed to know his stuff when it came to drones. I hear he's doing fine.
Disclaimer: this story isn't about code or my own code. But I think it fits here because I approached dangerous hardware with the "build, run, see what happens" mindset of a software developer.
I feel obligated to add my silly mistake here. I was playing with SDR and was soldering together a small antenna for receiving ADS-B signals.
I soon realised my electric soldering iron wasn't powerful enough so I nipped out and bought a miniature blow torch. The kind which are basically a big cigarette lighter. Having got it home I tried igniting it a few times and nothing happened. I held it up to my ear to try to hear if there was any gas coming out, sure enough there was gas coming out, which in that instant ignited beautifully into a 700 degree flame pointed right at my ear.
Hey, accident twins! I once had a Zippo lighter that was playing up - you could strike it and you could see the spark fly, but it didn't light. I sniffed the wick, yeah, definitely fuel evaporating off it. I struck the striker, yup, spark. Sniff, fuel, strike, spark. Sniff, strike and OF COURSE the thing lights up immediately, sending a cigarette lighter flame right up my right nostril. I'm told by bystanders that half my face lit up in an "electrocuted film character" way for a fraction of a second before I jerked it away, and I was smelling nothing but burnt nose hair every time I inhaled for about a week.
People are sometimes kind of down on that approach in software, considering it sloppy. Especially in comparison to other engineering disciplines it just looks kinda bad sure.
But really I'm pretty sure if for example civil engineers could build a bridge in an hour and load it up consequence-free they'd do it too.
The fact that we do it isn't bad at all, but yeah it's easy to not realize when you've exited the realm of consequence-free testing.
I mean, the novel of 3d printing is that it's just additive construction, don't we already build dams and almost all other structures that way already?
I built one too, and the first time I powered on the motors I felt like I was staring at four unguarded blenders and thought: wow, people actually handle these things while they are running.
Made me very nervous for a long time, especially the first few flights (or attempt at flight).
Now I twitch whenever I connect the battery and the FC makes them jerk a little. I know they aren't armed and failsafe is active and all, but you bet yer tuchus that I'm super careful connecting!
Not sure if you want to hear this, but please don't entirely trust any arm/safe system. I've had to debug one when it failed. Original dev: "impossible... show me... huh?!".
(It was some faulty hardware. Dont remember the details; it was a non obvious issue with one FC. Wasn't worth fixing the hardware, I discarded it.)
Point taken. I'm getting a tiny bit lazy connecting the batteries (too bad XC60 connectors require so much force). But I'm very cautions to make sure my fingers aren't in the line of the props (I actually used to wear welding gloves when connecting the battery). I just need an inline 60A switch or something even safer that doesn't keep my fingers in the line of fire that long. Thanks!
I still remember an EE lab professor saying one day "get in the habit of using red wires for Power and black for Ground. That way, when you have your first accident, maybe it won't be too bad."
Or a technician I used to work with who would quote his tech school instructor daily, "NO, no loose conductors on the test bench."
All the nail heads on my work bench are covered with electrical tape. I try to use red wires for + and black or green for - whenever possible. I learned to think about what could happen before I flip the power switch (first power up use the lab supply with current limited to the absolute minimum the circuit needs), or when I hit F5 in the debugger (does anyone have their hands in the machine?).
I've still set things on fire, still broken expensive pieces of equipment because I had the wrong sign on a variable, still made loud banging steel-on-steel noises because I didn't calculate an offset correctly etc.,
At the end of the day, if everyone goes home with all body parts intact, we'll call it good.
I set my first Arduino on our washing machine, which was my platform for demos for my family. I set it right on an area with chipped paint and exposed metal.
I eventually figured out I'd shorted and destroyed the 7805 regulating the DC input to 5v. My first in-the-field electronics repair was to remove it, bodge it, and live with a USB-only Arduino. I still have that Arduino; it's a reminder of the first time I let out the magic smoke.
tl;dr: Experience makes dangerously careless. Examples: quadcopters, lasercutters.
I had a similar scenario with the same preconditions. In this case, one of the propellers came off and barely missed a face.
This was a 10 inch hard plastic prop with some sharp edges. It could've taken an eye out. It could've caused serious cuts. It could've been a carbon fiber prop and caused _serious_ cuts. Of course it could also have been a soft plastic, round edged prop that would've done less damage. It missed, and nothing happened.
In this case, the cap on the mount wasn't tight enough - complete negligence; preventable. But what bothers me it that it is not possible to completely prevent that kind of mistake. Mount caps _can_ shake loose under vibration - with some features (spin reversal) there is no one safe screw direction. Also, mounts can break. More importantly, prop blades can break. Some prop mounts only use rubber loops to secure the props - they props are _meant_ to fly off off in that case. A prop could be inverted, or the PID controller could diverge, potentially sending the entire copter into your face. Probably everyone should wear safety goggles. But nobody does, and things rarely go wrong. At the very least, please do not have your head on _or above!_ the propeller's plane. Search Youtube for "quadcopter hand launch" for an appreciation how often this rule is broken as a matter of normal, routine operating practice. Often the person holding is not the pilot. That's some trust, when a small inadvertent finger movement on the pitch axis could permanently injure.
What also bothers me is that the people who should and do know best often ignore safety the most. Ever seen a group of copter devs scramble as the noise of the copter thirty feet overhead cuts off? Ever seen the same group charge a few dozen lithium polymer batteries that have survived more than a few crashes, unattended, with no fireproof bags, with no fire extinguisher, in someones room? Nothing ever went seriously wrong. But everything could have. And dont get me wrong - these are smart, safety minded people.
Along the same lines, if you are ever near someones DIY lasercutter, say in a hackerspace/makerspace... do _not_ assume it is eye safe, no matter what they claim and what laser safety certs they claim to have. In particular, do _not_ ever assume it is eye safe when you look at it from an unusual angle, like when you bend down, kneel, or when small people, children or pets are present. I have seen multiple DIY lasers get the top cover right (easy - any thick plastic sheet will block stray light from a CO2 laser), and completely and utterly fail to close small holes in front (air vents, or lid not closing perfectly, ...). There's a back of the envelope calculation that looking at the diffuse (not even reflected) spot (invisible! - and there might not be secondary light) a 100W CO2 laser (a typical size for ambitious hobbyists) creates on a surface can cause permanent eye damage if viewed from 1 meter away.
I love laser cutters but all the videos of cheap open frame cutters on YouTube scare the shit out of me. I never want to be around one with an open frame.
I was building an underwater mapping GUI, a quick SCUBA dive to do some testing before the weather closed in whilst at sea in the GBR Australia.
Dropped to 10 meters, set the datum and started swimming, going well until I crossed into a negative quadrant. My beautiful track went haywire/dead.
Then I swam around trying to get back "into" the positive quadrant, I couldn't find it and consequently couldn't get back to the datum. When I surfaced I couldn't see the dive boat!
After some time contemplating my life/coding choices for literally jumping in without thorough testing, I heard the Zodiac inflatable buzzing around the rising waves looking for me.
Back on the boat I discovered that I had only coded it to work in the positive axis from the datum. In the other axis the location was undefined.
The "system doesn't work with negative datum" bug allegedly hit F-16 flight control software, resulting in a plane that would flip upside down on crossing the equator.
Not much. A floating GPS antenna on a self tensioner, tablet in a housing. And some buggy code :) Good enough for swim lane mapping and preventing holidays (unsearched areas). Another system we worked with used ultrasonic positioning from beacons, very accurate and covert.
Great story and it made me realize that usage of "holiday" is more general than how I thought of it (missing a spot when painting). Which led me to http://www.word-detective.com/2010/12/holiday/
I have. Back in early days of Oculus, I was using one of the development kits (DK2?, maybe DK1) and making something in Unity. The Oculus had one screen, with lenses over the left and right halves. To give depth perception, it renders a view for each eye, and shows them in a vertical split screen. Some script had a bug, and none of that happened; Instead it simply stretched a normal view across both screens.
I put the headset on, and quickly noticed things weren't working right. I was walking around, trying to figure out what the issue was. Trying walking back any forth looking at a wall in front of me, I felt terrible pain. Something about the left and right eyes seeing movement in different directions across their entire field of view really breaks the brain. It was very sharp and localized too.
I had weird experience with valve index. I somehow miscalibrated it and the floor wasn't level.
I spent maybe 20 seconds in VR with skewed floor and it felt horribly wrong. And the whole evening my sense of ballance and perception was broken not to be the point of falling over but the real world around me felt wrong. Only after I slept my brain fixed itself.
I had a similar early experience with Oculus Quest. I downloaded a "ISS tour" game, where you played as an astronaut, and had the full freedom of movement microgravity affords you. The "advanced mode" of the game allowed you to move around by grabbing handles or pushing off things.
This kind of unconstrained motion is notoriously hard on VR players, and I felt a bit uneasy the whole time when I was navigating this way, but then I made a mistake. I wanted to rotate myself, so I instinctively grabbed two handles and made a sideways hand motion, sending myself into a fast spin. I almost puked, and even after taking the VR headset off, I kept feeling nauseous for the rest of the day. Like in your case, my brain fixed itself when I fell asleep, and I woke up feeling fine.
My bachelor's degree is in neurobiology and it would have been very interesting if this was reproducible in other people. Experiencing physical pain from visual stimuli (stimuli unrelated to light intensity, at least) is not something I've ever really heard of. You may have discovered the visual equivalent to the Brown Note.
I know in the past I felt pain while trying to say certain lies. I do not mean I felt uncomfortable, I mean I felt real pain. It is weird, but sometimes you can cause pain without a direct physical cause.
I built a TENS unit with an Teensy and decided to skip a current sensor. Real switching power supplies regulate current too, not just voltage (a low Ohm shunt across one of the stages to an opamp that tells the PWM circuit to slow down the n-fet input pulses, in addition to the voltage feedback power gate).
The funny part is: I didn't shock myself, I punched myself.
I had the electrodes connected to my pectoral muscle and I was adjusting the levels while holding up my arm with my hand to the side of my head. A random current change translated to a huge voltage boost, the pectoral twitched hard, and BLAMMO, punched myself in the bridge of the nose.
At least I think that's what happened. Could have been changing skin conductivity, but I like to think my Teensy code hurt me. (I eventually removed the MCU and just used two comparitors with a voltage-controlled duty cycle oscillator... much easier.)
In the 90s I implemented a PWM motor controller in asm, for a robot with enough power to accelerate hard on soft grass, outside. Robot was rather over engineered by a team mate who previously worked on automated farm machinery. Tested the microcontroller on the breadboard with an oscilloscope, all looked well: nice PWM shapes.
For the first integrated test on the robot, I high-centered it on some bricks so the wheels would turn freely, on the bench. Didn't want to deliver too much torque with wheels up, so asked for 1% PWM duty cycle. The robot leaped into the air, tearing off its umbilicals, hit the floor spinning and generally smashing shit up, including bits of me.
Debugging revealed that the output PWM duty cycle was inverted when commanded <2%, so my 1% command was 99% power. My breadboard tests had never gone below 3%, which I guessed was the minimum to overcome stiction on soft ground. Poor robot. The chunks out of my hands were the price I paid to learn to test important corner cases.
Ouch. I'm curious what would cause the PWM output to invert under such condition? Was there a special case built in for <2% that was coded incorrectly, or did it emerge from something else?
PWM periods and on-time are implemented in the time domain in hardware, so my guess would be issues with integer algebra.
Some hardware implementations are notoriously weird on edge cases. Some manufacturers built PWM modules so 0 setting on the on-time register means “no signal”, while for others it means “minimal on-time” (no signal is achieved by turning off the module).
The other bad handled case is when going above period (if period is set at 210 clocks but on time is set to 250). Some implementations wrap around, some get locked in “always on”.
It's extremely easy to hurt yourself with audio, it almost feels like cheating. Just regular audio work provides plenty of opportunities to do that. Here's a random note from Supercollider, a platform for audio synthesis [1]:
> CAUTION: macOS system volume doesn’t effectively limit audio applications’ maximum volume. Extra care has to be put in working on this platform, especially with headphones, because programs can produce unexpectedly loud sounds regardless of system volume settings, potentially causing ear damage.
The macOS system volume behaviour is ridiculous. I ... had a really bad time once with puredata. I...it's really unpleasant to remember. I also generally amn't entitled with open source software, but reporting this as an issue to the people at puredata (dsp software), recommending that they put in their own software cap in the pipeline was met with the response that I could always do that myself in my scripts as I'm writing them if I cared about it. For me (as someone who's made audio software), user's physical safety of this avoidable kind must be high priority, and it's more or less unconscionable to leave things like this to chance.
Oh Apple... On the iPhone, using earphones, the volume is limited (afaik because of a EU law). On Mac, none of that is the case. I was in a teams called, tried to make it quiter with the touchbar but accidentally set the volume to 80% (insted of 10-15 where it's usually at). My ears hurt for an hour. Thanks Apple for that useless Touchbar.
I just made a comment elsewhere in this thread regarding the absolutely awful behavior iOS had for 3rd party bluetooth headphone volume until a recent (~18 months or so) update. Every time I connected my Sony headset over bluetooth the system volume would reset to max, sometimes seemingly only after I had hit the play button in spotify. I am fairly certain this actually damaged my hearing after several occurrences of getting up, throwing my headphones on as I walked out the door, and blasting myself with max volume playback by accident. Even now that the issue has been fixed, I habitually check the device volume anytime I connect something on bluetooth. To this day I'm astounded Apple shipped such problematic behavior over the course of repeated iOS updates. I think it was fixed around the time they started to provide feedback about listening volumes in Apple Health.
this is when developing audio I have several precautions in place:
1) system volume level pretty down (usually 30%)
2) headphones volume in the middle
3) when testing something really broken I have my headphones not on the ears but on the neck
Shouldn't you do it the other way round? Set software volume to 90% and limit to safe levels with a good old potentiometer to be safe from any software issues?
I’ve not been physically hurt but lessons were learnt :
A friend of mine once gave me an old computer (I don’t remember exactly but it was some random Compaq running Windows 98 and this happened in ~2010). I installed some distro in it but tbh, it was barely usable.
I decided it was a great opportunity to see with my own eyes what would happen when you intentionally « sudo rm -rf /* ».
Well, no surprise, it erases everything. Conscientiously. Recursively. Including the mounting point of the USB hard drive where I stored my hobbies projects. Including the network share of my other computer’s /home.
No real harm if you don’t account the dehydration from sweating.
In college I knew the GNU Coreutils rm had the --no-preserve root option and that my friends didn't know about this. So for fun I ran `sudo rm -rf /` just to show off or something.
Unfortunately I had busybox rm earlier in my $PATH and it started chugging through my files.
Unlike on Windows where each drive has its own letter (so I don't think it's possible to create a path including all drives), in Linux the filesystem originates from "/" and any additional drives or network shares are "mounted" into folders within that parent filesystem, so recursively deleting everything from the parent would also affect everything else.
I remember doing something similar a long time ago (~22 years ago), and it'd actually stop removing files at some point because it deleted a file it required for the rm operation. Though I might be mixing it up with dd.
And then there was that one infamous time in Debian libc broke in Testing/Unstable. Suddenly literally every application, minor or big, was broken (everything used libc).
Almost. I was working on a web-controlled, high-intensity LED grow light (~1800watts of LEDs).
I was building a UI element which used a single slider to both control the output of the light and show its current position. First attempt had a bug which caused an infinite loop of the UI setting the light to 100%, then the light setting the UI to 0%, and back and forth.
The light was on my desk in an otherwise dark room. I (thankfully) don't suffer from epilepsy, but the the rapid, constant changing from incredibly bright to near darkness made me dizzy to the point where I couldn't really move.
The context is building a robot for a sumo competition in university. By this time I am towards the end of my Phd, and regular strategies don't cut it anymore. We want to show off.
Since many of these robots use ultrasound locators based on echolocation to find other robots, we want to eliminate those from detecting us. One of the strategies we wanted to try, was to generate sound at the right frequency ourselves, which should completely ruin those sensors, thus making us invisible for no apparent reason.
So I bought a transducer used to clean ships, which was rated for use around the correct frequency. I connected it to a signal generator at an ultrasound frequency and wanted to test its effect on the echo sensor.
Now, I am doing this sitting in a noisy lab with a bunch of noisy instruments, robots whirring and computer fans. Some other people in a corner chatting away.
I put the transducer in front of the distance sensor, set up the program to print the distance measured, turn on the signal generator, and the whole room goes eerie silent.
I turn it off, and luckily the sound comes back immediately. It appears that if you pump 100+ decibels of ultrasound in a room, it actually drowns out other noise! This thing was quite powerful. After all, it was made for cleaning ships from foul.
At that point, I do realise I have no idea whether this is a safe thing to do for my hearing (and that of the audience), and shelve the idea. But I remember the split second where I thought I made myself and everyone else in the room deaf.
It affected everyone in the room and to a lesser extent the next rooms over if the door was open.
Obviously, we did not shelve it right away since there seemed to be no permanent effect. Some people were really creeped out after they had been exposed in my first try. But this is an engineering lab, so soon enough the lab was filled with cowboys wanting to experience it and trying to figure out how it works. Meanwhile, the more safety minded people took a short break and went for some air outside.
We stopped after the professor figured out something odd was going on on his floor.
I wonder what the physics behind it is. I guess if you have an aquarium of water with low frequency waves and overwhelm it with high frequency waves, you wouldn't be able to see the low frequency ones any more. Presumably (IANA physicist) it's the same thing but with sound waves.
Why? Because different frequencies are linearly independent and shouldn't affect eachother? That is only true for linear systems.
I am not sure what causes the other sounds to sound dampened, I figured it had something to do with how the ear works, that the sounds were physically still there.
But it is easy enough to try. Get a speaker or transducer rated for ultrasonic frequencies, and pump it with enough power that would make a real speaker sound painfully loud.
> Look at an audio file's waveform before playing it at max volume.
This is important, but more broadly, practice good sound hygiene: wear headphones them around your neck until you know for a fact that it's safe to put them on your ears. Additionally, never play "new" sounds without remembering to set audio output to a tiny fraction of normal and increasing it after the sample is deemed safe.
Musicians have this drilled into them because it involves their daily work, but this is good advice for everyone. Damage to ear drums can be permanent.
Also: put a limiter on your audio bus if you're exposed to such risks regularly. Don't play sounds directly, but open them from a host program that can apply VST/AU/... effects, and make sure there's a (brick-wall) limiter at the end.
And if you have been exposed to a very loud noise, to the point where your ears are ringing (probably not from headphones, but like starting a loud bike in a garage or gun fire), go to hospital, as soon as possible. They can give you medicaments and prevent permanent damage (tinnitus).
I have tinnitus. You don't want tinnitus. Silence is no longer a possibility for me. I got it messing about on computers and with loud cars in my teens, so unfortunately it was just a dumb kid thing that will last a lifetime.
I hate to guess how many kids are giving themselves tinnitus right now. It's just not possible to communicate the seriousness of long term problems to kids, they have no context for what long term really means yet.
Sorry to hear that, but I appreciate your words of warning. I go to loud clubs / live music a lot (pre covid) and despite knowing I should probably wear earplugs, I don't. Perhaps club revival post-lockdown is the time for me to begin.
In a pinch, you can use rolled / crumbled scraps of paper towels from the bathroom. It's quite common here (Berlin) and absolutely no one looks at you strangely if you do that. Some good clubs only have the bass really loud but it's not as common as it should be. High frequencies are what causes ear damage.
They are pricey, but such a good investment. Way better than anything else I've tried, more comfortable for extended periods of use and most importantly they attenuate the sound fairly evenly across the spectrum.
My only advice is to get the string attachment option, so that you can't accidentally lose one of them!
I just got myself a pair of custom earplugs from https://1of1custom.com/ which are absolutely amazing.
I ride a motorcycle and needed something to make sure I don't lose my hearing from the wind noise/exhaust noise (it's stock, but still 85 dB when the throttle is open).
They are also great for concerts and live music events where the speakers are generally cranked up to 90 - 95 dB.
I got the 27 dB version, and it allows me to hear what people are saying above the the music but really cuts out the painful parts.
They are not cheap, but I already have tinnitus, so I want to make sure it doesn't get worse.
Totally worth getting some nice-ish earplugs IMO. Even just getting a $30 set is such a wild improvement, comfort-wise, over those horrid foam earplugs you see a lot of people use.
This was a practice I had to adopt for a period of time where connecting my Sony bluetooth headphones to my iPhone would reset the system volume to max, sometimes only after I had pressed play on Spotify. Numerous occasions where my ears were instantly blasted with whatever music I had last paused at maximum volume trained the habit.
It was finally fixed a couple updates ago, I think around when they introduced the health feature to track whether you've been listening to music too loudly. Go figure. It had been getting frustrating enough that I was ready to write a blogpost wondering how much cumulative hearing damage had occurred across the iPhone userbase as a result of that bug.
I'm not sure if you ever write rage comments, just laced with profanity and nonsense, complaining about the situation at hand... I've written my fair share, I used to work with a lot of perl and bash, and I'd come across some disgusting ideas that had made their way into scripts and utilities. Naturally, finding some of that crap after an hours long search for some bugged behavior, it can be very frustrating and irritating to find out that it all stemmed from someone doing an easy task in a stupid way!
I once had someone leave me a message on my desk phone referring to one of these comments verbosely, and I happened to be listening to my messages on speakerphone as the day was almost over and we were all doing our little ritual tasks before we walked out the doors for the evening. So, this comment starts being read and all my neighbors are packing up their lunchboxes or tidying papers on desks, etc. As the message went on, I could hear the silence enveloping me, because of course it was wildly heinous, and I just froze up and let it play out. It wasn't that I couldn't have jumped over there and hung up the phone but it was so casual that it just caught me off guard that someone would read that awful crap I wrote right into my voicemail! I remember the end being sorta like "anyhow, that's not a very good practice, so don't write them like that anymore". I don't really even remember exactly what happened next other than leaving with my tail between my legs. I don't think anybody mentioned it to me. I guess it seemed worse in the moment of it.
This was well over 20 years ago now, I was basically brand new to everything. That was a turning point, thankfully enough.
Reading open source has exposed me to a LOT of different commenting practices. I don't really think about it often enough, but the human on other side is always the most important consideration.
Not sure if this qualifies as my own code but I have a highly modified 3D printer, I had upgraded to more modern trinamic stepper drivers which have sensorless homing and I had forgotten to set a sane value for the torque limit to let the drivers know when it had hit the axis' limit when I ported over my existing firmware config and like an idiot decided to use my finger to test it... I learned that day even small stepper motors have finger crunching torque and that under sudden intense pain you will forget where the power switch you've operated 1000s of times is located.
Yes, I setup a DDP to figure out how I can make my own TNF blockers using nutrient intake optimization.... yada yada yada. Immunomodulators and the immune system are really complex and now I have 2 detached retinas.
Yes, I have Crohn's and I do not like to take the meds or listen to the doctors. This is NOT AT ALL SOMETHING I RECOMMEND, PLEASE DO NOT ATTEMPT IT.
Crohn's is an auto-immune disease and the main class of drugs that is used to treat Crohn's like mine (long term) are called TNF inhibitors or TNF blockers.
TNF alpha triggers the production of several immune system molecules, including interleukin-1 and interleukin-6. I realized I can track this with basic inflammatory marker test, I also realized that I could use diet to impact my markers. So instead of taking what is referred to as a Biologic e.g.: Adalimumab, Certolizumab etc... I started using NIO to try and get the same effect.
I got a pill making machine, and learned how to make supplements but they were not working well enough so I knew I needed something stronger. Then I found this article: https://pubmed.ncbi.nlm.nih.gov/32311496/ I think it was on HN but I do not remember for sure. I order some modafinil and worked it into my mixture.
I do not manually create my mixtures because I do not want to know which version I am on, I want my symptoms to go away and that should be the trigger to tell me if its working. So I have a 14 vile setup with an audrino all wired into my press and based on my food diary (e.g.: nutrient intake) it decides how much of what should go into a run. e.g.: how much burdok, tumeric, serrapeptase etc...
I got something wrong and ended up adding far too much to a run of pills, I didn't realize this until i started ti see floaters in my eye and I checked to see how much moda was left and it was far less than should have been left.
Then i did some reading and a side effect of taking too much moda can be detached retnas, since I have all the symptoms: Floaters, stars and peripheral flashes I am assuming that based on the timing I now have detached retnas, I also found my mistake and essentially no matter where my markers were I was getting about 600mg of moda per day. Which is far more than should be taken. This was for about a 1 month period.
I have fixed the issue now and I have a much more sophisticated pipeline but I will have to get this fixed.
NOTE: I am not a doctor, I have no college education or anything like that. I just like bio-hacking and decided to pursue my moonshot during the pandemic. I can explain more or provide pics and vids to explain further if you like, email in profile.
I am currently writing up a 100% independent non peer reviewed case study to document everything I have done and the results.
LMAO, this was really funny. I did not really think of it as blind I just wanted to remove confirmation bias. I saw so much of that at goop. I have no formal training and I just learn on the fly and try to execute. I have no doubt there are better and smarter ways, I would love critical feedback here or via email.
I'm not sure I have any useful advice; I get the impression you're doing incredibly well for someone with no formal training. On the one hand you might benefit from someone with a more rigorous background helping you avoid known non-obvious risks, but on the other hand almost all such people are going to run screaming because your risk tolerance is way higher than theirs. Having a chronic condition for which the existing treatments are inadequate really sucks. I wish you luck and safety.
(For the "era of higher risk tolerance", the good old "Ignition!" by John D Clarke is a fun read from the era when the official US rocket fuels programme consisted of just lighting stuff on fire and seeing what happened)
All of my "buddies" kind of abandoned me pre-pandemic. Much of what was driving me here was boredom, curiosity and solitude.
The CEO/Founder at my old job used to kind of check-in on me from time to time via slack, she thought my work was cool which kind of helped me keep going once I was no longer at the company.
What in the everliving biohacking heck? I though I was leaning into things by modulating my caffeine levels based on workload (just dissolved in liquid and pouring out X mls based on need). I've thought about having a dispenser I could track metered doses with, but arionhardison here has a robotic pill press. Man, I gotta up my game now.
I wouldn't be comfortable without some sort of closed loop to be reasonably confident it was dispensing what it claims. Also helps to have the active ingredient pre-diluted so you are mechanically capped at a certain volume.
I am using pre-diluted (or mash paste) in some cases, I have no idea how else to do it. I would actually need a mechanical weighting system and that would be really hard to manage. Moda was not really a liquid mixture but more of a paste at this point and I use stops in the vile. For example. Each vile has 5 stops and each stop has a MG associated with it. There are smarter ways of doing this im sure but they involve more ME than I know how to do.
Wow. That’s... bold. One suggestion, maybe have it email your dosing to a trusted person so a human being can at least establish whether the numbers look approximately right? Although that still doesn’t cover any mechanical failures unless you’ve got a rock solid redundant closed loop setup. To be honest, the whole thing sounds ill advised, but I guess you already knew that.
< unless you’ve got a rock solid redundant closed loop setup
I do not
I do not even know who I would send it to honestly.
I am obsessed with this work now which is why I am expanding my provider network to other countries.
I found that things I think are "experimental" are much more common overseas probably due to a lack of regulatory controls but the result is that there are really smart people with a plethora of knowledge about these things as where my western doctors were not that knowledgeable or willing to really listen.
If you have any suggestions it would be awesome if you could email me.
I'd imagine having a strict boundary between "software thing that calculates how much you need" and "robot thing that mixes stuff together" would help, and you'd set up guardrails and unit tests on the calculation part.
Worst case you could have physical guardrails such as "can't take more than x mg per week" in the form of only supplying a certain amount of raw materials and topping off intermittently. If you run out you find out sooner instead of a month later.
I am using a 5 stop vile system right now, I don't even know if thats a thing the big boys do or not but its the only way I knew to handle things without needing to using lasers or mechanical weighting systems; both of which I have not the least bit understanding of.
Yes, it is one of the therapies I am currently studying as I have had success with it but it does not scale. The reason I want to do this is so that I can create a Medicare/Medicaid E2E single payer solution that provides these solutions to everyone. Even people on the lower socioeconomic rungs. The pandemic was really hard for me and I have been behaving very recklessly in terms of my own health but I have been very responsible in terms of other people health.
I was running an outpatient program for alternative therapies before I knew that you cant just do that, you need insurance and stuff. So now I am making my own Medicare/Medicaid and hope to bring all of my work into a single payer system. There is no way I can pull this off, my only hope is to attract the attention of some really smart people that will tell me why and how I am a moron and how to fix it, lol.
I would love to talk about my work with someone but i'm kind of still scared because its not in a state that is 100% ready for end users and I know everyone is just going to laugh at me, lol. Hell I laugh at me. But I worked at goop and i know more than everyone there so i'm kind of like ... fuck it. Just code / Fierce Nerd blah blah <insert-some-rationalization-here>.
Right now I am having fun exploring the world of BHM HMS modules, its far less regulated than I thought it would be which might not be a good thing, but we will see. I am going to do a "Show HN" soon but I want to publish feedback from my active patients and providers first.
As someone with autoimmune issues who rarely checks HN but is very interested in your work, do you have a newsletter I could sign up for or an email address I could reach out to to receive updates on your work?
Yes, I also am dying to just talk to anyone about my work and what I am trying to do. I am very approachable and I CRAVE the most vicious, critical feedback that I can find. You can email me (email on profile) as the newsletter stuff will not be done for at least 1 month.
Well, this was finally the thing that made me get an HN account, because I am really interested in talking with someone about that kind of stuff. I can't see an e-mail in your profile though, and as far as I understand noone can see your email you supplied in the email field, and your about section looks empty to me.
Because I am "literally" trying to recreate a better version of medicare and Medicaid. Those terms are not trademarked. If you look at Medicare.gov and Medicare.com you can see, the term is actually used a ton and the gov does not care. They care much more about bad-faith actors. One of the main benefits is I don't have to tell "regular" people what I am trying to do. This is my "moon-shot project so even if it was an issue I would not change it just to cause a big fuss and get the press from it. The bigger issue was using all of the state HHS logos, but they don't really care about that either.
In preparation for my big launch I needed to test the "do they care" theory so I literally did 2 press releases.
1 targeted directly at the D.C. area and one nationally, every contact they have made with me has been a positive interaction.
I paid for someone to handle this for me, really embarrassed by the title but in their defense I have won 7 health hackathons; much of that work inspired what I am doing here.
Ideally I get to a point where my systems are so much better than theres that I can promote services from .dev to .gov, I really have not thought that far ahead but I would love to discuss.
I'm not a trademark lawyer so take this as you will, but the term Medicare has been trademarked since 1957, assigned to the Executive Director of the US Army.
Just because you haven't run into a trademark issue yet doesn't mean that you will not in the future. And I don't think I'd want to be fighting the US Army lawyers for the naming rights.
I love your initiative, but you may want to look into the naming issue a bit further (since this is what trademarks are explicitly designed for, to prevent confusion about one product/service doing the same thing under the same name).
Not OP, but I have done this for allergies. N. Americanus, 10-15 eggs at a time. No side effects other than an awful itch 12-36h after administration. Been great for my allergies. I've cut way down on fexofenadine. I also live with a cat and a poodle and only really feel symptoms if I literally rub my face in the cat, or groom the dog inside without a mask.
If you would ever be willing to discuss your work and hear about mine, that would be awesome. AGAIN, I AM NOT A DOCTOR. But I really love this stuff and have started to study for MCAT just so I know more and dont feel like such a moron.
Having worked in research on Crohn's this sounds wild.
Why would you not take the biologics if you can afford them? Side effects?
What you do is of high risk to yourself and of no value to others.
Let's discuss in public, I think others might be interested. What do you mean by scale?
Are you saying that the biologica are too expensive and you are looking for cheaper solutions? Apart from the price AFAIK they are the best known solution.
In that case hurting yourself trying to find sth. cheaper is not worth it, because:
a) it is bad for you
b) it doesn't help others either, since even if your special cocktail ends up working for you it will most likely not work for others.
I would focus on making tnf-a blockers cheaper, probably by circumventing or straight out ignoring the patents. This stuff is not rocket science anymore.
Have you researched the prices in other countries? Looks like in Europe its below 2k€ per month but more around 20k in the us? Whats the price in India?
> Let's discuss in public, I think others might be interested. What do you mean by scale? Are you saying that the biologica are too expensive and you are looking for cheaper solutions? Apart from the price AFAIK they are the best known solution.
In that case hurting yourself trying to find sth. cheaper is not worth it, because: a) it is bad for you b) it doesn't help others either, since even if your special cocktail ends up working for you it will most likely not work for others.
OK, lets start with just the official stuff that they actually admit.
HUMIRA can cause serious side effects including hepatitis B infection in carriers of the virus, allergic reactions, nervous system problems, blood problems, heart failure, certain immune reactions including a lupus-like syndrome, liver problems, and new or worsening psoriasis.
Do you see a trend here? Auto-immune treatment causes more auto-iummune diseases. Thats real sus to me.
> I would focus on making tnf-a blockers cheaper, probably by circumventing or straight out ignoring the patents. This stuff is not rocket science anymore.
You are actually trained at this and I am not but I do not understand why youy would focus on alpha when beta is far more cytotoxic. Like I said, I don't have your training but that seems odd given the rate of colo rectal cancer in Crohn's patients.
Given that the entire family of drugs refers to Cytokines which is cell-death it seems a bit asinine to focus on alpha.
> Have you researched the prices in other countries? Looks like in Europe its below 2k€ per month but more around 20k in the us? Whats the price in India?
India does not sell the name brand I am familiar with; they have Zydus' Exemptia and its around $4,500 USD.
> What do you mean by scale?
I mean scale. Given that N patients have Crohn's and wish to treat themselves with Z. If Z is a finite resource what are the obstacles to Z being produced and distributed at a "scale" great enough to reach each patient, for life.
> it doesn't help others either, since even if your special cocktail ends up working for you it will most likely not work for others.
Please provide some form of empirical evidence to support this position, I was saying in private because I have actual clinical outcomes that i can report form myself and a number of others, but doing so publicly is not ethical or legal; HIPPA and all.
Can you expand a bit more on what you meant when you said you were a researcher? Possibly point me to a white paper or jupiter notebook, anything so that I may get a better understanding of your work.
I do not even know how to begin to address the reductive nature of pharma disco and production "not being rocket science" other than to state the obvious, yes it's not rocket science its bio chem.
I am sure i'm just missing something given that you work professionally in the field.
FYI: It has nothing to do w/ the price at all, even on the worst medical/medicare plan humera is only 250 for 2 viles and it was less, now it just has the extra lux tax.
Not my code, but somewhat related: I almost hurt myself when my friend used a sonic weapon on me in StarCraft.
Back in the ancient days, my friends and I would meet every Saturday and go to an Internet cafe for a few hours of playing multiplayer games over LAN. Mostly StarCraft: Brood War, with a mix of Unreal Tournament and Quake 3 Arena. During the week, we'd all play these games alone, in single player, figuring out new tricks to unleash on each other the next time we met.
One of these weeks, I've learned how to properly play Terrans against the Zerg, and was about to demonstrate my knowledge by steamrolling my friend with an army of Marines and Medics[0]. In that game, my friend went for his usual tactic of harassing me with Mutalisks[1] - an effective technique, as long as he avoided the main body of my army. Well, on that day, he wasn't careful enough.
At one point, he accidentally flew his entire (by that time pretty big, I think 24+) swarm of Mutalisks straight into my M&M army, which was just staging to launch an attack. My units took about 5 whole seconds to destroy most of his force - but the overlapping audio of dying Mutalisks pretty much saturated my headphones with high-amplitude noise. This was so unexpected that I wasn't able to comprehend what's going on around me (both in-game and in real life) for good 30 seconds, my vision blurred and my head was spinning.
Having wasted his entire army, he lost that match. But I keep thinking that this could have been a viable stratagem. If he sacrificed half of his army like this to break my focus, he could've crippled me with the other half. And ever since that day, I kept my headphones at half the volume.
--
[0] - M&Ms, aka "bio", was the usual Terran army composition against Zerg players in Brood War. Zerg armies consist mostly of weak but cheap units - compensating individually low DPS and health with quick, mass production. Terran Marines are also cheap and low DPS, but in 2:1 ratio with Medics, they're healed faster than Zerg units can kill them, so a big ball of M&Ms is unstoppable to an inexperienced Zerg player.
[1] - Weak, cheap, annoyingly fast flying units. Perfect for distraction, but their low DPS makes them completely useless in a straight fight against Terran "bio" army.
Hahaha okay I have to share a similar story now of where I've actually seen this weaponized. Also not my code but somewhat related.
Somewhere in the range of 10-15 years ago I played Guild Wars somewhat competitively. I was in one of the top-20 PvP guilds, and most of the top PvP guilds were pretty friendly with each other. Very rarely, we'd be good enough friends with an enemy guild that we would know their Teamspeak or Ventrilo server credentials.
So one day, we're doing our nightly battles like always and we get matched up against one of our rival / best friend guilds. A couple minutes into the fight, one of our Mesmers says
"Hey uh guys. So.... This might be a bit much. But I know their Voice Chat login. I could spam their server right now."
"Do it."
So we all hear the "user left" voice thing, 20 seconds later, "user joined". And apparently what he did was open the text-to-speech tool, meant for users without microphones, and entered "!@#$%^&*()_" except copy pasted a thousand times.
Which means the other guild heard from the robotic text-to-speech: "user joined. User Ha Ha Got U says Exclamation Mark, At Symbol, Pound Sign, Dollar......."
They're talking trash about how could we sink so low in the global chat in-game when suddenly we hear "user joined. User Ha Ha Got U Back says Exclamation Mark, At Symbol, Pound Sign, Dollar......."
There was a way to disable the text-to-speech on your client, but none of us knew that at the time. The text-to-speech rambling continued the entire night on both our servers and neither guild was able to speak. Both guilds thought it was hilarious but agreed never again.
Love this, thanks for sharing. I'm sure I'm not alone in the HN crowd of having fond memories of BW playing days.
The sonic weapon, while accidental, feels similar to tactics used to disrupt concentration and logical thinking. E.g. taunting, trolling, cheese strategies, or your opponent getting tilted from something you didn't intend to annoy them with.
Often think of how keeping a cool head is incredibly important in games like this, specifically for the pros. IdrA comes to mind as a technically gifted player who was often his own worst enemy due to his temper. He never did crack into the top of the pro scene (hard to do as an American in general) but felt like he really held himself back.
> feels similar to tactics used to disrupt concentration and logical thinking (...) trolling, cheese strategies
Yes, we did plenty of that.
Between Internet cafe days and high-school SCBW matches, I think I've got a dozen people to fall for the simple trick of writing "[a bunch of spaces to manually center the message] nuclear launch detected" on chat[0]. Most of the times it only caused a laugh from everyone, but once I actually won a game this way.
It was the late phase of a match, myself and my opponent were in a sort of stalemate - his army held a strategic position; we both knew it, so he just held position, and there was no way I could get through[1]. Not sure how to solve this tactical riddle, I just pressed ENTER and sent the " nuclear launch detected" message. It caught him off-guard, and in a moment of frantic confusion, he decided to move his army elsewhere. Of course, there was no nuke, but I suddenly had an opening I could exploit and win the match.
EDIT: I miss the tactical depth of SC:BW. I haven't seen any other game that came close. Not even StarCraft 2. In particular, all the cheese strategies we tried against each other. Most of cheesing happened early-game, but I was particularly fond of creative abuse of Terran Science Vessels in mid-to-late game...
--
[0] - For non-SC players: Terrans have tactical nukes in their arsenal. Launching one causes a warning message (and audio) to appear for every player, which gives the opponent a few seconds to try and figure out where the nuke will land, and either kill the unit that's laser-guiding it in, or evacuate from the area. People who played SC a lot develop a habitual reaction to this message, overriding whatever they were doing and thinking for a moment.
[1] - I unfortunately don't remember the details about the tactical situation and composition of armies. All I remember is that I was playing Terran, like I almost always did.
This works in Age of Empires 2, too! I've seen a number of videos where a player writes "x has arrived in the Imperial Age" at a point where it would be devastating and the other player resigns.
Skin/eyes: experimenting with high-brightness LEDs. These can become pretty hot in no-time. I was trying to do my own LED driver (regulating a PWM signal from voltage/current sensing), on an LED without heatsink. Because of buggy code, it started to burn my table, and by reflex I tried to pull it up with my hand....
Not to mention the countless times a white spot remained in my vision for hours, after looking at such bright LEDs (buggy PWM signal regulation algorithm that kept going from dim to super bright randomly).
Ears: every time I write a driver for an amplifier/DAC with headphones output. No matter how many precautions I take. It is going to happen anyway (wrong register configuration, the default volume was too loud, etc.).
Also while listening to mic recordings done with a buggy/incomplete software.
I tried to automate mouse moves, keystrokes and screenshots to take a higher-res picture of an area in Google Earth. Something went wrong and it got out of control. My attempts to stop the script were futile as the automated mouse steered me away from the code window. The spinning, gyrating earth rapidly made me seasick - had to close my eyes and fumble my way to the power off button. Stretching 'hurt' but it was a memorable code fail nonetheless :)
I feel like Industrial Automation is cheating, especially if you're working with a lot of tradesmen/clients who refuse to follow safety procedures.
We were commissioning a rather large food processing facility and had already verified that our PLC->Motor Starter wiring was all valid, but at some point the client decided they're ready to run a production line without testing the Motor Starter -> Motor wiring (bump testing the motors).
Normally you'd have people away from the equipment, proper lockout, people with radios verifying operation, all that jazz, but the client decided to go around us and just start turning things on.
Well when they went to turn on motor in section A, a drag in section B started due to some mistakes by the electricians. Section B's motor just happened to be straddled by a welder who was standing over it to do some work on an upper walkway when the thing fired up beneath him. Understandably he was pissed.
I've never had an injury on the job (thank god) in the 9 years I've been doing this, but there's been a handful of close calls. 100% of the time its because people skip safety procedures and think it'll be fine.
The client never did learn their lesson I'm guessing. We went home for the weekend, "Days since last work stopping injury" was reset when we returned Monday. Not sure what happened there.
Easily. Got ear infection (!) from an unexpected, very loud random noise in my headphones (just one channel) as a result of a bug in my CoreAudio code.
What does CoreAudio do if your floating point audio buffer is filled with random numbers? That's right, it plays random noise at the maximum possible level, bypassing the system volume setting.
Why ear infection? I have no idea, but my GP explained that it's quite possible even if the eardrum doesn't get damaged. Which in my case thankfully it didn't.
If the system volume is a multiplier and the float values have large exponents... Small times huge ~= huge.
I guess safe volume control should ideally limit the output energy. Energy is proportional to square (or so) of frequency, so ideally it would take that into account as well. That rules out simply hard-clamping sample values because that creates high frequency / energy distortions. Not trivial, especially if low latency is also required.
Exactly and it's not obvious at first. You can easily see that the system doesn't limit the FP audio in Logic Pro: you can in principle crank up the volume all you want. So if the system volume multiplier is, say, 0.1, you can have a buffer with values -10..10 and that will play at maximum volume fine. Everything beyond that will get clipped by the DAC.
So random FP noise clipped is still random FP noise at maximum level.
I hit this bug just the other night, and I think what caused it was accidentally sending NaNs to the audio API. That bypassed whatever clamping functions were in place, and just produced an ear-piercing shriek. Very unpleasant.
I always wanted to make an electric skateboard. After a few successful iterations, I decided to make a really fast one that could replace a car. I built my own lion battery out of ~500 18650s. It could go about 30 miles on a charge. It could go about 50mph. It was a very wide body with huge air filled tires. It could pull 10 of my friends up the steepest hill. It was very powerful because I installed an electric motorcycle engine on it. My one extra stupid move was I didn't account for the battery dying at high speeds. Normally I'd stop well before an empty battery but I only had 3 LEDs of primitive battery indication. And that only measured with voltage. Voltage fluctuates wildly in motorized vehicles. It died while only going about 20mph but up a steep hill. The sudden loss of forward momentum flung me off the board into the pavement where I flipped a few times and scrapped across the pavement for a while. Was a painful lesson.
Oof. I didn't realize "harm" was meant so literally. At least it was a one-time thing, though... right? I read "had several thousand WAV audio files that I generated" and expected to read something of the form "I corrupted several thousand important data files irreversibly".
Haha yeah. I've definitely "harmed" myself in the form of time lost from deleting files/messing something up on my computer, but I think this was the only time I've actually experienced physical pain from my own bad code.
I once programmed an arduino driving multiple solenoids with felting needles at pretty high speeds (wool felting uses needles to push wool fibers together into shapes), all pointing to the same target area, at slightly different timings. In the perfect case, it worked really well. Felting needles however bend and break with heavy use, leading to colliding felting needles projecting toward my hand. Ouch.
It didn't happen to me personally, but I worked on a flight simulator. Not the fancy kind which moves around but it still used hardware from the real cockpit, including the stick and its actuators.
And if the controller is not properly initialized, the stick will slam left and back, hitting the leg of the guy in the pilot seat. For men, it can be much worse...
Another bench had a real aircraft gun mounted on a turret that is also controlled by software. No ammunition of course, but it is still a big metal pipe swinging around at great speed, thankfully, that one was fenced because that's the kind of thing that can easily break bones, maybe even kill you on a bad hit.
I've melted a table once. Was testing a heat controller, and had the debugger left on.
When the laptop the debugger was running turned off, it also stopped the code from running on the microcontroller, leaving the heater on without adding any new controls.
It was a good learning to make sure there's a watch dog circuit, and that the microcontroller is much less trustworthy than the fpga
I've done this debugging a system with a pneumatic controller on one of the threads. Hit a breakpoint with the compressor still running and after a minute, hoses start blowing off. It happened often enough that we learned to not use hose clamps since losing a hose connection was a safe failure point.
However, I've read about the same thing happening to a couple guys testing a tank turret rotation controller. Controller is paused at a breakpoint, but a hardware counter is still accepting error pulses. Start running again and the error built up enough to command a full speed slew, sending the engineer who was sitting on the turret slamming into the wall, breaking a few bones.
Did something similar to OP. I was writing a controller for a streaming system and managed to accidentally set the volume to 100. This was with speakers not headphones. I had to pull the power plug to stop it. Just about gave me a heart attack.
The bug was a feedback loop in the volume control code that somehow ramped the volume up without any way to stop it. After that I always tested with a physical volume control later in the audio chain, with the volume set to a medium level.
I've once started a small fire. I had a software-controlled voltage regulator connected to the printer port (it was for a high-voltage programmer for 8051 chips) and I was writing a Linux driver for it. I accidentally put the chip in backwards... I ran the software and suddenly had a physical manifestation of lp0 on fire on my desk. ;)
I’ve gradually developed the same instincts around mechanical and home improvement tasks. “How could this five-minute task turn into a multi-hour nightmare?”
Examples could be spilling a poorly placed can of paint all over the carpet, or having a nearly unobtainable fastener fall somewhere inaccessible (or where it can do damage).
I've made the mistake in this article by piping something that wasn't uncompressed audio to /dev/dsp. These days I prefer to work with speakers with a physical volume knob and start it at 0 with unknown sources... you just never know what the yahoos upstream are sending you.
I was taking a class in software security and had a homework assignment to demonstrate a buffer overflow. For extra credit, we could have our exploit play music without invoking exec. My approach to this was fairly straightforward. Using ffmpeg I converted the audio to raw 16bit little-endian PCM. Then I appended this data to the end of my exploit. When my exploit runs, it sets some ioctls on /dev/audio then starts copying the data from the end of the file to /dev/audio causing sound to play.
As you might have guessed by reading the article, I had an off-by-one error, causing the music data to be misalligned and loud static to play. Fortunately, my system volume was not particularly high, and I was happy to even get sound to play. I never figured out where I made an off-by-one error, since I had just assumed that the static was caused by an alignment issue that could be "fixed" by adding a 0 byte to the start of the audio data.
I haven't ever hurt myself with my own code, but I have done the reverse. I work on COVID research, and one of the programs I maintain involves pulling the data on all our the COVID patients and vaccine recipients enrolled in our study. One day, it was my turn to get the vaccine, and I also volunteered to enroll in the study myself. However, they were unable to find a vein to take a blood sample, so my enrollment was cancelled. After I received the vaccine, I went back to my home office and continued working on my program, which immediately crashed.
I drilled down on the offending database record, looking in the demographic data to see if something was wrong. After staring at it for a few moments, I realized that the demographic data looked... familiar. And then it hit me: my own enrollment record from that day had been left in an inconsistent state in the database that my program was pulling the study data from, due to the failure to collect a blood sample. This resulted in my program crashing on the inconsistent data. So I had to add a special case to my program to handle my own failed study enrollment from earlier that same day.
Mistake #1: Should not have had my volume that loud.
I always keep the volume low enough that a full-amplitude noise wouldn't be anywhere near physically painful to listen to, but then again most of the stuff I listen to is ultra-compressed already...
Of course, the actual bug is that the audio is in units of samples, which are only 1 byte in the case of mono 8-bit format, so treating the file as being 8bps mono when it could be 16bps mono, 8bps stereo (far more subtle difference in the case of byte misalignment), 16bps stereo, or any of a number of other formats is always going to lead to cases where this could occur.
I've been slowly building a homemade quadcopter over the last few years. One of the first times I tested it out it with all 4 motors it immediately headed my direction and caught me in the ankle before I could get out of the way. Nothing a bandaid couldn't fix but it sure sucked.
At a very "lean" company that made power electronics (modular telecoms rectifiers and 1.5-5kW grid-tied solar inverters), I nominally worked as a test engineer but I wound up doing a fair bit of EE/firmware work on the products too. Above my bench was that typical drop ceiling stuff like in offices worldwide, except mine had little singed bits of semiconductor packages stuck in it from where things had gone wrong in testing and blown up transistors and such. All of us who worked with open electronics (often necessary during development, for probing or whatever) had earmuffs and safety glasses at the ready, and a wood stick for pushing the on/off switch. AFAIK there weren't any real injuries, but there certainly was potential.
My favourite near-miss was the result of a dumb EE experiment, not really code: I had built an 8kV surge generator to test against IEC 61000-4-5, and needed to test the generator itself. We spent an afternoon finding interesting components to blow up, at first under a shield, but the good ones would just make a satisfying snap or pop - not too exciting from a kinetic perspective. Then, I noticed a DVD... The surge through the foil in the DVD made one of the loudest bangs I've ever heard - easily louder than a gunshot - the foil vapourised and sent plastic shards all over the office.
The surge generator itself was a glorious hack; it used a neon sign transformer to generate the HV, and the main switch was a trigatron I made from a couple doorknobs from a home recyclers in the same industrial park.
I program CNC lathes in G-code for a living, so yeah. Dodgeing shrapnel is part of the job. A missing dot could cost thousands in repairs and result in loss of life limb.
There is usually an aptitude test for machinists. Not everybody can do it fast enough safely.
Good machinists are something akin to lion tamers. CNC machine tools inspire a special sort of horror. They're mechanical beasts that growl and groan, ready to lunge at a moments notice with sharpened fangs, and will disembowel you if you let them. Working with a machine that will happily blow itself to pieces with a few errant keystrokes does wonders to focus one's attention. You learn to move carefully and deliberately in their presence.
I'm a software developer who has had occasion to program a CNC mill and lathe over the past few years. The relative banality and physically harmless nature of software bugs made in my normal job made the stakes seem so much higher by contrast, when touching machine tools. I partly credit this "culture shock" in helping to keep me safe and the equipment undamaged - apart from a trio of snapped endmills on Day 1 (F100 instead of F10).
I can definitely echo that the ability to work safely, quickly, is one thing that sets the pros apart. I'm glad I have the luxury of time that light production affords.
I managed to program a 'hard interrupt' into my skull so that before I press the play button I at least have brought into mind what I expect to happen... It usually works. You have to keep a lot of state in mind, and when you run multiple machines at once you do get immersed in the flow and time flies. It is a power trip when you're punching buttons with complete confidence like you're part machine yourself. A quick one to come down from too. :)
I think the dumbest way I could have hurt myself was trying to build a DIY laser cutter with a 2W IR laser. The catch is that you don't know wether it's on or not. As they say in the laser community "Don't look into the laser with your remaining eye".
The most consistently hurting project was a plotter that printed images with milk (don't ask why), it used a heating part to reveal the drawing. When a paper jam creates a fire you sure want to be near during a print job ! Plus burning my fingers a few times (lost some parts of my fingerprint on one of my thumbs).
My first ten minute as a lab instructor in a full intro to computing class. I was standing talking and backed up a bit stepping on the leg of my swivel chair. I fell right on my ass hard. Cracked a joke but the whole class of about forty students didn't laugh or say a word. Was rough and I was showing some code at the time and I blame this on the code to this day.
I don't know about hurting myself specifically, but at my first job I programmed PLCs. You know, those little computers that control industrial machinery... my code could definitely hurt something (or someone).
One example that stands out is a case where we had a heating element to seal plastic bags. It turns out those heating elements get ridiculously hot and only need to touch the bag for a fraction of a second. Naïve me felt that 3-4 seconds was a "reasonable" amount of time for a first attempt...it caught on fire.
Not exactly but I've been mashed, crushed, cut, scraped, shocked (static), etc. many times by the FIRST robotics team robot I mentored as code ran haywire.
One time I got run over by my FRC robot causing me to shout a profanity around a bunch of probably very disappointed adults at the competition. Not my proudest moment...
The story is we were testing some autonomous code I wrote and it stopped moving because it was hanging waiting for on some sensor data. Without remembering to disable the robot first, I walked over to it and found the sensor wasn’t plugged in properly. Plugging it in, the code started running again and proceeded to drive up and on to me...
Nowadays that I work with industrial robot arms (specifically ones with 24,000 RPMs of death on the end of them) I am very aware of how important safety practices are knowing how easy it is to slip up.
Not my own code, exactly, but back in the day I was trying to get a balky dot-matrix print head working and accidentally sent power to it while I was holding it.
I had a row of dots tattooed on the ball of my thumb for a year or two afterward.
While at university, late night coding an assembler assignment, I had a bug in my code, and the compiled code would lead to some CPU violation.
After running the code, the CPU started making a super loud high frequency noise. The code was a super tight infinite loop, co CTRL-C did not work to make it stop. Hell, even power button of the laptop didn't react! Everything was completely unresponsive.
It was middle of night and my laptop was about to wake the whole neighborhood, and the only solution I found quickly was to remove the laptop battery.
Luckily I had a removable battery in my laptop back then!
Yes, I gave myself tinnitus while working on audio code.
Turns out debugging audio code and wearing headphones is a bad idea when your code sometimes randomly generates sample value changes from -1.0 to 1.0 :o
I learned that you could pipe anything to any device. Decided thirteen-year-old me was an avant-garde artist who would pipe my hard-drive to my speakers and create beautiful works. Was that just a `cat /dev/hda1 > /dev/snd` or something like that?
Incomprehensible shrieking. Later that year, someone posted about the thing that would become the Internet phenomenon called 'Anonymous'. I am certain that idea was birthed from the wailing portal of hell I summoned that day.
When I was in college, there was a introductory signal processing course. We were using a LabView based FPGA, called myRIO.
In one of the labs, we were doing audio processing to filter out noise from the audio and listening on the headset. Towards the end of the session, we were messing up with the code to see what else is possible.
Anyways, I accidentally set the gain so high somewhere, while wearing the headphones still and played a tone. I almost got deaf. It still gives me chills to think about it.
The WAV format is not mixed-endian; everything that’s actually a number is little-endian.
The fields the diagram in the article marks as “big endian” are ASCII text— four-byte strings with specific content (“RIFF” for the first ChunkID, “WAVE” for the Format, etc.). If you wanted to treat those as integers in your code, you’d need to treat them as big-endian so their byte order doesn’t get reversed, but they’re really four-byte sequences, not numbers.
I've had this come up with composite data formats. If your data formats includes already existing data formats and they do not all agree on an endianness you are basically stuck with being inconsistent about it.
Yeah I was kind of confused about this when I was reading through the spec trying to figure out what went wrong. I wanted to touch on this in the blog post, but I wasn't able to find a good resource explaining the advantage for mixing endianness in a file format.
Because the important thing about those fields is that they aren't really big endian at all, they're clearly ASCII characters. Why the spec you have decided to say they were big endian is beyond me.
Obviously not ideal, but it could for instance come up when the file format has one overall endianness but wants to include fragments of data conventionally encoded with the opposite endianness. Trivial example would be a .tar file containing an assortment of other files, but this would also include say embedding network endian data or images within a larger file that contains other data.
This would be the case for 16 bit samples (which all of my files were, and most WAV files are nowadays), but for 8 bit samples, it would be correct to remove single zero bytes. Basically I just have to follow the spec more closely
A decade ago I wrote firmware for a printer company. One of the cases we needed to handle was to check if the print head would go back to the home position if I block it with my hand. Being the new guy and wanting to follow instructions I did literally just that. Later on I find out that the QA guy who wrote that test case was just messing with me. The other devs used a pen.
If anyone has trouble with normal (not-obviously-broken) VR, I recommend Yoga for Building VR Tolerance. https://web.archive.org/web/20190813004505/http://elevr.com:... The research organization ran out of funding but IMO they had some groundbreaking stuff. Thank goodness for the Internet Archive at least.
I made a janky AR rig with a webcam taped to an Oculus DK2 as part of a hackathon. My code ran at 15fps. after taking off the goggles, my vision was 15fps.
Reading what OP's goal was, my first thought was "can `sox` do that?". Yes, yes it can, apparently. `sox silence` cuts off silence at the start of a file (or in other places, suitably configured). http://sox.sourceforge.net/sox.html (search for `silence`)
I was working on a software for devices that read stuff for blind people. Basically you put a newspaper on a table and it detects it and reads it aloud to you.
We had a feature where user can scan whole books just by turning pages and save them as audiobooks or txt with "audio tags". Basically the device records you saying the title saves it as metadata, and later you can browse the list of books listening to yourself saying their titles.
Sadly our hardware had mic near power lines and there was a lot of interference and the volume was pretty low, it was barely usable. So one of my tasks was to boost the volume and remove noise. I tried to write something to this effect, tested a few libraries, and eventually settled on just running sox in the background with several plugins and noise sample collected on our device under different loads. Works like a charm.
The best thing - a few years later I google how the devices are doing on the market and I've found a podcast by a blind guy reviewing it, and he mentioned how good the audio tag feature is :) It wasn't the best paying job but no B2B job gives you this kind of feedback.
Apple Airpods Pro protect users from over-loudness.
iPhone has an option to enable this protection for all headsets, but it doesn't work properly. For example, when answering a FaceTime Audio call with Bose SoundSport, the "call connected" tone often plays at max volume and is staticky. This is with the latest firmware and iOS.
macOS has no over-loudness protection.
Bose's expensive noise-cancelling headphones do complex audio processing but fail to protect users from over-loudness. I think the company has lost its ability to focus on user needs. Over the last 10 years, only their noise-cancelling function has gotten better, but other aspects of their headphones have gotten worse. Features I want in my next headset:
- active noise cancelling
- loudness protection
- swappable battery
- physical buttons
- mic windguard
- stowable boom mic so I can talk quietly on a call and still be heard
- an option to automatically pause music when I take off the headphones and resume when I put them on
- an option to automatically enable or increase noise cancelling when the environment becomes noisy and disable it again when in a quiet space
- Automatically detect me speaking and pipe my voice through the headset so it feels natural, even when not on a call.
- Work properly in extremely noisy environments. When I wear my Bose QC25 noise-cancelling headphones while riding the BART subway in San Francisco, the headphones emit painful crackling sounds when the train noise is very loud. I don't expect the headphones to block extremely loud sounds. They should not make the noise worse. Bose's headquarters is in downtown SF. I expect some of the firmware engineers ride BART every day. Does anyone know why they haven't fixed this in 7 years?
I don't understand why this isn't a common thing everywhere??? I'm not a headphone designer but the "loudness protection" seems like it would be trivial to add! For some reason that idea never occurred to me but its a good one.
Decades ago I had a Original Commodore PET 2001. It could only display white text/characters on a black screen. Foolish me having read a Byte magazine describing how a black & white colour wheel could make you see colours see: https://archive.org/details/byte-magazine-1977-02/page/n45/m... so I tried to get my PET colour to display colours using this method.
Trying different timings, all the while staring at the screen. I did this all day looking at flashing lights all the time.
Afterwards it turns out I could not see properly for hours.
Hi,
I think I have mentioned this before in HN too. I am not from CS background and just learnt the trade as I was doing the job, I mean even the normal stuff.
We have a project that tries reify live objects into human readable form. Final representation is so complicated with lot of types and the initial representation is less complicated.
In order to make it readable, if there is any common or similar data nodes, we have to compare and try to combine them i.e. find places that can be made into methods and find the relevant arguments for all the calls (kind of).
Initial implementation did the transformation into the final form first, and then started the comparison. So, the comparison have to deal with all the different combinations of the types we have in final representation now, which made the whole thing so complex and has been maintained by generation of engineers that nobody had clear idea how it was working.
Then, I read about hashmap implementation later (yep, I am that dumb) and it was a revelation. So, we did following things:
1. We created a hash for skeleton that has to remain the same through all the set of comparisons and transformation of the "common nodes", (it can be considered as something similar to methods or arguments) and doing the comparison for nodes with matching skeletal hashes and
2. created a separate layer that does the comparison and creating common nodes on initial primitive form and then doing the transformation as the second layer (so you don't have to deal with all types in final representation) and
3. Don't type. Yes. Data is simplest abstraction and if your logic can made into data or some properties, please do yourself a favor and make them so. We found lot of places, where weird class hierarchies can be converted into data properties.
That did not just speed up the process, but resulted in much more readable and understandable abstractions and code. I do not know, if this is widely useful but it helped in one project. There is no silver bullet, but types were actual problem for us and so we solved it this way.
Burned myself many, many times, not realizing that a bug in my code had resulted in way too much power going through something or the other, and then going to touch that something. Got myself an RF burn that way once, too.
Oh yeah, plenty of flesh wounds. No serious injuries that I can remember, though. Maybe that means it was a head injury? :-) More importantly, I don't think I've injured anyone else seriously either.
I've worked on embedded software for solar powered race cars, rockets and spacecraft, self driving cars, and most recently UAVs and corresponding high power motorized ground systems.
You gotta take safety procedures seriously when testing out electro-mechanical systems strong enough to injure you. One memorable bug discovered in testing in the last few years I labeled "ninja assassin mode"...
I've never hurt myself, but I have set the computer on fire.
Context: building an avionics test set with an integrated loads and measurements capability and complex relay switching network to allow different things to be switched to different loads and voltage drops measured. During software/hardware integration testing (first time that the hardware had been driven full speed) we found a bug in the CPLD that resulted in 28V being sunk into a 2A resistive load over a couple of PCB traces specified for 10mA; resulting in a large amount of magic smoke being emitted.
Not so much myself physically, but I certainly have written code that destroyed my own projects (hurt my wallet).
Many years ago I was working on a mobile outdoor hobby robotics project (RoboMagellan) and had two glitches in parallel. One was the software controlling the robot, the other was in a microcontroller in the kill switch mechanism.
The main computer was reset by a brown out which also caused the uC listening for inputs from the radio used as the "enable" switch to lock up (with the motors enabled) and I hadn't yet learned about hardware watchdog timers.
A long time ago in a university far-far away, I stayed up for several days straight writing code for an aerial robotics platform. I was so focused on writing this code that even my dreams were trying really hard to be expressed in perl. I woke up extremely tense and in a sweat because I couldn't figure out how to express a strong emotion in perl.
As for the harm, well ... that code led to a marriage which catastrophically failed. Lesson learned: keep code and emotions away from each other.
I've done something like that as well while working on audio firmware.
Think about how many times you hit compile and there were mistakes vs. perfect code? To err is human nature, that's why it's so important to set up safety nets for ourselves when dealing with dangerous things. Wear your digital PPE :-).
I once wanted to run my Bash script (for archiving photos) through ShellCheck. I will never know, but I had to do something terribly wrong, as it started to remove my root directory... Thankfully, didn't had root privileges, so "only" resulted in nuking my home folder.
I once copied a Terraform directory & changed all the confit values to match the new environment I wanted to spin up. Unfortunately I forgot to remove the Terraform state files. So running “terraform apply” did a great job of spinning up the new environment, right after it tore down the old one.
Not physically but once I did a find & replace across a folder of PHP files but didn’t specify filetype, ended up replacing a few characters in a Flash .FLA that was part of the same project, corrupting it. Had to start nearly from scratch, I would say that hurt.
Haha a friend of mine once deleted a key to his Ethereum wallet with more than a million bucks worth of Ethereum on it, due to mistake in his script. That is as "hurt" as it gets :D
I used to have a big CNC router. Like, one that you could mill a whole door on, if you wanted to.
One day I thought it would be a cool hack if I could rig up an Xbox controller to send movement commands. Long story short I managed to snap the bit by moving too much after a plunge cut. No safety glasses or anything; but a day or two later I did find some shrapnel from the bit embedded in a piece of foamboard I had near the machine, so that was cool...
One of the first lessons (often learned the hard way) of any sort of audio processing work is to turn your volume way down before starting any sort of playback.
Bugs like these are the reason why I always turn the volume way down before listening to audio that newly written code generates. And even if you know that you're listing to audio that's OK, try to keep the volume low. Your ears will thank you in the long run. It's easy to have headphone levels to high and slowly damage your ears with long listening sessions.
I run a home HVAC thermostat with custom code that has no other hardware fallback.
Once, due to a logic error on my part the heater was triggered in the middle of the summer while I was out of town. The internal temp got up to well over 100°F.
I was able to have a friend come over and disconnect things for me, but I could have killed a pet, at the least, if not some more sensitive hardware.
I bet most robotics and other embedded people have :) . I once got zapped because of a timer I set on a 50V section (95% of the board was 12V or less) of a circuit and proceeded to forget the timer (for a transistor switcher) was set in my debug version. It was just 50v DC and tiny amperage but still very zappy.
tl;dr I got myself banned from #emacs accidentally because of a bug in my code.
One time I was writing a little emacs lisp module to automatically reconnect me to #emacs on freenode, but it was buggy, but it was still in my .emacs at the time, so when i restarted emacs, it started running, and I didnt notice it.
fast forward a little bit, i notice the irc buffers open in my list of buffers, and lo and behold, my code was constantly disconnecting/reconnecting in #emacs and it was spamming the channel with those messages. They banned me (briefly) so it would stop.
It was just funny to see like a flood of connects/disconnects in the chat log, and people being like "whats going on" and "must be a bug in something".
Hopefully the finished code also didn't make Mistake #4: skipping the zero first byte of the first non-zero 16 bit integer. i.e. it should only skip zero words (byte pairs), not zero bytes. This error would probably go unnoticed for a while if it did.
Mistake #0: Working at the wrong level of abstraction.
There are perfectly good library functions (in python, and I assume in C) for loading a wav file into a simple array of values, and writing an array back into a new wav file... Load the data, skip the zeros, and write.
I have taught robotics enough to have hurt myself in front of a classroom while demonstrating a safety feature. Nothing serious, everyone has a good laugh.
3D printering has also led to some pinching and burning here and there. Worth it!
back in the early 80’s I wrote 400kLoC in the course of a summer (APL/360, very short lines), printed it all out on green bar fanfold paper. Stashed the printouts in binders on bookshelves, the shelves collapsed and I got nasty bumps and paper cuts.
If you meant conceptual injury, I try not to dwell on it, but I once wrote a makefile that “clean”-ed up all the source code, source control, and the backups...just a cut and paste error, but soured my original exuberance about make. For life.
I can think of two examples. The first is somebody else's that I helped them with, and the second is mine. Context: Mid-2000's snack-sized hosting company with less than 10 employees.
A customer with a dedicated server called in one day. I knew him well, and he I. It was that kind of company and I loved it. Anyhow, he called in and said "I've been hacked!" I asked him to explain the problem and he said that his server wasn't working right and wouldn't reboot. I looked into it, and a ton of things were missing from the file system. /bin, /boot, /dev, etc. Gone. So I did a restore of the server and got it back online.
He called me up an hour or two later "I've been hacked again!" Same problem. Same solution.
An hour later he called me up, sheepish. "I think it might be ME. Every time I think it's happening every time I run this command." I managed to get him to email me the command he was running, verbatim (he was copy/pasting it into the shell) and it looked like this:
The other harm was my own. I was budding system administrator tasked with designing and deploying dedicated servers (this is before VPSs were a thing, and way before cloud computing). I challenged myself to learn Perl because the greybeard admin (who cut his teeth on PDP-11's) was a master at it and I could benefit from his tutelage. But I didn't. Instead I got the SAM's book on Perl and started learning. Having an interest in security, I decided that I'd write a simple Intrusion Detection System for our dedicated server products.
I don't have the code, but it's irrelevant. A the time one of the bigger problems was servers getting rooted due to various exploits. The attacker would rewrite /bin/ls with their own version that hid their executables. The solution (obviously right?) is to look at the md5sum of /bin/ls, and if it changes, the server must be rooted, right? So I wrote code that would shut down sshd, close the port, and display a message via `wall` that said something very much like:
System Modification Detected! Shutting down system and alerting security staff. YOU HAVE BEEN CAUGHT! BUH BYE!
I was very pleased with myself. I couldn't understand why the aforementioned greybeard didn't revel in my brilliance. sigh I deployed the script on a cron job and felt very satisfied with my good work. Until a call came in. "Yeah, I ran a yum update, got some message about being caught, and now I can't get into my system."
Yeah that's right. I'd hard coded the md5sum for /bin/ls and had no means of updating it. I've since forgotten Perl but I never forgot this lesson: Take everything into account. Spend less time coding and more time thinking about what you're building and how it'll affect others. Since then I've written several utilities that are/were in use at the hosting companies I work(ed) for and I saved people countless time, effort, and trouble. But it sure didn't start out that way!
Back in mid 90's, as a fresh student barely having a year of programming under my belt but with a burning passion I was doing my summer practice (required by school) to a factory IT center. This factory was making a lot of large industrial stuff but during that period the current contract was to make propellers for big ships. Like 20m high one. And they used AutoCAD in the IT center to design those. For a Japanese client.
So the director of said IT center, seeing me how I dabbled in all kind of stuff with latest and greatest technology asks me "can you create a copy protection?". Nowadays I see this kind of question as a job on my freelancer marketplace and I always say to the potential customer "impossible, and if anyone else says otherwise are either incompetent or just want to hustle your money" but back then? my naive brain said "sure I can".
The IT center just acquired, at around 4000 USD each, a brand new line of 486 DX2 at a whooping 100 MHz which came with latest and greatest Windows 3.1 for Workgroups. Around 20 of them for all their design engineers to use ACAD at a faster pace. Serious business required serious tools. So I enter the scene with my protection. Which was a wrapper around the protected "exe" that on launch would ask for password, 3 tries and you're out. If password was provided then it would unwrap the good exe and launch it, otherwise the protection would kick in.
And oh boy, what a marvelous protection I wrote. First step - overwrite MBR with zeroes, you can guess to what goal.
Second step - well, this one is a bit complex. You see back then you could directly access graphic cards DMA channel and write your own graphic driver inside your application because, well, DOS was like that. And poor Win 3.1 was no different either. And because of a physical layout that majority of board back then employed all the same you had an electrolytic capacitor near (like 2 mm only) a pin. Which said pin could go to up 25 KV if you were driving a certain pattern on your graphic card. Which would result in a shortcut between the pin and the capacitor. Which would ignite the resin that was there. Which would set your computer on fire.
Third step - restart the PC.
So I am there with the director, head of designers and a bunch of other people to test my copy protection. I explain to them in what the protection consist of, and we test it. They wanted to test it on "acad.exe", so I wrap it up in my protection, delete the original and the new exe is launched. All good, password prompt, get in, Autocad is launched, they can do the work in peace. Except the director asks "and if I launch this wrapper tool separately, what happens?". "Nothing, it's just a tool and if you don't supply a parameter will simply exit". So the director does that, except he supplies a bogus parameter, by mistake, and not any parameter but ^U...you know, the combination that a Windows user will see at a command prompt when he does a mistake and presses CTRL+Z (Undo in Windows), because he pressed space and then wanted to back it off..and muscle memory for that action is CTRL+Z. And happily my tool tries to wrap around a file called ^U, but for some reason that file instead to be "not found", because I had this coded, was treated at "launch the protection". So here a little bug, launched my protection on a $4000 brand new machine. Of course MBR was zeroed instantly and then we see some stuff scrambled on the screen (protection no 2) and puff!! we're at BIOS reset. No fire!!! Why? because protection no 2 should've run for 10 seconds to allow the buildup of those 25 KV, but I was lucky because my dead ass brain introduced another bug and I was triggering the reset immediately.
I spent the next 3 days, me and the head of designers, rewriting the MBR by copy/paste via eyes and hands, using a hexeditor, by reading the MBR from another 486, and I was lucky since they all had identical configuration. That protection scared off the director, he never use it. And my ass hurt from the stick because $4000 during that time would've been both my parent income for an entire year.
Ah yes, off-by-one errors when filling a PCM buffer can be loud. Speaking from experience, it’s similarly loud when you accidentally fill an integer PCM buffer with floating point data.
My story: I physically broke an indoor bike trainer by writing a mobile app.
I was fed up with the rent-seeking subscription-based app that the vendor provided for the machine, and wanted to write a simple app to be able to change the training parameters over Bluetooth. It worked via a standard BLE fitness machine protocol, so I’ve spent a few hours creating a prototype iOS app for interacting with it via the CoreBluetooth framework, based on the free docs from Bluetooth.org.
Everything worked wonderfully, up until the point of adding a slider to the UI for changing the “hardness” parameter of the current session. You see, changing the hardness parameter adjusted an electromagnetic braking mechanism inside the machine, and the slider I’ve put on the UI was set to its “continuous” mode, which meant that it was generating a steady stream of change events while dragging, basically at the framerate of the phone (60 fps). The designers of the machine probably didn’t anticipate that someone would be flooding it with 60 “set hardness” commands per second, and the actuator doing the adjustment simply broke from the overload after a few seconds of me dragging the slider…
I’m not sure exactly which part broke, but there was a loud crack from inside, and the braking power could no longer be adjusted at all. I could have disassembled the machine, but it wasn’t even mine (it was lent to me by my brother-in-law to try it out), and was still under warranty, so I gave it back and told that it spontaneously broke :^)
One day I had some friends over for a glass of wine, and wanted to show off my creation. I invited them into my "lab" and placed my wine glass down on the desk so I could type a few commands with both hands.
My rudimentary software had some motion smoothing once it was up and running, but upon initialization, if the arm was significantly displaced from where it had been when it was turned off, the PWM board would instruct the motor to immediately "be" in a position that required the arm to travel clear across the desk in effectively as little time as possible.
In this case, where it had been previously happened to be where my wine glass was now, and the flimsy aluminum at high speed was enough to shear the stem from the glass and explode the bulb. Luckily the wine didn't get in any sensitive electronics, but I learned a valuable lesson about the difference between messing around with hardware vs software.