HTML5 had originally laid out support for a new element (the “device” element) but it appears this element has been scrapped now in favour of the “getUserMedia” API. So far I have only seen the Opera Mobile Experimental build support this but hopefully it’ll get into Dolphin and other mobile browsers soon.

http://my.opera.com/core/blog/2011/03/23/webcam-orientation-preview

If you just want to cut to the chase here’s a video of the final result:

There are three moving parts here

• a) The client page which captures the video
• b) the server which is a simple Node broadcast server
• c) and the Client which is just a web page that renders the output.

The client is just a copy-paste from Opera’s website. I take the video stream, render it to a canvas, then grab the canvas as a base64 encoded image. One image per frame. I could not find a way to limit the video’s size so the resulting image is fairly large (240×400 on an HTC Incredible). I down-sampled, cutting the image data to reduce the traffic over the wire. Framerates are still pretty poor but this is just an experiment.

The server is a generic websockets server and gets a message which is a raw data/base64 stream. It broadcasts this down the any connected clients.

The client then is the simplest of all, just connects to the socket server and renders whatever it gets to an tag.

It’s all Javascript.

Client (this is a jade view).

h1
    Remote Webcam using NodeJS, Opera, Web Sockets and HTML5/Canvas
video(autoplay=true,id="sourcevid")
canvas(id="output")
div(id="log")
script
    var log = function(msg) {
       document.getElementById('log').innerHTML = document.getElementById('log').innerHTML + msg + "<br/>";
    };
    var video = document.getElementsByTagName('video')[0],
        heading = document.getElementsByTagName('h1')[0];
    if(navigator.getUserMedia) {
        navigator.getUserMedia('video', successCallback, errorCallback);

        function successCallback( stream ) {
            video.src = stream;
        };

        function errorCallback( error ) {
            heading.textContent = "An error occurred: [CODE " + error.code + "]";
        };
    } else {
        heading.textContent = "Native web camera streaming is not supported in this browser!";
    };

    var back = document.createElement('canvas');
    var backcontext = back.getContext('2d');

    var ws;

    if('WebSocket' in window){
        connect('ws://192.168.2.100:8080/');
    } else {
        log ('web sockets not supported');
     }

    function connect(host) {
        ws = new WebSocket(host);
        ws.onopen = function () {
            log('connected');
        };

        ws.onclose = function () {
            log('socket closed');
        };

        ws.onerror = function (evt) {
            log('<span style="color: red;">ERROR:</span> ' + evt.data);
        };
    };

    function send(msg){
        if (ws != null) {
            if(ws.readyState === 1) {
               ws.send(msg);
            }
        } else {
            //log ('not ready yet');
        }
    }    

    cw = 120;//240;//video.clientWidth;
    ch = 200;//400;//video.clientHeight;
    log('width = ' + ch);
    back.width = cw;
    back.height = ch;
    draw(video, backcontext, cw, ch);

    function draw(v, bc, w, h) {

        // First, draw it into the backing canvas
        bc.drawImage(v, 0, 0, w, h);

        // Grab the pixel data from the backing canvas
        var stringData=back.toDataURL();

        // send it on the wire
        send(stringData);

        // Start over! 10 frames a second = 100milliseconds
        setTimeout(function(){ draw(v, bc, w, h); });
    }

The server. Simple Broadcast app.

var sys = require("sys"),
    ws = require("./ws.js");

var clients = [];

ws.createServer(
	function (websocket) {

		clients.push(websocket);

		websocket.addListener("connect", function (resource) {
			// emitted after handshake
			sys.debug("connect: " + resource);
		}).addListener("data", function (data) {

		// handle incoming data
		// send data to ALL clients whenever ANY client send up data
		for (var i = 0 ; i < clients.length ; i ++ ) {
			clients[i].write(data);
		}

    }).addListener("close", function () {

		// emitted when server or client closes connection
		sys.debug("close");
    });
  }).listen(8080);

  sys.debug("Listening on port 8080");

The client.

<img src="" id="frame" style="width:240px;height:400px"/>

<div id="log"></div>

<script type="text/javascript">

	var img; 

	function Init() {

		img = document.getElementById("frame");	

	}

	$(document).ready(function () {

		Init();

	});

// Web socket connection stuff is next...	

	if('WebSocket' in window){

		connect('ws://localhost:8080/');		

	} else {

		log ('web sockets not supported');

	}

	var ws;

	function connect(host) {

		ws = new WebSocket(host);

		ws.onopen = function () {

			log('connected');

		};

		ws.onmessage = function (evt) {  	

            if (evt.data != null) {		

			  if ((evt.data[0]=== "d") &amp;amp;amp;amp;&amp;amp;amp;amp; (evt.data[1]==="a") ) img.src=evt.data;	//log('got' + evt.data);

			}

		};

		ws.onclose = function () {

			log('socket closed');

		};

		ws.onerror = function (evt) { 

			log('<span style="color: red;">ERROR:</span> ' + evt.data); 

		};

	};

	function log(msg){

		document.getElementById('log').innerHTML = msg + "<br/>" + document.getElementById('log').innerHTML ;

	}
</script>

Instead of broadcasting, you could store these frames in a MongoDB for assembly later. This would make the ultimate, storage independent video camera. Never run out of storage again!

I really need to start storing these snippets on github…

P.S. Everyone knows insects are clockwork which is why god made so many of them. Today’s image is from http://www.insectlabstudio.com/

HTML5 introduces the ability to perform multi-threading in the browser using Javascript through the notion of “Web Workers”. So far I have only seen examples of using workers to calculate very high prime numbers. I took a fresh look at these from the standpoint of genetic algorithms and applied it to the Traveling Salesman Problem (a classic). The results are a multi-threaded implementation of the TSP in Javascript capable of converging on a solution for up to 200 cities, all with a zero-footprint.

This project was born on a plane over the Atlantic last week. With such a long title to this post I thought about breaking it up into multiple posts but got lazy and figured if you’re on this site to begin with, chances are you’re familiar with all these concepts already so here goes.

First a refresher:

The Travelling Salesman Problem (TSP) is an NP-hard problem in combinatorial optimization studied in operations research and theoretical computer science. Given a list of cities and their pairwise distances, the task is to find a shortest possible tour that visits each city exactly once.

The most direct solution would be to try all permutations (ordered combinations) and see which one is cheapest (using brute force search). The running time for this approach lies within a polynomial factor of O(n!), the factorial of the number of cities, so this solution becomes impractical even for only 20 cities.

http://en.wikipedia.org/wiki/Travelling_salesman_problem

Instead of Brute Force I will try to converge on the solution using a genetic algorithm.

At this point you may want to flip to the finished project using CHROME 7+ or Firefox 4+ or Opera 10+

http://francisshanahan.com/tsa/tsaGAworkers.htm

Genetic algorithms are those which can be said to exhibit the characteristics of evolution, i.e. a coded sequence, mutation, a fit function and iterative progression. The typical flow is as follows:

1. Develop a sequence of instructions (the DNA)
2. Develop a large number of these sequences (the population). In the code I called these “strands”.
3. Score the population for fitness.
4. Sort by fitness score and select the top-performers.
5. Generate a new population based off the top-performers.
6. Modify or mutate this new population and repeat the process with this new generation.

Over time the population will tend to converge on a solution. This is a genetic algorithm and it’s not guaranteed to give the absolute best solution. As you can guess the rate at which the population converges on the best solution is determined by a number of factors:

1. Population Size
2. Population diversity
3. Mutation Rate
4. Fitness Function
5. The number of generations
6. The number of “parents” selected to breed from.

A closely related process is that of “Hill Climbing”. Hill Climbing I would say is more deterministic (less probabilistic). A typical hill climbing algorithm is as follows:

1. Develop a sequence of instructions (the DNA)
2. Score the solution for fitness.
3. Modify or mutate this solution and score.
4. If the child is better than the parent it becomes the new parent.
5. Repeat the process (go back to step #2).

So what’s the difference? Well for one, with hill climbing we only ever advance if the new descendant is better than the current solution. With each generation you always converge. With a Genetic Algorithm you advance regardless and hope for convergence over time. Convergence in a GA is not assured.

A more subtle difference is that the Hill Climbing algorithm is fixed on a specific path. It always chooses a better solution, even though there is a chance that this vector will not ultimately result in the absolute solution. However in a GA, the algorithm chooses a set of “good” solutions to breed from, and hence includes the possibility that a current inferior solution might ultimately lead to a better absolute solution overall.

This GA approach mimics real evolution much more closely. It allows for the possibility that a currently superior branch might die off and yield to a currently inferior solution. I think of this as more of a “strategic” solution than a “tactical” hill climbing solution.

Applying GA to the Traveling Salesman Problem I ended up with this:

1. I create a set of random cities within a specific area.
2. Then I create a route through all cities (dna in the source code).
3. Then I score the route by calculating the overall length of the route.  A score + dna = a single strand.
4. Then I create a population of these strands.
5. I sort by fitness score and select the 5 best regardless of score.
6. I create a new generation based on these 5, mutating approximately 80% of the time.
7. A mutation is basically swapping two cities at random. There is no intelligence to the mutation.
8. Score this new generation and repeat the process (go back to step 5).

This works nicely and is pretty trivial code in Javascript involving a little bit of math and a lot of array copies. In order to get decent results for a problem space of 100 cities or more it’s necessary to to repeat this process for at least 20-50 generations at a time. All processing is sequential and the browser hangs up whilst this is going on. To achieve solutions to a higher number of cities some other means of processing is needed.

Enter web workers.

Web Workers are new in HTML5 and in a nutshell they allow you to execute Javascript in a separate thread (in parallel) from the current browser thread. So far Chrome, Opera, Firefox have all implemented web workers. ). I’m not going to explain the basics of workers here as Mozilla has an EXCELLENT explanation of how to get started here: https://developer.mozilla.org/En/Using_web_workers

