FRC 3506 YETI Robotics - 2023 Build Thread

[starsick]

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!

[starsick]

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:

Carriage Prototype: Cone Flip Test

Carriage Prototype: Cube Flip Test

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.

High Node Elevator Angle Test

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.

Launching Cube From Intake Prototype

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.

Intaking Cone At An Angle

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.

Weedwhacker Prototype Intakes Cone

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: https://www.yetirobotics.org/

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

[starsick]

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.

Pathplanner Testing With Swerve

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!

[Tyler_Olds]

https://youtu.be/KLQBMM_7F-s 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

[starsick]

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: https://workbench.grabcad.com/workbench/projects/gcsk616gCdVvqH6jOjA261Fr03P2kKkb4rglN0IL1kVqZt#/space/gcdUFtYpiO214fERCdzzTIGcSwTIOAQxZi6qlOXZWK9OAe

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!

[starsick]

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.

Elevator Extension Tests

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…

Engaging Charge Station At An Angle With Swerve

… and heading at it straight on, slowly…

Engaging Charge Station Slowly With Swerve

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

Engaging Charge Station At Full Speed With Swerve

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.

[Tyler_Olds]

https://youtu.be/OMJg9T4kOiU 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

[starsick]

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!

[LSao]

@Tyler_Olds

19

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.

[tsar-boomba]

Hi, I’m the person who made the dashboard. The repository is public at https://github.com/Yeti-Robotics/genius-dashboard where you can download the latest release and check out the source code. Hopefully the code helps you in your own endeavors.

[LSao]

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.

[tsar-boomba]

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

[EHutson]

Robot Reveal is out! 2023 Yeti Robot Reveal - YouTube

[starsick]

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:

YETI 2023 FRC Scrimmage

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

Functioning Autonomous Routine (Top Node Cone and Balance)

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:

Launching Cube to Top Node

Scoring Tipped Cone On Top Node

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

2023 Yeti Robot Reveal

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

[starsick]

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

Two Game Piece and Engage Autonomous

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

[EHutson]

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

[starsick]

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…

All-In-One Intake Prototype: Cube Test

All-In-One Intake Prototype: Cone Test

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

[starsick]

We went to Mecklenberg and did pretty well; we were finalists and we won the Team Sustainability award (huge shoutout to everyone who worked on that!), giving us the boost we needed to play at DCMP. We didn’t have any major repairs to make while on the field (for instance, our whole intake didn’t fall off - yay!), but that shiny new autonomous we were showing off didn’t get a chance at Mecklenberg since we didn’t get a chance to try it in practice matches. We did, however, make a new autonomous for the playoffs while there to get that mobility bonus as well as the balance.

Mecklenburg Playoffs Autonomous Routine

There are a couple of decisions we made following this competition - mainly getting rid of our intake, or at least replacing it. Each time we tried to use it to launch cubes at competition, it tended to list to the right and miss the shelf; especially in the times we needed it to score one last game piece before time ran out, it failed us. We’ve posted about our all-in-one design if you want to check that out, and we’re still seriously considering it for our next competition - we built the arm and intake for this in the week following Mecklenburg, so we could have it as an option.

What actually ended up going onto our robot for DCMP is something similar to what fellow Open Alliance team 5727 Omegabytes has on their robot, though it didn’t start out like that. It started out as just a roller bar with a standoff at the bottom. Since our roller bar intake worked much better than the squeezing motion we initially had, we started with a similar concept when designing this new intake since this intake’s only purpose was to shoot cubes - we eliminated the handoff altogether since it wasn’t competitive. As a prototype, this actually ended up working pretty well:

Roller Intake Prototype

The biggest challenge with this intake was designing it so that our carriage could still flip while our intake was stowed so we wouldn’t violate extension rules. Even after cutting down the back, we still had this issue with the carriage being stuck under the intake due to the height the intake had to be in order to intake cubes.

We fixed this by mounting hard stops under the carriage to hold it up above the intake - since we’ve eliminated the hand-off, there’s no need for it to be tucked under there. These have pool noodles wrapped in gaffer tape on top to keep them from slamming down too hard.

As you might spot in the image above, we also made the rectangle of 1x1s which the carriage mounts onto the elevator with shorter - since it no longer needs to be large enough to hold the game piece, it just takes up room and weight. We’ve also added extra rollers to the elevator for stability since it kept bending due to the weight of the carriage and slowing the time it takes for our elevator to stow. These new rollers limit the extension of our elevator slightly, but not significantly enough that it impacts us.

Though it’s not shown in these screenshots, we made the decision outside of CAD to add an extra roller bar on the bottom to help take in the game piece, especially from the floor. This intake ended up being extremely reliable for us, as shown in the videos below - rather than a last resort thing, we were able to incorporate it as part of our strategy.

A lot of controls’ work was speeding up everything. They worked on tuning the carriage PID and made setpoints to automate aligning to the double and single substations. They also worked on programming the new intake and retuning the arm (since the intake is lighter, we can move the arm faster. This design also lets us pick up cubes from the single substation!). With this, we have settings for whether we use our intake or carriage for picking up from the single substation; our LEDs activate depending on which. Once they got this working, they worked on putting together a 3-cube autonomous for DCMP.

Our teammate working on our Genius dashboard fixed a bug where the dashboard crashed when you disconnected it from the robot, as well as added shortcuts for switching between boards and adding widgets and the ability to resize widgets. With all of this functional, we brought Genius dashboard with us to DCMP and used it there - it worked great!

Week 12 was mostly focused on getting in further driver practice, so our mechanical subteam didn’t have much access to our robot. We did some maintenance on our swerve modules to make sure they were in tip-top shape for competition and replaced the treads. Otherwise, we were busy building spares for the rest of the robot, like the intake (we had to steal the wheels off of our all-in-one arm for this one). Controls was meanwhile busy with making every autonomous under the sun, starting from any position - whether on the open side of the charge station, the side of the charge station with the wire, or from directly behind the charge station to balance. While we were fairly versatile, most of these involved scoring a mid cone, going forward to collect a cube and returning to score it on the mid shelf beside the mid cone, and then collecting the next cube to score in the low node. Here are a couple of examples of those:

Wire-side Intake

Inside 3 Piece Autonomous

During this time, we made a couple of changes to our strategy to align with our design changes. We’d started picking up mainly from the single substation at Asheville, then switched to the double substation with our new carriage design, and for this competition, we switched back to the single substation. Through all this time, we have focused on cones and will probably continue to focus on cones, but with this new intake, we’re now able to be more versatile when it comes to cubes. Less significantly, we’re flipping the carriage and then extending the elevator rather than vice versa (as we had been doing in previous competitions) to reduce the risk of tipping.

DCMP recap and what’s next for us coming in the next update - wanted to get this out first! Thank you for reading, and let us know if you have any questions!

[starsick]

States went very well for us this year! We were finalists, we walked out with the Engineering Inspiration Award along with 3459 Pyrotech, and one of our lead mentors Mrs. Iaiela Dumitrescu brought home the Woodie Flowers Finalist blue banner! You’re an incredible mentor Mrs. D - thank you so much for everything you do for us. Words here could not express how grateful we all are to have you guiding our team to success.

Most of the competition went off without a hitch, with no big repairs that we had to do mid-competition like at Asheville. Match 57 comes to mind, where we glanced off the charge station at top speed returning to the community zone, and fell on our side, where we remained for the rest of the match. Somehow, nothing really broke here.

This one is just a personal favorite of mine, but our last match 2640 HOTBOTZ sped in at the last minute, scored a top cube with literally less than a second left in the match, and as a result also scored parking points. This score won us the match - fellow OA team 5727 Omegabytes completed a hybrid link which tilted it one point in their favor just a second prior. Fantastic play from all robots here - and go HOTBOTZ!

