Interaction Lab section 4 – Gottfried Haider
Yoon Lee (Team Yoon & Yuni)
Save the Duck
During the earlier semester, we engaged in multiple stages of research, which laid the groundwork for the development of my personal concept of interaction. Particularly, while exploring interactive art projects in our research, I delved into the fundamental aspects of interactive design. I distinctly recall how “The Augmented Reality Sandbox” influenced my understanding of interaction, leading me to conclude that the subject should not be the sole performer. Instead, the subject’s performance should coincide with or follow the act of interaction. Additionally, through a collaborative research project spanning several weeks, I gained a deeper insight into the essence of performing interactivity. This understanding played a vital role in shaping my own project centered around interactive performance. Based on these principles of mine, the objective of our midterm project was to create an interactive game that fostered collaborative participation between performers and the subject. Initially, my definition of interaction centered primarily around the process itself. I placed a strong emphasis on developing a project where interaction was established as the performer engaged with the subject. I believe that the outcomes of the project effectively corresponded with my understanding and definition of interaction.
My partner and I initially designed an arcade game using gravity, just like a flappy bird. We used an ultrasonic sensor to control the height of the bird. The bird fell when the ultrasonic sensor detected nothing among its designated range. As the user placed their hand closer to the sensor, the bird in the screen started to go up. Based on this mechanism, the goal of the game was to go as far as possible the user can get by controlling the bird to avoid the obstacles. Unfortunately, we faced harsh feedback on the user testing day. The feedback mainly contained the lack of uniqueness and simplicity. Although the basic mechanism of the game was already widely existing, we thought the physical part of the project (sensor) could make the game very unique if there were improvements in detail. Still, we had to seek a dramatic change for the project as professor Garcia mentioned and ultimately decided to start a totally new project.
After we made our decision to start a new project, we only had 4 days of time. We quickly restarted the research process and thought it would be interesting to design a robot that detects obstacles. Our inspiration for the design mainly came from my experience in the Army, which led us to mobilize the robot with track rather than conventional wheels. We thought challenging such a mechanism would be more unique and align with the idea of the unmanned detection vehicle. Once the detector becomes fully mobile by the usage of a joystick, the ultrasonic sensor in the front would detect the obstacles within the setted range and send its signal to the monitor. The aim of our project was: “Users have to use a joystick to control the detector and go pass through obstacles. If the users fail to reach the target in 60 seconds or make the buzzer go on by detecting explosive obstacles, the game is over”.
The fabrication began by designing the main body of the detector with cardboard. The reason why we chose cardboard as a material was because to give flexibility to the construction process. Since we did not have a lot of time to build the robot, we could not manage to go through miscalculations. Despite 3D printing and laser cutted wood being solid materials, it was extremely difficult to fix the design during the process when there was miscalculation. However, we used laser cutting for the wheels which were used to rotate the track of the robot.
We used two stepper motors to rotate the main track wheel. We peeled off the layers of cardboard to make a wheel cover and the main track. This was to give more friction to both wheels and track so that the wheels could hook the track and successfully generate the track movement. Then, we built an arduino circuit of ultrasonic sensors. The design of the detecting part was very simple, the buzzer went on when the sensor detected obstacles within the range of 13.
Ultrasonic Sensor/Buzzer code
The most challenging part of the project was the arduino sketch of stepper motors. The problem was controlling the direction of the two wheels. If the two motors were able to move in the same direction, it was impossible to make the vehicle tilt either right or left. (In such a mechanism of using track, the tilt occurs when each side of the wheels rotates in opposite directions) However, once I fixed this problem, the vehicle was no longer moving forward or backward. We spent a lot of time fixing this problem and while we were going through this problem, the friction on wheels and track occurred too much so cardboard was severely damaged. We kept on solving the problem by replacing the wheels and the track over and over again. One time, we were not aware that the stepper motor was so heated until it burnt all the wirings and started to malfunction. This made us rebuild the entire design more than five times which later caused the time shortage for processing sketches.
We solved the processing sketch by finally finding out the controlling directional complement of the stepper motors and managing the wheels to rotate in the intended direction at any time “separately”. Then we moved on to the next step. We connected the motor circuit with the joystick and inserted the map function to control the vehicles. We also tried to make the robot fully remote by inserting the sketch into the arduino and making the vehicle carry the batteries by its own. This did not work out well since the voltage of the battery did not match well so it started to overload the circuit and eventually burnt the internal part of the wirings.
The processing sketch ended up not completing the part where it showed signal when the sensor detected the obstacles. It only showed the remaining time of the game with the music playing.
Videos
https://drive.google.com/file/d/13arCkv3scg8A-NYp82EEQgFJQ8TO9zZl/view?usp=share_link
https://drive.google.com/file/d/1PlybSvM_eqmrVhKe7kxbTfdjU5b0tj-3/view?usp=share_link
The general overview of our final project was failing to meet the aimed design by time shortage due to poor performance in research/initial proposal. We would have completed the project with details if we managed to follow the process along with our planned details. We could have designed the map of obstacles and worked on more to make the vehicle fully remote. Also the graphics of processing would have been a lot high quality, along with several components added when the game is over by detecting the obstacles. However, I believe the unique mechanism of utilizing the wheel track and the tilt system was worth challenging. The performance we showed in such a short time was also one of the satisfying factors of our project. I believe we really well aligned with the concept of interactivity and showed the possibility of our potential of maximizing it in a timely manner. It was also crucial to learn that it is very important to go through a well-prepared brainstorming/research proposal session.
Yoon – Proposal, Robot design, Robot construction (body, wiring circuit, wheels and track), Ultrasonic Sensor/Buzzer coding, stepper motor coding
Yuni – Robot construction (wheels and track), Processing coding
-Only included the contributions in Final project, not first two projects until user testing –