One of my favorite ways to think of engineering is that a glass is not half empty or half full, only twice as large as it needs to be. As useful as that idea is, it also means that I rarely put any effort into the aesthetics of my projects – I learn or accomplish what I need, desolder and recycle the components, then move on. Few of my projects are permanent, and custom cases tend to be non-reusable, so I skip the effort and expense.
Once in a while though, I need to make a gift. In that case form and function both become priorities. Thankfully, all that glitters is not gold – and over the last year I’ve been learning to etch the copper alloys commonly classified as ‘brass’. We’ve covered some truly excellentetched brass pieces previously, and I was inspired to try and etch larger pieces of metal (A4 and larger) without sacrificing resolution. I thought this would be just like etching circuits. In fact, I went through several months of failed attempts before I produced anything halfway decent!
Although I’m still working on perfecting my techniques, I’ve learned enough in the meantime to give a report. Read on if you’re feeling the need for more fancy brass signs in your life.
Okay, we’ve just left May and stepped into June, why are we talking about Arduino Day — traditionally a March 16th event where makers congregate and share projects? I live in Ho Chi Minh City, and the event tends to take place in mid-May, but the enthusiasm and collaborative spirit are just as strong. Organized by the awesome local maker group Fablab Saigon with the venue provided by Intek Institute, there were some neat projects on display along with some talks from local companies.
The first thing that struck me about the event was how young the maker movement is here – most attendees were still in high school or early university. By contrast, I was 23 when I first learned to use AVR microcontrollers with assembly language (by the time Arduino started to get traction the boat effectively missed me). I couldn’t help but feel like a bit of a relic, at least until we all started talking excitedly about robots (I had brought a couple). It seems that geeking out about electronics is the great equalizer which knows no age limits.
I couldn’t decide between normal and decaffeinated coffee. So to eliminate delays in my morning routine, and decision fatigue, I’ve designed the Schrödinger Quantum Percolator — making the state of my coffee formally undecidable until I drink it.
At its core, the Quantum Percolator contains a novel quantum event detector that uses electron tunneling to determine whether to use caffeinated or decaffeinated coffee. The mechanical components are enclosed in an opaque box, so I can’t tell which type of coffee is being used.
The result is coffee that simultaneously contains and does not contain caffeine – at least until you collapse the caffeination probability waveform by drinking it. As the expression goes, you can’t have your quantum superposition of states and drink it too!
Last year, we saw quite a bit of media attention paid to blockchain startups. They raised money from the public, then most of them vanished without a trace (or product). Ethics and legality of their fundraising model aside, a few of the ideas they presented might be worth revisiting one day.
One idea in particular that I’ve struggled with is the synthesis of IoT and blockchain technology. Usually when presented with a product or technology, I can comprehend how and/or why someone would use it – in this case I understand neither, and it’s been nagging at me from some quiet but irrepressible corner of my mind.
The typical IoT networks I’ve seen collect data using cheap and low-power devices, and transmit it to a central service without more effort spent on security than needed (and sometimes much less). On the other hand, blockchains tend to be an expensive way to store data, require a fair amount of local storage and processing power to fully interact with them, and generally involve the careful use of public-private key encryption.
It’s no secret that I rather enjoy connecting things to the Internet for fun and profit. One of the tricks I’ve learned along the way is to spin up simple APIs that can be used when prototyping a project. It’s easy to do, and simple to understand so I’m happy to share what has worked for me, using Web2Py as the example (with guest appearances from ESP8266 and NodeMCU).
Barring the times I’m just being silly, there are two reasons I might do this. Most commonly I’ll need to collect data from a device, typically to be stored for later analysis but occasionally to trigger some action on a server in the cloud. Less commonly, I’ll need a device to change its behavior based on instructions received via the Internet.
In the former case, my first option has always been to use IoT frameworks like Thingsboard or Ubidots to receive and display data. They have the advantage of being easy to use, and have rich features. They can even react to data and send instruction back to devices. In the latter case, I usually find myself using an application programming interface (API) – some service open on the Internet that my device can easily request data from, for example the weather, blockchain transactions, or new email notifications.
Occasionally, I end up with a type of data that requires processing or is not well structured for storage on these services, or else I need a device to request data that is private or that no one is presently offering. Most commonly, I need to change some parameter in a few connected devices without the trouble of finding them, opening all the cases, and reprogramming them all.
At these times it’s useful to be able to build simple, short-lived services that fill in these gaps during prototyping. Far from being a secure or consumer-ready product, we just need something we can try out to see if an idea is worth developing further. There are many valid ways to do this, but my first choice is Web2Py, a relatively easy to use open-source framework for developing web applications in Python. It supports both Python 2.7 and 3.0, although we’ll be using Python 3 today.
I’ve always been fascinated by AI and machine learning. Google TensorFlow offers tutorials and has been on my ‘to-learn’ list since it was first released, although I always seem to neglect it in favor of the shiniest new embedded platform.
Last July, I took note when Intel released the Neural Compute Stick. It looked like an oversized USB stick, and acted as an accelerator for local AI applications, especially machine vision. I thought it was a pretty neat idea: it allowed me to test out AI applications on embedded systems at a power cost of about 1W. It requires pre-trained models, but there are enough of them available now to do some interesting things.
I wasn’t convinced I would get great performance out of it, and forgot about it until last November when they released an improved version. Unambiguously named the ‘Neural Compute Stick 2’ (NCS2), it was reasonably priced and promised a 6-8x performance increase over the last model, so I decided to give it a try to see how well it worked.
I took a few days off work around Christmas to set up Intel’s OpenVino Toolkit on my laptop. The installation script provided by Intel wasn’t particularly user-friendly, but it worked well enough and included several example applications I could use to test performance. I found that face detection was possible with my webcam in near real-time (something like 19 FPS), and pose detection at about 3 FPS. So in accordance with the holiday spirit, it knows when I am sleeping, and knows when I’m awake.
That was promising, but the NCS2 was marketed as allowing AI processing on edge computing devices. I set about installing it on the Raspberry Pi 3 Model B+ and compiling the application samples to see if it worked better than previous methods. This turned out to be more difficult than I expected, and the main goal of this article is to share the process I followed and save some of you a little frustration.
When I began programming microcontrollers in 2003, I had picked up the Atmel STK-500 and learned assembler for their ATtiny and ATmega lines. At the time I thought it was great – the emulator and development boards were good, and I could add a microcontroller permanently to a project for a dollar. Then the ESP8266 came out.
I was pretty blown away by its features, switched platforms, except for timing-sensitive applications, and it’s been my chip of choice for a few years. A short while ago, a friend gave me an ESP32, the much faster, dual core version of the ESP8266. As I rarely used much of the computing power on the ESP8266, none of the features looked like game changers, and it remained a ‘desk ornament’ for a while.
About seven weeks ago, support for the libSodium Elliptic Curve Cryptography library was added. Cryptography is not the strongest feature of IoT devices, and some of the methods I’ve used on the ESP8266 were less than ideal. Being able to more easily perform public-private key encryption would be enough for me to consider switching hardware for some projects.