Team 708
  • Home
  • About Us
    • Calendar
    • Current Robot
    • Videos
    • Mentors
    • Sponsors
    • Contact Us
  • Program
    • FLL
    • FTC
    • What is FIRST?
    • Join the Program
  • Community
    • Local Demos
    • HatterSTEM
  • Events
    • HAVOC
    • HatTricks
    • FRC District Event
  • History
    • 2019
    • 2018
    • 2017
    • 2016
    • 2015
    • 2014

2020 Robot

Team 708’s 2020 robot is designed to be able to efficiently and effectively perform almost every task on the Infinite Recharge field. Our strategy this year was to use our agile swerve drive combined with our large and dominating intake to start the match off by scoring 8 balls. After auto ends we speed to the other side of the field under the trench and quickly gather more balls Then, we race back, avoiding our teammates and the opposing alliance, to rapidly score 5 balls into the high goal. As our robot is intaking, the free-flowing hopper is constantly preparing the balls to be hurled out of our turreting shooter that locks onto its target using its limelight. After we have scored the 29 balls, we can spin the color wheel which mechanism is powered by the same gearbox that we use for the intake and climber. During the last 30 seconds, we raise our arms and extend the climber to reach up and grab onto the bar. Lastly, we climb off the ground to finish the match with our teammates. 
Picture

Season Summary

Picture

Hatboro-horsham

Record: 6-8-0
Rank: 14 (out of 36)
Quarterfinalist
​Creativity Award
Picture
Season postponed...

Weekly Build Season Videos

CAD Download

Picture
708robot_2020.zip
File Size: 46168 kb
File Type: zip
Download File

Robot Poster

Picture
2020_robot_poster.pdf
File Size: 18470 kb
File Type: pdf
Download File

Strategy

  • At the beginning of the build season, we made many important foundational decisions. We discussed extensively how we wanted to play the game, what we wanted our robot to look like, and what type of drive train we wanted during the first few days following kickoff. 
  • During the first weekend, we read through the game manual, talked about ways to score, and broke down how we wanted our robot to play the game. We were able to base the look and functions of our robot off our conversations about what we wanted to accomplish. 
  • We separated various objectives into three categories: needs, wants, and stretches. Needs consisted of things we determined our robot must include, like the ability to shoot in the high port, the ability to climb, and the ability to score in autonomous. Wants were goals we though would be important to succeeding, but not a necessity. These included an eight-ball autonomous and a turreted shooter. Finally, we had stretches. These objectives would be very cool to have, but would require more space, weight, or complexity than it would be worth to implement. Lateral generator switch movement, a buddy climb, and a ten-ball auto were our stretches.
  • We had to make many important decisions about our robot during the early stages of the season such as: high or trench robot, tank or swerve drive, etc. These topics were discussed in length through examining the pros and cons of each issue. 
  • This year, we determined we wanted a high-scoring robot with fast cycle times. We settled on a trench bot with a swerve drive, a drive drain we have never attempted at a competition robot before. Next, we moved into planning the general shape of our robot using the goals we established. We prototyped mechanisms to get a general idea of the space they would need on the final robot. ​

Swerve drive

Picture
  • Following our goal of an agile and maneuverable robot, we decided this was the perfect year to attempt swerve drive for the first time on a competition robot and that it would be the best drivetrain for our strategy and the game. 
  • It was a huge risk for us, considering the cost and complexity of the system and that before 2019 no current team members had worked with swerve, especially on the software side.  
  • We held numerous meetings with the entire team to discuss the decision and we also evaluated how confident our software team was in their ability to program the swerve modules.
  • In the end, we decided it was a risk we were willing to take because it would be a huge learning experience and it was the perfect year and game to experiment with it. Also, due to the rising popularity of swerve, we were putting our team at a disadvantage by not having worked with it intensively yet. Therefore, we decided that because we had a strong team this year, we would tackle this challenge. 

  • As a backup, we set a date we felt safe with to switch to tank drive if we hadn't made enough progress yet and software wasn’t sure if they were able to finish. Software asked for extensions twice because they were extremely close to getting it working and they were confident. 
  • We attempted to design our own swerve drive during the offseason but never finished so we ended up buying two swerve drive kits from West Coast products before the season. 
Picture
  • One thing that made this easier was during the offseason before this year we built a swerve-drive base using the kits we bought. This drive base served to expand our capabilities as a learning experience for team members. Unfortunately, we didn’t have much software time with this during the offseason so we had to write all of the code for the swerve drive during build season. Luckily, the software team had spent the summer reviewing the concept of swerve drive and what was necessary to accomplish this on an FRC robot. In addition, we were able to start writing the code day one of the build season because we already had a swerve drive base. 
  • In order to write the code, we used a combination of some existing libraries and some home grown software to incorporate the use of new motors, motor controllers, and encoders on each swerve module. 
  • By the end of build season into our first competition, we had fine-tuned many issues, and during our first competition, there were few problems with it.   

Architecture & Packaging 

  • As a team, we defined what the robot had to do and then we broke up into various subsystem groups, where we figured out how to accomplish these tasks. We initially prototyped every subsystem independently until we had a general idea of their requirements and the space they would take up. 
  • Knowing the results of prototyping, we had a meeting to lay out where everything could be located on the robot. 
  • Because we had decided on swerve drive, there would be no defined front, so our intake group wanted to have two intakes each located on the long sides of the robot. 
  • We knew that the hopper and shooter would need to be centralized which meant we had to have two climbing arms that would wrap around them. This also left limited space for the intake. 
  • Due to limited motors and space, we decided to have one intake placed on the end of the arms so we could combine the intake, climber, and color wheel mechanism's motors . This was a compromise to have only one intake on the short side of the robot. 
  • The mechanical system quickly took up much of the space on the robot leaving limited room for the electronics, compressor, battery, air tanks, etc. This forced us to place the electronics board on the underside of the robot.  ​

out of Motors

Picture
  • With 8 motors being used for swerve drive and 1 port used for our limelight, we realized that we cannot have each of the 6 sub-systems use individual motors as we would be over the port limit and potentially could have battery issues.
  • ​Thus, we decided that the only way for us to have all the capabilities that we determined necessary was to either  combine systems to use the same motors, or in some cases, use pneumatics in place of motors.
  • The area that we determined would be easiest to combine systems was the color wheel and intake. ​But that was not enough; we were even more ambitious and combined the intake, spinner, and climber into a "PTO style" shifting gearbox that sits at the end of 1 of our arms.

intake, climber, spinner shifting gearbox

Picture
  • Our climber & intake integrated gearbox is similar to a more traditional PTO drive system. The intake always runs and a dog gear shifts to engage or release the climber. 
  • The gearbox is powered by a neo brushless motor. The intake and color wheel mechanism is a 2:1 reduction and the climber is 18:1 reduction. 
  • Due to space allotment, we could not use all parts of the common FRC shifter sold by Vex Pro. We selected the Automation Direct C090025D "pancake" shifter with only 1/4" stroke and fabricated an output shaft that locks into that of the Vex Pro PTO components, such that the entire assembly fits within 2".

Climber Strategy

  • When we first looked at the climber we made the decision to do a linear extending telescope tube to extend out, reach, and hook onto the bar and then retract to lift the robot. 
  • We looked at using constant force springs and a winch initially, but once we decided that this would be powered from the top of the arm we decided against this option. 
  • We then looked at using chain attached to the top and bottom of the inner stage that goes around a sprocket, and when the sprocket spins the tube slides in and out, but the chain was either too weak or too big and heavy. 
  • This led us to using belt in a similar format which worked extremely well for us in Week 1. 
  • Because we wanted to reduce the climbing time as much as possible but only had one motor to use, we knew we would have to reduce the friction in the system. 
  • Thus, we designed and manufactured our own custom bearing blocks to allow for a very stable yet low friction climber that extended to just under the max height of the bar in just a few seconds.​

Climber Prototyping

