Project Poseidon

Overview

For the Mechatronics class I took in the Fall of 2021, I was placed into a group of three students and tasked with constructing a robot for the Cube Craze robot competition sponsored by ASML. The competition consisted of 50 teams and involved designing a robot that could bring more cubes to their half of the board than the enemy robot in under a minute. I took charge over the electrical design of the robot and made sure that it was wired to be the most efficient in terms of spacing and facilitating the coding. I also assisted in remaking the chassis to optimize weight and increase the speed using Fusion360. Overall, we ended up placing top of our group in the preliminary stages and then 7th overall in the playoffs.

Design

Mechanical

Our robot features a custom chassis measuring an overall 8”x5” that fits all the components necessary for our design. In the rear, it features an elevated shelf to hold the Arduino Uno R3 and breadboard with room to store the batteries and wheel motors underneath. The middle of the chassis includes holders for the two servos that hold the trident-shaped cube scooper and control its orientation. At the front of the chassis, there is a cantilevered section from which the QTI sensors hang and on which the color sensors sit. This cantilever is set 1 inch off the ground to allow the QTI sensors to hover an optimal distance from the ground such that ambient light will cause minimal disruption to their readings. To protect these sensors from being hit by an opposing robot, our design also includes a shield in front of the cantilever.

Electrical

The electrical design of the car is wired to be the most efficient in terms of spacing and coding. We used a lot of the provided sample code for our milestones so we decided it would be easier to code the robot using the same pins. Then with the remaining pins, we organized them from back to front corresponding with the sensors and motors on the robot. For example, the sensors at the very front of the car were the two QTI sensors and the color sensor so we wired them into pins 5 and 6. Then we had the servo motors in the middle section of the robot, the servo was connected to pin 9. Lastly, we had the two H-bridges controlling the two-wheel motors connected to pins 3 and 4 for the right wheel and pins 12 and 13 for the left wheel. That way we could wire the far away motors and sensors under the acrylic chassis and avoid them impeding the arm.

Software

The software of our car is designed with the overall strategy of moving all of the cubes on the board onto our side. Our robot starts by checking the board’s color to orient itself, and then it drives forward and deploys its trident so that it can reach the center of the grid where the cubes quickly. After the trident is deployed, the robot continues to drive forward until it senses a color change on the board (indicating it has reached the opponent’s side). When it senses this color change, it turns 90 degrees counterclockwise and drives forward, effectively scooping the cubes on the opponent’s side and pushing ours. Once our robot senses that it has reached the black tape, it turns 90 degrees counterclockwise again to scoop the cubes it has collected onto our side. It then turns around by making a 270 degree turn clockwise, switches the orientation of the trident, and drives back to the other side of the grid until it senses the black tape again. As it does this, it collects the rest of the cubes so that once it reaches the black tape and turns 90 degrees clockwise, it has moved all the cubes onto our side.

Manufacturing

For the project, we were given a budget of $40 along with a starting kit of materials which included QTI sensors, a color sensor, an acrylic sheet, 2 wheels, an Arduino, and various other electronic components. We were also given a 4-pack of AA batteries for the circuit and a 9V battery for the Arduino. Below is a bill of materials of items we ordered that were not included in our initial starting kit of materials.

The first step in our manufacturing process was to laser cut the new chassis from the acrylic sheet. We created a CAD model using Fusion360, which can be downloaded at the bottom of the page under “Files”, to generate a drawing file that we could bring to the Cornell Rapid Prototyping Lab for laser cutting. I created the CAD models for the sensors and the servo motors to allow us to have a full understanding of how our components were going to interact. The drawing file is shown below in Figure 3A along with the laser cutting process (Fig. 3B) and the final cut pieces (Fig. 3C).

After the chassis was glued together, we planned where all of the components would go for our circuit. We had to take special consideration when placing the QTI and color sensors as they need to be towards the front of the robot for optimal reaction time, but also as close to the ground as possible for accurate readings. Once the placement was all worked out, I created a circuit diagram before wiring all of the components together. It can be seen below in Figure 4.

I had the two H-bridges that controlled the wheel motors wired to opposite side of the breadboard to allow for the main sensors and motors to have the shortest, most efficient path to Arduino pins 3/4 and 12/13. Then I had the two QTI sensors connected to middle pins 5 and 6, so that I could pass the wiring up and down the bottom of the chassis to prevent the wiring from interfering with the trident. The color sensor connected to pin 7 as that was the pin that the sample code used and we decided that it was more effective to use the same pin than having to redo all of the masking in the code. Finally, we had the servo motor that controlled the cantilevered trident connected to pin 9 as it was spaced far enough from the other wired pins that we could access it easily in case the servo broke. All of the sensors and motors were connected via a breadboard where they all had a common ground and 5V. The Arduino had a 9V battery connected to power it and the 6V pin. The final product with all the wiring finished can be seen below, it is a picture of the completed robot the day of competition. As I did not directly work on the software of the robot, I will not be discussing it here. For more in-depth information on the software flowchart and code, you can download the full report at the bottom of the page under “Files”.

Competition Analysis

Our robot won 4 out of 6 matches in the round-robin tournament to make it to the first round of the playoffs before it was defeated. In our first match, one wheel rotated and the robot turned off the board, which is not what we had observed the night before competition. Immediately following this, we analyzed what had changed about our robot between the night before and that morning, and we came to the realization that we uploaded the wrong code. As we weren’t allowed to change the code anymore, we had to instead fix our wiring to create some sort of strategy out of the incorrect code. We decided to have our robot spin in circles and hope that the other robots would either drive themselves off the board, or accidentally push cubes onto our side. Our strategy proved effective as we were able to win our round-robin bracket and move into the playoffs seeded 7/50. The flaw in this strategy was that since our robot was not doing anything proactive, as long as the other robot worked as it had planned to, we couldn’t do anything to stop it. This is what led to our robot being defeated in the playoff bracket eventually. This proved to not be the worst strategy as our robot did make it quite far, however, the skill involved to get this far was obviously not really indicative of the mechanical, electrical, and software work that went into building our robot.

Conclusions

If we were to do this project again with all the same parameters, the big change we would make is uploading the correct code the morning of competition. When we ran our final code the night before competition, our robot did exactly what we described in the software design section of this report. After going through the competition and observing that many of the robots failed to move cubes to their own side even when they went essentially unopposed against our robot, we came to the conclusion that our robot probably would have done very well with our correct code. We are consequently extremely happy with the work that we did on this robot, and proud of ourselves for creating a robot that at least we know can do its intended job.