When [314Reactor] got a robot car kit, he knew he wanted to add some extra things to it. At about the same time he was watching a Star Trek episode that featured exocomps — robots that worked in dangerous areas. He decided to use those fictional devices to inspire his modifications to the car kit. Granted, the fictional robots were intelligent and had a replicator. So you know he won’t make an actual working replica. But then again, the ones on the TV show didn’t have all that either.
A Raspberry Pi runs Tensorflow using the standard camera. This lets it identify objects of interest (assuming it gets them right) and sends the image back to the operator along with some identifying information. The kit already had an Arduino onboard and the new robot talks to it via a serial port. You can see a video about the project, below.
We released this on Tuesday and mentioned that the podcast was available on all major podcasting platforms. But turns out you need to wait for approval which we have since received.
This first installment covers some of our favorite trends, articles, and hacks from 2018. Get caught up on what you missed this year, and head over to the show notes for links to everything Mike and Elliot covered in the 67 minute walk down memory lane. We’ll be doing this more regularly in 2019 so pick your podcast aggregator and subscribe to Hackaday to keep up with new episodes.
The build uses a Raspberry Pi, fitted with the Pi Camera board, to image the area around the back door of the house. A Python script regularly captures images and passes them to a TensorFlow neural network for object recognition. The TensorFlow network returns object type and positions to the Python script. This information can be used to determine if there is a cat in the frame, and if it is inside or outside. If the cat remains in position for ten consecutive frames, a text message is sent via Twilio, indicating to the owner to let the cat in or out, as the case may be.
Thirty years ago, object classification was a pie-in-the-sky technology, but now you can run it on a $30 computer to figure out where your pets are. What a time we live in! A similar solution to this problem may be a cat door that unlocks via facial recognition. Video after the break.
The Computer History Museum in Mountain View has two operational IBM 1401 mainframes, which use IBM 1403 high-speed printers. They aren’t some decades-old notion of “high speed” that barely looks sluggish today, either. These monsters slam out ten lines per second thanks to a rotating chain of type slugs and an array of electromagnetic hammers. Every 11.1 microseconds, a character in the chain would be lined up with a hammer, and if the control circuitry identified it as a character that needed to be printed, the hammer behind the paper would drive the paper into the print ribbon and the slug, putting an imprint of the character onto the paper. When one of these printers failed with a sync error, it kicked off some serious troubleshooting to diagnose the problem.
The IBM 1403’s type chain has a repeating set of characters that spins around at high speed. Unlike a typewriter or label maker, the hammers are not inside this unit. The hammers are on the outside, and work by pressing the paper onto the type slugs as the required characters line up.
Investigation of the problem ultimately led to an intermittent connection in a driver card due to a broken PCB trace, but by then some fuses had been blown as well. In the end the printer was brought back online, but possibly with a slightly damaged coil on one of the hammers.
[Ken]’s writeup on the repair process is highly detailed and walks through the kind of troubleshooting and repairs involved when solving problems with vintage electronics. Electrical fundamentals might be the same, but a deep understanding of not only the architecture but also the failure modes of vintage hardware is needed in order to troubleshoot effectively.
If IBM 1401 mainframes and fixing 1403 printers sounds familiar, it’s because a printer fix has been done before. That was due to a different problem, but still a challenging task to narrow down and fix.
We’ve all been there. When debugging a microcontroller project, we just want to put in a print statement to figure out what’s going on with the microcontroller in real time. However, advanced embedded programmers know that printf statements are verboten: they’re just too SLOW. While not fixing this plight entirely, [Atakan Sarioglu] has come up with a clever way to create readable debug messages with minimal runtime overhead.
[Atakan Sarioglu]’s innovation, called BigBug (Github), is a dynamically-generated codebook. The codebook translates abbreviated messages sent over serial (UART here) to longer-form human-readable messages. To generate the codebook, BigBug automatically parses your comments to create a lookup between an abbreviation and the long-form message. When you are running your program on the microcontroller, BigBug will translate the short codes to long messages in real-time as you send log/debug data over serial. Continue reading ““DB” = Abbreviated Microcontroller Debugging”→
If you think that this scratch instrument looks as though it should be at least… three times larger in order to be useful, you’d be wrong. This mighty pocket-sized instrument can really get the club hopping despite its diminuitive size. Despite that, the quality of the build as well as its use of off-the-shelf components for almost every part means that if you need a small, portable turntable there’s finally one you can build on your own.
[rasteri] built the SC1000 digital scratch instrument as a member of the portabilist scene, focusing on downsizing the equipment needed for a proper DJ setup. This instrument uses as Olimex A13-SOM-256 system-on-module, an ARM microprocessor, and can use a USB stick in order to load beats to the system. The scratch wheel itself uses a magnetic rotary encoder to sense position, and the slider is miniaturized as well.
If you want to learn to scratch good and learn to do other things good too, there’s a demo below showing a demonstration of the instrument, as well as a how-to video on the project page. All of the build files and software are open-source, so it won’t be too difficult to get one for yourself as long as you have some experience printing PCBs. If you need the rest of the equipment for a DJ booth, of course that’s also something you can build.
[John Whittington] failed to win a bid for an old VT-220 serial terminal on eBay, so he decided to make his own version and improve it along the way. The result is the Whitterm-220 (or WT-220) which has at its core a Raspberry Pi and is therefore capable of more than just acting as a ‘dumb’ serial terminal.
Rear of the WT-220 with paint-filled laser engraving and all necessary connectors.
The enclosure is made from stacked panels of laser-cut plywood with an acrylic plate on the back for labels and connectors, where [John] worked paint into the label engravings before peeling off the acrylic’s protective film. By applying paint after laser-engraving but before peeling off the film, it acts as a fill and really makes the text pop.
Near the front, one layer of clear acrylic among the plywood layers acts as a light guide and serves as a power indicator, also doing double duty as TX/RX activity lights. When power is on, that layer glows, serving as an attractive indicator that doesn’t interfere with looking at the screen. When data is sent or received, a simple buffer circuit tied to the serial lines lights up LEDs to show TX or RX activity, with the ability to enable or disable this functionality by toggling a GPIO pin. A video overview is embedded below, where you can see the unit in action.
