Be Still, My Animatronic Heart

Fair warning for the squeamish: some versions of [Will Cogley]’s animatronic heart are realistic enough that you might not want to watch the video below. That’d be a shame though, because he really put a lot of effort into the build, and the results have a lot to teach about mimicking the movements of living things.

As for why one would need an animatronic heart, we’re not sure. [Will] mentions no specific use case for it, although we can think of a few. With the Day of Compulsory Romance fast approaching, the fabric-wrapped version would make a great gift for the one who stole your heart, while the silicone-enrobed one could be used as a movie prop or an awesome prank. Whatever the reason, [Will]’s build is a case study in incremental development. He started with a design using a single continuous-rotation servo, which powered four 3D-printed paddles from a common crank. The four paddles somewhat mimicked the movements of the four chambers of the heart, but the effect wasn’t quite convincing. The next design used two servos and complex parallelogram linkages to expand each side of the heart in turn. It was closer, but still not quite right.

After carefully watching footage of a beating heart, [Will] decided that his mechanism needed to imitate the rapid systolic contraction and slow diastolic expansion characteristic of a real heart. To achieve this, his final design has three servos plus an Arduino for motion control. Slipped into a detailed silicone jacket, the look is very realistic. Check out the video below if you dare.

We’ve seen plenty of animatronic body parts before, from eyes to hands to entire faces. This might be the first time we’ve seen an animatronic version of an internal organ, though.

Continue reading “Be Still, My Animatronic Heart”

Binary Advent Calendar Does More With Fewer Doors

[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.

Continue reading “Binary Advent Calendar Does More With Fewer Doors”

Experiments In Soft Robotics

[Arnav Wagh] has been doing some cool experiments in soft robotics using his home 3D printer.

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.

Continue reading “Experiments In Soft Robotics”

Play That Funky 3D Printer…

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.

Continue reading “Play That Funky 3D Printer…”

Modular Solar-Powered IoT Sensors

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.

When a large community develops around a modular ecosystem, it can truly grow beyond the originator’s wildest dreams. Just look at Arduino and Raspberry Pi. We’re also currently running a contest involving boards for the Feather form factor if you want to get in on the act. Continue reading “Modular Solar-Powered IoT Sensors”

Another IoT Debacle: Charter Offers Home Insecurity

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.

Continue reading “Another IoT Debacle: Charter Offers Home Insecurity”

Building A Better BitTorrent Client In Go

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
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.
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.