So a while ago, I made a promise to myself not to start any more projects before I finish the ones I've already got going. And the one that'd been sitting around the longest was the damn LED spider that I'd been meaning to make a simple USB interface for.

IMG_0132

Thanks to swag from GDC, LED Spider now has an LED Wiimote to play with! So yeah, they're just two silly things involving blue LEDs, but I figured I might as well hook up whatever I have around that has LEDs in it to this thing since USB can provide the power for more of these than is ever necessary. Hence the new name of the project, "LED Casserole". I'll just keep hooking up whatever I find to this box until the board gets full.

IMG_0142

One of the interesting things about this project is the project box I used. I had black "project boxes" of all types lying around that I've gotten from different electronics stores, all of which are usually <1cm to large/small in some direction to be truly useful, and all of which cost at least $5. I packaged this board in a little plastic box from Ichiban Kan in El Cerrito. Incredibly simple to cut up with my Dremel, and @ $1.50/4 boxes, I can fuck 'um up all I want. And they've got all sorts of sizes, nothing more than $2. Realized this technique after checking out some stuff from a Japanese electrostim builder on SmartStim, and I have a feeling most of my projects are gonna come out looking like this now.

IMG_0145

The circuit itself is simple. This is the exact board I was using for my 1-node ambilight which ended up not working due to massive noise problems. I'm building another version of that board, so I just stripped the extra MOSFETs off this one and left it with one line. The 50V/48A MOSFET as LED driver is probably a smidge much, but hey, it was already there and it worked.

This project also makes use of the nifty new molex friction lock connectors I got from Phoenix Enterprises. No more plugging in shit backwards! Yay!

The whole thing is powered off the USB line, the MOSFET just works as a simple switch for the LEDs. The switch on top turns the power to the lights on and off. Software is USBTiny with an extra CONTROL instruction that takes a single byte for setting the PWM.

Onto the next project!


Hotel/plan booked, registration finished, I'm goin' to SIGGRAPH! I haven't been this excited about attending a conference in quite a while. Not to mention, this is gonna be possibly the first conference I've been to where I haven't also been speaking. See you there!


Fwiktr 0.2.0 is up and running

The goal of Fwiktr v0.1 was to simply get a picture from flickr based on a twitter message. That goal achieved, it was time to make the interface more extensible.

I've now broken fwiktr into performing certain core functions (called services), and then providing a way to edit the input and output of those functions (called transforms). For those of you who are thinking "hey, this setup looks awful familiar", please stop reading my blogs and work and get back to fixing the grid.

Here's what a current run of fwiktr looks like at the moment

  • Retrieve Post from Public Timeline of Twitter (via Twitter Service)
  • Run cleanup transforms on post (Twitter Post Cleanup Transform - Remove URLs and specific post service information, like @name symbols for twitter directed messages)
  • Run post through language parser (Lingua::Identify Service - Right tool for the job, even if it is the wrong language :) )
  • Using returned language, choose proper TreeTagger implementation and run Parts of Speech Marking on post (Treetagger ENGLISH - Nouns Only Transform)
  • Get pictures using ALL search mode for flickr API (Flickr Full AND Transform)

  • If zero pictures returned, use ANY search mode for flickr API (Flickr Fuck It Transform)

All of this is compiled into an XML block which is then shipped to the remote web DB. Instead of trying to wrestle with a generalized SQL schema, I decided to send data in XML form as it is easily mutable and still fairly backwards compatible as long as the DTD is kept generalized. Not to mention, it's less code I have to write at the moment, and I'm more interested in making art than in making a searchable database for the time being (and thanks to the DTD, turning the data into a DB shouldn't be much of a problem at all once I want to do that).

Aside: The XML block is now available for outside parsing, just add "&xml=1" to the end of the art request URL, but I'll warn you, it's a complete mess right now, there's many different formats (that at least all follow the same DTD, but that's it) due to having the DB persist through development of v0.2. I'm gonna write a script to clean things up, but that may be a ways off)

The really nice thing about this setup is that every level (the post retrieval, picture retrieval, language identification, and transform layers) are all completely pluggable, while still providing a fairly robust pipeline for the task. I am very much interested in writing my own parts of speech tagger, language identification algorithms, and other things, but for right now, they work on proven software, and produce output that I can compare my own implementations against once I get around to that.

Which may very well be never.

