FRC 1418 2023 Build Thread

Welcome to 1418’s 2023 build thread this will cover from January 1st till our last competition whenever that may be. There will be updates once a week working on a Monday to Sunday schedule with updates on Sunday. ( If you are interested in following 1418 more closely, e.g. day to day, I would highly recommend the Open Alliance discord)

During preseason the team built a chassis to test our MK2 swerve modules. We have yet to drive them on the chassis but that is a priority before kickoff.
We are also refurbishing an older chassis so that both mechanics and programmers can get some hands on experience.

As far as new sponsors we got a grant from the Gene Haas Foundation as well as donations from the families of 1418.

Build Season
During build season this year our goal is to be more efficient than previous years, allowing our new members time to learn without dragging our feet too much and giving programmers ample time to test, troubleshoot, and create an autonomous routine.

1418 looks forward to a successful season and wishes everyone well in preparing for kickoff.


Kick-Off :
This kick-off 1418 was joined by a rookie team 9033 from Yorktown high school. 9033 stayed to both watch the kickoff live stream and helped us for part of our brainstorming phase. After the kick-off live stream ended we broke off into smaller groups with members from both teams in each group.

These groups were each tasked with reading a section of the game manual to generate an abridged version, the sections read were, Section 5 - Arena, Section 6 - Match Play, Section 7 - Game Rules: Robots & Humans, Sections 9 & 10 - Robot Construction and Inspection. After groups were done with their assigned sections they began brainstorming ideas for pick-up and delivery mechanisms.

We took a break for lunch around 3, 9033 left to continue their own brainstorming and collect their Kit of Parts. Over lunch the team discussed some key elements of the game such as point values between autonomous and teleoperated, various penalties, and restrictions to robot dimensions.

We returned to the classroom to make some final thoughts before we began to share our ideas. Groups shared their ideas and took questions from team members and mentors about pros & cons of each of their ideas. At the end of this we ended the meeting, we will meet again on Monday to begin prototyping, we hope to be done prototyping and starting our build by the end of Saturday.

a few of the sheets we used for brainstorming

Season Plans as of Jan 7 :
1418 is using swerve! On Monday we will vote on the ideas which we brainstormed and start prototyping. On Saturday we will hope to start our actual build with the goal of having the programmer having full access to the robot on February 9 which is our designated “hand off” date. We also spoke about working longer hours and decided that our official season goal even if we don’t go, is to qualify for worlds.

Build Season : Miscellaneous
Important to mention beginning on Monday will be our field element construction lead by one of our technical mentors and new members. Also beginning will be the work on our much awaited roadcase pit project, Pit^2.

Personal Thoughts:
I’m optimistic about a lot of things this season, especially the emphasis on working longer hours and planning out our meetings as well as using Open Alliance as a tool and to document our progress. Also super psyched about building a super pit because that will be something that gets passed down on the team likely forever. Very anxious to end 4 years of robotics on a high note.

1418 hopes everyone had a great kickoff, good luck during build season!

Are you all having any luck getting your mk2s to work on the 2023 library? We have mk2s and are having little luck getting them to run on the 2023 wpi lib.

We’ve been having some trouble also, but I figured it’s just because none of us have experience with swerve drive programming. I don’t think the module version should affect the programming too much though, as long as you’re using the same motor controllers. It may have a different top speed/you may need to use different PID values, but the general code should work the same.

We’ve been using the SwerveDriveKinematics class to calculate speeds/angles, are you doing the same?

1 Like

Hi all,
Welcome to a look into our first full week of build season.

Swerve Drive:
At the beginning of this week we were dead in the water with swerve drive, it wasn’t working at all and we couldn’t find the exact issue. However, we soon found (one of) the issue(s), we hadn’t realized that there was a functional difference between the encoders built into the SPARK MAX and an absolute encoder. We did have these encoders on all the modules, as we had purchased them and their wires with the modules and thought we didn’t need them. After correcting this error multiple issues still remained especially around the attempts to make all or even just two wheels do the same action. We attempted to determine the nature of the issue electrical, mechanical, or programming so we decided to test each encoder individually. A few things learned from this, three out of four encoders we had on the swerve modules had been burnt out presumably from faulty connections to the roboRIO, because of this error we made four completely new wires out of PWM cables to gain a more secure connection.

As far as programming is concerned it’s hard to say whether the issues we have been experiencing are anything to do with code at all. Currently the challenge for our programmers is an issue with the modules twitching which has been speculated to be a PiD issue.

Mechanically things haven’t been much smoother, we transferred the modules to a “new” test chassis that was used for swerve drive in 2017. The modules also experienced an issue where gears were catching on each other which was never completely fixed, as well as another issue that has been around since assembly of the module which was that the wheels have been loose forever and we just discovered that we had been using the wrong sized bearings.

Given the issues we’ve been having we are looking to purchase old modules from teams no longer using MK2 swerve as well as looking into MAX Swerve as a worst case scenario if we can’t get extra modules.

Brainstorming & Prototyping:
We began this week by reviewing the designs that were presented at kickoff, and many of our meetings have been talking about strategy and designing to implement the action we want to perform, especially what we want out of autonomous.

We had 2 main groups designing intakes this week, one group was working on a design for a gravity assisted intake based off of Ri3D Redux with one 6” piston and green compliant wheels that could pick up both cubes and cones (see below).

Another was working on a design which is 2 sheets of thin metal or another flexible material that are pushed together by a pair of pistons. This design can also pick up cubes and cones and offers an intake that doesn’t have to be as precisely lined up to pick up pieces as the other design. This is also the design that we have chosen to move forward with as our primary design (see below).

As for delivery there have been a few ideas we are sure that we need an arm, but the group responsible for brainstorming or delivery have come up with an idea to use both a telescoping arm and an elevator (see below), nothing on this has been decided yet though.

Construction (Field & Pit):
Construction officially started on Pit^2. Construction on field elements started to build order as follows: scoring nodes, substation, charging station (see below).

1 Like

it’s funny because I had to redo all my measurements, haha… :face_holding_back_tears:


Swerve Drive:
Swerve has been progressing in leaps and bounds this week. At the beginning of Monday we still couldn’t drive properly, by the end of the day our programmers not only got drift mode to work, but we could spin (we also secured the battery better at this point). Apparently some PID values needed to be inverted after which many of the issues with driving were solved (feel free to ask questions about this I’m sure our programmers can explain this better). Since our code issues were solved enough to drive “properly” we were able to nail down field-centric drive.

secure your batteries, please
The next step is to begin work on our autonomous routines which as of yet we have not had success with. This is news for a little later in this post but our bot can comfortably drive up onto the charging station (without bumpers).

For our primary intake design we are in the process of making a few quality of life changes. The biggest change is the ongoing change in material from 80-20 to MAX tube to save some extra weight, as well as making shorter but more accurate side plates for the same reason. Pneumatics were rewired along the arm for organization and to see what the pneumatic system may have to look like.

Our elevator system was completed (structurally) this week and is ready to mount once our chassis is prepped accordingly. Still on the to-do list for the elevator are brackets for a chain system to raise and lower the elevator.

Our telescoping climber in a box two-stage was repaired and had a new motor and pivot point attached to the back (see below). We have, however, decided not to move forward with this arm and instead opted to buy a new telescoping arm system. Once our new arm was complete we attached the original version of our intake to it to discuss the length that it needs to be cut to (see below).

We also have two completed 25” 80-20 chassis that will work with our MK2 modules however it seems that we are going to switch to MAX swerve so they may be for the team some time in the future.

Construction of our field elements has been going slow but, we have completed our partial (½) charging station.
Currently under construction and slated to be completed by Wednesday (hopefully) are the scoring nodes which are about 60% complete.

didn’t have any pictures of charge station or cube sections of scoring, soon though

Our order of new Spark MAXs & NEOs came in, Spark MAXs were terminated and we just left the NEOs in the boxes, and now everything is packed away neatly in a drawer (see below). In the same order we also received 4 new batteries and taught one of our younger members how to terminate them. The most fun new thing we got however, to the dismay of one of our mentors we got a battery powered Ryobi miter saw.

And now the big thing, we decided to go ahead and purchase MAX swerve, likely this will become our competition drive system as right now there seems to not be much faith in and want to continue with the MK2 modules. The gist of it is we spent $1800+ on a single REV order, should be in on Tuesday, more news to come as that order comes in.

1 Like

Bot on Onshape, will try and keep this updated through the season but I’m not very CAD adept so you’ll have to bear with me. Not much here yet but i’ll repost the link or send screenshots as new things get added

p.s. Don’t worry about the file name

The chassis that we had been using was from 2017 and while it had a good run during testing it was no longer square and failed to keep the roboRIO level (or supported at all really). At this opportunity when we were switching the chassis over we also redid the electrical board and is now a rat’s nest again, however, the roboRIO is now centered and level (within 2°). With all said and done I only plugged in one CAN connection and two absolute encoders backwards, these issues were realized by our electrical lead and were quick fixes. After the bot was running properly again, autonomous testing resumed and with it more PID fine tuning and encoder “fun”. On Tuesday we got our order of five MAX swerve modules, the day of, we managed to get three assembled, and the subsequent two days we had members assembling the remaining two modules as well as testing all of them to ensure proper working order.

Towards the beginning of the week there was a team discussion on the topic of the elevator and whether or not we actually needed it for the arm to function as needed, specifically to pick up off the ground and to reach the highest level of scoring. We have decided to continue to move forward with the elevator.The elevator has since been sized down twice from initially being 25” across to now being 23” across in order to fit it all within our frame perimeter, we’ve also designed a super structure that will lift the elevator 5.25” in order to fit our intake attached to the arm inside the chassis. The pivot has been attached to the new telescoping and we decided on a length to cut the arm to. The arm is able to both telescope and pivot with the intake attached to it. We have gotten to a point where we are worried about the robot tipping if the arm is fully extended with a game piece so to counteract this we are making our superstructure to ideally add about 20 to 30 pounds.

We have finished building our last field element, we now have the double charging station, scoring nodes, and a charging station.

On Monday we officially started our CAD model of the robot which has helped immensely with measurements and catching problems before everything gets riveted together. Brief overview of the model, all systems at this point are mounted and move more or less like they are supposed to. Since this is my first “real” cad project and I’m doing this solo I have opted to not add some of the more complex mechanisms like the chain that drives the elevator and the additional mount that comes with it. Electrical systems will be added but only once the mechanical side is 100% finalized. Link here (Onshape)

It’s decided that we are doing reversible bumpers this season, not really a huge announcement but definitely will save us time switching bumpers which has been a problem in the past. We are waiting on 90 degree gussets which we need to attach the supports to the MAX tube chassis not sure of the ETA on those though.


So, um, robot!

It seems we have neglected this build thread, and all of a sudden the competition is over for us. Yes! Unfortunately, somewhere in that story, we are not going to worlds.

We have been doing a lot of documentation on the Open Alliance discord (great place), so I wouldn’t say we’ve been completely negligent. However, we can’t forget about everyone who isn’t there, so without further ado, here is a summary of everything that has happened since January.

Drive train & Frame

Starting from the bottom, we’re using a Max Swerve drive train, 25 by 25 inches. Per our programmers’ request, the swerve drivetrain had to be square. Since this is basically our first time with swerve drive, our programmers wanted to keep it as simple as possible. None of that rectangular swerve stuff.

Adding frame perimeter rules, the biggest we could make it was 30x30, but we decided to go a bit smaller. The idea was that a smaller robot could fit on the charge station more easily, and that did seem to be true once we arrived at the competition. However, once we put the robot together, the small wheelbase was likely a big reason why we had trouble with falling over so much.

Screen Shot 2023-04-12 at 2.13.23 PMScreen Shot 2023-04-12 at 2.14.07 PM

We tried to fix this by adding weight in the form of steel bars to the front of the robot, but we mostly just had to get used to driving more carefully, and the problem really never fully went away.

Looking at the wheels, we originally used the rubber/plastic ones suggested and provided by REV. That seemed to be a bad idea.

These wheels wore down quickly, and the tread tended to just fall off after a while. While we brought a plethora of extra wheels, the time needed to replace them was annoying. Even after reinforcing the wheels with some rivets, they tended to fall apart pretty quickly.

Instead, these treaded aluminum wheels from the thrifty bot were much nicer. They are so close to being too big to fit, and they did wear down, but they lasted an entire competition without delaminating! In the future, I would definitely recommend using these wheels.


Moving up, bumpers! Or really, I should say bumper. This year we tried 2 things that our team had never done before, one-piece bumpers and reversible bumpers. Putting both of those together, we only need one bumper assembly to display both red and blue!

This was super convenient. After weighing the robot without the bumper during inspection, we could bolt the bumper on and forget about it. With the reversible bumper, switching alliances are a quick flip away, and the one-piece bumper was super strong and never fell off.

The only problem with the bumpers this year is they tended to get ripped and needed to be repaired. I assume this was always a problem, I just find it weird that I never noticed it before. Maybe it was the way I made it, maybe I noticed more because I was the one repairing the bumpers, or maybe we just ran into peculiarly sharp field elements more often this year. One thing is for sure: I got noticeably better at sewing this year.


Didn’t do anything crazy with custom electronics or something, but we’ve got some neat organization.

We put most stuff onto a piece of Lexan attached to the frame. All of our Spark Maxes were attached to rails above that, which let us access the power, CAN, and encoder lines more easily. Shout out to Team 5406 Celt-X, who designed the 3D-printed mounts we copied and adapted for securing the Spark Maxes and various Wago terminals to Din rail: Celt-X FRC Din Rail Mount Collection by CeltXRobotics - Thingiverse.

Most interesting, we used a sort of branching CAN setup (not exactly like the image below, but close). All of the Spark Maxes were on separate branches, with the idea being if any of those CAN lines went bad, the rest of the system would be okay. However, the CAN branches have a maximum effective length, so the Falcon at the top of our robot had to be on the main line between the RoboRIO and PDH.


The first part of our intake system is this elevator. It moves up and down, powered by one motor and some chains. For the motor, I think we started with a NEO, but that didn’t have enough power, so we tried a Falcon, and that must have also not worked because we got a 100:1 gearbox for it. We stuck with the Falcon until one of the two we were using broke (more on that in the Competitions section). Since we only had two Falcons, we had to switch back to a NEO, which with the bigger gearbox seemed fine.

The elevator is primarily mounted to the frame via two bolts going up into tapped 80-20 extrusion, with additional cross bars to keep it vertically level. The elevator is kinda up on a platform to give it some extra height.

The initial reason for the elevator was to help us reach different places better. However, when that Falcon broke, we had to play for a bit with the elevator locked in place. We discovered that was fine. However, at that point, it was too late to make big changes, so we just fixed it and continued the same. We did use the elevator to help us start autonomous, but after that, we would just keep the elevator at its lowest position to help not fall over so much.


Moving up, the arm. It is a combination of the Andymark Climber-in-a-Box we used last year for climbing, a new ThriftyBot Telescoping Tube Kit we bought, and an old Swerve and Steer module thrown in as a pivot mount. There is a NEO with an 80:1 gearbox driving the pivoting and a Falcon with a 16:1 gearbox controlling the telescoping.

The arm is mounted onto the top MAXTube of the elevator with just an intermediate plate and a few bolts. At one point there was concern that the MAXTube wouldn’t hold up to all the weight and stress, but it performed very well. On the bottom tube of the elevator, there is also a ‘cradle’ assembly to stop the arm from falling into the electronics while the robot is powered off.

There was some trouble adapting these climber systems usually meant for vertical movement to a horizontal system. When the tubes are pulled sideways to the direction they’re moving, there is a lot of friction, which the constant force springs couldn’t overcome, so the arm doesn’t move out. A couple of modifications to the usual system though, and we made it work. There was also a lot of silliness with adding the pivot to the arm, but it worked out in the end.

There were another two problems faced with the arm. First, when falling over, the telescoping Falcon is the first thing to hit the ground. After a couple of falls, it seemed fine, but eventually, it broke. Since we only had two Falcons, we couldn’t easily replace it and had to steal the motor from the elevator. The broken motor also seemed to cause the CAN bus to freak out, causing us to miss a match while we were very confused. Second, the rope that pulled the arm in snapped once. It was the same rope that we used last year for climbing, so it was just surprising that it lasted so long. Luckily it did not snap at a competition, it just took a while to put the new rope in.


Last, but certainly not least: the claw. We ended with a pneumatics-based design, with two 5-inch pistons. Each piston is connected to its own solenoid; there is not one solenoid with both pistons attached via a junction. We did this so that each side would move at the same time, instead of the side with less resistance moving first. The claw is made of two hinged thin sheets of metal covered with cut-up compliant wheels. The flexible metal and rubber formed around cones and cubes, allowing us to pick them up with a strong grip.

The claw is simply bolted to the end of the arm. There is a large cable drag train to keep the pneumatic tubes contained as the arm changes length.

The only problem we had with the claw was that it occasionally got bent a bit too much, which made it harder to pick up game pieces. However, after the matches, we were always able to bend it back into shape, with only a little bit of leftover bend.


Not having programmed the robot, I can’t really say how the programming happened, but I can point out what it ended up doing. I think our code is somewhere in this GitHub repository, or maybe one of the forks, or maybe a branch. Anyway, here are some things the code did:

The driving was controlled by two joysticks, one for strafing and the other for rotating. Swerve drive, being holonomic, can move in any direction and rotate in any direction at the same time, and the two joysticks work well for choosing those two directions. The buttons on the joysticks control automated movements that align the robot at the double substation and grid for easy pickup and delivery. Another button enables our autonomous balancing system, which moves the robot in whatever direction it needs to level out the charging station.

The intake system was controlled by another controller. There are buttons for all the controls: moving the elevator up and down; moving the pivot up and down; moving the arm in and out; and opening and closing the claw.

We used a limelight 2.0 to see and align to the April Tags. Unfortunately, the image was a bit jumpy, so we had trouble making precise repeatable movements and occasionally had to fall back to manual control. We considered switching to the Photon Vision software but didn’t put enough effort in to make that work.

We used Path Planner to plan our autonomous paths. Unfortunately, we had a strange and persistent issue where the robot would not exactly follow the given path. It followed roughly the same path every time, but definitely not the path we told it to follow. Since the end result was consistent though, we didn’t bother fixing the root issue and just pushed through the process with trial and error, eventually stumbling upon paths that mysteriously sent the robot to the right spot.

In the end, we created decent autonomous for each of the starting positions. Every autonomous would start by delivering a cone to the high position, which was very consistent.

On the human-player side, we would exit the community and attempt to pick up a staged cube, then return and place it in the high position. We managed to get this autonomous pretty consistent on our practice field, but at competitions, it only succeeded about one-quarter of the time.

On the other side, the cable protector powering the charge station got in the way, preventing us from doing anything consistently after going over the bump. As a result, we only attempted to leave the community on that side. A better vision system that could see game pieces on the ground might have allowed us to correct for errors from going over the bump, but we didn’t attempt that.

In the middle, after delivering the high cone, we would dock and engage with the charging station. This was luckily very consistent and ended up being our preferred starting position. Unfortunately, with our tipsy robot, we didn’t attempt to leave the community over the charge station and missed out on those 3 mobility points.


While we have a separate thread for our PIT, it also wasn’t updated, so I’m including it here!

Overall, I really like how the PIT PIT turned out! The road case carried everything nicely and allowed us to have consistent organization at every event. We could also move it out of our main classroom over to our practice field, making it easier to work wherever the robot was.

Just one problem: the pit didn’t quite fit in our van. While measuring the van for size constraints, we missed two latches in the middle of the doorway that hold the back doors shut. Luckily, we could just barely squeeze the pit in once we removed the top lid. When we arrived we would just rivet the lid back on, and before we left we would have to drill out those rivets. One of our off-season projects will be fixing this, probably by taking an inch or so off of the PIT.


Okay, finally! How did we do?

Week 3 - Alexandria

Our first competition was the week 3 Alexandria event at Hayfield high school. It did not start well.

We lost the first 5 straight matches, mostly due to falling down early in the match, and so not contributing much past auto points.

After figuring out how to drive without tipping (keep the elevator down, basically meaning we aren’t using it), we did a bit better. Our middle autonomous’s balancing helped us get the activation bonus ranking point, but the overall alliance performance wasn’t yet quite enough to get the sustainability bonus.

We ended qualifications 5-7-0, ranked 30/40. Luckily, other teams recognized that we had gotten past the tipping problem, and we ended up being the second pick for the 5th seed alliance, alongside 620 Warbots as captain and 4541 CAVineers as the first pick. In the playoffs, our alliance won 1 match in the upper bracket and 1 match in the lower bracket before being eliminated. So, despite our poor performance in the qualifiers, we ended very well!

Week 4 - Timonium

Our second competition was the week 4 Timonium event at Dulaney High School.

Qualifications went much better at this one. This was the competition where our telescoping Falcon for the arm broke during match 7. We missed match 16 because a very weird CAN bus error knocked out our drive train, perhaps due to the broken Falcon. We had to improvise for a few matches without telescoping before stealing the Falcon from the elevator and playing with the elevator fixed in place instead.

Overall, we ended qualifications 7-5-0, ranked 18/36. During alliance selection, we were the first pick for the 7th seeded alliance with 8726 CryptoHawks as captain and 1895 Lambda Corps. Unfortunately, we had a weird lingering issue with our swerve drive (I’m not really sure what fixed it) that messed up our autonomus and slowed us down. Our alliance ended up double eliminated in the first 2 rounds.

Week 6 - Chesapeake District Championship

Despite our challenges, we ended the district events ranked #46 in the Chesapeake district! That was good enough to go to District Championships at Eagle Bank Arena. We were looking forward to qualifying for this event because it is conveniently only about a 15-minute drive away. Maybe we got better, or maybe we were carried by other teams, but this event was awesome!

Qualifications went very well. There were no major problems, so it was just up to our performance. We consistently balanced in auto and endgame for the activation bonus. With the general quality of teams increasing, we were also able to get the sustainability bonus often. We certainly won more often, but even when we didn’t we still got one or two ranking points.

We ended qualifications 8-4-0 and ranked 13 out of 60 teams. We were very close to moving up to be alliance captains. If Alliance 7 just chose the 8th captain, I think we could have made the 8th alliance. Regardless, we were the second pick for the 6th-seeded alliance, with 1123 AIM Robotics as our captain and 1599 CircuiTree as the first pick. I’ll tell you though, those other alliances were crazy! We played well — about 130 points in each match — but the other alliances just played better, and we were swiftly doubled eliminated in the first 2 rounds.


Pretty important to note: we won the Gracious Professionalism Award at all 3 of our events! I personally question why they gave us the same award 3 times instead of recognizing other teams, but I have to say good job to the team for being so gracious-professional (or something), and big thanks to all the teams who mentioned us to the judges! We probably wouldn’t have qualified for districts without the extra points from these awards.

(I’m responsible for dropping the first one on the ground and breaking it. Whoops)

Very professional:

In the end, we ranked #23 out of the 139 teams in the Chesapeake district. That was super close to the 20 teams going to worlds, but unfortunately, we did not qualify.

Final words

So, that’s the recap! In hindsight, our design was quite tipsy, which definitely hurt our performance. We pulled it together though and managed to play among some of the best teams in the district. While this is like the most words I’ve ever written for a long time, there are definitely details I’ve left out, so if anyone would like to know more, definitely ask!

And to end, an excerpt from the OA Discord: