Wednesday, May 20, 2015

SumoBot Challenge


Sebastijan Skoko
5-21-15
SumoBot Challenge


My partner and I were tasked with the challenge of constructing the ideal SumoBot for competition. The basic idea was to create a bot that could somehow cause the opponent to leave the ring. Our bot was comprised of a brick onto which the code was to be uploaded, motors which turned two wheels enhanced by gear trains, and various other components. The base of our bot was comprised of two motors. The motors turned a wheel, the torque of which was enhanced by a gear train. These motors received orders to turn in various manners from the brick placed directly above. The brick was placed horizontally and the code was uploaded onto it from Java. The third motor controlled a lever. When rotated, depending on whether the command was to rotate forward or to rotate backward, the lever was brought down to battle or lifted up into resting position. On this lever was a color sensor. The purpose of the color sensor was for the bot to locate itself. We took the sensor readings of the black ring outlining the platform as well as the white surface of the platform. We ordered the motors to move forward when the sensor readings matched that which we received from testing the white platform, and we had the motors reverse for two seconds and then turn when the sensor readings matched that which we received from testing the black ring. This ensured that the only way for our bot to find itself outside the boundaries of the ring was to engage in head to head collision with a more powerful, or heavier bot. Also on the lever, we constructed a wall that was designed for the purpose of pushing the opposing bot outside of the ring. At the bottom of this wall we placed a black lego piece. This piece was designed to trick the opposing bot. Various other partners executed similar ways of keeping their bots within the boundaries using a color sensor. If this contraption were to fall into the opposition’s color sensor’s field of vision, it would react in the same way that it would react to the outer ring. The impetus behind having all of these features on the lever was so that our bot would fit the size requirement. While, when rotated down, the bot exceeds the size limit, when rotated up, into the resting position, the bot fits the regulations perfectly.

The color sensor was the only sensor of which we made use. This sensor was both helpful and destructive regarding our success. While it was necessary for the bot to to self-locate and stay within the restricted area, many other groups utilized the same deception device as we did. In the end, however, it proved necessary and more helpful than destructive, as without it, the bot would have left the ring without a fighting chance. The platform on which we competed was comprised of a white surface and a black outer ring. We took the sensor readings of both sections, and wrote a line of code telling the motors to proceed onward provided that the readings matched the numbers we received from testing the white section of the platform. We also wrote a line of code directing the bot to retreat for two seconds and then turn when the readings matched the readings that we received from testing the black ring in order to avoid falling off of the platform. This feature enabled us to keep the bot in the ring, however many other groups utilized a similar deception strategy to that which we implemented and hoaxed our bot into retreating and often falling off of the platform.
Here is the code which my partner and I wrote for our SumoBot as well as:
import lejos.hardware.port.SensorPort;
import lejos.hardware.sensor.EV3ColorSensor;
import lejos.hardware.sensor.EV3TouchSensor;
import lejos.robotics.SampleProvider;
import lejos.hardware.motor.Motor;
import lejos.utility.Delay;

public class Class2 {
public static void main(String[] args){
Motor.A.backward();
EV3TouchSensor touch = new EV3TouchSensor(SensorPort.S4);
EV3ColorSensor color = new EV3ColorSensor(SensorPort.S3);
SampleProvider touchSP = touch.getTouchMode();
SampleProvider colorSP = color.getRedMode();
float[] touchSample = new float[1];
float[] colorSample = new float[1];
//boolean done = false;
Delay.msDelay(5000);
while(true){
touchSP.fetchSample(touchSample, 0);
colorSP.fetchSample(colorSample, 0);
System.out.println("Button Pressed: " + touchSample[0]);
System.out.println("Color: "  + colorSample[0]);
Motor.A.backward();
Motor.C.backward();
Motor.B.backward();
Motor.B.setSpeed(700);
Motor.C.setSpeed(700);
if(colorSample[0] < .1){
Motor.A.backward();
Motor.C.forward();
Motor.B.forward();
Motor.C.setSpeed(700);
Motor.B.setSpeed(700);
Delay.msDelay(3000);
Motor.C.forward();
Motor.B.backward();
Motor.C.setSpeed(700);
Motor.B.setSpeed(700);
Delay.msDelay(2000);
}
//if(){
              //done = true;
//}
}
}
}


In this video, our bot can be seen winning handily a match in one of the early rounds of the tournament. In this battle, our bot moves forward and defeats an opponent. Our bot was more powerful and drove right through the opposition.


