Arduino Watchdog Sniffs Out Hot 3D Printers

June 18, 2018 by 23 Comments

We know we’ve told you this already, but you should really keep a close eye on your 3D printer. The cheaper import machines are starting to display a worrying tendency to go up in flames, either due to cheap components or design flaws. The fact that it happens is, sadly, no longer up for debate. The best thing we can do now is figure out ways to mitigate the risk for all the printers that are already deployed in the field.

At the risk of making a generalization, most 3D printer fires seem to be due to overheating components. Not a huge surprise, of course, as parts of a 3D printer heat up to hundreds of degrees and must remain there for hours and hours on end. Accordingly, [Bin Sun] has created a very slick device that keeps a close eye on the printer’s temperature at various locations, and cuts power if anything goes out of acceptable range.

The device is powered by an Arduino Nano and uses a 1602 serial LCD and KY040 rotary encoder to provide the user interface. The user can set the shutdown temperature with the encoder knob, and the 16×2 character LCD will give a real-time display of current temperature and power status.

Once the user-defined temperature is met or exceeded, the device cuts power to the printer with an optocoupler relay. It will also sound an alarm for one minute so anyone in the area will know the printer needs some immediate attention.

We’ve recently covered a similar device that minimizes the amount of time the printer is powered on, but checking temperature and acting on it in real-time seems a better bet. No matter what, we’d still suggest adding a smoke detector and fire extinguisher to your list of essential 3D printer accessories.

Continue reading “Arduino Watchdog Sniffs Out Hot 3D Printers” →

Buttery Smooth Fades With The Power Of HSV

June 18, 2018 by 20 Comments

In firmware-land we usually refer to colors using RGB. This is intuitively pleasing with a little background on color theory and an understanding of how multicolor LEDs work. Most of the colorful LEDs we are use not actually a single diode. They are red, green, and blue diodes shoved together in tight quarters. (Though interestingly very high end LEDs use even more colors than that, but that’s a topic for another article.) When all three light up at once the emitted light munges together into a single color which your brain perceives. Appropriately the schematic symbol for an RGB LED without an onboard controller typically depicts three discrete LEDs all together. So it’s clear why representing an RGB LED in code as three individual values {R, G, B} makes sense. But binding our representation of color in firmware to the physical system we accidentally limit ourselves.

The inside of an RGB LED

Last time we talked about color spaces, we learned about different ways to represent color spatially. The key insight was that these models called color spaces could be used to represent the same colors using different groups of values. And in fact that the grouped values themselves could be used to describe multidimensional spacial coordinates. But that post was missing the punchline. “So what if you can represent colors in a cylinder!” I hear you cry. “Why do I care?” Well, it turns out that using colorspace can make some common firmware tasks easier. Follow on to learn how!

Continue reading “Buttery Smooth Fades With The Power Of HSV” →

Watch The World Spin With The Earth Clock

June 18, 2018 by 9 Comments

With the June solstice right around the corner, it’s a perfect time to witness first hand the effects of Earth’s axial tilt on the day’s length above and beyond 60 degrees latitude. But if you can’t make it there, or otherwise prefer a more regular, less deprived sleep pattern, you can always resort to simulations to demonstrate the phenomenon. [SimonRob] for example built a clock with a real time rotating model of Earth to visualize its exposure to the sun over the year.

The daily rotating cycle, as well as Earth’s rotation within one year, are simulated with a hand painted plastic ball attached to a rotating axis and mounted on a rotating plate. The hand painting was done with a neat trick; placing printed slivers of an atlas inside the transparent orb to serve as guides. Movement for both axes are driven by a pair of stepper motors and a ring of LEDs in the same diameter as the Earth model is used to represent the Sun. You can of course wait a whole year to observe it all in real time, or then make use of a set of buttons that lets you fast forward and reverse time.

Earth’s rotation, and especially countering it, is a regular concept in astrophotography, so it’s a nice change of perspective to use it to look onto Earth itself from the outside. And who knows, if [SimonRob] ever feels like extending his clock with an aurora borealis simulation, he might find inspiration in this northern lights tracking light show.

This is a spectacular showpiece and a great project you can do with common tools already in your workshop. Once you’ve mastered earth, put on your machinists hat and give the solar system a try.

Fatalities Vs False Positives: The Lessons From The Tesla And Uber Crashes

June 18, 2018 by 175 Comments

In one bad week in March, two people were indirectly killed by automated driving systems. A Tesla vehicle drove into a barrier, killing its driver, and an Uber vehicle hit and killed a pedestrian crossing the street. The National Transportation Safety Board’s preliminary reports on both accidents came out recently, and these bring us as close as we’re going to get to a definitive view of what actually happened. What can we learn from these two crashes?

There is one outstanding factor that makes these two crashes look different on the surface: Tesla’s algorithm misidentified a lane split and actively accelerated into the barrier, while the Uber system eventually correctly identified the cyclist crossing the street and probably had time to stop, but it was disabled. You might say that if the Tesla driver died from trusting the system too much, the Uber fatality arose from trusting the system too little.

But you’d be wrong. The forward-facing radar in the Tesla should have prevented the accident by seeing the barrier and slamming on the brakes, but the Tesla algorithm places more weight on the cameras than the radar. Why? For exactly the same reason that the Uber emergency-braking system was turned off: there are “too many” false positives and the result is that far too often the cars brake needlessly under normal driving circumstances.

