FRC 2713 iRaiders 2022 Build Thread

[jtrv]

Hello everyone, and welcome to 2713’s first ever build thread! We are very excited to be joining the Open Alliance this year. We have all greatly looked up to Open Alliance teams in the past and we are thrilled to have the opportunity to contribute what we can to the community.

Team 2713, iRaiders, is based out of Melrose High School in Melrose, Massachusetts. We have approximately 30 students and around 12 mentors (6 of which are FRC alumni). The team has two rooms to ourselves in the school, although they are each on the smaller side and are not directly connected, so our layout is a little bit wonky, but nothing that is a hindrance to our operations. Our machine shop features a lathe, three drill presses, a band saw, a milling machine, several 3D printers, and an X-Carve CNC machine (only does polycarb/wood). We have a very amazing sheet metal sponsor, Churchill Corporation, that we will be utilizing for aluminum CNC machining tasks - such as the belly pan, gussets, and possibly drive rails. They have been a huge resource to us.

Currently, we plan on meeting Mondays through Thursdays from 5:30pm to 8:30pm, plus Saturdays from 9am to 1:30pm, which comes out to 17.5 hours per week across 5 days per week. This may change over the course of the season, due to time constraints, person constraints, COVID constraints, etc, but it’s what we plan on doing for now.

We have a few posts that we are currently working on and will get up before kickoff. We’ll outline our basic team structure/hierarchy, our goals for the season, talk about our offseason drivetrain project, and also our structure for kickoff weekend.

If you have any questions at all about anything in this thread, please don’t hesitate to reach out to us over CD or Discord! We are more than happy to help out wherever possible.

Some team media:

• Team website
• Facebook
• Instagram
• YouTube
• GitHub

Good luck to everyone in the upcoming season, have a happy holiday, and stay safe!

[jtrv]

This post was written by one of our student captains, Tina.

During our most recent captains-mentors meeting, we all discussed what goals the team wanted to achieve during our upcoming build season. We used a mind map (we used miro.com) to help organize our ideas and goals for the season. Some of the goals go from as small as just understanding the game to attending DCMP.

The six goals established:

• Attend district champs (DCMP) - The team has never qualified for DCMP in the past. We’d like to attend as we think it will be a huge inspiration to our entire team, getting to compete with the best teams in New England, including some that are in Open Alliance.
• Attend a real competition - Due to COVID, for the past two years, the team hasn’t been able to attend a real competition, and some of the students on our team haven’t been able to experience a full build season or a competition at all.
• Improve team communication - This is a recurring goal that we set every year to strengthen team communication. It is easy for communication to break down in the midst of the build season. There is always improvement to be made here.
• Town and school support - Our robotics team has been around for 10+ years and much of the community and school still isn’t very much aware of our presence within the school community. The first step of getting attention from the community is to achieve more as a team such as making it to DCMP. Along with greater goals, the PR team would work on more outreach to the community.
• Alliance captains at district events - This will greatly help us in our goal for qualifying for DCMP.
• Understand the game - We have a pretty young team, without all that much FRC experience, largely due to the team not being able to compete in 2020.

Another topic we discussed during our meeting is deciding who would be subsystem leads for the robot. We generally have three different categories for the robot for students to lead, generally consisting of the chassis, game piece manipulation, and the 30 second end period. From looking at previous years and the pre-season, the captains on the team determine potential candidates that consist of sophomores and juniors that exemplify qualities such as leadership and commitment to be a subsystem lead. The goal of this role is more of a learning experience for these sophomores and juniors to see if they are able to step up in leadership roles and management while gaining experience of robot designing and collaboration. We have 3 juniors/seniors that act in more overarching leadership roles (called captains) within the team that cover multiple areas of the team, giving guidance to subsystem leads.

[jtrv]

We’ve been fairly active in the offseason over the last few months. A couple months ago we competed at Battle of the Bay in Alton, NH (big thanks to 319 for hosting - it was a ton of fun), where we competed with the team’s 2020 robot. We seeded top 8 and captained an alliance, the third time in 2713’s history! We’d like to extend a huge to teams 238 and 7314, who were awesome to work with and willing to try out some scrappy match strategies.

This was also our first time scouting. We had a small group of people filling out scouting sheets in each match, mostly doing qualitative analysis - such as “is the robot good at scoring?” or “can the robot climb reliably?” Exact quantitative numbers weren’t super important for a 1 day offseason where most teams haven’t competed in 22 months, and could have been somewhat overwhelming to our new scouts, so we started simple. The climbing was the most important part, and our scouts did an amazing job highlighting that - we managed to grab 7314 as a third robot who we saw as the last robot with a reliable climber left, which panned out to be true in elimination matches.

Outside of Battle of the Bay, we’ve been doing a lot of stuff back in the shop. We’ve spent quite a lot of time reorganizing the shop, as the team has a ton of stuff still saved from the yesteryears of FRC - stuff that is really cool and sentimental to the FRC veterans, but not stuff that we need to have within an arm’s reach at all times in the shop. We picked up a couple extra shelving units to help organize more parts, and we completely redid our electrical cabinet(s).

We’ve also spent quite a bit of time building an offseason drivetrain, both as a CAD exercise and a manufacturing exercise. For this, we specced out the following:

• 8 wheel drive
• 4” Colsons
• 4 NEOs
• Whatever gearbox is in stock and fits the above - we went with the WCP SS Single Speed, Single reduction gearbox (nonflipped)

We initially had a 9:62 gear ratio, but we had heard about plenty of pain points with fitting 9T pinions on the NEOs. We were dumb and thought we could fit them on anyway. We were wrong. I’m not super sure the reason, but I believe the reason is because the CIM/miniCIM shafts are actually very slightly undersized, while the NEOs are true to size. We did not measure them ourselves, that’s just an explanation we heard from another member in the community. We swapped to a 10:60 gear ratio on the gearbox, which puts us up to 16ish fps. Not the biggest deal in the world, and for an offseason drivetrain, it’s more than fine.

We ran into an issue with the gearbox and NEOs, though. The gearbox has 4 mounting holes per motor, which are 60 degrees apart, as the gearbox is primarily designed around the Falcon 500. This means that there are 2 holes 180 degrees apart which is where you would mount the NEO, CIM, or miniCIM. However, the upper standoff is on neither of those holes, which means the upper standoff on the gearbox has no way to be mounted when using NEOs. We moved the standoff to a lower mounting hole, but it’s so close to the other standoff that it doesn’t really accomplish that much.

We reached out to RC about the issue and were told that the gearbox plate should have had a countersunk hole on the motor side, such that you can thread a bolt through the standoff from the motor side. Unfortunately there was a production issue that caused the plates to not have this hole. The recommended fix is to add that countersink ourselves, which we had considered, but as we were short on time, we decided not to. We recommend you do this if you have the same issue however - the lower standoff location slightly contacts the chain, which is fine for an offseason drivetrain that won’t hit the field, but we wouldn’t do it in-season. You could also tap the hole to a ¼-20 and use a ¼-20 bolt.

We manufactured the driverails in house, and we utilized our sheet metal sponsor to make us a custom belly pan. We saved some time and didn’t go all out on the diamond pattern lightening - just a simple aluminum belly pan. We got both a ⅛” and 1/16” belly pan made, so we could compare the stiffness in person.

We were hoping to get the REV control system on this robot, but as you probably know - global shipping delays. We probably wouldn’t have gotten them on the chassis anyway as we ran out of time before the holidays. We ordered 2 sets of the REV control system, so we’ll probably stick one on this chassis early in build to learn how it works early.

Attached are some photos I’ve accumulated over the last couple of months about the stuff outlined here.

[Ty_Tremblay]

Kickoff is tomorrow. I keep telling myself that over and over again and it’s surprising and exciting every time.

Kickoff is tomorrow!

How 2713 is planning to do kickoff

Understand the game as a group

1. Watch the kickoff live stream together.
2. After live stream, the entire team will get together (online, and spread out among several classrooms in the school). We put the game manual up on the projector, and we have a whiteboard handy.
   • We go throughout the room, reading the game specific part of the manual one paragraph at a time. Mentors and students alike read in turn. This forces the entire team to have read the game manual at least once.
   • After each paragraph, questions can be asked and discussion can be had.
     • Typically, the mentors will ask leading questions to the students to spark deeper game analysis
     • “Why is this a penalty?”, “How many cycles is a penalty worth in this game?”, “Why did they add a height limit here?”, etc
   • Important terminology is written on the whiteboard
     • Game element names, important rules, scoring, etc
3. Group exercise to calculate the theoretical max score
   • Gives everyone an idea of how game actions compare in value
   • Frames future conversations about our team’s contribution
   • Break down auto vs tele vs endgame
4. Make a list of all the actions a robot could do in a game
   • Scoring actions, defense, assisting, etc

Strategize in parallel

1. Break into groups of 5-10

   • Each group comes up with 3 lists and justifications for them.
     1. Our robot will do…
     2. Our robot will not do…
        • This must have at least one item in it.
     3. It’d be nice if our robot could…

