The Strategy
We debated several strategies for our SumoSenator, but decided early on that the game would primarily be determined by size and strength. There's a reason sumo wrestlers are so large! We decided to initially focus on making a strong, heavy, friction-y robot that was good at pushing other robots - a basic "Bowser Bot" in our brainstorming parlance. This would be our foundation - we would sacrifice speed an maneuverability for strength. Once we had a powerful platform in place, we could incrementally add additional strategic aspects, like a "Ramp Bot" or "Sequester Hugger" strategy as time permitted (see the Brainstorming section under Design Process for descriptions of these strategies).
The maximum pushing power of a SumoSenator depends on the torque of its motors, but has an upper bound that is the static coefficient of friction times the robot's normal force (the robot's mass times the gravitational acceleration at the surface of Earth). Any more torque is largely useless, since the wheels will spin out instead of providing pushing power. The Fiscal Cliff Face-Off placed 15 pound limit on the mass of SumoSenators, which is a torque easily attainable by (multiple) hobby motors with the correct gear-head. Assuming everyone went to the 15 pound limit, and all teams had motor torques spec'd such that they were limited by normal force, not motor torque, the game would simply be decided by who could stickier wheels. Thus we bought the material with the best traction we could find - the Vex 2" Wedgetop Traction Thread - and affixed it to our wheels.
Our design philosophy was KISS - "Keep It Simple, Stupid". We ended up not using many of the sensors and features we initially thought we would include, such as tape sensing, bump sensing, and range detection. Our control logic was as simple as: if you see the enemy in front, drive forward. If you see the enemy on the right, turn right. If you see the opponent on the left, turn left. If you do not see the opponent, turn the direction that you saw the opponent last. Tape sensing turned out to be nonessential, because as soon as we pushed the opponent into the moat, we would lose their beacon signal, and start turning in place, thus not following them over the edge. This turned out to be more reliable than many of the other teams more advanced tape sensing strategies! Ultimately, if we had a bit more time in the end, we might have added these features, however, they proved to be largely unnecessary for the task at hand. Many teams were plagued by failure to account for the edge cases of their additional sensors (especially tape sensors), and their robots displayed unintended or even suicidal behavior! It's hard to cover all the edge cases in software when you are being attacked by a tenacious opponent. We were well served by concentrating our time on the things that were most important, and doing them well.
To see other strategies we debated and prototyped, see the Design Process section.
The maximum pushing power of a SumoSenator depends on the torque of its motors, but has an upper bound that is the static coefficient of friction times the robot's normal force (the robot's mass times the gravitational acceleration at the surface of Earth). Any more torque is largely useless, since the wheels will spin out instead of providing pushing power. The Fiscal Cliff Face-Off placed 15 pound limit on the mass of SumoSenators, which is a torque easily attainable by (multiple) hobby motors with the correct gear-head. Assuming everyone went to the 15 pound limit, and all teams had motor torques spec'd such that they were limited by normal force, not motor torque, the game would simply be decided by who could stickier wheels. Thus we bought the material with the best traction we could find - the Vex 2" Wedgetop Traction Thread - and affixed it to our wheels.
Our design philosophy was KISS - "Keep It Simple, Stupid". We ended up not using many of the sensors and features we initially thought we would include, such as tape sensing, bump sensing, and range detection. Our control logic was as simple as: if you see the enemy in front, drive forward. If you see the enemy on the right, turn right. If you see the opponent on the left, turn left. If you do not see the opponent, turn the direction that you saw the opponent last. Tape sensing turned out to be nonessential, because as soon as we pushed the opponent into the moat, we would lose their beacon signal, and start turning in place, thus not following them over the edge. This turned out to be more reliable than many of the other teams more advanced tape sensing strategies! Ultimately, if we had a bit more time in the end, we might have added these features, however, they proved to be largely unnecessary for the task at hand. Many teams were plagued by failure to account for the edge cases of their additional sensors (especially tape sensors), and their robots displayed unintended or even suicidal behavior! It's hard to cover all the edge cases in software when you are being attacked by a tenacious opponent. We were well served by concentrating our time on the things that were most important, and doing them well.
To see other strategies we debated and prototyped, see the Design Process section.