How did you decide what portions of the game challenge to address?
After kick-off we began breaking down the game. As excited as everyone is to start sketching designs right after kick-off, it’s important to understand the requirements for the game. We’ve found the best way to make sure everyone has read the rules is to read them as a team. So right after kick-off we get together, put the manual up on a projector and have everyone take turns reading a rule. As people have questions about rules, we write them down so that we can answer them later.
We intentionally read the manual out of order. We start with the tournament section so that we understand the game’s ranking system and any changes to game play during eliminations. After the tournament section we read the game rules and then the robot rules.
After reading the tournament rules we write down the ranking criteria. This way we can keep in mind what it’ll take to seed high at an event. Then we write down all the ways to score points and all the ways to play defense or de-score points. Then we start discussing possible robot features (shoot discs from the pyramid, shoot discs from the feeder station, pick up discs, climb to level 3 of the pyramid, etc). We try to list all the possible robot features we can think of so we can think of the different types of robots we’ll see in the game. This process also allows us to weed out features based on legality.
Once we’re done with this we simulate the game with people. Each person pretends to be a robot with a different feature set. This allows us to see what happens when a cycler and a floor loader play together or what happens when two floor loaders play together or a level three climber and a multi-disc autonomous. While we’re simulating we start to see which robot types work well together. We can also see which robot types are undesirable and we eliminate them from the list of features we want our robot to have.
During our simulation we found that every good alliance had one of three types of robots: Full Court Shooter (FCS), a Multi-Disc Autonomous (Floor Loading) or a level 3 climber. We knew we wanted to build a robot with at least one of these features. As we started evaluating which feature we wanted to prioritize we went back to the ranking criteria. Autonomous was the 2nd ranking criteria behind winning a match. We also found during our simulations that autonomous was heavily weighted in points. For example, if a 7 disc auto was playing with 2 robots with no autonomous mode and playing against 3 robots who were roughly 60-80% in auto the 7 disc would either match or be very keep their alliance very close in autonomous. On the other hand, if a 7 disc autonomous was playing with two robots who were 60-80% in auto and against 3 robots who were 60-80% in auto they’d come out ahead by almost 2 cycles. That was a huge cushion for an alliance.
Then we thought about things in terms of defense. Being an FCS gave the alliance the ability to score a lot of points very quickly, however one dedicated defense robot with a blocker could take down a FCS. A level three climber gave us the big point value at the end of the match, but being a level 3 climber was probably one of the most difficult tasks of the game. In addition, well placed zone defense could prevent you from having enough time to pull off a level 3 climb. In autonomous, you couldn’t be defended. So we felt there was a higher probability of success with a multi-disc autonomous than a FCS or level 3 climber.
In terms of difficulty, we felt that making a FCS wasn’t very challenging so a lot of teams would do it and be successful at it. On the other end of the spectrum we felt that a level 3 climber was probably beyond our technical capability. We were confident in our software ability and our ability to make a good floor loader.
This is what led us to building a floor loader in 2013.
Since the floor loader meant we were putting all our eggs in the ‘autonomous basket’, we decided we needed to design the robot around autonomous. We asked ourselves “How do we make autonomous as simple as possible?”. This led us to more ‘required’ robot features:
- The robot needed to be short enough to fit under the pyramid. This was to allow us to drive under the pyramid during autonomous.
- The robot needed to have a pickup wide enough to pick up 2.25-2.5 discs at a time. This would eliminate having to turn at all during autonomous since we could drive forward, shoot shoot discs, drive forward, pick up discs, drive backwards, shoot discs.
Both of these features had advantages in the teleop portion of the game, but we felt we needed them to make autonomous easier and more reliable.
What process did you follow to evaluate different approaches to challenges?
After determining what we wanted our robot to do, broke the robot down into 4 systems:
- Floor Loader
- Hopper / Disc Transport / Shooter Loading
- Shooter / Tilt Adjustment
Each group had a veteran student in charge and they would report to the mentor(s) on their progress. Each group worked on several prototypes at one time. For example, the shooter team evaluated U-shaped shooters, linear shooters, wheel weights, traction materials, etc.
Once we get the prototypes to a point where they meet most or all of our requirements, we decide which idea best meets our requirements and integrates well with other systems. From there we begin designing it in SolidWorks. While designing the robot in SolidWorks we occasionally find issues like systems not fitting with other systems. When this happens we usually go back and modify the prototype so that it fits in the model and then re-verify that the prototype works.
In 2013 we ran into this problem on the shooter. The original prototype we used used 6” pneumatic tires. We settled on those because they were heavy, so there wasn’t much ‘spin down’ time between shots and we wouldn’t have to deal with conveyor belt tread which we found was difficult to keep attached at high speed. When we started designing the shooter in SolidWorks we found that the wheels were too big and created interference problems when the arm was down. We found that 4” wheels would work, but that was a pretty big change in surface speed. So we went back to our prototype and tested it with 4” wheels, changing the gearing and playing with traction materials.
How do you go about creating your solutions?
The night of kick-off a few of us went to dinner at an Indian restaurant (Taste of the Himalayas) down the street from the the high school we work out of. Obviously we were talking about the new game and the robot. We started going over all the systems we’d need with a floor loader. We’d need to not only make a mechanism that was really good at picking up discs, but we’d need some way to raise them up into the hopper without jamming and then a way to feed them into a shooter without jamming and then a way to shoot and then a way to adjust the angle of the shooter and a hanger… The robot was sounding like a mess of different sub-systems.
We talked about different ways of approaching each sub-system or ways we could integrate different systems. Then Kiet says “We need a 67 arm. We need an arm that has a bunch of different systems on it, like what 67 did in 2012”. Then it clicked for us. If we put the intake on the end of an arm and the discs rode up the length of the arm, that integrated the intake and disc transport. Then if we put the hopper / shooter loader at the shoulder of the arm and then put the shooter on the underside of the arm. Then we could use the arm to pull off a really easy level 1 hang. This would allow us to turn 6 or 7 different systems into 3 systems.
From that point we started designing and evaluating prototypes on how well they could be integrated on an arm. We split into three sub-teams:
- Floor Loader
The climber team had figured out a simple solution, using the arm, after the first day or two. At that point we had them start working on ways for us to do a level 3 climber. They had some working prototypes, but we weren’t confident we could get it light enough and strong enough to be really effective.
By the end of our kick-off meeting we had a working U-shaped shooter prototype. However after deciding the build an arm, we knew the U-shaped shooter wouldn’t integrate very well. We decided to try some of the linear shooter we had seen pop up around Chief Delphi a few days after kick-off. Once we got the distance and accuracy figured out, we started fine tuning variables.
We knew that we wouldn’t have much time to shoot discs in the autonomous period, so we didn’t want there to be much “spin down” time on our shots since that would slow down our fire rate. We played a lot with wheel weights to find a weight that was still light, but allowed us to shoot discs quickly.
The floor loader was the most challenging of any prototype. For one, picking up flat objects off the ground is hard. However, trying to design a double wide intake that could funnel discs down into a single stack was probably equally challenging. A jam in autonomous was catastrophic for us since we would be unable to shoot if we were jammed. So we spent a lot of time finding ways to prevent jams in the intake system and in the shooter.
We had the practice robot running around the beginning of week 5. The competition robot was running about 5 days early, part of that was copying changes from practice robot to the competition robot. Once the practice robot was done we spent close to a week tuning systems in, finding issues and copying them over to the competition robot.
One of the big issues we had was tuning the shooter in. We spent a ton of time dialing in the amount of pinch between the shooter wheels, the speed in which the discs were being fed into the the shooter, how much pinch there could be on the shooter loader roller, etc.
From a manufacturing standpoint the drum at the bottom of the shooter loader was very difficult. Since the drum sat at the bottom of the stack of discs in the hopper it needed to have a lot of grip to force the disc out and into the next roller. However, the drum had a really high surface speed and so any material we attached wouldn’t stick. We tried riveting conveyor belt material, but it didn’t have enough grip and the rivets just ripped out. We tried using adhesive backed rubber, but the adhesive wasn’t strong enough. We tried riveting the adhesive backed rubber, but that didn’t last long enough. We were really started to worry we’d never find something that would work. One day when I was at work I spent the day doing some research on different adhesive backed rubber products. For the most part all the adhesives were pretty weak. However, I did find that the rubber we had tried previously had the strongest adhesive, but needed 24-48 hours to fully cure. So that night we set up a drum and let it sit overnight. In addition we also riveting the ends of the rubber on the drum. The next day we tried it and we never had a problem. The rubber did wear down from time to time. So all through competition season a few days before we left for an event, we’d set up a drum and let it sit so that in the event we ever had to replace the drum at an event we’d have a fresh one ready to go.
After build season the development of the robot certainly didn’t stop. After our first few practices we weren’t happy with our accuracy in the 3 point goal, so we were actually considering focusing all of our teleop scoring on the 2 point goal. Then the weekend of week 1 competitions we added some software that we called “SmartShot” that controlled the fire rate of the robot. This was achieved by placing an small IR sensor at the entry of the shooter. Instead of the operator having to press the fire button every time they wanted to shoot, they now just held the fire button down and the robot controlled when the discs were fired. This greatly improved our accuracy and so we decided to keep our teleop scoring focused on the low goal.
Between the San Diego and Inland Empire regionals we redesigned the arm gearbox to make it more robust and then we redesigned the intake system so it wasn’t as susceptible to jamming. The other thing we changed between the SD and IE regionals was the front roller on the floor pickup. We had a lot of jams in San Diego. So what we did was change the front roller from one long piece of rubber to two pieces. One half of the roller was a larger diameter than the other. In addition the larger diameter had a larger inner diameter. This did two things:
- The two discs would come in at different speeds. This solves a lot of our jams.
- In the event there was a jam early in the system, the larger diameter roller also acted like a poor man’s clutch so it wouldn’t stall the intake, the the disc on the opposite side could keep moving, freeing the jam.
These changes greatly improved the robot’s performance. After our win at the Inland Empire regional we felt we were lacking in a couple of areas. For one we felt our rate of fire was too slow. We were seeing robots like 469 put an entire cycle of discs into the 3 point goal in 1-2 seconds. Our fear was that at the Championship level people would have seen enough of our matches to realize that a 5’ tall robot that got right in front of us could block us. This happened once or twice at the regional level, but the really good teams will have seen those matches and made notes. We felt we needed to increase our rate of fire to make their window of opportunity as small as possible.
Between Inland Empire and Champs we geared the shooter faster, re-tuned “SmartShot” and got our robot to the point where it could put a cycle of discs in the 3 point goal in about 1-1.5 seconds.
What would you do differently if you could redo it again?
I don’t know if there’s much I would change outside of maybe making the arm gearbox more robust earlier in the season and trying to make the shooter faster earlier in the season.
Quick Facts Section:
- Drivetrain: Single Speed, 4 Wheel West Coast Drive
- Linear Speed: 15 Ft/Sec
- Wheel type: 4” AndyMark Performance Wheels. Black Rough Top Conveyor Belt Material
- Speed Controllers: Talon & Talon SR
- Programming Language: C++
- Official Record: 40-6-0
Additional Information Provided:
Below are some pictures and renders of the robot and its sub-systems:
Up until the 2014 robot, this was probably one of the tightest packaging jobs we’ve ever had to do for the electronics.
Pretty basic drivetrain; nothing too special here. A lot of people ask us why we did a 4 wheel drive. The reason is that the robot is actually wider than it is longer. The spacing between the front and back wheels is just shy of what we would normally have on a 6 wheel drive. Had we gone with a 6 wheel drive there would have been about 10” between the center wheel and the front or back wheel.
This was probably one of the more underrated features of the robot. This sat just behind the front roller and transported discs from the floor to the hopper. We designed this as an easy to remove chassis so that if we ever needed to redesign the position of the rollers (which we did between San Diego and Inland Empire) we would not have to re-make the arms. We also slotted the mounting holes in the arms so that we could also adjust the amount of pinch between the bottom plate and the rollers.
This was the gearbox that powered the shooter feeder.
This is the part of the robot that sat under the arm. The drum that I mentioned above is located back by the hopper.
This is what mounted to the underside of the arms. The two black bars are actually guides that directed discs into the hopper.
- Powered by 2 CIM motors, providing over 750W (1 HP)
- 63:1 reduction (at the gearbox output), 252:1 reduction (including chain) producing over 250 ft-lbs or torque
- Can lift robot in less than ½ seconds
- Pneumatic cylinder that locks gearbox and allows arm to maintain position after match ends
Article Content Provided by: Jon Jack (Mentor 1538)