turrets bade
13 Likes
What if you have multiple?
1 Like
What if they put drive wheels on turrets? And then a turret on top of those wheels? 
saik plz
11 Likes
Since we have a bit more time on our hands, we thought that other teams would like to see our prototyping process for the 2020 season!
Wish, Prefer, and Demand List
Every kickoff, we help guide our season by creating a complete list of robot functions and specifications. We then unanimously classify each item by whether it is a wish, prefer, or demand to have on the robot(W/P/D). Demands are requirements for the robot, items and functions that we deem necessary for success. Prefers are functions that we would like to have, but can be sacrificed for larger robot goals. Wishes are items that might be nice to have, but we will not chase in our designs. Although we create this specification week one of season, we often return to it and edit it through our prototype, design, and iteration process.
This list was crafted with the intended goals of winning both regionals and being the first pick overall in a championship division. The picture above is the real spreadsheet, and below is a summary of the thought process that was put into every decision.
| Specification | W/P/D | Reason |
|---|---|---|
| Score Into Low Goal | Wish | It has a low point value and effort is required |
| Score into High Goal | Demand | Required for high levels of play |
| Score into Inner Port | Demand | Provides higher points per cycle |
| Spin Control Panel | Demand | Can help with getting RP as well as scoring points when power cells are not readily available |
| Color Vision | Demand | Necessary to spin color wheel using automation for driver ease |
| Hold 5 Power Cells at Once | Demand | Maximizes points per cycle |
| Balls Easily Put In From Top (For Assisted Autos) | Prefer | Could help score higher auto points, but deemed that multiple multi ball autos would be easier |
| Vision Tracking For Outer/Inner Port | Demand | Deemed necessary for hitting 3 point shots and consistently scoring 2 point shots |
| Pass Balls To Other Bots | Wish | It would probably be easier for us to finish the cycle ourselves |
| Control Panel Spin & Stop | Demand | Required to be able to score control panel points |
| Shoot From Target Zone | Demand | Believed that this would be our “bread and butter cycle” because a hard stop position is less susceptible to defence |
| Shoot From Trench Close | Demand | Provides a second scoring position that is hard to defend because it is a safe zone |
| Shoot From Trench Far | Wish | Would require incredibly accurate shooting and would not shorten cycle times as we would travel a few more feet to get to the front of the trench |
| Shoot Over Defense | Prefer | While an unblockable shot would be nice, shooting from protected zones can help play around defense |
| Score From Anywhere Close | Demand | Can help speed up cycles when under no defense |
| Score From Anywhere Far | Wish | Driving forward to a closer zone deemed acceptable to hit scoring goals |
| Drive High Torque(IE Push out of defense, push robots out of tight spaces) | Wish | Decided that there was not a big defense risk if we stayed in safety zones, as well as little value in being able to push alliance robots into certain zones |
| Drive High Speed | Demand | Driving fast is important for fast cycles and getting out of defense |
| Driving Under Trench | Demand | Getting through the trench is much faster than going over a bunch of 1 in. bumps + impossible for tall robots to through shield generator if all the robots climbed |
| Push Power Cells Out Of Way | Demand | Running over power cells and getting stuck would negatively impact our cycle time |
| Quick Trench Passthrough | Demand | If driver found it hard to drive under trench, we could put wheels on the side of the robot to help pass through |
| Intake Power Cells From Ground | Demand | Shortens cycles if there are power cells on the other side of the field |
| Intake From Loading Station (high) | Demand | Allows for quick loading from the driver station, which would help optimize full field cycles |
| Go Over The Shield Generator Boundaries | Demand | Important for climbing and traversing field if the trench run is blocked |
| Intake From Trench (autonomous) | Demand | Easy and open place to access |
| Intake PC From Shield Generator (autonomous) | Demand | The Shield Generator is where most PCs are located at the beginning of the match |
| Intake Power Cells From Ground (autonomous) | Demand | This is important for intaking power cells from the trench |
| Get Off The Initiation Line (autonomous) | Demand | This is the easiest way to get points |
| Simultaneously Process Two Balls From Ground | Wish | Being able to intake one ball at a time compared to two or more initially seemed like a trade off we would need to make. This changed later in season |
| No Jamming | Demand | No brainer |
| Climb Alone | Demand | Guarantee points without relying on our alliance partners |
| Carry One Partner | Wish | Initially on the fence, prototyping revealed the complexity of action with the resources we had |
| Carry Two Partners | Wish | Based on our feelings about a double climb we really did not have to talk about the triple climb |
| Climb Center | Demand | Easiest possible climb |
| Climb Tilted Low | Demand | Requires less extension than a normal center climb so demand |
| Climb Tilted High | Demand | Requires much more extension but opens up an option to climb in any case. This guarantees that we will always be able to climb and not be forced to climb right when the endgame starts |
| Climb Non Tilted | Demand | Demand because that is the best case scenario |
| Level (15 pt) | Demand | Balancing the switch gives an easy 15 points just by taking a bit more time to line up and balance |
Climber
Does our robot need an active balancing mechanism?
After building a LEGO model and looking over calculations done by FRC 27, we concluded that we would be able to meet our demand of a balanced climb with drive practice and a static climbing hook.
Do we want a double or triple climb?
We began by discussing the pros and cons of a double or triple climb. A triple climb would be beneficial because it would give us a guaranteed ranking point and 90 points in a match. Some of the cons were that positioning a robot/s would take up all the time in endgame and may negatively affect our last cycle.We also concluded that we would not want to have to sacrifice/fundamentally alter key parts of the robot such as the drive train to implement a triple climb . This led us to look at FRC 148’s Robowrangler from 2018. A small team of students worked on prototyping a model of the 148 Robowrangler but with 12 inch long forks that extend under a robot. They concluded that the forks would be able to hold the weight of another robot, but it would be difficult to prevent it from tipping off using velcro strap mounting positions (at bumper level) like 148 did in 2018. We felt that mounting velcro straps on other robots would not be very feasible as it would be much more difficult to accommodate different designs.
How do we want to grab the bar?
There have been many games with climbing and the most popular and simple solutions have been using a hook. We took inspiration from our 2018 climber hook which was essentially a carabiner attached to a winch. However, we realized that removing the robot from the switch would be a pain if the hook was locked onto the bar. This simplified the design and we ended up with a normal hook that has an angle at the end.
Hook prototype
How does the hook reach the bar?
Our team regularly refers to previous years to help us make decisions. In 2016, our team shot a hook at the bar and in 2018 we used our elevator to raise the hook up to the bar. We then realized the 2016 and 2018 games had walls on the field where the robot could line up with the bar. With this in mind, we decided that a telescoping arm that extends over the bar would allow us to drive into the switch for alignment. We ended up prototyping a telescoping arm using pvc pipes and it seemed to work well. Since the tubes had to be as compact as possible, it was out of the question to use pulley for an “up rope”. This resulted in us using constant force springs for the “up rope” and a normal “down rope” attached to the bottom of the hook. Since constant force springs are flat and easy to attach to flat surfaces, we decided to go with box tubing. This design would be flexible and allow us to have either a 2, 3, or 4 stage arm depending on what we wanted. We derived inspiration from the FRC 33 and FRC 176 climbers from 2016.
CAD Prototyping
After we settled on a design for the climber, it was sketched out in Solidworks to figure out the details of the design. Since our team wanted to build a short bot to pass under the trench, the climber stow height was restricted to 27 inches. At first, in the sketches, it seemed that we would need some stowing mechanism for the climber to fit under the height limit. Because our design was a telescoping arm, we experimented with different numbers of stages, from two to four.
From the picture above, you can see that initially, we were looking at having to rotate the climber down in some way. You also notice that the stow height of the climber decreased as the number of stages increased. This was beneficial, but as the number of stages increased, the larger footprint the climber made and the harder it was to integrate into the robot. However, the hook was changed to drastically decrease its own height, so that overall, the height added by the hook was not 5 inches, but 1.5 inches. With this change, it was now feasible to remove the stowing mechanism of the climber. Doing that ruled out a two stage climber as it was too tall. Thus, we were left with two options: the three stage and the four stage.
The decision between choosing a three stage or a four stage climber was of two things: overlap and complexity. The three stage climber was easier to manufacture as it required less parts. It was also more favorable because it had a smaller footprint on the robot because it had one less stage. The four stage climber, however, allowed much more overlap between stages. This was important because of the concern how drivers could ram the climber into the bar. We did not want the climber tubes to be bent or broken. In the end, we determined that the three stage climber was the most favorable. It had 3 inches of overlap per stage at full extension, which we determined was enough.
Control Panel Mechanism
How do we spin the control panel?
There were two ideas for spinning the control panel. One of the first ideas was to run a wheel on the top colored portion like a bevel gear and the other was to run a wheel against the side like a spur gear. We decided to go with the second option because it would require less actuation and spin the control panel more accurately. It also seemed much easier to attach a color sensor with this format.
Hopper
How do we serialize the power cells?
Mecanum Serializer
When tackling this problem, we initially started working with mecanum wheels to help us serialize the ball. Deriving inspiration from our 2013 intake, we decided to prototype a system where the balls were biased to one side of the robot, rather than the center, to help solve race conditions.
This serializer configuration was nested after the intake to allow us to drive while serializing. We liked how well it seemed to work, but we had issues packaging it inside our robot, and we were not really happy with the speed.
V Serializer
After seeing a successful 6135 prototype of the same design, we started looking into replicating it.
This was one of those prototypes that just kind of worked from the beginning. We liked how simple it was, and how it did not seem to jam. However, we did not like the footprint, the inconsistent ball output, and the motor count it required to integrate with the rest of our design.
Brush Serializer
We ended up testing one ball transportation solutions on the serializer: the brushes. We put them horizontally and ran the two brushes in opposite directions to funnel the balls to the center.
We were surprised this solution worked well. It fit within a reasonable amount of space, was not prone to jamming, and was the fastest solution we found.
How do we bring a line of balls to the shooter?
Vertical J Hopper
The first prototype we worked on was a vertical J, inspired by FRC 254’s 2012 robot.
While it worked well with individual game pieces, we ended up seeing jamming issues with multiple balls in a row.
Horizontal J Hopper
We iterated this vertical J hopper into a horizontal J hopper. The inside belt column was driven, and had passive PVC rollers on the outside. We ended up putting driven belts around the curve to solve dead zone and jamming issues.
While this worked, we still had some jamming issues and were not happy with how it packaged with the rest of the robot.
Helical Hopper
We kept encountering problems with balls jamming when queued next to each other. We derived inspiration from Team 148s 2009 robot and started testing using door sweeps to drive the balls instead of belts or wheels. The theory was that the brushes would bend instead of forcing balls to jam, which would solve our problems.
This worked incredibly well. When we used a polycarbonate ramp, we found that the system would sometimes jam, but adding teflon to the surface reduced the jams. We still had issues packaging this solution into our robot.
Snail Hopper
When packaging issues started coming up in CAD, we decided to try taking the helical hopper and flipping it onto its side.
https://www.youtube.com/watch?v=pdAnofJUs4Y
This solution allowed us to package the climbers on the side of the hopper, store a line of 5 balls, and bring the balls to the appropriate position for the shooter.
We ended up putting our serializer, hopper, and intake solutions together and tested the prototypes as a packaged solution.
Intake
How do we intake balls from the ground?
Over the Bumper Intake
When approaching the problem, we wanted to find the simplest solution that would allow for driver misalignment when intaking. To us, this meant making a full robot width over the bumper intake so we could have more error when picking up balls in auto and teleop. Our initial prototypes worked well, but ended up being hard to package with the rest of our design.
Initial PVC Intake
Brush Intake
Translating these designs to our comp bot ended up being a bigger problem. The initial intake we had used brushed to help pick up balls, which caused massive current draw issues. We ended up trying to fix this, but it ended up being too slow to use effectively in a match. The final iteration we made before our first event ended up working well, with lessons we learned from the different iterations and prototypes.
Official Intake Rev1
Field Modified Intake Rev1.1
Field Modified Intake Rev1.2
Official Intake Rev2
How do we intake from the loading station?
The initial idea was to have enough space between the rollers to grab a power cell from the feeder station. This option, however, would be bulkier and require more than one motor to control 2 rollers spinning inwards. After deciding to go with the car wash serializer, it left enough space for the ball to fall in from the loading station above the open intake. After a few days of drive practice, a cardboard funnel was made to help guide the balls into the car wash.
Loading station idea 1
Loading station idea 2 (cardboard feeder)
Shooter
What shooter design do we want to use?
Going through all the ways of making a shooter, we knew that using wheels to project the power cells would be the easiest and fastest way to shoot multiple power cells in a row. There were two different design considerations: a linear shooter and a radial flywheel shooter. To find out which was better, we began to prototype these different ideas.
Linear Flywheel Shooter
The linear flywheel shooter had a 775 pro attached to a versa planetary gearbox on each side. After testing we found out that it shot PCs very far but was very inaccurate. We thought this could have been due to the wheels being driven by separate motors as well as feeding inconsistencies. Additionally, we deemed it difficult to create a low profile linear shooter that could easily adjust angles for different shots.
Linear flywheel shooter
Radial Flywheel Shooter
To prototype the radial flywheel, we CNCd wooden plates that had holes in it to allow us to change compression. We used a 4” fairlane wheel driven by two 775 pro connected to a 3:1 dual versa planetary gearbox. When testing it we found out that it was pretty accurate and changing the angle of the shot on this setup was something we had done in 2016 and 2017. The radial flywheel gives the power cells back spin, which makes the shot more stable. One of the big disadvantages that we saw was that it wasn’t giving us as powerful a shot as the linear setup did with comparable motors and ratios.
Radial flywheel shooter
Radial flywheel shooter
After going through all the pros and cons, we decided to go with the radial flywheel because it was easier to control the angle of the shot, was much less complicated, and was able to be easily integrated into a robot format we were familiar with.
Should we use an accelerator wheel?
We had many internal debates on if we should have an accelerator wheel, similar to FRC 67 in 2013 or FRC 2451 in 2017, before our main flywheel, to help with shot consistency and range. After much discussion, we decided that we only wanted to shoot from the area in front of the control panel. Having an accelerator wheel seemed to increase range in certain prototypes, but that range was out of our W/P/D spec.
With accelerator wheel
Without accelerator wheel
79 Likes
Oh my goodness. This is so much information and it is going to be great when I get to dissect everything. Btw, great job on the robot like always. It looks like a beast!! (sorry, it is definitely a mandarin 
).
2 Likes
Woah this is amazing! I think there is a lot of value in seeing some of the processes and learning the “why” behind decisions you made. Really impressed with the different prototypes built and your ability to integrate each of them together. Thank you for sharing all of this. For context, what is the timeline on your prototype progression? How far along where you when you knew flipping the helical hopper on its side and storing the 5 balls in a line was going to be the final design? At what point in build season where you at “Field modified intake Rev1.1”?
1 Like
This is amazing! Thank you for writing this all up. There is so much we can borrow from your design process. I’ll definitely be sharing this with the rest of my team. Also, I would also like to know your timeline. How long do you guys usually spend prototyping?
We usually prototype for around 2 weeks but this season it definitely went on a lot longer due to the changes in bag rules. If I recall some of those prototypes were as late as week 4.
2 Likes
We were prototyping for a long time. I think around week 4 is when we really had all the major stuff finalized in prototypes.
The first intake was completed with the rest of the robot late in early week 7.
1 Like
It is also important to note that we prototype continuously as we design and build. If we find a problem in CAD, we prototype potential solutions. A few of those intake videos were taken a week before our first event, because we felt the intake we had wasn’t good enough to be competitive. From the original design, we did probably 3 or 4 CAD iterations, a bunch of different prototype iterations on the original intake at drive practice, and finally made and designed what is currently on the robot.
5 Likes
This is a really great write-up. The prototyping process here is fabulous.
Just wondering, how did the team come to the conclusion to build a static shooter rather than a turret, especially after building a turreted elevator last year and using turreted shooters in both 2016 and 2017?
2 Likes
This is a great question! We realized turreted shooters do the same under defense compared to static ones because vision tracking isn’t always perfect. Looking at the decision as a whole, a turret would add another layer of complexity to the design process, and it would delay the finish date of the robot. We ultimately decided that having more drive practice would be much more advantageous.
A more mechanical answer would be that a static shooter gives us more range in the hood angle while the hood of a turreted shooter is restricted by the ball path.
4 Likes
Regarding the flipping of the helical hopper, it was at the end of week two. We were having a lot of problems with formatting the robot but this style of hopper fit perfectly. At this point, we had some nice whiteboard drawings and then we moved on to a rough cad model. As for the “Field modified intake Rev1.1” it was done at the end of week 8. We had mounted everything on the practice bot except for the climber and control panel mechanism.
2 Likes
Did you have a powered kicker wheel before the shooter to prevent balls from touching the flywheel before it spins up?
Nice auton run. I did notice it looks like you violated rule “G6. No more than five (5) POWER CELLS at a time.” though. So maybe shoot 3 (or more) in your first burst.
Yes we do! When the driver held down the shoot button, the kicker would spin when the flywheel was in an acceptable RPM range. Also, although we never got to it before season ended, the plan was to monitor current on the kicker during auto so we could detect rising edges and count how many balls had gone through to avoid mistakes like the one in the video.
1 Like
Thanks! Yes, in that run we did indeed violate G6 because there was a jam in our hopper. The intent was to do 5 and 3. We were planning on implementing a rising edge detect on current on our feeder wheel to accurately count how many balls went through and avoid this issue.
2 Likes
Hello everyone, we have moved the autonomous video originally linked in this post to our main channel here:
14 Likes
I just read through a lot of the information here about your prototyping process, and it’s really cool to see how much effective prototyping you guys get done over the season. When I was looking more into your robot, I found a video with a closeup of it shooting balls:
I was really impressed by how stiff the hood stayed as you shot balls. Some of the videos of adjustable hood shooters I’ve seen which actuate on rails (especially this year) show significant flex in the hood backing as balls come out, which I’m sure contributes to inaccuracy in the shooter. I assume the concept for what you guys have done here to make the rails slide is similar to what 2056 did in 2016 (shoulder bolt in slot), but can you share any closer pictures/CAD screenshots of your specific design? Is there anything specific you did to maximize stiffness?
Also, from the video and screenshot, it looks like you guys have 2 sliding pieces of polycarb (one on the fixed part and one on the sliding part of the hood). With this type of design, how do you attach the polycarb to your rails? With our fixed hood last year we did zipties to standoffs on the parts of the hood which would not contact the ball, but if you did this in the center I think it would tear up the balls.
2 Likes
I hope this answers your questions!
Rigidity
The orange and teal plates are both 1/4" thick and there are also 10 standoffs holding the hood to the outer side plates. The slot diameter is only 0.001" bigger than the bearing that fits in it.
Polycarb
To attach the two pieces of polycarb we zip tied them to 3D printed curved L brackets. When shooting with the hood up, we didn’t see any visible damage done to the power cells. I think this is because the zip ties are facing the direction of the ball path.
11 Likes