FRC 4099 The Falcons 2023 Build Blog

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.

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:



Do you guys use AdvantageScope for sim?

Yessir :100: I’m not entirely sure if you’re asking about visualizing simulation or simulating the physics for mechanisms so I’ll talk about both.

With respect to visualization, we now pretty much only use AdvantageScope for viewing mechanism and drivetrain simulation. WPIlib simulation visualization tools (Field2d, Mechanism2d, etc.) are seriously incredible and AdvantageScope has helped us take it one step further in visualizing stuff!

With respect to simulation itself, we use AdvantageKit in conjunction with WPIlib physics simulation. We stick most of our control related stuff (motion profiling, tunable setpoints, feedforward control, etc.) in our logic classes and leave lower level controller stuff (setting voltages, commanding setpoints, etc.) to hardware implementations.

To give an example, here’s our Ground Intake subsystem in code. Trapezoidal motion profiles and the setpoints we command our ground intake to go to are all done in this logic class (independent of hardware implementations).

And here is the Ground Intake simulation implementation which the subsystem communicates to using the io object. The only thing the simulation implementation does is simulate the mechanism using WPIlib physics simulation and implement lower level control stuff (configPID(), setArmVoltage(), setArmPosition(), and setRollerVoltage()).

Having a minimal amount of controller specific functions in our hardware implementations helps us be more confident in our code working b/c the logic class is utilized by all hardware implementations (this is also why logic class is like 2x longer than hardware implementations).

Tbh, @jonahb55 has done a much better job of explaining this so if you’re interested in learning more about how IO structures are used to help simulate check out this section on AdvantageKit docs.

Last thing on this is that we generally like to stick PID controllers in hardware implementations to reduce overhead on the roboRIO. To increase our confidence in the robot using the fr fr hardware implementations (i.e. GroundIntakeIONEO.kt) we could add PID controllers in our logic class but we like to take advantage of inbuilt motor controller PID controllers: which is why we have to add PID controllers in simulation implementations.