We ended quals at rank 2 and formed an alliance with fellow OA team 4795 Eastbots and 6004 f(x) Robotics for the playoffs. We remained undefeated in playoffs until Match 11 against Alliance 1, bumping us to the lower bracket where we proceeded to set the high score for NC Champs in Match 13 against Alliance 4 (174 points, albeit with 22 penalty points). Alas, we lost both finals matches. We started the first match at a 20-point disadvantage - our autonomous failed our second and third game pieces, and we almost made up the deficit until the balance where 6004 f(x) Robotics got caught on the edge of the charge station and both we and 4795 Eastbots tried to get one last game piece in. We did our best to balance alone in the last few seconds and 6004 f(x) Robotics backed off just in time, but it didn’t work out and we ended up only getting docking points for one robot in endgame, losing that match 125 - 110.

Finals 2 was a doozy.

Our autonomous actually ends up working well this match, but we come out of this period at a 6-point deficit due to a top cube that falls off the top shelf and rolls out of the grid. We start this period rolling, going straight to the single substation to pick up a cone. On our way out, we get caught on the side of the substation and actually tip it inward quite a bit before we free ourselves - here is where we think the problem started. When we go to score this cone on the top node, as we typically do, we find our carriage hanging too low. So we score mid-node instead, and when we do our second cone cycle the same thing happens again - we pull at the single substation worse on our way out. Recognizing that something’s gone seriously wrong, we decide to switch to shooting cubes, as is our failsafe, at which point we see our intake is horribly bent. Miraculously, it still works to some extent and we shuttle a cube from the floor of the loading station to the hybrid node. We try to score a second, but it doesn’t end up working out and we complete a triple balance still holding the cube in the last 10 seconds of the match.

The culprit?

Now That's A Lot Of Damage

We think that a collision in Finals 1 probably made a hairline fracture in this part, and then when we got caught in the single substation it finally gave out. Since this is the only support on the back right side, our carriage basically see-sawed down so it wouldn’t reach the top node. From what I can tell, the bent intake is actually a victim of this as well - when we bring our elevator down for the final time, it slams down into the intake with the cone hard enough to bend the top bar inward. (fun fact: the center white wheel just can’t come off that bar now). As a result, we couldn’t score nearly as many game pieces as we typically did - coupled with the speed of opposing teams 7890 SeQuEnCe and 587 Hedgehogs as well as 3229 Hawktimus Prime’s solid defense, we ended up losing 157 - 130.

Huge thanks to our alliance partners for amazing playoffs, though - 6004 f(x) Robotics had phenomenal defense, and 4795 Eastbots was one of the fastest-scoring robots there. We’re honored that we got to play with you all!

Following DCMP, we were ranked 4th in the state in district points - this alongside winning Engineering Inspiration qualified us for Worlds. We’re super excited about this chance!

So, for Week 13:

Our lead engineering mentor’s opinion was that we should go ahead and rebuild the entirety of Robot 1 on Robot 2, which if you’ve read our previous posts was originally going to be its twin and therefore had the drivetrain already set up. This would give us a fresh robot to work with that didn’t have the damages of 3 previous competitions built up on it.

Our leadership team’s opinion was to also give our all-in-one design a chance - we felt it genuinely had a chance to be more competitive than our current robot despite meaning that we would then be working with a completely new robot altogether.

In the end, our mentor wagered that we wouldn’t be able to make both robots by the end of Saturday, so we built and tested them both by the end of Saturday. 51 minutes to spare!

All-In-One Test Run

Most of our week was spent on building these robots - we rebuilt our original hand-off robot on what used to be the drivetrain for robot 2 and built the all-in-one on our drivetrain from robot 1 once we dismantled the old robot and got the replacement parts for the elevator support. Controls worked on wiring both robots and programming the all-in-one. A couple of smaller changes were made to both designs - the hand-off’s cube intake was made wider after we replaced the damaged bar, and the all-in-one’s arm was made longer and lacked the pocketing seen in the CAD screenshots.

That’s a wrap for Week 13 - thank you all for reading!

[starsick]

RIP Mr. Giraffe you will be remembered

As you might have read if you follow our Open Alliance Discord channel, this year is the best YETI has done at Worlds - we even managed to win our first Worlds-level award with the Judge’s Award at Johnson Division. But before we get to our worlds recap, here’s a short blurb about what went down the week before worlds!

