FRC 3506 YETI Robotics - 2023 Build Thread

Hello everyone! Welcome to the YETI Robotics 2023 build thread!

We’re super excited to be returning to Open Alliance this year - it’s a fantastic way to support our fellow teams and a premise that YETI has agreed with since our founding.

Here’s a little bit about us:
We’re a community-based team from Charlotte, North Carolina, and this will be our 12th year competing. We’re a part of the Queen City Robotics Alliance (QCRA) which supports a number of other FRC, FTC, and FLL teams in our area. Alongside QCRA, we have been able to use and share the FIRST Zone, a workshop with full-sized fields for FRC, FTC, and FLL. This area is open for any team to come and use - we think it’s essential for teams not to be held back by a lack of resources. During build season, we typically meet here 6 pm - 9 pm from Wednesday through Friday and 9 am - 9 pm on Saturday.

This year, we have 67 students and 23 mentors, most of which are alumni of FRC teams. Of the students, 83% are from minorities, 28% are female, and 28.4% are not enrolled in public schools.

Long updates will be posted weekly, with smaller updates on the Open Alliance Discord in between as they come up!



Hi everyone! I just wanted to share some of the work we’ve done to improve the reliability of the CAN bus on our robots during the off-season.

CAN Bus Hub

For the most part in FRC, CAN devices are wired in a daisy-chain fashion. This makes it relatively straight forward to wire, but it has a major flaw in that if one device is removed from the chain the rest of the chain fails.

So during the offseason, we began experimenting with wiring the CAN bus closer to how the industry wires the CAN bus. This involves having a main “backbone” (there are other names for the backbone such as trunk) that nodes (devices) then branch off of. The backbone is still terminated with 120Ω at each end. This setup allows for a node to fail, but not affect the other nodes on the bus. Here’s a simple diagram of what I’m describing from Pico Tech’s website.

To make things easier to wire, we had PCBs manufactured that break out the backbone into ports we can quickly plug into. We had 8 and 4 port versions created, but these boards just tap the plugs into the backbone so any number of ports can be added. The connectors we are using are Molex SL connectors. These boards in combination with this wiring topology make it easy to find any devices that disconnect since it is all in one place.

A few things to look out for:

  • The stub lengths (the length of the wire from the backbone to a node) are recommended to be 30cm or less according to the ISO standard for this specification of the CAN bus.
  • The total bus length should be less than 40m. Though this is kind of a non-issue because 40m would be long for an FRC robot.
  • While this topology has been working for us, we haven’t used this during a competition season yet. So there is still a possibility of issues arising. I don’t see this being a big deal, however, since this topology is mentioned in the Falcon 500 manual and it says it works.

CAN Scanner

This is still very much in its prototype stage, so excuse the jank, please.

The goal of this project is to make it very obvious and easy to know when a device is no longer communicating on the CAN bus. This device simply listens in on the CAN bus, and cross-references devices it sees on the bus with a list of devices it knows should be on the bus. If a device goes missing it will alert you with the screen and the buzzer.

This is built using an Adafruit Feather M4 CAN for the microcontroller and an Adafruit 128x64 OLED Featherwing for the display. The connector for the CAN bus is a right-angle board terminal for Molex SL connectors. The buzzer is a TMB12A05 (any 5v buzzer should work though) and it is controlled by a 2N2222A BJT transistor.

The code is all in Python using Adafruits’ CircuitPython library. Here’s a link to the GitHub repository: As all of this is still very much in the testing phase, the most recent code (and the code that does anything) is in the development branch.

The plan is to hopefully get finish getting this tested in the next couple of days. Then design a PCB to connect all the components more securely as well as make a case to protect everything.

That’s all for now. Hope everyone has an awesome kickoff tomorrow and let’s have an exciting season!


Hope everyone had a great kickoff!

We had the privilege to host our kickoff at our workspace, QCRA’s FIRST Zone, with three teams present - 3506 YETI Robotics, 4290 Bots on Wheels, and a rookie team working closely with us this season: 9005 Avian Robotics. Afterward, we split into groups - leadership talked about strategy and the rest of our team had a guided brainstorming session.

