This is a follow-up to a previous post describing Magpi Radio. Read that first if you’re curious about the project. In this post I’ll describe the technical details of Magpi Radio (with a link to the code) and show some process.
Hardware
As you can see in the system diagram the brains of Magpi Radio is a Raspberry Pi computer. These are small, cheap linux computers that pack a lot of horse power, making them perfect for internet-of-thingsy projects like this. Here are some of the benefits of the Pi when picking your hardware:
• Speed: The Pi runs at 700 mhz with 512 MB of RAM. I never experienced any latency when making this project.
• Audio: Playing audio files is a breeze through the audio jack and supports pretty much any format you throw at it.
• Programming: You’re not limited to a specific library or language. I wrote the Magpi software in Ruby to leverage the excellent Twitter gems (twitter and tweetstream).
You’ll also notice an Arduino in the diagram, which handled the physical interface (the knobs and light). The reason I used the Arduino in addition to the Pi is because the Pi doesn’t have great support for analog io. I was able to read the volume potentiometer with an ADC chip through the GPIO pins, but because there’s only 1 PWM pin I wasn’t able to control the RBG LED. (If you’re interested in using the Pi’s GPIO pins for sensor io, I’d recommend the WiringPi lib).
So the Arduino was connected to the Raspberry Pi with a USB cable to provide serial communication and power. This ended up being quite a challenge, but I eventually stumbled onto this post that solves the problem of communicating with the Arduino over USB.
A simpler version of this project could be run without the Arduino and I’d be interested to hear if anyone tries it.
Software
There are 3 main software components for Magpi Radio:
• Arduino Program: This code reads the knobs and controls the LED RGB. It’s also responsible for the serial communication with the Raspberry Pi.
• Ruby Script: This is the main program running on the Raspberry Pi. It’s 3 primary responsibilities are taking serial data from the Arduino, communicating with Twitter and Audio playback. Since all of these tasks are fairly needy, they’re run on different threads so they don’t block each other.
• Say Server: This is an optional Ruby script run as a cgi-executable on my OS X web server. It converts a string of text into an audio file that the radio then plays. This can be handled a few different ways, but I added this layer because the OS X text-to-speech program (“say”) was the highest quality solution I could find and it also gave me control over the voice. If you don’t want to run this program, it defaults to using tts-api.com (which is also using the OS X “say” program but doesn’t give you voice control), and falls back on eSpeak if the tts server isn’t available.
I’ve made all of the software for Magpi Radio available on github. Instructions for running it can be found in the README.
Process
Here are some photos of the construction of Magpi Radio.
The guts, splayed out on my desktop.
The bowl, pre-lobotomy.
The bowl, post-surgery. The speaker holes were created with a drill-press and the eye-sockets and beak were done with a Dremel.
Getting aquatinted.
Mounting the knobs took a bit of head scratching, but Tom suggested using Sugru, which ended up being the perfect solution.
This is pretty much what it looks like on the inside. I wrapped the Pi in a static-free bag because I was getting some short circuits when the components bumped into each other. You can see the top of the Sugru (white and black blobs) behind the wires.
Finished product. It all fit inside!
The Internet of things.
After a semester at ITP, I’ve found that one of the most popular themes is synesthesia. Students like to use technology to translate colors into sound, words into images, light into motion, etc.. All of the projects I’ve worked on in Physical Computing do this on one level or another—the very act of converting data into electricity is a sort of synesthesia.
For my final project, I’ve reformatted Twitter as a radio. It’s called Magpi Radio:
Objectives
I had two objectives for my final project. First, I wanted to create a physical manifestation of a piece of software. I’ve been interested in this idea since the original iPod was released—it was the first time I considered an electronic device as a meatspace expression of software. iTunes and iPod were two interfaces to the same content. I chose Twitter as the software because there’s an endless amount of content and it’s a robust platform that makes two-way communication very easy.
Second, I wanted to think of this project through the lens of product design. How could I piggyback on the user’s understanding of existing interfaces to make it’s function obvious? I chose the radio metaphor for this reason. One knob is power/volume, and the other knob is the channel. More complex use-cases (like content organization and settings) can be handled through Twitter, which allows the behavior to be extensible.
Behavior
A quick overview of what it does; Magpi Radio uses text-to-speech to read tweets coming in from various channels. Volume and power are controlled by the knob on the left. Channels can be selected by turning the knob on the right. As you click through channels, the beak changes color so you have a “glanceable” indication of it’s state. Pressing the knob on the right will favorite the last tweet, indicated by a red pulsing beak.
There are two kinds of channels; lists and streams. Lists use the REST API to read tweets from lists that have been created on the @magpiradio account. For example, “News,” “Humor,” and “Weird.” Streams read tweets in real-time that are filtered by criteria. The “Nearby” channel reads tweets that have been geo-tagged in your immediate vicinity, like a social police-scanner. The “@magpiradio” channel reads tweets sent to the radio, and the “Requests” channel pivots based on search terms that you send the radio.
The Hardware
Magpi Radio is enclosed in a Crate & Barrel bowl that’s received some love from the wood shop. The beak is made from a diffuse silicon sheet that I found attached to an ice-cube tray. This diagram describes the electronics that do the heavy lifting:
I’ve added details about the process and code in another post.
For our Physical Computing midterm, Max Ma, Harry How and I set out to create a remote controlled car that follows a laser beam. Why? Because Max needed a companion to replace his cat that’s living in China.
The Setup
We’ve got a webcam hanging above the room that’s wired to a laptop running a Cinder app. The app uses OpenCV to track the position of the car in relation to the laser beam and sends steering instructions to the car wirelessly via XBee chips.
We originally tried using IR to transmit the instructions to the car but we found it much slower and less reliable. Switching to the XBees introduced a couple of additional challenges (e.g. debugging without the serial output) but ultimately it was the right tool for the job.
Here are a few videos of the steps we took to construct the end-product:
Color Tracking
This video shows the initial state of the app that’s just doing color tracking. The sliders on the left let us configure the exact color ranges that we’re interested in. We also ended up using an excellent little utility called uvc-ctrl that allows us to control the exposure, focus and white balance of our video feed.
Vehicle Simulation
We then added a simulated car to the app for play testing and to accommodate the car model in the software design.
Steering Tests
We made a quick-and-dirty app to test sending steering directions to the car. Steering is accomplished not pivoting the wheels, but by rotating the wheels in opposition to each other. This gives us a very tight turning radius which is easier to model in the software.
Successful Loop
Finally we tied it all together and Laser Cat was born. The vehicle is moving a little slowly in this video because the batteries are getting low. We were all a little tired at this point.
All of the code required to run Laser Cat is available on github: https://github.com/wdlindmeier/lasercat
In this video, I’m controlling the pixelization of an image with a potentiometer that’s connected to an Arduino. Here’s a brief overview of how it’s done:
• The Arduino is sending the value of the potentiometer to my laptop via USB with Serial.println();
• Node.js is reading the incoming data on the serial port with the SerialPort library.
• Node.js passes the serial value to the browser through Socket.io.
• The browser redraws the image in canvas when it gets new serial data. I got the pixelization code from html5canvastutorials.com.
The webapp source is available to download and modify. The Arduino source is very simple:
void setup(){
Serial.begin(9600);
}
void loop(){
int analogIn = analogRead(A0) / 4;
Serial.println(analogIn);
}
© William Lindmeier | wdl225@nyu.edu | @wdlindmeier | Theme by Eleven Themes
Recent Comments