FRC 2412 Robototes - 2024 Season Build Thread

jbko6 · January 8, 2024, 7:49pm

2412 Robototes Crescendo Build Thread

Crescendo is finally here! Over at the Robototes, we all are so excited for this year’s game.
I’m Jonah, the Robototes’ Technical Director for this year and I’ll be managing our Open Alliance posts for this season.

Who are the Robototes?

We’re Team 2412, based out of Sammamish High School in Bellevue, Washington. We were founded in 2008 with 12 students and 2 mentors. Our team mission is “to provide all members with the opportunity to grow and learn as leaders, learners and innovators, all while growing interest in STEM in our community”. We’re known locally for our advocacy efforts, which you can learn about here, however this build thread will focus on the robot.

Our Links

Our website
Our blog, which will mirror these posts
TBA
Our Instagram - check out our reels!
Our YouTube

Competitions

Glacier Peak
Sammamish - Hosted by yours truly!

Kickoff

We started our kickoff bright and early Saturday morning, tuning in to the game reveal livestream. After the livestream, we split into groups to analyze the game manual. There were five groups; Two groups for game rules and a group each for robot rules, scoring, and endgame. Each group read through and discussed the game manual, then created a PowerPoint presentation on it. Once all the groups were done, we presented our presentations to each other.

Reading through the game manual

A game rules presentation

After our presentations, we took a break for lunch. Of course, the game analysis doesn’t stop during a break. Most of our conversations as we ate were still focused on the game.

After lunch, we moved on to an activity that’s become somewhat of a kickoff tradition on the team. In order to better understand the game, we play a match of that year’s game using our bodies as robots. We get 6 team members to volunteer and act as robots while the rest of the team makes observations on their dynamics. This year, since we held the activity after lunch, our “robots” had a lot of energy and maybe got a bit too into the competitive side of the activity, so, while lots of fun, we didn’t glean a ton of useful observations.

Next up, we separated into new strategy brainstorming groups. Similar to our game analysis groups, these groups discussed potential game strategies, then created a PowerPoint presentation on their findings.

One group’s thoughts on teleop strategy

Another group’s thoughts on the game

For most our team members, after we finished up our strategy presentations, the day was over. However, for those on this year’s Robot Design Team, there was still plenty of work to do. The 2024 Robot Design Team is comprised of 6 veteran technical students and 6 mentors and is tasked with choosing the final robot design. As soon as strategy presentations had concluded, the design team started discussing our plans for the coming week. We first determined our robot priorities. We identified a floor, touch-it-own-it intake as a high priority alongside reliable speaker scoring. Next, we decided what we planned on prototyping in the coming week. We decided on five prototyping groups, consisting mainly of intake and shooter variations alongside one group prototyping solutions for the stage and trap. Finally, we ended the meeting making some decisions on what needed to be purchased immediately.

Overall, Saturday’s kickoff was a great start to the season and we here at the Robototes can’t wait for the meetings to come!

jbko6 · January 16, 2024, 6:36pm

Prototyping Week

We just finished our prototyping over here at the Robototes. This post will cover all our insights, troubles, tribulations, and more that came with prototyping! Hopefully teams that have not yet decided their final designs can learn a thing or two from us.

Prototyping Philosophy

We try to prototype only for problems that we haven’t dealt with before - like how to interface with a game piece or element. We don’t prototype things like a telescoping arm or other systems that we already have experience developing.

At the start of the week, we split into 5 mechanical prototyping groups plus one programming prototyping group. I’m going to go over each group one by one.

Shooter

This prototyping group focused on creating a feasible shooter design for our robot. After some discussion, they settled on starting with a design similar to the shooter featured on the kitbot.

The shooter group’s first prototype

After this initial prototype, they iterated by replacing the wall with more wheels. Then, they drove each side with NEO Vortexes. They experimented with using solid rubber wheels, but accidentally found that the wheels simply couldn’t handle the RPM.

Unplanned rapid disassembly of the solid rubber wheels

Ultimately, using compliant wheels with 5 inches of compression proved very effective with this prototype. One side was driven at a slightly lower RPM so that the note would have some spin as it exited the shooter. According to their testing, roughly 5-10% difference in power between each side was ideal for stability. The distance traveled by the note was consistent although sometimes the note would drift sideways in the air.

Shooter + Amp

The next prototyping group was directed to create a design that could score in both the speaker and amp. However, pretty soon the group found that its concepts could also be applied to work as an intake as well as a shooter. Their first concept involved an under-the-bumper intake-shooter combo attached to an arm that could raise to score in the amp.

One of this group’s initial prototypes, with a reminder to always wear safety glasses. This video was posted as one of our Instagram reels and as of now has 12.4 million views!

However, the group found that the rollers would accelerate too slowly when the note was loaded to function as a shooter. Their next designs continued their concepts of an intake-shooter combo, but these designs allowed for a note to be held away from the wheels to allow them to spin up before the note is sent through. These designs also did away with the arm.

This design intakes from all sides of the robot. Before the notes are shot, they are held against the ground in the center of the robot. Lift kits are used on the swerve modules to gain a few extra inches of clearance. While the group did test scoring in the speaker with a similar design, scoring in the amp was never tested.

This prototype is similar to the final CAD model’s shooter and worked well

Intake + Amp

This group’s assignment was to prototype a design that could function both as an intake and as an amp scorer. Their first idea was to use two sets of rollers with tread between them to intake and hold the notes until they could be scored in the amp. This design would be attached to a pivoting arm to allow the height required.

The design intaking

The design scoring in the amp

This concept proved to be simple and effective. A little while into prototyping, this concept was actually applied on the Unqualified Quokka’s Ri3D team, proving the design could work.

Ground Intake

This group was tasked with coming up with an optimal intake design. They choose to go the under-the-bumper router, using rollers and compression to lift the note off the ground.

In testing, their design proved effective in picking up notes

In this render, you can see where the top of the bumpers are relative to the intake. In a best-case scenario, there is 2.5 inches of clearance between the bottom of the bumpers and the ground.

This group also experimented with how their intake design could integrate into a larger robot.

With or without an index, the design feeds notes into a shooter similar to the one prototyped by the Shooter group. The shooter is attached to a telescoping arm with a pivot to allow scoring into both the amp and the speaker.

Climb + Trap

Since we didn’t have a chain to reference yet, this group had trouble actually coming up with things to prototype. In the end, most of this group was dissolved into other groups with few members sticking behind to come up with insights and concepts that could later be applied to the real robot. In the end, they recommended using two climb-in-a-box kits with high-grip hooks to lift the robot up on the chain. For trap scoring, they recommended the arms be off-center, so the robot leans into the core of the stage. To open the trap, they suggested some kind of linear actuator that interfaces with whatever scoring system is chosen. They also found a Ri3D team that had a similar climb design as they had brainstormed.

Programming Prototyping

While most of our programmers join mechanical prototyping groups to advise their work, a few programmers stayed behind to research new programming concepts.

This year, our programming prototype group focused on researching Yet Another Generic Swerve Library (YAGSL), pose adjustment with AprilTags, and game piece detection using Limelight’s new neural network features.

Since coming across YAGSL, our programming group has wanted to try it out. The first year we used swerve, we used Swerve Drive Specialties’ swervelib to drive our modules. Last year, we switched to WPILib’s swerve implementation. In both those cases, our drivebase code ended up moderately messy. We were really hoping that by switching to YAGSL we could cleanup our side of drivebase code and leave the nitty-gritty details to YAGSL.

Unfortunately, as CTRE just released Phoenix 6 API to all, we found the 2024 version of YAGSL to be pretty buggy with this big switch-up. We ended up spending nearly the whole week debugging. However, by the end of the week, we did have a working robot. For those also trying to get YAGSL working on their robot, check out our repository for an example of a working implementation. I’ve also submitted a few PRs to YAGSL’s repository to help clean up some of their bugs.

Game piece detection was quite quick to setup. We used our v1 limelight with Coral’s AI accelerator to speed up the game piece detection. At the end of the week, we were working on generating paths to drive the robot directly to the game pieces, but we weren’t quite able to finish in time. We’ll continue exploring this further into the season.

That just about wraps up this massive update! See you soon as we continue into build season!

nstrike · January 16, 2024, 7:19pm

Thank you for finding those bugs and submitting the PR’s! They should all be merged by now.

jbko6 · January 23, 2024, 4:16am

More prototyping and our selected robot design

Our second week into the season saw lots of discussion from our robot design team in selecting our robot design as well as the completion of a new launcher prototype.

New Launcher Prototype