In the strategy meeting, leadership came up with an initial priority list after discussing the main types of robots they thought they’d see and the likelihood of gaining different ranking points. Our strategy analysis is not complete yet, but after listing a multitude of different robot capabilities we are currently prototyping and planning to prioritize design of the robot in this order below:

  1. Drive

  2. Automatic engaging
    a. Engage with charge station
    b. Engage with charge station with 1 other robot
    c. Engage with charge station with 2 other robot

  3. Automatic dock
    a. Dock with charge station
    b. Dock with charge station with 1 other robot
    c. Dock with charge station with 2 other robots

  4. Pick up cone from floor
    a. Pick up a tipped cone

  5. Pick up cone from double portal (slide)

  6. Pick up cube from floor

  7. Pick up two game pieces ( < 3 secs) (any combination)

  8. Pick up cube from double portal (slide)

  9. Auto align with nodes

  10. Score high node (cone)

  11. Score high node (cube)

  12. Score upper link (requires 2 cones, one cube)

  13. Score hybrid node (cone)

  14. Score hybrid node (cube)

  15. Score hybrid link (any combination of game pieces)

  16. Score 3 pieces in coopertition grid (any combination, any position)

  17. Score middle node (cone)

  18. Score middle node (cube)

  19. Score middle link (requires 2 cones and 1 cube)

  20. Launch cube (Only in community)

  21. Shuttle cone from loading zone to community zone

  22. Shuttle cube from loading zone to community zone

  23. Pick up cone from double portal (drop)

  24. Pick up cube from double portal (drop)

  25. Pick up cone from single portal

  26. Pick up cone (upside down) from single portal

  27. Pick up cube from single portal

  28. Defense

  29. Launch cone (Only in community)

YETI Robotics has been well known in past seasons to use West Coast tank drives that feature West Coast Products gearboxes. In fact, we have been buying these drive systems consistently since 2015 and have guided countless teams on their usage with our video content and technical assistance.

We are excited to announce that for this season West Coast Products is a new sponsor for YETI Robotics. After using swerve in the offseason on our tiny Borealis robot we are initially planning to use the tried and tested corner-mounted Swerve X drivetrain with a ratio of 6.55:1. Ideally, this brings us to a speed around 15.5 ft/sec. After a few final calculations on sprint distances we plan to cement this choice, report our findings, and get the drive system on order.

The remainder of our team not focused on strategy and drive train came up with ideas for prototypes, ranging from types of intakes, ways to move game pieces onto the shelves, and more - here’s some pictures of those.

A lot of these prototypes drew inspiration from the FTC teams this year since their games share the cone-shaped game piece. We also drew inspiration from similar games such as 2011 Logomotion, 2012 Rebound Rumble, and 2018 Power Up for the long-reaching elevators, bridge climbing aspects, and inflatable game piece handling.

We had a follow-up meeting on Sunday to flesh out our strategy more and do some testing with the swerve robot we built during the off-season, Borealis. One thing we tested was how well swerve performs on the charge station.

Our mentors created this ramp using a sheet of old 2012 bridge material we tested with back then (we believe it to be HDPE which is even more slick than polycarbonate) at the starting angle of the charge station - note that it doesn’t tilt like the charge station does and it’s harder than we expect the charge station to be. The robot, if capable of getting up this slope, should be able to cross and attempt a balance. We hope to get the full charge station assembled by this weekend and show a definitive test.

For the following tests below, Borealis has SDS Mk4is and one set of competition-worn black nitrile wheels; here’s a few videos of how it performed.

For those planning to use the Mk4i modules, there should not be any issues getting up the initial ramp per our test so far. As long as one wheel is in contact with your frame configuration, the robot should be able to get up the ramp.

We tried a couple of strategies to prevent slipping on the tilted surface which will be extremely important when other robots are trying to get onto the charging station - using the swerve lock (wheels at 45 degrees) yielded a slower descent from sliding than pointing the wheels straight up the ramp and stopping. This is still a bit slippery in this test and when giving it a kick with a boot it started to slide down the ramp some.

What we found that really worked well and prevented almost all slip was doing a small sideways movement while on the ramp. Even when stopping on a steeper ramp, Borealis was able to stay up if the wheels were pointed side to side. If teams plan to use swerve, we think it would be best if teams went up at the same time and then drove sideways towards one another to lock in place and prevent slip. This will be much harder with a tank drive if you don’t have current limiting or braking engaged in some way.

We also tested how easy it might be for a swerve robot to get stuck on a cone by having a lot of fun driving into a cone.

We couldn’t manage it despite trying for almost half an hour- the cone would get stuck under the robot and experience some minor damage from the carpet sanding it down, but the robot’s speed wasn’t hindered by it at all. Even deliberately starting Borealis completely on top of the cone with only one wheel barely in contact with the ground, we were able to use a few quick movements to quickly free it.

However, though we didn’t test it, we expect more damaging results from the cube. As a more delicate game piece, if it pops or flattens the cube material will likely get sucked up into the swerve module. We plan to mitigate this by trying a few experiments once our extra cubes arrive since we don’t wish to flatten our only cube until we have more.

We were also able to use Borealis to get a rough estimate of autonomous cycle times - the cones mark out key positions, like initial game piece positions, the location of the grid, and the charge station. As you can see below, we’re able to have enough time to score a preloaded game piece, grab another game piece, score it, then navigate and balance on the charge pad.

We are looking into possibly moving forward at the end to grab a game piece before balancing and letting us score as soon as teleop starts or taking control of 2 game pieces for under 3 seconds for extra points with that movement. We believe some of the best teams will make use of this loophole and potentially dole out 5 game piece autos.

We’re very excited for this season! Expect an update in a few days about the prototypes we’re working on. If you have any questions, please let us know!


Hello everyone! We’ve been working on developing our strategy for this year’s game and have found that the cones are more difficult than many of the past game pieces. We wanted to go into further depth on the strategy behind the prototypes we’ve been working on and describe our intended direction for the build this season.

We spent a lot of time brainstorming what types of archetypes we thought we’d see on the field this season:

  • Cube and Cone specialists
    • These are robots that are capable of only picking up cones or only picking up cubes; we expect more of the latter since the cubes are the easier game pieces to handle compared to previous games.
  • Defense specialists
    • Given how flat the field is this year and that you have to cross the field to bring game pieces from the human player to the scoring station, we believe that we’re going to see a lot of defense-heavy robots this year.
  • Balance specialists
    • These are robots that will make balancing on the charge station their main goal. They will be very adept at this.
  • Swiss army intakes
    • These robots are the ones we see the majority of teams working on - these robots are able to use the same intake to get both cones and cubes.
  • Dual intakes
    • We expect these to be less common, but these robots will have two intakes, each specialized for either cubes or cones. This type lends itself well to swerve since it needs the robot to be able to spin easily.
  • Shuttles and Loaders
    • These are robots that go well together - one robot makes runs between the human player station and the community zone, where the other sits in the community zone and scores the pieces delivered to it. Loaders will probably be skilled at scoring on the high level nodes where shuttles will be better at scoring on the hybrid nodes.

With all of this in mind, we hope to design a robot with an intake designed for both game pieces and a method of scoring at the high nodes, that is small, light, and has a low center of gravity. This is our first year ever working with swerve, so we’re steering away from more riskier designs - especially designs that put our robot at risk of toppling.

We are quite familiar with elevator designs from our past builds so we have initially gravitated towards a robot that has an elevator at an angle to lift game pieces.

While having an elevator inevitably increases our risk of tipping, the field is relatively flat and having swerve allows us to vastly decrease our cycle times. With our current drivetrain, we expect cycles of around 7-10 seconds when optimized.

We believe in our ability to design a robot that reliably scores at the high nodes, so though we may have faster cycle times by scoring cubes or scoring in the hybrid nodes, we think being able to score cones at the top level has a higher scoring potential since we expect many other robots to focus on the hybrid nodes.

Some features we know we want to focus on are automation of tasks like lining up with the nodes to score a game piece and balancing on the charge station, if possible. This would take some of the time needed to aim from our drivers, further decreasing the cycle time. We’re also looking into whether the intake should be part of the elevator (“all-in-one”), or whether it should pass the game piece to a “carriage” on the elevator (“hand-off”).

As we get into prototyping intakes, there’s a couple of things we’re keeping in mind. We think that cubes can be launched onto the shelves easily since they don’t bounce as much and there’s a lip on the shelves, so an intake that would be able to launch cubes without needing to aim and extend would take less time than having to place it. The cones, on the other hand, have to be carefully placed.

We hope to update with more prototype photos this weekend and gauge our progress!


Lots of prototyping is underway this first week!

One of our first prototypes for an intake involved squeezing the game piece on either side to maintain control and flipping it into the robot. While we ultimately decided that it would not be efficient as an intake, it evolved into what’s currently our leading prototype for a “carriage” (a mechanism to carry the game piece from the intake to the top of the elevator and eventually to the high node).

The design shown above was able to flip the game piece, but it couldn’t squeeze it since there was too much friction between the wood and the hex rod. The subteam redesigned that part slightly to add a linear slide on top of the hex rod with separate wood attachments for squeezing the game piece.

This squeezing mechanic is nifty because it works for both cones and cubes, as we were able to demonstrate:

This prototype uses a 775pro motor with a 40:1 gear ratio, and it uses 30% power when flipping the game piece.

We’ve also been testing angles for mounting an elevator. We used a wooden chassis that has the same dimensions as Borealis (our previous swerve bot) with a climber we previously used with Aurora (our 2022 Rapid React robot) to mimic what an elevator might look like on this year’s robot.

This elevator is at an angle of approximately 30° and is mounted around 10 inches from the base of the drivetrain. Note that in this picture, we don’t have the second stage attached, but fully extended, and with the additional length we expect from the carriage, this would be able to reach the top node and drop a cone on top.

You may notice that this model rests on the Falcons in the climber - this won’t occur in the final design. Note that the actual elevator would have to be shorter to remain within the frame perimeter and might need a third stage in order to reach the top node, which isn’t ideal for us as it would add complexity. This mock elevator is also a lot thinner than we’d like the actual elevator to be; in reality, we’d like the elevator to be wider than the game piece.

To that end, we’ve started working on an elevator prototype that more closely resembles our vision of a final product; it’s mounted at the same angle and height as we found above. Although it’s skeletal at the moment, we hope to develop it into a working prototype that we can mount our carriage onto in our following meetings.