I’m using them as follows:

1. Create a large population of possible solutions (my solution uses 1000)
2. Create a number of workers, my solution uses 10.
3. Split up the population across the workers, giving each 100 solutions to work on.
4. Mutate and score each one within the worker (10 threads operating in parallel).
5. Join back and Collect the results.
6. Sort the entire population and repeat.

Couple of advantages here are that not only do we get parallel execution and finish processing quicker, we don’t hang up the UI thread so the browser remains responsive throughout.

Web Workers are great for processing but little else. They cannot access the DOM, the cannot generate page events, they cannot do much of anything. What they can do is receive information from the parent page, process information and send it back. This information is limited to strings. You can serialize your objects to a json string and then do an eval on the worker side but this ultimately will be done for you by the browser. So far only Firefox and Opera are capable of serializing JSON objects between the page and the worker thread. Hence the example solution only works in these browsers.

A couple of things I noticed in working with this approach.

1. A larger population does not always guarantee a better solution. There is a balance for any given problem space and fitness function.
2. Mutation rate: You cannot simply change EVERYthing on each generation. You must maintain some of the core DNA in order to improve. Otherwise the solution is too random and does not converge.
3. Similarly, too little mutation and the solution converges too slowly.
4. Number of Breeders – you would think breeding from the single-best solution at any given point would be ideal. Surprisingly the system did better when a higher number, say 10% of the population is used to breed from. Too many and again you don’t converge. Too few and the system can be boxed into a dead-end solution ala the Hill Climbing approach.

The key thing to remember is at no point have I written an algorithm to find the shortest distance. I’ve simply put pieces together in a closed system, assigned probabilities and set the thing in motion. Even still it’s pretty fascinating.

Over the course of the past week I’ve run this thing many times. It’s the type of thing I can waste hours with. I tried various combinations of mutation rate, population size etc to get the right balance. Initially the system did not converge at all. Then I found it would converge but very quickly plateau and run out of ideas so to speak. Amping up the mutation fixed this but negatively impacted convergence, so I tweaked the number of breeders a little. Back and forth until I got it to where it is today. It’s fun to watch the code try to figure out new pathways, occasionally it’ll drop a segment in favour of a different route, only to bring that same piece back in later.  This is where my knowledge of GA falls short. I’m not sure I’ve gotten it right and to take it any further would require some heavy duty research. It’ll suffice for now.

This is a crude system with only 1 test for fitness and no competing goals. Imagine scaling this up to “earth” scale with billions of competing factors, each of varying weights, trillions of instructions per individual,  3.5 billion years of evolution and a system that feeds BACK on itself, altering the fitness functions as it goes. The possibilities are astounding.

As you can tell I had a lot of fun with this one. Genetic algorithms are a powerful concept, particularly when dealing with difficult to solve problems (e.g.  NP-hard). The outcome is highly probabilistic and how the algorithm progresses essentially mimics our own progression as life on planet earth. Too cool.

Now flip to the finished project using CHROME 7+ or Firefox 4+ or Opera 10+

http://francisshanahan.com/tsa/tsaGAworkers.htm

This past weekend I tried my hand at Kirigami. Kirigami is like Origami but cutting is allowed. Typically take one sheet of paper but you can combine multiple pieces as in unit-Origami.

This a cheap past-time and a lot of fun. I recommend a good cutting board, a fresh Xacto, some graph paper and plenty of quiet. I was going to publish up the patterns for these but I think that’d spoil it for the reader.

Here are some photos of the pieces I’ve cut and models I’ve folded. I find the animals far more challenging but not as mathematical or as satisfying.