After our first robot design team meeting, it became apparent we were really leaning towards selecting a horizontal roller launcher design. However, we realized that we hadn’t quite prototyped that kind of design yet. So, before we locked in on it, we decided to create another prototype to confirm the idea.

This prototype features another set of wheels before the flywheels to stabilize the note as it is launched. We also played around with using uneven wheel sizes to add some spin to the note, although this prototype does not implement that idea.

Altogether, this prototype worked quite well with it being able to shoot consistently at a good distance.

Our robot design

Our robot design team met several times this week and spent a lot of time discussing our robot’s design. Due to illness and our uncertainties regarding a climb design, we were slightly delayed, with the final robot design only having been decided this past Saturday.

Let’s start with the intake.

We decided to go with an under-the-bumper design based on one of our earlier prototypes. Our swerve modules are lifted, allowing notes to pass under our bumpers and be picked up from our rollers. We use four driving rollers on each side of the robot, allowing our robot to pick up notes from all sides. We also plan on using these driving rollers to reject notes once we have one stowed.

Next, our launcher.

Our launcher design is very similar to the prototype we created earlier in the week. We’re going to attach our launcher to a pivot so that we can both aim our speaker shots and make our amp shot. To make the amp shot, we’re planning on using a hood or some other retractable system to redirect the note into the amp.

Scoring into the amp will look a bit like this, with the launcher pivoted up 90 degrees towards the amp.

Pivoting the launcher to aim into the speaker

Finally, our climb

Our climb design is inspired by FRC 95’s 2022 climber.

Although not pictured in this mockup, the climb will use torsion sprung arms regularly held down by a string attaching the hook of the arms to the drivebase. When we want to climb, we will extend the string, allowing the arms to extend up towards the chain. Pulling the arm back down with the string will complete our climb.

We’re hoping to ensure that our climb will bring the chain at the same level as our launcher pivot. Doing so should allow us to launch a note into the trap by first opening the trapdoor using our hood and then using the same hood to redirect the note similar to how we expect to score in the amp.

There’s our robot design! We’ve started CAD and programming work for each of the subsystems. One of our goals this year is try and reduce the time between concept and physical, working subsystem, so hopefully in future OA updates you’ll see these subsystems come to life soon! See you then!

AllenGregoryIV · January 23, 2024, 4:27am

Can you expand on the value that having an intake on all 4 sides will provide? We thought about a similar setup but decided against it. Since you can only hold one game piece at a time it didn’t seem like it would take that much time to spin the robot around to point the intake at the note you are driving towards.

BordomBeThyName · January 23, 2024, 7:08am

I agree that I’m not sure I see the benefit to 4-sided intaking. Some teams in 2022 had double-sided intakes because of the randomness of cargo pickups, but game pieces this year are coming from a pretty predictable spot and won’t be rolling uncontrolled around the field.

I love the simplicity of the rest of the design though! Everything stays inside the frame perimeter with only 2 degrees of freedom, very clean.

2412Kangaroo · January 23, 2024, 3:36pm

During our meetings, we had said that 4-sided intake would be helpful in auto and when picking up missed speaker shots (from us or from other teams). Specifically, the starting placement of notes in auto really favors having a side intake (designating front as the side you shoot from), especially since there isn’t a lot of time in auto and the notes are close together (so adding in rotation time would have a larger impact).
It wasn’t a high priority for us, but since we ended up picking a design that made it simple to do additional sides, we decided to go ahead and see if we can get it to work.

dwwright · January 23, 2024, 6:04pm

Interested to see if you can get this to work well! There are some note spamming strategies that will benefit significantly from side in-taking in addition to the clear advantages in auto.

jbko6 · February 2, 2024, 3:46am

More robot updates

We’ve dived deep into the development process. We’ve made good progress with our CAD, our code, and our physical prototypes.

More prototype progress

For quite a while, we were stuck with our launcher prototype. It wasn’t shooting consistently, with the notes occasionally flipping in the air and with irregular trajectories. Eventually, however, we did discover a few issues. First, we added another set of rollers before the flywheel. These additional rollers improved the consistency of the note’s angle as it entered the flywheel. They ensure the note is level relative to the flywheel. Next, we actually tuned PID for the flywheel. This helped us ensure consistent testing as the flywheel’s speed was more predictable. Finally, we reduced the horizontal compression of the note. It’s now only compresses the note 1/16th of an inch on either side of the launcher. With less compression, the note maintains a more circular shape as it proceeds through the launcher.

Our launcher is now much more consistent

We also tested out our launcher’s amp scoring capabilities. Inspired by Team 4481 Team Rembrandts, we decided to try out scoring into the amp by reversing some rollers. This method worked pretty well with our design.

With these tests, we found our flywheels would push the note up towards the top of the amp and keep it from scoring down. However, once we moved away, the note did fall right in.

CAD Progress

After inspecting a bit more climb geometry, we realized that our selected climb design would have difficulties lifting our robot high enough to allow our launcher to score into the trap. We’ve also been paying close attention to threads here on Chief Delphi discussing shooting into the trap from the ground. With these developments, we decided to pivot on our climb decision. Rather than employ a separate climb subsystem, we’re attaching two hook systems to our launcher. We’ll use two pivots off our launcher with hooks attached at a distance.

We expect to be able to reach at least 3 feet from the ground with this design, allowing us to climb along most of the chain. We also expect this design to allow at least one other robot to climb along with us on the same chain, although having all three robots on the same chain seems unlikely. We plan to shoot into the trap throughout the duration of the match. Once we have our stage built, we’ll do some more launcher testing with it, and we hope to achieve decent accuracy.

Code Progress

Our programming team is progressing along well. Our programmers are split between subsystems right now. I’ll include details on some of the interesting developments

Drivebase

We’ve continued our experiments with Choreo and PathPlanner for autonomous. We created a few diagnostic paths for us to tune our odometry and PID on. These paths consist of a marked starting location (we use a tape square on our field), a difficult trajectory (mostly spinning or capricious translation), and then a return to the start location. Using these paths, we can identify what kinds of movements mess up our odometry the most. Then, we plan to identify methods to reduce odometry error.

This xsin(x)-like path really did a number of our odometry.

This path featured lots of rotating which messed up our odometry a lot.

Vision

This year we’re not only continuing our AprilTag vision exploration, we’re also branching into object detection with Limelight’s neural network interface. We plan to include AprilTag cameras on the front of the robot (the same side as where the notes are launched from) and our Limelight for object detection on the back of the robot.

Since we’ll generally be facing our targets when lining up to launch, we decided on only placing AprilTag cameras on the front of the robot. This might come back to bite us if this isn’t enough data for accurate odometry correction, but we’ll see.

We also decided on really only using object detection for our autonomous pathing. We plan on using object detection to both improve our pathing toward game objects, and to see if game objects are really there before we path towards them. Since this game has a set of game pieces that are accessible by either alliance, we want to make sure the game pieces are really still there before we spend time moving towards them. If game pieces have already been taken, we’ll instead switch to a different autonomous trajectory. Since we expect to always be facing towards the speaker during auto and therefore the center line game pieces will always be facing the back of our bot, we decided to only put game object detection cameras on the back of the robot.

Climb

Previously to our decision to nix the separated climb subsystem, we had a climb programming group. Now that climb is integrated with the launcher, we’ve moved those programmers into our intake group. They’re helping integrate sensors into the design.

Okay, that’s about all the updates I have to share. More to come soon!

jbko6 · February 9, 2024, 4:03am

Coming along

Hi all! This past week we have been focused on refining our CAD, ordering parts, and generally preparing to move forward towards more hands-on manufacturing and assembly.

CAD Polishing and Design Review

Our team’s CAD experts have been hard at work polishing up our robot CAD and finalizing the last elements of our design. On Tuesday we held a design review with both the programming and mechanical teams to review the CAD and ensure everyone is on the same page. This consisted of the Solidworks CAD being presented with a few mech members going through the design choices of each subsystem. Speaking of design choices, let’s highlight a few interesting ones.

Flywheel motors

We’re using Vortexes for our flywheels, and, to keep everything within the launcher frame, we decided to put the motor itself inside a few of the wheels. We’ll see how well the Vortexes handles the temperature dissipation constraint of being wrapped in a rubber wheel once our robot is up and working.

Tensioned Rollerbar Belts

We’re using RoboBitz’ RoboRollerz for our indexing up until the launcher flywheels. All the rollers are driven together via belts and gears. The belt path is shown by the thin gray lines along the rollers in this CAD screenshot. The two wheels next to the middle roller aren’t completely fixed along the vertical axis. If you look closely, the slots they move along are visible. All this should help keep our belts tensioned.

