How The Public 8Ball Works

This computer uses an infrared link to communicate with some Lego robotics components from a Mindstorms kit. There is a tiny computer in the lego running this program. It controls two motors (which operate in unison) to turn the 8ball over and then shake it back and forth. It watches with an electric eye so it can turn the 8ball upright after the shaking.

A video camera looks down on the ball from above and sends its signal to an STB TV/PCI card in this computer where this program digitizes the frames, converts them to JPEG, and sends them out to you as a multipart/x-mixed-replace type of content. This is a slick technique since it lets the server program pipeline nicely staying just one frame ahead of your browser. It automatically runs at 1 frame per second or so on a 28.8 modem and up to 10 frames per second with faster links.

For those of you hung up on the picture, the objects are, in order...
a set of UHF/VHF rabbit ears, the head of the lamp, a rubber band, the camera and its cord, the 8ball in its lego cradle, the IR tranceiver, the Lego RCX controller, my keyboard cable, the top of a tiny Boston Acoustics speaker, the power supply of an Apple Studio Display, Patty Larkin's Angels Running CD, and the base of the lamp.
Everything in the picture is outstanding, except for the rabbit ears which stink, the camera which was real cheap at our local surplus electronics store, and the lamp which is unremarkable.

And yes, that is representative of my entire office.

How It Doesn't Work

Originally I had planned to write a continuous realtime animated gif so that the 8ball would run on any browser. Unfortunately Unisys would sue me for that since only Unisys and their licensees are permitted to create GIFs in the United States, Canada, France, Italy, Germany, Japan, and the UK. JPEG is much faster anyway, 30kbit per frame in JPEG as opposed to 100kbit per frame in GIF.

IE hasn't gotten around to multipart/x-mixed-replace support yet, so you should use Netscape to view the 8ball if you swing both ways. I waited a year and a half for Microsoft's legions of programmers to get around to implementing x-mixed-replace, but I finally gave up and implemented a Javascript abomination to do the job.

They make it hard. The 8ball needs to communicate state changes to direct the rate of image loading. Various IE versions violate the Javascript spec in different amusing ways. I finally found one mechanism that works on all known current versions that lets me send 1 bit of state change. It involves delete images out from under the browser and catching the debris with an onerror handler.

Other things I've tried in the long unhappy path to IE Windows support...

Just Plain Neat Things

I limit the buffering in the program and OS so the frame generation rate is guided by your comm link. The digitizing rate automatically adapts to your speeds without me writing code. Unwritten code is always the best.

I send the frames at low quality except for the final frame, which is sent at a medium quality. You get 30% faster frame rates during motion but still get a reasonably nice picture in the end. update: Its even neater now. I send reduced resolution images during the ball spinning portion then progressively increase the quality as the image stabilizes.

It only takes about 10% of my PII-266 to run this thing.

Everyone gets their own destiny. If someone is using the 8ball you will be queued and get an image showing your position in the queue. This is actually some of the trickiest code involving semaphores, shared memory segments, signals, and forking. Yes, there is still a tiny race condition related to number assignment, but I can live with that. Its just possible that two people might get the same number. They still get handled in order and get a unique destiny.

How has it Failed?

You can watch of movie of the ball dispencing mysticism if you like. (2MBytes MPEG-4 file. It is typed as quicktime since windows falls on its nose if you tell it MPEG-4).

Back to the Public 8 Ball