555 Montclair Robotics - 2023 Build Thread


We’re excited to join the Open Alliance this year and this is our build thread!

Some quick info about our team:
We’re from Montclair High School, we compete in FIRST Mid Atlantic, and we have around 60 members.
We plan to share our Onshape, Github (we program in java), and updates/photos of our robot throughout the season along with our insights into problems we face.

We’ll be competing at Mount Olive (Week 2) and Warren Hills (Week 4)

We’ll post roughly twice a week and will make a post soon about our offseason.

Here are links to our stuff for the season:
Website: montclairrobotics.org
Instagram/Facebook/Tiktok: @montclairrobotics
Onshape: Onshape
Github: GitHub - MontclairRobotics/ChargedUp: 2023 Game!


There’s a mistake in the original post, here’s our onshape: Onshape

Anyways, had a bunch of brainstorming at kickoff, will post a document soon with our strategy and everything.

1 Like

Hi again,

Our Swerve Offseason Project

The 2022 offseason we made a mk4i swerve drivetrain to prepare for the 2023 season. This drivetrain served to give us the opportunity to use swerve in 2023 (we plan to, a post about kickoff coming soon!) and served as generally good training. In the fall we were able to fully setup and make our drive train. Additionally, we trained a group of swerve drivers using this drivebase and our 2022 robot to practice offensive/defensive strategy.

What went badly:

  • we didn’t grease the gearboxes enough so they screamed (no physical damage)
  • Also we have issues identifying the “front” (still not resolved, just brute force fixed so that teleop would work)

What went well:

  • We got a working swerve drive!
  • We now have a group of trained swerve drivers
  • We had a lot of fun racing it up the hallway (see video)



Kickoff Post!
(and Week 1 because we were a little busy and forgot to post earlier)

At our kickoff we first reviewed the game manual, then organized into groups to come up with needs, wants, and wishes for our robot. These focused on the what do we want our robot to be able to do over the how do we do it. The groups then reconvened to combine their ideas into one full needs, wants, wish list.

After kickoff, we use a design group made of all of our CAD division and representatives from our other three divisions (build, electronics, code). This group meets throughout the beginning of build season to come up with a design that accomplishes the goals of the list created at kickoff. The rest of our members begin prototyping ideas generated by the design group and begin creating our code base.

Here’s the document we used for all of our design thinking at kickoff and meetings the rest of the week: Overall Design - Google Docs

A summary of our main design ideas:



  • With our focus on being able to score and move quickly and in all locations easily we’ll use a swerve design given our experience this fall
  • We’re currently are thinking of a frame with dimensions 25"x30" in order to accommodate the mechanisms we’re designing (detailed later)
  • Here’s an image with the rough design of the frame and the sizing:
Intake (aka the schwooper)
  • We want to be able to get either game piece easily and quickly in our control so we want an intake that allows us to essentially drive over the game piece to pick it up
  • To do this we’re designing a deployable intake using wheels either angled vertically or horizontally (prototyping to figure this out)
  • The goal of the intake is to aim cones along the longitudinal axis of the robot for our grabber (see that section)
  • Here’s a rough drawing of it:

For our main scoring motion we’re currently divided between two ideas and are using prototyping to figure out which are more feasible. Our main goal however is to be able to score in all three locations with ease and with either game piece. This is an ambitious goal however given the limited design necessary for a climb this year, we think it’s within our grasp.

Elevator & Stinger
  • This design is essentially the cartesian coordinates system moving the game pieces (x then y)
  • We would use a cascade elevator and then an extension system that reaches out far to place the game piece
  • This is the weak point of the design because the system would have to go from around 10" compressed to about 5’ 3" extended
  • To do this, we’re thinking about a horizontal scissor mechanism made of some kind of plastic with steel support pieces in between layers (CAD below):
  • This design is essentially the polar coordinates system moving the game pieces (r then θ)
  • We would use a arm mounted around a pivot point pretty high on our robot
  • This arm would then extend (possibly using the telescoping using constant force springs method because of our experience last year with that)
  • The weak point of this design is the higher center of mass while driving and the higher loads experienced
  • Here’s a rough sketch:
    Extendo-Arm Drawing

Our final mechanism is our grabber/holder of the game pieces:

  • We wanted to prioritize being able to score both cones and cubes from any orientation so in conjunction with our intake design (see that section)
  • After the cones are oriented perpendicular to our intake our current grabber design will use two plates that clasp the game piece
  • the plates are designed to be free to spin so that a cone will always be oriented properly for scoring
  • The plates would be actuated using a pneumatic cylinder
  • We’re currently working on a prototype of this design with a focus on minimizing the weight because it has to extend on whichever cantilever we choose for our primary motion

These are our design notes so far, we’ll post our next update about prototypes, building field elements, and whatever else we’re up to next week!


Your Onshape docs do not seem to be sharable, I’d like to get a look if you can turn link sharing on.

Thanks for catch, we had it public with no link sharing. The link above should now work with link sharing (Onshape)


Good progress!

If I understand correctly, you plan to have the base of the cone always pointing towards the ground? Something you may want to consider is that the driver will essentially be playing the claw game when doing that, you may have better luck with the base of the cone facing towards the driver station for alignment.

Great stuff so far thanks for sharing!

Thanks for the comment!
While scoring we’d absolutely be playing claw game. We do plan to use some form of automatic vision scoring in order to help line everything up and avoid the claw game situation.
While intaking, we’re trying to use a v shaped deployable intake which hopefully would allow drivers to funnel the game pieces into our robot.

Week 2 Update!

To test our designs we’re trying to prototype our intake, grabber, and stinger mechanisms (see above for our design). This week we started working on them but hit a number of roadblocks in our prototypes. The good news is our CAD, code and field element building are all going really well.

What happened to our prototypes...


  • We’re trying to make a deployable intake that uses two sets of wheels to angle the game pieces into our robot’s frame and aligns them to be perpendicular to the edge of our frame.

  • We tried to make it out of plastic and belts which didn’t go well

  • We made it out of plastic and bearings and hex shafts without any form of measurements (this is where the problems began…) see photo below

  • Additionally, due to the lack of measurements, when we tried to belt the different wheels together we ran into a lot of problems trying to tension and quickly pivoted to metal with chains instead

  • We then began a metal version but still have to finish one piece before testing (here’s an artsy photo from when we were working on the holes):


  • We’re trying to make two plates that both move horizontally together to grasp the game piece.
  • Due to our lack of experience with this kind of motion (no one has done horizontal motion on our team) we wanted to prototype it.
  • We tried a prototype with lexan and bearings which ended up having so much play it was near useless except to show that the four bar design works.
  • We’re planning to 3d model and print a design to prototype the grabber using a tough filament (likely carbon fiber)
  • We like 3d printed carbon fiber here due to it’s strength : weight ratio since it’s going to be on the end of our extension


  • We’re trying to prototype our stinger using lexan plates with steel rods
  • This should tell us whether this design works and how much the plastic bends
  • We just didn’t quite finish this prototype, no major setbacks, we just didn’t finish
  • We’re currently CADing up both of our two main ideas (elevator and arm) and are making really good progress with these.
    Elevator & Stinger:
  • for this idea we’re currently working on a rack and pinion system to drive the stinger. We want to try to 3d print the rack/pinion using a tough filament (likely carbon fiber)
  • We like 3d printing here simply ease of manufacturing

  • We’re currently working on the extension part of this and how we’re going to telescope
  • The code is going pretty well and like CAD, is coding both options for the robot
  • all major subsystems have been made along with commands for each of them
  • Also we’re working on LEDs!
Field Elements

Our main takeaways this week:
Our prototyping methods suck. They use difficult materials (metal, lexan), aren’t fast, and often are difficult to make (see intake prototype V1). Additionally, we underutilize the fast prototyping aspects of CAD and instead use it for generating machining drawings for a final robot.
Going forward, we’re trying to use CAD and 3D printing to help work on the grabber and elevator design. Additionally, in future year’s we should focus more on generating a variety of CADs and using the faster, simpler manufacturing methods (3d printing or cnc if we can get one) to prototype.

That’s all for now, should have some new stuff early next week with how the prototypes are going.

1 Like

Week 3 Post!

We’re moving forward with everything and have begun machining! We have a decision on the Elevasting vs extendoarm (see above for context)!
We’re making an elevator and a stinger!

  • This means we’re making a vertical and then a horizontal motion to move our game pieces to score

In other news our Elevator CAD is mostly done, we’ve begun CADing the stinger, intake, and electronics board and we finished most of our prototypes!

Additionally, like many other teams, we’re struggling a bit with ordering materials right now but with some luck it will all work out.



  • We made a metal version of our intake prototype which utilized green andymark compliant wheels to grip the game pieces
  • The prototype worked well grabbing and maintaining control of the game pieces however if we inserted a cone with the base first it sometimes got caught between compliant wheels
  • To solve this problem we plan on using nylon "blockers’ that sit between the compliant wheels to prevent the base from getting lodged there.
  • For the final version we plan on using polycarbonate to make it lighter
  • Additionally, we learned that the 10" space in our drivetrain is not enough for a inflated cube.
  • We changed the drivetrain’s dimensions to 27"x30" to solve this
    Here are some photos:


  • We finished it!
  • It works pretty well!
  • The negatives:
  • It’s really heavy when fully extended and has a lot of stress on the mount points
  • It takes a good amount of force to open and close
    To solve these problems we plan to:
  • Use springs mounted from the top of our elevator to the end of the stinger to help support it’s weight
  • Use a lead screw to control the motion with a heavily torqued up motor

We haven’t finished the grabber prototype but we did get the strong carbon fiber filament for it

  • We’ve begun manufacturing!
  • Here’s a photo of someone on our build division working on a piece to stabilize our drivetrain:
  • Here’s our drivetrain as of Wednesday (we finished the stabilizer piece that goes across the opening but I didn’t take a photo
  • We planned our double decker electronics board (see CAD for design)
  • Since our electronics isn’t done yet for the drivetrain, our code division has been working on subsystem code. Also we began working on possible autonomous routines and started looking at pathplanner.

  • ALSO, We got rainbow LEDs!!! (and then promptly plugged them into 12V breaking them)

Main takeaways this week:
Prototype faster ofc but that was kinda last week.
Otherwise we’re doing pretty good but we need to continue to refine our designs of our intake and stinger especially.

Week 4 update!

Lots of good progress this week. We began machining, have almost a final cad, and are getting lots of good electronics and code done.


All of our prototypes finished last week except for the grabber


  • We’re continuing to 3D print iterations of our grabber design. we got the latest one pictured below working really well, we just need to scale it up and add plates on bearings in-between the two four bar linkages

  • To drive this mechanism we plan on either using a pneumatic cylinder attached to one of the four bars or a motor attached to one of the gears


It’s almost done!


  • The elevator is all done after being redone twice this week (shoutout CAD team!!)
  • It now uses maxtube, has the chain, pulleys for the rope, and mounts for the constant force springs
  • We plan to use a 3 stage cascade elevator with a chain driven first stage and constant force springs to help it move quickly


  • We took what we learned from the prototype we CADed the intake!
  • It uses the angle and compression we found we liked while testing the intake
  • Additionally, the bare hex shaft that runs between the two sides of the intake will have wheels on it, they’re just not CADed yet
  • Also it deploys using two pneumatic cylinders (see the photos below)

IKEA Shelf

  • This is our vertical electronics system
  • We have two boards stacked over our battery mount (yet to be CADed)
  • It’s mounted behind the elevator (it’s the weird post thing)

We machined all of the IKEA shelf parts and have them mounted to the drivetrain (but I forgot to take a photo so here’s just the parts)

We’re waiting for a REV shipment to have the maxtube to make the elevator

Also we’re planning to use andymark’s waterjet cutting service to make our intake plates

  • We made the electronics boards but they have yet to be attached to the robot (only have a photo of one)
  • Early next week we plan to attach the board and wire up the drivetrain

This week is setting things up for code!

  • We dealt with 2023 wpilib issues in our swerve code
  • We set up our auto system using path planner which uses a combination of 6 different positions to create many different options (eg: start at 1 go to A go to 2) see white board below
  • Also, we got a limelight 3!!! In less than three hours we got our limelight tracking both objects pretty well (something that took a week last year with our custom raspberry pie based setup)

Here it is wired up with our 2022 robot, Big Jim (more info on that robot here: Big Jim

Main takeaways this week:

Fast iteration is the key to success. We’ve been able to put more effort (and more ideas) into our grabber than anything else because we’re making a 3D printed prototype as opposed to metal or plastic
Additionally, communication is really, really important. We had some miscommunications this week about how to rig the elevator and how to machine some parts


Week 5 Update!

The big news of the week: Our rev order arrived!!! This means we have the maxtube needed for the elevator. In other news, the CAD is almost done, we have a complete drive base (minus some code problems), and we are beginning a lot of the manufacturing.


The elevator and intake are done!! The stinger is also nearing completion.

  • Most of the work on the stinger this week has been focused on how we will drive it. While not shown in the image below, we plan to use a lead screw running between the two bars of our carriage through the piece marked in blue. By utilizing xtube and v bearings this will allow the bottom mount of the scissor to move vertically while the top one remains stationary. This actuates the scissor in and out.


  • Since getting our REV order Thursday we have been churning out parts at record pace. We’re currently through 23 of 38 parts, see photo below (not all are maxtube)




  • Got the IDs all setup and the motors spinning in the drivetrain, just not properly. The offsets appear to be the source of the problem however more research is needed to pinpoint and solve the problem.
  • Thanks to everyone in the OA discord for helping resolve these problems with us, it’s great to be a part of this community!


  • Began working with a limelight 3 and coral.
  • Setup a pipeline for recognizing each game piece and a pipeline for vision tape using our electronics board from last year’s robot.

Main takeaways this week

  • Make effective use of time because it always is cut close.
  • Always have redundancy. We’re taking a pretty big gamble with the stinger design and have been looking for emergency backup plans for the just in case it all falls apart.

Finally the most obvious and possibly most important:

  • Order parts early. In two meetings we were able to machine more than the previous two weeks. Also we still haven’t gotten some parts necessary for the elevator and we’re going to be cutting it close (as always).

Also here’s photo of our part manufacturing tracking system in our basecamp (a project management software) project:

Finally, here’s a photo of the most amazing package our school has possibly ever recieved:


What made you decide on the scissors+ elevator concept?

1 Like

The general thinking behind the elevator/stinger over an arm is:

  • collapse into a smaller space (so lower COG)
  • less force on a single axle, it’s spread to bars instead of an axle
  • the drive system can be offset with constant force springs so it can get fast
  • additionally, the linear motion fit better with what we were thinking about for an intake

Here’s the document we used from kickoff forwards as a design document if you’re interested. it has pros, cons, and thoughts about every design we thought of:

Mid week 6 update
While this wasn’t part of the plan, i think it’s important to post this.

Really bad stuff has happened in the past 2 days.

  • Rev elevator bearing blocks have updated to restock in march (as opposed to end of januray) so we have to redesign our elevator. We are planning on thrifty ones but they don’t fit the grid maxtube we already machined, so that has to be redone.
  • somehow, we shorted our limelight 3. we were powering it over the power port and saw a spark between the two cables. It no longer receives power over that port or POE. We reached out to limelight for help and are weighing what to do next.
  • We’re currently 15 meetings away from competition and have a robot that drives right only sometimes and that’s it. (that’s the good news, we got it sometimes driving right)

If anyone has advice on how to fix the limelight or address any of our other problems any help is greatly appreciated. We’re a very student led team so unfortunately we often have these kind of problems that may seem obvious to most others in FIRST.

Wcp clamping bearing blocks may work for you. they have a very similar footprint to the rev blocks, and work with maxtube. Use an old limelight for vision if you can, if you can’t get a limelight by competition, a webcam hooked up to a coprocessor(think rasberry pi or nvidia jetson) works well for vision(photon vision is a godsend, more info can be found on frc discord). “drives right only sometimes” sounds like a wiring issue, check all power and can connections. Good luck with the bot

thank you for the advice!!
we looked a lot at the wcp stuff but decided on the thrifty ones because simply they’re cheaper and fit on our frame perimeter better (even though they do come with a bunch more issues).

We may try using photonvision for our system because we do have some raspberry pis i think and a coral accelerator.

With regards to the driving, we found what we think to be the problem. We forgot to push the working code from lunch and then tested a bunch of bad code during the meeting. :man_facepalming:


what about the wcp inline clamping blocks?(https://wcproducts.info/files/frc/drawings/Web-WCP-0897.PDF) they’re the same price as ttb blocks, work with maxtube, and are the same form factor as ttb blocks

1 Like

thank you so much!!! we completely missed this product in our review and will likely use them now