Archives for Work

Arduino Prototyping

26 February 2006

arduino_prototyping.jpg

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).

Thesis Possibility: Truly Integrated Development Environments

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.

Possible Thesis Topics

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?

Wiring for Processing

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.

Wiring for Processing example screenshot.
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.

Net Hacks

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.

The Sense of Touch

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.

Service Design

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.

Portfolio

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.

Strangely Familiar

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.

Strangely Familiar Poster

Serial Buffering Library

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++;
	}
}

Forcefeedback Radio Picture

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.

Picture of the radio

Haptics Library for Wiring

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.

Typography Exercise

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.

Der Lauf Der Dinge [java]

Turing Project Reflections

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.

Turing Machine Screenshot

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.

Java Applet for Abstract Composition

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.

Squares

Try it out and let me know what you think.

Inkfall

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.

Inkfall