Aluminum No Match For 3D Printed Press Brake Dies

If you’re looking for a get-rich-quick scheme, you can scratch “Doing small-scale manufacturing of ultralight aircraft” off your list right now. Turns out there’s no money in it. At least, not enough money that you can outsource production of all the parts. Not even enough to setup a huge shop full of customized machining tools when you realize you have to make the stuff yourself. No, this sounds like one of those “labors of love” we always hear so much about.

So how does one do in-house manufacturing of aircraft with a bare minimum of tools? Well, since you’re reading this on Hackaday you can probably guess that you’ve got to come up with something a bit unorthodox. When [Brian Carpenter] of Rainbow Aviation needed a very specific die to bend a component for their aircraft, he decided to try designing and 3D printing one himself.

Printing a die on the Zortrax M200

He reasoned that since he had made quick and dirty dies out of wood in the past, that a 3D printed one should work for at least a few bends before falling apart. He even planned to use JB Weld to fill in the parts of the printed die which he assumed would start cracking and breaking off after he put it through a few cycles. But even after bending hundreds of parts, wear on the dies appears to be nearly non-existent. As an added bonus, the printed plastic dies don’t mar the aluminum pieces they are bending like the steel dies do.

So what’s the secret to printing a die that can bend hundreds of pieces of aluminum on a 20 ton brake without wearing down? As it turns out…not a whole lot. [Brian] attributes the success of this experiment to designing the die with sufficiently accurate tolerances and having so high of an infill that it may as well be solid plastic.

In fact, the 3D printed die worked out so well that they’ve now expanded the idea to a cheap Harbor Freight brake. Before this tool was going more or less unused as it didn’t have features they needed for the production of their parts, namely a radius die or backstop. But by 3D printing these components [Brian] was able to put the tool back to work.

We’ve previously covered the art and science of bending sheet metal, as well as a homebuilt brake that let’s you do it on a budget even Rainbow Aviation would scoff at. So what are you waiting for? Go build an airplane.

Thanks to [Oahupilot] for the tip.

Continue reading “Aluminum No Match For 3D Printed Press Brake Dies”

Software Design Patterns For Real Hardware

Here on Hackaday, we’re generally designers of hacks that live in the real world. Nevertheless, I’m convinced that some of the most interesting feats are at the mercy of what’s possible in software, not hardware. Without the right software, no 3D printer could print and no quadcopter could fly. The source code that drives these machines may take months of refinement to flesh out their structure. In a nutshell, these software packages are complicated, and they don’t happen overnight.

So how do they happen; better yet: how could we make that happen? How do we write software that’s flexible enough to coexist peacefully on all sorts of hardware variations?

What separates the big open-source software projects like ROS, LinuxCNC, and Multiwii from the occastional hackathon code are the underlying principles that govern how they’re written. In object-oriented programming, these principles are called design patterns. In the next couple posts, I’m going to crack the lid on a few of these. What’s more, I’ll package them into real-world examples so that we can see these patterns interact with real hardware. The next time you pop open the source code for a big open source hardware project, I hope you can tease out some of these patterns in the code. Better yet, I hope you carry these patterns into your next robot and machine project. Let’s get started.

For readability, all of the examples run in Python3. The snippets below are truncated for brevity, but the real examples in the repository will work if you’ve got a similar hardware setup.

Continue reading “Software Design Patterns For Real Hardware”

Apple Passwords: They All ‘Just Work’

When the Macintosh was released some thirty-odd years ago, to Steve Jobs’ triumphant return in the late 90s, there was one phrase to describe the simplicity of using a Mac. ‘It Just Works’. Whether this was a reference to the complete lack of games on the Mac (Marathon shoutout, tho) or a statement to the user-friendliness of the Mac, one thing is now apparent. Apple has improved the macOS to such a degree that all passwords just work. That is to say, security on the latest versions of macOS is abysmal, and every few weeks a new bug is reported.

The first such security vulnerability in macOS High Sierra was reported by [Lemi Ergin] on Twitter. Simply, anyone could login as root with an empty password after clicking the login button several times. The steps to reproduce were as simple as opening System Preferences, Clicking the lock to make changes, typing ‘root’ in the username field, and clicking the Unlock button. It should go without saying this is incredibly insecure, and although this is only a local exploit, it’s a mind-numbingly idiotic exploit. This issue was quickly fixed by Apple in the Security Update 2017-001

The most recent password flaw comes in the form of unlocking the App Store preferences that can be unlocked with any password. The steps to reproduce on macOS High Sierra are simply:

  • Click on System Preferences
  • Click on App Store
  • Click the padlock icon
  • Enter your username and any password
  • Click unlock

This issue has been fixed in the beta of macOS 10.13.3, which should be released within a month. The bug does not exist in macOS Sierra version 10.12.6 or earlier.

This is the second bug in macOS in as many months where passwords just work. Or don’t work, depending on how cheeky you want to be. While these bugs have been overshadowed with recent exploits of Intel’s ME and a million blog posts on Meltdown, these are very, very serious bugs that shouldn’t have happened in the first place. And, where there are two, there’s probably more.

We don’t know what’s up with the latest version of the macOS and the password problems, but we are eagerly awaiting the Medium post from a member of the macOS team going over these issues. We hope to see that in a decade or two.