We’ve also spent a lot of this week designing our drivetrain in CAD. We shifted our plan slightly to using Swerve X modules with a gear ratio of 6.75:1. Originally, we’d planned to use the belted version, but since we don’t have the Falcon V3s that the belted version requires, we’re using the geared version. Our rough dimensions are 27” x 27”, which are the same as Borealis’ dimensions - we wanted to keep it square to make it less complex to program.

One of our more daunting tasks was figuring out how to intake both cones and cubes with the same intake. We went into more detail about this in our last post, but most of it boils down to the irregular shape of the cone - we need to be able to control its orientation to place it on the node, but it’s more difficult to control its orientation on the field. At the same time, we wanted to keep our intake from being too complex. Much of our team worked toward solving this and as of now, we have four main prototypes.

This first design is one of the more fleshed-out prototypes at the moment - you might have spotted it in our previous post. It’s made of lightning-bolt-shaped attachments that each have two sets of two compliant wheels that open and close using a piston. These are able to close around cones but remain open when intaking cubes, letting us launch them. This intake uses Neo550s on both sides that are connected to the inner wheel axles using a pair of 36T GT2 pulleys, which in turn are connected to the outer wheel axles using another pair of the same pulleys.

This intake was designed with upright cones in mind, but we also did some tests at different angles. However, this would require a second mechanism to lift and angle the entire claw which increases the complexity of this design.

This second prototype is similar, but rather than the lightning-bolt shape, it simply extends forward. This design uses two pistons on either side to open and close the intake and has a motor on either side to power compliant wheels. Similar to the previous prototype, it’s also able to close around the cone and launch the cube. Though it isn’t pictured here, this intake is also able to pivot up and down and we expect it to be lighter than the prototype above.

The third intake is similar to our second prototype but has longer arms extending like a funnel and compliant wheels mounted along these arms. Similar to the other intakes, it’s able to intake both cubes and cones, but it cannot launch cubes. Its width would help drivers spend less time lining up to intake the game piece, but it also poses a risk as we think this will be a very high-impact game. This intake is a direct copy of one made in our CADathon during the offseason for 2018’s game Power Up.

The fourth intake uses a different approach from the prior three. Instead of using compliant wheels, it uses a “weedwhacker” approach - it uses rotating wheel treads to pull in the game pieces. It’s unable to launch cubes, but it can intake both game pieces. It can also intake the cone at different orientations without having to alter the direction of the intake. However, it’s more difficult to control the orientation of the game piece within the robot than with our other prototypes.

Not seen on this prototype are compliant wheels on the edge of the frame perimeter, which would help bring the game piece over the frame and into our robot.

While our mechanical subteam’s been busy with these prototypes, our controls subteam has also been hard at work!

Part of the team worked with rookies to import our project into the 2023 WPILib framework, helping them learn more about debugging and our overall controls scheme. Other parts of the team worked on updating Borealis to our 2023 control scheme. They updated the firmware on the motors, speed controllers, encoders, and RoboRio. We have also been looking into creating multibuttons (buttons with different layers of functions).

Outside of updating our code, we’re making changes to the code structure to make it more reliable. We’ve been using the library Dagger for dependency injection. This gives us better access to dependencies in subsystems, especially if we need multiple dependencies, and makes unit testing easier. This works by letting us make a mock motor to test with, rather than having to create the mock motor later in the code. With unit testing, we can test each part of the code individually without needing the robot connected, letting us find issues earlier and easier than if we needed to wait for a robot connection to test code. To create these mock objects, we use the library Mockito and for unit testing we use Junit.

We’re also fleshing out a project that we’ve been working on since the offseason: our Robot Enabled Self Test (REST). This is similar to unit testing, but where unit testing tests the code without the robot connected, REST tests it with the robot connected. It runs the code, then collects data to show that the code worked as intended. We are working on expanding it to return more specific details as well, like how much current a motor is drawing - we’ll be able to test whether a component is running sub-optimally before something more damaging happens.

Our web development team has been diligently updating our website, which we’re proud to say is finally up to date with more information about the past seasons! We invite everyone to take a look here:

We hope to have completed CAD by the end of this week. We’re excited to share that and any other developments then!


Our goal this week was to have a full robot concept in CAD by Saturday. We’re proud to announce that we have two full concepts!

Most of our work this week has been taking the prototypes we discussed last week and making a complete robot with them. As you may know from our previous updates, we’ve been considering two types of robots to build. The first is the hand-off, where the intake is stationary and passes the game piece to a carriage within the robot. The second is the all-in-one, where the intake is attached to the elevator and is moved around to score the game piece.



Both use the same drivetrain. The all-in-one has a 2 stage elevator since the arm can swing around to make up for the remaining length. The hand-off version has a 3-stage elevator because of the lack of this arm. Because of this, the hand-off version is a lot bulkier than the all-in-one, but the all-in-one is swinging quite a bit more weight around.

Though both renders show the same intake, we’re still choosing between two different intake prototypes, which you may recognize. The first differs from the prototype mostly in its weight - we’ve been designing it to weigh less. The second is similar in shape, but we expect it to be lighter.



