FRC 555 Montclair Robotics - 2024 Build Thread

[Team_555]

Hi everyone! Welcome to the Build thread of FRC team 555, Montclair Robotics!

We are a group of students from Montclair High School. We compete in FMA with around 70 or so members, after losing a bunch seniors but gaining a large, incoming group of new members. This is our build thread for the coming season. I will do my best to post at least once or twice more in the preseason, and around once a week in the build season.

We are planning on sharing both our Onshape and Github, as well as photos and updates of our robot throughout the season. I will attach all of our files as soon as the season starts up.

Still not totally final, but right now we think we will be competing in Allentown and Warren Hills, weeks 2 and 4.

Last year, the post-season, we led a large effort to completely reorganize our entire space. We’ve made tools that we use often more accessible and easy to use, and created a more open, larger workspace. This will be invaluable to our team this season.

After a late start to the offseason, we finally began meeting in early October. We were very quickly inundated with new members, mostly freshman, more than doubling our team size. They’ve chosen their divisions, and we’ve been working to train and teach them everything we know.

After joining Hatsboro Havoc (an offseason comp this weekend), we’ve spent this past week frantically preparing for that.

Thanks for checking us out! We’re looking forward to a great season.

[Skeller]

Best of luck this year! We’ll see you at both events!
-4573

[Team_555]

Happy Kickoff!!!

Sorry, a bit late to the kickoff build thread party. We met from 9-5 yesterday to plan out our season and robot project as a complete team. Kickoff was exciting, as always, and we quickly began discussing the challenges of this years game and our course of action. A few of us met again today to get a head start on design (something we took too long with last year). These are some of the main concepts we figured out yesterday and today:

• Intake
  • we think that its going to be very advantageous to have a smooth working ground pickup of Notes. After realizing theres no breaks in the bumpers, we began thinking of either a deployable intake or a under-the-bumper way of picking up Notes.
    • Deployable - this was a huge disaster in our attempt last year, so we are very wary of this idea. This would also have to deploy over and then down around the bumper, some tricky motion there.
    • Under-the-bumper - Briefly discussed this at kickoff, but couldn’t come up with a great way of doing it. We had a separate design meeting today, and discussed a concept of a series of rollers right behind the frame that could quickly bring Note up and into a shooter. We will be pursuing this (more about this below).
• Shooter
  • We really liked the KitBot shooter that we saw in the videos, with its two roller wheels (one for accelerating, one already at speed). I think this is gonna be vital as a single wheel to shoot Note won’t have the acceleration needed to shoot it off at speed in the limited, quick contact it will have (prob less than one rotation).
  • we want an adjustable shooter angle, for speaker and amp, and originally thought yesterday that at a slow speed, the note would be able to simply tip out of the shooter into the amp. After more testing today, we realized it will need another mechanism/shield to deflect a note into the amp, vertically.

What we figured out today:

• Our design is as follows:
  • under-the-bumper rollers boost notes on the floor up and into our shooter. The shooter has belts to hold and then accelerate notes into the rollers in the front, which are already at speed to shoot the not. The shooter can pivot between an angle for the amp and an angle for the speaker via a rack and pinion. After realizing the difficulty going from shooter into amp, we thought of either:
    • a flip-out section of the shooter, pivoting from the tip of it, out, sending the note vertically into the amp. This would be complicated, and we like the second option better.
    • a top flap/shield to deflect a shot note down, vertical into amp. This would be fully up for speaker shooting, and down for the amp to curve notes into amp box.
  • we haven’t really talked much about hanging on chain, but we are thinking two independently controlled retractable arms, to balance on chain and work with whatever angle its at. The hooks would have some sort of 3d printed pieces that would align to each perpendicular link, locking them in place, hopefully stoping us from slipping into center low section of chain.

Two questions for the community:

• what sensors could we use to detect notes in our intake and shooter? We want to try and use more sensors this year, especially as notes will move around in the robot.
• AndyMark sells a string potentiometer that we are planning on using to accurately find the “third side” of the shooter triangle as it moves, so that we always know its angle. We have had issues in the past with encoders drifting, so didn’t want to fully trust the rack and pinion motor. Is there any sensor that could directly give us the angle in a less janky way? some sort of protractor sensor.

I’m trying to put together some photos of our designs, which I can hopefully share tomorrow. Github and Onshape will also be shared.

Any thoughts or feedback greatly appreciated!

[TNorris]

Thanks for sharing! Hope this helps with your questions:

1. Teams commonly use beam break sensors or distance sensors to detect game pieces in their robots. Here’s a thread with some suggestions and sources

@Team_555

AndyMark sells a string potentiometer that we are planning on using to accurately find the “third side” of the shooter triangle as it moves

2. That’s actually the exact case that the sensor you found was designed for. Team 2468 designed it in 2013 for the angle of a frisbee shooter. You could also use something like the Rev through bore encoder or another absolute encoder to sense the angle at the pivot point. If the ‘drifting’ you’re worried about is inconsistency every time you turn the robot on, then an absolute encoder will give you the same angle no matter the starting position, even if you turn the robot off and on.

[Team_555]

Week 1 & 2 Update

So sorry for not posting a week 1 update. I’ve been in the middle of trying to juggle robotics and a hundred other big school projects this past week. I’ll do my best to post every weekend without fail from here on.

We’ve been up to a lot these past weeks. We worked on a ton of design/CAD work and did a bunch of prototyping, mainly of different shooter designs. Don’t think I’ve talked about this before, but our team is split into 5 divisions (CAD, Build, Electronics, Code, and Business), each responsible for their allocated part of the robot. Unfortunately, Business and all that they do won’t be super front and center in this blog (build blog), but they are super valuable to the team. Here’s a rundown of the activities of each of our engineering divisions and then a deeper discussion of the robot:

CAD

• has been working a ton on designing basically the entire robot
• Started by CADing most of the structural elements and then began finer work like motor mounts, rollers, etc. Still needs to add chain climber capabilities, which will most likely be a pretty simple climb-in-a-box system.
• We’ve done a lot this year to make the CADing process more efficient, and it’s really paying off. Last year, CAD wasn’t fully done until week 2-3. Although there’s always smaller thing to fix/redesign, CAD has already reached a point (earlier in week 2) where many key elements can already be sent to Build for machining. LETS GO CAD!!!

BUILD

• Build has been doing a ton of prototyping work, especially on the shooter. We started with side roller design, but after taking inspiration from some other teams and testing a top/bottom roller design, we have decided to do that. It’s a lot more powerful (longer note contact) and seems to be more accurate.
• Built the Amp and tested ways to score from our shooter into it.
• Has begun machining and assembling a decent chunk of our robot parts.

ELECTRONICS

• completely built a testing electronics board to test our rebuilt swerve modules and to teach new members (most of that division) about wiring an entire robot.
• is planning out how the different components and wires will run on the robot.
• unfortunately realized that they did most of the CAN wiring on the board completely wrong (oops). They’ve been redoing it and learning about wiring the can bus

CODE

• has been working closely with new members on all of the robot subsystems (drivetrain, shooter, intake, etc) and has gotten a lot done.
• started some work on planning out auto paths.
• Also super ahead this year!!!
• did some testing of our refurbished swerve drivetrain.

Our robot:

This is our general robot CAD as of right now. Under-the-bumper intake (see below) brings note into shooter. From there, the rollers store note (i think people have been calling it the indexer?) while cycling, and then accelerate it into shooter wheels (top-and-bottom roller system)

Our Robot CAD (points of failure, things we want to share, and other interesting design stuff):

Shooter angle:

• our robot is designed so that its cycling/intake shooter angle is 45º. The intake is designed to pull note directly into shooter for that angle and the shooter is just short enough to fit under stage like that. From there, depending on our position for shooting into speaker, we would raise shooter to ~55º (against subwoofer) or lower to closer to ~30-35 (against podium).
• we control that angle through two Neos, 100:1 90º gearbox on both of them (there’s not enough space to mount motors horizontally without 90º). A 14T sprocket and chain meshes to a 64T plate sprocket fastened on the shooter. We’ve done the math, and, theoretically, the motors should be able to deal with over 600 lbf ft of torque on the shooter. I think the weakpoint is the 14T sprocket and the rest of the chain, but even that should be able to handle the forces and movement.
• Its super important in a system like this to have proper chain tension, so we have a clearance slot milled into the maxtube for the 14T driving sprocket shaft. Both motor and gearbox stacks can then be mounted on bearing blocks, able to be clamped on maxtube further back to tighten chain perfectly.
  
  
  
  (imagine there’s the other side of the bearing block clamped around maxtube)

Motors/gearboxes:

• quick rundown on all our non-drive motors: two 10:1 Neo 550s run the intake rollers, one of them also chained to preliminary front roller. Indexer has a single neo, no gearbox, and its three rollers are chained together. The shooter is again two seperate Neos, top and bottom, again 1:1. Does this make sense or do we need more torque for shooter and indexer?
• I’ve never actually used a Neo without a gearbox and am having trouble designing ways to mount it. Right now, i’ve designed a system of a 8mm keyed shaft to .5" hex adapter on the Neo shaft, with a hex coupler on top connecting to the roller shaft. The roller shaft is also bored out for a deeper fit on the motor shaft. The motor is then just screwed into the frame, the small lip on it locates into a .75" hole through just one side of the maxtube. Is this viable, and is this the way that this sort of mounting is or should be done?
  
  
  
  

Thoughts on note compression:

• After some prototyping and snooping here on CD, we’ve decided on .5" compression for shooter rollers. Our intake and indexer rollers we are leaving with .25" though. I’m slightly worried about increased friction of note directly down onto shooter LEXAN piece with any more compression than that.
  
  
  
  our intake - top rollers (large one and smaller preliminary contact one out of frame) both have .25" compression down. Other bottom roller is designed to compress another .25" into the line of the indexer floor piece at 45º, leaving roughly 1.625+" between the two in photo.

Amp scoring:

• we’ve tested a mock-up of our current shooter and it is able to just “pop” the note up and then back down into amp.
• This, however, isn’t really ideal, as some better sort of guide piece to push note down into amp will be a lot faster and reliable in game
• We’re planning on building our current shooter, and then building a flip-up, curved guide that pivots out to deflect a released note vertically into amp.

Finally, our robot CAD is available here and our GitHub here!

As always, open to any feedback on our design, CAD, code, or even my way of writing these (hope everything im writing about makes sense)

[nicbamb12]

So awesome to see your designs, they look really good imo! Our team has been going through our design process and funnily enough come across a lot of the same conclusions in our testing (e.g. compression, under the bumper intake, climb, etc.) Excited to see where you take it this year, and good luck from Jersey City!

P.S. Say hi to Andrew Press for me! (tell him its from his secret admirer )

[Team_555]

Thanks! Always great to hear about teams with similar ideas. Good luck! heres to a great season!

I’ll tell him you said hi

[Team_555]

Week 3 Update

We’ve been up to a lot this past week. Here’s a rundown per division:

CAD

• has been finishing up - the CAD is mostly done, just needs some final touches, drawings for Build, and a few strength/alternate mechanism redundancies.
• Ran into a few issues with our climber arms, but eventually got them figured out.

Build

• Build started off the week with some great prototyping work. We built a full-scale, exact dimension wooden prototype of our shooter for testing. It worked incredibly well:
  • the note, depending on our questionable hand in-feed, was pretty consistently able to fly over 20-25 feet at roughly 30º.
  • there was no side spin on the note, but it stayed remarkably flat, only beginning to tip forward in the air after 15 or so feet, which should be plenty.
  • amp scoring (just popping the note up and in) also works well, however we are still most likely going to add some sort of flip out chute to direct note downwards, as this is going to be a lot quicker.
  • this prototype exceeded all of our expectations. If we can transfer this success to the real thing, we’re going to have a great shooter this year.
• Has been working on a lot of machining as well, and has close to a majority of our parts done. We are a fully manual machining team (mostly using our two Bridgeport-style mills and 2 metal lathes as well as other assorted saws, sheet metal tools, etc), and have certainly had a fair bit of complex part making to do, but Build has been trucking along.
• We even started assembling! We’re still waiting on the chassis from code testing (see below if you dare), but we’ve begun assembling a few of the parts we have done.
  
  
  
  Main robot/shooter frame, will attach to chassis.

Electronics

• Has been troubleshooting our thrown-together electronics board for testing our swerve chassis (two pretty old sparkmaxes just weren’t cooperating) and other assorted issues.
• planned out positions of components in some pretty funky places on the robot.

Code

• has been finishing up their subsystems and started a few auto programs.
• Ran into some huge issues with our Swerve code
  • It originally just didn’t work - offsets were set right, motors and CANcoders gave the right values, but nothing worked. The wheels would both spin and pivot randomly, they would twitch and move with no input from controller, and a whole host of other issues.
  • we spent a few late nights completely re-working everything, this time using the YAGSL library, and…drumroll please… it actually works!
  • we still spent forever trying to figure out how to make it work. We first implemented it and tried to test just our steer motors to a setpoint, got incredibly frustrated because some anti-jitter function also doesn’t allow steer motors to move when its not driving, but eventually tracked down where the angle setpoint was changed in the YAGSL code and fixed it. (and yes, we realized that if we had just tried to drive from the beginning it would have worked, but we still wanted to tune angle PID independently).
  • we still have no idea what’s wrong with the original code with the SDS Swervelib library…

Thanks for reading! These next weeks are going to be good as we see the robot sprout up during assembling. As always, any feedback or comments greatly appreciated!

[Team_555]

Week 4 Update

This is somewhat a short post, but we’ve been doing a lot. Quick rundown per division last week:

CAD

• has been working on a few extra strength redundancies and other things:

  • 45º hypotenuse supports to strengthen our shooter pivot point

  • alternate amp scoring method - a hood/chute thing pivots out in front of shooter output, forcing a shot note downwards into amp.

  • created a new 3d-printed interior climber rail!! The one that we were planning on using was meant for 1.5" square 1/8" wall square tubing, but the stock we have is only 1/16" wall. So we decided to design our own and will be getting it industrially 3d-printed.
    

    
    
    
    I think we came up with some really clever design features, especially a few interior things to make 3d printing easier. Let me know if you want to hear more!

  • worked on a climber rope pulley system and is thinking about a secondary, “hand-off” hook to hold robot on chain once disabled at end of match.

Build

• Fully assembled the shooter!!! ran into some huge issues with chain-tensions and dimensions, but finally got it done. We will independently test it with full motor setup and then mount onto the main robot frame.
  

  

• Has been wrapping up machining the last few parts of our robot!!

Electronics

• Has been working super hard at assembling all of our assorted gearboxes for the robot. We got a bunch of super nice MAXPlanetary ones that are so much nicer than our old Versa ones, so that was nice for a change.
• has a full, finalized plan of each component on the robot.

Code

• has been tuning our Limelight vision system a bunch and it seems to be working incredibly well at recognizing notes.
• worked on apriltag detection system to align our shooter to right angle for different distances from speaker.
• made some LED animations!!! (most important aspect of our robot by far)
• has been finishing auto paths and systems.

[Team_555]

Our Robot is done! (mostly)

Hi! Sorry it’s been so long. This is our mostly completed robot, name still tbd. After fully finishing this little guy last week, we’ve been transitioning into code and auto testing time. We’re hoping to get a really good auto and apriltag scoring system down in the next two weeks before our first competition.

Although we’ve mostly stuck to our original CAD and design this year (unlike last year ), there are a few additions that we’ve had to add. Here are a few of the more interesting things and then a full rundown of everything:

• 
  
  Our original design included these clamping bearing-block assemblies as a means to perfectly tension the chain that drives our plate sprocket and shooter angle. We soon learned that we couldn’t adequately tighten the screws in the bearing blocks because it would simply start to compress the Maxtube. This would leave it with not enough force and it would slip and loosen the chain. We created interior form-fitting Maxtube supports that allow for a lot more tightening force and, so far, the blocks and motors haven’t slipped down again.

• One of our climber assemblies, after mounting, completely and promptly ripped off (oops). The design originally only had screws that threaded into its thin .125" plates from the inside (there wasn’t space for nuts), and those threads were very quickly stripped and obliterated. We now know that a threaded hole in .125" plate isn’t enough to hold a screw under any types of load. We have modified them slightly to include multiple bolts going through the entire assembly and will reattach. Is there anything else we can to to strength these?

Full summary of our activities

CAD

• After finishing up most of the robot CAD, including a few last minute fixes, began working on some improvements to our designs.
  • We’ve been seeing a bunch of robot reveals that have similar, pivoting shooter designs, but with much shorter shooters/indexer pieces. While we originally thought that we would need a long shooter in order to reach up to the Amp, we are now realizing that that is not the case. CAD and Build have started designing and machining a shorter shooter, which would provide lower COG, easier access under the Stage, and other benefits without actually needing to give up Amp like we thought we might.
  • As Build has been wrapping up, we’ve realized that we might actually have the time to make some important improvements to the robot, even if after our first comp. CAD has begun designing a possible Trap-scoring method for our climbers. This is something that we’ve thought about in the past and also now have a proof-of-concept from Hyperion’s robot reveal video (~1:50). (thanks for the inspiration! your robot is amazing!!!)

Build

• Has literally finished the robot. While there are a few issues/improvements that need to be made, the entire robot is assembled, tested, and, best of all, WORKS!!!
• A lot of the improvements to climbers and bearing blocks listed above.
• Had also been working on and is almost done with our bumpers. We have three-section bumpers (one on each side and then one in front at the max height for the intake). They just need mounting brackets and numbers, but they fit great.

Electronics

