Conception and Design When my partner and I were first designing the outline to our project, we knew it had to be simple and easy to understand. Our audience was targeted at young kids so they would be able to learn and understand their native Chinese dialect. We tried to think about how young kids approached learning. From my own experience growing up, I personally remembered loving to make and build things. Whether was with blocks of wood or legos, it was fun for me. Inspired by this, we eventually we decided that a puzzle of China would be a suitable method to help kids understand both the geography and dialect culture at the same time. To make a puzzle, we used Tinkercad online to manually piece together Chinese provinces and then laser cut the file on a wood board. Because the pieces were going to be taken out of the puzzle many times, we wanted a sturdy material so we avoided cardboard. During the process we thought about 3-D printing the map, but because we wanted it to be roughly 15 inches by 15 inches, it wouldāve taken days to individually 3-D print separate parts and piece them together later. Below are pictures of the initial base surrounding the puzzle and also the puzzle pieces fitted into the base.
Base of the puzzle by itself
Base with puzzle pieces inside
Fabrication and Production In our initial plan, the puzzle was to be raised 3 inches off the ground and a motion sensor would be put under each province that we selected. It was meant to be a puzzle that one would put pieces into, but we changed it so that pieces would be taken out for the sake of the using sensors underneath. Simplified initial sketches of the design can be found below.
Sketch of the base
Sketch including proposed sensors below
But, when we attempted to raise the puzzle, all of the pieces fell to the ground because they were not fastened in tight enough by themselves. We shifted the idea and placed the puzzle flat onto a cardboard background. Alongside this, we created a map online through processing and arduino which displayed the same physical map. We connected a joystick so that participants would be able to hover over provinces and hear a whisper of the dialect, and thus be incentivized to then pick up the puzzle piece. Unfortunately during user testing, we were not able to connect any sensors to the physical map, so our project was only displayed through the online map. One of the tips was received was to make the joystick easier to use and control our character on screen. So, we changed the initial code to support diagonal movements on screen and improve the fluidity of movement. Another crucial tip we received was a way to involve the physical puzzle pieces of our map in correlation with the online map. Using this advice, we poked holes in the bottom of the cardboard base corresponding underneath each province we had a recording for. We used a wire to connect from Arduino to the map and placed conductive tape over the wire once it was stuck through so just the foil tip ways displayed. We then placed conductive copper tape on the selected puzzle pieces to ensure that the energy from our body would be transferred through the tape on the piece to the wiring below and back into Arduino. This method made it possible to play the native dialect of the province when that particular piece was touched. It was essential to our project and half of it wouldāve been incomplete without it. Because it was a last minute adjustment, many of the wires became tangled, but the attempt to beautify the project was our last priority at this design stage. Below are pictures of our project during user testing day.
Participants using the joystick
Conclusions The goal of my project was to create an educational experience focused on exposing audiences to different Chinese dialects from separate provinces. I think we accomplished this and more by sparking a discussion on how important preserving these dialects are in user testing and presentation days. Within the context of interaction, I think it aligned with my original definition that āInteraction is a continuous conversation between two or more corresponding elementsā because it was constant involvement either when using the puzzle, listening to the dialects, or controlling the joystick. The conversational element was representative when the participant would remove a puzzle piece and a dialect would play in response. This call and response constituted for me as a conversation between human and machine. Although, it may not necessarily be continuous because it only works when the participant picks up the puzzle piece. Thus, it isnāt interactive in the sense of a game where one is constantly playing. In our puzzle the subject is always thinking, but not necessarily interacting. Ultimately, our audience didnāt end up picking the pieces up, but rather just touching them. This was because they figured out that the sound would play as long as they touched it. It had the same educational effect as picking it up so this was just a minor diversion from our original intentions. When we concluded that it was not possible to use the light or motion sensors, I felt a sense of defeat. Through the help of professors and our classmates, we strayed from our comfort zone and used conductive tape, a material both my partner and I were not accustomed to working with. While it was indeed difficult to grasp at first, we became aware of the tapeās advantages and it eventually tied our entire project together. The main thing Iāve taken away from this project is that nothing is possible without the help and advice of those around you. Many of the notable alterations in structure came out of comments from our professors and classmates. For this, I am grateful to have such a unique community here at NYU Shanghai that is always willing to help and give feedback at almost any time of the day. Below is a picture of Kevin using our project on the final presentation day and also at the IMA fair.
I think a component of this project that made it so fun to work on is that our project ended up looking completely different from how we initially began working on it.
Original design for the physical component of the projectConcept design for how the sensors would recognize if you were sorting trash
When we first began working on this project, I started to design it coming from a robotics background. The original design incorporated elements that would involve numerous robotic processes and give this project a physical interface like an arcade game. There would be gears, buttons, and many other physical pieces that would all need to be created in order to make this interaction successful. Another element of the initial designs were that we would use chips (like tokens) and you would put a chip in the correct bin in order to “sort your trash”. As I was creating various design, Salome was giving feed back and she suggested that we use light sensors as a means to record how the user sorts his or her trash.
Once we agreed on using the light sensors, the design began to evolve. When starting to work on our final, I knew that I wanted to create a project that would have a practical, real-world use. When we were starting this project, I took reference to the current games that China has available to help people learn how to sort their trash. A popular version that I found included one that had four physical bins labelled according to the four sorting bins, and it had a deck of cards that contained images of items to sort. We were going to try and make four individual bins, but ended up just making the tops of each bins. This allowed us to save materials, conceal the wires and Arduino, and prevent extra variables that might have posed a problem with the user. For example, if we had physical bins with chips, how would we get the chips out of the bin at the end? This process would probably prove to be clunky for the user so we scrapped the idea of having the user use physical pieces.
We ended up having a physical component that mirrored what a user would actually be doing with a trash bin which is to open it. This proved to be logical, and the most straight-forward approach to this project.
Fabrication and Production:
In terms of the Ardunio, the process was fairly straight-forward. We created our circuit with 4 photo-light sensors. We did not required too many additional components and we were able to use the wires provided from the kit because they did not require extra length.
One of the main parts of our project included the cards. I used the Shanghai Government’s Trash Sorting poster as a reference, and I chose 40 items to make into cards. Some of the items that the poster offered I felt were repetitive, so not every object got a card. I used Photoshop and was able to cartoonize each card.
Stephanie creating the cards in Photoshop while Salome creates the circuit
I created the physical interface using Makerbox.com to generate a laser cut box. When I had this schematic in Illustrator, I was able to put in my own design features such as the bin openings, Arduino upload cable openings, laptop space, and the insides of the box which made the “bins”. Salome found trash bins online which were already 3D models, so we used those as our tops and we proceeded to cut the rest.
3D Trash Bin LinsLaser cutting our box and logosFinished laser cutsAssembly
The code was probably the most exciting part of the project!! We included various classes, for loops, if and while statements, and long nights of thinking! The basis of our code lies in boolean statements that were necessary in the first part to being the progression of the game. We originally were unsuccessful in our attempts to create a “intro sequence”. We went everywhere from if statements where it would read the sensor values, to switch cases, and then eventually to boolean statements at the suggestion of Eric. It was so rewarding and satisfying once we were able to finally bring all of the pieces together!!
User Testing
This project was very important to me and Salome, not just because it was our final, but also because of its practical use. Moving forward with it, I would like to make it available to our students and community at NYUSH so that people can better understand how to sort his or her trash. With that said, with such a sort amount of time, the success of this project was based in checklists and things to do!
Checklists for daysss and usertesting.notes
Going into user testing there were things that we knew that we needed to improve/ work on. To start with, we had not really decorated our box or knew what we wanted it to look like yet. We taped together our best design and found that the users would appreciate having labels and more clear signs of what bins were what on top. This was helpful because originally we would have assumed that the users want this on the front face so that they could see these as they walked up. Another big task that we needed to finish was the starting sequence. We were not really sure how to properly code that as our previous attempts had not been working. I think that the basis of this problem had been that we were making the code too complicated and including too many statements which ended up confusing the computer and us.
By the time we go to the final presentation day, I was really happy with our progress especially with how much that we had done. There is always more to do, but I was really proud of the fact that our project will work every time and we do not have to hope that one wire is plugged in or that the code will work this particular time or anything. It just works. It is reliable. I really appreciate this because growing up when I had robotics projects or coding projects, it would not always work 100% of the time, so I am really proud of how far I have come as well.
Final Product
To get to the final product from user testing, we were able to debug our existing code to make it 100% reliable and create the boolean sequence that allowed the user to get used to how the game worked and understand the instructions. We were also able to construct that the code would reloop and restart as soon as the user had finished his or her own turn.
Working through the code: https://drive.google.com/open?id=1m7EKRfjvRmtbmeqrjS6lo03qv6IH6gI8
Putting together the painted piecesThe finishing touches on our final!
As far as the physical components, we painted and decorated our box. We also finalized the design for the bins by using our logos at the handles for our bins. In addition, we labeled and color coordinated the tops and bottoms of the bins in order to make it as clear as possible to the user where everything should go. It was also suggested to us that we have some sort of “cheat sheet” so that people could be studying while a friend was going. We included which cards should be sorted where on the insides of the bins. This works two fold: they can look at it while they are reading the instructions, or, at the end, they can open all of the lids and practice before they start again.
Final product: https://drive.google.com/open?id=1IDJdS__sR7KRQ9HmcXO98l8x6TSF6mU_
Conclusion
This project was successful because of the teamwork and chemistry that Salome and I had. I can honestly say that I have never worked on a more efficient team. We were both on top of our game and equally shared the responsibilities and took initiative for what we needed to get done. There were several parts of the code and other steps in the process that I was really thankful to have Salome as my teammate, and I hope I can work with her again in the future!!
Once the project was actually over, it was fun to see how people originally thought an item should be sorted and see where it actually goes. I think that with our project we were able to create a meaningful interaction that allowed users full control of their destiny. I hope that this also translates into real life when the next time they are thinking about just throwing everything into the residual waste bin. I think that once a user has completed their experience with our project, they are able to reflect on some of the “out-of-the-ordinary” cards. From interacting with our project, I think that people are able to learn about how to more appropriately sort their trash, and also pay attention to certain items they normally sort incorrectly. For example, I would have though that glass should be sorted as hazardous waste when it is, in fact, supposed to be sorted into recyclable waste. I think an important part of the end of this project is that it starts a conversation. Whether it is with me or Sass or it is with people around them, people are able to have a conversation about how they have been sorting their trash, or how they intend to do so from now on. In our society, people sorting their trash in correctly, or not at all has been a huge problem. When you do it once, you will not start to notice it, but in 20 years when you are seeing trash all over the streets and in our communities, you do not need to look far when you start asking who to blame.
Moving forward, I would like to include leader boards where people can include their names and grade/staff. I would like to be able to make this available for freshman to play during orientation or for RA’s to use as a game to see who gets free boba. Not only does creating this into a game give people an incentive to win, but, practically, it gives them a platform to learn how to do these things. I think one of the biggest challenges we face when it comes to sorting our trash correctly is a combination of not knowing where something goes and also using the excuse that it takes too much time. With “Sort Your Trash; Save the World,” you not only learn where to sort your trash, but that it only takes a few seconds to save the world from exploding.
These two videos are the particles that I have made for the oop workshop, the idea is to let the videos firstly randomly generated on the screen and then follow the cursar wherever it is and orbit around it.
I use map() function in the first video example to declare the randomly generated position of the particles, in the second example the function is used to set the opacity of the particles in terms of their distance from the cursar.
The following code is for the first video, including three files.
Particles
ParticleSystem ps;
void setup() { size(1920,1080); ps = new ParticleSystem(); ps.addParticle(); }
void draw() {
background(0);
ps.run();
}
Particle1
class Particle1{
PVector curPosition; PVector accelerationX; PVector accelerationY; PVector position; PVector velocity; int r = 2; color c;
Particle1(PVector curPos, PVector pos, PVector v, color parc){ //acceleration = new PVector(0.05,0.05); position = pos.get(); velocity = v.get(); curPosition = curPos.get(); accelerationX = new PVector(random(0,2),0); accelerationY = new PVector(0,random(0,2)); c = parc; }
// Method to update position void update() { if(position.x <= 0){ velocity = new PVector(velocity.x*=-1,velocity.y); float prey = position.y; position = new PVector(1,prey); } if(position.x >= width){ velocity = new PVector(velocity.x*=-1,velocity.y); float prey = position.y; position = new PVector(width-1,prey); } if(position.y <= 0){ velocity = new PVector(velocity.x,velocity.y*=-1); float prex = position.x; position = new PVector(prex,1); } if(position.y >= height){ velocity = new PVector(velocity.x,velocity.y*=-1); float prex = position.x; position = new PVector(prex,height-1); }
class ParticleSystem { ArrayList<Particle1> particles1; PVector position; PVector velocity; color c; color[] co = new color[10]; PVector[] pos = new PVector[10]; PVector[] v = new PVector[10]; int pNum = 10;
ParticleSystem() {
particles1 = new ArrayList<Particle1>(); for(int i = 0; i<pNum; i++){ position = new PVector(random(width*1/4,width*3/4), random(height/4,height*3/4)); velocity = new PVector(random(-5,5),random(-5,5)); c = color(random(0,255), random(0,255), random(0,255)); pos[i] = position; v[i] = velocity; co[i] = c; } }
void addParticle() { for (int i = 0; i<pNum; i++){ float x = map(mouseX,0,width,500,600); particles1.add(new Particle1(new PVector(x,mouseY), pos[i],v[i],co[i])); } }
In this week’s recitation, I attended two workshops, which are map() function workshop and OOP workshop
For the map() function, it is pretty straightforward.
map(Variable name, lower bound of domain, upper bound of domain, lower bound of codomain, upper bound of codomain), which accept a variable name and 4 float data as range.
For the OOP part, a definition of class starts with
class (class name){
}
Then we define local variables within the class, and write an initialize funtion within the class, whose name is same as the class itself. It goes like:
class (test){
float x = 0;
float y = 0;
test(parameters){
……
}
}
When creating a new instance of class, we use
test instance = new test(parameters);
In my final project, I wrote a class of bullets in my game since all the bullets are similar objects and can be put together.
class Balls {
float x_pos;
float y_pos;
float vy = 10;
PImage bullet;
Balls (int n,int m,int p,float x,float y){
x_pos = (x-50*width/height) + ((m+1)*100*width/height)/(n+1);
y_pos = y;
switch (n){
case 1:
switch(p){
case 1:
bullet = loadImage("bullet1.png");
break;
case 2:
bullet = loadImage("bullet3.png");
break;
}
break;
case 2:
switch(p){
case 1:
bullet = loadImage("bullet2.png");
break;
case 2:
bullet = loadImage("bullet4.png");
break;
}
break;
case 3:
switch(p){
case 1:
bullet = loadImage("bullet2.png");
break;
case 2:
bullet = loadImage("bullet4.png");
break;
};
default:
bullet = loadImage("bullet4.png");
break;
}
}
void update(){
//fill(255);
//ellipse(x_pos,y_pos,8*width/1000,8*width/1000);
image(bullet,x_pos,y_pos,25*width/1000,25*width/1000);
y_pos -= vy * 0.9;
}
}
Base of the puzzle by itself
Base with puzzle pieces inside
Sketch of the base
Sketch including proposed sensors below
Participants using the joystick
Presentation Day