The preliminary round proved helpful in that we were able to make slight adjustments, but my partner and I already had a very good sense of how our bot was going to operate. The early testing, however, was very helpful and necessary. We learned that the motors rotate in the opposite direction of that which the code commands them to. This was necessary information that we would not have gained without the early testing period. We also were able to test the speed of the motors. This information was integral, as the bot needed to be fast enough to impact the opponent, but not too fast to the point that it would fall off of the platform before getting a chance to react to the sensor reading. Also, we wrote a line of code telling the bot to retreat for two seconds upon receiving the reading that matched the black color. This amount of time for which we had the bot retreat was largely dependent on how far the bot would travel during this period of time. If the bot was moving too quickly, it would fall off before getting the chance to turn, however it was too slow, it wouldn’t cover enough ground and would likely be hit in the side, a very dangerous place in which to be struck.
Although my partner and I did not deal with any major problems or breakdowns, as we mainly coasted, we had minor deficiencies that kept us from the success which we could have achieved. It proved difficult for us to implement a gear ratio that would have enabled us to incorporate the greatest amount of torque possible. Also, we did not take into account the fact that the more weight we had pushing down on the wheels, the more power the bot would have to push through the surface and through the opponent. It was difficult to watch our bot be pushed outside of the ring with brute force, as this is an adjustment that we easily could have made. It was comforting, however, to know that there was no deficiency regarding our code, and all that we needed to do in order to have a more competitive bot was add more weight.
The component of our bot of which I was most proud was our color sensor. We were able to effectively incorporate a color sensor which aided the bot in that it kept the bot inside of the ring. Due to commands from our code of which I spoke above, it recognized the difference in color from the outer ring to the white surface. The recognition of this contrast is what enabled us to prevent the bot from leaving the ring. Many other groups utilized this same method, however, my partner and I were among the first groups to accomplish this task and it helped us tremendously.
If I were tasked with reconstructing a SumoBot or making improvements upon that which we originally constructed, I would certainly build a bot with more mass and implement a more sophisticated gear ratio. These adjustments would provide more torque and power to our bot, thus enhancing the ability of our bot to compete. Since most other groups had simple codes similar to ours, the only advantage they had over us was the mass directly over the wheels. All of the bots present in the final four were rather large and possessed a lot of weight.
During the SumoBot showdown, our bot was competitive, but clearly not up to the same standard as the top bots. We were able to place fourth in our class, however, we did not have enough success to compete with the bots from the other classes in the final four event. Our bot had all the qualifications regarding code, however, as aforementioned, it lacked significantly in the weight department. When our bot engaged in head to head contact, it was outmatched by the larger bots with more impressive gear ratios and more weight. We were pushed out of the ring by more powerful bots, especially those that also had an adequate code. Although we were not ultimately crowned the winners, we did certainly have our share of success. We were able to defeat two other groups, and were competitive in most of our matches.
To someone doing this project for the first time, I would advise that they build up their bot as much as possible, particularly over the wheels. While it may seem excessive at first, you will reap the benefits when the showdown comes. Although the code may be an important part, the most integral part is the power and force with which your bot drives. This power comes from the gear ratio, but mainly the weight. I also would recommend that, like my partner and I did, they make use of the color sensor as far as programming goes.
To a teacher running the project, I would insist that coding process should represent a larger portion of the project. It is unquestionable that the design should be an integral part of the project, but in this project, it accounted for the majority. I do not feel that my ability in the field of coding has greatly improved as a result of this project, and I believe that there should have been more emphasis in this area. One team that made it to the finals had barely implemented any code, however, due to the size of their bot, they experienced tremendous success. While this is not a knock on them, as they took advantage of a loophole, it did not take much skill to simply add random pieces to their bot.
My partner and I also made various calculations in order to further analyze the efficiency and effectiveness of our bot. Mr. Piper briefly explained the formula: Power (in this case, watts) = Torque (in this case, newton meters) X Angular Velocity (in this case, radians per second). Online, it states that the original torque is  20 N/cm, or 0.2 newton meters. The website also states that the initial speed at which the motor rotates is 165 RPM. This tells us that there are 165 revolutions per minute = 165 x 2π radians per 60 seconds. Our bot’s calculations are as follows:
Weight = 842g
Wheel Diameter = 5.5cm
Wheel Circumference = 5.5cm(π) = 17.27cm
Gear Ratio
Our gear train consists of an 8 tooth gear which turns a 24 tooth gear. This makes for an 8/24 gear ratio. This can be simplified to ⅓.

Final Speed = ⅓(165), which equals 55rpm. In order to convert this number into m/s, a more easily understood figure, the following calculations were done:
55(17.27) = 949.85cm/m
    949.85/60 = 15.83cm/s
   15.83/100 = .1583m/s
Initial Torque = 0.2 nm
Power Calculations: Power remains constant
RPM Conversions
165rpm(2pi) = 1036.73r/m
1036.73r/m / 60 = 17.28r/s
165 rpm ---> 17.28radians/s
Power = .2 nm(17.28rad/s)
Final Power = 3.46 watts (for the original bot; before gear ratio)
3.46 watts = T(17.28)/3
3.46 watts = T(5.76)

Final Torque ≈ 0.6nm