A robot assistant would make the lives of many much easier. Luckily, it’s possible to make one of your own with few fancy materials. The [circuito.io] team demonstrates this by building a robot arm out of recyclables!
With the exception of the electronics — an Arduino, a trio of servo motors, and a joystick — the arm is made almost completely out of salvaged recyclables: scrap wood, a plastic bottle, bits of plastic string and a spring. Oh, and — demonstrating yet another use for those multi-talented tubers — a potato acts as a counterweight.
Instead of using screws or glue, these hackers used string made from a plastic bottle as a form of heat shrink wrap to bind the parts of the arm together. The gripper has only one pivoting claw for greater strength, and the spring snaps it open once released. Behold: your tea-bag dunking assistant.
I have a bit of a love/hate relationship with the Arduino. But if I had two serious gripes about the original offering it was the 8-bit CPU and the lack of proper debugging support. Now there’s plenty of 32-bit support in the Arduino IDE, so that takes care of the first big issue. Taking care of having a real debugger, though, is a bit trickier. I recently set out to use one of the cheap “blue pill” STM32 ARM boards. These are available for just a few bucks from the usual Chinese sources. I picked mine up for about $6 because I wanted it in a week instead of a month. That’s still pretty inexpensive. The chip has a lot of great debugging features. Can we unlock them? You can, if you have the right approach.
For a few bucks, you can’t complain about the hardware. The STM32F103C8T6 onboard is a Cortex-M3 processor that runs at 72 MHz. There’s 64K of flash and 20K of RAM. There’s a minimicro-USB that can act as a programming port (but not at first). There’s also many 5 V-tolerant pins, even though this a 3.3 V part.
You can find a lot more information on this wiki. The board is a clone–more or less–of a Maple Mini. In fact, that’s one way you can use these. You can use the serial or ST-Link port to program the Maple bootloader (all open source) and use it like a Maple. That is, you can program it via the USB cable.
From my point of view, though, I don’t want to try to debugging over the serial port and if I have the ST-Link port already set up, I don’t care about a bootloader. You can get hardware that acts as a USB to ST-Link device inexpensively, but I happen to have an STM32VLDISCOVER board hanging around. Most of the STM32 demo boards have an ST-Link programmer onboard that is made to use without the original target hardware. On some of the older boards, you had to cut traces, but most of the new ones just have two jumpers you remove when you want to use the programmer to drive another device.
The “blue pill” designation is just a common nickname referring to the Matrix, not the pharmaceuticals you see on TV ads. The board has four pins at one edge to accommodate the ST-Link interface. The pin ordering didn’t match up with the four pins on the STM32VLDISCOVER, so you can’t just use a straight four-pin cable. You also need to bring power over to the board since it will have to power the programmer, too. I took the power from the STM32VLDISCOVER board (which is getting its power from USB) and jumpered it to my breadboard since that was handy.
With interest and accessibility to both wearable tech and virtual reality approaching an all-time high, three students from Cornell University — [Daryl Sew, Emma Wang, and Zachary Zimmerman] — seek to turn your body into the perfect controller.
That is the end goal, at least. Their prototype consists of three Kionix tri-axis accelerometer, gyroscope and magnetometer sensors (at the hand, elbow, and shoulder) to trace the arm’s movement. Relying on a PC to do most of the computational heavy lifting, a PIC32 in a t-shirt canister — hey, it’s a prototype! — receives data from the three joint positions, transmitting them to said PC via serial, which renders a useable 3D model in a virtual environment. After a brief calibration, the setup tracks the arm movement with only a little drift in readings over a few minutes.
Let’s start right off with a controversial claim: Forth is the hacker’s programming language. Coding in Forth is a little bit like writing assembly language, interactively, for a strange CPU architecture that doesn’t exist. Forth is a virtual machine, an interpreted command-line, and a compiler all in one. And all of this is simple enough that it’s easily capable of running in a few kilobytes of memory. When your Forth code is right, it reads just like a natural-language sentence but getting there involves a bit of puzzle solving.
Forth is what you’d get if Python slept with Assembly Language: interactive, expressive, and without syntactical baggage, but still very close to the metal. Is it a high-level language or a low-level language? Yes! Or rather, it’s the shortest path from one to the other. You can, and must, peek and poke directly into memory in Forth, but you can also build up a body of higher-level code fast enough that you won’t mind. In my opinion, this combination of live coding and proximity to the hardware makes Forth great for exploring new microcontrollers or working them into your projects. It’s a fun language to write a hardware abstraction layer in. Continue reading “Forth: The Hacker’s Language”→
Building a software defined radio (SDR) involves many trades offs. But one of the most fundamental is should you use an FPGA or a CPU to do the processing. Of course, if you are piping data to a PC, the answer is probably a CPU. But if you are doing the whole system, it is a vexing choice. The FPGA can handle lots of data all at one time but is somewhat more difficult to develop and modify. CPUs using software are flexible–especially for coding user interfaces, networking connections, and the like) but don’t always have enough horsepower to cope with signal processing tasks (and, yes, it depends on the CPU).
[Eric Brombaugh] sidestepped that trade off. He used a board with both an ARM processor and an ICE FPGA at the heart of his SDR design. He uses three custom boards: one is the CPU/FPGA board, another is a 10-bit converter that can sample at 40 MSPS (sufficient to decode to 20 MHz), and an I2S DAC to produce audio. Each board has its own page linked from the main project.
Rotary encoders are great devices. Monitoring just a few pins you can easily and quickly read in rotation and direction of a user input (as well as many other applications). But as with anything, there are caveats. I recently had the chance to dive into some of the benefits and drawbacks of rotary encoders and how to work with them.
I often work with students on different levels of electronic projects. One student project needed a rotary encoder. These come in mechanical and optical variants. In a way, they are very simple devices. In another way, they have some complex nuances. The target board was an ST Nucleo. This particular board has a small ARM processor and can use mbed environment for development and programming. The board itself can take Arduino daughter boards and have additional pins for ST morpho boards (whatever those are).
The mbed system is the ARM’s answer to Arduino. A web-based IDE lets you write C++ code with tons of support libraries. The board looks like a USB drive, so you download the program to this ersatz drive, and the board is programmed. I posted an intro to mbed awhile back with a similar board, so if you want a refresher on that, you might like to read that first.
Reading the Encoder
The encoder we had was on a little PCB that you get when you buy one of those Chinese Arduino 37 sensor kits. (By the way, if you are looking for documentation on those kinds of boards, look here.; in particular, this was a KY-040 module.) The board has power and ground pins, along with three pins. One of the pins is a switch closure to ground when you depress the shaft of the encoder. The other two encode the direction and speed of the shaft rotation. There are three pull-up resistors, one for each output.
I expected to explain how the device worked, and then assist in writing some code with a good example of having to debounce, use pin change interrupts, and obviously throw in some other arcane lore. Turns out that was wholly unnecessary. Well… sort of.
Around here we love technology for its own sake. But we have to admit, most people are interested in applications–what can the technology do? Those people often have the best projects. After all, there’s only so many blinking LED projects you can look at before you want something more.
[Landingfield] is interested in astrophotography. He was dismayed at the cost of commercial camera sensors suitable for work like this, so he decided he would create his own. Although he started thinking about it a few years ago, he started earnestly in early 2016.
The project uses a Nikon sensor and a Xilinx Zynq CPU/FPGA. The idea is the set up and control the CMOS sensor with the CPU side of the Zynq chip, then receive and process the data from the sensor using the FPGA side before dumping it into memory and letting the CPU take over again. The project stalled for a bit due to a bug in the vendor’s tools. The posts describe the problem which might be handy if you are doing something similar. There’s still work to go, but the device has taken images that should appear on the same blog soon.