We went ahead with continuing our hand-off design for a few reasons. We didn’t finish our top stage rigging in time and decided that we did not have enough time for programming and subsequent driver practice for it to be a viable design. As such, the all-in-one design was gutted for parts for spares for the main robot.

Most of that week was spent driver practice - our mechanical subteam spent most of their time on creating spares. We did rebuild the intake for strength and made other small improvements to the robot (for instance, we had the 3D-printed parts that failed on us at states remade in metal). Programming mostly spent time on tuning the autos - we developed a two-high-one-mid auto in this time that wasn’t especially reliable but was able to hit one high and one mid fairly consistently.

We also tested out having our human player hold up an Apriltag while in front of the field to help the robot auto-align with the chute, but the angle of this ended up being impractical - we found that with our current limelight angle, our human player would have to hold the Apriltag over his face. (we did joke about making an Apriltag mask for him)

The student working on Genius Dashboard also made it stable and ready to go; we ended up using it for some of our matches at worlds! More information on that later.

On to worlds!
Our robot performed very well at Johnson - we ended up ranking 30th out of 78 teams in our division and then was first pick for 8th Alliance Captain 4011 πρbοtics. Our other alliance partners were 971 Spartan Robotics and 1391 The Metal Moose. Huge thank you to these alliances - this was a fantastic opportunity!

Our robot did not sustain much serious damage in this event, barring our last playoff match where the mechanism that flips our carriage broke - Is anyone else noticing a trend of our robot breaking in the final match?

At worlds, 4 RP was no longer the “unicorn point,” so we were a lot more focused on links than we were at the district and even the state level. We managed to score the two extra ranking points in half of our qualification matches. Interestingly, the remainder lost the ranking points primarily for the charge station rather than the links, despite the increase in links needed to gain this ranking point.

We have a knack for losing things by one point this season as well - in our first playoff match against Alliance 1, we lost 168-169. Our autonomous routine’s mid cube ended up bouncing out of the grid. Alliance captain 4011 πρbοtics, unfortunately, broke down during this match, so we subbed in 1391 The Metal Moose for our second match in the lower bracket against Alliance 5. Everyone’s autonomous this match was flawless! You might remember from above that our flipping mechanism broke in teleop, and 971 Spartan Robotics’ arm’s sensor broke down this match leaving them to defend for much of the match as well. Up against the strength of Alliance 5, we ended up losing this match 151 - 196.

Regardless, we had a great time this year - in fact, as mentioned above, this is a record-setting year for our team. It’s the best win-loss record we’ve had at Worlds (7-5-0), and the first time in our team’s history we’ve advanced to our division finals. The Judge’s Award we received at worlds was also the first time we’ve won an award at this level. We’re all extremely proud that we got here, and the future holds a lot of promise!

Our team doesn’t stop, though - we learned a lot from this season and we’re looking to have a very busy offseason.

First on our priority list - YETI is homeless. (temporarily, hopefully!)

The building in which the QCRA FIRST Zone was housed was sold and will no longer be available for us to use in the coming season. Both QCRA and our lead mentors are searching for a new space for all the teams that work here. Provided that we can find a new space, our policy of keeping the doors open to any team that wishes to use it will remain regardless of where we are - nothing but the location is changing. This does mean that a lot of our offseason will be spent prepping to move out of this building.

Now, those of you who have been following our build threat probably have a good idea of how our design process went and how we ended up going with a less competitive but more practiced design. We went back and scrutinized this process to hopefully not encounter the same situation next year.

One of our main issues this season was strategic design. This season, we had fairly good subsystem designs, but put together they did not reach what we believed to be our potential for competitiveness. A change we thought might help for upcoming seasons is to try designing with a whole robot in mind rather than prototyping individual subsystems and trying to form-fit them all together. We had a couple of ways to try and implement this - one of our mentors suggested doing something like our offseason CADathon for the first week of build season, where we split into separate groups to generate full robot designs. The goal of this would be to move away from individual subsystem prototyping, and instead full robot prototyping. Splitting into separate groups like this would hopefully also eliminate groupthink. We found this season after one person made a working prototype, more efforts went to improving that design rather than encouraging people to design their own offshoot and possibly more competitive designs.

We also wanted to work on our bumper fabrication. Here’s an untold story from NC District Championships: we went a day early so that we could arrive rested and ready to go since this competition was farther away from us than all our other competitions. However, on opening our truck, we found our bumpers torn and unusable. One of our lead mentors (who is also our drive coach) and half our drive team stayed up to fix it up - they were up until around 2 AM trying to cut out new bumper fabric with a box knife and replace them. To try and avoid this situation in the future, we’re going to (finally!) document the fabric pattern we use to make our bumpers, rather than them being an afterthought. This also hopefully means we won’t have much loose fabric around our bumpers - since we use flipped bumpers instead of two separate bumpers for each alliance, having well-cut fabric is especially important.

Less related to this problem but still related to bumpers is working on making a bumper mounting design we can reuse each year. Until now, we’ve had to spend time coming up with new ways to mount the bumpers on our robot each season which often takes up a meeting or so to CAD. Having a design that we can reuse would help us shorten the amount of time we spend on robot CAD.

Speaking of shortening the amount of time we spend building the robot, we also spoke about improving procurement of designs - many of our parts are produced by sponsors, and we found ourselves at many points this season sitting around on Saturdays (our main all-day meetings) without parts because our designs were not sent out early enough, or because we didn’t have the parts to progress. Preventing this mostly involves scheduling better, and finalizing designs earlier in the week so that we can either purchase the parts or send them out to sponsors on time.

More specific to the offseason, we’re changing the way we train rookies. In previous years, we’ve shaped our training in the form of presentations, but this often ends up giving possible recruits the idea that we only ever do lectures. So this year, we’re hoping to shift to more hands-on learning. We still have to keep some presentations around since theory is important, but we’re hoping that this shift will improve engagement.

We’re also hoping to increase electrical training - as it stands, next year we will have 1 person out of the 70 people on our team that is proficient with electrical skills. Historically, the number of people with these skills on our team has been low since programming and electrical are both lumped into the controls subteam, which tends to prioritize programming skills over electrical in the offseason; we’re hoping that shifting this to prioritize electrical more will make sure we don’t have only one person to wire the entire robot. We’re also working to encourage people to work outside their subteam - for instance, pushing those on the mechanical subteam to learn at least a baseline of controls - which we think will help both make our designs more strategic and spread out knowledge rather than restricting it.

Our lead mentor has mentioned that part of increasing hands-on education should possibly include having all women on the team design and build their own robot for Doyenne, an off-season competition for women and non-binary people typically held near us.

Outside of robot design, we have a couple of other things we’re looking to improve. One of the things we saw was especially lacking was our scouting this year - engagement in scouting from our team was low, the accuracy itself was low, and oftentimes those in our strategy meeting would end up rewatching matches anyway to get an idea of what each robot was like, more or less negating the work of scouting. One idea we bounced around was creating a new scouting system with 2 or more people assigned to each robot, with one person responsible for qualitative information (for instance, in the context of this season, how well a robot balances on the charge station) and the other person responsible for scoring data, or one person responsible for callouts and the other person responsible for recording the data. Furthermore, to aid the strategy meeting and with generating a pick list, we hope to update our scouting website to sort through the quantitative data and generate a preliminary pick list rather than making those attending the strategy meeting sift through all the data from that day’s scouting.

We also wanted to look at our outreach. We don’t feel that we’ve hit the ceiling for technical outreach - while we have initiatives like our Girl Scout badge program, our Montessori afterschool robotics programs, and our senior cybersecurity education programs, we still think there’s more that we can do with the resources that we have. We’re looking into other things we could do - a couple of ideas we’re considering is to help machine parts for local FTC teams or restart our YETI Tips on our Youtube channel, among others.

This was a great close to our season, but we have plenty planned. More updates are on their way!