The carriage CAD was very close to our prototype’s design but eliminates having separate mechanisms for squeezing and flipping the game piece, reducing weight.


Originally, this carriage was on both robots, but it was removed from the all-in-one design since the intake holds the game piece. Furthermore, where this design was originally designed to move up and down the elevator in the hand-off design, we found that the intake would deliver the game piece to the carriage without needing to move the intake. Now, it’s simply mounted on the third stage of the elevator.


If anyone is interested in the CAD for the robot, please reach out! We’re working on fixing the link in our intro post, but we’re happy to send over the models on request until we figure that out.

Outside of CAD, we recently got ahold of our Swerve X modules - these are now assembled (sans treads) and we’re excited to get them on the field!

Meanwhile, our controls team has been working on developing vision and our autonomous. We’re figuring out whether we want to use Photonvision or the original Limelight firmware for vision this year. After some testing with April tags and trying to 3D data from Photonvision, we’ve found that both can do pose estimation with April tags. As for speed, both Photonvision and Limelight claim to have a speed of 90 FPS, with a latency of around 21-25 milliseconds based on testing from team 1718. Based on this, we’ve decided to start with Photonvision for this season.


We’ve also been working on learning how to code autonomous for a swerve module. A lot of time this week was spent getting Pathplanner to work since this is our first competition season using swerve, but after some trial and error, we were able to get it working! We then spent some time working on how tight curves could be and whether they would drive the robot off the path. We found it remained fairly stable, despite fairly extreme spins and turns, so now our work is more focused on what paths we want to use for autonomous.


We’re very excited by the progress this week - this is a very quick start for our team. We’ll be back next week with more updates!

6 Likes 3506 YETI Robotics is back on The Open Alliance Show to detail their CAD with two arm options, show off prototypes of their intakes and to overview their initial autonomous routines with PathPlanner



Hi everyone - here’s our recap of Week 3!

As you may know, we’ve been working on designs for two separate robots until now - a hand-off design, where the intake passes the game piece to a separate mechanism on the elevator, and an all-in-one design where the intake is attached directly to the elevator and is lifted in order to score pieces. We’ve decided to proceed with the hand-off design since at this point it’s more complete. Though it is more complex, we think it’s a safer design and has more scoring potential than the all-in-one.

For most of this week, our mechanical team has been working on touching up our CAD and creating drawings. We’re continuing with a 27” x 27” frame perimeter. Our elevator also has some finalized measurements: our static stage is 26”, our 2nd stage is 27”, and our 3rd stage is 27.5”, all of which are made of aluminum 1x1s.

We’ve also determined the gear ratio for the elevator gearbox using JVN; we’re planning to use a ratio of 7.75:1.

The gear ratio for the 2 gearboxes on the arm (the mechanism that lifts the intake up and down) is 32:1.

While we’ve chosen the overall design for our robot, we’re still deciding between a few of our prototypes. The large intake, which our team has developed more, is more compatible with our current robot. It’s also a better fit for the cube and cone game pieces. However, out of the two it is heavier and the 2x2 which connects the two sides makes repairs on the intake difficult.

The smaller intake has had less focus from the team, but it’s more compact and lighter. The biggest downside to this design is our arm is currently designed around the large intake and would have to be redesigned since the center bar attaches differently, but it could be done without major changes.

Outside of CAD, we’re starting to physically assemble our robot. We’ve sent out our custom parts to be 3D-printed. Our swerve modules have been mounted to our belly pan, and we’re putting our bumpers together. We’ve begun assembly on gearboxes for both our elevator and arm, pulley parts for our elevator, and the carriage. Now that we have more specific measurements, we’ve also milled and assembled 2 stages of our elevator.

Our controls team has begun work on programming the subsystems of our robot, testing limit breakers, and have also started work on fly trajectories in Pathplanner that we can use in teleop and for lining up with the node.

Outside of programming the robot, we’ve been working on our own dashboard. We’ve found Shuffleboard tends to be resource intensive, so our new dashboard seeks to improve on that. Development on this has been steady this week and we hope to have it done by next week!

We’ve also been working out the positions of electronics in CAD, and mounting what electronics we can to our belly pan.

We’re proud to announce that our CAD link is finally working! This link will be updated with our newest CAD regularly. You can check out our most recent work here:

We’d also like to announce a practice with FRC Teams 4290 Bots On Wheels, 4795 Eastbots, 5727 Omegabytes, 8738 Slice, and 9005 Avian Robotics on February 18th! We’re really excited about the chance to practice with these amazing teams, and we’ll share updates on how that goes. Otherwise, that’s all we have for this week!


After a lot of work this week, we’re almost done assembling our robot!

First things first: we found out part way through our meeting on Saturday that we’d been building our robot backward. Whoops!

