how the ArtBus idea came to be

In the Summer of 2006, I was briefly involved with the planning of  a large interactive installation art project which was to employ various sensors and control points. These electronic elements were to be distributed along a narrow, but 100 foot long space and and connected to a central computer running Max/MSP. This required various analog sensors to be read, and various lines to be turned on an off at different times. Initially, an Ezio or Arduino style I/O board seemed to be the right interface. On closer examination it was realized that using those types of breakout board systems, there would not be enough of the right kind of I/O available on the interface boards, and the wire lengths made sending fragile sensor voltages or serial control data very awkward. Additionally, one of the devices being considered for use in multiples in the installation was a hacked MP3 player (needing specific pulsed commands to cue and play) which would have required more control intelligence close-by than the long-wires with Arduino model could provide. This set of problems created the context for designing a very minimal protocol and hardware layer that could be used as the basis for connecting many kinds of specialized I/O devices to a host controller over a single wire pair.

The first device made to test the bus concept was a hacked MP3 player. It was a silly place to start because it mixed two sets of unknowns into one problem set, but since it works, it really helps make the point about specialization in device function. Heinliein said "Specialization is for insects." Since the purpose of the ArtBus is to enable connection of specialized but disparate I/O, sensing, data, and devices, it is appropriate to refer to the individual devices as "bugs" [see note below]*. What makes an ArtBus bug* what it is, is that the commands and bit-twiddling needed to operate a specific sensor or actuator are wrapped in an ArtBus command. A local MCU attached to the raw device or devices in question operates the sensor or actuator and returns requested data back to the bus master. This "wrapping" makes all ArtBus messaging look as alike as possible on all platforms and devices, and allows any ArtBus bug* to coexist on the same communications wire and in the same host development environment no matter what its function.

Devices prone to being made into bugs* include sonar rangers, motor controllers, realtime clock-calendars, lamp dimmers, motion sensors, RFID readers, GPS receivers, Bluetooth radios, Zigbee modems, accelerometers, servo controllers, LED drivers, MP3 players, proximity sensors, and so on.

The controller design that came out of the 2006 explorations worked well  with some multimedia and control systems, but not with others. It seemed that Max/MSP would be the toughest nut to crack in terms of a smoothly running system, so what better place to start? 

Robb Drinkwater and I set out to find a way to get Max to play nice with real-world hardware in real time. The idea of the mediator program evolved as a stand alone type of bridge between Max and ArtBus. A good mediator was difficult to implement, but in the end successful enough to inspire Matt Nelson to try making one for Adobe Flash .

Looking at the ArtBus as simply a way fo connecting multimedia to sensors doesn't capture the whole picture. Any comupter or little controller as well as
Internet and Bluetooth through specialized adapters are an easy and obvious extension to the bus. For example, the bus master could be a bluetooth to serial adapter.

There are many experiments left to be done...

Happy Happy

-Ed

"sbennettSYMBOLsaicDOTTedu"

*edit july 08:

Although Bug Labs has been using the term "bug" since July 14, 2007, they now have a product in commerce which is identified by the name. Since Bug Labs seems to be fulfilling the requirements for earning a registed trademark, it seems wise for the ArtBus project to drop back to plan "B" and re-designate the term we use to identify our hardware devices. From July 08 we'll use the term "B" instead of "bug". Although this is plan B for a name for our devices, the name fits well because there's hardly a better example of specialized insects than bees. We've written a lot of stuff about ArtBus since 2006, and if there are un-noted references to bugs here or elsewhrere where they shoud be B's, please let us know so we can change them. -e