Fail Of The Week: Roboracer Meets Wall

There comes a moment when our project sees the light of day, publicly presented to people who are curious to see the results of all our hard work, only for it to fail in a spectacularly embarrassing way. This is the dreaded “Demo Curse” and it recently befell the SIT Acronis Autonomous team. Their Roborace car gained social media infamy as it was seen launching off the starting line and immediately into a wall. A team member explained what happened.

A few explanations had started circulating, but only in the vague terms of a “steering lock” without much technical detail until this emerged. Steering lock? You mean like The Club? Well, sort of. While there was no steering wheel immobilization steel bar on the car, a software equivalent did take hold within the car’s systems.  During initialization, while a human driver was at the controls, one of the modules sent out NaN (Not a Number) instead of a valid numeric value. This was never seen in testing, and it wreaked havoc at the worst possible time.

A module whose job was to ensure numbers stay within expected bounds said “not a number, not my problem!” That NaN value propagated through to the vehicle’s CAN data bus, which didn’t define the handling of NaN so it was arbitrarily translated into a very large number causing further problems. This cascade of events resulted in a steering control system locked to full right before the algorithm was given permission to start driving. It desperately tried to steer the car back on course, without effect, for the few short seconds until it met the wall.

While embarrassing and not the kind of publicity the Schaffhausen Institute of Technology or their sponsor Acronis was hoping for, the team dug through logs to understand what happened and taught their car to handle NaN properly. Driving a backup car, round two went very well and the team took second place. So they had a happy ending after all. Congratulations! We’re very happy this problem was found and fixed on a closed track and not on public roads.

[via Engadget]

Fail Of The Week: How Not To Watercool A PC

To those who choose to overclock their PCs, it’s often a “no expense spared” deal. Fancy heat sinks, complicated liquid cooling setups, and cool clear cases to show off all the expensive guts are all part of the charm. But not everyone’s pockets are deep enough for off-the-shelf parts, so experimentation with cheaper, alternatives, like using an automotive fuel pump to move the cooling liquid, seems like a good idea. In practice — not so much.

The first thing we thought of when we saw the title of [BoltzBrain]’s video was a long-ago warning from a mechanic to never run out of gas in a fuel-injected car. It turns out that the gasoline acts as a coolant and lubricant for the electric pump, and running the tank dry with the power still applied to the pump quickly burns it out. So while [BoltzBrain] expected to see corrosion on the brushes from his use of water as a working fluid, we expected to see seized bearings as the root cause failure. Looks like we were wrong: at about the 6:30 mark, you can see clear signs of corrosion on the copper wires connecting to the brushes. It almost looks like the Dremel tool cut the wire, but that green copper oxide is the giveaway. We suspect the bearings aren’t in great shape, either, but that’s probably secondary to the wires corroding.

Whatever the root cause, it’s an interesting tour inside a common part, and the level of engineering needed to build a brushed motor that runs bathed in a highly flammable fluid is pretty impressive. We liked the axial arrangement of the brushes and commutator especially. We wonder if fuel pumps could still serve as a PC cooler — perhaps changing to a dielectric fluid would do the trick.

Continue reading “Fail Of The Week: How Not To Watercool A PC”

Fail Of The Week: Bright Idea For LED Signs Goes Bad

Typically when we select a project for “Fail to the Week” honors, it’s because something went wrong with the technology of the project. But the tech of [Leo Fernekes]’ innovative LED sign system was never the problem; it was the realities of scaling up to production as well as the broken patent process that put a nail in this promising project’s coffin, which [Leo] sums up succinctly as “The Inventor’s Paradox” in the video below.

The idea [Leo] had a few years back was pretty smart. He noticed that there was no middle ground between cheap, pre-made LED signs and expensive programmable signboards, so he sought to fill the gap. The result was an ingenious “LED pin”, a tiny module with an RGB LED and a microcontroller along with a small number of support components. The big idea is that each pin would store its own part of a display-wide animation in flash memory. Each pin has two terminals that connect to metal cladding on either side of the board they attach to. These two conductors supply not only power but synchronization for all the pins with a low-frequency square wave. [Leo]’s method for programming the animations — using a light sensor on each pin to receive signals from a video projector — is perhaps even more ingenious than the pins themselves.