For a bit more detail, the lower elevator supports were supposed to be mounted 4” from the front of the robot, and the upper elevator supports were supposed to be mounted 8” from the back of the robot - we had it the other way around. Our first sign that something was wrong was finding the arm hit the pinions on our swerve module, which we waved off initially thinking that they wouldn’t hit it once the bumpers were mounted. Had we properly consulted CAD though, we might have avoided this problem earlier - we only noticed it much later after the two sides were attached, after finding that the battery mount was too tight.

Since our arm was already put together, instead of switching the supports around it turned out to be easier to disconnect the entire superstructure and reverse it. We were able to get this done Saturday, though rewiring the robot was left for the next meeting.

With that said, our robot is almost fully assembled!

We’ve spent most of week 4 on assembly, and while there are always still improvements to make we’re very happy with our progress so far! It weighs in at around 97 pounds at the moment, though that’s by no means final as I’ll explain below.

The elevator at the moment has had some issues with the pulleys slipping - given the slanted angle of the elevator and the violence we expect our robot to undergo in competition, we’re looking into using springs in the rigging. Outside of that though, it’s working well - here’s a video of it in action before we mounted it.

Our second, and more pressing problem, was with our carriage. Our current design did not grip onto the cone as tightly as we’d like - we suspect part of the reason it worked better in prototypes was because of the heft of the wood. By the end of this week, we were still working on a redesign, possibly with a smaller piston to squeeze the cone tighter, but other options were on the table on whether to rethink our design completely and turn the carriage into an intake for the human player station.

Now that we have a fully assembled charge station (huge thank yous to our mentors!), we’ve been running some more tests with how well swerve docks and engages using Borealis.

We tried approaching at an angle and twirling onto the charge station…

… and heading at it straight on, slowly…

… and then we caught some air engaging with the charge station at full speed. Still balanced!

The biggest problem we find is getting the platform to tip when approaching at an angle, and even then at high enough speeds, it doesn’t seem to pose a problem. With the agility of swerve, we think (as many others have proven as well) that teams with this drivetrain should have little trouble docking and engaging.

We’ll have a lot more information this week about what we’ve done so far, including more information about how the assembly of this robot’s twin goes.

7 Likes 3506 YETI Robotics provides their week 5 update detailing their first robot build and providing a look into their custom dashboard and why this was the best route for their team



Hello all!

Last week our mechanical subteam started machining Robot 2 after passing Robot 1 off to controls. This robot is mostly identical to Robot 1, except for a few tweaks here and there. Mechanical is also working on updating the carriage design because our previous one was too flimsy. Controls is working double time to finish testing code on the robot before our scrimmage on Saturday, February 18th.

We haven’t built a twin robot since the impact of COVID-19 in 2020, but rapid team growth since then has both enabled and prompted us to bring the practice back. Not only does it let us involve more team members, but it also lets our mechanical subteam continue work improving designs without stopping our controls subteam from testing code. It isn’t completed yet, but we hope to have it on the field this week.

We’ve also been handling another issue - those who have been following our build blog will know that our carriage design has run into some issues with being too flimsy and not being able to properly grip the game pieces.

We’d initially planned to fix this by using two smaller pistons instead of one large one, changing how the arms opened and closed around the game piece - using more of a pinching motion rather than a squeezing motion.

We decided against this model simply because it wasn’t as efficient as the other one we were developing alongside it.

This second model was a complete redesign in comparison, based heavily on the intake on 118’s Everybot. It consists of three rollers, spaced out so that one space is optimized for cubes and the other is optimized for cones. The rollers for the cube are spaced 9.75” apart, and the rollers for the cone are spaced 4” apart. This design is ideal since it can also intake game pieces from the human player stations, letting us forgo the handoff altogether most of the time and therefore speeding up cycle times.

Meanwhile, our controls team has been busy finishing off rewiring the robot - we turned our robot on for the first time this week! They’ve also been working on our firmware and testing the code that they previously wrote.

While we have no videos yet, we have had mild success with auto-balancing. We’re still doing work to fine-tune it further, but it is on its way to being a fleshed-out feature. We’ve also been working on fleshing out an autonomous, which we hope to test further at Saturday’s scrimmage.

Speaking of, unfortunately, 8738 Slice isn’t able to attend our scrimmage on Saturday, but we’d like to announce teams 6894 Iced Java and 4935 T-Rex will also be joining us. We’re planning to record a video with highlights from the event, so look out for that in the coming days!


Hi team Yeti. Your OA video was very informative and helpful. Regarding your custom dashboard, is it available on Github for other teams to look at? My team has also been looking for alternatives to shuffleboard.


Hi, I’m the person who made the dashboard. The repository is public at where you can download the latest release and check out the source code. Hopefully the code helps you in your own endeavors.


Hello, your dashboard is very well done. I downloaded it and have been adding widgets. I was wondering if there is a way to add camera streams and group widgets together.

1 Like

Glad you like it :grin:. We are going to add camera support soon. Grouping widgets is more challenging, so that might take a while to be added.


Robot Reveal is out! 2023 Yeti Robot Reveal - YouTube

