After sketching the design on paper, the design process moves into the digital domain, where an accurate 3D model of the wearer is required. [Nancy] created hers with Make Human, a free software that creates to-size avatars of humans from tape-measured parameters. Using the professional garment modeling software MarvelousDesigner (which offers a 30 day trial version), she then created the actual layout. The software allows her to design the cutting patterns, and then also drapes the fabric around the human model in a 3D garment simulation to check the fit. The result are the cutting patterns and a 3D model of the garment.
Hackaday.io contributor extraordinaire [davedarko] gets hot in the summer. We all do. But what separates him from the casual hacker is that he beat the heat by ordering four 120 mm case fans. He then 3D printed a minimalistic tower frame for the fans, and tied them all together with a ULN2004 and an ESP8266. The whole thing is controlled over the network via MQTT. That’s dedication to staying cool.
We really like the aesthetics of this design. A fan made up of fans! But from personal experience, we also know that these large case fans can push a lot of air fairly quietly. That’s important if you’re going to stand something like this up on your desk. While we’re not sure that a desk fan really needs networked individual PWM speed control, we can see the temptation.
Now that they’re individually controlled, nothing stops [davedarko] from turning this into a musical instrument, or even using the fans to transmit data. The only thing we wouldn’t do, despite the temptation to stick our fingers in the blades, is to complicate the design visually. Maybe that would finally teach the cat not to walk around on our desk.
Measuring length is a pain, and it’s all the fault of Imperial measurements. Certain industries have standardized around either Imperial or metric, which means that working on projects across multiple industries generally leads to at least one conversion. For everyone outside the last bastion of Imperial units, here’s a primer on how we do it in crazy-land.
The basic unit of length measurement in Imperial units is the inch. twelve inches make up one foot, three feet make up one yard, and 5,280 feet (or 1,760 yards) make up a mile. Easy to remember, right?
Ironically, an inch is defined in metric as 25.4 millimeters. You can do the rest of the math for exact lengths, but in general, three feet is just shy of a meter, and a mile is about a kilometer and a half. Generally in Imperial you’ll see lots of mixed units, like a person’s height is 6’2″ (that’s shorthand for six feet, two inches.) But it’s not consistent, it’s English; the only consistency is that it’s always breaking its own rules. You wouldn’t say three yards, two feet, and six inches; you’d say 11 1/2 feet. If it was three yards, one foot, and six inches, though, you’d say 3 1/2 yards. There’s no good rule for this other than try to use nice fractions as often as you can.
Users of Imperial units love fractions, especially when it comes to parts of an inch or mile. You’ll frequently find drill bits in fractions of an inch, which can be extremely frustrating when you are trying to do math in your head and figure out if a 17/64″ bit is bigger than a 1/4″ bit (hint, yes, it’s 1/64″ bigger).
If it wasn’t hard enough already, there came the thousandth of an inch. As the machine age was getting better and better, and parts were getting smaller and more precise, there came a need for more accurate measurements than 1/64 inch. Development of appropriate tools for measuring such fine resolution was critical as well. You can call a 1/8″ bit a .125″ bit, and that means 125 thousandths of an inch. People didn’t like to wrap their mouths around that whole word, though, so it was reduced to “thou.” Others used the latin root for thousand, “mil.” To summarize, a mil is the equivalent of a thou, which is one thousandth of an inch. It should not be confused with a millimeter. It takes about 40 mils to make 1 millimeter. Also, the plural of mil is mils, and the plural of thou is thou.
Measuring length is done with a variety of tools, from GPS for long distances, to tape measures for feet/meters, and rulers for inches/centimeters. When it comes to very small measurements, the caliper is the tool of choice. This is the kind of tool that should be in everyone’s toolbox. Initially it started with the inside caliper and outside caliper, which were separate tools used to measure lengths. The Vernier caliper combined the two, added a depth meter and a couple other handy features, and gave machinists an all-around useful tool for measuring. Just like the slide rule, though, as soon as digital options became available, they took over. The digital caliper can usually switch modes between decimal inches, fractional inches, and metric.
Every industry has picked a different convention. Plastic sheets are usually measured in mils for thin stuff and millimeters or fractions of an inch for anything greater than 1/32″. Circuit boards combine units in every way imaginable, sometimes combining mils for trace width and metric for board dimensions, with the thickness of the copper expressed in ounces. (That’s not even a unit of length! It represents the amount of copper in one square foot of area and 1 oz is equivalent to 1.4mil.) Most of the time products designed outside of the U.S. are in metric units, while U.S. products are designed in either. When combining different industries, though, the difference in standards gets really annoying. For example, order 1/8″ plexiglass, and you may get 3mm plexiglass instead. Sure the difference is only .175mm (7 thou), but that difference can cause big problems for pieces that are press fit or when making finger joints on boxes, so it’s important that when sourcing components, you not only verify the unit, but if it’s a normal unit for that industry and it’s not just being rounded.
Often you can tell with what primary unit a product is designed with only a few measurements of a caliper. Find a dimension and see if it’s a nice round number in metric. If it’s not, switch it to imperial, and watch how quickly it snaps to a nice number.
Use metric if you can. The vast majority of the world does it. When you are sending designs overseas for production they will convert to metric (though they are used to working in both). It does take time to get used to it (especially when you are dealing with thou/mils), but your temporary discomfort will turn to relief when your design doesn’t crash into the Mars (or more realistically when you don’t have to pull out the Dremel and blade to get your parts to fit together).
Near the end of the lifecycle of mass-market commercial product development, an engineering team may come in and make a design for manufacturability (DFM) pass. The goal is to make the device easy, cheap, and reliable to build and actually improve reliability at the same time. We hackers don’t usually take this last step, because when you’re producing just a couple of any given device, it hardly makes sense. But when you release an open-source hardware design to the world, if a lot of people re-build your widget, it might be worth it to consider DFM, or at least a hardware hacker’s version of DFM.
If you want people to make their own versions of your project, make it easy and cheap for them to do so and don’t forget to also make it hackable. This isn’t the same as industrial DFM: rather than designing for 100,000s of boards to be put together by robot assembly machines, you are designing for an audience of penny-pinching hackers, each building your project only once. But thinking about how buildable your design is will still be worthwhile.
In this article, I’m going to touch on a couple of Design for Hackers (DFH) best practices. I really want to hear your experience and desires in the comments. What would you like to see in someone else’s open designs? What drives you nuts when replicating a project? What tricks do you know to make a project easily and cheaply buildable by the average hacker?
We’re all particular about our chosen hobbies. Some of us like one design direction and hate another. For [Waalcko], he really hates internal supports in kites. When he spied a single line kite in a circular foil configuration he was enraptured, but the design had those hideous spars. So, he got to work and pushed himself to the limit coming up with a kite that was a circular foil, flew with one line, and had no internal supports.
His instructable is a great read and goes into deep detail about the basics of kite construction. (After reading it we’re certain that even the shallows have depths when it comes kites.) It goes through the terminology used when talking about kits, the techniques used to assemble them, the common problems, and more.
Many hours later, if all goes well, one should end up with a really cool kite.
It’s pretty awesome to have a hardware design hero jump at the chance to work on a Hackaday conference badge. I am of course talking about Voja Antonic.
I’ve gotten to know him over the last two years when we were introduced and he agreed to work on some original articles. He’s long been a hacker and shared his story of technology despite politics and society changing around him. His Galaksija computer was the first personal computer available in Yugoslavia with over 8,000 kits sold. Since those days he never stopped refining his design and fabrication skills. For instance, his method of making cases from FR4 is beyond compare, and reading some of his wisdom from hardware design in the casino industry is the kind of fascinating stuff that rarely makes it out for others to enjoy.
But I digress — the point is Voja’s been around the block, he knows what he’s doing, and he does it at an amazingly high level. He did an incredible job with the Hackaday | Belgrade conference badge. It features a 16×8 LED display, IR comms hardware, 5 user buttons, USB programming, an option for an accelerometer module, and has spectacular life running on two AAA batteries. It was a hit at the conference, and so was his talk discussing the design and fabrication. Check it out below and then join me below the fold.
[Daniel Reetz] spent six years working as a Disney engineer during the day and on his book scanner, the archivist at night. Some time last year, [Daniel] decided enough is enough, got married, and retired from the book scanner business. There’s a bit more to it than that, but before leaving he decided to dump, not just the design, but the entire rationale behind the design into a twenty-two thousand word document.
One of his big theses in this document, is his perceived failure of the open hardware movement. The licenses aren’t adequate, as they are based on copyright law that only applies to software. This makes it impossible to enforce in practice, which is why he released the entire design as public domain. He also feels that open hardware shares design, but not rationale. In his mind this is useless when encouraging improvement, and we tend to agree. In the end rationale is the useful thing, or the source code, behind a design that truly matters. So, putting his money time where his mouth is, he wrote down the rationale behind his scanner.
The rationale contains a lot of interesting things. At a first glance the book scanner almost seems a simple design, not the culmination of so much work. Though, once we began to read through his document, we began to understand why he made the choices he did. There’s so much to getting a good scan without destroying the book. For example, one needs a light that doesn’t lose any color information. It doesn’t have to be perfect, as the software can correct the white balance. However, it can’t lean too far away from the natural spectrum, it can’t be too bright, and it can’t be uneven, and it can’t be prohibitively expensive. A lot of thought went into the tent light design.
[Daniel]’s book scanners are immensely popular, and are being used all over the world. He’s certainly made an impact, and the community that formed around his project continues to grow without him. He made some interesting points, and if anything wrote a really good build and design log for the rest of us to learn from.