Archives for Work
26 February 2006
A PCB I designed for Arduino – with prototyping holes so you can solder in extra components. Nothing too new, as I mostly just deleted pieces of the existing Arduino serial board, but I did spend a lot of time rearranging the components to get as much room as possible for the prototyping space. Many thanks to Massimo for teaching me to use Eagle (among other things).
28 July 2005
A possible thesis topic that explores closer integration of various parts of programming: writing, running, reading, and debugging code. How can principles of programming environments for beginners (e.g. hands-on exploration, visualization of program execution) be applied to professional programmers? How can we play with existing code to figure out what it does? How can we take advantage of tools that understand the structure and function of code?
One inspiration is Subtext, another is Jared Schiffman's thesis on the aesthetics of computation, a third is the Omniscient Debugger.
A possible difficulty is that although I consider this to a legitimate topic in interaction design, it may be outside the specific expertise of the IDII faculty.
21 June 2005
Working titles, deliberately vague.
Extra-Textual Tools for the Working Programmer
Visual Interfaces for Physical Computing
Software Tools for Custom or Interactive Data Visualizations
Experiments in Social Software
Explorations of Internet Media as Extensions of the Nervous System
Thoughts?
22 May 2005
Wiring for Processing is Wiring firmware and a Processing library that allow you to use the microcontroller from the PC. That is, you can read sensors, detect buttons presses, control LEDs, turn on DC motors, and the like straight from Processing by downloading a single piece of code to the Wiring board. Check it out.
Screenshot from an example Wiring for Processing program.
It didn't take long to port this to the beta version of Processing and package it up into a library, but documenting took a while. I like the new input example (with the abstract Wiring board) a lot, though.
21 April 2005
I uploaded a couple of web-related programs that I've been working on. I should explain that Kinja is an online feed aggregrator, or a website that lets me collect my favorite news sources in an easy-to-track page. It goes well with del.icio.us a site for storing and sharing bookmarks. Anyway, check them out.
16 March 2005
James and I are heading to the World Haptics Conference tomorrow to show I Can Feel the Music. I'm looking forward to seeing all the hard-core haptics projects.
02 March 2005
For the last month or so, I've been working on a service design project. Marcos, Pei, and I are trying to build a website to allow people to share books, notes, and recommendations.
02 March 2005
I put up a portfolio of my IDII work. It's not complete, but it should give you some idea of what I've been up to for the last six months. Let me know what you think.
24 January 2005
The radio that James and I made in our physical computing class was
in a show in Torino on Saturday. James refined and rebuilt the radio during
the Applied Dreams, and built two more radios in the process. All
three were on display, along with many of the other projects from the
class. They looked intriguing and polished in the midst of a newly
designed, ancient luxury apartment. We were upstairs from an
exclusive restaurant built on Roman ruins, across from the Porta
Palatina, and had views of two domed churches. We were even
mentioned
in we make money not art. Definitely worth the all-nighter I
pulled helping James get the radio the working. Now I'm inspired
to keep working on the Wiring haptics library I developed during the
Appled Dream.
17 January 2005
Spent today working on a serial library for Wiring. I'm trying
to buffer characters and process a whole line at a time. Lots of
problems with synchronization, as the serial data arrives as an
interrupt, and so I had to be very careful not to disturb the line
parsing routines. Also, I set up a CVS repository on my machine,
and spent some time struggling with its command-line arguments.
Anyway, here's what I came up with:
// serial.c
// David A. Mellis
// Interaction Design Institute Ivrea
// 17 January 2005
// This file documented with Doxygen.
// See http://www.stack.nl/~dimitri/doxygen/docblocks.html for details.
/// \file
/// \brief A library for processing serial data one line at a time.
///
/// Replaces (and uses) Wiring's default serialEvent() function for
/// processing serial data character-by-character and inside an interrupt.
/// Instead, buffers serial data and allows access to entire lines from
/// within the loop.
#include
#include
#include
#include
#include "BConstants.h"
/*****************************************************************/
/* Serial Line Library */
/*****************************************************************/
// ser_buf buffers incoming serial data.
// ser_write_index and ser_read_index chase each other around ser_buf.
// ser_write_index is the index to which the next character of incoming
// serial data will written.
// ser_read_index is the index of the next character of data to process.
char ser_buf[1024];
int ser_buf_size = 1024;
int ser_read_index = 0;
int ser_write_index = 0;
int ser_overflow = 0;
/// \brief Initialize the library.
void beginSerialLine()
{
}
/// \brief Call when done with a line to free the memory it uses.
void serialLineDispose(char *line)
{
if (line)
free(line);
}
/// \brief Gets a copy of the next line of serial data.
///
/// Returns 0 if no line or not enough memory is available. Call
/// \ref serialLineDispose when done with the line.
char *serialLine()
{
int len, i, j;
char c, *line;
boolean found_newline = false, hit_end = false;
boolean overflowed;
// check overflow now, otherwise an overflow between the calculation
// of line length and the overflow check would trick us into
// thinking that we had counted all the characters received
// and leaving part of the line in the buffer.
overflowed = ser_overflow > 0;
// starting at the current read index, look for a line of serial data.
// two things can end a line: a newline or an overflow.
// we have to remember which condition we encounter, because an
// interruption by more serial data could make it impossible to
// figure out later.
i = ser_read_index;
len = 0;
for (;;) {
if (i == ser_write_index) {
hit_end = true;
break;
}
if (ser_buf[i] == '\n') {
found_newline = true;
break;
}
i = (i + 1) % ser_buf_size;
len++;
}
// if we hit the end of the buffered data and there's no overflow,
// we're processing data faster than it's coming in and we haven't
// actually received a full line yet.
if (hit_end && overflowed == 0)
return 0;
line = malloc(len + 1);
// XXX: we should distinguish between no line and out-of-memory
if (line == 0)
return 0;
for (j = 0; j < len; j++)
line[j] = ser_buf[(ser_read_index + j) % ser_buf_size];
line[len] = 0;
if (found_newline)
len++;
ser_overflow = 0;
ser_read_index = (ser_read_index + len) % ser_buf_size;
return line;
}
void serialEvent()
{
// stop at the character before the last character that was
// processed. if instead we stopped when the indices were equal,
// we would never buffer any characters when processing was
// caught up (e.g. at program start, when both indices are 0).
if ((ser_write_index + 1) % ser_buf_size != ser_read_index) {
ser_buf[ser_write_index] = serial;
ser_write_index++;
ser_write_index %= ser_buf_size;
} else {
ser_overflow++;
}
}
17 January 2005
Here's a quick picture of the radio that
James
and I built. On the left is a simple Processing GUI that lets you
chance the forces that are applied as you tune into each station on
the dial. On the right is the radio. To adjust the volume, you
pierce the tin foil top.
14 January 2005
Last week and next, I'm working on a haptics module for
Wiring with
Reto, Massimo, and David and Diego Cuartielles. We're
trying to make it easy for other people to use force-feedback, as
James
and I did in our radio (link coming).
Wiring is a board, programming language, and IDE for using electronics
in physical computing projects. It was designed as
Hernando Barragán's IDII thesis last year. It builds on
Processing, a language and IDE
for on-screen interactive design. Both tools are wonderful for all
sorts of interesting projects.
The project has a few layers: a Wiring API, a serial protocol,
a Processing API, and a GUI. My priority is ease-of-use (at the
cost of perhaps a bit of efficiency); for example, I'm reporting
encoder positions as degrees instead of encoder counts. It's a
good challenge to try to create something for designers instead of
other programmers. Definitely something I want to do more of.
Here's a quick sample of the sort of functionality I'm working on:
- void attachMotor (int drive0, int drive1)
- Attach a motor to particular pins.
- void addPeak (float angle)
- Adds a peak to the feedback function at angle degress.
- float encoderResolution ()
- Returns the encoder resolution in degrees.
- float encoderAngle ()
- Returns the current position of the encoder.
08 November 2004
Here's a typography exercise I did for my design skills class. Together, we had to animate
the title of Der Lauf Der Dinge,
or The Way Things Go. I had L and A.
07 November 2004
Last Thursday,
Aram
and I gave our final presentation for our first class here at the
Interaction Design Institute Ivrea.
We had spent the preceeding four weeks creating a Java applet that
introduces people to the Turing machine, a simple mathematical model
of computers. This week, we're supposed to reflect on the process and
what we learned (a lot, in my case).
After we decided on a concept, Aram and I retreated to our areas of
expertise and started working: Aram on the design, and I on the coding.
Two weeks later, two days before the presentation, our program was
nearly done and we felt good. Then we tried it out on a few people from
the non-Turing machine half of the class. That half-hour taught me more
than the previous three weeks. No one could use the program without
our help, and the initial tutorial felt too long and boring. I wanted to redo
a good portion of the interface. It was a shame that our class didn't talk
about prototyping, or allow us to use a language that facilates it (like
Flash). We would have ended up with a better-designed program, though
not necessarily one that was as functional.
That trade-off between design and implementation is another of the main
lessons I'm learning here. As a software developer, my job was to get a
program to work. Now, that's not always the primary goal. If you have a
good enough idea and present it well, someone else can handle the
implementation. Not that I don't want to build working projects, but I'm
starting to understand that it takes a long time to build a system, and I'm
better off with a finished design and prototype code than half of the production
code. It gets other people more excited about your idea.
21 October 2004
Here's a quick screenshot of the project that
Aram and
I are working on. The Turing machine works, now we just have to create the
levels and hints, and the code to support them.
12 October 2004
This applet comes from an assignment in my design and programming skills class. We had to express a mood by arranging four equally-sized black squares on a white square. The moods were balance, tension, progression, motion, play, and rhythm.
I had trouble with the paper squares, so I wrote a Java applet to arrange the squares. It could use a few more features, such as different shapes and colors, but it worked well for my assignment.
Try it out and let me know what you think.
19 September 2004
I was playing around with Processing and came up with this simple simulation of ink falling into a maze. The source code is also available. I'm hoping to work on my design skills this year. If you have any suggestions, let me know.