L8DE_Desktop Robotics

DESKTOPROBOTICS Research and development of desktop robotics for architectural design purpose.

Contents Muhammad Zharif Rafiq Bin Rozlan Scott Wang Andrea Plebani Slow Robotics 2015, RMIT Masters Electives

1__ Introduction 1.a__ Desktop Robotic Research 1.b__ Architectural Hypothesis 1.c__ Software & Hardware Examples

__Assemblies and Calibration

__Reference Assemblies & Kinematics

__Compensation and Speed

2__ Refinement

__Design Revisions

3__ Implementation

__ Toolpath Writting test

__ Follow the Mouse

__ Painting Elvis

__ Spiral Movement Test

__ Gesture Movement

4__ Appendix

__ Processing Definitions

Right. Elvis Robotic Arm, Source: arcode.blogspot.com

1__ Introduction Desktop Robotics is a project of small scale programmable mechanical arm. The project aims to study their capability and limitation to be develop towards a better task performance for design. The Elvis Robotic Arm were use for the project and we went through a process of understanding the hardware and software, assemblies, movement and accuracy test, revisions and improvement of the arm design and finally the application of the robot with different software tools .

Elvis is an open source 6-axis robotic arm the size of a human arm, built from simple electronics part and laser cut acrylic pieces, and is directly driven from Rhinoceros and Grasshopper. Design and developed

by Suryansh Chandra, Elvis files can be download from it’s official website page [arcode.blogspot.com]. The provided Rhino and Grasshopper files contains a sophisticated model of Elvis as well as the kinematics definition with three different preset commands. The project target to input commands from processing into the grasshopper file to carry out a more autonomous task

The architectural purpose of this project is to control Elvis arm to act as a physcical simulator for the 6-axis Kuka robot we have in RMIT. The advantages of Elvis is the small size and light parts making it portable and more accessable. In this particular project, we focuses on getting Elvis to follow a point generated from processing to draw on 2d plane.

The project achieved its target when we were able to control Elvis to follow the processing input with an improvement of accuracy towards the end of the semester. We’ve done a significant changes in strengthening the assemblies to improve its movements. We’re able to allow Elvis to be use by other group to test their script.

The main drawbacks that we were facing was the usage of laser cutted acrylics arm parts that creates small gaps and loose connections contributes to the low accuracy movements. Also, the limitations of the servos used tend to overheat over a series of movement task. This impose that Elvis will be unable to run for a long time unless a cooling system is introduce.

A part of the project that was unpredictable is when Elvis were drawing a different toolpath from the processing input because it was unable to catch-up to the input speed points forcing Elvis to skip a certain part of the toolpath. Thus we synchronize the speed between Elvis and the processing input points for it to follow. As expected, working with a slower speed for both produce a better result of the output drawings.

The project can be extended by experimenting more in sending a more complex task to Elvis from processing using different script.

Some of the possibilities that can be done would be doing a longer writing or drawing task and 3D fabrication with 3D printer pen as an end-effector. A continuation from the collaboration with the scanning group to add a scanner to Elvis so it would able to response to the scanned objects. These would be possible by redesigning the arm design using less mechanical parts as well as improving the inverse kinematics algorithm in the grasshopper to allow a more smoother point-to-point movement of Elvis.

A

B

C

D

E

F

KEY: A_6 DOF Robotic Arm [http://tiny.cc/f7bv4x], B_MeArm Robotics [http://blog.mearm.io/], C_DAGU 5DOF robotic arm [http://tiny.cc/9ccv4x], D_Dobot [http://dobot.cc/], E_7Bot [http://7bot.cc/], F_OWI-535 [http://tiny.cc/xjcv4x] Below. Hotwire foam cutting Stack It workshop with Robots in Architecture with Sigrid Brell-Cokcan and Johannes Braumann [http://architecturalrobotics.org/]

Desktop Robotics Research Robotics has been use for industrial level for years mass-producing products such as cars. And in recent years, application of robotics in architecture has been even more interesting from robot making bridges to houses. At the same time, as technology being more accessable, personal or desktop tools such as 3D-printers, laser cutters and a CNC machines are getting affordable and buildable at home.

Desktop robotics arm are one of the desktop tools that constantly being develop.

Some of the significant desktop robotic arm that are in the market are the 6 DOF Robotic Arm [A], MeArm [B], Dagu 5DOF [C], Dobot [D], 7Bot[E] and OWI-535. Each with different number of axis, accuracy, design, capabilities and limitations.

The MeArm, DAGU 5DOF, Dobot and Owi-535 are not suitable for this project because of it low number of axis.

Giving limitations in certain movement directions as well it wont be able to simulate the KUKA very well.

The 6DOF robotic arm would be limited in it reach as the arm length is only 320mm. Thus, it is not suitable.

The 7Bot appears to be one of the best desktop robotics for its accuracy and design. The usage of alluminium and small figure seems to be contribute to its great accuracy. In addition, the design with 6-axis is similar with the KUKA would help to be a better simulator.

However unlike Elvis, these other desktop robotics are avaiable to be purchase and ready-to-assemble.

Thus limit us to understand and develop the robot as the end-user.

Thus, Elvis would be the ideal robotic arm for this project. It’s open source file provides a laser cutting file that we would be able to experiment with different material and changes the design.

Left. Robotic assembly line illustration with each robotic arm spesific task. [http://tiny.cc/1snw4x] Below Key: A_Foam hotwire cutting B_Gesture control C_Drawing or writing function D_Printing pen function

ArchitecturalHypothesis With the 6 degree of freedom in a robotic arm implies a high flexibility in movement and the end-effector allow different tool can be attached and run different task. We’ve looked at some robotic function task for Elvis to carry out.

The task that we chose to run was task C. We would like to run this task as the first step to simulate the accuracy of Elvis to follow a path or point.

The task were done in two different complexity for each toolpath and point follow. For the toolpath task, The four task represent a different sending a curve from Rhino to grassaspects of the robot capabilities. hopper as a tool path. The curve will Task A would test the robot ability to be divided into several point planes manipulate an object. For example, for Elvis to move from point-to-point. attaching a hotwire cutter at the end This would test Elvis ability to follow effector to cut foam. Manipulating a complex toolpath. The toolpath the foam to fabricate a certain output can either be a text spelling “Hello� or form. just a drawing of a circle. The second follow point task, would be to send Task B would be to test the robot abil- a point coordinate from processing ity to response to a feedback. Using into Elvis workspace for elvis to move sensors such as camera or motion towards the referenced point. Testing detector to control the robot moveElvis to follow a moving target point. ment.

These writing task would allow us to Task C is to test the robot ability to compare the resulted drawing with follow a toolpath or follow a moving the sent path. See how Elvis stability point on a 2D canvas. Testing whether in moving from point to point or chasthe robot would be able to produce ing after a point plane. an accurate drawing output.

Task D is to test the robot ability to fabricate in a 3D space. Using tools such as a 3D printer pen to extrude plastic in different directions.

A

B

C

D

Right. Arduino Mega 2560, Source: http://tiny.cc/49zw4x

Software/Hardware Description & Examples Desktop Robotics involve a series of software and hardware usage to control a robot. As Rhino and Grasshopper has been the main software to drive Elvis, processing are used to send a more autonomous point movements into Elvis.

Alongside understanding the processing languange, we are working in software with the similar languange such as eclipse for an ease for collaboration between teams as well as Arduino software to learn how we could use it to manage the robot.

The first proccess of understanding that we have done with Arduino was to light up some LED on the Arduino Mega 2560. At this point we are learning how servo movement works and how to use the code to program Arduino, playing around with the software and see how it responds. Then we started with a simple cheap servo. Testing simple sweep command and tweaking the command.

As for the hardware, a couple of electronics parts, fixings and mechanical parts were ordered online. The main electronic parts are

Figure 1. Simple connection between Arduino Mega 2560 and a servo.

Elvis is being drive by 8 Dynamixel AX12A servos. Two servos each to drive the first two axis as they are carrying the heaviest load of the whole arm, and four more to drive the other 4 axis.

the USB 2.0 Dynamixel that would allow us to directly send command to the servos and the SMPS2Dynamixel as the power supply adapter.[below]

The assembly of the robot started by using acrylic. Drawbacks on using acrylics are that it create loose connections between the slits causing the robot unable to stand and have a strong grip between each part. This reduce the stability and durability of its movement.

A

B

C

E

F

D

KEY: A_Laser cutting process of the arm parts, B_Assemblies of the parts, C_Connection of servos to Dynamixel USB, D_The overall loop connection from the first servo to the eigth servo, E_Roboplus Software [http://www.robotis.com], F_Dynamixel Wizard.

Below. Dynamixel Wizard calibration proccess[http://tiny. cc/r55w4x]

Assemblies and Calibration Finalizing the assembly by applying super glue to hold the main bearing bracket and fixing the gears together using timing belt. Adjusting the screw fixing between the arm and the servos to ensure the strong grip and connecting the servos via jump wires.

Each servos are calibrated to return to zero positions. Calibrating each servos to zero are important to ensure directional control over the servos by knowing how much it can rotate and move, control accuracy and avoid any broken servos.

Calibration process of the servos are being done using Roboplus software.

It gave a direct control of each of the servos to manually rotate its position.

It will also detect the current position of each servos. In the process, each servos are set to zero position and given a labelled from 1 to 8 by each respective position starting from the base up to the end-effector. Dynamixel servos Ax-12A offers two input pin which allows the servos to be directly connected to its neighboring servos.

In the calibration process, servos number 5 was read as an unknown servos while servos number 3 were unable to read at all. Thus the solution

for this issue was using the firmware recovery with Roboplus and recalibration process are being done again for each of the servos. Once each of the servos are well connected and calibrated with each respective ID number, Elvis are ready to be connected to the Elvis_MissionControl_1.0 rhino/ grasshopper file to control Elvis.

Reference Assemblies & Kinematics 5. Finally, double-click the “Q” C#Script to change the port number to the port number used by your USB Dynamixel.

A Once the provided Rhino and Grasshopper file are open, an error will occur indicating the failure of loading a Reference Assemblies for the C# Script component.

Following are the steps to resolve the assemblies issues: 1. Download the Dynamixel SDK version 1 according the computer system.

2. Right-click on the C#Script component to open the “Manage Assemblies” option 3. Load each assemblies into each C#Script 4. If the assemblies are still undetected, then unblock each of the dll. files.

C

B

E

Kinematics Definitions end-effector

Within the Elvis.IO C#Script is the kinematics definition of Elvis. The main script that define the movement of Elvis by calculating and providing command sets towards each servos to how much should it rotate to reach the end-effector position.

This definitions has both forward kinematics and inverse kinematics equations. The forward kinematics means that inputing a spesific task to spesific servos(link) to rotate at certain rotation angle. This would then affect the end-effector position.

This allow Elvis to be control by axis.

For example rotating axis 1 at positive 30 degree. This definition are set as one of the preset command under perAxis command.

On the other hand, the inverse kinematics is the opposite of forward kinematics. By providing the endeffector position, the robot will calculate the best solution to reach the end-effector position. It’s a more difficult and complex proccess as it would create redundancies of movement. However, as the defintions are already being resolve

link link fix by the developer within this script to work sophisticatedly. This is applied in most of the task command and the the preset command as the planeFollow and toolPath command.

D

The output of the script is the current position of each of the servos with each respective ID number.

Right. Elvis range and workspace. Source: arcode.blogspot. com Below. C#Script component for Elvis.IO kinematics

Compensation and Speed Compensation and Speed The compensation of Elvis home position and speed of its movement can be adjustable within the Elvis.IO definitions.

The compensation of axis 2 and 3 are important to be adjustable to get a right angle position in the home position. This would be easier to clibrate than to reessemble elvis to reach zero position.

The static set speeds represent the speeds of each respective servos.

As the first two servos are driving the same axis, thus the same speed number. Similarly to the third and forth servo speed to run axis 2.

Technical Details DOF/Axis: 6 Motors: 8 x Servos, Dynamixel AX-12A Range: ~525mm for wrist Centre (diagram below explains in detail) Cost: ÂŁ480 (UK). Presumably cheaper in the US/Asia. Detailed breakdown here.

IK Solver: Trigonometric Wrist Type: Spherical

Right. Elvis Robotic Arm, Source: arcode.blogspot.com

2__ Refinement Every physical component of Elvis underwent rigorous calibration and revisions in order to improve stability and increase accuracy of its movement. Straight off the GitHub, the design of hardware poses various critical issues such as insecure timing belt connections, constant backlash motion, and loose component contacts. The use of adhesives to secure the components will compromise the complete disassemblility and upgradability

of the hardware, thus it is avoided.

Without the aid of adhesives, the top portion of Elvis (above the second axis) has the tendency of falling out of the Revolving Deck, and the Motor Housing detaching from the base. Our approach is to implement interlocking joints and removable locking systems.

Catch the Timing Belt Our first hardware revision was to enhance the effectiveness of the

timing belt driving Axis 3. We went through multiple design iterations in search for the best solution that would deliver maximum grip and minimum friction. Initially, Velcro Strap was used hoping to reduce the belt length by pinching it at the midpoint. The strap caused too much friction against the belt which introduced minor recoils to the motion of Axis 3. Our second iteration includes inserting a large diameter rotating gear at the midpoint

to stretch the belt. This iteration isn’t capable of preforming long operations as the different sized gear disrupts the movement. Our third iteration offers the best result where the distance between Axis 3 and Servo #5 was increased.

Anchor of the forearm When Elvis is in motion, the anchoring connection between the revolving deck and the forearm portion (above Axis 2) depends on slot joint which without adhesives can be extremely unsteady. In fully extended position, the heavy weight of the forearm induces large amounts of torque towards the anchoring connection, without adhesives the slot joints tears apart. Our first design iteration is creating a bracket system that would clamp the Forearm and grip around Axis-3. This implementation works well under low acceleration movements. Rapid fluxes of movement cause the acrylic material of bracket to bend and fail. In our second iteration we opted for metal angle brackets, bolts and nuts in order to maximise rigidity. This option allowed us to fine tune the tightness of the anchoring connection while

maintaining disassemblility of Elvis.

The outcome of this revision gave the forearm a solid foundation, vastly enhanced Elvis’ overall stability and accuracy.

Below. Lateral displacement changes Right. The black box

THIRD FIXTURE IS ADDING ANOTHER LAYER ACRYLIC TO SECURE THE UPPER ARM AND THE REVOLVING DECK. (3)

SECOND FIXTURE IS ADDING A BRACKET TO SECURE THE CONNECTION BETWEEN THE REVOLVING DECK PARTS. (2)

THE FIRST LATERAL DISPLACEMENT WERE FIXED BY REFERRING THE ORIGINAL DESIGN OF ELVIS ADDING ANOTHER LAYER OF ACRYLIC AS TO CAP THE BEARING. (1)

Damp the lateral movement The focus of this revision is on reducing the excessive lateral movement of the arm caused during heavy operation of Axis 1 and 2. To eliminate the tendency of uplift, we’ve modified the housing for the revolving bearing by replacing the compression contact with the sandwiching system. Furthermore, an additional acrylic plate is placed tightly enclosing the forearm and the gear blades of Axis 2 to further improve the stability of Elvis. With these implementations, Elvis’s pick-up point isn’t limited to the base plate, but anywhere along the body.

Calm the Heat The servos responsible for driving Axis 2 and 3 carries the most load in the entire system. Under ambient temperature these servos tends to overheat after several minutes of operation. The overheating of servo# 5 occurs when the forearm is stationary in zero position for more than 2 minutes. The double servos for Axis 2 tend to overheat after 2-4 minutes of continuous operation.

Unfortunately, overheating is a known issue for these AX-12A Dynamixels servos. However there are ways of prolonging its overheating window.

The unsafe option (voids warranty) is to perforate the bottom part of the plastic casing, allowing for faster heat dissipation. We opted for using a desktop fan inducing airflow directly towards Axis 2 and 3. The additional airflow has drastically extended the operation time of Elvis to 6-10 minutes.

Introducing the Black Box The calibration process tend to be a challenge we are facing every time we reassemble Elvis due to the multiple parts being taken down and stored in a small box with other tools, and the movement of the box itself would disrupt the previous calibration. Plus, the heavy upper arm part require a stronger base to hold Elvis down during movement test. All of these minor incompletion contributes to the accuracy default. Thus, I’m introducing the Black Box as the working space for Elvis.

The black box is a mock-up cardboard box acts as a heavy base with a

drawer to store all the tools as well as to hold Elvis down without needing to clamp to a table allowing Elvis more mobility as a desktop robot. This is also avoid the re-calibration process each time we’re working on the robot.

Left. Elvis writting task Below Key: A_First Test B_Final Test

3__Implimentations Tool Path Writing Test After each hardware improvement we used it to conduct a series of writing tasks using the Tool Path preset command in MissionControl with the aim to measure the accuracy of Elvis’s movement. The test requires a setup of a paper base a permanent marker as an end-effector. The calibration process involves the positioning of the tool path in Rhino space, ensuring optimum contact between the endeffector and the paper base.

The tool path of the first test is the drawing of a circle. To test accuracy the circle was drawn multiple times.

The second test was done to test Elvis capability to follow complex tool path. Elvis’s motions are directed by a point to point basis when following the set tool path in Rhino space. Thus, the resolution of the tool path directly impacts on the legibility of the writing. For our test the low number of division point plane resulted in rough outcomes. A third test using a higher value of point plane on the tool path produced higher accuracy writing.

However, there are a few areas that were missed due to uneven base surface. Our fourth ‘hello’ writing test was

successful. It involved iterative calibration of the drawing base orientation, tool path positioning and speed of operation.

A

B

Right. Follow mouse resulted drawings Below: Drawn path on processing and the proccess screenshot

Follow the Mouse The point-to-point planes toolpath preset command in grasshopper limits the accuracy of Elvis following a path. Using a follow plane present command allows Elvis to glide in a much more fluid motion. However manually moving the point plane in Rhino space would be inconvenient.

Thus, we opted for an UDP workflow where processing would send point plane directly to MissionControl driving Elvis. Using follow the mouse function in Processing, Elvis is able to move in the X and Y direction based on the location of the mouse. A series of scribbling test were done to test its accuracy and stability.

The spiral movement test works with each respective slower servos speed, from {75,75,63,63,75,127,255,255} to {20,20,10,10,20,30,50,50}. This has significant improves the accuracy but reduce it limit to maximum 0f 5 minutes run as servo 3 and 4 will overheat. The three tests done were circular spiral, square spiral and rectangular spiral. The outcome displays higher accuracy and clearer legibility.

Left. Elvis bouncing ball painting task Below Key: A_Swarming sketch B_Bouncing ball sketch

Painting Elvis This test involves using water colour and paint brush to produce the output. The reason for the paintbrush is to test the different pressure of the end-effector applied to the drawing plane. This also allows us to examine Elvis’ XY movement levelling.

The first step in the test is getting the workspace as accurate as possible between processing void, rhino/ grasshopper space, and the physical workspace.The next step is testing the speeds of both, the agent behaviours in processing and Elvis servos speed.

Swarming sketch agent is a point affected by the neighbouring agents that would affect its trajectory/behavior. However this sketch generates several failed result; lagging in software, jerky elvis movement and Elvis stop moving. Thus, we moved to another simplified sketch which is the bouncing ball.

In this test, we use the edge of the canvas as the paint sources so that Elvis will mix the different colors with the bouncing ball sketch. Also, the three main boundaries of canvas; blue on the right of Elvis, Red opposite of Elvis and Yellow on the left side, helps to detect the skidding in Axis-1

A

B

Right. Spiral point movement drawings Below: Drawing proccess screenshot

Spiral Movement Test This test we focuses on applying an outonomous point coordinate in processing to lead the movement of Elvis. Using a simple sketch that creates an outward spiral movements to test Elvis accuracy to draw. The difference between this test and the writing test was that this test keep a constant speed generated in processing. Thus a constant variable in speed would us to focus on Elvis drawing accuracy.

In addition a slow speed were set for the test to reduce any aditional inertia occurs from point to point movements.

Figure shows the overlay comparison between the resulted drawing and the spiral agent.

Left. Elvis following average gesture movement Below: Web Camera used to scan the average movement

Gesture Movement We also did a test with the scanning group with a sketch using a laptop webcam. Elvis works fine with their sketch based on average movement scan. But this resulted in a jittery movement of Elvis. This is because of the sketch is scanning multiple movement at once thus produce a constant average movement.

4__ Appendix Processing Definitions

background(0); stroke(0);

Swarm Definitions

}

import toxi.geom.*; import hypermedia.net.*;

String locList = “”; for (int i = 0; i < agents.size (); i++) { agent a = (agent) agents.get(i); a.update(); a.render(); agent b = (agent) agents.get(0); Vec3D p = b.pos; Vec3D v = b.vel;

UDP udps; ArrayList agents; void setup() { background(0); size(297, 210); frameRate(20);

//println(p); locList = locList + String.valueOf(p.x) + “,” + String. valueOf(p.y*-1) + “;”;

udps = new UDP (this, 6000); } agents = new ArrayList(); for (int i = 0; i < 1000; i++) { Vec3D p = new Vec3D(random(0, width), random(0, height), 0); Vec3D v = new Vec3D(random(-5, 5), random(-5, 5), 0); agent a = new agent(p, v, 5); agents.add(a); }

String message = locList; String ip = “127.0.0.1”; int port = 6500; udps.send (message, ip, port); locList = “”;

}

}

void draw() { noStroke(); if (mousePressed == true) {

class agent { // parameters

Vec3D pos; // where the agent is Vec3D vel; // velocity float rangeOfVis; // how far it can see float maxVel; // float maxForce; // how fast it can turn int sz; // render size float avgVel; // constructor agent(Vec3D p, Vec3D v, int s) { pos = p; vel = v; sz = s; rangeOfVis = 30; maxVel = 1.8; maxForce = 1.5; } // behaviors void update() { // call functions Vec3D ali = alignment(); // add to vel vel.addSelf(ali); // limit vel vel.limit(maxVel); // position = position + velocity pos = pos.add(vel); if ( (pos.y > height) || (pos.y < 0) || (pos.x > width) || (pos.x < 0)) { // invert the vel vel.invert();

} } Vec3D alignment() { Vec3D sum = new Vec3D(); int count = 0; // loop through all the agents for (int i = 0; i < agents.size (); i++) { // for each agent get the distance from this agent to that agent agent a = (agent) agents.get(i); float d = pos.distanceTo(a.pos); // if distance < range Of Vision if (d < rangeOfVis) { // get other agentâ&#x20AC;&#x2122;s vel and sum sum.addSelf(a.vel); count++; //count = count + 1; } }

// find the average vel (sum * 1/ count) sum.scaleSelf(1/(float)count); sum.limit(maxForce); // return the average return sum; } float Dist() { float d = 0; for (int i = 0; i < agents.size (); i++) { agent a = (agent) agents.get(i); float Distance = pos.distanceTo(a.

pos); d = 1 - Distance; } return d; } void render() { float d = Dist(); float red = d + 300; float green = 20; float blue = 100; //float SZ = ((red/20) + sz); fill(red, green, blue); agent c = (agent) agents.get(0); float px = c.pos.x; float py = c.pos.y; ellipse(px, py, sz, sz); //ellipse(pos.x, pos.y, sz, sz);

}

}

//println (Dist()); //println(red);

Follow Mouse Definitions import toxi.geom.*; import hypermedia.net.*; UDP udps; //import oscP5.*; //import netP5.*; //OscP5 oscP5; final int nX=1; //array length at X final int nY=1; //array length at Y PVector [][] myArray=new PVector[nX] [nY];

//NetAddress myBroadcastLocation; //OscMessage arrayMsg = new OscMessage(“/array”); // “/array” is an arbitrary header/filter that the //message will be delivered with. //you can create multiple of these OscMessage variables with different filters to push streams of //different data to GH void setup() { size(600,300);

udps = new UDP (this, 6000); smooth(); background(0); //oscP5 = new OscP5(this, 6882); // myBroadcastLocation = new NetAddress(“localhost”, 6881); // broadcast to port 6881 and //receive at 6882 /use the opposite for GH //the numbers “6881” and “6882” are arbitrary. //”localhost” is for sending to my own PC. To send over ethernet or other devices you have to enter //an IP number. for (int i=0;i<nX;i++) { //fill in the array //in this case with random numbers for (int j=0;j<nY;j++) { //myArray[i][j]=new PVector(random(i*400, (i+1)*400), random(j*400, (j+1)*400)); myArray[i][j]=new PVector(mouseX, -mouseY); } } } void draw() {

String locList = “”; //String toSend=””; //create a new string to assemble the message // arrayMsg=new OscMessage(“/ array”); for (int i=0;i<nX;i++) { for (int j=0;j<nY;j++) { //Display array points in Processing pushMatrix(); //to actually compare the prossecing display window with grasshopper we //have to change the coordinate system of processing so as the positive Y values are //upwards. This is done by translate and scale(1,-1) (something like mirror) translate(0,0); scale(1,-1); stroke(255); ellipse(myArray[i][j].x, myArray[i] [j].y, 1, 1); line(width/2,0,width/2,-width/2); // draw X and Y axis //line(0,0,width,0); popMatrix(); //now assemble the message to send in a string //toSend+=”{“; //toSend+=myArray[i][j].x + “,”;

//toSend+=myArray[i][j].y + “,”; //toSend+=myArray[i][j].z + “}”; //this assembles “{x,y,z)” : a “Grasshopper ready” point //if (j<nY) toSend+=”*”; //this places a “*” between points of the same row } //if (i<nX) toSend+=”&”; //this places a “&” between points of different columns } locList = locList + String. valueOf(mouseX) + “,” + String. valueOf(mouseY) + “;”; String message = locList; String ip = “127.0.0.1”; int port = 6500; udps.send (message, ip, port); locList = “”; //arrayMsg.add(toSend); //this loads the string to the message container prior to sending // you can actually load(add) many strings/values before sending them.