Picture
Climber Prototyping:
  • In the first couple of days when the climber group met to discuss this years endgame, we looked a lot at the physics of the pendulum and the various heights we would have to reach. 
  •  After discussing the importance of a balanced bar, we started prototyping a mechanism that would allow us to drive on the bar to level the bar. 
  • While working on this, we investigated how we would be able to reach the bar and pull our robot off the ground. Some of the ideas we explored were a light elevator or scissor lift to attach a hook and then use a winch to lift the robot up. We quickly ruled this out because we knew our robot would swing a lot when climbing, making it hard to balance and we could possibly hit our teammates.  
  • We then debated between a telescoping arm and a folding mechanism. We decided we would use a telescoping arm because of our experience of using one, and then we debated whether we should have one or two.  
  • At this point in the season, we knew that the shooter and hopper would occupy the center of the robot and we would have to place the arms on the side, so we choose to do two arms, one on each long side. ​

  •  We looked at numerous ways to extend and retract the arms starting with constant force springs paired with a winch. After some time looking into this option, we determined that we could do better, so we set off to look at other designs.  
  • We considered using chain attached to the top and bottom of the inner tube that wrapped around a sprocket, and as the sprocket spun it would move the tube in or out. We were unable to proceed with this idea because 25 chain was too weak, and 35 chain was too heavy.  
  • We attempted the same thing using Kevlar or similar cables, but this was also not feasible because the stretch in the ropes could cause the system to rock and damage itself.  
  • Lastly, we researched if belt would solve the issues we had because it is extremely lightweight yet strong and has relatively little stretch. After significant time spent researching the qualities of belt on manufacturers' websites, we were confident that the belts would work in this use. Thus, we moved forward with developing a final design for this.  ​

Custom Bearing Blocks

Picture
  • Another thing special about this years climber is we designed custom bearing blocks that would enable us to reduce the friction in the system and allow us to have a shorter overlap the tubes, yet still maintain the necessary rigidity. 
  • We normally would have used PTFE sliders to contain the inner tube when traveling, but we decided that we wanted to reduce the climbing time as much as possible. The way we would be able to do this is to have less friction in the entire system so we could lower the gear ratio slightly. This was mostly just optimization of the system to create the most efficient climber we could. 
  • The initial idea came from doing something similar to what we did for last years' climber and elevator, but transferring it to the inside of a tube. We then looked at other teams' robots for more inspiration to see if anyone else had attempted something similar and how other teams built telescoping arms without PTFE sliders. 
  • We found some and once we felt confident with what it should look like, we looked into what kind of material we would use for the bearings. We tried to find bearings, but they would not have been strong enough or small enough, so we then looked some more and decided bushings would work well for us. 
  • Next, we picked tube sizes and designed the bearing blocks to fit in these tubes. We machined and assembled the bearing blocks and tested it, finding that it worked wonderfully. 
  • One thing we learned from this test was how critical the tolerances in the tube were. 
  • One thing we did to attempt to mitigate this was when picking what tubes to use, we measured them and used the ones closest to the size we needed. 
  • The final tubes ending up being too small for the bearing blocks, so we took a dremel to the bushings to take a small amount of material off, and then ran the bearing blocks back and forth through the tube until it was a good fit. 
  • Overall, the bearing blocks provided a great low friction system that was cheap and provided the strength we needed. ​
  • We made the bearing blocks out of a .75 inch thick, 1.7 by 1.7 inch aluminum block that we then milled to size and shape, and we used a reamer to drill the holes. We then press fit steel dowel pins into the holes and as we put the dowel pins in, we slid brass bushings on. These bushings were what ran on the inside of the outside tube. ​

Climber

  • This years climber consisted of two telescoping arms that allowed us to reach a max height of 77 inches and could extend and lift our robot in under 10 seconds.
  • The outer tubes were 2 inches by 2 inches with an 1/8 inch wall and had an isogrid pattern to save weight. This pattern was on the outside and didn’t go all the way through because the inside of the tube needed to stay whole so that the inside bearing blocks could ride smoothly.
  • The inside tubes were 1 inch by 1 inch with an 1/8 inch wall and had a triangular pattern to save weight. Connected to the top and bottom of this tube was the belt that we used for the extension and retraction.
  • We connected the belt using custom clamps that interfaced with the teeth on the belt to help hold it and we used these clamps to tension the belt so that we couldn’t skip teeth and rack the arms.
  • This belt engaged with a sprocket at the top of the outer tube and there were two bearings to hold it in place. As the sprocket turned, it extended the arms in and out to allow us to climb.
  • The sprocket was then connected to the intake gearbox and we used a dog shifter to do something similar to a PTO in a drivetrain that gave us an 18:1 reduction for climbing.
  • Intake

    • In prototyping the intake, we looked at both through the bumper and over the bumper options. We also tested different types of wheels including vector wheels, high traction wheels, rollers, etc. 
    • All of the wheels and rollers worked and we found both through and over the bumper worked well.
    • ​From a packaging and integration standpoint, we considered if it was advantageous to index the power cells from inside or outside of the robot. We knew the hopper did not require the balls to be indexed and over the bumper allowed for a faster intake.
    Picture
    • In the end, we selected polycarbonate tubes that brought the balls over the bumper because they integrated well with the other subsystems, were as light as possible, and we had experience with them in 2016 with similar balls.​
    • Our intake has 3 polycarbonate tubes the width of the robot, each with 2.5" diameter and 1/16" wall.
    • The intake is powered by a neo with a 2:1 reduction at a speed of 2,000 RPM.​

    Color Wheel Mechanism

    • We prototyped many stand-alone options for a color wheel mechanism; however, we determined that it should be integrated into another subsystem to save weight and motors.
    • The architecture of our robot arm provided an intake at the end, which was above the color wheel in the arm pivot's home position. We realized a color wheel mechanism could run off the intake power, be used in the arm's pivot's home position, and be tucked away when not in use. 
    • This resulted in our "dingus" or color wheel mechanism. The system is pneumatically actuated and has a 1.5" diameter Omni wheel to spin the color wheel.
    Picture

    Arm Pivot

    • We needed a way to pivot our utility arm up and down to be able to intake balls, start inside the frame perimeter, align with the color wheel, and reach the climbing position. This design required three distinct positions of the arm. 
    • In design, we knew there were no motors available, so we decided to achieve this motion using pneumatics. Standard air cylinders have two positions, so we had to figure out a way to get three positions. To accomplish this, we used two pistons that would lift or lower the arms and then two more pistons to hold the arms in the three distinct positions.  
    • Cam plates attached to the arms created an arc of a circle and on the outside rim of the plates, a bearing rides as the arm goes up and down. On the arc, there were slots that the bearings could fit into. Thus, the bearings rode up and down, but when the arm was at a certain position there was a slot that the bearing could fit into and an air cylinder locked the bearing into the slot, holding the arm in that position.  
    • The starting position and the climbing position were extremely close to each other so the slots on the pivot plates were too close for them to work properly. We handled this by making different inside and outside pivot places that each had different slots. 
    • The locking air cylinder was on a lever that would either engage the inner or outer plate. The outer plate engages the down and climber position and the inner plate engaged the home or color wheel position. 
    • One issue we had is that when we initially calculated the air cylinder bore and geometry of the cylinder location, it wasn’t strong enough to lift the utility arm. To remedy this, we cut weight in the arms and intake and removed the second motor and gearbox on the arm. We also increased the air cylinder’s bore and adjusted the geometry to better leverage the motion.  ​
    Picture
    Intake & Shooting Position
    Picture
    Color Wheel & Starting Position
    Picture
    Climber Position
    Picture

    Hopper

    Picture
    • We went with an open hopper design because we felt that we would be able to intake balls quicker and get them more easily from the loading station. Our prototyping for the rotary style hopper was also more promising than our other methods. This also gave us a large area to intake the power cells and jostle them around to reduce jamming and sticking. The system had a low friction sidewall that allows power cells to slide by as the hopper is rotating. A brush in the center helps separate the power cells and apply a little compression against the hopper wall.  ​

    • The hopper is powered by one neo550 motor through a custom 2 stage gearbox. The compact gearbox design is low profile and required mounting from the bottom of the robot. 
    • The bottom of the hopper is a disc that rotates along with the brush using the same motor. 
    • This style hopper takes up a lot of space on the robot. As a result, the required size of the hopper dictated the shape of the robot. In addition, placement of the swerve modules limited the amount of space we had for the hopper.  
    • We discussed extracting power cells from the center rather than the edge but that made the hopper diameter larger, so we decided to extract them from the edge.  
    • Due to a large amount of space this and other subsystems took on the robot, we had to place our electronics on the underside for the robot, which was not ideal but it was the best space we had left. ​

    Extractor

    • The purpose of the extractor is to remove power cells from the rotary-like hopper and normalize their motion leading into the shooter.  
    • Normalizing the power cell motion into the turret is critical for ​consistency. With a turret, we don’t necessarily know the angle of the shooter relative to the extractor at any given time. We needed the balls to feed in with no spin so they contact the wheel the same every time.  
    • Power cell jamming in the extractor will render the shooter worthless for the entirety of a match, so we had to identify all the potential causes of this. Based on our findings, we added a few design parameters to this system. We geared the roller system so that the power cell accelerated as it passed to each stage of the extractor. Omni wheels remove power cells from the hopper tangent to the sidewall. This allows the cells to roll by when the hopper is spinning but we aren’t shooting.  
    • The system is powered by a custom gearbox and one neo550 motor. ​
    Picture

    Shooter Prototyping

    • During prototyping, we focused on testing one variable at a time to ensure data that told us accurate information about each variable. We tested the flywheel type, RPM of the wheel, amount of compression, feeding system, and the backplate material. 
    • We had four separate prototypes for the shooter this year: 
    • Our first prototype was our shooter from 2012 and all we did with this was test numerous types of flywheels. We found that the fairlanes had the best grip while being compact and having a high moment of inertia, reducing the speed lost between shots. 
    • We then improved the design slightly with our second prototype which we built to better allow us to test with the power cells. 
    • The second prototype was sturdier in construction and allowed us to test the compression, hood length, and shot angle.  ​
    Picture
    Picture
    • Up until this point, we were hand feeding balls into the shooter, which we learned led to a very inconsistent shot and it didn’t allow us to properly test the variables we wanted to. In addition, all the prototypes had severe vibration issues, and one thing that helped to improve this was instead of using shaft collars, we used spacers and reduced the acceptable machining tolerances. 
    • We continued to improve the prototypes and by the third one, we added a simple feeder system to improve consistency. Also, we used sandbags to reduce vibrations and with this prototype, we were confirming our results so far and testing the new feeder system.  
    • The last prototype was the cleanest prototype and was very similar to the final design on the robot. This prototype included a ramp and feeder system to further improve the consistency and simulate robot performance, and we were easily able to switch the hood. Up until the fourth prototype, we had been using a thin polycarb plate as the backplate that provided the compression, but we realized that this plate flexed every time we shot which made it slightly inconsistent. To fix this, we instead used numerous smaller polycarb plates stacked side by side to make the hood more rigid. 
    • With this prototype, we tested the new feeder system and the hood length and angle. Once we refined the prototype, we used it to obtain some initial data for software. 
    • Throughout our prototyping, we realized the importance of a consistent feeder system and minimal vibrations because they accounted for a lot of variability in the shots. ​

    Shooter

    • Our shooter can consistently shoot balls from a layup shot at the front of the tower all the way to the front of the trench. 
    • We were able to obtain this range by using a two-position hood powered by a piston and by changing the RPM of the flywheels 
    • When designing the shooter, we knew we had to keep the whole system compact so that we could fit under the trench and so it could fit on top of our extractor tower. This also limited the height of the shooter. 
    • This meant that we could not have a super large flywheel like other teams were doing and that we must stick to a smaller wheel. However, because of this smaller wheel, we had issues with getting the balls up to speed. 
    • To remedy this, we added smaller pre-accelerator wheels that sped the balls up as they passed in between the feeder and the shooter. 
    • This year our robot used a swerve drive for the first time, which normally would be enough maneuverability for the shooter, yet we deemed it important to be able to rotate any direction and still shoot. For example, we wanted to be able to intake balls while still shooting. ​
    Picture
    Picture
    • Thus, our shooter had a turret that allowed us to stay locked on the target as the robot rotated, line up faster for our shots, and it also made it harder for teams to defend us. 
    • We used a limelight camera that would lock on to the retroreflective tape and keep the shooter aimed at the goal. In addition, it would also calculate the distance to the goal and appropriately adjust the RPM and launch angle. 
    • In software, we used the field-oriented swerve to treat the turret as a fifth swerve module to simplify code. 
    • The turret could rotate 1.5 rotations and then spin all the way around to the other side when it reached its maximum rotation. The turret was also custom designed and made in house on our CNC. 
    • We used a wiring sleeving to help reduce the tangling of wires and keep the wires organized and out of the way. 
    • We had some issues with the bag motor that powered the turret because it kept overheating and getting burnt. To fix this, we changed the motor to a 775 Pro and limited the amperage draw. ​

    Software

    Picture
    • To ensure that our robot was agile and maneuvered the field with ease, we decided that a field centric swerve drive using a gyro best suited our needs. Due to having limited swerve drive experience prior to the season, we referenced code posted by many other teams to create our swerve code baseline.  
    • Getting swerve to work was an interactive process that involved a lot of code review, time, and testing. We used our swerve drive base that was built over the summer to iterate through all of our code until we were confident in what we had, knowing that we would continue to tune the code for our final drive base. 
    • After getting our field centric drive base working, we then took the same base idea to program our turret. We wanted to ensure that the robot always knew where the target was using vision tracking, the field orientation, and the position of the turret with respect to the robot. 
    • Using vision tracking with a limelight locking on to the retroreflective tape around the goal, our targeting system calculates the distance from the goal to adjust the hood position and the speed of the flywheel. In conjunction with the automatic maneuverability of the turret, this made targeting fully autonomous. 
    • Due to the limited availability of motor and sensor ports from the swerve drive, we had to combine systems meaning using fewer sensors to control the remaining systems. We used encoders to determine the spinner revolutions and climber extension and retraction to avoid the use of extra sensors. The spinner automatically stops after a certain number of encoder counts, which we calculated to be just over three complete rotations of the control panel for rotation control. By pressing a button on the controller, it will also rotate the color wheel a set number of encoder counts, moving the wheel one color over. The button can be continually pressed so the desired color is matched up for position control. 
    • We have several autonomous routines that run successfully. Our starting position on the field and our role for a match determines which routine we run. Our eight-ball autonomous is one that we are most proud of. Starting with 3 power cells, the robot moves from the initiation line to pick up 2 more and shoots all 5 into the goal. The robot then goes to pick up the 3 balls along the boundary of the rendezvous point, with the shooter constantly tracking the goal, and shoots them. ​

    Coping with Obesity

    • After we completed our robot, we realized that it was approximately 12 pounds overweight.  
    • We combed through every single part of the robot, analyzing them to see if we could save or remove weight anywhere.  
    • Numerous plates and tubes were lightening-patterned on the CNC router, many parts were swapped out for lighter variants, and some mechanisms, like the combined climber and intake gearbox, had two motors but we dropped one. Also, we were more aggressive with pocketing. 
    • By competition, we were successfully under the weight limit, allowing us to compete.  
    • After HH, we lightened the intake by about 2 pounds and solved some jamming issues. Furthermore, the competition sparked other ideas about how to fix the robot for future competitions. ​
    Picture
    Picture
    Picture
    Picture
    Picture
    Picture
    Hatboro-Horsham High School - 899 Horsham Road, Horsham, PA 19044 
    © 2020 FRC Team 708 - Hatboro-Horsham Robotics. All rights reserved.
    • Home
    • About Us
      • Calendar
      • Current Robot
      • Videos
      • Mentors
      • Sponsors
      • Contact Us
    • Program
      • FLL
      • FTC
      • What is FIRST?
      • Join the Program
    • Community
      • Local Demos
      • HatterSTEM
    • Events
      • HAVOC
      • HatTricks
      • FRC District Event
    • History
      • 2019
      • 2018
      • 2017
      • 2016
      • 2015
      • 2014