At this point, I'm pretty happy to let fwiktr run as is for a while. Before I completely call phase 1 finished, I'd like to have an RSS feed, and /maybe/ start taking post requests (i.e. you can hand it a twitter URL and it'll parse it for you).

Here's the plans for the future:

Phase 2

  • Implement small, quick user system (maybe using OpenID, 'cause that seems neat, but I'll probably just try to hook into some prebuilt simple CMS, which scares me, 'cause CMS selection is a bitch these days) to allow ratings, favorites, etc... - this is very important for AI training that I can use later
  • Create simple DB import utility to make data more accessible

Phase 3

  • Implement art overlay rendering (pasting the message back over the picture
  • Implement seasoning system

  • The "seasoning" system is something that I'm rather looking forward to implementing. Right now, we're throwing away all URLs and emoticons. However, these are completely valid and useful parts of a message which could be used to seed more tags into a search. The emoticons could be translated into moods (though I'd have to do some statistical analysis on tags first to see if anyone actually uses that), while URLs could be descended into and scraped for some sort of context which could be fed back into the message. There's other metadata that comes along with the message that this idea could be used with too (i.e. using location plus post time to pull weather modifiers from some weather reporting service, adding "clouds" or "sun" or "rain" as tags.

Phase 4

  • Start phasing out external NLP systems in favor of hand written ones

  • I'm leaving this step until I have all the features in as I want them, otherwise I'll just get pissed off and quit and leave the project in a half finished, non-working state while I try implementing something someone else has already done. Much better to have a working model to compare against,too.

But, for right now, this is the end of this phase of fwiktr. I've got a couple of other quick one-off projects I want to work on which I'm sure will give me more ideas for this one, and at the rate this turns out pictures, I'll have lots of fun data to play with when I get back to it.


Out of the 27551 images fwiktr produced over the past 3 days ('cause I totally forgot I had it running), around 1800 have to do with the iPhone.

I'm not sure whether I'm surprised by how large or how small that number is.


So I've added a DB backend to fwiktr, and gave it the ability to reload automatically so you can sit there and stare.

Here it is

Trying to clean things up a little more so I can easily plug more post and picture sources, then back to the fun stuff ('cause I'd completely forgotten how much I hate PHP programming).

Some favorites so far:

freakin underwear keeps riding up ugh

LaTeX isn't cooperating. I know for a fact that my document is well-formed TeX.

At KABUTO-CHO .

resisting sleep for no good reason.

I was a math teacher, and my counting is impeccable. http://sciencehack.com/videos/view/HJPKrcnXRRc - Wow, and I found this neat video from this one

Back to the Java Forums


Weird things happen when I get bored.

Luckily, they're usually things that make both me and others less bored.

I've had a 3Com Audrey sitting on my computer desk for a few weeks now, staring at me, begging me to do something with it. Unfortunately, all it can really do is run a web browser. A web browser from the late 90's at that. No CSS love for me, nor even flash or anything else. Nope, only the basics of HTML.

It seemed like it'd be a neat picture frame, at least. However, I didn't really want to just cycle random flickr pictures on it, because that's boring. There had to be some more interesting way to produce stuff for it, that would actually make me want to look at it.

Thus, Fwiktr was born.

The Fwiktr Creation Process

This is all done using python, because it seemed like a fun way to start picking up more parts of the language.

Here's the ingredient list for everything that's not included with python these days:

The idea behind Fwiktr is simple. In its current form, it's bascially a Chinese Room artist. It pulls the last 20 lines from the public timeline of Twitter, runs them through a parts of speech generator, and discards everything but the nouns. It then uses those nouns as basis to do tag searches on flickr. This is currently an "ANY" search, meaning that it will return pictures with any of the tags listed. It pulls a list of up to 100 images from flickr, picks one at random, dumps the information to a file, and uploads it to http://www.30helensagree.com

Right now, the Parts of Speech tagging happens through an external call to Treetagger. This is because before this project I'd had zero experience working with natural language processing, and I'm still working on figuring out exactly how one makes a nicely trained Brill Tagger in nltk. But I'll get to the future plans in a bit.

So, for all intents and purposes, Fwiktr is nothing but superglue right now. There's no real AI to speak of, it's a purely reactive behavioral system. Anything it does right is emergent, anything it does wrong is your fault for not understand the art it produces.

Now, I'm not the first person to do a twitter/flickr ma... mas... Ok, I can't bring myself to say that word. I'm not the first person to do a twitter/flickr combination before, there's some other neat ones out there:

What's Happened So Far

Here is the very first file Fwiktr ever put out (File format: Flickr Message, Parts of Speech Output, Tag list, First 100 pictures returned by tag search)

That file cost me a good 30 minutes of time, just because I didn't format it nicely and found myself cutting and pasting URLs everywhere just so I could see what was going on.

The first message:

"Got my new Russian neighbor drunk on margaritas. USA! USA! USA!"

The first URL gave me this image:

Oh yeah, this was gonna be good.

Second message:

"Laughing at Thomas' outburst in the maxipad section of the drug store: "Look Mum! All the vaginas are lined up in a neat row!" AH, 3. OY."

Image?

Ok, so, 2 for 2, but there was still the human element there, with me having to cut and paste the URLs. If Fwiktr was gonna work right, it would have to decide for itself which picture went with the message. So, it chooses a number between 1 and min(number of pictures returned, 100) and uses that image.

First automated message:

"Lovely spam, wonderful spa-a-m, Lovely spam, wonderful S Spam, Spa-a-a-a-a-a-a-am, Spa-a-a-a-a-a-a-am, SPA-A-A-A-A-A-A-AM, SPA-A-A-A-A-A-A-A"

First automated image:

I now firmly believe that God is communicating with me through Fwiktr.

Fwiktr has the capability to upload results on its own now, and is running a new image every 30 seconds at 30helensagree.com. The current file format is:

  • Message Text
  • Image
  • Treetagger Output
  • Tag string sent to flickr
  • Random index selected and total result count
  • First 100 images returned

It's definitely had some hits as well as some more artistic moments.

The Future of Fwiktr

Fwiktr has a long, long way to go. Right now, I'm content to revel in its emergence and work on a better interface for the display. But, I do have feature plans:

  • Use Python Image Library to overlay the message on the image
  • Far future: Do this in some interesting, artistic way.
  • Language Processing Tasks
  • Vary parts of speech used for tags
    • Obviously, tags are not just nouns. People use verbs, adjectives, and other parts of speech. These should get picked up while still dropping parts of speech that are rarely used for tags.
  • Use neural nets and manual feedback (via rating system on the site) to train tag combination system
    • When we pass tags to flickr, right now the only data Fwiktr knows is "I've got a pile of nouns, you do somnething with them!". If we could possibly say "Ok, I've got this set of nouns and this set of verbs and they go together with these boolean operations", we lose our chance for crazy emergence but possibly gain contextual search
  • An example of all of the above: In the first text file, one of the twitter messages was "At board walk. Got an ice cream.". Fwiktr did a good job of pull tags, and gave us back the list "board,walk,ice,cream". Unfortunately, when this pile was passed to flickr, it saw "board OR walk OR ice OR cream", and gave us back ANY images with tagged with board, walk, ice, or cream in them, which means, that we got lots of winter pictures of iced over trees, too. If Fwiktr knew to pass "boardwalk AND icecream", then we'd have gotten back 48 completely contextual images versus many thousand hits and misses. Of course, the AI between "board,walk,ice,cream" and "boardwalk AND icecream" is a mighty step.
  • Train up specific tagger for Fwiktr versus using treetagger
    • Natural Language Processing programs are trained off of what are called "Corpora", which is the plural of "corpus". Basically, it's text that's been marked up to show different grammatical structures and parts of speech to make it easy to process. Unfortunately, most of the big, usable corpora are stuck with HUGE, unusable costs to get to, because they're used by academic institutions who can afford them. Now, I'm not sure I really need to get able to hit all of treebank to get this working correctly, but I don't know if I'm gonna have much luck working with just the Brown Corpus either. Still lots to learn in this area, but I'm rather eager.

So, that's it for right now. Fwiktr is slaving away throwing new files up on the site, so keep an eye out. I hope to have a nice auto-reloading interface up by tomorrow.


Off to sunny Georgia, where I'll be speaking at the GDX Conference on Creativity in Second Life. Should be a fun trip!


DesktopMap

Originally uploaded by qdot76367.

In the interest of seeing what happens when I build my own usability interfaces, I put my daily development setup into a mindmap, documenting keystrokes required to get to things, number of sub-contexts each application forms (either fixed, range, range+ which means range is normal but can be more, or ? which means god only knows).

This setup seems completely natural to me, but looking at it this way, it's interesting to see what could be changed and optimized to either be lower in the tree or accessed differently.



IMG_4298 Originally uploaded by qdot76367.

Weekend project, while not quite as done as I wanted it to be, was still a success!

Made a USB reference implementation using the USBTiny firmware only USB 1.1 Low-Speed driver. Haven't actually gotten to do much with it outside of putting the board together and running a couple of python (which I'm learning to love quickly) test scripts. Still, it's nice to have some sort of USB connection without having to go through FDTI, though I suppose I could always do something zany like move to a decent, higher speed 32-bit platform too. But for now, this works.

usbref Originally uploaded by qdot76367.