FRC 2713 iRaiders 2022 Build Thread

Day 9 (1/16)


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


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 :slight_smile:


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


Day 12 (1/19)


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.


We’ve started the code! You can see it here:

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.


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?

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.


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.


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 :slight_smile:

1 Like

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


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.




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.


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.



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:

(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:



It’s been a while since our last update!


We began manufacturing & assembly on the drivetrain. We sent out our belly pan to our sheet metal sponsor at 6pm on Jan 24th, and they let us know at noon the next day that it was ready for pickup. We honestly didn’t expect that quick of a turnaround time, so we were super super excited.

We got the majority of the frame riveted together. We shared this with a few of our friends, and we received a very kind offer from 125 to powdercoat what you see in this image (minus the bearing blocks) over the weekend. We sacrificed a day of build on Thursday in order to do this - we could have kept going with assembly, but we wanted to try out powdercoating for the first time. Unfortunately, a blizzard hit the northeast over the weekend, depositing about 18” of snow on the greater Boston area on Saturday, which led to 125 (and also 2713) not being able to meet. They graciously offered to do it any time we wanted, but we signed up for Week 0, so we feel that we really need to use our time carefully and decided to skip out on losing any additional time. We’d like to thank @Brandon_Holley for the offer though :slight_smile:

Over the last few days, we’ve honestly struggled a bit with the process of moving from CAD to manufacturing and assembly. On our drivetrain side rails, some of our clearance holes were not properly centered on the rail, which caused us to lose more time than we really should have lost. Some minor COVID-related growing pains that I’m sure we will get through.

Anyway, we got half the chain on there tonight and all the gearboxes on there.

Hopper / Snek

We had some concerns about the sturdiness of the hopper, so we added, well, a bunch of standoffs.

We also added several 10-32 holes on a 0.5” spacing to a small lip past the climber tubes, so that we can mount extra electronics to the plates. Our belly-pan space is a bit constrained:

We have a decent amount of space here, however we want to keep an option available to us to add ½” steel plates to where the Rio currently is, for ballast. Adding these plates - one above the belly pan and one below - could lower our center of gravity by about 2 entire inches. Our robot without them is roughly 80lbs including battery, so we have quite a lot of weight room to play with.

We sent off the aluminum plates to our sponsor. Hopefully we will get them soon!


As Ty mentioned above, we’re going with a pretty cool climber where a belt is held in tension between a 3d printed plug (with a belt profile subtracted from it) that is bolted into a tube. We did a couple of test prints of PLA to make sure our dimensions were sound:

The inner hole is spaced at 1.03125”, or 1” + 1/32”, which slides nicely onto a 1x1 tube. We’ll be printing the real ones out of Markforged Onyx, so it should hopefully survive everything we need it to.

And we have a nifty little method for tensioning our belt.

We will be competing at Week 0 in NH in a couple of weeks. It’s slightly terrifying that we compete in 2 weeks. But it’s also very exciting. We will do our best :slight_smile:


Temporary Intake Mount

While waiting for our sheet sponsor to finish manufacturing our intake mount, we decided to build a temporary one for now in order to continue productivity. We built it out of some spare aluminum that we have in our mechanical lab, as well as using one of the 4 preseason belly pans that our sheet sponsor gave us.

In order to create the mounting panel, there were a bunch of tools that had to be used to create these pieces. We don’t have a CNC machine that can cut metal in the shop, so we printed out a to-scale drawing of the side gusset plates and taped it to some aluminum sheets. We used our band-saw to cut the outside, and our milling machine to drill the holes. In order to manufacture and create the side and center 1” x 1” tubes, the mechanical team re-used old aluminum tubings that we had lying around. We made those tubings the right size with the band-saw that we have in the machine shop. Since the original plan was to rivet everything together, we drilled out some larger holes in the Versaframe corner-gussets, the Versaframe Corner Gusset, and both tubings to a #10 Screw size. This is so the rivets that we have will be able to go through each piece during assembly.


Auto dev, 2/7-2/12

We’ve had some headaches here. We wanted to use PathPlanner, as the UI is very nice and it doesn’t ask you to save every time you click anywhere on the screen, unlike PathWeaver. We had a series of odd bugs (that were our fault) that led us to want to limit the maximum speed of the drivetrain on a trajectory to 1 meter/second, for safety reasons. We set that limit (and an equivalently low acceleration limit) in code and in the PathPlanner GUI, however upon running the path, it was quickly going up to maximum speed of the drivetrain (much greater than 1m/s), and we got spooked. Additionally, not on Saturday, but at a previous meeting, the paths being run were being run as the default path created in PathPlanner, even though we had modified it and deployed and quadruple checked.

Due to these reasons, we made the call to ditch PathPlanner for now, and come back to it in the offseason when we are less time-constrained. We tried out PathWeaver for a single path, and noted that it also was not obeying the maximum speed we had set. However, it was much closer - we had a limit of 1m/s and we noted it going up to 1.2ish m/s. This is about the time we realized we had re-characterized the drivetrain in SysID and updated the feedforward gains in the code, but did not update the suggested kP value for the velocity PID loop, which makes us believe that the overshoot was simply due to an imperfect kP value, rather than PathWeaver not obeying maximum velocities, and isn’t really something to worry about.

We asked around to other teams and we looked more into their trajectory generation methods, and realized that 6328 is generating trajectories via manually listing out waypoints in code via Pose2ds, and has a lot of already-written code that we can copy pretty easily. So we did that.

And… It worked the first try. Literally the first try. We’d like to extend a huge thank you to @jonahb55 and @came20 for making the code open source and answering our questions.

We have our four ball auto path down, but now we just have to integrate the rest of the robot above it. We’ll see if we get a chance to test the entire auto before week 0, but I think we would probably cry if we hit a 4 ball auto at week 0. We’ll try for it, but no promises.




On Saturday, we mounted the fully assembled snek onto the robot, removing the temporary intake mount in the process. We also began assembling the climber uprights, however only finished most of one. The electrical subgroup began organizing cable runs throughout the robot and mounting electronics on the internal sides of the snek. We’re making heavy use out of some #10-32 threaded inserts from McMaster in order to mount some 3D printed parts. We have week zero in about a week, so we’re trying to get the whole robot functional by the end of the week, ideally with a couple days of buffer to test with.

Preparing for Week Zero…

Speaking of Week Zero, the people who weren’t heavily involved in finishing the Snek started to pack up tools that are used for the robot into some organized cases. For example, if the robot used a 7/16” nut and bolt, people on the team would jot it down on a spreadsheet that we need a 7/16” ratchet, wrench, and allen wrench. This practice benefited us in two ways, being prepared for week zero as well as an excuse to organize our bins of tools. Now we know what tools and replacement parts we need for Week Zero!

Drive Team

At the start of the day, we opened with our first drive practice of the season with our makeshift temporary intake. We learned pretty quickly that the floppiness of the intake was causing the chain powering the rollers to pop off the sprocket, and it wasn’t surviving more than 30 seconds or so at a time. Due to this, we had our driver just pretend it was working, and lightly tap each ball with the intake, then go over to the hub and lightly tap the fender. The most important thing we were practicing was basic cycling and building muscle memory with drive controls.


Intake Version 2

Today, we worked virtually on making changes to the Intake’s CAD so they can be ready to get cut on our school’s carving machine. Some changes that were made were…

  • Adding a stiffening rod to the front roller as well as an optional additional rod near the motor
  • Moving the chain to the outside of the intake arms
    • The reason for this was to add the stiffening rods into the inside of the arm as well as to protect the polycarbonate plates
  • Added bearing retention screws
    • These will thread into the polycarbonate plates and hold the bearings in place
  • Removed the tiny bushings and made the pivot holes ¼”
    • This will allow the team to use the locknuts to adjust how stiff each joint is



This is my first year on 2713 (It’s the first year on 2713 for a lot of us, actually), so we have a lot of opportunities for firsts this year. We’re running our own scouting app for the first time ever.

Previous Apps

In the past, we’ve used paper scouting, Google Forms, and FRC Krawler, but they all had their limitations.

  • Paper scouting is exhausting
  • Google Forms requires internet access
  • FRC Krawler only works on Android (this team has a lot of iPhone users)

So we started doing our research, discovered ScoutingPASS from 2451, and fell in love.

Scouting pass is:

  • Configurable
  • Device Agnostic
  • Only needs internet to load the page once (or host it locally!)
  • Transfers data to the central repository via QR CODE! So clever!

While playing with it, and found ourselves saying “I wish it could…” a few times. It’s a delightfully elegant system, so we didn’t think it’d be that hard to roll our own and see what we could come up with.


This year, we’ll be running QRScout, a ground up re-creation of ScoutingPASS with a few tweaks.

The form looks like what you see above, and the sections and fields are configured by JSON file. You can define as many sections as you like, and you can have several different types of fields:

  • Text
  • Select
  • Number
  • Counter
  • Checkbox

Here’s our configuration for the endgame section:

      "name": "Endgame",
      "fields": [
          "code": "c",
          "title": "Climb",
          "type": "select",
          "choices": {
            "1": "Low",
            "2": "Mid",
            "3": "High",
            "4": "Traversal",
            "f": "Attempted but Failed",
            "x": "Not Attempted"
          "defaultValue": "x",
          "required": false
          "code": "be",
          "title": "Started climb before EndGame",
          "type": "boolean",
          "defaultValue": false,
          "required": false
          "code": "cn",
          "title": "# of alliance bots climbed",
          "type": "counter",
          "defaultValue": 0,
          "required": false

As you can see, you can mark fields required, and the Commit button won’t be enabled until all of those fields are filled in. Once you’re ready to commit the data, you click the Commit button and you’ll see this:

The lead scout will come around with their QR Code Scanner , and scan each QR Code to gather the data. The data in the qr code is just the values of the fields separated by TAB so that they enter properly in Excel / Google Sheets.

Then the scouter hits the reset button, and gets ready to scout the next match.


Like I said above, the sections and fields for the app are entire configurable by JSON file, but we took it one step further. You can download the current config via the Download Config button, modify it, and re-upload it to the app to change the scouting form! We’re still working on saving the current form config to your browser’s local data so you don’t have to upload your custom config every time. You can add entire sections, like a bonus section for example:

Hosted by Vercel

We reached out to Vercel, and they generously offered to host our scouting app on their system for free! You can see it live at, and you can see the code at Give it a try by downloading the config file, editing it, and uploading a new one.

It’s certainly not bulletproof, yet. So if you find any interesting bugs, please send them our way.

This can be your scouting app too

All you need is a QR code scanner (any webcam + some software will work in a pinch), and your own config.json file. Load the page before the event starts (if you don’t have internet in the venue) and you’re good to go.

If you use the default config that comes with the site, we can share data! We’ll be publicly posting our scouting data as the season progresses.



Electrical woes

Gremlins have infested our robot and we’re in the process of evicting them. We’ve ran into a handful of issues this week that have been eating up a frustrating amount of time…

Grounding your frame - how to fry components


On Tuesday, we were working on both electrical components and assembly of the climber at the same time. We had a battery plugged in so that we could diagnose some connection issues we were having. We were also assembling the climber, which was right next to the main breaker:

You can see the nut to the left of the main breaker, which is what we were tightening with a wrench. We did not have the electrical tape over the main breaker at the time. We fastened a wrench around the nut and had it resting against the right side main breaker terminal, which is connected directly to the battery. We noticed an odd smell and a small amount of smoke began to appear. We quickly turned off the robot and used an insulated allen key to remove the wrench. Cue minor collective anxiety attack. Everyone’s okay, so, onto diagnosing the robot.

We examined for any obvious damage and didn’t see anything, so we turned the robot on. We noted three Spark MAXs did not turn on with the robot. Luckily, the PDH and rio and radio did, so it could be worse. This happened at the very end of the meeting, so we called it there and spent some time trying to find any common issues online. We got a tip to try to use recovery mode to save the Sparks, and we decided to also do a continuity test from the PDH ground to the frame. If there was a beep, our frame was grounded and we’d fail inspection.


On Wednesday, we put one multimeter terminal on the ground cable going into the PDH (on a tiny bit of exposed copper) to the frame. No beep. Not grounded? Which doesn’t make any sense, how could something short if the frame wasn’t grounded? Weird, right? (We’ll realize later that this test was botched. My bad.)

We booted recovery mode into the three non-functional sparks and were able to completely save one. The other two, however, were beyond saving. I’m sad to report they passed at roughly 8:25pm on Tuesday, 2/15/22. (One of them actually powers on with a USB input, but not when connected to the PDH, so we assume some 12v related thing fried inside the spark.)

We replaced them with new Sparks and continued on with other things, being very careful not to have a battery plugged in when doing mechanical work from then on. Wednesday continued without much issue.


We decided to run another continuity test, this time putting the multimeter’s terminal far into the PDH ground wago terminal, rather than on the tiny amount of exposed ground cable. We got a beep, so our frame was grounded. This makes a lot more sense. Oops.

Now, to find the source… The main breaker was no longer connected to the PDH, so it wasn’t a main breaker fault. We began unplugging one thing from the PDH at a time, then doing another continuity test from ground to the frame. We eventually found the problem - we unplugged one of the sparks powering a NEO 550 on our hopper, and the frame was no longer grounded.


(The two pulleys on the right are mounted to 2 NEO 550s.)

Next, we completely unplugged the Spark from the motor - all 3 phase cables and the encoder cable. We ran a continuity test from the Spark to the frame, and no beep. Okay, so it must be the motor, right? We then ran a continuity test from the black cable on the NEO 550 to the frame, and… beep. Blah.

It was at this time that we realized we may have used bolts that were too long to mount the NEO 550 to our hopper. We unscrewed the bolts a bit, and tested again… no beep. Yep. There it is. We replaced the bolts with much shorter ones and decided to run the hopper to see if the motors were also dead (we hadn’t had a chance to power them on since the original incident). We pretty quickly realized they sounded like garbage and also smelled pretty burnt, which we interpreted as them being fried in the original incident. We’ll be replacing them tonight before week 0 tomorrow morning.

We believe that the bolts we used were too long and were touching some important component inside the motor - coils, encoder board, something. This caused a short / grounded the bolt that was touching the frame, which grounded the frame. When we accidentally rested a wrench from the battery terminal of the main breaker to the nut on the frame… we sent 12v straight into the motor coils and into the Sparks the wrong way. Oops.

Lesson learned: use manufacturer recommended bolt sizes. And pay close attention.

Comms issues

Now that the short is fixed… we can test code! Right? Right??

We’ve deployed code to the robot just fine before. However, the first time we deployed on Thursday seemed to just… Not want to work. We would deploy and the robot would lose comms after the build but before the deploy finished. The radio would maintain power the entire time, and we’d be connected to it the entire time, but for whatever reason we are losing comms between the Rio and the radio. We simply tethered into the robot for now, but this isn’t really sustainable for driver practice / auto development. We imaged a few radios after meeting hours and will be trying those tonight. Maybe re-imaging the Rio as well. I outlined some of our issues here: Rev Radio Power Module - No Data Connection to Radio - #5 by jtrv

If anyone has any ideas at all, please let me know, this is a frustrating issue that I don’t know the origin of.

Week Zero

Tomorrow we’ll be competing at week 0. A lot of our stuff won’t be automated. We probably won’t have the full scoring sequence automated, and our climber for sure won’t be automated. Expect some first-run pains in quals tomorrow.

We don’t really know what to expect, but we’re optimistic that week 0 will give us a great leapstart on the season, and we’re very grateful for the opportunity to compete at an unofficial event for practice. Thank you to everyone who’s given us feedback and offered their help, especially with these electrical issues. We’re very, very grateful.


With the belt printed bracket, how do you get the belt inside? Is it made as 2 parts than put together around the belt?

While printing put the belt inside while it prints?

Or do you cut and reattach the belt?

1 Like

The belt is cut before installation