2. Reconvene after ~20min of group discussion

3. Each group presents their lists, we collate, and we discuss

   • No idea is a bad idea. Even if it seems silly, it could spark a great idea for someone else.
   • We can debate tradeoffs of an entry on a list.
     • What are the pros and cons?

End of Day 1 Goal

1. Understanding of the game
2. Rough idea of what 2713’s robot will do in a match
3. No robot design discussions until Sunday

Maximum Bucket Effectiveness

2713 is in a bit of a rebuild phase, so we’re getting back to basics.

Every team has a “bucket” of resources. We spent the offseason learning how big our bucket is, and what is in it. Now that the season is starting, our focus will shift to taking the bucket we have, and maximizing how effective we can be with it.

2713 understands that our bucket isn’t as big as some other teams’ buckets, so we decided to implement a rule that there will be at least one element of the game that we will intentionally leave off the robot. If we end up with a lot of spare time on our hands, we may add it later, but we don’t want to spread our bucket too thin.

[jtrv]

Wanted to toss up a quick post about code quality that we’ll be attempting this year. You can see our 2022 repo here: https://github.com/iraiders/Robot2022

• We have a pretty healthy number of programmers, so its best we teach the students git practices early, like branches and pull requests (PRs).
• We will likely be breaking up branches by “feature,” a suggestion by FRC 900. Feature is a fairly vague term, but one of our students suggested we could define it as anything that has the potential to alter the expected performance of the robot, which I like.
• We followed WPILib’s docs on adding Spotless integration, which was super easy.
  • We went one step further and made it so Gradle’s build step depends on the spotlessApply step (which actually formats your code). That way, whenever we build, Gradle will automatically format the code for us.
  • We can also configure VSCode to format our code for us without having to build or run a gradle command.
    • Since VSCode’s default Java formatter (via the Red Hat extension) will differ slightly than Spotless’s config (which for us uses the Google Java format), we can install another VSCode extension called Spotless Gradle which adds a Spotless formatting option to VSCode. You’ll have to go into the extension’s settings and enable that though, for some reason it isn’t enabled by default.
      
      
    • Once you do that, open a Java file and hit ctrl-shift-p and hit Format Document With...:
      
    • Then hit Spotless Gradle. Or hit shift-alt-f to format your code. It should complain that there are multiple formatters installed. Click around to set the default to Spotless Gradle.

Hope you all have a safe kickoff! We’ll be posting more soon.

[jtrv]

It’s day 2 and we love the game. Following the plan we outlined above, we think we had a very successful kickoff weekend.

Day 1 (1/8)

We had some of the team virtual, some of the team in one classroom, and some of the team in another classroom. Each room (plus the virtuals!) were all connected via a Google Meet call, and we alternated between the rooms as to who was reading off the next part of the manual.

We estimated the “max score” to be around 143 points. This isn’t really the absolute maximum score as there’s no limit to how many cargo you can score in teleop, but it’s the max we realistically expect teams to get. Maybe by DCMP or CMP this score will be broken, but we’ll have to see!

We then split off into 3 groups (one group per room, and the virtual group) and each group made a list of

• Our robot will do X
• Our robot will not do Y
• It would be nice if our robot could do Z

We then shared those lists with each other, and that brought us to the end of our meeting on Saturday.

Day 2 (1/9)

MoSCoW method

Today we met again and decided to compare our 3 lists and decide, as an entire team, on what our robot will, won’t, and might do.

We decided on this:

Our robot will:

• Drive in auto
• Drive over bumps
• Drive below the low rung
• Score in the low goal
• Score in the low goal in auto
• Be able to carry 2 cargo at once
• Pick up cargo from the ground
• Score from fixed locations
  • In this case, we are talking about a wall shot from against the hub
• Hang on the lower & middle rung
• Intake and outtake cargo in opposite directions

Our robot will not:

• Shoot from anywhere on the field
• Hang on the high or traversal rung
• Monkeybar from rung to rung
• Break the rules

It would be nice if our robot could…

• Score in the high goal
• Score in the high goal in auto
• Score from the launchpad
• Catch cargo from the HP
• Feed cargo to the HP
• Have the HP score in auto

We recognize that all of our “nice-to-haves” are unlikely, but we don’t want to immediately rule them out without further prototyping data from both ourselves and the community.

The low rung

We believe that fitting under the low rung is extremely important for us. If an alliance has 3 robots that are all trying to climb in the last 30 seconds, and none of them can fit under the low rung, that means they all must enter from the side, rotate 90 degrees, and then align to their respective rungs… Sounds like a major, major headache. To give our alliance room to breathe and a larger window of execution, we see it as highly important to be able to fit under the low rung.

Cycles & high goal

We are unsure about how fast high goal cycles can be. Cargo may take 4-10 seconds to pass through the hub’s upper goal, and our (extremely nonscientific and low sample size) testing is that a ball dropping out of the high goal takes about 4ish seconds to settle. Intaking a bouncing ball is not something we have done before, and not something we have seen teams do reliably, so it is an unknown factor for us. We think that the ability to catch a bouncing ball is probably rather important, but we aren’t sure how to do it, and will wait to see more results from the community first, as it’s not a high priority for us (in fact, not even on our lists). Low goal depositing the cargo essentially immediately onto the floor for pickup should be a relatively significant difference in cycle opportunity.

The cycles seem very similar in distance to 2019 thus far. In 2019, the good teams were hitting 12-14 cycles, and the elites were hitting 16-20 cycles in a match. I would hazard a guess that cycles could be maybe 50% slower than 2019 cycles, meaning a good team could hit 6-7 cycles in a match (where each cycle is 2 cargo), or 12-14 cargo, which is nearly a solo ranking point depending on how well your auto goes.

First concepts

We began sketching out a few different basic ideas. Many of them resemble cargo passthroughs from 2019, such as the Everybot, 5406, or 1323. We view having opposite side scoring/intaking as massively important for our cycle times - turning is slow, and you should avoid it. For the most part, balls will be sorta-kinda scattered semi-randomly around the hub - you can score a lot by driving in mostly straight lines between the hub fender and the cargo on the field.

This also allows us the opportunity for a possible 4 ball auto, which would be a significant boost to our likelihood of a cargo RP in quals. We have not discussed auto too much in detail yet, but I think a safe goal would be a reliable 3 ball auto, and our reach goal could be a 4 ball auto. The team has not successfully used gyros or encoders in the past, so I’ve been introducing some of the veteran programmers to WPILib’s documentation on Ramsete and odometry in preparation for the season. We are getting a ¼ field carpet on Sunday, which we’ll use with the 2020 robot to develop paths starting early in the season (hopefully next week?).

As for the climb, we briefly looked at our COTS options, but realized we only need 1 stage to reach the middle rung. Because of that, we’ll likely be building our own single stage climber, as we don’t expect it to be a significant headache, and it will save us some money. That’s as far as we got on that front.

Motor counts

We specced out approximately how many motors we’ll need for each subsystem.

• Drivetrain: 4-6 NEOs
• Intake: 1 NEO or 1-2 NEO 550s
  • NEO or NEO 550 depends on our roller/wheel size and drivetrain speed; we need the surface speed of the intake to be greater than the drivetrain’s velocity in order to safely pick up the game piece
• Ball tube / hopper: 1 NEO
• Shooter: 1-2 NEOs
  • For the low goal, this is likely just a tiny bit of extra oomph to make sure it gets out of the hopper. It would be very slow so as not to whip it into the low goal that hard.
• Climber: 1-2 NEOs
• Total: 8-13 motors, mostly all NEOs, maybe a NEO 550 or 2

Quick intake test

We briefly powered on our 2020 robot to test how the intake worked on the ball. The ball seems much harder to grip than the 2020 balls, but it may behave differently when it’s on carpet. https://photos.app.goo.gl/ns1Qouwgs1WhVxnFA

Wrapping up

While reading the manual and doing all of that, we had someone taking summary notes in a doc, which you can view here: Copy of Kickoff 2022 Notes - Google Docs

I gave the 2713 students some prior years to take knowledge from. Specifically, for climbers, we can learn a lot from 2013, 2016, 2018, and 2020 (special thank you to Everybot). As for ball mechanisms, our closest game pieces were 2016, 2012, 2020, and 2019, in that order, but they’re all vaguely similar.

If anyone has any questions please feel free to reach out via CD or Discord!

[Ty_Tremblay]

We had an interesting development during brainstorming yesterday that I’ve thought about over night.

Idea Latching

Brainstorming is supposed to be an unfettered flow of ideas. It’s popular to say something along the lines of

Anything goes and no idea is bad.

There’s always the possibility that your “bad” or “silly” idea is actually good, or inspires someone else to have a great idea.

But what if that idea really IS good? So good, in fact, that no one else can think of an idea that is better and the brainstorming session fizzles out or dies? Do you share it now? Do you wait until further in the brainstorming session to share? This happens, and I’m going to call it Idea Latching.

Idea Latching occurs when most, if not all, of the members of the brainstorm think that one idea is the best, and “latch on” to the idea. They can’t think of ideas that are better, or all subsequent ideas assume the Latched Idea will happen. In FRC, this could be a robot concept, a strategy, a subsystem idea, or anything else. Idea Latching can be great, but it can also be really dangerous.

If you’re Latched:

• you could miss an even better idea
• you’re less creative
• future brainstorming is constrained to include the Latched idea

Or:

• You could have just had a really efficient brainstorming session and you’ve accomplished your goal.

The common example of Idea Latching in FRC sounds like this:

Team XXXX’s robot from year XXXX would play this game great.

I catch myself in this Latch every year. I go down a deep rabbit hole of trying to force this year’s game in to a previous year’s robot. I often end up with a robot that is okay at this year’s game, but not as good as if I’d tried to develop a robot to play this year’s game from scratch.

So what do we do about Idea Latching? We have two options. We can either avoid it, or turn it into a skill.

Avoid: Don’t Share Great Ideas Until the End

You could hold all of your great ideas back until the end of brainstorming. You could make sure that all ideas are presented before you drop in your epiphany. This practically ensures that the brainstorming session continues “unlatched”. There’s several problems here, though.

• You’re still latched - The whole time you’re holding your idea back, you’re not participating in the brainstorming session at full capacity.
• You’re breaking the core rule of brainstorming - All ideas need to be shared in the event that you might inspire better ideas from other team members.
• You’re wasting valuable time - What if your idea DOES inspire a better idea? What if your team could all agree that your idea actually IS the idea they want to persue and you could move on to brainstorming for other problems?

Option 2: Idea Latching as a Skill

The other option is to share this idea just as you would any other idea in a brainstorm. Then it’s up to you and your team to be conscious of the pitfalls of Idea Latching and to work with them.

• Test the boundaries of the idea - See if you can improve it, morph it, find flaws, etc
• Don’t go too deep - Acknowledge that the idea is good, but table it to come back to later.
• Embrace the idea - Maybe this is actually the best idea for your team! Try to think of reasons why you shouldn’t do this idea. If you can’t, move on to more detailed evaluation, then implementation. If it’s actually a good idea, use it!

It takes practice

Over the years, I’ve settled on Option 2. If you stay aware that an idea is good, and you can catch yourself latching, you can employ skills to make that beneficial instead of detrimental. This doesn’t happen overnight, though. You’ll need to practice and work your brain muscles to become good at working with Idea Latching instead of avoiding it.

Over time, recognizing Idea Latching and working with it, can be come a powerful skill that will make you a much more creative problem solver.

What are your thoughts? Do you have examples in which you or your team encountered Idea Latching?

[MikLast]

@Ty_Tremblay

Do you have examples in which you or your team encountered Idea Latching?

In 2019, 4513 thought the idea of 2018 passthrough robots such as 254 and 1678 would be perfect for this years game. So much so, climbing (despite being identified as important for RP, extremely beneficial for ranking high and getting district points) was put on the backburner to build a brand new elevator and some mechanism to pass both cargo and the hatch panel through the robot to score quicker than everyone else, despite never building an elevator that wide before or any passthrough mechanism. Come bag day, the elevator came out flawlessly after reaching out to learn how top teams set theirs up. The rest of the bot on the other hand…

By the end of event 1, it was basically stripped off and our bulky intake was roped down so we could play defense without fouls as the last pick of the #1 alliance, a far cry from how 2018 went for the team, despite getting another blue banner.

Qualification wise, it was the worst even ever for the team since the beginning of the district system. The team agreed that passthrough wasnt something we could realistically do, so it was tossed to [implement a system that instead mimicked 2910’s hatch panel mech which was much simpler and would actually let the drive team have drive practice.

Despite not having a climber (that kind of rebuild just wasnt in the cards), the rest of 4513’s season went much better, being able to consistently score every match and be a valuable partner in elims, getting to semifinals in all of their events after (and helping upset the #2 alliance of 1619/5199 in Turning)

[jtrv]

Day 5 (1/12)

Drivetrain

We spent some time optimizing our ratio choice. We have a couple of constraints:

• We need to be just below traction limit regardless of our weight
• We will be fairly lightweight in our first two district events (aiming for ~80 lbs)
• If we deem it necessary to play defense at DCMP to get picked, we will be adding weight ballast to go up to 125lbs

Therefore, the drivetrain should be just under traction limit at 125lbs (plus bumpers and battery), and we can adjust traction limitation via harsher current limiting when we are lighter weight.

We used the ILITE Drivetrain Simulator to get some specs for our choices. We don’t have too many preferences for COTS gearboxes, but we prefer single speed ones. Plugging in every single speed COTS gearbox into ILITE sim would be more than a headache, so I wrote some code to do it for us, which spits out a graph that looks like this: https://tervay.com/static/html/2022/neo0150.html (doesn’t work well on mobile)

Effectively, we want to maximize tractive force and minimize time to goal, so the top left area of the chart is the good place. We discussed 4 vs 6 motors and concluded that .05 seconds on a cycle has no difference to us, so we went with 4 motors. We also plan on being a fairly small robot, so the WCP flipped gearbox is a big plus for us - with that in mind, we went with the WCP SS Flipped 2 stage gearbox, at 11:60 → 20:28 reductions, for a total reduction of 7.64.

We’ll be running 5” wheels - specifically, Colsons from RobotMarketplace, coupled with the VEX Colson live hubs. The chassis will look essentially identical to the one we built in the offseason, just with 5” wheels, a new gearbox, and 6wd instead of 8wd.

As I mentioned earlier, we’re trying to go as small as we can - the hangar is tight. That said, we are prioritizing functionality over size, as size alone won’t do you any good if your mechanisms are jeopardized due to size constraints. We initially wanted to go really small - 18” wide and 26” long, but we’ve agreed to increase the width by a few inches - the exact number we haven’t really nailed down yet, but will be determined by how the rest of the mechanisms begin to develop.

Here is a screenshot of our CAD from a few days ago when we were 18”x26”. Need to spend some more time on the belly pan, but it’s a fairly simple WCD, extremely similar to the offseason one posted earlier in the thread.

Cargo manipulation

We’ve been looking at a lot of footage of prior robots, since a 9.5” ball is not exactly a never-before-seen challenge. Some notables include the 2019 Everybot’s ball elevator, 6329’s 2021 hopper & shooter, 2910’s 2021 hopper, 3847’s 2022 intake testing, and 319’s 2021 intake.

This is our basic path for the ball - an intake (not drawn) brings it into the back of the robot, where we have some small rollers rolling it up a polycarb S-shaped hopper/ball-elevator. There is a second roller - powered by a separate motor - at the top, which the first ball will stop at, as it won’t be powered until we need to feed into the flywheel.

The flywheel does not need to be very powerful, as it’s mostly just plopping it into the low goal across the robot. 1 NEO is likely sufficient.

Climber

You know - it’s hanging from a bar. We’re still firmly set on the mid rung. We are kind of waffling between building our own and buying a COTS one - right now we are leaning slightly towards buying the AndyMark Climber in a Box, but stock issues are something we are keeping in mind. We may be able to send some drawings of COTS climber components to our sheet metal sponsor and have them cut some parts for us, but there are still many tiny components to a telescoping climber, which make us a bit hesitant to try to source all of them ourselves. However it is, we bought a few MAX Planetaries that will likely power the climber(s), which we’re super excited to try out.

Software

We are trying to navigate a large increase in autonomous capabilities with having SPI broken on the 2022 image, but SysID being in 2022, and also half of GitHub being blocked on the school network. It’s been a slow couple of days. GitHub itself is unblocked, but the CDN (githubusercontent) is not, which blocks the WPILib installer and some other stuff. Thrilling.

We are tentatively aiming for a 4 ball auto. We are semi-confident we can hit 3 reliably - 4 will likely be hit or miss depending on how our intake feels like working in a given match.

(Thanks to Mik for posting some fantastic renders)

Our current plan is to line up against the fender of the hub as a guaranteed starting location. I’m not entirely sure the tape on the tarmac is going to be consistently angled at every event. I’m hoping to be proven wrong on that, though, to save a few seconds.

---

If anyone has any questions please feel free to reach out!

[jtrv]

Day 9 (1/16)

Drivetrain

Our drivetrain CAD is mostly complete now. Our frame perimeter is 24” long and 26” wide, although our usable belly pan space is 22” long and 18” wide. The vast majority of it is COTS, but we are having our sheet metal sponsor cut us our belly pan, which features a grid of #10-32 tappable holes (0.159” diameter) at a 1” spacing. This will help quite a bit with electronics mounting, both being able to mount components directly to the belly pan, and also providing ziptie locations if need be.

Our bumper system is a near direct copy of how 2168 and 2791 have done bumpers in the past, and is the same way that 6328 is doing theirs this year - the only difference is that we are using 3x1 tube stock between the wheels, rather than 2x1.

Hopper / Shooter

Our hopper CAD is obviously still in the very early stages, but we’re going with a full-width S curve “hopper.” This is very reminiscent of, and very much inspired by, team 2135’s 2021 robot. It’s also very similar to what 4481 has been testing recently. We don’t really have any use for the space on the side of a single-wide hopper, so we’re just going to make it full width and just not center the ball at all. It takes a lot of optimization effort out of either the intake or the hopper (or both), and since we are low goal, we really don’t need an absurd amount of accuracy.

We have the general shape down, but we are still learning more about shooter wheel choice. In all honesty, as a team undergoing a lot of change at the moment, we have not had much time to compare shooter wheels ourselves, so we are paying close attention to open alliances teams to learn more about wheel choice from them - thank you to 4481 and everyone else doing testing.

The hopper is going to go over the robot on the side opposite of the drive gearboxes; this takes up a good deal of volume on that side, which is why electronics are rather crammed together. Getting under it will likely be possible, just annoying, but these are some of the tradeoffs you have to accept when building small.

The climber will go somewhere. This is a “future us” problem. We are obviously hoping to cram it somewhere in the middle of the drive rails, but we honestly have not had the chance to plan that far ahead yet.

Electrical

Electrical quality has been a pain point for the team historically, so we’re spending a lot of time focusing on wiring quality in preparation for the upcoming season. One of these projects involves wiring the offseason drivetrain we had designed and built a few months ago.

While we wish we could go for 1538 or 254 wiring quality, this is still a massive step up for us and something we are quite proud of. We can definitely improve with some more zip tie square friends and some shorter ethernet cables (or more dedicated zip tie cutouts on the belly pan lightening), but this works and is something we’re very excited about.

Carpet!

We managed to track down a free, used carpet in the area that is about ¼ of a normal field size. This will be a huge resource for us, especially now that we are aiming for higher autonomous capabilities. The fit inside the shop is a little tight but we’ll make it work. We’d like to extend a huge thank you to team 6731.

Rough Gantt Chart

Our team captains put together this Gantt chart outlining our expectations for build season.

2022 Build Season Schedule

It includes some handwaving; our 2nd robot is likely just to be the offseason drivetrain I’ve mentioned a few times here. We’ll likely stick iterations of our other mechanisms on it in order to test them without compromising the quality and state of our primary competition robot.

---

Please feel free to reach out if you have any questions. Thank you for following along

[Ty_Tremblay]

Here’s our cad document in Onshape. Things are taking shape!

https://cad.onshape.com/documents/03f8a0da7179b63f708c664f/w/82aa1887423a1d97da774162/e/7f81ae34c2b2b5582f4c7f7b

[jtrv]

Day 12 (1/19)

Intake

Four-bar? Four-bar.

We need an intake that can cram tightly into the frame, as our hopper is really close to our frame perimeter for ease of pass-off over the bumper, and our hopper is also full-width. The intake needs to be low profile, compact, and work over the bumper. A four-bar deployment fits perfectly here, plus they’re super cool, so let’s do it.

Hopper / Shooter / Snek

Our hopper is a bit more flushed out. Currently planning on having a NEO 550 on each feeder roller here, mounted in roughly the locations that you see them floating about in space. Likely some form of planetary gearbox into another belt reduction. Something like that. We’ll be using a lot of these L brackets to fasten the polycarb backing to the sheet metal side panels.

The upper bearings (without the shaft) are for the flywheel. We’re mildly concerned about hex shaft rigidity. We can put a versaroller over the shaft which will make it much more rigid, however that limits our wheel choice pretty heavily, especially if we are being budget conscious. The VEX flex wheels are likely our best option here, but we’re yet to commit to anything. That’s what we are currently wrangling inside our heads.

Code

We’ve started the code! You can see it here: https://github.com/iraiders/Robot2022

The code for the 2020 robot had a lot of dangling object issues, and semi-random null pointer errors, so we are starting very fresh for the new season and referencing 5254’s 2020 code quite heavily.

We currently mostly just have the barebones drivetrain stuff done, a lot of which is also just a near-copy of the WPILib trajectory tutorial.

We’re working mostly through branches this year, in order to prevent people from stepping on each others’ changes, as we’ve got a pretty healthy group of programmers and I think this is maybe the best way of approaching it. We’ve still got room to learn though, so I would be curious about how other teams have approached managing robot code when you’ve got some 5+ students programming!

Offseason drivetrain

We spent some time wiring up the offseason chassis with the new REV components we got (ordered 2 sets). This helped get the electrical students familiar with it before we do the real robot. It drives using the 2022 code!

We’ll have another post this Sunday outlining some more details on the climber. We’re still learning a lot here by dissecting CAD of COTS climbers like the AM Climber, and we haven’t super committed to a direction yet.

[KrazyCarl92]

@jtrv

Our frame perimeter is 24” long and 26” wide,

I can very easily understand how being narrow is a likely advantage, especially when considering maneuverability and wiggle room in the hangar.

What advantages does the team expect to gain from having a shorter fore-aft dimension?

[Ty_Tremblay]

Having a wide aspect ratio (while still being pretty small) let’s us eliminate the drop center on our wheels, making our little bot a little more stable on the field.

But mostly, we didn’t need the length so we didn’t add it.

[Ty_Tremblay]

Our climber turned out pretty elegant this year. Building off 319’s experience with 3D printed bushings for their climber in 2020, we decided to make a single stage telescope with printed bushings.

The top will be printed PLA, but but bushing on the bottom of the extending tube is where the clever stuff is.

We’re going to print this as one piece, and it has the profile of the timing belt printed right into it. We’ll then use a long strip of 5mm HTD belt (15mm wide). We’ll put the belt around the pulleys, put the two ends into the block, slide the block onto the 1x1 tube, and then bolt it in place. There’s no where for the belt ends to go, so now have a timing belt climber.

We’ll power this with a NEO through a 30:1 ish reduction.

[LaythJ1519]

Love this innovation, Ty. The 3D printed pulley teeth pattern in the bottom bearing gives me sketch vibes. I’m hyped to see it in action, though. Looking forward to seeing you guys at some Comps

[Ty_Tremblay]

It’ll be printed in onyx. Does that help?

[kswaid]

Ty, this is basically what we did in 2020 on team 1740 and were very happy with the performance. Instead of belt it was chain drive with the chain attached to the inner tube via some #8 through bolts, but otherwise was a continuous loop drive with 3D printed bushing top/bottom made out of HIPS. The advantage we found over the average spring extending design was that deploying the climber to full height was much faster and more reliable after taking a good beating.

[tchen]

1/22/19

Intake

Not much has changed with our mechanism. We refined our model by cleaning up the dimensions and adding rollers in the assembly. Along with that, we worked on adding motors and motor mounts to our model. The rollers on the upper half of the intake are powered by a Neo 550 with a series of pulleys allowing the two rollers to spin simultaneously. The four-bar is driven by two Neo 550s paired with a REV Max planetary gearbox with a 125:1 gear reduction and another chain reduction, the exact number we are still working on figuring out.

Snek(Shooter)

We’ve made significant progress on our shooter within the last few days. First noticeable change are the side panels on the shooter. We’ve extended the sides to fit the chassis frame properly and removed any unneeded material to lighten our shooter. To strengthen the structure and improve rigidity we added two aluminum tubes going across the shooter.

Since our shooter has been flushed out, we focused on getting motors mounted for the rollers and flywheels. Powering the two rollers are two Neo 550 motors with a 4:1 ratio. The row of flywheels are run by two Neo motors with a 1:1 ratio. For the flywheels on the shooter we decided on 4in Vex flex wheels, which fit around a VersaRoller shaft, which is there to keep the system rigid.

[jtrv]

Software

We started the code last week and have more-or-less split up programming by giving a handful of kids each individual control over the mechanisms, each currently on a different branch until we are able to test them on real hardware… We’re sticking pretty close to barebones basics here. Going with all Spark MAXs will give the students a more consistent environment for learning basic controls and APIs.

On Saturday, we rolled out our new-to-us carpet for the first time and ran characterization on our offseason drivetrain and started working on autos, which we got working!

Example video: https://photos.app.goo.gl/6H22h8tq5Lu4p1aJ9

(Watch out Citrus, we’re right behind you guys…)

We’ve only actually done some S curves and L curves thus far, but we’re still super happy with moving in auto this early in the season. Most of Saturday was experimenting with PathPlanner, and just learning how to make paths, chain together paths, how the reversal flag works, field coordinates, which heading angle is which direction, etc. The path followed in the video is a little shaky but we think it’s because of a few reasons:

1. We accidentally characterized with only 1 motor per side (whoops)
2. The robot is super light and probably has some noisy acceleration data because of that
3. Our gyro mount is a very temporary measure… it’s haphazardly taped onto the Rio, which is haphazardly taped onto the belly pan… Likely plenty of noise coming from it.

But it’s good enough for now. The most important thing is that the core of the code works - we still have plenty of time to optimize the last few hiccups. You can view the majority of the code for auto here:

• DriveSubsystem
• RobotContainer