1 Like

Apologies for the lack of updates! It’s been a busy couple of weeks for us. This post will go over weeks 6, 7, 8, and February 18th’s scrimmage.

Week 6 saw further work on our second robot. The intake arms, the elevator, and the drivetrain were assembled but weren’t put together - in this picture, they’re just propped up on each other. Our 3D parts came in towards the end of the week, so we didn’t get a chance to put those on. We were also still waiting on our Falcon 500 V2s to come through, so this was essentially a bare skeleton.

As for the main robot, we’d gotten our bumpers assembled. In previous years, our bumpers went on in 4 different pieces for each of the sides. While fairly stable, they always tended to be a hassle to take on and off the robot. This year, we’ve opted for bumpers that are all in one piece and can just be slipped on top of the robot, making it incredibly easy to remove and attach the bumpers. These are mounted to hex rods on the drivetrain using thumbscrews.

Controls worked with the main robot to prepare it for the scrimmage that Saturday. This mostly involved testing subsystems and assigning them to buttons on our driver station - we hadn’t planned on having an autonomous routine prepared, so it was just making sure everything else was good to go. They also put limits in place to make sure we didn’t break the extension rules in a match.

February 18th’s scrimmage went great! Huge thank you to teams 4290 Bots on Wheels, 4795 Eastbots, 4935 T-Rex, 5727 Omegabytes, 6894 Iced Java, 8429 Valence Robotics, and 9005 Avian Robotics for joining us! You can check out the stream of the event here:

You may notice we were only able to drive a few times here - unfortunately, we spent a lot of time in our pits fixing a few issues that we hadn’t seen until we tested the bot on the field. We found that our elevator wasn’t supported well enough and when fully extended, the weight of the carriage and the elevator combined to actually bend the elevator slightly, preventing it from collapsing back down. The set screws on the Versa planetary gearboxes attached to intake Neo 550s weren’t Loctited properly, so the intake didn’t spin - instead, the motor spun itself. On the other end of the spectrum, Loctite ended up on the Lexan plates of our intake and our carriage, leading to breakage. Moral of the story - be wise with Loctite! We also had a code-related issue with the pneumatic brakes on our intake arm that prevented it from moving up and down.

We were able to get some good driver practice in the matches we did drive, though, especially with balancing on the charge station, and it was definitely much better to experience these issues there than at an official competition!

We got the chance to interview each team at the scrimmage - hopefully that video should be up sometime this week!

Week 7 and week 8 was mostly spent further testing and ironing out the smaller flaws in our robot. Controls worked on ironing out subsystem code and our autonomous routines - here’s a video from March 1st (the Wednesday before our first competition at Asheville - we were definitely cutting it close!).

For our mechanical subteam, weeks 7 and 8 were spent preparing spares for our main robot and polishing off the final bugs on the main robot - one of the major things we did in week 7 was redesign how the motor on our carriage was mounted to increase stability. Around week 8 especially, we realized that finishing our second robot would not be feasible and that the parts might be better used as spares for our main robot at competition; as such, we finished the elevator but left it detached from robot 2. We tried to leave the robot for driver practice as much as possible, especially near the end of the week. Here are a couple of videos of scores we made during driver practice:

Our robot reveal video is also out - huge thanks to members Robbie and Aryaman as well as our mentor Jacqueline for putting this together!

Update coming soon about how Asheville went and what we’ve worked on since!


Yep. That’s us. You’re probably wondering how we got into this situation.

2 weeks ago we attended the UNC Asheville District event. Any of you who were there or following along might have spotted us - we did pretty well! But to continue, we managed to break our intake twice (fun fact: also in the same spot each time) (fun fact 2: both times it hung onto the robot only by the power cord!).

The first time, we hit the human player station as we tried to pick up a cone. The 3D printed parts attaching the intake to the arms sheared along the layers of the printing - our running guess as to why this happened is that the parts were printed with 40% infill instead of our intended 100% infill. We used an intake spare, previously made for Robot 2, to repair it, and it held for the rest of the day (we initially repaired it with a faulty Neo 550, rendering the intake useless for the rest of that match, but this was fixed directly after). We went into day 2, feeling good, and then on one of our first matches of the day we lowered the claw and it broke again.

This time, not having another spare to fall back on, we did our best to bolt together the 3D-printed parts. Then using the machine shop trailer, we sandwiched them between two pieces of plexiglass - thankfully for us, this repair lasted us the rest of the competition.

Controls was also busy at Asheville - we tuned our auto-balance PID to the real charge station. (our charge station at the FIRST Zone seems to be much less sensitive than the competition charge station). We also worked on optimizing our handoff to make cycles faster and more successful. A shoutout to controls - our 1 high cone and charge station balance was successful every time we attempted it!

We were part of Alliance 3 in the playoffs alongside 7890 SeQuEnCe and 9005 Avian Robotics. We tied in points in our first playoff but lost on the charge station tiebreaker. This put us in the lower bracket, where we almost fought our way back into the upper bracket until we faced off with Alliance 2. We actually made a true tie here, since our charge station points also matched up, and then we lost by one point after replaying the match. Very exciting, to say the least!