Local Infrastructure: The Devil Is In The Details

About two months ago I rode my bike to work like any other day, but on the way home a construction project seemed to have spontaneously started at one of the bridges that I pass over. Three lanes had merged into one which, for a federal highway, seemed like a poorly planned traffic pattern for a such a major construction project. As it happens, about an hour after I biked across this bridge that morning both outside sections of the bridge fell into the water. There was no other physical damage that seemed to explain why parts of a bridge on U.S. 1 would suddenly collapse.

The intriguing thing about this bridge collapse was that the outer retaining wall and about half of the sidewalk on both the northbound side and the southbound side had fallen into the water at the same time. This likely wasn’t caused by something like a boat impact, car accident, or an overweight truck. Indeed, Florida Department of Transportation (FDOT) investigated the incident and found that two post tension wires that held these sections of the bridge together had failed, making it unsafe for pedestrians and bicyclists but also for any boaters below. Continue reading “Local Infrastructure: The Devil Is In The Details”

Meltdown Code Proves Concept

If you’ve read about Meltdown, you might have thought, “how likely is that to actually happen?” You can more easily judge for yourself by looking at the code available on GitHub. The Linux software is just proof of concept, but it both shows what could happen and — in a way — illustrates some of the difficulties in making this work. There are also two videos in the repository that show spying on password input and dumping physical memory.

The interesting thing is that there are a lot of things that will stop the demos from working. For example a slow CPU, a CPU without out-of-order execution, or an imprecise high-resolution timer. This is apparently especially problematic in virtual machines.

Continue reading “Meltdown Code Proves Concept”

You Got A 3D Printer, Now What?

Given the incredibly low prices on some of the models currently on the market, it’s more than likely a number of Hackaday readers have come out of the holiday season with a shiny new desktop 3D printer. It’s even possible some of you have already made the realization that 3D printing is a bit harder than you imagined. Sure the newer generation of 3D printers make it easier than ever, but it’s still not the same “click and forget” experience of printing on paper, for instance.

In light of this, I thought it might be nice to start off the new year with some advice for those who’ve suddenly found themselves lost in a forest of PLA. Some of this information may seem obvious to those of us who’ve spent years huddled over a print bed, but as with many technical pursuits, we tend to take for granted the knowledge gained from experience. For my own part, the challenges I faced years ago with my first wooden 3D printer were wholly different than what I imagined. I assumed that the real challenge would be getting the machine assembled and running, but the time it took to build the machine was nothing in comparison to the hours and hours of trial and error it took before I gained the confidence to really utilize the technology.

Of course, everyone’s experience is bound to be different, and we’d love to hear about yours in the comments. Grand successes, crushing defeats, and everything in between. It’s all part of the learning process, and all valuable information for those who are just starting out.

Continue reading “You Got A 3D Printer, Now What?”

PostMarketOS Saves Old Smartphones

Modern smartphones, even the budget models, are extremely impressive pieces of technology. Powerful ARM processors, plenty of RAM, and an incredible number of sensors and radios are packed into a device that in some cases are literally given away for free when you sign up for a service plan. Unfortunately manufacturers are not obligated to keep up with software updates, and while the hardware may be willing to keep on fighting, the user is often pushed to upgrade due to perennially outdated software. Even if you aren’t the kind of person to be put off by using a phone that doesn’t have the latest and greatest OS, the lack of software security updates pose a clear threat in a world where mobile devices are increasingly targeted by attackers.

But what if the operating system on your phone worked more like the on one your computer? That’s the dream of postmarketOS, a Linux distribution created by [Oliver Smith] that is designed to be installed on outdated (mostly Android) smartphones and tablets. He’s recently made a comprehensive blog post about the state of the project a little over 6 months since it started, and we have to say things are looking very impressive so far.

One of the key goals of postmarketOS is to avoid the fragmented nature of previous attempts at replacing Android with a community-developed operated system. By avoiding binary blobs and focusing on getting the mainline Linux kernel running on as much as the hardware as possible, there’s no need to make different forks and releases for each supported device. By unifying the OS as much as far as it can be, an upstream update can be pushed to all devices running postmarketOS regardless of their make and model, just like with traditional Linux distributions.

The blog post shows two things very clearly: that the community is extremely excited and dedicated to the prospect of running what is essentially desktop Linux on old smartphones and tablets, and that postmarketOS still has a long way to go. In these early days, many devices aren’t what could be considered “daily drivers” by most standards. In fact, the blog post mentions that they’ve decided to abandon the term “supported” when talking about devices, and make no claims beyond the fact that they will boot.

Still, incredible progress is being made on everything from mainline kernel development to getting standard Linux desktops such as Gnome, MATE and XFCE4 running. Work has also been done on the backend process of compiling and packaging up components of the operating system itself, promising to speed up development times even for those who don’t have a beefy machine they can dedicate to compiling. The blog post ends with a helpful list of things the reader can do to help support postmarketOS, ranging from making your own t-shirts to porting to new hardware.

At Hackaday we’ve seen our fair share of hackers and makers re-purposing old smartphones and tablets, keeping them out of the landfills they would almost certainly end up in otherwise. A project that aims to make it even easier to hack these cheap and incredibly useful devices is music to our ears.