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