Team 4099 2020 Build Blog

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:

Code Repository

You can see previous years’ code in that organization as well.




Drivetrain tutorial


Saturday Summary

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:

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:

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.

Sunday Summary

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.


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.


End of Week 1 Update

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:

CAD Update

Yes, this looks like a snake to us, too. :snake:

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.

Subsystem Updates

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:

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 :angry:. 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.

Other Subteams Update (far less detailed)

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).

Things I’m Proud Of This Week

  • The whole team handled being out of our normal workspace incredibly well. The level of productivity stayed as high as I could reasonably expect given that our meeting location made it physically impossible to precisely cut prototype parts and some of our parts were just not accessible (stuck in the shop room).
  • Our design subteam is almost entirely made up of new members – the only returning members are the two design leads and the design mentor (me). Even still, design is ahead of the ambitious schedule we set at the beginning of the year. Almost all of the mechanisms are being worked on by new members exclusively (climber has both design leads). I’m very proud of the job the design leads have done in teaching CAD over the offseason, and even more proud of the job the whole subteam have done themselves, successfully taking on (and already nearly finishing) full mechanisms.
  • I set this up during our Saturday meeting :smiley:

Hiccups and Mistakes

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.

Still To Do

  • Add climber support beams
  • Figure out feeder motor locations
  • Potentially move shooter motors down
  • Finish drivetrain

This is looking really nice, I hope you keep up this blog!

1 Like

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.

1 Like

End of Week 3 Update

I skipped a week :grimacing:, 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.

CAD Update

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.

As a result of the small size of this bot, we’ve decided to go with inserting the battery from the bottom of the bot. We are going to use rivnuts and screws to secure the battery holding plate to prevent the battery from falling out.


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).

Other Subteams Update

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 :tm:.

Electrical has crimped almost all of our motors and motor controllers with Powerpoles and latching connectors for CAN.

Things I’m Proud Of This Week

  • 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 :sweat_smile:

  • 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.

Hiccups and Mistakes

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.

Still To Do

  • Assemble practice bot
  • Test practice bot subsystems and code
  • Get autonomous paths to work

Feel free to ask on CD. Many folks will gladly print and send you parts, even in Onyx.

I can only do PLA+ though :slight_smile:


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.

1 Like

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.

1 Like

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.

Beginning of Week 5 Update

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:

  • The front bottom feeder roller (the one that attaches directly to the drivetrain) is not possible to install or remove after the braces it connects to are riveted in place. We had to remove one brace to be able to install it. We will most likely end up shortening the roller or something to make it more possible to maintain — it’s the part of the feeder most likely to take damage and the hardest to repair. Incidentally, this difficulty is why currently in CAD there’s 3” wheels on that shaft and not on the bot — we forgot to install them the first time around and didn’t want to disassemble again. We’ll try it this way and if it works, we save a few flex wheels.
  • There was a gusset to attach the H structure on the feeder to the braces which clipped the battery box :confused: Easy fix in CAD, should be fine on comp bot.
  • When using to install rivet nuts, the tool is left hand threaded (probably to protect the aluminum threads in the rivet nut if you over-install it).
  • We need a better system to indicate which parts have been milled and which are in progress. Currently, our PBS sheet shows the status of a part, but I think we need a better way to show current (in inventory) quantity for both COTS and milled parts. This issue is why we only have one bumper rail on the bot as of now.
  • The drivetrain configuration currently on the bot happened in a very spur of the moment type of way. We discovered that we didn’t have enough omni wheels in stock to build 2 2+4 drivetrains. Since we had extra pneumatic wheels in stock from last year (thanks @mrnoble), and some teams are using the pneumatic wheels to reduce damage going over boundaries, we thought we’d try this type of configuration as something of a middle ground. As of now, the Colson wheels on this bot are worn down pretty significantly and don’t get much traction on the ground, so it’s really acting as a 4WD as of now — as a result we can’t see how effective the drive would be with even wear just yet.
  • Our team’s manual machining skills need work. Part of the problem is the tools we have access to and what we’ve trained with, but the other problem I think is we have too much reliance on CNCing all the critical parts, so when we have to manually machine things like shafts and spacers, our tolerances are awful (like worse than ±0.125” awful) because nobody has any real practice on this. Also, our current method isn’t ideal (hacksaw + file/sand). We have a CNC lathe that we’re just beginning to learn to use, so we could avoid the problem entirely by this time next year, but for shafts longer than ~10” we’re afraid to run on the lathe because we have no tailstock. Fixing this will likely be one our major offseason training improvements next year, as it made our drive gearboxes something of a pain to get right. Most likely, for the comp bot, we will buy OTS spacers to eliminate this problem.

