[Aldric Négrier] wrote in to let us know that his DriveMyPhone project has been open sourced. The project is a part telepresence, part remote-controlled vehicle, part robotic rover concept on which he says “I spent more time […] than I should have.” He has shared not just the CAD files, but every detail including tips on assembly. He admits that maybe a robotic chassis for a smartphone might not seem like a particularly new idea today, but it was “an idea with more potential” back in 2010 when he first started.
The chassis is made to cradle a smartphone. Fire up your favorite videoconferencing software and you have a way to see where you’re going as well as hear (and speak to) your surroundings. Bluetooth communications between the phone and the chassis provides wireless control. That being said, this unit is clearly designed to be able to deal with far more challenging terrain than the average office environment, and has been designed to not only be attractive, but to be as accessible and open to repurposing and modification as possible.
[Evan] found his minion at a McDonald’s and took out essentially everything inside of it, using the minion as a case for all of the interesting bits. First he scavenged a PS/2 port from an old motherboard. An Arduino Nano is wired to an HC-05 Bluetooth chip to translate the signals from the PS/2 peripherals into Bluetooth. The HC-05 chip is a cheaper alternative to most other Bluetooth chips at around $3 vs. $40 for more traditional ones. The programming here is worth mentioning: [Evan] wrote a non-interrupt based and non-blocking PS/2 library for the Arduino that he open sourced which is the real jewel of this project.
Once all the wiring and programming is done [Evan] can turn essentially any old keyboard and mouse into something that’ll work on any modern device. He also put an NFC tag into the minion’s head so that all he has to do to connect the keyboard and mouse is to swipe his tablet or phone past the minion.
We posted about a 3D printer fire a while back. An attendee of the Midwest RepRap Fest had left his printer alone only to find its immolated remains on his return. In the spirit of open source, naturally, he shared his experience with the rest of us. It occurred to me that hackers are never powerless and there are active things to be done and avenues to explore.
There are really fantastic commercial fire extinguishing systems out there. One implementation, which is commonly deployed in cabinets and machining centers, is a plastic tube pressurized with an extinguishing agent by a connected tank. When a fire breaks out the tube melts at the hottest locations, automatically spraying the area with a suppressant. Variations of this involve a metal nozzle filled with a wax or plastic blended to melt at a certain temperature, much like the overhead fire sprinklers.
This system is also used inside engine compartments with success. For example, this item on amazon, is nothing but a pressurized plastic tube with a gauge on one end. Since the inside of an engine compartment can be treated as an enclosed space, very little fire suppressant is needed to extinguish an unexpected flame. It is important to note that this system works in a high temperature environment like an engine compartment, which bodes well for enclosed build envelopes on 3D printers.
Another option is to construct a suppressant mine. A Japanese and a Thai company have both come out with a throwable fire extinguisher. In the Japanese device, the outside of the extinguisher is a breakable glass vial which shatters upon impact; releasing the agent. The Thai device looks like a volley ball, and releases the agent upon the application of heat. This device seems like a better candidate for 3D printing or home projects. Imagine a small rectangular pack with adhesive on one side that sits near the possible fire points of the printer, such as under the bed or above the nozzle. In the event of a fire, the casing will melt and the system will automatically deploy a spray of extinguishing agent.
Most of the chemicals used in these constructions are benign and readily available. High pressure tubing and waxes can all be purchased and the desired melt points can be aligned with their datasheets by need. Plastic sheets are not hard to procure. These offer a nice solution due to their entirely passive nature. They don’t need power to operate and rely entirely on the properties of the materials they are constructed out of.
There are other options in active systems. Hackaday readers suggested things such as flame sensors for adding automatic cut-offs in case of a fire. Thermal fuses can also be considered in some cases. There are other tricks too, which are less kosher but will work nonetheless. For example, placing a critical wire, fuse, or component in the likely path of a fire so that it is destroyed first, stopping the operation of the device quickly. These avenues should be explored. At minimum there should be at least one project that uses a Raspberry Pi and an Arduino to tweet that fire suppression failed and the house is on fire.
Some of the big questions to ask are on the legal and ethical side. If someone started selling kits for a DIY fire suppression system and a fire ends up destroying someone’s property despite the device, who is responsible? Is it even safe to post instructions? What if a kit prematurely sets off and injures someone. I imagine a big part of the cost of these professional systems is some sort of liability insurance and certification. Still, putting a six hundred dollar fire suppression system on a six hundred dollar printer seems silly, and something is better than nothing.
Lastly, the comments directed a ton of flak towards the certification systems. There should be no reason that open source projects can’t produce their own specification for safety. An open source specification without an agency naturally couldn’t provide a legal defense against property damage, but a thought-out test program would provide piece of mind. For example, in the case of 3D printers, one could have a set of basic fail-safe tests. One example would be bringing the printer up to temperature and rapidly disconnecting the thermistor, does the printer erupt into fire? No? Good, it meets the spec. I wouldn’t mind knowing that the latest version of Marlin was tested on the popular boards and still met the community specification for fire safety.
As far as I can tell, there’s been very little work in open sourcing safety systems or in providing a testing framework for ensuring open hardware meets basic safety conditions. Many of you have experience with these systems. Some of you have gone through the entirely un-enjoyable process of getting a UL certification. What does Hackaday think?
With a welder and a bunch of scrap, you can build just about anything that moves. Want a dune buggy? That’s just some tube and a pipe bender. Need a water pump? You might need a grinder. A small tractor? Just find some big knobby tires in a junkyard. Of course, the one thing left out of all these builds is a small motor, preferably one that can run on everything from kerosene to used cooking oil. This is the problem [Shane] is tackling for his entry to the 2016 Hackaday Prize. It’s an Open Source Two-Stroke Diesel Engine that’s easy for anyone to build and has minimal moving parts.
[Shane]’s engine is based on the Junkers Jumo 205 motor, a highly successful aircraft engine first produced in the early 1930s and continued production through World War II. This is a weird engine, with two opposed pistons in one cylinder that come very close to slamming together. It’s a great design for aircraft engines due to it’s lightweight construction. And the simplicity of the system lends itself easily to wartime field maintenance.
The Jumo 205 was a monstrous 12-piston, 6-cylinder engine, but for [Shane]’s first attempt, he’s scaling the design down to a 50cc motor with the intent of scaling the design up to 125cc and 250cc. So far, [Shane] has about 30 hours of simple CAD work behind him and a ton of high-level FEA work ahead of him. Then [Shane] will actually need to build a prototype.
This is actually [Shane]’s second entry to the Hackaday Prize with this idea. Last year, he threw his hat into the ring with the same idea, but building a working diesel power plant is a lot of work. Too much for one man-year, certainly, so we can’t wait to see the progress [Shane] makes this year.
Researchers at Binghamton University have built their own graphics processor unit (GPU) that can be flashed into an FGPA. While “graphics” is in the name, this GPU design aims to provide a general-purpose computing peripheral, a GPGPU testbed. Of course, that doesn’t mean that you can’t play Quake (slowly) on it.
The Binghamton crew’s design is not only open, but easily modifiable. It’s a GPGPU where you not only know what’s going on inside the silicon, but also have open-source drivers and interfaces. As Prof. [Timothy Miller] says,
It was bad for the open-source community that GPU manufacturers had all decided to keep their chip specifications secret. That prevented open source developers from writing software that could utilize that hardware. With contributions from the ‘open hardware’ community, we can incorporate more creative ideas and produce an increasingly better tool.
Many successful large-scale projects don’t start out large: they start with a small working core and grow out from there. Building a completely open-source personal computer is not a weekend project. This is as much a retelling of events as it is background information leading up to a request for help. You’ll discover that quite a lot of hard work has already been put forth towards the creation of a completely open personal computer.
When I noticed the Kestrel Computer Project had been submitted via the Hackaday tips line I quickly tracked down and contacted [Samuel] and asked a swarm of questions with the excitement of a giddy schoolgirl. Throughout our email conversation I discovered that [Samuel] had largely kept the project under the radar because he enjoyed working on it in his down time as a hobby. Now that the project is approaching the need for hardware design, I posed a question to [Samuel]: “Do you want me to write a short article summarizing years of your work on Kestrel Project?” But before he could reply to that question I followed it up with another: “Better yet [Samuel], how about we tell a more thorough history of the Kestrel Project and ask the Hackaday community for some help bringing the project home!?” Continue reading “Kestrel Computer Project”→
Looking through the schematics (PDF), there’s not much to the card. At the center of everything is an ADuC7061, which is an ARM microprocessor equipped with 24-bit ADCs that also has an internal DAC-driven voltage reference connected to one of the user’s thumbs. This, plus a little buffering circuitry, seems to be enough to translate the tiny voltage potential difference across your two hands into a beautiful signal on the included OLED display. Very nice!
Everything (including the big version of their EKG) is open source and made on an open toolchain. If you’re interested in health and medical sensing, you should head over to the project’s GitHub and check it out. The standalone open EKG is based on a much more complicated circuit, and stands to be more accurate. But the business card version is just soooo cute!