[John] sent this one in to us a little bit after Christmas, but we’ll give him a pass because it’s so beautiful. Think of it this way: now you have almost a full year to make a binary advent calendar of your own before December 1st rolls around again.
Normal advent calendars are pretty cool, especially when there is chocolate behind all 24 doors. But is it really a representational ramp-up if you never get more than one chocolate each day? [John] doesn’t think so. The economics of his binary advent calendar are a bit magical, much like the holiday season itself. Most days you’ll get two pieces of chocolate instead of one, and many days you’ll get three. That is, as long as you opened the right doors.
A momentary switch hidden behind the hinge of each door tells the Arduino clone when it’s been opened. The Arduino checks your binary counting abilities, and if you’re right, a servo moves a gate forward and dispenses one chocolate ball per opened door. We love the simplicity of the dispensing mechanism — the doors are designed with a ceiling that keeps non-qualifying chocolates in their channels until their flag comes up.
[John] is working out the kinks before he releases this into the wild. For now, you can get a taste in the demo video featuring a bite-sized explanation. If you don’t like chocolate, maybe this blinky advent calendar will light you up inside.
Soft robots have a lot of advantages, but as [Arnav] points out on his website, it’s pretty hard to get started in the same way as one might with another type of project. You can’t necessarily go on Amazon and order a ten pack of soft robot actuators in the way you can Arduinos.
The project started by imitating other projects. First he copied the universities who have done work in this arena by casting soft silicone actuators. He notes the same things that they did, that they’re difficult to produce and prone to punctures. Next he tried painting foam with silicone, which worked, but it was still prone to punctures, and there was a consensus that it was creepy. He finally had a breakthrough playing with origami shapes. After some iteration he was able to print them reliably with an Ultimaker.
Finally to get it into the “easy to hack together on a weekend” range he was looking for: he designed it to be VEX compatible. You can see them moving in the video after the break.
Human brains are wired for music. Scientists think the oldest musical instruments were flutes that date back somewhere between 67,000 and 37,000 years ago. We assume though that people were banging on wood or their thighs, or knocking two rocks together long before that. Almost anything can be a musical instrument. A case in point: [elifer5000] walked into a room containing a lot of running 3D printers, and thought it seemed musical. Next thing you know, he harnessed 3D printers as a MIDI instrument.
At a hackathon, he found some software that converts a MIDI file to GCode. The only problem is a common printer has three axes and, therefore, can only produce (at most) three notes at once. The obvious answer to this problem is to use more printers, and that’s what he did, as you can see below.
Bringing a product to market is not easy, if it were everyone would be doing it, and succeeding. The team at Pycno is in the process of launching their second product, a modular solar powered IoT unit called Pulse. It’s always interesting to get an inside look when a company is so open during the development process, and see how they deal with challenges.
Pycno’s first product was a solar powered sensor suite for crops. This time round they are keeping the solar part, but creating a modular system that can accept wired or wireless connections (2G/3G/4G, WiFi, LoRa, GPS and Bluetooth 5) or modules that slide into the bottom of the unit. They plan to open source the module design to allow other to design custom modules, which is a smart move since interoperability can be a big driving factor behind adoption. The ease of plugging in sensors is a very handy feature, since most non-Hackaday users would probably prefer to not open up expensive units to swap out sensors. The custom solar panel itself is pretty interesting, since it features an integrated OLED display. It consists of a PCB with the cutout for the display, with solar cells soldered on before the whole is laminated to protect the cells.
Making a product so completely modular also has some pitfalls, since it can be really tricky to market something able to do anything for anybody. However, we wish them the best of luck with their Kickstarter (video after the break) and look forward to seeing how the ecosystem develops.
If you are a glass-half-empty person, you’ll view Charter’s announcement that they will shutter their home security and smart home service on February 5th as another reason not to buy into closed-source IoT devices. If you are a glass-half-full person though, you’ll see the cable company’s announcement as a sign that a lot of Zigbee hardware will soon flood the surplus market. Ars Technica reports that after investigation it appears that some of the devices may connect to a standard Zigbee hub after a factory reset, but many others will definitely not.
As you might expect, users were less than thrilled. Especially those that shelled out thousands of dollars on sensors and cameras. This sort of thing might be expected if a company goes out of business, but Charter just doesn’t want to be in the home security business anymore.
When it comes to peer-to-peer file sharing protocols, BitTorrent is probably one of the best known. It requires a client implementing the program and a tracker to list files available to transfer and to find peer users to transfer those files. Developed in 2001, BitTorrent has since acquired more than a quarter billion users according to some estimates.
While most users choose to use existing clients, [Jesse Li] wanted to build one from scratch in Go, a programming language commonly used for its built-in concurrency features and simplicity compared to C.
Client-server versus peer-to-peer architecture
The first step for a client is finding peers to download files from. Trackers, web servers running over HTTP, serve as centralized locations for introducing peers to one another. Due to the centralization, the servers are at risk of being discovered and shut down if they facilitate illegal content exchange. Thus, making peer discovery a distributed process is a necessity for preventing trackers from following in the footsteps of the now-defunct TorrentSpy, Popcorn Time, and KickassTorrents.
The client starts off by reading a .torrent file, which describes the contents of the desired file and how to connect to a tracker. The information in the file includes the URL of the tracker, the creation time, and SHA-1 hashes of each piece, or a chunk of the file. One file can be made up of thousands of pieces – the client will need to download the pieces from peers, check the hashes against the torrent file, and finally assemble the pieces together to finally retrieve the file. For the implementation, [Jesse] chose to keep the structures in the Go program reasonably flat, separating application structs from serialization structs. Pieces are also separated into slices of hashes to more easily access individual hashes.
The bitfield explained as a coffee shop loyalty card.
Next, a GET request to an `announce` URL in the torrent file announces the presence of the client to peers and retrieves a response from the tracker with the list of peers. To start downloading pieces, the client starts a TCP connection with a peer, completes a two-way BitTorrent handshake, and exchanges messages to download pieces.
One interesting data structure exchanged in the messages is a bitfield, which acts as a byte array that checks which pieces a peer has. Bits are flipped when their respective piece’s status changes, acting somewhat like a loyalty card with stamps.
While talking to one peer may be straightforward, managing the concurrency of talking to multiple peers at once requires solving a classically Hard problem. [Jesse] implements this in Go by using channels as thread-safe queues, setting up two channels to assign work and collect downloaded pieces. Requests are later pipelined to increase throughput since network round-trips are expensive and sending blocks individually inefficient.
The full implementation is available on GitHub, and is easy enough to use as an alternative client or as a walkthrough if you’d prefer to build your own.
When you start sharing your projects with the world, you never know who might take notice. [Sterling Backus] and his son [Xander] have been building a functional Lamborghini Aventador look alike in their garage, and the real Lamborghini company caught wind of it and decided to turn it into an awesome Christmas ad.
Named the AXAS Interceptor by its creators, the car is built from scratch around a custom tubular space frame chassis. Most of the body panels are 3D printed and then skinned with carbon fibre, with a few sheet metal panels mixed in. The interior is mix of parts from other cars and aftermarket components, with 3D printing to pull everything together. The drivetrain consists of an engine from a Corvette, a transaxle from a Porsche 996, with the rest of the chassis components being either aftermarket or custom-fabricated pieces.
[Sterling] got an unexpectedcall from Lamborghini, and they arranged to secretly sneak a real Aventador into the garage in the dead of night to surprise the rest of the family, and let them borrow it for a few weeks. Lamborghini got some marketing out of it, which most people would probably agree is a pretty good deal. We would admit that we’re quite envious.
The car is driveable, but still many hours from being complete. [Sterling] admits that he is no car building professional, but we’re impressed by what he has been able to achieve so far with this ambitious project, and we’re looking forward to the finished product.
If you want to get your feet wet with your first project car, here’s how you pick one.
