FRC 4099 The Falcons 2023 Build Blog

Team 4099, based in Poolesville Maryland, is proud to open our #openalliance 2023 build blog!

Our team is excited for the 2023 season after an incredible performance last season! Some info about us: we have over 40 active members, six mentors (mostly online for now), and operate from the Poolesville Baptist Church! Special thanks to NASA, MITRE, MSBR, Gene Haas Foundation, Lotmaxx, and Octo Corps for making this season possible!

Over the past few months, we’ve held workshops for our new members per this schedule, but near the end of the offseason, we decided to adopt a longer, less frequent meeting schedule consisting of meeting on Tuesdays and Fridays from 3:30 to 7. Going into build season, we plan on meeting from 3:30 to 7 PM on weekdays and Saturdays from 12:00 to 6 PM (with Sundays being a break day).

Quick Links

2023 Onshape

2023 Code

Older resources can be found on the 2022 build blog

Vex Ecosystem

For the 2023 season and onwards, Team 4099 will avoid buying products from VEX product in places we can. We’ve been invested in the ecosystem for a while now, so it will take us some time to phase the VEX ecosystem out entirely, but in the meantime, we’ve been buying new parts from other places and reusing old VEX motors/parts where we can. Here’s an excellent resource compiled on the FRC discord that has helped us find alternative parts in our effort to boycott Vex.

Now onto what we’ve been doing in our offseason.


Every year, our leadership and veteran members create comprehensive presentations and engaging projects for the students we onboard at the beginning of the school year. As our workshops close, here’s a link to all of our 2022-2023 season workshops across all of our subteams. Previous years’ workshops and recordings can be found on our 2022 build blog.

Offseason Projects


Over the summer, we developed a QR-code-based attendance system called FalconTrack. Due to our team’s build space situation, we decided to make a custom-attendance solution. Although we have one consolidated build space, we often relocate to buildings in our local high school, some of our members’ garages, etc. This led us to create a QR-code-based attendance tracking system: members scanned QR-codes that were made specific to locations. All of that data would be stored in the cloud and could be accessed by other team members in case they needed something from a particular location. We made a lot of iterations but ultimately shut it down because it was hosted on Heroku, and we couldn’t justify the cost of what we got out of it.

Regardless, it was a great learning experience for our programmers and helped spark conversations about standardizing web designs for all of our web applications. It was also a good medium for experimentation for more critical apps we developed later on in the season. Although it’s no longer up, here are some pictures of what FalconTrack looked like.

FalconTrack images

Here’s our own login page that was connected to our team’s slack! It allowed us to do 2FA to make sure students weren’t signing in for each other.

Here’s the home page of FalconTrack. I’m running this locally but the idea is different meeting locations would show up with the corresponding checked in members displaying below the locations.

We also made a few things for leadership. A place to generate QRcodes which could be displayed on slides or displayed physically.

Upon scanning a QRcode, students could check themselves in or out using a button.

And an admin dashboard that allowed admins to add students, add locations, and even manage checkins.


F4 Cadathon

For the third year in a row, our team participated in the F4 CADathon to act as a culmination of the skills we learned during workshops in the offseason and to prepare both new and old design members for the actual season. From the last two times we have done this, we realized that actually diving in and designing a full robot is one of the most valuable ways to practice, and this year was no exception!

We were able to simulate a kickoff where both new strategy and design members could get a sense of what the actual kickoff will be like in January by calculating the most optimal and valuable actions in the game, as well as evaluating different mechanisms that fit our needs. We modified our old time based analysis template to simplify the process and give us a lot more information such as Points Scoring Efficiency (a measure of how many points a task would give us per second), all with the power of spreadsheets! One problem we found was that there was not a defined set of constants, leading to groups having different constants for actions but we’ve improved this for kickoff.

Overall, the CADathon was a great learning experience and members were able to design and integrate different subsystems together. Even though we did not have enough time to fully flesh out the intake, we were able to design a really cool robot in a week and are ready to take what we learned to the actual season! Here are our Onshape CAD submission with renders and our kickoff time based analysis + mechanism analysis.

Moco Support

In the past few months since we started our initiative to get further support from our county (Montgomery County, MD), we have seen tremendous progress. We are collaborating with most of the FRC teams here (449, 1389, 5115) and some of the local FTC and VEX teams. Before the school year started, we submitted a white paper going in-depth about the benefits of robotics and including different support areas needed to increase the number of teams (stipends, space, etc.). When the school year started, we established a firm connection with the county officials in charge of extracurriculars and STEM education by hosting bimonthly meetings with them. In these meetings, we have received verbal confirmation of a centralized grant system for local teams (amount TBD), elimination of build space charges, potential for a centralized build location/practice field, and official stipends for our mentors. In the next few months, we plan to continue our collaboration with the county and set up an easily-accessible collaboration network to get help for anyone trying to make a robotics team in the county.