Pivot

Our pivot geometry ended up a pretty interesting this year due to space constraints caused by the location of our swerve modules. We also employ a tensioner here for the chain. This pivot design is pretty similar to the one used in the arm of our 2023 robot, Crane.

Programming Updates

We’ve also been progressing along on the programming team.

LEDS

We’re now looking to add an LED strip to the robot. We’ve realized that with our under-the-bumper intake and with field elements heavily restricting driver vision, we need some way to signal to drivers that the robot has successfully picked up a game piece. We’d also like to be able to signal to human players which amp buttons we’d like them to press.

Logging

We’ve also been focused on adding additional logging and configuration to all our subsystems. We’re trying to reduce the time we spend tweaking values during tuning. The last few years, we’ve had to redeploy code over and over to adjust things like PIDF values. This year, we should be able to do all that tuning through Shuffleboard. To help with this goal, I wrote a sendable wrapper class for the Spark Max PID controller.

That’s about all the updates I have for now. See you in the next post!

cincomurchison · February 9, 2024, 4:27am

Are you able to provide a picture of the full robot CAD? I’m having a bit of a tough time understanding how the architecture comes together

Domtech · February 9, 2024, 6:54am

Looks something like this:

jbko6 · February 21, 2024, 1:17am

This post was written on Friday the 16th

Manufacturing and Assembly

This past week has been hyper-focused on manufacturing, assembly, and general preparation for robot testing.

Mechanical Work

Mech has been working to catch up to meet the robot deadline but has been set back by assembly errors and some issues regarding organization. Nevertheless, Mech has been making some serious progress.

It drives!

Early in the week we assembled our drivebase and tested it out. We were extremely pleased by the bot’s speed. We’re running a 5.4:1 drive motor gear ratio which comes out to a calculated free-speed of 18.9 feet per second with our Kraken motors. We’re also running 3d printed TPU wheels to improve grip and we’re considering increasing our wheel diameter to improve some aspects of our intake design. Overall, it runs well and we’re quite happy with it.

Index and Intake Assembly

We’ve prioritized our intake and index for assembly over our launcher. Our 3d printed belt sprockets double as spacers in this design, minimizing assembly time. Or, that was the idea, but an error in sizing with the first iteration of the sprockets caused a delay in assembly. Regardless, we’re well on our way to functioning intake and index by this point

Pivot Plates

Our Omio CNC has been super busy this past week cutting both aluminum and polycarb plates. Here’s a nice photo of some cut aluminum plates we’re using for our pivot this year.

Programming Prepping

Programming has spent the week finalizing robot code and adding additional functionality anticipating issues during robot testing. For one, we’re adding diagnostic commands to each of our subsystems. Running these commands tests all functions of the subsystem. Once Mech hands over the robot, we should be able to power through each these diagnostic commands and figure out quickly what needs to be fixed.

As mentioned in my last post, we’ve also been focused on adding logging and we hope this will also speed up our testing of the robot. Generally, with mechanical delays adding up, programming is expecting to have its timeline shortened, so we’re trying to prepare for that possibility.

Finally, our fully integrated launching command has also been implemented. We use a vision-enhanced robot pose to calculate the robot’s yaw angle to to the speaker, then use PID control to rotate the robot to that angle. For launcher angle and RPM, we use an interpolating tree map with data interpreted from a CSV file. Once the robot is aligned to the speaker and the launcher is up to its target RPM, the drive controller vibrates to signal to the driver that the robot is ready to launch. We used a very similar setup two years ago for Rapid React and it worked well, so we’re hoping for good results this year as well.

As for the general mood on programming this past week… well, there’s been a lot of references to one of our Instagram reels we posted a few weeks back.

That’s about all for now! I’ll have more updates soon as next week is Midwinter break for us (aka next week is all robotics).

jbko6 · February 28, 2024, 4:35am

A working robot

Over mid-winter break we were finally able to catch up a bit and assemble the full robot. We were also able to test it out with our programming!

Mechanical delivers

We thoroughly used mid-winter break, meeting every day of it for nearly the entire day each time (with mech meeting mornings and programming evenings). In exchange for our time, mech was able to deliver a fully-assembled robot.

As foreshadowed in my last post, we did end up increasing the size of our wheels. Our intake was just a bit too low to the ground to effectively intake notes. To do this, we ended up just printing larger TPU tires to fit around our billet wheels.

Low infill percentages make the tires a little squishy in a manner similar to Michelin’s Tweels

We started off mid-winter break away from the shop. With our school closed due to President’s Day, we met at the newly christened Steamnasium, which is an old school district building our district turned into a robotics hub (after advocacy from district teams). Go Bellevue Alliance!!

The Steamnasium a few weeks ago. The field elements are all mostly in place now.

Since we were away from the shop, we weren’t able to make massive progress with the bot mechanically. However, we were able to attach the intake rollers and test them out… at which point we discovered that we had made them too high off the ground for the notes to be affected by them. However, this was a pretty simple fix of just adding spacers to the mounting hardware for intake. Later, for a more permanent fix we simply decreased the diameter of our wheels slightly.

In general, we were able to fully manufacture each part of the robot either before or during the beginning of mid-winter break. However, assembly ended up taking a sizeable chunk of time.

Fixing the launcher to the pivot assembly.

However, by Friday night mech finally had a workable robot to hand over to Programming.

Programming gets the robot

Programming ended up with Friday night and most of Saturday to work with the robot. Wasting no time, they got right to work testing the core features of the robot.

Working from bottom to top, Programming started with intake. With the new wheels and spacers, intake worked quite well. Although worn down notes don’t slide as well on the carpet into the ingestion system, the robot doesn’t need to give much more assistance moving on top of the note for it to reach the index. Unfortunately, we didn’t capture any video of this in action.

Index and feeder systems also worked alright, but we did identify one case where notes can get stuck in the belly pan. This happens when we intake when the launcher is vertical, which is when we have the largest gaps in our rollers.

Before we added an extra bar, this pivot angle would sometimes cause notes to get stuck in the bellypan.

Finally, we tested out the launcher and pivot. These also worked quite well. We were able to make several shots from a few tested distances. For control, for now at least we’re using a combination of manual control using controller joysticks and presets for common positions such as at the subwoofer.

Video of the launcher making a shot into the speaker

For fun, we decided to launch a note straight up into the air. For reference, we estimate the room of the atrium (where the note is launched in this video), to be about 60 feet high.

At the end of Saturday, we had a bot that we reckon could compete competitively at our week 1 event, Glacier Peak. However, we do still have a week left to work, so we’re very excited to see what improvements we can make to the bot. More updates soon!

Robototes · April 10, 2024, 4:58am

We are excited to announce our 2024 trading shirts are now available for order. Orders can be picked up from our pit at worlds, or from our shop when we return. Orders not picked up by June will be donated to the team.

Copy Pasta of a wonderful post by @rainyskies

Own a piece of robototes history with our new shirts, featuring a mountain dew inspired design as well as the CAD of our 2024 robot, Toucan. Shirts will be available for pit pickup at the world championship in Houston. Orders close Thursday, so get yours soon!

TheRohan · April 10, 2024, 5:20am

I didnt see, did you ever get the 4 sided intake working? I remember you had issues at Glacier Peak

Domtech · April 11, 2024, 10:19pm

Bumping this. There are only a few hours left to order shirts. We may have to place the order sooner than the countdown on the website so don’t delay!

Yes it works!

At glacier peak it was really good at getting a note under the robot, but bad at lifting it off the ground.

For Sammamish, we rebuilt our index/ingest to have a pair of low rollers to lift the notes off the ground better and to have a more direct path when intaking from the back (the trade off is the back no longer has a roller right behind the bumper). We also redid the front/side rollers from roller tubes to compliant wheels to save weight and decrease sensitivity to note wear. During the event we 3D printed a pair of wedges and added them to the side intakes to help the notes make the turn into the indexer. Our programming team also implemented sensors to reverse the intakes once a note is grabbed. It was really cool to see the bot drive over 2 notes and pick up one while spitting out the other!

At DCMP our driver mainly used the rear intake due to the shorter path and more experience with it.

In the 3 days we had the bot after DCMP, our driver put in several events worth of practice and really focused on utilizing the side intakes to speed up cycles. We also realized that we were really limiting the acceleration of our bot with the way we had set current limits, after turning those up we were able to shave seconds off of our cross field cycle times. We also added a Rev through bore encoder to our launcher pivot to replace the failing lamprey encoder, and re-tuned auto aim to be very accurate anywhere within the close half of the field.

I’m really happy with how the bot is looking going in to worlds!