Project Description
The goal of the project was to create a robot that could complete three to five laps of a race and to make a basket from the shooting zone and to go over the teeter-toter obstacle at least one time. In order to complete this project we were given a variety of field resources to complete the task including a black tape track, a wire track and a camera based navigation system (DRS).
Team Strategy
As a team we tried to live by the strategy: as simple as possible. Consequently we decided to design a DRS based robot. We knew that we would need to be able to communicate with DRS one way or another (because we needed to know when the game started, stopped and other data about the game play). Additionally, relying on the DRS entirely made sense because it would allow the robot to know it’s own location regardless of where it was on the playing field (which would have been impossible with tape or wiring following strategies). To make a basket in the shooting zone we thought that a fly wheel would be the most consistent, repeatable and compact method.
What we built:
Navigation
Our strategy for navigating the field was to set targets for each corner of the track and also for the beginning, middle and end of the shooting zone and obstacle. Each target had a buffer for which the robot was allowed to be within in order to reach that target. This kept the robot from wandering aimlessly trying to reach targets. To know if we reached these targets we ping-ed the DRS system for our location and then drove according to that information. After a given period of time we would check our location and calculate our orientation based on our previous and current location information. This was in place of using the DRS heading information because we knew from taking data that the DRS orientation information varied as much as plus/minus 15 degrees in certain spots on the field. This allowed us to use the DRS in its most accurate form. Furthermore, to determine the angle rotated during turning we used encoders on our wheels. The encoders also allowed us to close the loop on our motor control to give us the best chance of going in a straight line. At the end of the day though we found that we needed something that we could rely on a bit more consistently than the DRS. So we decided that adding bump sensors would be a good addition. The bump sensor was not so much a navigation tool as a “get out of trouble” implementation. Whenever a bump event was detected the robot would back up for a set period of time (about three seconds) and then use the DRS orientation to realign with the target.
Shooting
For shooting we implemented a fly wheel style shooter and we found it to be decently accurate. We decided to make it out of foam core to reduce weight and allow for easier alteration. But foamcore has its downsides. It wears out easily and has a lot of potential for deformation. Because of this we actually had to recut our shooter the day before grading. The main advantage we saw to the fly wheel shooter was that we were already familiar with the circuitry necessary to create it and it was easy to reload and use multiple times per race. It ended up being effective enough. We found that in a non-race environment we made about 80% of our baskets. This was good enough given that we had three chances each race to make a basket.
Obstacle
We didn’t think that much about the obstacle until the end of the project but a number of things helped us to navigate it. First, we found that being a light, bottom-heavy bot meant that navigating the obstacle was easier for us than for the other bots. Mainly this manifested itself in the fact that we were able to leave the obstacle without face-planting. Additionally, in order to navigate the obstacle, we switched our bot’s orientation back to front (ie the back become the front and the front became the back). This allowed us to gain more traction when going up the obstacle because the rear wheels remained in contact with the ground and with a decent amount of normal force on them at all times. Fortunately this didn’t mess up any of our other systems and actually made leaving the shooting zone after taking a shot easier (because now we were shooting out of the back rather than the front).
The goal of the project was to create a robot that could complete three to five laps of a race and to make a basket from the shooting zone and to go over the teeter-toter obstacle at least one time. In order to complete this project we were given a variety of field resources to complete the task including a black tape track, a wire track and a camera based navigation system (DRS).
Team Strategy
As a team we tried to live by the strategy: as simple as possible. Consequently we decided to design a DRS based robot. We knew that we would need to be able to communicate with DRS one way or another (because we needed to know when the game started, stopped and other data about the game play). Additionally, relying on the DRS entirely made sense because it would allow the robot to know it’s own location regardless of where it was on the playing field (which would have been impossible with tape or wiring following strategies). To make a basket in the shooting zone we thought that a fly wheel would be the most consistent, repeatable and compact method.
What we built:
Navigation
Our strategy for navigating the field was to set targets for each corner of the track and also for the beginning, middle and end of the shooting zone and obstacle. Each target had a buffer for which the robot was allowed to be within in order to reach that target. This kept the robot from wandering aimlessly trying to reach targets. To know if we reached these targets we ping-ed the DRS system for our location and then drove according to that information. After a given period of time we would check our location and calculate our orientation based on our previous and current location information. This was in place of using the DRS heading information because we knew from taking data that the DRS orientation information varied as much as plus/minus 15 degrees in certain spots on the field. This allowed us to use the DRS in its most accurate form. Furthermore, to determine the angle rotated during turning we used encoders on our wheels. The encoders also allowed us to close the loop on our motor control to give us the best chance of going in a straight line. At the end of the day though we found that we needed something that we could rely on a bit more consistently than the DRS. So we decided that adding bump sensors would be a good addition. The bump sensor was not so much a navigation tool as a “get out of trouble” implementation. Whenever a bump event was detected the robot would back up for a set period of time (about three seconds) and then use the DRS orientation to realign with the target.
Shooting
For shooting we implemented a fly wheel style shooter and we found it to be decently accurate. We decided to make it out of foam core to reduce weight and allow for easier alteration. But foamcore has its downsides. It wears out easily and has a lot of potential for deformation. Because of this we actually had to recut our shooter the day before grading. The main advantage we saw to the fly wheel shooter was that we were already familiar with the circuitry necessary to create it and it was easy to reload and use multiple times per race. It ended up being effective enough. We found that in a non-race environment we made about 80% of our baskets. This was good enough given that we had three chances each race to make a basket.
Obstacle
We didn’t think that much about the obstacle until the end of the project but a number of things helped us to navigate it. First, we found that being a light, bottom-heavy bot meant that navigating the obstacle was easier for us than for the other bots. Mainly this manifested itself in the fact that we were able to leave the obstacle without face-planting. Additionally, in order to navigate the obstacle, we switched our bot’s orientation back to front (ie the back become the front and the front became the back). This allowed us to gain more traction when going up the obstacle because the rear wheels remained in contact with the ground and with a decent amount of normal force on them at all times. Fortunately this didn’t mess up any of our other systems and actually made leaving the shooting zone after taking a shot easier (because now we were shooting out of the back rather than the front).
We decided that it would fun for the competition to strap a Go-Pro camera to our robot for the competition. This is the footage from the competition, round 1 from the perspective of the robot. During this round we successfully completed all activities including the 3 laps, shooting and making a basket and going over the obstacle. On our first lap, after some meandering, we make our way over the ramp (0:58). Because our shooter shoots from the back, unfortunately you can't see the basket being made but you can see the crowd's reaction! (Shot starts at about 2:00).