Distributed Creative Dance

dichotomy: Process/Product; Centralized/Distributed control
What shall we focus on? The process of creating the dance together or the result of it? What are the (dis)advantages of (De)centralized systems? How would it impact on the system design?

Contents

Distributed Creative Dance

Program

To make it feasible in a one day workshop, we will not be dancing with music, but scripts. Also to limit our creativity at the technological side, we will be thinking in terms of two different types of distributed systems:

Client/server, with centralized control at the server side.
Peer-to-peer, with decentralized control, or, let’s say, without control.

In type 1 systems, dancers will be following the instructions from the server, and the server interprets the script and directs the dance.

In type 2 systems, a robot initiates dance by following a homebrew private dance script. Other robots join the dance by requiring the script from the robots that are already dancing together. Any robot can initiate a dance. Anyone can join and leave at anytime.

In both types of the systems, to simplify the situations, a dance script shall define:

The number of dancers;
The (abstract) movements of each dancer along a timeline.

Some other requirements:

To further simplify the system, when positions of the dancers are filled out, no more dancers are allowed to join.
4 dancers maximum.
A dancer improvises and performs the abstract movements in his/her own style.

Teams

25 divided into 5 teams, team 1-5.
Team 1 is the mini ISO. It is the organization that develops, publishes and refines the standards (the script, the messages).
Team 2 and 3 will be working on the type 1 system. Team 2 develops the server, and team 3 develops the clients (4 robots).
Team 4 and 5 will be working on the type 2 system. Each implements 2 peers. In total 4 peers will be dancing together.

Schedule

(may change, depending on the progress)

9:00-10:00: Presentation/Hands-on: explanations and tool-kits.
10:00-12:00: Team 1 collects the requirements from Team 2-5, and develops the specification of the dance script and the messaging protocol. Team 2-5 start experimenting with the tool kits. Team 1 distributes its version 1 standards to other teams.
12:00-14:00: First round implementations. Team 1 tracks the activities and collects the feedback about its version 1 standard. Team 1 Improves the standard and distributes its version 2 standard. Version 2 shall be backward compatible with version 1, to minimize the impact on other teams’ work.
14:00-16:30: Second round implementations. Version 2 standards shall be implemented. Team 1 repeats its work and improves its standard to version 3 as the final deliverable.
16:30-17:30: Final show: dancing with robots. Reflections.

Knowledge/skills required

Processing or/and Java
Arduino

References and Materials

Software environment (Processing+Arduino):

Follow carefully the instructions here.
Documentation and example for controlling the AdMoVeo robot

For client/server communication

Processing Network Library

For peer to peer communication

JXTA library jxta.jar in <your sketchbook location>\libraries\jxta\library.
Extract files in MulticastMessaging.zip in <your sketchbook location>.

For messages, you might want to format them in XML:

You can use XMLElement in Processing to parse the XML messages.

Website: