Hey CD,
Team 4099 is going to try the open build approach this season. In the past, our build blog has technically been public (on our website) but we tend to stop updating it as we get to crunch time. Hopefully, having it on here will motivate us to keep it going.
To start it off:
You can see previous years’ code in that organization as well.
Our team meets for both days after kickoff, so we got quite a lot done.
The first thing we do on kickoff day (after reading through the manual and doing a rules quiz) is to list all forms of scoring and all actions a robot can take to facilitate those scoring methods. Then, from there, we listed out a bunch of potential robot archetypes to analyze later. The output of that discussion is here: Scoring Analysis [∞R] - Google Sheets
The next step was to split into groups and look at time-based analyses of different scoring actions based on previous years. For those who are unfamiliar with this method, basically the idea is to find similar challenges from previous years and look at how much time they took to complete by various teams. Then, based on which teams were analyzed, our estimated difference in skill level between that team and ours, and the differences between the challenges, we come up with time estimates for each part of each scoring challenge. Of course, this isn’t perfect, but it’s a good way to have some evidence to back up assumptions people make.
The most interesting of these was the analysis of cycle times for low and high cycles. The two groups that looked at these ended up finding about the same average cycle times for both low and high cycles, assuming that you shot high goals from right up against the wall. At this point, we hadn’t differentiated between shooting for the OUTER PORT and INNER PORT except that shot percentage would be different. Later, we realized that it would be extremely difficult to angle a shot in from up against the wall into the INNER PORT.
The rest of the analysis is in our master time analysis spreadsheet, along with things from the next step: https://docs.google.com/spreadsheets/d/1HxTiwT2nj7xNU2kHgn6TIQcAXMlRn6jYr_vJhOgLr98/edit#gid=1407858903
Another interesting thing that came out of the time based discussion was that we determined that the CONTROL PANEL scoring wasn’t as useful as it initially seemed. We estimated that each cycle for a fairly fast (but not super-elite level) cycler would be about 25 seconds, based on cycle times in 2012 and 2013, and assuming they cycled from both the LOADING BAY and the ground near their POWER PORT. This would mean that we realistically would run 4 cycles per match, maybe 5 if we sped everything up. With four 5-ball OUTER PORT cycles, this would mean we put in 20 POWER CELLS in teleop and optimistically 5 more in AUTO, for a total of 25. This meant that even in our optimistic estimates, we would not be able to put in the 29 POWER CELLS to allow for getting CONTROL PANEL points by ourselves, forcing us to rely on our partners. That’s just for rotation control – position control was way too far out of reach (49 POWER CELLS seemed to us to be unlikely to occur repeatedly until DCMP/Champs).
The most critical thing that we realized, though, was that with the relatively low point value of each cycle, especially at early events, being able to do a level climb by yourself is enough points to be game-breaking. Even if you run 4 OUTER PORT cycles and make all the shots each time, this is 40 points, the same as the 40 you can get for a level climb by yourself. But we also estimated that most competitive teams would realize this and many would be able to pull off the climb reliably, so good cycling would still be critical as a tiebreaker.
Once we did all of the time based analysis, we combined the timings into potential scoring methods for each robot archetype we initially discussed. Then, we talked as a group about which archetypes made the most sense for our team to pursue, and we did some mix-and-match of strategies to pick what actually is optimal.
One big assumption we made after discussing and before picking was that realistically, we cannot reliably get any of the extra RPs this year (we can’t contribute enough ourselves that it would be reliable with minimal help from partners). Therefore, our strategy was based entirely on maximizing points, especially in elims.
We ended up tentatively settling on an OUTER PORT shooter with the ability to do a solo level climb. We considered that the OUTER PORT is large enough that making shots up there from being square against the wall should be very straightforward (later backed up with trajectory analysis), and it’s worth twice the points as dumping. The solo level climb should be able to put up enough points by ourselves in qual matches to win a lot, especially at early events. Hopefully we should be able to adjust just the latching position in elims to be able to potentially have two/three robots level climb (with enough preparation). We believe that this robot will be simple enough to give us enough practice time to iterate on mechanisms when things inevitably break, get actual driver practice, and do all of the little things we’ve missed in the last couple of years that can make our robot more reliable at competition this year.
The first thing we did Sunday morning was to make a list of needs, wants, and wishes for our robot. Before we could effectively do that, though, we had to list out our team’s goals, so the needs, wants, and wishes would be in the appropriate context:
To summarize: early on, we tossed aside the idea of doing a buddy lift (far too difficult for us to do reliably). Then, we worked on needs, which are the bare minimum things we would need to be competitive. Our plan is for the rest of the season to design around needs as basic requirements, fit in wants wherever possible without adding significant complexity, and fit in wishes only if it would take minimal extra effort to do (and even then, they’re low priority).
In summary, we finalized our strategy around what we had tentatively decided on the previous day. This meant that we have five mechanisms: intake, feeder, shooter, climber, and drivetrain.
We determined that scoring high would be more worthwhile than the CONTROL PANEL manipulation. Realistically, we would only be able to do rotation control for 10 points because of the stage gating, whereas the difference between LOW PORT and OUTER PORT scoring would be 10 points after only two cycles. The only way we could make room in the five mechanisms for a control panel manipulator would be to cut one of the parts of the shooting mechanism to make it a low scorer. We did not want more than five mechanisms on the robot because we felt that would be overreach (I think it would violate one of Karthik’s golden rules).
Once this strategy was determined, we split into groups to analyze more specific forms of each mechanism – single vs. double flywheel, vertical vs. horizontal intake rollers, linear feeder vs. open hopper, climber options, and drivetrain gearing.
Climber: Climber - Google Sheets
Drivetrain: Drivetrain - Google Sheets
Feeder: Feeder - Google Sheets
Intake: Intake - Google Sheets
Shooter: Shooter - Google Sheets
Groups did their own analysis and made their case for the optimal mechanism choices. After a group discussion, we made “final” decisions.
For the climber, we decided on a single stage elevator with fixed position hooks. We decided against an active aligning system for a double climb (briefly considered something similar to what FIRST Capital is doing), because we’re primarily strategizing for elims. We feel we could coordinate with alliance partners to add ballast mass and line up right next to each other to make it easier to double level climb if we decided to do that at a competition.
For the drivetrain, we decided to gear at ~15fps, based on the ILITE design calculator. We initially considered 8:84 gearing with the new 8T pinions, but after the meeting ended, realized that the gear would have only 0.85" of ground clearance with 6" wheels and therefore would be at risk of being damaged by the BOUNDARIES.
For the feeder, we decided on some form of linear (or potentially segmented) belt-fed system (no open hopper) to avoid jams. One potential concern with this mechanism is clearing balls out of the path of the intake without allowing them to touch the shooter. Our current plan is basically to have the feeder constantly rolling when intaking to prevent intake jams, then have a separate counter-rotating roller at the top of the feeder to keep the feeder from pushing the balls up too far into the shooter. We want to make sure that the shooter can spin up without a ball being ejected before it’s ready. However, I’m sure there are some better solutions than what we have come up with – if you reading this and have one you’re willing to share, please do.
For the intake, we pretty much decided on a motor-actuated intake with 2" mecanums (this was motivated entirely by @Ryan_Dognaux’s video demonstration with his mecanums on the POWER CELLS and how quick they were able to intake). We decided on motor actuated instead of pneumatic because we most likely won’t have any pneumatics on this robot.
Finally, for the shooter, we decided on a single flywheel with a fixed position hood (to only shoot from right up against the wall) – while we briefly entertained the idea of also being able to shoot from farther away and potentially make some INNER PORT shots, we decided the added complexity of a multi-position hood would not be worthwhile. We decided to try putting extra mass on the flywheel, similar to what teams did in 2017, to allow shooting 5 shots in very quick succession without losing momentum. This may end up being unnecessary just because of how much margin for error we have on the shot.
Tomorrow, the design subteam will begin laying out a conceptual sketch of the robot with these mechanisms and try to nail down at least the dimensions of the drivetrain – we want to go as small as possible. Mechanical will begin working on intake prototypes, while programming will work on beginning code given what we know, and start creating autonomous paths for Tuesday/Wednesday when we will have Falcons installed on our mule chassis.
Blog posts from here on out will most likely be less detailed than this (probably a relief for anyone who made it this far, lol) if only because now I’ll be working mostly with the design subteam and the remaining subteam summaries will be written by students who, not being on winter break, won’t have as much time as me to write this much.
Realistically, this will just be a weekly update barring needing to ask for help to fix issues or something very cool happening.
This week was interesting, as we were not able to meet in our normal build shop in school. We expect to get back to our normal build schedule mid-week 2, but this hiccup did slow down our fabrication team’s progress with prototypes a little. Even still, a lot got done this week, starting with design:
The first couple of work days we had were used to work on the full system sketch. This is the first year we’ve done this in great detail, and it’s paid off incredibly well. Now, when the students are doing their detailed mechanism design, they start their part studios with a derived sketch from this master sketch and they have to think about very few dimensions, since they figured them out earlier in this sketch. The only downside is that making this sketch isn’t really effectively parallelizable, as far as I’ve seen, so the first couple of days had 9 kids huddled around one computer and they rotated who was actually drawing things in.
We drew a lot of inspiration from FIRST Capital’s design. Going into Monday, our intention was to build a robot that just shot for the OUTER PORT from the TARGET ZONE. However, based on the accuracy FIRST Capital was able to show shooting from the INITIATION LINE into the INNER PORT, we decided to try for inner port shots by modifying the robot concept to shoot from the INITIATION LINE.
This also simplified our concept greatly – initially, since one of our design constraints was to intake from the opposite side as we shot from, we had a double bend in our feeder which we were not confident in our ability to get working. This was because shooting from the TARGET ZONE required the shooter to be at least one robot length away from the port so the angle was not literally vertical. Therefore, since we had to shoot across our robot, the intake would have ended up on the same side of the bot as the shooter, forcing the double bend.
The downsides we brought up for this switch were that it’s easier to be defended on the INITIATION LINE because it’s not a protected zone, and shots need to be more accurate because it’s a longer range shot. Additionally, we’re not confident that we will hit INNER PORT shots with great consistency, so we may not see great benefit from this shift. However, because the point potential is higher, and it simplifies the design of the robot, we chose to stick with this concept.
The only major thing that should change from this sketch is the positioning of the intake pivot point – we noticed that as is, there is a 5" gap between the intake roller and the top of the feeder when we’re intaking. We are worried that the ball will sometimes shoot out of this gap, so will likely move the pivot point of the intake to be on that feeder roller and add something to stop the ball from flying out of the top.
We’re planning on running chain in tube this year, because our offseason build of that style of drivetrain was successful and we wanted to build a small and narrow robot this year. The chassis will be 24" wide and 30" long with 6" wheels. Currently, our intention is to use corner omnis and center Colsons, but we have a 1/8" center drop and will be testing all traction wheels to see if the resistance to being pushed is worth the loss in maneuverability.
Our hope is the narrow chassis will make it more likely for us to be able to fit on the rung with wider robots while also making it easier to put our CG closer to the center of the rung when we go up. Additionally, for the first time, we will now be able to easily fit our full bellypan on our OMIO X8 router, making it far easier to machine (last year all the holes fit but we had to manually cut out the outside because it was just over the size of the bed).
The intake is modeled in many ways after 971 in 2016. We’re using 2" mecanums vs. their 4" ones, and the shape of the intake is different, but the concept is the same. We’re using a 1" OD aluminum tube at the front of the robot to prevent direct hits to the 3D printed Thrifty Bot mecanums when intaking from near walls. The side plates are going to be 1/8" polycarb, also to deflect impacts. While this may change because the intake pivot may change, the current plan is to drive the roller with a NEO 550 on a 4:1 reduction (similar RPM to what Ryan from Thrifty Bot showed in his example intake video). We want both the intake roller and the intake arm motors to be inside the frame perimeter at all times, so the roller is belted (that’s the far side of the image). The intake arm gearbox has some interesting packaging constraints where it is right now – we spent a decent amount of time figuring out how we would fit that in. With our narrow robot, this has to fit into the 3.5" of space between the 8" wide feeder (in the middle of the robot) and the side rail. With this design, the plan is to use a NEO 550 with some gear reduction to a VersaPlanetary 180 degree drive kit and a custom mounting plate, then use a 1-stage VersaPlanetary to drive the hex hub mounted to the intake plate. This would get the intake to move at a semi-reasonable speed (currently we have 6:60 into 1:10 for a stupid quick 614.8 deg/s). This will be a pain to get right for the programming subteam, which is one of the reasons we’re considering moving the intake arm up (more space for more reduction there).
We had most of this design done well in advance of the release of the Greyt elevator, but we modified the hood to be polycarb with standoffs once that came out. It used to have rails, but that was mostly because we had no idea how teams fastened polycarb to the standoffs with these types of designs (for those that don’t know, apparently it’s just zipties).
This is our Limelight attachment method. If you haven’t seen it already, check out @AdamHeard’s video on these Keystone 4337 angle brackets: https://www.youtube.com/watch?v=q-VbqeWwro4
They’re super tiny and super cheap, and for teams (like ours) that only have access to routers and no 3D CNC machining techniques, a great way to precisely line up things in 3D.
Our entire feeder assembly seems to have appeared between our last meeting and now, even though today was supposed to be a work-free day 
. But the general idea is very similar to FIRST Capital’s: the intake roller centers the ball and pulls it into the drivetrain, where the feeder rollers grab the ball and push it up. There will be 2" wide urethane belt running between the rollers. The reason you don’t see the bottom feeder roller is that one is going to go in the drivetrain, since it only mounts to the drivetrain.
We plan on having beam break or distance sensors along the ball path to detect how many balls we have, so signaling LEDs can show the drivers how many balls they still need to grab.
Initially, around the bend in this feeder, we planned on only having one roller. However, we realized that if we did this, one section of the feeder would have its polybelts off-center, changing the compression. Rather than worrying about what the new off-center compression should be, we decided to just go to two rollers at the bend, so the whole ball path will have the polybelt along the center.
The climber is, in my opinion, the most interesting mechanism on this robot, just because of design decisions we made due to not using pneumatics.
This design was also fairly heavily inspired by FIRST Capital. We’re using 1x1x0.125" tubing for the climber rails. We’re powering it with 2 NEOs geared at 10:72 on 12T #35 sprockets. This gives us ~1s actuation on the climber.
The interesting part of this climb is that the actual climb is heavily assisted by CF springs. The initial intention behind this design was to find a way to hold ourselves up after the buzzer without using a pneumatic brake, since the rest of this robot was done without pneumatics and we didn’t want to add them into this robot. One of our team members suggested that CF springs would work if they were balanced while holding the robot up. We realized that the heaviest CF springs sold by Vulcan (using the KOP voucher) were 40.9lbs, so we decided to use 3 of those per robot. We hope that even if we’re at max weight, the springs plus the gearbox friction and brake mode on the motors will prevent us from falling down.
More interestingly, though, if (as we expect to be) we are below max weight, and the robot is under 120lbs with battery and bumpers, we get an after the buzzer climb. This is a double edged sword, as if we are trying to line up a double/triple climb when the buzzer goes off, we may ruin the level state of the existing climb when the climber slams down. However, in matches where we are the only climbing bot, it would be quite helpful to be able to cycle till the last second and rush over to get the climb. This was not the initial design intention, but may end up being a nice bonus.
Unfortunately, it seems that the CG of this subsystem is quite high (25" off the ground!!) We hope that the other subsystems will drag that number down way lower. To that end, we plan on running belt up to the shooter wheel to move those motors down, in addition to the motor for the final stage of the feeder.
The mechanical subteam was able to prototype an intake and a feeder. However, due to some oversights in pre-season ordering, we did not have any long hex shafts for them to be able to test a full width intake with. They were therefore able to figure out ball compression for both the intake and feeder (2" seemed optimal for both), but not spacing from the bumper for the mecanum wheels. We will do more testing this week, especially after Tuesday when our new hex shafts will come in.
Programming wrote most of the basic subsystem code for all of the subsystems on the robot, and are currently working on signaling LED code, as well as state machines for multi-subsystem interaction.
One of the tools that made this way faster to do is our new ServoMotorSubsystem class, pretty much copied from 254’s 2019 code. What I think they realized was that almost all the code in subsystems like turrets, elevators, arms, etc is the same, because fundamentally all these subsystems do is move to a target position based on encoder values. The only real differences are the encoder values, units, and PID values. For our purposes, we’re able to use this wherever there is a servoed subsystem (intake arm and climber this year).
I think one of the most important things about these build threads is when teams talk about mistakes they’ve made and how they’ve overcome them. We’re not quite far enough yet to have made massive mistakes with the robot yet, but we did make an administrative mistake a couple of days ago.
We try to avoid ordering parts for a mechanism until we have done a full design review of that mechanism. However, on Thursday, when placing one of our Vex orders for prototyping parts, we thought it would save some money to add in our drivetrain gearbox gears for both robots. We were fairly confident this would not result in an issue, because we had checked the gearing and were sure we would stick with it. However, while we had sketched the gearbox, we hadn’t done an assembly of it yet.
It turns out that the gears we ordered made it physically impossible to assemble the gearbox (the first stage output gear clipped the output shaft by a significant margin). It was an easy CAD fix, but it will result in a great deal of effort to now have to return the gears in question to The Robot Space (and a loss of at least $30 in shipping and restocking fees). If you’re reading this, please don’t rush orders this early in build season – it may end up costing you. We learned this lesson the hard way – no matter how confident you are, review before ordering parts.
This is looking really nice, I hope you keep up this blog!
Great updates. Really admire how you’ve laid out the progress and thought process. Showing teams examples like these of what they could aspire to present information in helps their fundamentals and seeing it from others reinforces that its not only our mentors who like to see these detailed updates.
I skipped a week 
, so a lot has happened since the last update. Overall, we’re just getting into manufacturing, and all the box tubing for the practice bot has been machined, as well as bellypans for both robots. We do the bellypans first because they are the only part on the bot that requires the TubeMagic to be taken off of our Omio X8 (because they take the full bed size to fit). We expect that by the end of this week, the practice bot should be fully assembled and wired up for programming to test and tune. We expect that mid-late week 5, we should be able to start driver practice with that bot while the comp bot is being built.
At this point, we’ve decided to not worry about fixing some things in CAD to try to get a robot built quickly. There are details we could spend a while ironing out to perfect now, but we prefer to have something built so we can test and make potentially larger refinements.
By the way, the Onshape link for the bot is in the first post in the thread.
We’ve done a similar bumper mounting strategy to what 254 has done for the past couple of years. I’m still concerned that we only have attachment points to the drivetrain right at the top of the bumper, but we’ll see how it turns out. Worst case, we can add some tube spacers or something in between the wheels to support the bottom of the bumpers.
We added a second roller to the intake to reduce the dead space and hopefully prevent balls from flying out between the intake and feeder. The polybelt you see here connects to the top roller of the feeder. We’re concerned that potentially, balls will fly out of the gap on the right side of that polybelt (we can’t put a second polybelt there because it will interfere with the intake wrist motor when the intake is up). If this proves to be an issue later on, we will likely change the way we mount our wrist motor.
We’ve settled on using 2 NEO 550s to power the feeder. This isn’t for any particular reason – we could just as easily have used BAG motors or 775pros, but since we have 4 550s we decided to use them here. If later, some other subsystem really needs the small packaging these allow, we can swap them out for 775pros. We briefly considered doing a gear+belt between the top side and bottom side of the feeder, but we suspected we may need two motors on the subsystem anyway and thought overall it would be simpler to just use two VersaPlanetaries.
The intake wrist motor (moves the intake up and down) is a 775pro on a 50:1 VersaPlanetary and a 18:56 gear reduction after that. We measure the rotation through a Mag Encoder in absolute mode in a hex bore housing. Because the intake is very light, we think we should be able to transfer the torque necessary to rotate it through just that one long hex shaft. If that doesn’t work, we can change that gear out for one with VersaKeys and attach the intake to that through bolts.
If you look at the structure of the feeder, there’s only one bearing/bushing hole that goes directly through the 1x1 box tubing. This was a conscious design decision – later on, if we decide to change the compression in the feeder, or the distance between rollers, or anything else, we now only have to re-mill the plates they’re mounted on rather than the full tubes.
Also, because they were so much cheaper (about 50%, I believe) we decided to use the Space Coast Products 18t pulleys on the feeder rather than the aluminum Vex pulleys. These will see very low load, and we honestly could have printed them from PLA ourselves, but we don’t have super reliable access to a 3D printer right now.
Final feeder interesting point: we decided to, for the first time, use shoulder screws and bearings for dead axle rollers in a lot of places. We’re using the 5/8-16 tapped inserts for the VersaRollers from Vex, then using 3/8" shoulder bolts to screw into those to create a super simple to assemble dead axle.
That roller driven by a 775pro in the back used to be a belt stage in the feeder. However, we decided to swap that out for a single roller. The purpose of that roller is basically to stop balls from coming up into the shooter before we’re ready to fire. It also acts as something of an accelerator wheel, since it’s the wheel that will pull balls up from the feeder into the shooter flywheel.
We decided to power the flywheel with 2 NEOs on a 1:1 belt stage. The belt stage is for a couple of reasons – first, we wanted to take load off of the internal bearings on the NEOs – we wanted to avoid the radial forces generated by the ball pressing on the flywheel as the ball passes through from affecting the motor. Additionally, doing the belt stage makes it simpler for us to replace the urethane wheels if we ever need to do that.
There are standoffs around the flywheel – these are primarily for rigidity, but also for safety. Safety wise, they do two things: make it harder for people to accidentally touch the flywheel, and act as something of a barrier if the wheel explodes/delaminates.
The primary thing we’ve added is the climber supports. These are 1x1x1/16" box tubing and are fairly straightforward. Additionally, we’ve mounted the radio and switch to these supports to make them as high up (and far away from motors) as possible.
We also added plates to mount the chain to the climber carriage. This needs updating, because as of now, when the climber goes up, it clips the bearing blocks (reducing travel by 8in).
We prototyped a feeder with the bend the way we did it – this was successful, and gave us the numbers for how much space we could have between rollers and not have an issue with balls getting stuck.
We also prototyped an intake and used that to iron down how much compression we wanted on the intake, as well as the distance away from the bumpers. We also tested this with multiple balls, and observed the same sticking/jamming effect other teams have noticed. However, we also found that simply doing a short pulse out and then continuing to intake pretty much always resolved this issue. As of now, we don’t think it’s a significant enough problem to fix for our week 1 event, though when we have time we will try to prototype/CAD an alternate intake + singulator and feeder. Most likely, it will look like 95’s or 3847’s.
Also, we have two milled bellypans and all the non-climber tube for the practice bot milled:
In the process, we did a skim cut on our TubeMagic, which since last year has had an issue where the middle of the jig is slightly out of alignment with the front and back sides. This made it so no matter how carefully we tramed it, there would be holes in the center of our tubes that would be off-center. We finally corrected this recently by doing some skim cuts along the aluminum rail the tubes square up against – now, the entire rail is aligned with the Y-axis of our router.
Programming got vision alignment working with our mule chassis. We are now able to (I think) seek the goal as well as line up to it precisely. They are currently working on getting path following working on that chassis using the Ramsete controller in WPILib. They also resolved a super weird bug with the drivetrain not stopping after the end of autonomous (caused by our use of “lazy” motor controllers, which was our attempt to reduce CAN traffic from previous years). This bug took enough time to resolve that we didn’t get to work on path following much, but the drivetrain characterization data has been collected so they should be able to get it working soon 
.
Electrical has crimped almost all of our motors and motor controllers with Powerpoles and latching connectors for CAN.
Mentors finished up most of the field part assembly we had to do. I personally didn’t do too much here, but @amanjaiman, @Siris243, and other (not on CD) mentors got stuff done. Embarrassingly enough, this is the first year since 2017 where we’ve had the field parts usable before the robot was ready to test them 
The build space situation still caused issues for us these past two weeks, with some parts being left in our main shop on days where we didn’t have access to it. The mechanical team was still (for the most part) able to find things to do and worked around most of these issues really well.
Our mechanical team has figured out how to use a Boxford CNC lathe at the school. We haven’t used it for anything much since 2016, when it was used to cut a lead screw (don’t ask). Back then, it was operated by a student who graduated that year, and nobody (including mentors) really knew how to use the thing until we found manuals online this year. Now, we plan to use it for simple things like cutting shaft to precise lengths. Unfortunately, it doesn’t have a tailstock, so some potential uses for the machine are not available to us, but even just being able to cut shaft precisely is a big boost for quickly machining gearbox parts and such.
The biggest hiccup I can think of right now is that we’re in week 4 and we still haven’t shot a single ball yet. We had prototypes for a shooter semi-built back in week 2, but there were some issues with it that prevented us from being able to use it. At that point, we decided we were close enough to having actual shooter CAD and it wasn’t worth trying to spend too long figuring out a prototype. Since then, we have had some delays (I would have liked us to have built the aluminum shooter last week, but we had milling issues, unfortunately). Hopefully, we don’t need to make major adjustments to what’s in CAD, but even if we do, we do have a decent amount of time to do so. We’ve tried to learn as much as possible from prototypes built by other teams who are posting on CD, so hopefully things like compression and gearing won’t need changing.
Other hiccups include some major milling errors with our bellypan (unfortunately, a massive waste of aluminum:
We still aren’t sure what the root cause of this was, but somewhere between the contour to cut the bellypan out, and the contour that acts as a finishing pass for the gearbox cutouts and cuts out the battery hole, we had major Y axis errors. We checked the set screws holding the coupler for the ballscrew onto the stepper, which were very tight. In the end, we couldn’t determine precisely what the cause was, but we cleared out all the chips between the pocketing op and the contour op, and the next two bellypans turned out fine. The current theory is there was so much chip buildup near the ballscrew that it jammed the system for a while, causing it to lose a lot of steps.
Also, our new plan to not order parts until CAD was absolutely finalized has kinda come back to bite us – Vex was, as of our last order, out of stock of VersaRoller hubs. Our backup plan is to 3D print some hubs, but as previously mentioned, we don’t have reliable access to a 3D printer this season, so we’ll see how that goes.
Feel free to ask on CD. Many folks will gladly print and send you parts, even in Onyx.
I can only do PLA+ though 
Have you tested how well this works? If you’re using the “run your storage belts continuously to bring up balls with a hard stop at the top to keep them from entering the shooter” method, we found you need a good amount of support at the top. We tried doing something similar, only covering half of the opening, but these balls managed to squeeze by the hard stop and enter the shooter anyway. We also tried something inspired by 118’s 2012 robot, but it managed to squeeze through that too. Those tests we also with pretty slippery belts, whereas it looks like you guys are using grippier polybelts.
We haven’t really tested the roller effectiveness, but we also aren’t trying to run the storage belts continuously. Given what other teams have said about the ball compression, I don’t think the roller will be as effective in its current form, but hopefully it doesn’t need to be since right now it’s basically the last resort if we can’t properly space balls with sensors.
To add to what Aidan said, we did do one test with a compliant wheel roller at the top, and when we ran the prototype feeder continuously, we did observe that balls were able to squeeze out of all but the smallest gaps between that top roller and the feeder. However, we also noticed that if we only needed to use that wheel for a short pulse (if a ball came in contact, pulse roller + entire feeder downwards) it did serve that purpose effectively.
Also, our tests were with a 30A flex wheel – I suspect we may get better results with a wheel that doesn’t compress as much.
It drives! This video is from Sunday night — one of our captains and I missed the beginning of the Super Bowl to get it driving before I went back to college.
This year, by contrast to previous years, we’ve decided to build the practice bot before the comp bot as opposed to in parallel. We think this should help us iron out some assembly issues and make the comp bot a better product on the field.
This past week was basically getting the practice bot to the status in that video. In the process, we discovered a few issues:
Easy fix in CAD, should be fine on comp bot.By the end of this week, we want to have started driver practice with a “fully functional” bot. This means controls and automation should not significantly change so the operator doesn’t have to relearn things. This is a mistake we made last year: the operator got so used to the manual controls we had early in the season that he didn’t ever want to use the (faster and more reliable) elevator presets for scoring.
In the next few days, we hope to get bumper structure done (plus enough of v1 of the fabric) so that we can send fabric and laser cutting SVGs to our sponsor for ironing.
Also by the end of this week, we want to have made significant progress on machining and ordering comp bot parts. By mid next week, we hope to have two full robots ready to drive, so that programming can tune autonomous while drivers are practicing.
This is with a decently tuned flywheel (it’s almost all feedforward) running at 5000rpm from about 9ft out. We shot 3 balls in an attempt to get an idea of recovery time, but we didn’t really get to test that because our feeder is still running pure open loop and we just couldn’t feed it balls quickly enough to get a good test.
This is from earlier, manually feeding balls into the shooter and running at max power (open loop) I believe from ~15ft out.
We made the decision to switch to using 60A neoprene Fairlane wheels instead of the WCP urethane ones because the WCP wheels were taking too long to ship. I had hubs for the fairlane wheels printed at my university on a Markforged printer, and so far, they seem to be working perfectly.
We’re definitely behind schedule at this point, but we did have 2 weeks of lag time built into the schedule. It’s making me uncomfortable how much of that lag time we’re using, but I still feel confident we’ll be very competitive at our week 1 event.
Oh, I forgot to mention:
As we try to catch up on our milling schedule, we need some help to get our Omio X8 running at the speeds it should be at. Long story short, whenever we run at the speeds some have recommended for this router, the machine skips steps around sharp corners. To try to fix this, we’ve significantly cut down the speeds the machine runs at, but this obviously slows down machining times. Does anybody have a good solution to our problem or some diagnosis we may have missed?
We competed in a Week 0 event this Saturday, and it mostly went well. The climber had just been attached to the bot hours before we competed, but it still worked perfectly on the second try. The first was when we squared the input to the motor to make it more controllable in open loop, not realizing that this prevented the climber from going up because squaring makes the output only positive.
Also, we’re very very excited about the climb because this is the first climb we’ve pulled off ever, I think (unless we hit one in 2017). It’s really incredible to me how much progress we’ve made since then, and I hope any of our students reading this realize how proud they should be of themselves for pulling off this robot.
This is just before our first match. That intake actuation is super satisfying 
. This is what happens when programmers get extensive time with a robot to tune things.
Video of our second match at the Week 0 event. Things to improve include auto (we fixed it after this – the issue was we stored a timestamp in onStop instead of onStart , shooter speed calculations (apparently we somehow lost our quadratic regression calculation on this branch? should be fixed now, too), driver practice, climber automation to avoid the issue at the end of the match (should theoretically be able to hold the rung level until a buddy is properly hooked, then go up close to together), and beam break sensor implementation just under the shooter to prevent balls from getting stuck while intaking.
Unfortunately, we only got two matches at the week zero event, but we got the bot pre-inspected so we know what to look out for before week 1. That inspection process took like 1.5 hours, though.
Also, don’t know if you can tell from the pictures, but we somehow managed to wrap our blue bumpers in different shades of blue fabric. Not sure how it happened, but we apparently had some old fabric on hand and that caused the issue. Luckily we caught it before we sent the fabric to our vinyl cutting/ironing sponsor.
My biggest worry going into Week 1 is our auto code. We can reliably hit 3 shots (if tuned, all in inner port) and cross the line. However, I’m not confident this will be enough to win the event. Overall, I’m confident that with some practice, our cycling + reliable climb will get us to the level where we can probably partner with a great auto team and it stops being an issue, but really it would be a lot better if we could get our path follow code working. Right now, the issue seems to be either a bad NavX or us missing something stupid:
Hopefully, we can get this worked out soon enough that we can at least attempt a >3 ball auto by the start of week 1, and hopefully tune it enough during competition to get it reliable by elims. Other than gyro issues, we seem to have figured out other issues we had (unit errors and the like).
Not anything technical, but we were warned by a CHS LRI at Week 0 that there is a possibility they will rule the Limelight LEDs illegal at competition if teams complain about the brightness. I really, really hope this doesn’t become an issue. I’m sure it would cripple far more than just our team if they did this. We were told to bring a ring light to put around the Limelight as a potential backup plan, but the issue is 1) this was one week in advance of the competition, and we would need to do custom regulator wiring and whatever else is necessary for the ring light for the first time ever in that time, not to mention shipping time for the LEDs, and 2) we would have to find a ring light that was less bright than the Limelight, and there is no guarantee such a light would even work for our purposes while also being dim enough to not cause teams to complain.
We started the season well ahead of schedule for design, then due to CNC machine issues fell way behind schedule with fabrication. I’m probably not as concerned as I should be about the status of the competition bot (not fully assembled yet, but pretty close and mechanically identical to practice bot so hopefully minimal additional tuning?) Also, it’s good to have a backup plan (fully functional practice bot which we can compete with in the worst case).
But it does look very nice, so there’s that:
Got a chance to see your team at the CHS week zero and the bot looks solid! You all put yourself in a pretty good position with week 1 coming up. Please keep posting as the season progresses. I have really enjoyed seeing how your team has tackled issues and moved through this season.
Today felt like we made a lot of progress, but ended up being a bit of two steps forward, one step back.
As Parth talked about, we’ve been working on our auto using WPILib Trajectories. Today we figured out that our navX was calibrated incorrectly, since two years ago we had calibrated it for a vertical roboRIO. After fixing that, we had trouble with the bot slowing down in the middle of the trajectory and speeding up again.
We didn’t manage to debug this during the meeting, but after we realized that our kV and kA were in meters/second(/second) per volt, which we fed directly to the Talon arbitrary feed-forward, which expects percent output on [-1, 1]. This meant that the robot was going much faster than it should’ve, causing the Ramesete controller to correct and slow it down. Annoyingly, we actually fixed this bug on Monday, but tested with a different laptop today. The code which fixed it never got pushed to GitHub, so we accidentally reverted our changes.
Our competition robot looks a lot cleaner now, with most of the wires actually being ziptied down. We hit a snag with our shooter wheel - one of the bearings was put in with the flange on the wrong side, throwing off the spacing for the entire thing and pushing the flywheel off center. The only real fix for it would be to disassemble the entire shooter and flip the bearing. We’ll see if we end up needing to do that tomorrow.
The one notable omission on the competition robot is the climber. Most of it has been milled, but it hasn’t been powdercoated yet since it’s too large for our oven. We’re hoping to use the schools ceramics kiln to coat it tomorrow, so hopefully our milling goes smooth tonight.
On the bright side, we finally replaced the LED board on our 2nd Limelight, and it actually worked… but one of the Weidmuller connectors isn’t holding on to the wire well. We’ll have to see if this is an issue with the wire or if we’ll need to relegate this Limelight to the practice robot.
Some Week 1 concerns at the top of our minds are a lack of driver practice and a lack of batteries. Our practice bot is ready, but we haven’t had a lot of time in a gym lately to get cycling practice. We’re hoping to get a couple hours in tomorrow, but our driver isn’t able to be at our meeting on Thursday, when we need to load our trailer. We do have a half day on Friday, meaning we’re able to practice from 12 to 5 that day. As of now, the plan is to practice then with the practice robot and have our drive team come down late in the evening.
A pretty great (though quite sad) recap video for our 2020 season
I wrote up a short update after week 1, and meant to give another update after events were cancelled. This is, of course, very late, but better late than never, I think.
A lot of the weekend didn’t go exactly like we’d have liked, but we’re optimistic we’re still on track to reach DCMP, and (assuming we improve significantly for week 3 and beyond), potentially qualify for champs.
Saturday morning
We were all pretty upset about not being able to compete week 3, especially as we had just gotten our shooter tuned in, a 6 ball autonomous working, and our intake + feeder upgraded. But after we got past the immediate grief of losing a competition season, we quickly moved on to creating plans for doing robotics (and our normal offseason plans) in a socially distant environment.
After event cancellation, we had a meeting to talk about the things that went well and things we could improve for next season. The list was quite long, but I’ll share a little of the “things to improve” list as it relates to doing better competitively:
More driver practice. This one is pretty obvious, and something nearly every team would benefit from (even those at the very top). Historically, our problem has been that our robots are not completed quickly enough to get any meaningful amount of driver practice. This year, though, we finished our robots earlier than usual but still didn’t get that much practice. We learned that it’s important to have scheduled practices in a usable facility for driver practice – we often had the issue where the drivers were not available at the same time that the robot was ready to use, and that the space we had to practice in was not great (if we drove fast, since the carpet was not affixed to the ground in any way, the carpet would slide a ton, etc).
If it’s not tested, don’t compete with it. This year, our practice bot was ready for week 0, and it competed there. We also had quite a lot of testing time with that robot, tuning the shooter and getting it fairly accurate from many distances at home. Unfortunately, we made the mistake of thinking that in the couple of weeks before competition, we could get our all black powder coated robot together quickly enough that we would be able to get it to perform identically. This was a mistake, and in the future, if it’s not ready a week in advance of the competition, it won’t compete. Had we used our practice bot, the shooter likely would have been a lot more accurate, and the drivers would have been able to practice more (some components were stolen off of the practice bot to make the competition bot work, rendering it somewhat inoperable).
My personal favorite: make sure to review match footage carefully before deciding what to change for later events. Going into week 2, when we were making changes to the robot, we heavily prioritized auto, shooter tuning, and intake fixes, putting feeder changes as something of an afterthought. After events were cancelled, though, we looked back at match footage, and it became clear that the feeder was the biggest problem we had outside of driver practice. The initial gut feeling of what we thought the problems were drove our decision making process, but it ended up being incorrect.
Usually, during the summer, we host RoboCamps, our youth outreach camps based on team 1678’s camps by the same name. These camps use the VEX IQ summer camp curriculum to get young kids (elementary and middle school) interested in STEM and robotics. The kids who have participated in the last couple of years have had an excellent time, and those who have come to our high school since have joined our team.
These camps are really great, because 1) they get young kids involved in STEM, 2) they provide a more consistent pipeline of robotics-interested kids into our team, and 3) they are one of our most important revenue streams for running our team. Unfortunately, they also obviously rely on in person meetings. We knew that with students staying home all of summer, some type of camp would be something many would be interested in, but even in March, we were not confident in being able to have in person gatherings for camps in June or July. We briefly considered stay-at-home VEX IQ camps similar to what some on this forum said they’re doing, but we were not confident in our ability to properly sanitize all the kits and ensure no spread of COVID-19.
Fortunately, two of the strongest areas of our team are design and programming, both topics that can be taught in a socially distant setting more easily than most robotics concepts. That’s why this year, we chose to create FalconCamps (not gonna go into too much detail about what FalconCamps are; there’s more info in the linked thread). Today (6/22) was the first day of the first session, and it went well (or so I’m told by the counselors).
Nearly all of both Design and Programming FalconCamps were planned, written up, and executed by our extremely hardworking and talented students. I could not be more proud of the job these students have done over the past few months putting together an excellent curriculum, doing advertising, making the website, and more. I pretty much only had to do minor reviews and corrections. Anybody who has organized camps like this knows how difficult this stuff is, and these students pulled it off without a hitch
The other project we planned to do after event postponement was a robot redesign. Before we knew how long COVID-19 would impact the world, we were thinking that money we had saved for DCMP registration could be rolled over into next season, while we would maintain most of our fundraising for 2021 as well. This led us to plan an ambitious offseason where we were going to try swerve for the first time. We started to CAD a very ambitious offseason robot (short turreted swerve robot) with the expectation that even if large parts of the robot didn’t work, the primary goal was to implement new-to-us mechanisms for the first time to hopefully be able to use them in future seasons.
When FIRST announced that the 2021 season would reuse the 2020 game, we postponed these plans somewhat, because we felt that whatever we put significant effort into during the offseason should now be something that is going to be competitively viable for us. As a result, after FalconCamps end, we’re going to work on our offseason robot redesign V2.
We haven’t really talked about this as a full team yet, so the following are my personal thoughts rather than team decisions.
During most build seasons, for teams to be competitive, they need to make a tradeoff between driver practice/testing and more robot features. The vast majority of the time, teams (including our own, usually) go for more features, resulting in competitive failures. This year, with people practicing social distancing, we’re in the unique position of not having to make these tradeoffs. We can CAD and program a complex robot, and it won’t take away from driver practice time – because we can’t practice now anyway. Of course, there will still be tradeoffs in terms of testing time (more features means more total testing time needed to get to the same quality of output) but this tradeoff is a lot less severe than it is for most seasons.
For this reason, I’m currently of the opinion that we can go a little more ambitious during our offseason redesign than we would during a normal competition season, while still being confident that we’ll be able to produce a competitively viable robot. I don’t think the initial short turreted swerve is viable, but something that looks a lot like 2056’s robot (but less insane software) would be a good option, I think.
If you’ve made it this far down the post and think this mindset will sink us competitively next season, please let me know before we meet to discuss plans, haha.
Historically, one of the biggest barriers to our team’s success has been a lack of driver practice. This year, even though we had time to practice, we didn’t have a great place to do it, which was one of the biggest reasons we didn’t get as much practice as we would have liked. We’re currently in tentative talks with local businesses who have enough space for at least a half field, but hopefully a full field. This would be great for us, since otherwise the closest practice field to us (that we know of) is an hour away, and transporting tall robots far away is a chore (again results in less practice than would be ideal).
Overall, while 2020 did not go at all as we expected, we hope and expect that 2021 will be a historically good season for us – if things go well, we should be able to address nearly every problem we had in 2020.
ooh, shiny
With the 2021 season effectively being a continuation of the 2020 season, and with most of the design process of this robot being in one post, I think this thread can just be for the combined build log for the two robots.
Also, if you stop reading here but have thoughts on the robot design, we welcome (and actually, are actively asking for) any feedback! Hopefully there are people who are bored over this vacation.
Also also, if you stop reading here, we’d like to thank a ton of teams whose work both inspired us and made our jobs a lot easier. This robot is effectively a Frankensteined bunch of robots we liked various parts of, so we really couldn’t have designed this without those teams.
As I briefly mentioned in the last post, we planned on doing a redesign of our 2020 robot for (whatever happened with) the 2021 season. We made plans for this for two reasons: this gave us a unique opportunity to be able to look at flaws in our 2020 robot and make massive revisions to them, and we really wanted to at least CAD and program a new robot for 2021 to make sure that students had as much of the FRC experience as possible even during the pandemic. With that in mind, we planned on having our team kickoff in mid September, after the school year started and a couple of weeks of workshops to get new members at least able to participate in the strategic aspects of kickoff.
Of course, nothing ever really happens on schedule, but in this environment, that was totally fine. We took a relaxed approach here, allowing for more workshops to be fit in before kickoff, and especially before CAD work really started. Our initial plan was for kickoff in mid September, but we pushed it to the end of September for more workshop time, and then only started CAD in late October.
One of the new things we tried this year was in response to a discussion on how to avoid overreaching in the future. In the 2020 season we did a pretty decent job of this (our issues this season were not, I think, primarily due to kickoff strategy) but in the past we’ve definitely had trouble with this. The conclusion we came to was to think about if we can concieve of any robots at all at the highest level of play we’re realistically trying to reach that will skip a given feature. If it’s something that any robots at that level of play could realistically get away without, we would have to have some really strong justification to consider that feature ourselves.
With that in mind, we also decided to immediately discard that philosophy for the 2021 season 
. Just kidding, but we did decide that with this effectively being an offseason robot, we could pick a couple of areas to try something fancy, with the hopes that we could learn how to do those mechanisms effectively in case we needed something similar in a future year. Also, if we had decided to stick to the zero overreaches strategic approach for this robot, we would probably have built something very similar to our 2020 robot, and that would not have been nearly enough of a challenge.
One of the “fancy” things we decided to try, before we even talked about strategy during kickoff, was swerve. We had been thinking about doing swerve for a couple of years at this point, and with the low cost of the Thrifty Swerve and the pretty good WPILib support for swerve at this point, we decided this offseason was probably the best time we would ever get to try swerve for the first time.
Other than swerve, we didn’t have any features we considered to be “fancy” until way later in the build process.
So using our new “no overreaches” plan, we realized that in 2021, we could actually have data on what robots at the highest level of play did, rather than just having to guess. We categorized a bunch of teams into “tiers” (Einstein bound, DCMP first pick, etc) and tried to analyze what strategic actions those teams took. We emphasized that what we cared about was not what those teams had the capability to do, but rather what they actually did in matches. Of course this was not perfect, since we didn’t get to see gameplay beyond week 2, but it helped us catch things like low robots that preferred to cross the generator switch area rather than go under the trench (the idea being that if they didn’t actually go under the trench there’s no advantage to being shorter).
https://docs.google.com/spreadsheets/d/1G0P4CUBFCePQ3ktBITnnOWEw00GQtA3zMPmn2Tz6hsE/edit#gid=0
Based on this analysis, and goals we came up with beforehand, we decided on the following needs, wants, and wishes: (everything below wishes are things we didn’t consider)
As for the 2020 season, the needs are things we design the robot around, wants are things we try to fit in if it doesn’t add significant complexity, and the wishes are things that we don’t actively try to fit in at all, but if it’s a trivial change to make them happen, we will do it. An example of treating “shoot beyond control panel” as a wish would be to pick hood angles and everything without considering the long shot, but then if it turned out the angle we picked could be used for the long shot, we would consider adding a flywheel setpoint for it.
One of the other new things we tried this year was to take a scrum-based approach to building the robot. We had been looking at this since midway through the 2020 season, after we heard about other teams using a similar structure. Basically, our implementation of this was to split the team into robot subsystems, rather than just subteams like mechanical or design or controls, to allow for each group of students to take a broader approach to the robot. This way, even students focused on software would get a little bit of mechanical experience, and vice versa. We hoped that this would both broaden students’ horizons and allow for more continuity in work (so people work on the same project every meeting, so they can see progress etc). On that note, we also decided that each student would have to sign up for both a technical and a non-technical subteam, even if they decided they primarily wanted to focus on one side of that. This was for two primary reasons: first, to get more students to take part in our business and strategy subteams, which we needed, and second, more importantly, to better achieve a part of our team mission, which is to show more people that STEM can be fun. This way, students who join primarily for a non-technical subteam would still do at least a little of the robot work, so they might potentially realize they enjoyed it more than they initially expected.
With everything being online for now, we also decided we would significantly scale back on meetings. Our student leaders brought up (and I agreed based on this semester of university being online) that when being in a Zoom call for a long time, it’s significantly more difficult to stay productive than at an in-person meeting for the same length. That, in addition to having no hard restrictions on time for designing this robot, led to us scaling back meetings to two 1-hour meetings per week, rather than the normal in-season schedule of 2-hour meetings every weekday and a 6-hour meeting on Saturday.
So, how did all of that go? After writing all of this out, I realize we stuck to this a lot better than I thought we did. On the note of widening students’ horizons: we did a pretty good job of that with the technical/non-technical stuff, resulting in us having more activity in our non-technical subteams than I can ever remember. For the “give mechanical people controls experience” side, though, I definitely hope we do better in future years. Most of the issue here was, I think, because of the nature of online calls rather than working in person. If we had both design and controls in the same call, people would just be talking over each other as they worked on different things, so we ended up splitting the calls, resulting in very little of students doing work on both. I think with in-person meetings in the future, though, this may get better.
For the meeting times: for most of the design process, we did stick to two one-hour meetings per week. The initial goal was for a lot of the work to be done outside meetings. Historically, we haven’t really been able to do this because our team is relatively new to doing CAD (going into 2020 we only had two CAD students with even a year of CAD experience). This year, that was a lot better, so some subsystems were able to get a lot of work done outside meetings. However, there were still a couple of subsystems that had primarily new CAD students who needed more help to do work, so those subsystems did have to expand to three meetings a week in the last couple of weeks as we came up on our self-imposed deadline.
As with the 2020 season, I was not very involved with the software side, so I have little insight into how the software developed over the past couple of months. If you look at our code and have questions, though, I’m sure someone on the controls team can jump in and answer anything.
Yeah, this is the section with the pictures.
The other interesting design decision here was how heavy this subsystem is. Without bumpers and the battery, the drivetrain weighs 43lbs on its own. This is because the bellypan is unpocketed 1/8" aluminum, and the side rails are unpocketed 1/8" 2x1. We made this decision largely based on looking closely at 2056’s 2020 robot, when compared to our own 2020 robot. One of our goals this year was to make the robot more controllable, and part of that was to make the robot less tippy. Our 2020 robot, in response to 2019 being nearly overweight, was super light – we weighed in at our competition at 90lbs. But a lot of this weight was fairly high up, resulting in a robot that was apparently pretty difficult to drive. At competition, we tried to address this by adding ballast mass to the drivetrain, but finding a good attachment point to make things secure was pretty difficult.
This year, we realized that teams like 2056 used 1/8" sheet metal for their entire drivetrain, likely making it fairly heavy. We realized that there’s no point in lightening everything, only to later come back and add weight back to the drivetrain. Instead, we decided to start with a super heavy drivetrain and remove weight later if the CAD was looking like the robot was too heavy. The first place to cut weight from this robot is everything other than the drivetrain, then reducing the side rails to 1/16" wall, then reducing the bellypan to 0.09" thick, then pocketing the bellypan.
To keep the climber up at the end of the match, we have a pneumatic cylinder, which when extended, goes through the inner tube and prevents it from extending. This is on a single solenoid so at the end of the match it will automatically brake, so a last second climb will hold.
The shaft across the tubes is meant to prevent the tubes from flexing towards each other. In 1923’s reveal for this year, we could see that before they added a similar beam, when climbing on a non-level rung, one of the tubes would flex towards the center. We may end up changing this shaft to something more substantial like a tube spacer.
We have three rollers, all powered by one Falcon 500. We chose this motor so we wouldn’t have to package a motor controller nearby on the moving subsystem (compared to a NEO or NEO 550). The bottom roller has 3" compliant wheels on it, so the linear speed on it is higher than the other rollers (which are just bare polycarbonate). I think the advantage of the faster bottom roller is that the balls come off of the ground faster, so we don’t drive over them, though to be honest we picked this architecture entirely based on 3847’s success with it. Usually we would prototype, but without in person meetings, that’s way more difficult. We chose this over our 2020 robot’s mecanum wheel intake because we realized that with mecanum intakes when compared to full-width roller intakes it’s just not possible to intake multiple balls as quickly from a wide area.
I think the lesson we learned here is to avoid mecanum intakes, and anything that centers the game piece outside the robot before lifting it off the ground, in games where you have to hold multiple game pieces. Even if a mecanum intake centers the ball in 0.1s and then pulls it in, that means you can’t just drive through that ball and into the next one you want to grab. Instead, you have to stop at the first ball, wait for it to come off of the ground, and then continue, unless you want to risk driving over the ball. In a game like 2019 where you only want to grab one cargo ball, this waiting time is fine, since driving through that one game piece doesn’t give you as much of an advantage. But in games like Infinite Recharge it significantly slows teams down, which you can see in a lot of teams’ match video when they try to grab balls from the open field.
In addition to the rollers, to add rigidity to the intake, we have a couple of tube spacers that just bolt directly to our intake plates.
This is the cross section of each of the rollers we’re using. To make swapping out the rollers easier, we decided to use dead axles here. From left to right: we have a shoulder screw, a bearing, a spacer, a hub for the roller with an integrated pulley, and a heat set insert for the shoulder screw.
This will be the first time we’re trying this, and the first time we’re printing parts that need the heat-set inserts. There’s a couple of issues I can foresee with this, that we would appreciate feedback on.
First, I’m not sure how well a roller like this would take even light impacts. Theoretically it shouldn’t need to take any real impacts because of our tube spacers, but you never know how things may play out, so I would like to make this stronger if necessary. Currently, the shoulder screw goes all the way through the pulley to try to get that steel part to prevent the pulley hub from delaminating, but I’m not sure if that will work. We also plan on printing the hub out of a strong nylon to try to make the roller as strong as possible.
Second, I’m concerned that the installation of the heat set insert will deform the plastic around the shoulder screw enough that it won’t fit in the hole anymore. It’s currently a pretty tight fit so that the shoulder screw properly adds strength to the part so a little deformation would cause a big problem.
We needed two motors on this subsystem: one for the bottom sliding floor, and another for the vertical feeder section. This arrangement, along with a couple of beam break sensors, is intended to allow indexing balls in the vertical feeder section.
These plates still need a little work – we need to add beam break sensors to allow for indexing balls, and the plate pocketing needs fixing (mostly because it could definitely look nicer). We also want to add some passive mechanism for balls to be centered inside the vertical funnel part. Most likely, we’ll end up doing what 2056 did with unpowered polycord rollers on the sides forcing the balls to the center.
The vertical part of the feeder is tilted back to allow the shooter to be as far back on the robot as possible, to allow us to take the target zone shot.
One other interesting part here is the crossbeams that the hopper and feeder are mounted to. For the 2020 season, we had similar crossbeams, but we put them in the profile of the drivetrain, as opposed to now, where we have the crossbeams on top of the drivetrain. We did this to increase modularity – now, theoretically, we can assemble the full drivetrain and the feeder separately, and then just assemble them together. We can also then easily replace the feeder if it somehow breaks.
Initially, the plan for this mechanism was just to do a single position hood for a robot designed to shoot from the trench. We mostly finished the CAD for this super early on, though, so to give students more to do, we decided to also CAD an infinitely variable hood (with linear servos) and a pneumatic two-position hood. Primarily, the goal was to be able to hit the target zone shot, after teams like 1690 demonstrated incredible 3-point accuracy from a couple of feet back from the wall.
The two position hood was designed to take these two shots – the trench run shot and the target zone shot. To maximize the chances at the 3 point shot, we picked a 65 degree angle from the vertical to release the balls, allowing us to hit the inner port if we were a couple of feet back from the wall. For the trench run shot, we used a 24 degree angle from the vertical, which is the same as we had last year, because we had some success for the medium to long shot with that angle last year.
One issue we’ve had with the two position hood so far is that it seems that we can’t use a single Limelight to see the goal both from 2ft away and from ~30ft away. Currently, we’re planning on trying the beta Gloworms and using two of them, one for the close shot and one for the long shot. The nice thing is that the close shot camera also may be able to help drivers line up the climb, if that’s necessary. If we have any major issues with the Gloworms, we can relatively easily change to using the Limelight we already have.
Compared to our 2020 robot, we also changed our inertia wheels (from large aluminum disks we made in house to the SDS COTS flywheel), motors (from NEOs to Falcon 500s), and the gearing (from 1:1 to 1.5:1). The motor and gearing changes will also help us with taking shots from the trench run. I’m thinking, though, that whenever possible, we want to play the front court game (just grab balls from the opposing loading station area) and take the target zone shot) since we should be able to swerve around defense more easily than most bots.
Missing from the CAD currently are the polycarb plates that act as the hood backing, the ziptie holes in the 3D printed curved pieces for that, standoffs in the back for stiffness, and the Gloworm mounting.
Honestly, the fact that anything at all got done in a timely fashion given the nature of this season is really impressive, and it’s even more impressive that the students were able to design something of the quality that they did.
I’m also really happy with how our process changes worked out. There’s probably a lot that we did this year by necessity that we will do in future years because it just works better. For example, we may have CAD members not come in every day but instead do a lot of work over video call.
On an individual level, I’m very proud of the new design members, in particular in the shooter group, who took charge of the design of a pretty complicated subsystem and took initative to learn to keep their group on schedule.
And finally, I’m proud of myself for finding the time in my least favorite semester at university to be able to help these students design the best robot we have done yet.
We currently have plans for a contact-free build process. We recently got a machining sponsor, who will likely make a lot of our sheet parts, and the remaining parts and tube can be run by some combination of our experienced students + a parent and myself in our shop. We’re planning on doing the machining like this, limiting contact down to zero (nobody is interacting with new people directly in this process), then kitting parts together into totes alongside some tools to allow volunteer students and their families to do assembly by themselves. In theory, there shouldn’t be any need for tools beyond a rivet gun, allen keys, a screwdriver, and a drill to do most of the assembly. This way, we plan on building the robot without having any in person meetings. We plan on starting this next week.
After the robot is built (hopefully by mid-February), we need to start doing some type of driver practice. Most likely, for now, this will just be giving the robot to the driver and having them do drills by themselves in a basement or on carpet on the pavement outside or something.
We’re really happy to get back to doing robots, even with the process as different as it is this year. Hopefully, future blog posts will be more regular (and therefore, not quite as long )
Your team may find it beneficial to have your (lead) designer(s), builder(s), programmer(s) and pit crew monitor how the robot performs during matches from as close to the field as possible. It gives them insights that would be difficult to get from just speaking with the drive team after the matches. We also had instances where we could see/hear something indicating particular components had failed and the pit crew went back to the pit to get the replacement parts and the necessary tools ready for when the robot returned.
Per your recommendation request on the intake pulley-
based on our experience doing something similar last year I don’t believe you will have a problem with that basic design. I like how you are using the shoulder bolt to give some more strength to the pulley. We tested something similar out of pla and then carbon fiber abs versions made it onto our robot. As far as the heat set insert goes, you definitely could end up with a build up of melted plastic beyond the insert that would mess up the bolt. One trick we have done is to make that hole have a taper so that there is less plastic being pushed to the bottom as you are setting it. Just my .02.