I started with the LED Matrix component itself. I used an RGB 8×8 common anode matrix from LedSee (only $10 on ebay). The matrix takes 32 pins: 8 anodes, 8 cathodes for Red, 8 for Green and 8 for Blue. Then I had an arduino Diecimila which was about $25 I think but you can use any ATMega based board.

A little googling revealed that a thing called a Shift Register could help me drive all those 32 pins using just a couple from the arduino. Shift Registers are cheap and easy to source. I used the 74HC595 IC.

The arduino website has a tutorial on Shift Registers which can be found here: http://www.arduino.cc/en/Tutorial/ShiftOut. This explains what they are, how they work, the clock, latch and data pins as well as how to chain them together.

After a few evenings of experimentation I knew I could drive 8 pins per 74HC595 chip. If I chained enough together I could drive all 32 pins. So I was set.

Next I drew up the schematic on paper. I played with a few prototypes using Breadboard until I had confidence that the circuit would work. This was a smart move as it turned out there was a problem. I found through experimentation that the Red LEDs were overpowering the Green and the Blue. I couldn’t figure it out since the code treated them all as equals. I went back to the reference manual for the LED matrix and found that the operating voltage of the RED LEDs in the matrix is actually lower than the Blue or Green.

I was able to even them out by introducing a higher resistor (330) into the RED cathodes than is in line with the blue and green (220 ohms). That was a true moment of enlightenment.

There’s a lot of wires so I put it into Visio. Here’s the result:

The blue, green and yellow lines go to the Arduino.

Next up I worked on the code. Besides turning the LEDs on and off I wanted to actually get different colors. I had no idea how to do this but it turned out Robert aka “MadWorm” had already figured it out: [LINK]. My code is essentially based entirely off of Robert’s so I won’t complicate or confuse you with my own extensions.

To better understand the ISR business, I’ll refer you this time to ucHobby [LINK]

The arduino supports an interrupt which is essentially a routine that runs in the the background, almost like a separate thread, from your code. This interrupt is what updates the Matrix pins and it happens very very fast. Even better is that it frees up the main loop of your Arduino sketch to do the interesting stuff like update the actual matrix data.

Pulse Width Modulation or PWM is essentially a way of simulating an analog output from a binary source. Huh? Wha?

If I turn on a Red LED I get red, if I turn on a Blue LED I get blue. If I turn them on both at the same time I get purple. What if I want to get some color in between? with this type of system you can’t get anything but 7 colors (R, G, B, RG, RB, GB, RGB). The only way is to turn on the LEDs partially. But an LED can only be fully on or fully off, how can you get a “partial” LED? The answer is PWM.

Pulse Width Modulation varies the time for which an LED is active. It’s still either fully on or fully off during that time, but if you think of that time as a wave, the “width” of the “pulse” during which the LED is active varies. Here’s a good visual:

The result is an ability to “mix” colors by different degrees and get a far wider range than the 7 possible combinations of RGB. The good news is this is all implemented within Robert’s ISR code above.

So I soldered away busily for three nights and in the end I had a nice little circuit board. Definitely not as small as it could be but good enough for a RevA.

At this point I had everything working nicely so I built simple case of Cherry/Lexan and four hex-head bolts to finish up.

That’s basically it! You can checkout the pictures below or find the video on Youtube. I had a lot of fun making this thing. It sits proudly on my desk today and although many have tried, no one can resist asking “what is that thing”.

The PWM is very tough to videotape but take a peek at the pics. Here’s my daughter playing with the prototype:

Silverlight 3.5 was announced recently so I finally took 5mins to look at their “Deep Zoom” technology. Deep Zoom provides a way to view a HUGE image by converting it into what they call an “image pyramid”. Similar to what Google Maps does. It just so happened that I have a thing that makes huge images. It’s a side project I’ve been working on for about 18 months now. Anyway, I fired it up and made two huge images, one of a Tiger and another of Ethan. More on how these images were created in a later post. Meanwhile email me if you’d like an image of your own.

For now enjoy the Deep Zooms of these images HERE: http://www.francisshanahan.com/zoom/default.aspx
Make sure you click the Full Screen link for full effect.

