“S.L.A.P.B.O.T” by Gerry Song and Ryan Hiew (Professor Minsky)

“Super Lesioning Advanced Playing slapBox Offense Technology,” also known as “S.L.A.P.B.O.T.” is me and my partner, Ryan Hiew’s, midterm collaboration project. Essentially, we wanted to create a robotic recreation of the commonly played real-life game “slap-bet.” The original game revolved around two people placing both of their respective hands onto the other one. Whoever had their hands placed at the bottom, would try to slap the second person in the back of their hand and the second person would try to react to the slap and move out of the way. We wanted to create this same nostalgic game into a more modern setting and make cold metal and plastic parts slap a person’s hand instead as we thought it would invoke more pain and fear into the player. 

The idea for our project came from a quick brainstorming session that ultimately resulted in us talking about nostalgic mini-games that we used to play anywhere. We got to the subject of the “slap bet” game and we both agreed that it was more fun when each player tried to hurt the other player’s hand as much as possible as it gave the game a sense of thrill. I guess this project was influenced slightly from my group’s research presentation where I played an unfeeling and rude robot assistant. Ryan and I both thought it would be funny to strike fear into people’s minds by making the game way more scary and anxiety-inducing by making the timing random as well as fast while attempting to avoid being slapped by a cold, unfeeling machine. We took the idea a little further by thinking about adding cardboard spikes to the hand of the robot, but we eventually decided that it would probably ruin the aesthetic of the robot as well as having to change the name to “S.T.A.B.B.O.T.”. 

“SLAPBOT” revolves mostly around the aesthetic of the cardboard fingerless hands attached to a cardboard box. Both hands as facing the floor and are attached to a servo motor. Once activated, both hands start flailing up and down as if trying to slap someone. Getting people to actually start the mini-game was the most difficult part of our project as we had so much trouble getting the infrared sensors (the sensors that picked up if someone had been touched by the hands) to work that we did not design the feedback system nor the user design very well. Once we reached the user-testing phase, we had only designed one of the slapping arms with barely any user design or feedback. The project worked fairly well, slapping anyone’s hand that came across it and stopping while printing “HAHA LOSER YOU LOSE” in the serial monitor if the player had been slapped. However, a mere part of the project as well as no feedback other than the serial monitor really hurt the project’s lucidity to the testers.

User testing era SLAPPER: https://youtu.be/sgRPzl4bSXw 

 

The final part of the project came by too fast. We had originally planned to add sound feedback whenever the player lost as well as another feedback mechanism that would turn on a light when the player lost. However, because of some issues with the code, adding the second arm to the SLAPBOT was much more difficult than expected. We eventually got it to work, but by then there was already barely any time to build and code anything extra. Unfortunately, our only choice was to make it more interesting through a little bit of code. We decided to attach the second arm of the SLAPBOT on the opposite side of the machine and make the slapper into a competition between two players, since the spirit of the original game was competition. Ultimately, this aspect was more of a hinderance than an addition since more than one person pointed out that the project relied too heavily on a two-player mode and could not stand out too much on its own. 

Final version of SLAPBOT: https://youtube.com/shorts/DuSLMNeHxhA?feature=share 

This project could definitely have gone much smoother with the building process. If that had happened, we definitely would have completed a much better user-interface and feedback system as well as making the project much more polished in general. The main problem’s focal point was the lack of time after making the second arm work. If I could do it again, I would focus less on the arms and build/draw the interface better. However, I am still thankful for the project we had built and how it had functioned despite its hiccups. 

 

Project 1 Documentation

Project Origin and Designs

Our idea for the project originated from a brainstorming session. We had all agreed that it would be interesting to do an interactive performance on the third story of Step 2 of the project, also known as the pandemic story. After deciding the setting, we also brainstormed what kind of interactive project would make living in a pandemic world more bearable. Moreover, the plague in the story would slowly paralyze anybody that is infected, so an interactive design to help them is almost necessary

We ultimately decided on a robot that can be controlled using some kind of… controller. The controller would have to have a small range of motion, as the people using the controller are halfway paralyzed. I believe the original idea of the controller came from my Step 1: Research interactive project: the haptic controller. A haptic controller is basically an interactive controller that responds with the user, giving real time feedback to the user. We ultimately decided to model our haptic controller a little bit off of Stanford Robotics Laboratories’s own haptic controller that was mainly used to control a virtual avatar. However, this controller would be used to control a robot that would do the most mundane tasks for the user.

The problem with the robots however, was that we had to make them as realistic as possible (at least in theory). Robots need to go through multiple stages of testing before they get released into the masses while also needing to improve on its prior model. So we decided that one robot should be an older model and the other should be a new one with better features. And what better features to have on a robot than literal wings. 

 

Group Dynamic

Getting to work with the group was the best part of the project for me. Interacting with them and having people to bounce my ideas off of while, at the same time, having them pass ideas through me as well. We all basically had the same job but done slightly differently. We all used the cardboard and built different things as well as contributed the storyboarding process, but we had our specific skill sets for these. For example, a teammate suggested the wings, but none of us except her had the artistic capabilities to implement this. 

Rehearsal and Performance

The rehearsing process was the most fun part of the project. We did not exactly have a script to follow, so we just resorted to improvisation. Each of us basically just did what felt right in the given situation. The people controlling the robots made up a random situation for the robots to go through. The robots acted ‘robot-y’ throughout these situations. The actual performance was a rough summation of what we rehearsed. If I were to be very picky about the performance, I would say that we all were a little stiff on stage and could have let loose a bit. Either that or there could have been more of a contrast between robots and the humans, making the humans more lively and the robots more stiff as if they were being controlled. 

Hello world!

Welcome to Web Publishing @ NYU. This is your first post. Edit or delete it, then start creating your site!

Online help is available via the Web Publishing Knowledge Site (wp.nyu.edu/knowledge) and the ServiceLink knowledge base (www.nyu.edu/servicelink). Through ServiceLink, you can find step-by-step instructions, as well as tutorials.

Digital Accessibility

As content creators who create and publish text, images, video, and audio, you must adhere to the NYU Website Accessibility Policy (https://www.nyu.edu/digitalaccessibility/policy) when creating and publishing digital content.

Web Publishing-specific Digital Accessibility Best Practices and examples of how to ensure your content are compliant are available at https://wp.nyu.edu/digitalaccessibility

If you have additional questions, contact the IT Service Desk for assistance. Support is available 24/7/365. For more details, visit www.nyu.edu/it/servicedesk.