= 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? <> == 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: 1. Client/server, with centralized control at the server side. 1. 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: 1. The number of dancers; 1. The (abstract) movements of each dancer along a timeline. Some other requirements: 1. To further simplify the system, when positions of the dancers are filled out, no more dancers are allowed to join. 1. 4 dancers maximum. 1. 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 [[http://wiki.id.tue.nl/creapro/SoftwareEnvironment|here]]. * [[http://wiki.id.tue.nl/creapro/AdMoVeoInProcessing|Documentation and example]] for controlling the AdMoVeo robot For client/server communication * [[http://processing.org/reference/libraries/net/index.html|Processing Network Library]] For peer to peer communication * JXTA library [[attachment:jxta.jar]] in \libraries\jxta\library. * Extract files in [[attachment:MulticastMessaging.zip]] in . For messages, you might want to format them in XML: * You can use [[http://processing.org/reference/XMLElement.html|XMLElement]] in Processing to parse the XML messages. Website: * [[https://jxta.dev.java.net/|JXTA]] * [[http://processing.org/|Processing]] * [[http://www.arduino.cc/en/Main/Software|Arduino software]] * [[http://wiki.id.tue.nl/creapro|Creative Programing assignment]] * [[http://en.wikipedia.org/wiki/Distributed_computing|WikiPedia: Distributed computing]]