Overview of technical components
Posted Mon, Nov 29, 2004 at 12:48 AM
Modified Thu, Nov 2-, 2004 at 04: 1 AM
Here's a diagram that breaks down the main components (obviously not proportionally scaled) required for the end product and the communication that happens between parts.
I'm queen at making things more complicated than they need to be so there's a lot going on here. I'm approaching the production of this project very "bottom up" so we'll see what I can get done by March 2005....
(Note that [A], [B], and [C] would be integrated together.)
(Also note that any links to products are for reference purposes only.)
[A] Sensors
I'm still in debate about whether to use photo resistors or infrared sensors to detect if and where a user might be. I want my pond skaters to actually swim (skate?) away if they feel threatened (ie. someone waves their hand close to the glass) and to die if they are stepped on. They also shouldn't be colliding with any solid objects standing on the glass.
With a photo resistor (aka photodiode, aka photocell), in conjunction with the RCTIME command in PBASIC, I can program a Basic Stamp microcontroller to continuously poll for changes in light. So a drop in the light level (a shadow) might mean danger; a complete blocking of light would mean that someone is standing right on the glass.
However, if the display were set up in a darkened room, then this wouldn't work very well. Infrared sensors would work better in this case but they are much more expensive (~$4-$30 each) compared to a photo resistor (~$0.70-$3).
I also need to consider the amount of RAM available to do all the sensing as a microcontroller only has about 16 Bytes of RAM available.
[B] LED matrix
A matrix of LEDs. The full display size would be made up of a bunch of smaller 8x8 or 16x16 displays networked together to create a seamless animation.
I've discussed the aesthetics of it in this post and I've been working out some of the technical details here.
[C] Microcontrollers and other electronic components
There will probably be at least 2 microcontrollers for each 16x16 LED segment. One microcontroller would need to drive the animations ([C]-->[B]) and the other would receive the data from the sensors ([B]-->[C]).
Either one of them (or maybe both) would need to communicate with the "super chip" that's sending/receiving input from the computer via the serial port ([C][D]) for the entire structure.
I'm currently prototyping on my Basic Stamp Stack (~$50 each) using PBASIC but, because there's so many microcontrollers needed, I'm going to go with PIC chips (~$7 each) in the final project and programming them using Assembler.
[D] Computer CPU
The CPU will be the brains behind it all. I'm going to go with the Processing programming environment to make the serial connection to my microcontrollers. I prefer programming in text which is why I chose Processing over Max, Pure Data (PD), and Eyesweb which are graphical programming environments. It's also nice that Processing is free and the forums are active.
Now making the connection to the internet ([D][E][F]) gets a bit tricky (or is at least uncharted territory for me). I'll work backwards from [G] to help explain why.
[G] Home user computer
Any user with an internet connection and a web browser with the Flash Player installed will be able to communicate with the LED display and each other. I pick Flash because most people have it, it's lightweight, and I'm familiar with the Flash authoring environment. (It's also worth noting that Processing doesn't yet support TCP network connections so I couldn't use that.)
[F] Web server
Because PoC is multi-user, the web server requires special server software to be installed in order to have persistent connections. I'm going to go with Unity which is a XML socket server built specifically for communicating with the Flash Player.
I'm not too sure about the specifics for server hosting yet. I can either go with a hosting company that has Unity pre-installed or temporarily set up a server using my home broadband connection.
Now back to...
[D][E][F]
Flash does not have inherit serial communication abilities which is why Processing was brought into the picture. So how will Processing and Flash talk to each other? Thankfully there's a dandy thing called Open Sound Control (OSC) which is the MIDI concept updated. It gives different applications a common language in order to communicate with each other.
FLOSC (Flash Open Sound Control) is, as the name implies, is the OSC implementation for Flash. The FLOSC java server would be installed on [D]. OSC support for Processing has also been created and requires the installation of a library.
So within [D]: Processing makes the serial connection, talks to a locally running Flash Player via FLOSC, and then that info gets broadcasted to Unity on [E], which subsequently broadcasts to any [G] users. (And vice versa.)
Yes, so that's it...mostly. Again, I'll point out that I'm taking this bit by bit so we'll see how much I get done by March.