Welcome to the Team "Bang My Bits" website (Note: This website works best in Chrome)
Description of Objective
Below we summarize the basic tasks required for this project. For a more detailed description of the project and game specifics, please click on Project Description and FAC Summary.
In true 218 tradition of fun with puns, the game designed for our class was a simplified version of Bat-tleship (for a clearer understanding of this pun, please visit the 218a project sites located in the Meet the Team section of this website). A game board was constructed with two sides separated by a wall. Two teams would play against one another on opposite sides. Each team would strategically place ships on their side of the board and during game-play, would try to sink the enemy ships by launching Nerf balls over or under the wall. Each bot could carry a maximum of five balls at a time, so a reloading station was located on each side of the field to request more balls. This reloading station was controlled by a power supply station that could also be the target of the enemy robot. A vision system mounted above the game board would update and relay position and orientation data for any visible ship or bot if requested by the bot. Points were awarded for the sinking of enemy ships, hitting the enemy power supply station, and hitting the enemy bot. If either bot was hit, the round would end instantly, otherwise each round lasted two minutes.
In true 218 tradition of fun with puns, the game designed for our class was a simplified version of Bat-tleship (for a clearer understanding of this pun, please visit the 218a project sites located in the Meet the Team section of this website). A game board was constructed with two sides separated by a wall. Two teams would play against one another on opposite sides. Each team would strategically place ships on their side of the board and during game-play, would try to sink the enemy ships by launching Nerf balls over or under the wall. Each bot could carry a maximum of five balls at a time, so a reloading station was located on each side of the field to request more balls. This reloading station was controlled by a power supply station that could also be the target of the enemy robot. A vision system mounted above the game board would update and relay position and orientation data for any visible ship or bot if requested by the bot. Points were awarded for the sinking of enemy ships, hitting the enemy power supply station, and hitting the enemy bot. If either bot was hit, the round would end instantly, otherwise each round lasted two minutes.
Description of Function
The following is a brief description of our robot and how it worked. There are more details under the various subsystem headings to the left.
Our bot was built around simplicity and on implementing systems that had low likelihood of failure. We would always start our bot near the middle wall closest to the origin facing the other side. Upon initialization, the bot would use the provided FAC data to figure out where the enemy ships were and begin moving down the wall using a front mounted ultrasonic sensor for positioning and the FAC data for alignment. The ultrasonic sensor ensured that our bot traveled in a straight line by implementing a simple derivative control on the motor system. If the derivative of the ultrasonic value was too large it meant out bot was traveling at an angle and we would use the wheels to correct the position. Once the bot got to a position directly across from the nearest enemy ship, the bot stopped and entered the firing sequence.
We would calculate the distance to the target using FAC data and start spinning the fan to the right speed for that distance. The fan only took a half second or so to spin up which was longer than it took us to load a ball. We used two servo motors for loading, one would stop queued balls from interfering with the ball being loaded into the barrel, and other other servo would tilt the ball into the barrel.
The robot would continue firing at the same target until it disappeared from the FAC. The launcher fired accurately, but there was some slight variation in both range and alignment. This resulted in a fairly compact spread and we found that if the first shot missed the target, the second would often hit with no adjustment.
Once the bot ran out of balls, it would use the FAC to position itself to the middle of the game field. Once there, it would use the FAC to rotate 90 degrees so the bot could drive straight backwards toward the reloading station. We implemented a control system using the FAC data to make sure that we were heading towards the reload station. This accuracy of this method was not impeccable, but through clever mechanical design, we were able to collect balls across the entire width of the back of the bot, so precision was not imperative.
The bot would ask for five balls, and would pause asking for balls if the supply station was hit while reloading. After collecting five balls the bot would move back to the middle of the field using the FAC, rotate 90 degrees to point the barrel across the field, and then move to the next ship location.
If all ships were hit, the bot would simply freeze and turn the fan up to full power because we figured it was the most fun thing our bot could do.
Our bot was built around simplicity and on implementing systems that had low likelihood of failure. We would always start our bot near the middle wall closest to the origin facing the other side. Upon initialization, the bot would use the provided FAC data to figure out where the enemy ships were and begin moving down the wall using a front mounted ultrasonic sensor for positioning and the FAC data for alignment. The ultrasonic sensor ensured that our bot traveled in a straight line by implementing a simple derivative control on the motor system. If the derivative of the ultrasonic value was too large it meant out bot was traveling at an angle and we would use the wheels to correct the position. Once the bot got to a position directly across from the nearest enemy ship, the bot stopped and entered the firing sequence.
We would calculate the distance to the target using FAC data and start spinning the fan to the right speed for that distance. The fan only took a half second or so to spin up which was longer than it took us to load a ball. We used two servo motors for loading, one would stop queued balls from interfering with the ball being loaded into the barrel, and other other servo would tilt the ball into the barrel.
The robot would continue firing at the same target until it disappeared from the FAC. The launcher fired accurately, but there was some slight variation in both range and alignment. This resulted in a fairly compact spread and we found that if the first shot missed the target, the second would often hit with no adjustment.
Once the bot ran out of balls, it would use the FAC to position itself to the middle of the game field. Once there, it would use the FAC to rotate 90 degrees so the bot could drive straight backwards toward the reloading station. We implemented a control system using the FAC data to make sure that we were heading towards the reload station. This accuracy of this method was not impeccable, but through clever mechanical design, we were able to collect balls across the entire width of the back of the bot, so precision was not imperative.
The bot would ask for five balls, and would pause asking for balls if the supply station was hit while reloading. After collecting five balls the bot would move back to the middle of the field using the FAC, rotate 90 degrees to point the barrel across the field, and then move to the next ship location.
If all ships were hit, the bot would simply freeze and turn the fan up to full power because we figured it was the most fun thing our bot could do.