Of all the parts on your average desktop 3D printer, the nozzle itself is arguably where the real magic happens. Above the nozzle, plastic is being heated to the precise temperature required to get it flowing smoothly. Immediately below the nozzle there’s a fan blowing to get the plastic cooled back down again. This carefully balanced arrangement of heating and cooling is the secret that makes high quality fused deposition modeling (FDM) printing possible.
But as it turns out, getting the plastic hot ends up being easier than cooling it back down again. The harsh reality is that most of the fans small enough to hang on the side of a 3D printer nozzle are pretty weak. They lack the power to push the volume of air necessary to get the plastic cooled down fast enough. But with his latest project, [Mark Rehorst] hopes to change that. Rather than using some anemic little fan that would be better suited blowing on the heatsink of a Raspberry Pi, he’s using a hacked CPAP machine to deliver some serious airflow.
The brilliance of using a CPAP machine for this hack is two-fold. For one, the machine uses a powerful centrifugal fan rather than the wimpy axial “muffin” fans we usually see on 3D printers. Second, the CPAP pushes air down a lightweight and flexible hose, which means the device itself doesn’t have to be physically mounted to the printer head. All you need is manifold around the printer’s nozzle that connects up to the CPAP hose. This “remote” fan setup means the print head is lighter, which translates (potentially) into higher speed and acceleration.
[Mark] was able to connect the fan MOSFET on his printer’s SmoothieBoard controller up to the brushless motor driver from the CPAP motor, which lets the printer control this monster new fan. As far as the software is concerned, nothing has changed.
He hasn’t come up with a manifold design that’s really optimized yet, but initial tests look promising. But even without a highly optimized outlet for the air, this setup is already superior to the traditional part cooler designs since it’s got more power and gets the fan motor off of the print head.
We’ve been having a lively discussion behind the scenes here at Hackaday, about SpaceX’s forthcoming launch of their first Falcon Heavy rocket. It will be carrying [Elon Musk]’s red Tesla Roadster, and should it be a successful launch, it will place the car in an elliptical orbit round the Sun that will take it to the Martian orbit at its furthest point.
On one hand, it seems possible that [Musk]’s sports car will one day be cited by historians as the exemplar of the excesses of the tech industry in the early 21st century. After all, to spend the millions of dollars required to launch the largest reusable space launch platform ever created, and then use it to hurl an electric vehicle into orbit round the Sun seems to be such a gratuitous waste of resources, an act of such complete folly as to be criminal.
Surely even given that there is a reasonable chance of a first launch ending in fiery destruction it must be worth their while canvassing the universities and research institutions of the world with the offer of a free launch, after all there must be a significant amount of science that would benefit from some cost-free launch capacity! It seems a betrayal of the famous “Why explore space” letter from the associate science director of NASA to a nun who questioned the expenditure while so many in the developing world were starving.
Testing
But on the other hand, first launches of rockets are a hazardous endeavour, as the metaphorical blue touchpaper is lit on the world’s largest firework for the first time. Satellites are expensive devices, and it would be a foolhardy owner who entrusted their craft to a launch vehicle with a good chance of a premature splashdown.
First launches traditionally carry a ballast rather than a payload, for example NASA have used tanks of water for this purpose in the past. SpaceX has a history of novelty payloads for their test launches; their first Dragon capsule took a wheel of cheese into space and returned it to Earth. We picture Musk looking around a big warehouse and saying, “well, we got a lot of cars!”
There is a fascinating question to be posed by the launch of the car, just what did they have to do to it to ensure that it could be qualified for launch? Satellite manufacture is an extremely exacting branch of engineering, aside from the aspect of ensuring that a payload will work it must both survive the launch intact and not jeopardise it in any way. It’s safe to say that the Roadster will not have to function while in orbit as the roads of California will be far away, but cars are not designed with either the stresses of launch or the transition to zero gravity and the vacuum of space in mind. Will a glass windscreen originally specified for a Lotus Elise on the roads of Norfolk shatter during the process and shower the inside of the craft with glass particles, for example? There must have been an extensive space qualification programme for it to pass, from vibration testing through removal of any hazards such as pressurised gases or corrosive chemicals, if only the folks at SpaceX would share some its details that would make for a fascinating story in itself.
Space Junk
So the Tesla Roadster is a huge publicity stunt on behalf of SpaceX, but it serves a purpose that would otherwise have to have been taken by an unexciting piece of ballast. It will end up as space junk, but in an orbit unlikely to bring it into contact with any other craft. If its space-suited dummy passenger won’t be providing valuable data on the suit’s performance we’d be extremely surprised, and when it is finally retrieved in a few centuries time it will make a fascinating exhibit for the Smithsonian.
Given a huge launch platform and the chance to fill it with a novelty item destined for orbit,the Hackaday team stepped into overdrive with suggestions as to what might be launched were they in charge. They varied from Douglas Adams references such as a heart of gold or a whale and a bowl of petunias should the rocket abort and the payload crash to earth, to a black monolith and a few ossified ape remains to confuse space historians. We briefly evaluated the theory that the Boring Company is in fact a hiding-in-plain-sight construction organisation for a forthcoming Evil Lair beneath the surface of Mars, before concluding that maybe after all the car is a pretty cool thing to use as ballast for a first launch.
It may be reaching towards seven decades since the first space programmes successfully sent rockets beyond the atmosphere with the aim of exploration, but while the general public has become accustomed to them as routine events they remain anything but to the engineers involved. The Falcon Heavy may not have been developed by a government, but it represents every bit as astounding an achievement as any of its predecessors. Flinging an electric vehicle into orbit round the Sun is a colossal act of showmanship and probably a waste of a good car, but it’s also more than that. In hundreds of years time the IoT devices, apps, 3D printers, quadcopters or whatever else we toil over will be long forgotten. But there will be a car orbiting the Sun that remains a memorial to the SpaceX engineers who made its launch possible, assuming it doesn’t blow up before it gets there. What at first seemed frivolous becomes very cool indeed.
Polyglots, in computing terms, are files have multiple valid meanings. We’ve seen some amazing examples of polyglot files in releases of The International Journal of PoC||GTFO. One example: a PDF that is also a ZIP, HTML file, and BPG image.
[Vi Grey] was inspired by PoC||GTFO’s release of a PDF/ZIP/NES ROM hybrid file for issue 0x14. Using a different method, [Vi] created a file which is both an NES ROM and ZIP, where the full contents of the ZIP are stored in the NES ROM.
When PoC||GTFO created their NES ROM polyglot, they stuck most the information outside the bounds of the NES ROM. While the file is valid, you’d lose the ZIP archive if it was burnt to a cartridge.
[Vi]’s polyglot is different. Rip it from a real NES cartridge and you get a ZIP file. Unzip it, and you get the source. Compile that source, and you get a valid ZIP file containing the source. Burn that to a cartridge and… hopefully you grok the recursion at this point.
The source and scripts to mangle the polyglot together are up on Github.
Increasingly these days drones are being used for urban surveillance, delivery, and examining architectural structures. To do this autonomously often involves using “map-localize-plan” techniques wherein first, the location is determined on a map using GPS, and then based on that, control commands are produced.
A neural network that does steering and collision prediction can compliment the map-localize-plan techniques. However, the neural network needs to be trained using video taken from actual flying drones. But generating that training video involves many hours of flying drones at street level putting vehicles and pedestrians at risk. To train their DroNet, Researchers from the University of Zurich and the Universidad Politecnica de Madrid have come up with safer sources for that video, video recorded from driving cars and bicycles.
For the drone steering predictions, they used over 70,000 images and corresponding steering angles from the publically available car driving data from Udacity’s Open Source Self-Driving project. For the collision predictions, they mounted a GoPro camera to the handlebars of a bicycle and drove around a city. Video recording began when the bicycle was distant from an object and stopped when very close to the object. In total, they collected 32,000 images.
To use the trained network, images from the drone’s forward-facing camera were fed into the network and the output was a steering angle and a probability of collision, which was turned into a velocity. The drone remained at a constant height above ground, though it did work well from 1.5 meters to 5 meters up. It successfully navigated road lanes and avoided moving pedestrians and bicycles. Intersections did confuse it though, likely due to the open spaces messing with the collision predictions. But we think that shouldn’t be a problem when paired with map-localize-plan techniques as a direction to move through the intersection would be chosen for it using the location on the map.
As you can see in the video below, it not only does a decent job of flying down lanes but it also flies well in a parking garage and a hallway, even though it wasn’t trained for either of these.
We’ve all been there — a steamy night in the rainforest of Papua New Guinea, sweaty slumber disturbed by the unmistakable sounds of gnawing. In the morning we discover that a rodent of unusual tastes has chewed the microphone cable of our transceiver right half in two, leaving us out of touch with base camp. If we had a nickel for every time that’s happened.
It may sound improbable, but that’s the backstory behind [Marius Taciuc]’s 3D-printed mic cord repair. Even with more mundane failure modes, the retractile cords on microphones are notoriously difficult to fix. Pretty much any of the usual suspects, like heat-shrink tubing or electrical tape, are going to do very little to restore the mechanical stability lost once that tough outer jacket is breached. [Marius]’s solution was to print as small an enclosure as possible to mechanically support the splice. The fit is tight, but there was just enough room to solder the wires and stuff everything back in place. Cable ties provide strain relief where the cord exits the splice, and a liberal squirt of hot glue pots the joint. It’s not perfect — we’ll bet the splice acts as a catch point and gets a little annoying after a while — but if it gets you back on the air fast and cheap, it probably makes sense.
[Marius] entered this rat-race beating hack into the Repairs You Can Print contest. Do you have an epic repair that was made possible by a 3D printer? Let the world know about it and you might just win a prize.
Model railways are a deep and rewarding hobby, and the mechanisms involved can be both surprisingly intricate and delightful. A great example that may surprise the unfamiliar is that of model train carriages, such as coal cars, that are capable of both receiving and dumping a load at various points on a model layout. This adds realism and, if we’re honest, just plain old fun.
This is the perfect example of a tidy repair executed through 3D printing. The broken part was extremely detailed and would be difficult and expensive to repair or fabricate through other measures. However, through the power of 3D printing, all that’s required is a 3D modelling job and a few hours to print it.
It’s a great entry into our Repairs You Can Print challenge, and covers the fundamentals of modelling and iterative design well. Got a neat repair you’ve done yourself? Document it on Hackaday.io and enter yourself!
The Casio SK-1 keyboard is fairly well-known in the “circuit bending” scene, where its simple internals lend themselves to modifications and tweaks to adjust the device’s output in all sorts of interesting ways. But creating music via circuit bending the SK-1 can be tedious, as it boils down to fiddling with the internals blindly until it sounds cool. [Nick Price] wanted to do something a bit more scientific, and decided to try replacing his SK-1’s ROM with an Arduino so he could take complete control it.
That’s the idea, anyway. Right now he’s gotten as far as dumping the ROM and getting the Arduino hooked up in place of it. Unfortunately the resulting sound conjures up mental images of a 56K modem being cooked in a microwave. Clearly [Nick] still has some work ahead of him.
For now though, the progress is fascinating enough. He was able to pull the original NEC 23C256 chip out of the keyboard and read its contents using an Arduino and some code he cooked up, and he’s even put the dump online for any other SK-1 hackers out there. He then wrote some new code for the Arduino to spit data from the ROM dump back to the keyboard when requested. In theory, it should sound the same as before, but with the added ability to “forge” the data going back to the keyboard to make new sounds.
The result is what you hear in the video linked after the break. Not exactly what [Nick] had in mind. After some snooping with the logic analyzer, he believes the issue is that the Arduino can’t respond as fast as the original NEC chip did. He’s now got an NVRAM chip on order to replace the original NEC chip; the idea is that he can still use the Arduino to reprogram the NVRAM chip when he wants to play around with the sound.