The OSC library //separates these values with commas. Thats why in this example we “devised” this trick with

//with * and & to send the whole array as a single string, everytime the “void draw” runs, //and separate the array into rows and columns in Grasshopper. //The way we did this was to assemble “Grasshopper-ready” points: {x,y,z} //in the case of a 3x3 array, the string will be something like this: // {0,0,0}*{1,0,0)*{2,0,0}&{0,1,0}*{1,1,0) *{2,1,0}&{0,2,0}*{1,2,0)*{2,2,0} //which in grasshopper we will read more or less like this: //{0,0,0},{1,0,0),{2,0,0} //{0,1,0},{1,1,0),{2,1,0} //{0,2,0},{1,2,0),{2,2,0} // oscP5.send(arrayMsg, myBroadcastLocation); //this is the actual command that sends //the message } void keyPressed() { //this is to check refresh rate. press a key to reset array values for (int i=0;i<nX;i++) { for (int j=0;j<nY;j++) { //myArray[i][j].set(random(i*400, (i+1)*400), random(j*400, (j+1)*400), 0);

myArray[i][j].set(mouseX, -mouseY, 0); } } }

Bouncing Ball Definitions

void draw(){

import toxi.geom.*; import hypermedia.net.*; UDP udps; //Using ArrayList Normal //DECLARE ArrayList ballCollection;

//CALL FUNCTIONALITY for (int i = 0; i < 1; i++){ Ball myBall = (Ball) ballCollection. get(i); myBall.run();

void setup(){ background(0); size(297, 210); smooth(); frameRate(10);

//float posx = x; //float posy = y;

udps = new UDP (this, 6000); //INITIALIZE ballCollection = new ArrayList(); for (int i = 0; i < 1; i++){ Ball myBall = new Ball(random(0,widt h),random(0,100)); ballCollection.add(myBall); } }

class Ball{ float x = 0; float y = 0; float speedX = 2; float speedY = 1;

}

}

Ball(float _x, float _y){

}

x = _x; y = _y;

void run(){ display(); move(); bounce(); send(); gravity(); } void gravity(){ if (mousePressed == true) { speedY += 0.05; } else{ speedY += 0; } }

void bounce(){ if(x > width){ speedX = speedX * -1; } if(x < 0){ speedX = speedX * -1; } if(y > height){ speedY = speedY * -1; } if(y < 0){ speedY = speedY * -1; } } void move(){ x += speedX; y += speedY; }

String ip = “127.0.0.1”; int port = 6500; udps.send (message, ip, port); locList = “”;

}

}

Spiral Definitions import toxi.geom.*; import hypermedia.net.*;

String locList = “”; x = r * cos(theta); y = r * sin(theta); fill(255); ellipse(x +width/2,y+height/2,4,4); theta+=0.05; r+=0.05;

UDP udps;

if(r >width){

float r, theta,x,y;

r = 0; }

void setup(){

void display(){ ellipse(x,y,5,5); }

size(297,210); frameRate(10); udps = new UDP (this, 6000);

void send(){ String locList = “”;

r = 0.0; theta = 0.0;

locList = locList + String.valueOf(x) + “,” + String.valueOf(y*-1) + “;”;

smooth(); }

String message = locList;

void draw(){ background(0);

locList = locList + String.valueOf(x) + “,” + String.valueOf(y) + “;”; String message = locList; String ip = “127.0.0.1”; int port = 6500; udps.send (message, ip, port); locList = “”; }