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.
For simply getting your project connected to WiFi, a least among hacker circles, nothing beats the ESP8266. But it’s not the only player out there, and we love to see diversity in the parts and languages that we use. One of the big shortcomings of the ESP8266 is the slightly-oddball Xtensa CPU. It’s just not as widely supported by various toolchains as its ARM-based brethren.
And so, when [Zach] wanted to do some embedded work in Rust, the ESP8266 was out of the picture. He turned to the RTL8710, a very similar WiFi module made by Realtek. Documentation for the RTL8710 is, at the moment, crappy, much as the ESP8266 documentation was before the hacker community had at it. But in trade for this shortcoming, [Zach] got to use the LLVM compiler, which supports the ARM architecture, and that means he can code in Rust.
In the end, the setup that [Zach] describes is a mix of FreeRTOS and some of the mbed libraries, which should be more than enough to get you up and running fairly painlessly on the chip. We’ve actually ordered a couple of these modules ourselves, and were looking to get started in straight C, but having Rust examples working doesn’t hurt, and doesn’t look all that different.
Is anyone else using the RTL8710? An ARM-based, cheap WiFi chip should be interesting.
Every December and May the senior design projects from engineering schools start to roll in. Since the students aren’t yet encumbered with real-world detractors (like management) the projects are often exceptional, unique, and solve problems we never even thought we had. Such is the case with [Mark] and [Peter]’s senior design project: a pick and place machine that promises to solve all of life’s problems.
Of course we’ve seen pick-and-place machines before, but this one is different. Rather than identifying resistors and capacitors to set on a PCB, this machine is able to identify and sort candies. The robot — a version of the MeARM — has three degrees of freedom and a computer vision system to alert the arm as to what it’s picking up and where it should place it. A Raspberry Pi handles the computer vision and feeds data to a PIC32 which interfaces with the hardware.
One of the requirements for the senior design class was to keep the budget under $100, which they were able to accomplish using pre-built solutions wherever possible. Robot arms with dependable precision can’t even come close to that price restraint. But this project overcomes the lack of precision in the MeArm by using incremental correcting steps to reach proper alignment. This is covered in the video demo below.
Senior design classes are a great way to teach students how to integrate all of their knowledge into a final class, and the professors often include limits they might find in the real world (like the budget limit in this project). The requirement to thoroughly document the build process is also a lesson that more people could stand to learn. Senior design classes have attempted to solve a lot of life’s other problems, too; from autonomous vehicles to bartenders, there’s been a solution for almost every problem.