[Leo]’s idea seemed destined for greatness, but alas, the cruel realities of scaling up struck hard. Each prototype pin had a low part count, but to be manufactured economically, the entire BOM would have to be reduced to almost nothing. That means an ASIC, but the time and expense involved in tooling up for that were too much to bear. [Leo] has nothing good to say about the patent game, either, which his business partners in this venture insisted on playing. There’s plenty of detail in the video, but he sums it up with a pithy proclamation: “Patents suck.”

Watching this video, it’s hard not to feel sorry for [Leo] for all the time he spent getting the tech right only to have no feasible way to get a return on that investment. It’s a sobering tale for those of us who fancy ourselves to be inventors, and a cautionary tale about the perils of participating in a patent system that clearly operates for the benefit of the corporations rather than the solo inventor. It’s not impossible to win at this game, as our own [Bob Baddeley] shows us, but it is easy to fail.

Continue reading “Fail Of The Week: Bright Idea For LED Signs Goes Bad”

Fail Of The Week: How Not To Die Of Boredom During Isolation

They say you can’t actually die from boredom, but put a billion or so people into self-isolation, and someone is bound to say, “Hold my beer and watch this.” [Daniel Reardon]’s brush with failure, in the form of getting magnets stuck up his nose while trying to invent a facial touch reminder, probably wasn’t directly life-threatening, but it does underscore the need to be especially careful these days.

The story begins with good intentions and a small stack of neodymium magnets. [Daniel]’s idea for a sensor to warn one of impending face touches was solid: a necklace with magnetic sensors and wristbands studded with magnets. Sounds reasonable enough; one can easily see a compact system that sounds an alarm when a hand subconsciously crosses into the Danger Zone while going in for a scratch. Lacking any experience in circuits, though, [Daniel] was unable to get the thing working, so he started playing with the magnets instead. One thing led to another, and magnets were soon adorning his earlobes, and then his nostrils. Unfortunately, two magnets became locked on either side of his septum, as did two others meant to neutralize the pull of the first pair. So off [Daniel] went to the emergency department for a magnetectomy.

Of course it’s easy to laugh at someone’s misfortune, especially when self-inflicted. And the now-degaussed [Daniel] seems to be a good sport about the whole thing. But the important thing here is that we all do dumb things, and hackers need to be especially careful these days. We often work with sharp, pointy, sparky, toxic, or flammable things, and if we don’t keep our wits about us, we could easily end up in an ER somewhere. Not only does that risk unnecessary exposure to COVID-19, but it also takes medical resources away from people who need it more than you do.

By all means, we should be hacking away these idle hours. Even if it’s not in support of COVID-19 solutions, continuing to do what we do is key to our mental health and well-being. But we also need to be careful, to not stretch dangerously beyond our abilities, and to remember that the safety net that’s normally there to catch us is full of holes now.

Thanks to [gir.st] for the tip — you actually were the only one to send this in.

Fail Of The Week: In CAD, Remember To Model The Environment

What’s wrong with the above picture? Failure can be an excellent teacher, and [J. Peterson] reminds us all of this when he says to remember to model the environment when designing things in CAD. He contrasts a failure with a success to demonstrate what that means.

The failure was a stand for a screwdriver set, shown above. He modeled up a simple stand to hold a screwdriver handle and the bits in a nice, tight formation. He didn’t model any of parts, he just took some measurements and designed the holder. Everything fit just fine, but it had a major ergonomic problem: you can barely reach the handle because it is fenced in by the surrounding bits! Had he modeled all of the parts during the design phase, and not just the part he was making, this problem would have been immediately obvious during the design phase.

The contrasting success is an adapter he designed to mount an artistic glass marble to a lit display stand. The stand itself as well as the glass marble were modeled in CAD, then the adapter designed afterwards to fit them. With all of the involved objects modeled, he could be certain of how everything fit together and it worked the first time.

Now, to most people with a 3D printer of their own, discovering a part isn’t quite right is not a big (nor even a particularly expensive) problem to have, but that’s not the point. Waste and rework should be avoided if possible. To help do that, it can be good to remember to model the whole environment, not just the thing being made. Add it on to the pile of great design advice we’ve seen for designing things like enclosures and interfaces.

Fail Of The Week: Padlock Purports To Provide Protection, Proves Pathetic

Anyone in the know about IoT security is likely to steer clear of a physical security product that’s got some sort of wireless control. The list of exploits for such devices is a long, sad statement on security as an afterthought, if at all. So it’s understandable if you think a Bluetooth-enabled lock is best attacked via its wireless stack.

As it turns out, the Master 5440D Bluetooth Key Safe can be defeated in a few minutes with just a screwdriver. The key safe is the type a realtor or AirBnB host would use to allow access to a property’s keys. [Bosnianbill] embarked on an inspection of the $120 unit, looking for weaknesses. When physical attacks with a hammer and spoofing the solenoids with a magnet didn’t pay off, he decided to strip off the resilient skin that Master so thoughtfully provided to prevent the box from marring the finish of a door or gate. The denuded device thus revealed its awful secret: two Phillips screws, each securing a locking shackle to the cover. Once those are loose, a little prying with a screwdriver is all that’s need to get the keys to the kingdom.

In a follow-up video posted later, [Bill] took a closer look at another key safe and found that Master had made an anemic effort to fix this vulnerability with a squirt of epoxy in each screw head. It’s weak, at best, since a tap with a hammer compresses the gunk enough to get a grip on the screw.

We really thought [Bosnianbill]’s attack would be electronic, like that time [Dave Jones] cracked a safe with an oscilloscope. Who’d have thought a screwdriver would be the best way past the wireless stack?

Continue reading “Fail Of The Week: Padlock Purports To Provide Protection, Proves Pathetic”

Fail Of The Week: Thermostat Almost Causes A House Fire

Fair warning: any homeowners who have thermostats similar to the one that nearly burned down [Kerry Wong]’s house might be in store for a sleepless night or two, at least until they inspect and perhaps replace any units that are even remotely as sketchy as what he found when he did the postmortem analysis in the brief video below.

The story begins back in the 1980s, when the Southern New England area where [Kerry] lives enjoyed a housing boom. Contractors rushed to turn rural farmland into subdivisions, and new suburbs crawled across the landscape. Corners were inevitably cut during construction, and one common place to save money was the home’s heating system. Rather than engage an HVAC subcontractor to install a complicated heating system, many builders opted instead to have the electricians install electric baseboards. They were already on the job anyway, and at the time, both copper and electricity were cheap.

Fast forward 40 years or so, and [Kerry] finds himself living in one such house. The other night, upon catching the acrid scent of burning insulation, he followed his nose to the source: a wall-mounted thermostat for his electric baseboard. His teardown revealed burned insulation, bare conductors, and scorched plastic on the not-so-old unit; bearing a 2008 date code, the thermostat must have replaced one of the originals. [Kerry] poked at the nearly combusted unit and found the root cause: the spot welds holding the wires to the thermostat terminal had become loose, increasing the resistance of the connection. As [Kerry] points out, even a tenth of an ohm increase in resistance in a 15 amp circuit would dissipate 20 watts of heat, and from the toasty look of the thermostat it had been a lot more than that.

The corner-cutting of the 1980s was nothing new, of course – remember the aluminum wiring debacle? Electrical fires are no joke, and we’re glad [Kerry] was quick to locate the problem and prevent it from spreading.

Continue reading “Fail Of The Week: Thermostat Almost Causes A House Fire”