You must remember my cute robotic dancing teapot. It works great, but it has a little drawback: you need to open it to physically connect and disconnect the battery. Therefore, let’s fix that issue by integrating a switch directly in the teapot lid!
I designed three new plastic parts for the second version of the lid. The new lid features a hole instead of the handle, and the actual handle is to be glued to an axis going through the lid, with an elliptic lever at the bottom. The lever shall push a micro switch attached on the inside of the lid, just like you would press a button.
You can download the new SCAD source files (licensed under GPLv3) and the corresponding STL files on my GitHub repository. Apart from a micro switch, I’ll also use prototype board, pins, and a Dupont wire.
Provided you connect a piezo speaker to your Arduino board, the tone Arduino function allows to play tones given their frequencies. Let’s use it to play entire melodies!
The melody encoding format I’ll use is compact and pretty straightforward, but I admit it isn’t the easiest one to read. The melody is represented as a null-terminated string of chars, in which each note is described by 3 consecutive characters:
The note duration in sixteenth notes as an hexadecimal digit between 0 and F (0 has a special meaning and is interpreted as a whole note)
The note name in English notation as an uppercase letter, or lowercase if sharp (R has a special meaning and indicates a rest)
The octave number as a decimal digit, between 0 and 8 (for a rest, the value is ignored)
So for instance, a quarter-note C from the 5th octave is 4C5, and a eighth-note D sharp from the 4th octave is 2d4.
With this notation, the Tetris theme is: 4E52B42C54D52C52B44A42A42C54E52D52C56B42C54D54E54C54A42A42A42B42C56D52F54A52G52F56E52C54E52D52C54B42B42C54D54E54C54A44A44R0
In this example, a piezo passive sounder is connected on pin 3 of the Arduino board. The code to play a melody stored in the format defined previously can be written as follows:
The Bob robot, itself remixed from the Arduped robot, inspired an impressive number of clones with its really good design.
The most famous ones might be Zowi, and more recently Otto. They are both simple, cheap, open-source and 3D-printed little robots which have refined Bob two-legged design.
Yet, I am not a fan of their strange square heads. What I would like is a teapot. A dancing teapot.
I chose to design 3D-printed parts from scratch, not only because I prefer to use OpenSCAD over FreeCAD, but also because the design of the top part will be entierly different anyway. Also, for once, it will be powered by a 9-volt alkaline battery rather than a lipo battery.
You can download the SCAD source files (licensed under GPLv3) and the corresponding STL files here or on my GitHub repository. I printed them with white PLA, not the fanciest color but the perfect one for a teapot.
In this article, I’m going to describe architecture enhancements for the control system of the WebRTC-controlled telepresence robot I built a few months ago, presented in a previous article.
Since I did not manage to have a satisfying WebRTC support directly in a native Android app, I previously settled for a hack where the smartphone of the Telebot uses two different connections to the signaling channel: one to receive user control in the Android app, and one to handle the WebRTC session in the browser.
This was bad for two reasons:
The robot can enter an incoherent state if one connection is closed and not the other.
User control commands do not benefit from WebRTC, instead they travel through the server, adding latency and jitter.
The Google Chromecast is an impressive little device. If you haven’t encountered one already, it’s a small HDMI dongle which, when connected to a TV screen, allows to play audio, video, or visual content of a compatible webapp from a computer or mobile device.
However, it is primarily designed to only stream content from the Web, and not from your computer itself, which follows the current trend that everything should be “in the cloud” and is infuriatingly limiting. As you can guess, that dubious ideology is not my cup of tea.
Luckily, the excellent library PyChromecast allows to control the device from a Python program. Yet the issue is that it only works for codecs the Chromecast is able to decode natively, i.e., H.264 and VP8. Besides, the Chromecast is only able to handle a few containers like MP4 and WebM. What if you want to stream other video formats ? Besides, what if you want to stream dynamically-generated content, for instance your screen or a live video from a camera ?
Building a specific Android application to handle a WebRTC session on the smartphone and relay commands to the controller via Bluetooth
Setting up a node.js server to serve an HTML5 control page over HTTPS allowing visioconference and remote control
The robot will be built as a base with 4 wheels, on top of which a vertical pole allows to stick a smartphone. The smartphone, connected to the base via Bluetooth, will permit visioconference via WebRTC and remote control at the same time, allowing to move around. Even if the center of gravity is quite high, a gyroscope will prevent the robot from falling over. The base will be powered by lithium-polymer batteries and rechargeable via a USB connector.
This article covers building the robot, while the next article focuses on programming it.
You are without doubt already familiar with the Tor project. The Tor browser is already a very handy tool to surf anonymously, but what if we had an entire network’s traffic forwarded through Tor via a special gateway? Let’s transform a tiny router in a transparent Tor proxy, a portable wifi access point redirecting all traffic to the Tor network!
Let’s begin with a short presentation of one of my favorite hackable network devices: the TL-MR3020.
Network-Attached Storages (NAS) are very handy devices on a home network. They offer a simple way to share or synchronize files, and can host various useful services at the same time provided they are generic enough. A NAS being nothing more than a specialized file server, we will actually build a small home server than will be able to do anything.
The functions can be the following:
File server (FTP, NFS, SMB/CIFS…)
Streaming server (audio or video on the local network)
Personal web server (to host a website, synchonize contacts or send files to people)
Local seedbox (to download torrent files)
Domotic hub (for instance by adding a Zigbee USB dongle)
The server will be pretty simple in its technical design: a Raspberry Pi 2 model B with two hard disks connected with USB adapters.
The Raspberry Pi is actually not able to power the two drives over USB, since we would need 500mA per drive, so 1000mA overall, and the Pi can only supply 600mA over USB. There is a possible boot setting in /boot/config.txt called max_usb_current, which when set to 1 raises the maximum current intensity over USB to 1.2A, but since it is applied only during boot, our disks will still prevent the Pi to actually start properly. For this reason, we need a USB hub with a 2A adapter to power everything and connect the drives to the Pi. Backfeeding would be quite a bad idea, so the Pi needs to be connected to the hub twice, once as a device for power and once as the host.
In this kind of setup, always pay attention to use a genuine power adapter that will be able to handle the load, some really cheap adapters are rated 2A but might not be able to supply this current over a long period of time due to overheating.
I designed the case, front panel and lid with OpenSCAD to print them in 3D. You can download the SCAD source files and the corresponding STL files here (licensed under GPLv3).