We loved 4414’s super pit at Worlds and decided to hop on the super pit train for competitions and our own build space. The setup still needs to be finished- more details to come in a separate post later- but it’s been beneficial in helping us be more organized and have a consolidated workplace.

Programming Updates

For the past few years, we’ve been using our own units library that allows for inline unit conversions. This means we store all of our measurements as custom base unit classes such as Length, Mass, and Time and allow for simple, inline conversions between different measurements systems (meters to inches, seconds to minutes, meters per second to inches per second, etc.). This has saved us from debugging countless issues, eliminating the need to store unit types in variable names, and has abstracted the process of dealing with sensor units. This means we sometimes have to maintain our own versions of WPILIB classes: namely the 3D geometry classes and unit tests we wrote in accordance with our own units library.

We’ve also worked on replacing our legacy swerve math with faster WPILIB implementations. In this process, we’ve also implemented swerve simulation–something we hope to be incredibly useful down the line when testing autos, vision simulation to test pose estimators with AprilTags, etc. More to follow on that topic in later posts.

ezgif com-gif-maker-2

Electrical Board

Prototyping is a lot more useful when you can do it with real motors, which is why we stripped parts off of our old mule chassis this offseason and made an electronic testing board. It includes a roboRIO 1.0, RSL, VRM, radio, main breaker, and a PDP. We hope it helps with making quick prototypes and testing them using REV Hardware Client/Phoenix Tuner or even uploading some code, configuring CAN IDs, and testing more complicated mechanisms.


VEX IQ Mentoring

This offseason, we began mentoring a startup VEX Team from Clarksburg, Maryland, providing them with technical advice, financial sponsorship, and robot parts so they can compete in their upcoming season. Our team members continue to meet with them every week and handle competition logistics, meeting dates, payments, etc. Current plans include teaching the team CAD, switching to Python programming, and improving their engineering process.

2023 Season Plans

Things We Are Changing from 2022

  • Neo Motors. Beyond our drive base, we are opting for a complete NEO motor ecosystem. We eventually hope to switch to using NEOs for our drive base next season, but for now, we’ll stick to running them for all of our other significant mechanisms until we can get a little more off-season practice with NEOs on swerves.
  • Spray Painting Max Tubes. We’ve spent a lot of time milling Versaframe Tubes, but we’ve planned to switch over to Max Tubes, so we aren’t spending more time than necessary. We’re also abandoning powdercoating as it takes too much time out of our iteration process. Instead, we’re using our newly bought spraybike to paint our stock. Since we don’t need to mill hole patterns, we hope that this process results in the same all-black look while making our iteration process more effective.
  • Protopiping. In previous seasons, our team’s prototypes weren’t effective in collecting the data we wanted, testing rigidity, and helping our iteration process. This year, we’ve decided to utilize Team 5254’s HYPEBlocks and similar systems, as well as continue to use Team 3847’s PVC prototyping system. With the testing we’ve done so far, our prototypes have been much more robust, and we were able to modify/iterate them. Here’s a video of showing some of the protopiping progress we’ve made.
  • Offline scouting apps. Our 2022 in-season scouting app relied on an AWS EC2 instance, a successful database connection, and TBA event being up. There wasn’t a single competition where all of these things worked at once, ultimately leading us to switch to a backup Google-Form-based system. We did some experimentation in the offseason with Chief2, which was a combination of PWA-based web form and Python-based admin panel. Offseason testing found that it ended up being incredibly robust at IRI and BoB. The most important lesson we learned from Chief2 was that QRcodes are the way to go. They make it really easy to transfer data to a computer that we are sure we can ensure a tethered connection on. Additionally, they can be generated without the need of a cellular or wifi connection which makes it accessible to any student with a device. Thus, for 2023, we want to continue a pipeline that generates QRcodes, which store all of our scouting data and scan it using a laptop designated to a scouting admin who then transfers it to a database from which visualizations can be generated. This led to the construction of our 2023 scouting app about which we’ll write a much more detailed post in the next few days.
  • Switching to 2 AWG. After learning a lot about batteries this offseason and experimenting with 2 gauge this offseason, we’re sticking with our switch to using 2 awg in season. Everything we’ve learned about batteries has been documented on our previous build blog: you can find what we learned along with a comprehensive list of tools that we’ve used to switch to using 2 awg battery cables.

Feel free to ask any questions about anything and hope everyone has a great season (no cap)!


As a former MoCo mentor, this is a mind-boggling development. Definitely not gonna complain about it though!

