Fail of the Week: Robotic 1950 Mercury Boogies, Won’t Come Back From Dead Man’s Curve

1950 Mercury[Dave] wanted to make an Arduino robot out of a remote-control 1950 Mercury. He removed the RC portion from the car and kept the drive and steering motors. The idea was to use three ultrasonic rangefinders in the grille real estate and move the car forward based on the longest distance detected.

He initially used a Seeed motor controller and some Grove cables soldered to his sensors to power the steering. It went forward, but only forward, and [Dave] decided the motor controller and the car’s steering motor weren’t playing well together.

[Dave] had the idea to use relays instead to both power the motor and determine polarity. Now, the Merc was turning and avoid obstacles about half the time, but it was also getting dinged up from hitting walls. He figured out that his sensor arrangement was making the car turn immediately and decided to give the program information from the wheels with a reed switch and a rare earth magnet. The only problem is that the caliber of magnet required to trip the reed switch is too heavy and strong. [Dave] and has concluded that he simply can’t exercise the kind of control over the car that he needs. and will build his own robot chassis.


2013-09-05-Hackaday-Fail-tips-tileFail of the Week is a Hackaday column which runs every Wednesday. Help keep the fun rolling by writing about your past failures and sending us a link to the story — or sending in links to fail write ups you find in your Internet travels.

Fail of the Week: This Inanimate Titanium Rod

titanium casting failYou saw [Chris] cast aluminium on the cheap using Kinetic Sand a few weeks ago, didn’t you? He recently got his meaty hands on some titanium through the magic of modern transactional methods and was bowled over by its strength, hardness, and poor heat transfer.

He thought he would cast it into a nice, strong bottle opener. As you can probably guess, that didn’t go so well. First off, it wasn’t easy to saw through the thin rod. Once he did get it split in twain, it was surprisingly cool to the touch except at the tip. This is nasty foreshadowing, no?

[Chris] takes a moment to help us absorb the gravity of what he’s about to do, which of course is to send several hundred amps through that poor rod using a DC arc welder. Special precautions are necessary due to the reaction between oxygen and heated titanium. His trusty graphite crucible is grounded to the bottom of a big aluminium tub, and a cozy blanket of argon from a TIG welder will shield the titanium from burnination.

Well . . . the titanium didn’t melt. Furthermore, the crucible is toast. On the up side, vise-enabled cross-sectional examination of the crucible proved that there was still gold in them there walls.

Do you have any (constructive, on-topic) suggestions for [Chris]? Let him know below.

[Read more...]

Sparkfun Ships 2000 MicroViews Without Bootloaders

microview-fail

Everyone has a bad day right? Monday was a particularly bad day for the folks at Sparkfun. Customer support tickets started piling up, leading to the discovery that they had shipped out as many as 1,934 MicroViews without bootloaders.

MicroView is the tiny OLED enabled, Arduino based, microcontroller system which had a wildly successful Kickstarter campaign earlier this year. [Marcus Schappi], the project creator, partnered up with SparkFun to get the MicroViews manufactured and shipped out to backers. This wasn’t a decision made on a whim, Sparkfun had proven themselves by fulfilling over 11,000 Makey Makey boards to backers of that campaign.

Rather than downplay the issue, Sparkfun CEO [Nathan Seidle] has taken to the company blog to explain what happened, how it happened, and what they’re going to do to make it right for their customers. This positions them as the subject of our Fail of the Week column where we commiserate instead of criticize.

First things first, anyone who receives an affected MicroView is getting a second working unit shipped out by the beginning of November. Furthermore, the bootloaderless units can be brought to life relatively easily. [Nate] provided a hex file with the correct bootloader. Anyone with an Atmel AVR In-System Programming (ISP) programmer and a steady hand can bring their MicroView to life. Several users have already done just that. The bootloader only has to be flashed via ISP once. After that, the MicroView will communicate via USB to a host PC. Sparkfun will publish a full tutorial in a few weeks.

Click past the break to read the rest of the story.

[Read more...]

Fail of the Week: Blown Light Bulb Controllers

fotw-nyc-resistor-chandelier-driver

We’ve been meaning to get around to this one for many weeks now. It’s been hard to find good fail write-ups… it’s as if hackers are afraid to admit that sometimes projects fail. We hope you’ll shake off that opinion as failure is the fastest path for learning and true understanding!

[xymax] was working on a control system for a chandelier with 150 bulbs which use 5 Watts each. This project was being readied for the NYC Resistor Interactive Party which [Adam Fabio] attended last month. As deadline for the show approached, the last piece was put in place late into the night… but it was connected backwards. In a tale worthy of a slapstick movie, the reverse polarity caused a chip on all seven controller boards for this module to blow like the one seen above. But that’s not all, the laptop being used during prototyping was connected by USB and started smoking!

All of us feel the pain of this type of equipment failure. Luckily [xymax] looked for lessons to learn instead of dwelling on the mistake itself. Use protection diodes, keyed connectors, and write about your failures. Hopefully reading this will help others avoid a similar equipment-destroying mistake.


2013-09-05-Hackaday-Fail-tips-tileFail of the Week is a Hackaday column which runs every Thursday. Help keep the fun rolling by writing about your past failures and sending us a link to the story — or sending in links to fail write ups you find in your Internet travels.

Fail of the Week: Projector LED Retrofit

fotw-projector-repair

That’s a deal for a project, how hard could it be to fix it up?

If you’re a real hacker we’d wager you’ve fallen for this type of thought process before. [Luft] bought this used Sharp XR-10X-L projector about a year back and planned to retrofit it with an LED bulb. He gathered all the parts and got to work, successfully testing and installing the modifications. But as luck would have it, the project is stuck in some type of boot loop.

This fail is certainly not for lack of preparation. The first post documenting his adventure shows that the hack has been done before, he acquired the service manual for this particular hardware, and he did his homework when ordering the parts. Success requires circumventing some sensors which ensure the case and internals are in place, and making sure the electronic status of the ballast is reported correctly event though it’s not needed for the LED source. Power-on gets as far as illuminating all the indicator lights in green as it should, but is then followed closely by a reboot sequence.

He tried watching the serial port to see if he can get any status info there but no dice. In keeping with the nature of this column, let’s see if we can provide any constructive troubleshooting advice in the comments.


2013-09-05-Hackaday-Fail-tips-tileFail of the Week is a Hackaday column which runs every Wednesday. Help keep the fun rolling by writing about your past failures and sending us a link to the story — or sending in links to fail write ups you find in your Internet travels.

Fail of the Week: Rewiring Robosapien

fotw-rewiring-robosapien

Our first thought was “check out all of those TO-92 components!”, but then we saw the wiring nightmare. [Tom] picked up a Robosapien from an estate sale for just $10. Most hackers couldn’t resist that opportunity, but the inexpensive acquisition led to a time-consuming repair odyssey. When something doesn’t work at all you crack it open to see what’s wrong. He was greeted with wiring whose insulation was flaking off.

This is no problem for anyone competent with a soldering iron. So [Tom] set to work clipping all the bad wire and replacing it with in-line splices. Voila, the little guy was dancing to his own tunes once again! But the success was short-lived as the next day the robot was unresponsive again. [Tom] plans to do some more work by completely replacing the wires as soon as he receives the replacement connectors he ordered. So what do you think, is this an issue that will be resolved with a wire-ectomy or might there be actual damage to the board itself?


2013-09-05-Hackaday-Fail-tips-tileFail of the Week is a Hackaday column which runs every Wednesday. Help keep the fun rolling by writing about your past failures and sending us a link to the story — or sending in links to fail write ups you find in your Internet travels.

Fail of the Week: CPLDs That Release Blue Smoke

fotw-floppy-emulator-burned-cpld

The card you see above is a floppy drive emulator for Macintosh. [Steve Chamberlain] has been hand assembling these and selling them in small runs, but is troubled by about a 4% burn-out rate for the CPLD which has the red ‘X’ on it. He settled into figure out what exactly is leading to this and it’s a real head-scratcher.

He does a very good job of trouble-shooting, starting with a list of all the possible things he thinks could be causing this: defective part, bad PCB, bad uC firmware, damage during assembly, solder short, tolerance issues, over-voltage on the DB connector, or bad VHDL design. He methodically eliminates these, first by swapping out the part and observing the exact same failure (pretty much eliminates assembly, solder short, etc.), then by measuring and scoping around the card.

The fascinating read doesn’t stop with the article. Make sure you work your way through the comments thread. [Steve] thinks he’s eliminated the idea of bad microcontroller code causing damage. He considers putting in-line resistors on the DB connector but we wonder if clamping diodes wouldn’t be a better choice (at least for testing purposes)? This begs the question, why is he observing a higher voltage on those I/O lines during power-up? As always, we want to hear your constructive comments below.


2013-09-05-Hackaday-Fail-tips-tileFail of the Week is a Hackaday column which runs every Wednesday. Help keep the fun rolling by writing about your past failures and sending us a link to the story — or sending in links to fail write ups you find in your Internet travels.

Follow

Get every new post delivered to your Inbox.

Join 93,813 other followers