NOTE: If you’re not seeing anything , install Silverlight first by going here [http://silverlight.net/GetStarted/] and look for the “runtime” link on the right (midway down).

1. I started with wordpess 2.5 which was my host’s default installation. I immediately upgraded to 2.7. This was as simple as ftp’ing some files across and running a database script.
2. I migrated my old data, which was in SQL Server into mySQL using some simple SQL scripts. This took about an hour as I’d never seen the wordpress scheme before. I lost my tags in the process but no big deal.
3. Then I grabbed the Arthemia Lite theme (http://colorlabsproject.com/arthemia/) which I’d first seen on my buddy Chris Webb’s site (ckwebb.com). The lite version is free but with reduced functionality.
4. I grabbed JCarousel (http://sorgalla.com/jcarousel/) and modified the index.php template to make the featured items scroll in the top right.
5. I threw in some Google Adsense ads into the main template.
6. I migrated from Feedburner to Google Feedburner and added in Ads into the RSS in the process.
7. I did some UI tweaks around the theme but nothing too crazy. E.g. Added an image to the Single Post page, updated the favicon etc.
8. As far as plugins go I’m using Akismet for spam prevention, Contact Form ][, All in One SEO and WP Super Cache.
9. Modified the Thumbnail script (timthumb) so I don’t have to upload the images to my server and can link to them directly. This makes new posts much much faster.

That’s about it. Last night I upgraded from 2.7 to 2.7.1 which was very easy and took about 10 mins. Pretty happy so far.

This new blog will allow a lot more features than I could’ve kept up with writing myself. Ping backs, Trackbacks, Gravatar support, a snazzy admin console, widgets galore and a nice theme (much better than my CSS/artistic bent would ever come up with). All in all I’m happy with it and will write more on the motivation behind switching in a few days.

All the old content is still there, links will continue to work although are now redirected. The RSS feed has been moved over but if you subscribed through feedburner you won’t notice a difference.

Let’s see how it goes for now.

foolstr is innovative in that it relies on OpenID as its form of authentication. This means foolstr doesn’t invade your privacy and registration is a snap. It’s also completely anonymous. Things like Passwords or Email addresses, we don’t need ‘em. Your email or password is never sent to Foolstr, you don’t have to remember a NEW password, you don’t have to remember ANYthing. Try it and see!

It’s a fun site and we want the barrier of entry to be small. You can post content without even registering and so far there is some interesting content.

From a technical side this site is another experiment, this time dealing with OpenID to determine just how viable this technology is. So far it seems sound for this level of authentication. The question is will the public understand it and be comfortable with this as a means of authentication. We’ll see. I’ve also hooked up the Yahoo Term Extraction API for content analysis and Google Analytics for Traffic.

So blog about it, Facebook it, Digg it, tell your friends, share your ideas and opinions and vote on what’s there. Let’s see what the fools know…

Foolstr’s still in pre-alpha, with many kinks still being ironed out. If you find a bug, post back to http://foolstr.blogspot.com or use the contact page at foolstr.com.

Now get out there and tell us something we don’t already know!!!
HTTP://FOOLSTR.COM

They saw how things were linked together, how a click on the screen lit a dot on the matrix and it was simple enough but yet they could quickly make shapes and letters. They got a big kick out of it and I’m really glad to be able to expose them to science and learning at such an early age.

If you’re interested in a closer look at the matrix driver circuit, checkout the gallery here:

I came across IBM’s website on burr puzzles [LINK] and decided to make one.

"Burr puzzles are interlocking puzzles known in Europe and Asia since at least the 18th century. Traditionally they are made from wood….and require special wood so that the pieces do not change shape too much in changing temperature and humidity."

Burrs? You had me at "35.65 billion".

I first picked "David Winkler’s favorite level 5 burr" [LINK]. This is a "notchable" burr meaning you can construct it entirely by notching the pieces. I used a bit of red-oak I had laying around. This burr is 6 units long, 2 wide. The unit size in my case is 3/8" which I found a good size. The design in this case is a "5.4" meaning there are 5 moves required to remove the first piece, then 4 to remove the 2nd.

My kids got a good kick out of this one and they’ll likely play with it in years to come. Sunday night I caught the bug again and decided to make another. This time a "general" design meaning one where the pieces are not just notched but also have some partial voids. Slightly more complex to create but allows for more complex solution. I decided to go all out and chose Peter Marineau’s
Piston Puzzle Burr [LINK].

"1986: Peter Marineau designed this puzzle by hand. It was the highest level burr known before Bill Cutler did his exhaustive computer analysis."

I made this one out of cherry with its tighter grain and the fit is a lot better, mostly due to me taking my time. The action in Marineau’s is such that the first piece only comes out after a full 9 moves then 3 more for the 2nd piece. So cool.

I imagine this is the type of puzzle my grandfather would have enjoyed making if he had had the same resources available as me. The chisel remains the most dangerous tool in my shop.