The crux of the self-driving at the moment is precisely figuring out when to slam on the brakes and when not. Brake too often, and the passengers are annoyed or the car gets rear-ended. Brake too infrequently, and the consequences can be worse. Indeed, this is the central problem of autonomous vehicle safety, and neither Tesla nor Uber have it figured out yet.

Continue reading “Fatalities Vs False Positives: The Lessons From The Tesla And Uber Crashes” →

Opening A Ford With A Robot And The De Bruijn Sequence

June 18, 2018 by 72 Comments

The Ford Securicode, or the keyless-entry keypad available on all models of Ford cars and trucks, first appeared on the 1980 Thunderbird. Even though it’s most commonly seen on the higher-end models, it is available as an option on the Fiesta S — the cheapest car Ford sells in the US — for $95. Doug DeMuro loves it. It’s also a lock, and that means it’s ready to be exploited. Surely, someone can build a robot to crack this lock. Turns out, it’s pretty easy.

The electronics and mechanical part of this build are pretty simple. An acrylic frame holds five solenoids over the keypad, and this acrylic frame attaches to the car with magnets. There’s a second large protoboard attached to this acrylic frame loaded up with an Arduino, character display, and a ULN2003 to drive the resistors. So far, everything you would expect for a ‘robot’ that will unlock a car via its keypad.

The real trick for this build is making this electronic lockpick fast and easy to use. This project was inspired by [Samy Kamkar]’s OpenSesame attack for garage door openers. In this project, [Samy] didn’t brute force a code the hard way by sending one code after another; (crappy) garage door openers only look at the last n digits sent from the remote, and there’s no penalty for sending the wrong code. In this case, it’s possible to use a De Bruijn sequence to vastly reduce the time it takes to brute force every code. Instead of testing tens of thousands of different codes sequentially, this robot only needs to test 3125, something that should only take a few minutes.

Right now the creator of this project is putting the finishing touches on this Ford-cracking robot. There was a slight bug in the code that was solved by treating the De Bruijn sequence as circular, but now it’s only a matter of time before a 1993 Ford Taurus wagon becomes even more worthless.

Dissecting The Elusive Wax Motor

June 18, 2018 by 34 Comments

We’d wager most readers aren’t intimately acquainted with wax motors. In fact, a good deal of you have probably never heard of them, let alone used one in a project. Which isn’t exactly surprising, as they’re very niche and rarely used outside of HVAC systems and some appliances. But they’re fascinating devices, and once you’ve seen how they work, you might just figure out an application for one.

[AvE] recently did a complete teardown on a typical wax motor, going as far as cutting the thing in half to show the inner workings. Now we’ve seen some readers commenting that everyone’s favorite foul-mouthed destroyer of consumer goods has lost his edge, that his newer videos are more about goofing off than anything. Well we can’t necessarily defend his signature linguistic repertoire, but we can confidently say this video does an excellent job of explaining these little-known gadgets.

The short version is that a wax motor, which is really a linear actuator, operates on the principle that wax expands when it melts. If a solid block of wax is placed in a cylinder, it can push on a piston during the phase change from solid to liquid. As the liquid wax resists compression, the wax motor has an exceptionally high output force for such a small device. The downside is, the stroke length is usually rather short: for the one [AvE] demonstrates, it’s on the order of 2 mm.

By turning heat directly into mechanical energy, wax motors are often used to open valves and vents when they’ve reached a specific temperature. The common automotive engine thermostat is a classic example of a wax motor, and they’re commonly found inside of dishwashers as a way to open the soap dispenser at the proper time during the cycle.

This actually isn’t the first time we’ve featured an in-depth look at wax motors, but [AvE] actually cutting this one in half combined with the fact that the video doesn’t look like it was filmed on a 1980’s camera makes it worth revisiting the subject. Who is going to build a wax motor power device for the Power Harvesting Challenge in the 2018 Hackaday Prize?

Continue reading “Dissecting The Elusive Wax Motor” →

Searchable KiCad Component Database Makes Finding Parts A Breeze

June 17, 2018 by 15 Comments

KiCad, the open source EDA software, is popular with Hackaday readers and the hardware community as a whole. But it is not immune from the most common bane of EDA tools. Managing your library of symbols and footprints, and finding new ones for components you’re using in your latest design is rarely a pleasant experience. Swooping in to help alleviate your pain, [twitchyliquid64] has created KiCad Database (KCDB). a beautifully simple web-app for searching component footprints.

The database lets you easily search by footprint name with optional parameters like number of pins. Of course it can also search by tag for a bit of flexibility (searching Neopixel returned the footprint shown above). There’s also an indicator for Kicad-official parts which is a nice touch. One of our favourite features is the part viewer, which renders the footprint in your browser, making it easy to instantly see if the part is suitable. AngularJS and material design are at work here, and the main app is written in Go — very trendy.

The database is kindly publicly hosted by [twitchyliquid64] but can easily be run locally on your machine where you can add your own libraries. It takes only one command to add a GitHub repo as a component source, which then gets regularly “ingested”. It’s great how easy it is to add a neat library of footprints you found once, then forget about them, safe in the knowledge that they can easily be found in future in the same place as everything else.

If you can’t find the schematic symbols for the part you’re using, we recently covered a service which uses OCR and computer vision to automatically generate symbols from a datasheet; pretty cool stuff.