• Fully designed and organized all of the robot’s wires and components. Everything is mounted and connected.
• We’ve been having a few issues with wires, especially CAN, getting unplugged as the shooter goes up and down (they get caught on screw heads and other protrusions). We just lengthened a bunch of the wires and strengthened the connections. Is there something else that we can do to remove this possibility in-match?
• 
  
  A super clean line of sparkmaxes (don’t worry we’re doing more cable organization too)

Code

• Has mostly finished auto-paths and our system for that.
• Has been transitioning into testing time!!!
• has been working on a bunch of limelight programs. We want to use our limelight to get our distance from the speaker to automatically move the shooter to the correct angle.
• Has been tuning PID (yay super fun!!) for drivetrain and shooter sprocket.

I know that teams have been rolling out their fully completed robots for weeks now and have even already done Week 0 comps, but this is actually a record pace for our team. Last year, for example, the robot was only a few days before competition and code had one late night of testing. We are incredibly happy with our robot, our growth this year, and our team.

Good luck to teams competing this weekend! We luckily have another week until Week 2 of testing time.

[Team_555]

Another update: (finally )

Last weekend, we competed at FMA Allentown. All throughout Quals, we did absolutely amazingly, one of our single best competitions in many years. We ended seeded 4th and the captain of the 3rd alliance. We chose 9015 (Questionable Engineering) and 8628 (Newark School of Global Studies), who both unfortunately ended up breaking down in our playoff matches, leading to our alliance’s premature demise. We ended up losing both of our playoff matches in succession and being the first alliance eliminated.

9015 and 8628, many thanks to you both!! We made a great alliance and I hope that all of us can sort out our technical issues to come back even stronger for the next one.

Then, best of all, WE WON THE AUTONOMOUS AWARD FOR THE SECOND YEAR IN A ROW!!! The judges really loved our Spaghetti system and the flexibility and combinations that come with it, not to mention its incredible multi-Note accuracy in matches. I really don’t know much about how our system works, but it enables us to string together short paths (from subwoofer starting position 1 to Note A, for example, then score from A and on to Note B), which gives us an incredibly flexible, accurate, and reliable Auto that was able to score 4 Notes with ease in multiple matches. There isn’t any “what Autos do you have” and “can u guys run a side auto?” - “no” for us – we can do it all. Many congratulations to our Code division for the award and all the hard work they’ve put into it.

As well as Auto, Code has done this incredible thing to our robot that we call Scoring Mode. I mentioned it up above, but this competition was our first big trial run and I am pleased to say that it worked amazingly. Scoring Mode is basically a button the driver can hold down when they are ready to score. Our Limelight picks up the Speaker AprilTag, locks our swerve heading onto it (even if the driver needs to veer around defense bots), and automatically calculates our distance from the speaker, which is inputted into a formula to convert to a Shooter angle. We found this formula by taking datapoints (manually moving shooter angle so it scores and plotting Limelight-given distance vs. angle) and running a curve fit. We rarely missed a Note this competition and we want to spend a lot more time tuning shooter speeds as well as angle for maximal accuracy.

FUN was there and interviewed us about our robot and code (much to our excitement: “We’re gonna be famous!!!” - me). Check out the video here for more info about our robot design, Auto, and Scoring Mode system.

Despite being incredibly successful, this competition has exposed a lot of pressing issues and areas for improvement that we spent that last week implementing. Here’s a summary of what we planned and what we’ve done:

Summary

• there were multiple times where we wracked up some hefty penalties for hitting within frame perimeter (G417), as our Shooter sticks 6 or so inches outside of the frame at our “cycling” angle (highest where we can still fit under stage). The solution to this (we even started manufacturing this before comp) is a shorter shooter, which would also have COG and speed advantages. Build finished and mounted it this week, but we still haven’t had a chance to test it due to some other issues. We are hoping its accuracy isn’t too impaired.
  

  
  
  The short shooter. While it still will reach outside of frame perimeter for lower angle shots, the advantage of it is that it can be at a high enough angle to be within frame while still fitting under the stage for cycling.

• We used to have a vertically mounted electronics board under the shooter, which we have now removed. This allows us a little bit more travel for some lower angles and hopefully further shots (the old long shooter could only shoot from just past podium)

• Code wants to do a lot more Auto and Scoring Mode testing, to get everything working even more reliably.

• CAD and Build have started designing and prototyping an alternate Amp scoring mechanism, as the short shooter will make our already mediocre amp scoring mechanism (just shooting it in with a prayer) even worse. This will most likely be some flip-out guide thing for faster, more consistent amp shots.

Here is a link to our team’s internal more in-depth breakdown of the competition and our matches. As always, open to feedback or thoughts on what we’ve been doing.

Thanks for reading!