Plans for this coming week

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.


End of Week 5 Update

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.

Still To Do

  • Figure out if our bottom feeder roller’s position is fine as-is. When we were testing the shooter, the intake wasn’t wired up yet, so we were rolling balls into the feeder by hand. It seemed that too frequently, the ball would just roll up against the feeder roller instead of being picked up into the feeder. This could be fixed by just having the intake behind it also spinning the ball forward, or potentially with the flex wheels we haven’t installed on that roller yet, so we will see if changes are required. If they are, the simplest mechanical solution for the comp bot (I think) is to just flip that brace which the roller mounts to upside down, lowering the position of the roller.
  • Figure out optimal flywheel RPMs per distance. We were beginning to test this (that’s what the first video is from) but my laptop died, and the programming members who were there didn’t have working Shuffleboard to adjust RPM values so we stopped after figuring out the one setpoint. Our plan is to input a bunch of RPM to distance data into Excel or Google Sheets and find a line of best fit (linear or quadratic, most likely) and use that line to calculate what RPM to use.
  • Add polybelt to the last feeder stage. We currently don’t have enough to make that possible, unfortunately, so we put surgical tubing over the rollers instead to allow us to run the subsystem. This technically works but isn’t ideal – the knots in the surgical tubing rub up against the wheel, leaving residue on the wheel, and the tubing doesn’t have pulleys to hold it in place so it slides along the roller. We are ordering the remaining parts today, so we should have it fully functional by the end of the week.
  • Add beam break sensors and implement feeder algorithm.
  • Test intake. This depends on finishing bumpers – the wood frames for this were almost assembled by this weekend, so we’ll see when the actual bumpers get done. Once they do, we want to make sure the centering and feeder action parts of the intake work effectively.
  • Assemble + test climber. Parts for the practice bot climber were just finished yesterday, so assembly will begin today. Since the first test of the shooter ran so smoothly, my worry about this robot not working has transferred to the climber. The whole season can’t run this smoothly, can it?
  • All the autonomous stuff. Primarily, this means characterizing the drivetrains and getting path following working on this chassis.
  • Building comp bot (all of the above, except on a powder coated robot this time)

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?

1 Like

Pre Week 1 Update

You know, from this angle it really looks more like a 2019 bot than a 2020 bot.

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.

Just after the first climb – we’re on the left here. We probably should have talked to 1418 about us wanting to climb beforehand – instead, we went up in the center, then on their way up, they hit us. We learned two things here: discuss before matches (even practice matches), and the climber is able to support the bot on one hook.

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 :heart_eyes:. This is what happens when programmers get extensive time with a robot to tune things.

Still shot of climber up (first full actuation). It was super scary because the springs pull it down with a ton of force, so the operator had to be very very careful to not let it slam down when not on the rung. In fact, we bent a bolt and dented our bellypan significantly when it came down the first time without even noticing until inspectors pointed it out. We later realized brake mode made this significantly more manageable, and we were going to do that anyway to help hold the bot up post-climb.

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 :grimacing:, 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.

Auto Issues

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).

Limelight issues

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.

Week 1 Preparation

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.

Slightly Closer to Week 1 Update (wrote but didn’t post this yesterday)

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.

2020 Season End and 2021 Plans

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.

After Haymarket, VA Week 1 Event (written right after event)

Student leadership addressing the team after we were eliminated

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

Team dancing during field delay (technically, the picture is the field delay just ending and everybody just about to walk back to the stands)


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.

What Went Wrong in 2020

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:

  1. 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).

  2. 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).

  3. 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 :slight_smile:

Offseason Robot Redesign V1

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.

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.

New Sponsors

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.