FRC 7461 Sushi Squad 2022 Build Thread

[howlongismyname]

Hi! FRC team 7461, Sushi Squad, is excited to be joining the open alliance for the 2022 season. We are a community team based in Redmond, Washington, and looking to contribute some ideas to the community while having a fun build season.

After an intense mock build and training season in which our new members built the majority of our offseason robot, we’ve been taking it pretty slow. A few weeks ago, we had our mock kickoff, and since then, we have been impatiently waiting for build season. Many details are still in the air for us, but we’ll be running the kit of parts drive train, and we recently got an Omio which will allow us to machine in-house parts instead of relying on online cutting services.

Our main goal is to get our robot done by week 4, so most of our decisions will be based on that timeline. In addition, we will be using as many COTS and community resources as possible to ensure our robot gets done on time.

We’ll be posting the majority of our photos and informal updates on the open alliance discord server, along with our main build blog on this thread.

Thank you for reading this post. Good luck everyone!

[forty-two]

Build season: week one

Kickoff

Team 7461 started kickoff by officially moving into our new space. The increased amount of workspace and tools that we now have access to has reduced the stress of this build season and heavily impacted the team’s efficiency for the better.

The team had two kickoff days; Saturday was in person, and Sunday was online.

Saturday morning, we watched the broadcast, read the game manual, and broke down the game. In the afternoon, smaller groups were assigned archetypes to analyze cycle times.

Sunday, we once again split off into smaller groups to discuss how the team should approach this game and what we should prioritize. Once the team regrouped, we created the priority list and started some mechanism talk.

Game Strategy and breakdown

The team discussed six different archetypes and analyzed how we could gain the most points in the least amount of time and how to gain the most RP. For every archetype, smaller groups formulated cycle times, and later the whole team discussed which archetype would work best.

In the end, we decided on a slightly modified version of R5. Ground pick up, 6 point climb, and shooting against the hub.

The three options we considered shooting from were the launch pad, the end of the tarmac, and from against the hub. We decided to go with shooting from against the hub because lining up within the launch pad would take away precious time, and shooting from the tarmac makes us vulnerable with defense. Shooting against the hub is the best option since it’s an easy position to get into and line up against. In addition, there are four places to shoot from, and defense is made to be somewhat difficult.

Although we can score two goals at once, and we wouldn’t be as vulnerable to defense if we scored in the low goal, the team decided to go with the high goal because we can score the same amount of points in half the cycles. Our primary concern with shooting in the high goal is missing the shot; however, our experience with the 2020 bots makes us feel confident that we can pull this off.

Robot design

Shooter

With the off-season robot in 2021, our prominent jam spot was where the hopper and the shooter integrated.To avoid that, we took inspiration from 2135’s 2021 robot and have decided to go with a wide shooter. Instead of going with a double-wide shooter, the team has decided to go with a 1.5 wide shooter in order to mount our climb.

The team has decided that it would be best to build a fixed shooter that shoots from against the hub. We feel that shooting from anywhere in the field would require an adjustable hood and a turret, or defense would be effective against us. In addition, not only does it take many resources to build an adjustable hood and a turret, but lining the angle up will take away much-needed time.

Climb

Speaking of climb, the team has bought WCP’s GreyT Telescope as we feel that building a reliable climb would take up lots of resources that are better directed elsewhere on the robot. In addition, because climb can hardly fit two robots side by side, we have decided to build a smaller robot.

Hopper

We have decided to go with a wide shooter to make indexing the ball much simpler. Our hopper is essentially a conveyor belt that feeds right into the shooter.

Intake

The team has decided to go with an over-the-bumper, touch it own it intake. Due to game pieces being so sparse on the field and the team having experience with over-the-bumper intakes, this is the easiest path for us to build a successful robot.

Drivetrain

We are using a kit of parts drivetrain, for both reliability and simplicity. The team does not have enough experience building a WCD, and we don’t have enough time to build, test, code, and tune a swerve drive. With a kit of parts drivetrain, we can spend time elsewhere on the robot.

Prototyping: progress on prototyping

There was no meeting on Monday (1/10); however, we got an initial CAD done for prototyping.

Tuesday (1/11), we got training on how to use the laser cutters and 3d printers, split up into our subsystems, and got to work.

Field Elements

We have a climb and a hub assembled and ready to use.

Shooter

The shooter prototype has been fully assembled, and we are currently testing how to angle the shooter and compression

Shooter prototype test 1

https://www.youtube.com/watch?v=mfWx3RW6KEE

Intake

The intake prototype has been fully assembled, attached to a drivetrain, and tested for compression.

intake prototype test 1

https://www.youtube.com/watch?v=m-Sg-v-Ttdk

Hopper

The hopper is fully assembled, attached to the drivetrain, and we are currently working on how to angle the hopper.

Intake prototype test 2

https://www.youtube.com/watch?v=JuuPOwaAd-M

Climb

We are currently waiting for the west coast products telescoping arm to arrive. In the meantime, we have chosen to rely on the falcon’s brake mode because our robot needs to be light, and the pneumatics sticks out of frame perimeter.

Drive Train

We are currently waiting for our drive train to arrive, we ordered the andymark am14u5 chassis, and we already have the toughbox minis/belts/wheels.

Goals

The main goal is to have the robot built by week three-four with programming and tuning to get more in drive practice. In addition, this year our team has decided to go for chairmans and we are all pretty excited to be participating in that.

[howlongismyname]

[howlongismyname]

Obligatory intake video, update post will come soon,
We’ve finished our prototype bot mostly, waiting on new kitbot + climb to arrive atm
Going to start manufacturing parts for competition robot tomorrow.

General things, finals week is going and a breakout of covid took out a lot of members, so generally low participation atm, cad is in a state where we can start manufacturing our frame and whatnot.

We found something with a floppy polycarb backing, in which we only attach the ends of the polycarb to the shooter that makes our shots a bit more consistent, but more testing is necessary to see if it’s actually doing anything.

For shooter videos:
Shows a bit of the floppy polycarb and our indexing/shooting, we’re planning on getting a cone to test bounce, and maybe a back wheel for backspin purposes.

Notion – The all-in-one workspace for your notes, tasks, wikis, and databases.

[snichols]

Thanks for sharing - this is really cool to see! I’m impressed by how fast you were able to throw together fairly sophisticated prototypes.

I noticed that you ranked climbing as a higher priority than intake or shooting, yet it looks like all the work you’ve done so far is intake and shooting design & prototyping. Did your priorities change after that initial assessment? Or is there climber development going on that you’re just not ready to share yet?

[howlongismyname]

We ordered the west coast products telescoping tube, though it hasn’t arrived yet, so we’re working on other things while waiting. Hook cad is theoretically done, so there isn’t much change, basically just a double hook 2020 style.

The climb is a higher priority than shooting/intaking/whatnot because we like the consistent points, and we think it will be more critical to winning matches. Still, to make it as reliable as possible, we’re relying on a COTS solution as we don’t have as much experience with climbs, which hasn’t arrived yet.

Hopefully that helps!

[forty-two]

Build Season: week two

General Week

Due to a couple COVID cases on the team as well as week three being finals week, week two was a little slow. Members had to get a confirmed negative test to return in person, and a couple new COVID procedures and safety measures were put into place.

best robot reveal winning worlds

Progress on Prototyping

Shooter

We connected the motors with the electrical board and tested shooter integration with the hopper. Two main problems arose. The first one is that when the two balls have different compressions, they end up hitting each other in the air. The second one is that since the hopper is wider than the shooter, it is possible for the two balls to feed through the shooter side by side. That is an issue because we have a 1.5 wide shooter and it messes with compression. One possible solution is making a 2 wide shooting instead of 1.5; however, that would require widening the drivetrain base for us to mount climb.

IMG 7673

Intake

The first iteration of intake prototyping was mounted onto our drivetrain for intake numbers. After gaining those, iteration number two was CAD-ded, parts were laser cut/3D printed and then assembled. However, we did not have the correct shoulder bolts for the linkage and, despite having our second iteration mounted onto the drivetrain, we could not test with it yet.

E5DB0EDC D8B5 411F 9160 A405DBC2AB48

Hopper

We tested the integration between intake, hopper, and shooter, and attached some initial hopper walls using cardboard and zipties.

Climb

Climb has yet to arrive, but the hook has been CAD-ded.

Drivetrain

We are currently waiting for our drivetrain to arrive.

Field Elements

This past week, we cut field elements and installed new parts. The inner goal got assembled, the upper goal was mounted onto the hub, and some structural fixes occured. In addition, we got access to part of the parking structure in our build space, and all field elements have been moved down there for testing.

Programming Subteam

For the first time in two years, our team got path following working!

20220123 125735

We mostly worked on auto and testing shooter speeds this week. The prototype code and the camera code is completed.

20220123 141554

GitHub - SushiSquad7461/falcon-drive-template: WPILib project containing a...

In addition, we programmed our scouting app and are currently working on the design of said app.

[forty-two]

Build Season: week three

General Week

Due to this week being finals week for majority of our students, it was a slow week. We finished prototyping and started manufacturing parts.

Progress on Prototyping

Intake

After testing the intake we found out that there was to much compression on outer wheels. However that problem should fixed with some minor edits and a change of motors (from 755s to falcons).

IMG 7722

IMG 7721

Also, because we didn’t have the correct belts, our intake prototype was more successful with chain. We are still planning on using belts on our final iteration.

Manufacturing progress

Shooter

Most of the metal parts are cut and sanded. We also got some 3/8s shafts cut and tapped for the backing of the shooter.

Hopper

We’ve parts and got hopper superstructure cut out. We’re planning on assembling starting week four.

Intake

Pneumatics mounting is yet to be fully fixed as we were waiting on some parts to come in. Wheel spacers were remodeled and assembled

Climb

Hasn’t arrived

Drivetrain

Hasn’t arrived

Field Elements

The team set up wifi in the garage, where field elements are set up for testing.

Programming

This week in programming we have a two ball auto, and are working on implementing a laser shark sensor. We’ve made progress on the scouting app and have used Axon to create a vision model. Right now, we are working on Axon based ball recognition.

SushiCV Test 0 test

(It has been perfected since this test)

[forty-two]

PRACTICE BOT IS ASSEMBLED

[heatblast016]

“assembled”

[howlongismyname]

close enough

[forty-two]

Build Season: week four

General Week

Week four was one of our most productive weeks yet! We were able to manufacture and assemble our entire practice robot even though we encountered some issues early on in the week.

Manufacturing progress

Shooter

We started building the shooter for our practice robot. We opted to make this out of wood to reduce materials cost and it didn’t seem to affect testing on our prototype. By the end of the week, this was completed and mounted onto our practice robot.

Intake

The intake was also completed by the end of the week. We spent a bit of time at the beginning of the week contemplating between 2 designs, but ultimately chose the design that we prototyped first. We did end up using chain on this practice intake because we were still waiting on a few things to arrive, but the final iteration will use belts.

Hopper

At the beginning of the week, we started gathering and manufacturing parts for the hopper and it was the first subsystem to be fully assembled! Please enjoy the video of our super cool Belt Drive.

IMG 1646

IMG 5398

Drive

Unfortunately our drive base from AndyMark has yet to arrive; we received one package that was just the battery mounting kit but had none of the rails. This puts our schedule back a little bit as we were hoping to finish assembling it for our final robot this week, but nonetheless we continued making our mechanisms to put onto the practice drive base.

We did encounter an issue when mounting subsystems to our current drivetrain. There was interference with a gearbox due to the fact that the frame was longer than we plan to have our final robot. After considering a few different solutions including cutting the rails of the practice robot, we fixed this by moving the 2x1 superstructure back by a little bit. This ensured we didn’t lose valuable time with our practice robot since we were still waiting for the final drivetrain.

Climb

Hasn’t arrived yet, but hopefully will next week.

Programming

The focus for this week was primarily making sure that all of our subsystems had working code for our practice bot. We rewrote a few subsystems and added our controller mappings. On Saturday we finally got to tes​​tings, and barring a few initial hiccups, all of the subsystems were working as expected.

Assembly Photos

IMG 5433

Things that make me happy

IMG 5397 MOV 1

Sushi Scouts

The Sushi Scouts is designed to get us quantitative data about team performance during competitions. It is designed to be used without internet access.

Tech Specs: It is a web app written in Next.js, a JavaScript framework. We also use Typescript instead of JavaScript. The data is currently stored in a CSV file. We didn’t use a database such as MySQL because we didn’t need such advanced features, and also the data analysis website we are going to use supports CSV files.

Hardware: Currently we are hosting the web app on a Raspberry Pi. Currently, we are using a network switch and physically hooking up client computers to the Raspberry Pi. However we are planning to incorporate a Private area network into our design so that we can have a wireless connection that doesn’t interfere with the field connection.

Features: The input format is stored in a JSON file so changing it from year to year should be as simple as changing the JSON and modifying some CSS.

Team number, the comp name, the match type and match number are stored in local storage so that if you close the page or reload these options will be saved. The match number will also increment by one every time you click the submit button.

When a user enters in a match number, and the match type it will autofill the robot number input. Each computer is assigned their own alliance member to scout. We use a CSV to store the match schedule for easy access. Currently the match schedule has to be manually uploaded, however in the future we are planning to get that match schedule from the FIRST Inspires API.

Current status and next steps: Currently we have a Beta of the app done, however there are still a lot of things that can still be worked on. One of these is allowing other teams to view the data. If time permits, we would also like to consider uploading the data to Firebase when we get internet access to reduce data loss. We are also working on a CLI to make the process of uploading match schedules, inputting team info, etc. easier. There are also a lot of minor styling, and code quality issues that need to be fixed.

We were also considering making a generic version of the app so other teams would be able to use their own instances of it. You can find the public packages of the app below, and hopefully we can make it more generic and accessible in the future as well.

GitHub - SushiSquad7461/2022-sushi-scouts: Scouting webapp for FRC's 2022...

sushiscouts

[howlongismyname]

5 Ball Auto

New video by howlongismyname

It’s a little bit long at 20 seconds and one of the balls didn’t shoot but we’re having a fix for that with our hopper

Currently working on tuning our auto and implementing hopper walls to get everything legal.

[lelerma]

Been a long time, here’s our official robot reveal as seen on the FIRSTUpdatesNow Premiere Night! Meet Tsunami!

FRC Team 7461 Sushi Squad 2022 Robot Reveal - Nami

And a little sneak-peek of our climb!

New video by danny

Catch us at the Week 1 event PNW Glacier Peak.

[lelerma]

Hi everyone, this is a very long overdue update. Since the last post, we’ve competed at 2 district events as well as our district championships. Unfortunately we fell a few ranking places short of qualifying for worlds. Nonetheless, it’s been a very educational experience and we’re super grateful for the Open Alliance’s help as well as our other alliance, the Bellevue Alliance. This will be a general recap post of everything that’s happened as well as changes we made to the robot over the course of the competition season.

To start, we competed at the PNW Glacier Peak event in Week 1, where we had an incredible qualifications run—making a 12-0-0 record with a 2.75 RP average—placing our team at rank number 2. We picked teams 2930 Sonic Squirrels and 2928 Viking Robotics as our alliance partners of Alliance 2, who helped us get to the Finals. We were also very happy to receive the District Engineering Inspiration award, something we definitely didn’t expect. All outreach work will be linked below in our Document Release. Below is our entire team at the Glacier Peak event.

Robot-wise, our shooter performed well, not sure the exact percentage on shots but we ran around 12-14 cargo per qualification matches. We ran our mid-rung climber as well, helping to supplement other climbers in matches.

After returning home from Glacier Peak (only a 30 minute drive luckily!) we decided that we wanted to slowly work towards a traversal climb, if possible. But we kept it a reach goal, for DCMP if we end up qualifying.

We ended up switching from the WCP climber-in-a-box setup to the TTB one, which ended up working out much better. Shown below is our robot in our workspace, mid-wiring. We made too many iterations to count towards the climber, but none of them ended up working, so we returned to the original version by the time SunDome rolled around.

In between the Glacier Peak event and the upcoming SunDome event, we also did an outreach event at Timberline Middle School, one of the middle schools in the nearby school district. We received a lot of good attention and feedback from middle schoolers as well as parents of these students. A lot expressed interest in joining the team when they reach high school age.

At the SunDome district event, we once again ended up captaining Alliance 2, this time as rank 3. We went 8-4-0 with a 2.08 RP average. Our alliance partners were 2147 CHUCK and 4104 Error-4104. And once again, we got to the Finals. Our team also received the Entrepreneurship award due to our business plan presentation and sustainability plans (outline below in the docs!).

One problem that constantly plagues our climber is that the two sides aren’t even (and we still haven’t fully figured out why). There are many instances where we go for a climb only for the left hook to slip and end up looking like this:

Later on when we worked on the traversal climb, this continued to happen. We’ve tried every single micro-fix, from replacing the rope (switched to Dyneema) to replacing the bearing blocks, replacing the Delrin hard stops, replacing the hooks, remaking the hooks, and more. It continued to happen, even at DCMP.

In between SunDome and DCMP, we made lots of changes. We tuned our autonomous to have a few different possible routines: a right side 5b (which is very hard when you don’t have swerve and/or turret), a left side 2b, a left side 2b + 2b deny (where we shoot the enemy cargo into the hangar to make it harder for them to retrieve during the match), a right side 3b, and more. We had some semblance of a traversal climber, we redid our pit, made a banner for the pit, fixed drivetrain (partially with code), got interviewed by Kevin Ross—y’know, the usual.

We successfully traversal climbed once, in a qualification match. Unfortunately from then on, the climber was always broken in one way or another. Like I mentioned earlier, we have no idea what was wrong exactly. As for autonomous, we usually ran our left side 2b since our other alliance partners had a more reliable 5b auto for the right side. However, tragedy struck, as during our last qualification match, we were awarded a red card for reaching inside another robot and damaging it. What happened was that while the robot was going over the center cable beam, we collided with 2471’s robot and they ended up mounting ours. Our intake had accidentally been lodged inside their robot, which consequentially ripped out their battery connector and turned them off for over a minute. Due to this red card, we were unfortunately DNP-ed by a few teams towards the end, making us go unpicked during Alliance Selection. This also brought the end of our competitive season.

Documentation Release

Sushi Squad 7461 documentation release

team 7461 is proud to share our documents for the 2022 season! although we tried for and didn’t get chairman’s, these documents helped us win engineering inspiration at our first district event and entrepreneurship at our second. also fyi, the brand standards are still in progress and will be fully completed in the future. enjoy technical binder chairman’s binder summary business plan safety manual judge’s handout brand standards

P.S. Shoutout to our friends from the PNW Open Alliance as well as the Bellevue Alliance.

Us with 2412 The Robototes (BA)

Us with 3636 The Generals (OA)

We have many plans for the offseason, and we’ll update more when that comes to be! For now though, our team is taking a well-deserved break for the upcoming month.

7461 Sushi Squad signing off

[howlongismyname]

Offseason Prog Update #1

So since an OA post hasn’t been made in months, we have decided to restart our OA posts, starting with programming. We are planning on doing a subteam-specific post each Saturday. Specifically for programming, we were going to split the post into three parts, Robot Code, Non-Robot Code, and Training. Also, this is prog specific; however, we plan to do some whitepaper writing later in the offseason on some of our more significant projects like our Scouting App and Scheduler.

Robot Code

Many changes have happened with our robot code since DCMP back in April. Most of them are attributed to Brian (our new prog mentor!). Brian is a former 4911 mentor, and when he joined the team, he decided it would be valuable for us to review how the 4911 code worked. Specifically, he reviewed how they implemented a custom scheduler based on 254’s scheduler. The 4911 scheduler allows their team to adjust how often periodic is called. After he explained how the scheduler worked, we decided that this was something we wanted to implement. However, we had a lot of changes we wanted to make. 4911’s code gave subsystems a lot of low-level control over how they were scheduled. This is something that we were hesitant about. Not only did it make subsystem code look bloated in our eyes it also opened a lot of chances for stupid errors when writing code. As such, we sat down and started trying to abstract as much of the scheduler as possible. We will not go into much depth in this post, but we will probably publish a much longer post explaining everything we did and how the scheduler works.

However, it worked well once the changes got right into testing, and surprisingly, aside from a couple of minor bugs. We still haven’t done anything advanced with it but plan to start “battle testing” it in the next couple of weeks. Aside from the scheduler, Brian has strongly urged/convinced us to write custom swerve code. At the start of the offseason, we were planning on using the SDS library. However, after Brian explained custom swerve to our prog team, we felt confident we could implement it. We currently have the swerve module and kinematics code written and are testing it on an SDS MK4 module. Currently, we are having CAN bus issue, but we think this is an electrical problem. One final change is that we have started to abstract our code in SushiLib. This change happened right as the offseason began, and since then, we have written a lot of utility functions/classes that simplify our subsystem code.

Current robot, same robot we used in season

Non-Robot Code

Our main non-robot code project this year is our scouting app. We have a discord bot that tracks attendance, but that’s a relatively small and tedious project, so we probably will not mention it here, though if you have any questions, we’ll be willing to answer them. This offseason, we set off with the goal of making a scouting app that could be configured for a new game with a few buttons and no code changes, and we are getting reasonably close to getting it done. Currently, we have a primarily operational scouting app (Sushi Scouts). In contrast, the config file builder (Sushi Structures), which allows us to create a JSON file that tells the scouting app what data to collect, is expected to be finished by the end of this week. All data from our scouting app will be stored on a tablet running the Sushi Supervise app. This is expected to be finished by the end of August. Finally, we are planning to create another app called Sushi Strategy that will be responsible for data visualization and analysis, but this is something that is low priority as Sushi Structures will be able to export in CSV format, making it so that we can use a tool like Tableau for our data visualizations. Also, if people want more information, here is a white paper on the proposed changes Sushi Scouts - Google Docs, this was written in April, so things have changed since then, but the Cardinal, Ordinal, and Pit scouting methods are still the same.

Scouting App Figma

Training

During the start of the summer, we decided to have to train pathways. The first pathway teaches people java from scratch and assumes people don’t know any programming when they join. The second pathway assumes you are proficient in java and teaches you robot code. After members are done with the first pathway, they can continue to the second, and if they want to skip the first pathway, they need to solve a coding problem in java to ensure they are proficient. Brian teaches both of our pathways. We also have two members with prior experience with FRC who are doing their training through shadowing current prog members. The purpose of the training section in each weekly OA post will be for them to write about what they learned/have done in the past week. The current section is written by the programming lead (daniel), but the new members will report their updates for future posts. This week, we had the new members write NEO code for the old 2021 season robot as we removed some of the falcons to use on our offseason robot. Additionally, we may use more neos on our offseason robot, allowing us to experience programming with NEOS. Outside of this, the new members got a rundown of PID from Brian, and one of the current prog members taught them a bit about the scheduler.

We thank our programming lead, Daniel, for writing this post!

Offseason robot updates:

As typical for our team, we decided on building an offseason robot to compete at our events to get practice in for the team, as well as instilling some FRC fundamentals and ideas to the new members before entering build season.

Some general robot goals:

• L3 Climb
• Intake floppy balls
• Shoot from anywhere on the field (sort of).

For things we want to learn or gain experience:

• How to use chain and sprocket
• Building custom multi-stage gearboxes
• Pocketing gearboxes
• Sensor usage and placement (beam breaks, color sensor)
• How to manufacture and assemble a robot

We’re currently working on a workflow that we’ll slowly implement and experiment with in this project, then start optimizing in more isolated environments with smaller projects. If we have time, we’ll also begin releasing and documenting our progress with our workflow on this OA thread.

Design/CAD wise, the cad is going, with the major superstructures finished and the intake assembly complete. Though we do not plan on doing a CAD release till CAD is “finished,” if you have any questions or want cad leaks, feel free to DM me or check out our discord channel, and I’ll post images and whatnot there.

The robot has heavy inspiration from 4414, 1678, and 6328. Thanks to them for their ideas!

[howlongismyname]

As our offseason progresses, we usually build a new robot to train our skills and get our new members a taste of build season. As a result, we’ve finished designing our offseason robot. We are beginning the manufacturing and assembly process, hopefully being able to compete at some offseason events while giving our programming team a decent amount of experience with more complicated robots. That being said, it is tradition to build robots that are significantly more difficult than our season robots to stretch our limits and improve our processes and skills. We’ll be building this robot and documenting our workflow improvements and experiences while going through the process, so hopefully, everyone can learn something new.

Anyway, enough with the filler, introducing our CAD for our offseason robot, “design convergence” (temp name)

They say, “steal from the best, and invent the rest,” so we’ll be using a:
4414 inspired motor pivot intake
The intake style allows us to intake bouncing balls, control our intake positioning and ball compression, and practice making multi-stage gearboxes, chain pivots, and arms.
The double flex wheel rollers might be adjusted to single roller, but the extra row of flex wheels removes a deadzone we originally had, though there may be more geometry changes as this looks kind of odd.

1678 style indexer and ball pooper (thanks citrus for the layout sketch!)
Originally planning on doing a simple flex wheel in ball tube design, we decided to add the ball eject as it seemed fun, and there was a layout sketch on Chief Delphi we could gratefully “borrow.” This style allows for an intro to ball color detection on our robot, as well as utilizing beam breaks for indexing.
Additionally, the shooter contains the spool for the L3 arm pivot.

6328-inspired adjustable hood (also heavily borrowed from our 2021 offseason robot, which is inspired by 1678’s shooter from 2020, oops)

Though rack and pinions are great, we chose to do an adjustable belt hood as we have some experience from 2021 with these and packaging pretty nicely on our robot. Hopefully, this allows our programming team to implement the learnings about PID and whatnot, as well as having a pretty cool adjustable hood where we can shoot from fender to launchpad.

a 2x2 SDS mk4i chassis (borrowed from 4414)
2x2 allows for more mounting possibilities, as well as looking pretty cool.
Center 2x2 for easier mounting, acting as a cross beam to keep the swerve rigid and hold the shooter.

As well as a flippy L3 climb inspired by 2976’s and 3175’s climb utilizing andymark’s climb in a box gearboxes.
Though we could do a traversal, an L3 seemed like a safer bet, scoring a decent amount of points and fulfilling the RP requirement for climbs at our offseason events.
(the cad is incredibly broken in this subsystem… but it works)

That being said, our primary focus is on our programming, manufacturing, and assembly processes. Using proven mechanisms will allow us to focus on our priorities and learn before the new season to build simple and fast to get as much drive practice as possible. However, we will spend some time prototyping other mechanisms to establish a workflow for things in the offseason after our events.

Though heavily inspired by other teams, we did adjust our mechanisms to fit our time and design constraints, utilizing a heavy amount of laser-cut Delrin compared to other teams. When REV ion comes out, we plan on using the grid box pattern tubing to decrease cnc router use, increasing bandwidth for plates and fun things. This will be all documented in our open alliance thread as we go through the process.

From a design standpoint, it was a huge learning experience even with the plethora of borrowed mechanisms, though it quickly showed the areas we lacked.

Any feedback is appreciated, as we currently do not have any design mentors and are looking to learn as much as possible, especially as we just lost a huge chunk of our team’s knowledge due to graduation. (a sophomore this season designed this offseason robot, so there’s lots of room and time to learn!)

For now, we need to work on optimizing our cad for load times and adjustability and separating various subassemblies into separate docs for ease of use, as well as making the part studios more parametric for future edits of CAD when necessary, as looking through tons of features wastes a lot of time.

Onshape

On the programming side, our weekly programming post was delayed slightly, so we’ll be posting that in the next few days.

As always, we’re always looking for mentors in the Greater Seattle Area, so send us a DM if you are interested.

If you have any questions, feel free to ask in this thread or on the Open Alliance Discord.
Thank you for reading!

[XaulZan11]

For the flippy L3 climb, I’d make sure you can keep the hooks inside your frame until it is time to climb. 2976’s hooks swung outside their frame and contacted and even hooked onto opponents, which I believe promoted them to remove them in the finals of DCMP when their partners were handling climbing. They were working on a solution to keep them inside the frame when I talked with them at the championship.

[howlongismyname]

Yup, we have some torsion springs on each pivot to keep the whole thing down, as well as plans for polycarb panels on the side to help keep things in on the horizontal axes.

[Cirrusx]

Sheesh this looks really good. I see the definite improvements from your in season bot. I can’t wait to see you guys at the offseason competitions.