Week 9 (following Asheville) started out with discussions of what we could improve. While Asheville was a good experience, our performance wasn’t where we wanted it to be. So we came up with 3 main plans for action:

The first was a rework of our previous all-in-one design. One of the things we had repeated problems with at Asheville was the hand-off - it was inconsistent and often led us to drop cones at crucial moments. The all-in-one would hopefully allow us to pick up from the floor and double substation and score with the same mechanism, removing the risk of dropping the game piece in the handoff. However, this would involve changing the entire design of our robot from the second stage up.

The second involved altering our carriage to pick up directly from the chute. The idea with this was rather than needing a separate mechanism to flip the game piece upside down into our carriage, we could just drop the game piece upside down into the carriage. The other intake would still remain, leaving launching cubes still viable.

The third was simply reworking both our carriage and intake to make the handoff smoother. This would involve rebuilding our intake to better launch cubes since this was often inconsistent. The carriage would be rebuilt to both better pick up the cones in the hand-off and pick up game pieces from the double substation rather than the single substation to reduce the number of times we needed to use the handoff.

We ended up going with a combination of the second and the third design - the CAD for the new intake and carriage was made early on in the week and quickly tested to see if it was viable.

Both designs are extremely similar to their previous versions - we adjusted the intake’s diameter and added different wheels so that it would intake and release cubes better (you can kind of catch a glimpse of it in this picture off to the side).

We added an extra roller to the carriage above the second roller to facilitate picking up the cone from the shelf of the double substation, negating the need for a hand-off with the cones - since we score primarily cones, this works out great for us. We still planned on using the intake for picking up and launching cubes at this point in time.

Controls was especially busy - in the time between Asheville and Mecklenberg, they worked heavily with vision, autonomous, and our subsystems.

We got Apriltag localization working, letting us reset and get accurate pose readings from only the Apriltags. We also improved our Apriltag alignment, meaning our secondary driver can now align our robot with the scoring objective with the press of a button using our vision.

Those who have been following us may know about our Genius Dashboard, a custom dashboard one of our members is developing in place of Shuffleboard. Camera support has been added, making it now fully competition ready - in fact, we used it at Mecklenburg.

We worked on tuning our autonomous routines, adding more mobility to our already successful middle cone and balance auto.

We’ve also worked on LED implementation - mounted along either side of the elevator, these turn different colors for communication with our drivers and human player (for instance, yellow or purple to signal the game piece the human player should place or different colors to show the state of the elevator).

Controls also worked on fine-tuning our subsystems as much as possible. This included increasing the speed of the elevator and optimizing commands to make them as fast as possible, as well as putting in command overrides that put our elevator down when putting our intake out to avoid extension penalties.

Week 10 mostly saw this fine-tuning work continue for both controls and mechanical. Some of the further tweaks we made to our carriage included replacing the latex rollers with neoprene rollers. We also remade the custom gearboxes on the carriage out of metal - this was something we intended from the beginning of the design, but only had a chance to do now. Mechanical also worked on making spare parts for Mecklenburg.

During this time, one of our members worked on the all-in-one design mentioned before, with plans that it might be implemented by the time we get to states. However, there’s much to talk about with this design that I think warrants its own post - that’s coming soon!

We also got this working. (if you follow us on Open Alliance’s Discord server, you’ve probably seen this!)

Aside from that, that’s all for now. Please reach out with any questions!


Be sure to check out our behind the bumpers! - YouTube


This post will probably be more of a photo gallery than me explaining things since our teammate CADding this design took screenshots of all sorts of situations. I’ll caption where I think it’s needed, but feel free to reach out and ask any questions you have!

The all-in-one design, like the old all-in-one, uses the same design up until the first stage. From there, the second stage differs in that the 34” arm is mounted on a carriage on the second stage of the elevator rather than all the way at the top, allowing more motion. This ends in a rotating wrist, capable of picking up cones or cubes depending on the orientation. The image below is the most recent and up-to-date image, with a close-up of the intake after - the remainder were taken earlier.

Here it is stowed:

These next two screenshots are how we expect this robot might be able to score at the top level. The rest of the robot isn’t shown here, but it’s anchored to where the floor would be.

These two images show how this intake takes in game pieces from the ground:

These are a couple of videos of this intake prototype taking in game pieces from the ground…

… and here is the JVN for the pivot that turns the intake.

It’s also capable of intaking from both the single substation and the double substation shelf:

And finally, here is a close-up of those arm gearboxes and the JVN for them:

These JVN calculations are for the arm pivot on the elevator:

We’ve been developing this because it’s just seemed more competitive overall - it does everything with one mechanism rather than needing to split it up between multiple mechanisms as our current design does. Especially with how promising prototyping has been, this may be a viable option despite needing a big overhaul.