Date: November 17, 2019

To: Professor Jessica Menold

From: Victoria Mayer, Miceala Stover, Mathew Tweedie, Rupal Chaudhary (ME 340, Section
5, Team 1)

Subject: Progress Update of the Development of our Sumo Robot

Introduction

This memo presents the progress of our sumo robot. Sumo robots are self-controlled
robots that push their competitors out of the ring to win the competition. In the Design
Methodology course at The Pennsylvania State University, we were tasked with creating a sumo
robot to compete against our peers in the class. This project will allow us to become more
familiar with autonomous robots. Autonomous robots will change the world and assist humans
as we become more efficient in various industries [1]. Learning how to interact with autonomy
will assist us in our future careers as engineers.
In our Proposed Redesign Memo, we generated various design concepts we wanted to use
in the final design of our robot. These design concepts include staying undetectable from our
opponents, using multiple ultrasonic sensors, and implementing a distraction component into our
robot. Our team created low fidelity and sub-system prototypes to test the concepts previously
generated.
In this memo, we will first talk about our low fidelity prototypes and sub-system
prototypes we used to test design concepts. Through these tests, our team found that the concepts
generated for our defensive based robot can be successfully implemented. Our distraction
component has been successfully tested. The shell of our robot was designed in a way that will
allow us to stay undetectable from our opponents. Creating Alpha and Beta prototypes allowed
our group to discover how we want to build our final robot. To conclude this memo, our team
will present the Gantt chart we have constructed to plan our remaining steps for the rest of the
semester.

Low Fidelity and Sub-System Prototypes

After completing the analysis and redesign phase of our robot, our team created low
fidelity and sub-system prototypes. These prototypes tested the ideas generated in the redesign
phase to confirm that their feasibility for the final version of our robot. We first created the
Alpha prototype of our robot, Alpha 1, as shown in Figure 1. Using Alpha 1, our team created a
more in depth evaluation of the angle necessary to make our robot undetectable. We tested this
concept in the redesign phase and determined that we wanted to include it in the final version of
our robot based on our design specifications. Alpha 1 has walls that are angled at 60 degrees,
determined from our initial investigation in the redesign phase. We found that the ultrasonic
sensor was able to find our prototype. However, after covering Alpha 1 in cloth, the prototype
was not able to be found. Our team determined that it is critical to cover our robot in a material
that will absorb the ultrasonic signals. We believe that the ultrasonic sensor was originally
picking up on the hot glue used to glue the foam walls together. Alpha 1 also allowed us to have
a general sense of how big our robot will be. Our team began to gain an understanding of how
many components we could include inside the shell of our robot. Alpha 1 allowed us to rapidly
test the feasibility of creating a defense based robot, as we proposed in the redesign memo.

Figure 1. Alpha 1, first prototype

We then created a sub-system prototype, Alpha 2.1, to test the feasibility of getting two
Arduinos to communicate with each other. Alpha 2.1 was created because the total number of
digital inputs we wanted to use exceeded the number of available pins on the Arduino. To test
this communication, Alpha 2.1 used the I2C protocol, explained in Appendix A. We enabled one
Arduino to take inputs, assign these inputs to a variable, and transmit that variable to the second
Arduino. The second Ardunio could then read the variable and use it to make various decisions.
The I2C protocol uses a direct wiring system to transmit the information from one arduino to
another. Alpha 2.1 allowed us to determine that we can successfully program two Arduinos to
communicate with each other, which will allow us to include more sensors on our final robot.

Through the redesign process, we determined that we wanted to create a defensive based
robot. Our team wanted to include a distraction in our robot to enhance its defensive capabilities.
Alpha 2.2 was created to confirm that we can successfully implement this distraction. First, we
connected two servo motors to our Ardunio. We then created a short code to have the servo
motors rotate back and forth 180 degrees. Alpha 2.2 ran successfully, and allowed us to
determine that holes need to be cut in the top of our robot to allow the servos to rotate freely.

Beta Prototype and Project Schedule

 After creating Alpha 1, we created three Beta prototypes, Beta 1.1, Beta 1.2, and Beta
1.3. We initially created Beta 1.1 out of sheet metal at the Learning Factory, as shown in Figure
2. Beta 1.1 was approximately 20% the size of Beta 1.2, the originally designed robot. Our team
learned that this might not be the best way to build our robot. We struggled to bend the sheet
metal to the exact angles we wanted, as we do not have much experience using sheet metal.

Beta 1.2, originally designed on CAD to build Beta 1.1, was then constructed through
Additive Manufacturing. Because of the size of Beta 1.2, it could not be printed in one piece. As
a result, we printed Beta 1.2 in four different sections. We believe that using Additive
Manufacturing is a more successful manufacturing method for our design because it will allow
the angles of our shell to be precise. Our team felt that Beta 1.2 was slightly larger than we
wanted it to be. Beta 1.3 was then created as another iteration of our robot. Beta 1.3 is slightly
smaller than Beta 1.2, but still has the same design.

Beta 1.3 allowed us to place a small skirt around the edge of our robot. Per our design
specifications generated in previous memos, our team wanted to include a thin white edge
around our robot. If our competitors’ infrared sensors run over our white edge, they will process
this as the edge of the ring and begin to back away from us. Using the slightly smaller Beta 1.3
will allow our team to accomplish this goal. Our team will use Beta 1.3 to create a vacuum-
sealed mold over Beta 1.3 at the Learning Factory. This mold will be colored white. In the final
design of our robot, we will glue this vacuum-sealed mold over the 3D printed shell to create one
solid body for our robot.
Figure 2. Features of the Beta prototype: (a) Beta 1.1, body of the sumo robot made out of sheet metal (b) Beta 1.2,
3D printed body of the sumo robot (c) Beta 1.3, smaller 3D printed body of the sumo robot

As shown in Figure 3, we have constructed a Gantt Chart to plan our final tasks for the
rest of the semester. Our team is currently testing Beta 1.3. This task will be completed by
November 18. As shown in the Gantt Chart, we are currently on schedule. Our team built in 16
days to finish testing the low fidelity and sub-system prototypes. This extra time has allowed our
group to not fall behind in the construction of our robot, as we did not expect to have to construct
three versions of our Beta prototype. After we finish testing Beta 1.3, our team will begin
mounting all of our internal components. This includes motors, wheels, wires, ultrasonic sensors,
infrared sensors, and servo motors. We will also finalize our code for the robot, and test our
robot in lab before the final competition. As we are finishing our robot, we will simultaneously
work on the final report for our class.
Figure 3. Gantt chart showing the remaining tasks for the rest of the semester

Conclusion

This memo has presented the progress we have made on our robot since our Proposed
Redesign Memo. We first created various low fidelity prototypes and sub-system prototypes to
test the concepts proposed in the previous memo. From there, we created multiple Beta
prototypes of our robot. We did not initially plan to create multiple Beta prototypes, but we ran
into a few issues in the manufacturing process. Through these events, we are still on schedule, as
shown in our Gantt Chart. Our team will continue to build our final robot as we prepare for the
final competition.

From our Progress memo, we have drawn a few conclusions. First, we have confirmed
that our defense based robot is viable. We are continuing to strive to make our robot as defensive
as we can. Secondly, we learned that we should have planned for more time to build our physical
robot. We thought that bending sheet metal, the first manufacturing method we tried, would be
the most successful. However, it was not. As a result, we had to pivot to another manufacturing
method. We will use Additive Manufacturing to construct our robot for the final competition.

References
1. Racoma, Bernadine, et al. “How Will Robots Change the World?” Day Translations
Blog, 8 Feb. 2019, https://www.daytranslations.com/blog/will-robots-change-world/.
2. Dejan. “How I2C Communication Works & How To Use It with Arduino.”
HowToMechatronics, 4 Aug. 2018, howtomechatronics.com/tutorials/arduino/how-i2c-
communication-works-and-how-to-use-it-with-arduino/.

Appendix A: Wiring and Coding using the I2C protocol

The I2C protocol uses two wires to directly send information from one component to
another. It can be used between different sensors, multiple arduinos, or a combination of both.
Using the I2C protocol requires each component to have a specific address for other components
attached to know what is being sent by which device. For our teams purpose, we were using two
Arduino Uno’s connected in this way. Our setup for connecting the two Arduinos is shown in
Figure A-1. One of the Arduinos is referred to as the “master,” which sends data to the Arduino
referred to as the “slave.” The I2C protocol uses one wire for the Serial Clock (SCL) and another
for Serial Data (SDA). The SCL is used for transmitting regular pulses to keep the two Arduinos
in sync relative to each other. The SDA line sends information in the format of a start signal,
data, and an end signal [2]. For a setup with multiple connections, the line can only handle a
single transmission at a time. However, after a transmission has been completed, another pair of
devices can send data. This timing is not an issue for our team as only two devices exist on the
network.
 Figure A-1: Wiring diagram of two arduinos connected using the I2C protocol

The coding required to make this setup work is relatively simple. Using the built in
“Wire” library of commands, it became simple to transmit data between Arduinos. On the master
Arduino, we write the variable x to the transmission line. The variable x increases by 1 every .5
seconds until it reaches 10, then resets. The slave Arduino reads the variable x from the SDA and
then plays a tone on the speaker corresponding to the variable x. The code for this setup can be
seen in Figure A-2. The speaker is hooked up with a 100 Ω on the positive lead and a sound is
played using the tone command. Figure A-3 shows the actual set up used for the I2C protocol
test.

Figure A-2: Code for using the I2C protocol: Master arduino code (Left), Slave Arduino code (Right)
Figure A-3: Wiring setup for I2C protocol test with varying speaker frequency