Kickoff Day 1

Happy kickoff everyone!!! Hope you all had as exciting a day as we did! We had a lot of new members join us, so it was great to see them leading conversations and really engaging as part of the team!


Full kickoff day 1 schedule

12:00 - 1:00 Kickoff stream

1:00 - 2:30 Go over game manual + kickoff worksheet

2:30 - 3:00 1678 rules test

3:00 - 4:30 Scoring analysis and robot archetypes

4:30 - 6:30 Time-based strategy analysis

6:30 - 7:00 Needs, wants, wishes

Game Manual Worksheet

We broke into groups to read the game manual and complete our kickoff worksheet (template here), which took heavy inspiration from 1678’s Strategy Offseason Training and 6328’s kickoff worksheet, which took inspiration from 2791’s Kickoff Worksheet and 1678’s Strategy Offseason Training. We then did the 1678 rules test. Thanks to all those teams for the resources!

Archetypes and Time-Based Scoring Analysis

We brainstormed what combinations of point-scoring capabilities our robot could have. Conversations about mechanisms were strictly forbidden (this is about WHAT our robot could do, not HOW).


  • CONE (only mid) robot + PARKING
  • CONE (only mid) robot + DOCKING
  • CUBE (only mid) robot + PARKING
  • CUBE (only mid) robot + DOCKING
  • Top/mid CUBE + top/mid CONE + ENGAGED
  • Top/mid CUBE + top/mid CONE + defense
  • Shove GAME PIECES into COMMUNITY + defense
  • CONE (top/mid robot + docking
  • CONE (mid) + CUBE (mid) + PARKING
  • CONE (mid) + CUBE (mid) + DOCKING
  • CONE stacking

The archetype with the most points from time-based analysis was top/mid CUBE + top/mid CONE + ENGAGED.

The spreadsheet can be found here.

Needs, Wants, Wishes

First, we came up with our goals for this season (what do we want to accomplish?). Then we came up with the following (these aren't necessarily just robot tasks):

Needs: we absolutely have to complete this task in order to achieve our goals

  • Drive
  • PARK
  • Pickup CUBE from any height
  • Pickup upright CONE from any height
  • Score CUBE on top
  • Score CONE on top
  • DOCK, not engaging
  • Drive over CABLE PROTECTOR
  • Vision based scoring
  • Fit robot in a car
  • Maintainable robot
  • Clean wiring (it WILL happen this year)
  • Labeling PDH slots
  • Easy swaps for parts
  • 90% accuracy for scoring
  • GRID at home
  • Intake in < 4 seconds
  • Score in < 4 seconds

Wants: if the needs get accomplished and we still have the resources, we are open to adding this (but it isn’t necessary)

  • Score CUBE on MID
  • Score CONE on MID
  • Score both on HYBRID
  • Pickup any orientation CONE (from floor???)
  • Intake CUBE directly into robot (SINGLE SUBSTATION)
  • Intake CONE directly into robot (SINGLE SUBSTATION)
    • Automatically
  • Wire through tubes
    • Wires through aluminum tubes
  • Have working field elements

Wishes: if, somehow, everything else is added and we still have the means, it may be useful to include this (but again, unnecessary)

  • DOCKING and ENGAGING with alliance member (buddy climb)
  • Holding multiple game pieces


A few questions and observations:
  • Possible mechanism similarities to 2012 (also 971 in 2016)
  • Strat style similar to 2017
  • How well is swerve going to work on the CHARGE STATION?
  • What options are there for defense?
  • How do we use the rules exceptions in the COMMUNITY to our advantage?
  • Picking up and placing CONES from an upright orientation and their sides could be different challenges
  • Would it be advantageous to have a robot run game pieces from the LOADING ZONE to COMMUNITY?
  • Stacking CONES is an interesting concept, but it is way too time consuming

Also if anyone wants it, this is the template I’ll be using for our playbook and match strategy planning sheet for coordinating with alliance partners (it’s very simple but very easy to print out and draw on):
I’ll post both full templates when they’re done. I also highly recommend checking out 4481’s cheatsheet.

Tomorrow, we will focus on mechanisms and robot design. Until next time!

Edit: uploaded a correct version of the field layout pdf


Decisions made after kickoff

Drivetrain: MK4i swerve

This decision is primarily driven by the fact that we’ve gotten very experienced with these modules over the past season. Demos like this helped clear up the question of getting up the lip of the charging station for us. We’re also looking at a brainpan, as that served us well in helping maintainability last year.

We’re leaning towards 28"x28" for our drivetrain, given the height of our robot. Minimizing the drivetrain size to 26" or 24" to fit three robots on the charging station is an option, but given that our robot could be somewhat tippy we want to widen our base as much as possible. Strategically, we don’t lose out too much by widening the base: if we dock and engage in auto (or just dock) and are still able to engage with 2 in teleop, we’ll still be able to get the activation RP. After some experimentation from our programmers, we’re confident that we’ll be able to balance along with an alliance partner by having them drive onto the docking station and having us balance both robots via a pitch-based PID controller (obtained from our IMU) which commands correction drive velocities to help balance the overall system. More on that in a later post though.

Lift: Tilted elevator + linear extension

Adding an actuation to extend your arm seems to be the differentiator between teams that will and won’t score in the high goals. Here’s the mechanisms options we’ve considered.

  • HIGH
    • double-jointed arm (see 971 in 2018)
      • The software end of this seems incredibly complicated for a high school level. With the control, there would be 2 approaches to controlling it. The “naive” method would be to calculate the angle that each arm must be at given a setpoint and then use a PID controller for each linkage on the arm to rotate them to the correct angle. The other approach would be to develop a state space controller where the state variables would be the angle of each part of the arm and then find the control vector using LQR to command the arm to actually go to said setpoint. Although this would give optimal control, given that the team would need to learn the equations that describe the dynamics of the system and then how to actually apply that to state space control which is a topic that can’t be sufficiently taught in the given timeline.
      • One of the primary benefits of this arm in 2018 seems to be moving cubes across your robot, allowing tank drives to avoid turning 180 degrees. However, this year’s cones will end up upside down if you turn the arm across the robot (without adding a method to reorient them). Adding on the fact that we decided on running swerve, and we determined the added complexity wouldn’t justify any competitive advantages.
      • Things we looked at
    • pink arm
      • Last year, during DCMP we ran into issues with sideloading bending our telescoping tubes when climbing, causing it to not retract. Using a telescoping arm for a more high-frequency use with greater risk of side-loading (hitting nodes while scoring, accidental momentum when turning, etc.) simply didn’t make sense for us. The precision in tolerances for nesting is also something we’re not confident we’ll be able to manufacture.
      • Things we looked at
    • tilted elevator + linear extension
      • With a straight vertical elevator, the manipulator would be cantilevered by ~43" when scoring on the top node. Tilting the elevator brings the manipulator closer to the node when extending, reducing that length to ~28".
      • That 28" length extends outside frame perimeter when the elevator is closed. We also want to fine-tune movements to align the code with node, which is why we went for adding another actuation.
      • Things we looked at
  • No HIGH
    • elevator + fixed length arm
      • Removing the linear extension from the option we chose still allows you to hit the mid and high nodes. At the start of week 3, we’re planning to reassess and change plans to this option if we’re not confident in our trajectory for the season.
      • Things we looked at
        • most 2018 robots
    • pivoting fixed length arm
      • This is the least complex option (what I’d guess the Everybot will look like). If we decided high was not a need, we’d probably have committed to this, but the elevator gives us more flexibility to reassess mid-season.

Manipulator: Horizontal compliant wheels

This decision is still tentative. We’re leaning towards the compliant wheels to avoid the lining-up time that would be required with a pincher. This week, we’re prototyping how accurately horizontal compliant wheels can outtake a cone onto a node. Based on videos like this, it looks like they might not be as accurate as we hoped on kickoff weekend, but hey, it’ll be a good prototyping exercise regardless.

Hand-off / ground intake

We are also considering having a ground intake with rollers, spanning full robot width and centering into a cutout. Moving cubes from the ground into our robot, we need to design a hand-off to move them from inside our robot to the manipulator on the elevator. This ground intake gives us the option of holding two game pieces during auto (not after the rules update lol) and frees up weight on the manipulator.

i accidentally hit enter so i edited it a bunch,



If i may ask - what was the rationale behind aiming for the top before mid?


U-shaped Gripper:



It was a simple design to test the compression and grip of compliant wheels on the game pieces. The two sides of the U were adjustable, allowing us a smaller width to test intaking and outtaking the cone and a larger with to test the cube. After gaining some basic measurements of 35A compliant wheel compression and spacing, we saw that the implementation of this design as a cone intake was questionable due to the way the cone reoriented itself and its distribution of weight after being gripped. At different angles and different speeds, the cone would rotate within the rollers and leave us uncertain about a fixed way to outtake. The outtake was also questionable because the vertical rollers pushed the cone forward at different distances depending on the speed of the rollers, and so outtaking directly above the cone node didn’t work and we couldn’t get a fixed position to outtake reliably from.
On the other hand, this design worked really well for the cube, as it is light and symmetric. We didn’t have to worry about any gripping issues, and since the cube nodes are much wider than the cube itself, outtaking accurately wasn’t an issue. We stopped pursuing this idea further due to more promising manipulator designs we tested below.

Horizontal Roller intake/outtake



The idea with this prototype was to figure out how effective and efficient two horizontal rollers could be when intaking a cone at a constant fixed angle. Our goal was figuring out this angle, how far apart the rollers should be, and what kinds of rollers would be most effective. Our mechanism could pivot about a shaft, allowing us to test intaking at different angles very easily. Our first iteration of this used pvc lined with horse gauze as grip tape for the rollers. This was pretty effective in both intaking and outtaking cones, but after shaking the intake while a cone was inside, it seemed that the intake wasn’t reliable in holding the cones. After realizing that our lack of roller compression, and therefore constant pressure on the sides of the cone was an issue, our next idea was to test 2" compliant wheels, which could provide the necessary compression and grip. After some discussion, though, we realized that the wheels would add a lot of weight to the lever arm that this intake would be mountain on, so to reduce the weight, we decided to line pvc with foam (providing the compression) and then F4 grip tape. This made our design work nearly a hundred precent of the time for intaking, holding, and outtaking the cone. Since the two rollers are horizontal and rotating at the same speed, outtaking was always at the same angle, directly into the cone node. We noted that having the two rollers at an angle of incline between 30-45 degrees worked really well.

Compression data collected:

Cube side: roller Center-Center distance is 8.5 inches
Cone side: Center-Center 4 inch. Roller Diameter 1.7 +/- 0.1 inch

Cube Ground Intake:


The idea behind this is that we want our intake to span the full width of our robot in order to cover the most potential intake surface area while driving. The cubes will go over the bumper and into the robot, where the arm intake from above will take control (the arm intake was not testing for cubes yet). With this, we wanted our cube to center itself in the middle of our robot so that there was only one fixed place that the arm intake could obtain the cube from. We originally prototyped this for 3 rollers but then later changed the design to only use 2 with a bumper cutout. We are still working to hone in our compression levels for the 2 roller design but the 3 roller videos and compression are linked here.


There were 2 key reasons behind this decision.

  1. We’re designing our robot to score high to ensure we can form as many links as possible, are aiming to be a successful scorer at DCMP as an alliance captain while also making it easy for our alliance partners focus on forming links on the mid nodes, and because it’s one more point in virtually the same amount of time. In quals, this would allow us to get the sustainability RP as quick as possible—we would never be in a situation where all the middle nodes are filled and what we’re fastest at doing is done. Arguably it would make sense to also design for low since the point differentials between node heights are small but the next reason was a more driving factor towards this decision.
  2. Cycling using the double substation slider. The single substation chute and the double substation ramp were far too unreliable in dispensing the cone upright. So, we went with cycling from the double substitution slider in an upright orientation (bc dealing with diff cone orientations sucks) to optimize our cycle time. The slider is close enough in height to the high node to prioritize design for high node scoring as it gets us a sweet extra point for every node (in addition to the link reason I gave above).

FWIW, our current design allows us to score on both the high and mid nodes. The plan right now is to primarily focus on scoring cones/cubes on high nodes. Not gonna cap I feel like high node cycling is gonna be the move for us but I expect the ability to score on the mid node will be useful sometime down the line.


We’ve separated our robot cad into specific subsystem files. Onshape be lagging a lot with everything in one file so splitting it before we got too much done felt like it was the move :no_good_man::billed_cap:.

Full Robot Assembly + Sketch


Ground Intake



Expect a more detailed post going over our v1 robot design later :bangbang:


Prototyping Week 2

In the process of finalizing our mechanisms and subsystems for our robot, our ground intake for cubes proved to give some trouble in terms of the spacing and grippyness of the rollers.

Previous iteration of ground intake with thrifty compliant wheels and vectored mecanum wheels

Assesment of Problem^^^ After iterating from our previous 3-roller design, we tried moving to a two-roller design: the bottom roller being the plastic thrify vectored mecanum wheels and the top being 2" thrifty compliant wheels. The issue we found with this was that the plastic mecanum wheels were not able to sufficiently grip the cube unless the cube was pushed into the wheels with decent force. One idea we had to solve this was to place a roller with compliant wheels right in front and at the same height as the row of mecanum wheels so the cube was stay gripped while being centered. Although we didn't test this idea, we knew from other tests that the grippyness of the compliant wheels often overpowered the centering ability of the mecanum wheels, so we were unsure about the reliability of the idea.

New iteration of ground intake with 4" grippy mecanum wheels

Another idea we had to solve this was to replace the plastic mecanum wheels with 4" grippy mecanum wheels, assuming that these wheels would grip the cube immediately and therefore center it much faster without added force.

Assesment of Problem^^^ At first, we used 2 of these wheels on each side and had the roller a bit far from the bumpers. Here, since there was enough space for the cube to go in between the roller and the bumpers, the cube would just go over the bumper as soon as the roller was in control of it and not center.
Summary of successful tests^^^ So we then moved the roller down and back so that the wheels were close to the top corner of the bumpers, ensuring that the cube could not physically go through in between. We also added a third wheel on both sides which reduced the possibility that the cube would get pinched and held in between two wheels. We tested two positions of the roller, both pretty close to the corner of the bumper, but one a bit higher than the other. For the higher one, when the roller was spinning at very fast speeds, the cube would bend the shaft upwards and find a way to go over the bumper, but at slower speeds, the roller was consistent and pretty touch-it-own-it. For the position that was closest to the corner of the bumper, the intaking and centering worked pretty well even at fast speeds.

After rewatching the videos, we did notice a discrepancy in how the cube was moving into the center. It seemed that the cube was moving over the top corner of the bumper, and more so on the right side (near side in the video) than the left side. This might be because on the right side, the mecanum wheels were more towards the right side and less near the center, so there was a decent space between the last mecanum roller and the corner of bumper at the center on that side, which gave the cube more leeway to move up. On the left side though, the mecanum wheels were closer to the center and so it kept pulling the cube in. We solved this problem by packing the center more closely and making sure the mecanum wheels on both sides pass the corners of the bumpers at the center.

Compression Numbers:
9.5" - height of center of roller off the ground
4.75" - horizontal distance between center of roller and back of bumper
1.625" - height of bottom of bumper off the ground


Robot Design Update

Woohoo it’s CAD!!

Design members have been hard at work and finished up CADing and reviewing the robot. Bar some prototyping for the Gripper which may change some distances, we now have a good idea of what our robot for this year will look like!

We ultimately decided to split our robot into four different subsystems: Drivetrain, Ground Intake, Lift, and Gripper. Overviews and design decisions for each subsystem can be found below :slight_smile:


For the Drivetrain, we used a similar design to our 2022 robot with MK4i swerve modules and a 28.5” x 28.5” frame. Last year, we really enjoyed having a brainpan to maintain clean wiring and having an easy way to access the electronics. We were initially going to use a brainpan to mount electronics this year too, but due to our Ground Intake and Lift mounting needing a lot of cutouts on the brainpan, it was difficult for us to maintain sufficient space to mount electronics and wire effectively. Having good electronics placement (such as reducing the distance of the PDH → Main Breaker and PDH → SB120 path as much as possible to reduce the resistance in our system, see CD post here) was a top priority for us this year. Therefore, the brainpan became a less desirable option. Soon after, we switched to bellypan as we realized that it would not be terrible given the open space we have on our robot this year, it would also give us enough space to mount our electronics where we wanted.

To protect our electronics, we have velcroed-on polycarb plates which cover the open areas on our robot. These are also raised to be slightly above the bumpers so that game pieces would not get stuck in our robot.

One mistake we made this year was not finalizing the bellypan fast enough. Since we do not have the manufacturing capabilities to mill the large bellypan, we usually get our bellypans done through SendCutSend. We’ve been very satisfied with their work, but it is one of the first things we prioritize because of the time it takes to ship. However, given the switching from brainpan to bellypan as well as the desire to perfect electronics placement/making sure that things didn’t clip or interfere with anything, we ordered the bellypan later than we would have liked, which blocked our goal of getting the drivetrain wired early.

Our bellypan, finally here!

We went with a bumper cutout this season in order to accommodate how the Ground Intake intakes CUBES. This cutout is only for the bumper as we deemed a frame cutout to be unnecessary; we did not like how it affected the structural integrity of the drivetrain frame and where the center of gravity would be placed.

Going along with the theme of clean wiring, we added numerous grommet holes in the Lift mounting rails, as well as other places on our robot to allow for electronics in the bellypan to be wired easily.

On the corner of our swerve modules, we took inspiration from Spectrum and printed out 3DP corner pieces to push our frame perimeter out by 1/4” on each side. This allowed us to move our bumper mounting plates out of the corner, making them a lot smaller.

Ground Intake

For the Ground Intake, we decided to use a motor-powered pivoting roller system with 4” mecanum wheels. This only intakes CUBES from the ground, as we decided intaking CONES was not worth the extra complexity. Although we do have a Gripper to intake both CUBES and CONES, we thought that a handoff system would speed up our CUBE cycles by a significant amount.

Current Design

Our decision to use rollers instead of a gripper to intake CUBES off the ground was based on the logic of “touch it own it.” With this full-width intake, we are able to run into and intake CUBES without needing to precisely align with it.

The Ground Intake was one of the first things we prototyped, and we actually had a different original design. This design utilized two rollers: a set of 2” mecanum wheels and 2” compliant wheels to center and bring the CUBE into the middle of the robot’s frame. Aluminum tubing was used to ensure the intake was structurally sound because its planned resting state during the match was against the bumpers. However, after prototyping the position and CUBE movement with this design, we realized that the geometry of the two rollers was barely able to intake the CUBE. We iterated on this design, and after successful prototypes with the 4” mecanum wheels, decided on what we currently have.

Original Design

In order to center the CUBES into an easily accessible position for the gripper to pick up, prototyping found that 4” mecanum and Thrifty Squish Wheels would work to center the CUBES into the bumper cutout.

The actuation of the ground intake is powered by a NEO Brushless motor on the right side of the robot, with a hex shaft spanning the robot to connect to the left. The NEO was geared with a 44:1 reduction, providing us with enough torque to lift the intake with only one motor.

The final stage of reduction is done through a 16T RT25 pulley belted to a 32T RT25 pulley on a dead axle. Originally, we had the pivot done with chain and sprocket, but we didn’t want to deal with chain tensioning or the extra weight. We hope that the belt and pulley will hold up to the torque, but if it doesn’t, the RT25 system was used so that we can just swap it out with 25 chain. The pulley is screwed directly to the arm, so as the pulley rotates, the arm will too.

The rollers at the end are powered by another NEO, mounted directly on the left intake arm. We originally had this NEO on the gearbox plate with a double pulley on the dead axle. However, due to concerns over 3D-printed spacers under the double pulley melting due to fast speeds, we decided that mounting it directly onto the arm would be the simplest solution.

We are also trying out 3D printing these bearing retention hats to retain our bearings and make sure that they don’t pop out on the polycarb intake plate.


For the lift mechanism, we decided on using a tilted elevator to minimize arm extension length. We took heavy inspiration from 125’s 2018 design. We opted for a continuous design over a cascading elevator because we wanted to save weight through 3DP and belts as opposed to chain.

Since we pre-purchased a thrifty elevator kit, we wanted to use things we got from it even though we were opting for a continuous elevator. Both the base and the first stage of the elevator are similar to the original thrifty elevator, using the thrifty elevator bearing blocks.


For our carriage, we decided to mill our own plates and have standoffs in between the plates. The design of the carriage is very similar to 125’s carriage, but instead of 3D printing it, we milled a 0.25” aluminum plate. The 3DP carriage was a cool idea that would have saved weight, but we were concerned about its rigidity. Since it had to hold a mechanism with a linear extension at a tilted angle, we thought it was better safe than sorry and traded some extra weight for more rigidity.

For the left-right constraining bearings on the carriage, we half-pocketed enough space to fit an aluminum dowel pin with bearings on it (similar to 125’s carriage). An important thing to note is the “dogbone” corner relief, which we did because our CNC’s 4mm endmill would not be able to cut the corners needed to fit the dowel pin.

For the front-back constraining bearings, we used 1/2” 10-32 shoulder screws with a 3DP spacer to stop the bearing from moving. We plan on tapping the plate for 10-32 screws so that the shoulder screw can directly screw into the plate. We want to do this on the CNC to ensure that we tap the hole completely perpendicular to the plate. The holes for the shoulder screw are half-pocketed so that a portion of the shoulder part of the screw can rest inside the plate. If the elevator ever takes a hit, the shoulder screw wouldn’t be taking all the force and instead the carriage plate would take some of it.


We have 2 NEO motors with a 2.08 reduction (see We are using RT25 belts and pulleys just incase we may need to switch to chain, where we can just swap them for chain and sprocket without having to change center distance.

Similar to 125’s rigging, we have inline 3DP pulley blocks to allow for a 20mm wide HTD 5mm pitch timing belt to run through them. They are attached to the tube through screws that go through the tube and 3dp block. We also have an idler near the driving pulley to make sure that enough teeth are contacting the driving pulley that the belt won’t skip teeth.

We plan to drill a hole through and tap a 1/2” hex shaft for #4-40 screws to fasten the end of the belt to the shaft. For tensioning, we have a ratcheting system using a ratcheting wrench so that we can hand-tighten the system.

Cable Carrier

Originally, we were planning on using an energy cable, but we couldn’t get it to fit properly without interfering with other things on our robot. Instead, we are using a polycarbonate sheet that holds the wires on the inside and attaches to the carriage. As the carriage goes up, the polycarbonate sheet will bend up with it so the wires move up and down.


For the Gripper design, we took inspiration from team 3847, Spectrum. We aimed for a lightweight manipulator that attaches to our tilted elevator carriage. This would be able to intake CUBES and CONES from the human player station as well as extend outwards to grab CUBES from the Ground Intake in one mechanism. We are still prototyping the roller distances and will iterate based on what mechanical finds to work the best.

We are using a set of three 2” rollers connected by belts with the motor connecting to the middle roller which then connects to both of the other rollers through infinity belts to ensure that the rollers run in opposite directions. The motor in this case is a Neo 550, mounted far back, also for weight-saving purposes, attached to an UltraPlanetary gearbox for a 3:1 reduction.

For all of the rollers, we are using tubes mounted to custom pulleys with bearings on either end mounted on dead shafts to reduce the amount of weight in the Gripper.

All of this is mounted on a linear slide with a 10” extension, made using two 2”x1” tubes and two 2”x2” tubes with Thrifty Elevator bearing blocks in between (essentially just a horizontal, inverted Thrifty elevator). This linear slide moves using another Neo 550 motor mounted far back, also for weight-saving purposes, with another UltraPlanetary gearbox with a 9:1 reduction. All of this is then mounted on the Lift carriage plate.

Feel free to ask if there are any questions about our design, and until next time! (hopefully with more of the robot built :eyes:)


Incredible work! Your robot is looking amazing. Definitely has been one of my favorite build blogs to follow! Thank you for the thorough documentation.


Just pedantry but your squish wheels linked are 2" when I think you meant to link the 4" ones. Looking forward to seeing what comes next, our design is very similar to yours.

1 Like

You are correct, it has been fixed now, thanks!

Really nice design, looking forward to seeing this on einstein

After we finished prototyping our gripper, it was time to construct it. The rollers were quite the challenge to prepare. For context, the rollers are comprised of two elements, a 2 inch diameter polycarb tube and 1 3/8 inch diameter rubber sleeving. The sleeving was chosen to help increase the grip between the rollers and cones/cubes. The rollers are then driven by two pulleys connected with an infinity belt. The middle roller is shared between the cone and cube intake sections.

Actually getting the rubber sleeving over the tubes proved to be quite the challenge however. The sleeving would have to be stretched over, and it wasn’t very stretchy to begin with. Initially, we tried having 3 members individually pull the opening of the sleeving wider to make it easier to insert the tubing, but even with soap and water as a lubricant, there was just way to much friction. Doing further research, we happened across a video from 1678: Citrus Circuits. They utilized an air compressor to more evenly inflate the sleeving to a larger diameter, which made it significantly easier to get the tube inside. To more evenly stretch the sleeving over the tube, we designed and 3D printed a custom “cone” to use as a tool to help with this.

To create a better seal for the air and to further lubricate the surface, we applied soap and water to the cone and polycarb tube which worked quite well. This worked quite well for us (though after 5 hours of struggle :sob:)


The struggle of learning to stretch rubber tubing on to rollers is very real. No matter how many years in a row we do it, I feel like we have to learn it all over again every year with slightly different tubes and rubbers.


for your intake, could you measure bumper edge to the center of the roller?

This was a difficult measurement to take since the bumpers are going to have some level of defect in them (especially because these were older bumpers taken apart) and so we chose to measure it to the back of the wood since this was a much more consistent and non-compressible measurement.

Based on CAD the distance from the edge of the wood to the front face of the bumper is around 3.25 inches so the Horizontal distance from the bumper edge to the center of the roller is about 1.5". I hope that helps but if not you can make any other measurements based on the bumpers on our onshape.

1 Like

I see, thanks, was just concerned about how well the cube would grab when against the side of the bot but it looks like it works just fine according to one of your videos that I missed.

1 Like

It spins!

Our elevator is rigged but we haven’t attached a motor to the system; 2 quick grip clamps are holding up the carriage right now. Our wonderful mechanical team has a detailed post coming tomorrow going into the specifics of all subsystems so I’ll leave the explanations to them :slight_smile:

Something I’m really proud of is that this was pretty much first try. I largely attribute this to our use of simulation this year. For example, we recently replaced our legacy swerve math with WPIlib swerve math and solved a lot of drivetrain logic-related issues right away in sim! We have to do proper PID tuning (stole last year’s values for now) but we zeroed the modules and it pretty much just worked.

Relatively speaking, drivetrain code is the most evergreen but I expect our use of sim to save an immense amount of time in debugging issues for other subsystems–sim is fr fr the move :no_good_man: :billed_cap: ong.

Looks cooler in real life but here’s the robot also spinning in sim: (1)

More detailed software post to come in the future but for now be on the lookout for a tuff mech one :eyes: