4930: Electric Mayhem | 2025 Build Thread | Open Alliance

FIRST FRC Open Alliance
, ,
1

Hello and welcome to Electric Mayhem 4930’s build thread for Reefscape season!

This is our first season as a member of The Open Alliance and we are excited to be a part of it! We wanted to join as a way to document our build seasons more effectively for future students and to be a part of a great organization. We were founding members of the FTC Open Alliance and found great success with posting there. If you’re interested check them out below.

FTC 12736: Electric Mayhem Green
FTC 12737: Electric Mayhem White

Our team
We are a school based team from Buffalo, NY and this our 12th season as a team. In total our program has 6 teams. FRC 4930, FTC 12736 & 12737, and FLL 12891, 38326, and 54840. Nichols School is our main sponsor supporting the whole program. Students participated in the team as their sports credit for a trimester of sports at our school. We meet primarily three times a week on Tuesdays, Thursdays and Saturdays.

We structure our FRC into 3 main subteams, Mechanical, Programming and Impact. The Mechanical Subteam is further divided into Design, Electrical and Prototyping, with the three groups coming together after the design is finalized to put the final competition bot together. The programming team is also further divided into Comp Bot, Website & scouting app and new this year, the teaching group (no it doesn’t have a catchy name) but more on that later. The impact team is responsible for writing all of our award submissions and creating our judging room presentations and scripts. They also do most of the outreach event organization which the whole team participates in.

Historically, the majority of our team has been mechanical, with only 5 or 6 kids on programming and impact each. Interestingly, this year our team is much smaller and the vast majority of new freshmen had their interest in programming over mechanical. So the majority of the team is now programmers, hence the teaching group where rookies can develop their skills. Mechanical has about 8 students on it, making it the first time in years it had a single digit student count.

Each subteam is led by student leaders who make all decisions regarding the subteam and the interactions between them. Mentors take a backseat roll on design and build, their main role being guidance on decisions and logistics for travel. So who are these student leaders?

Student Leadership

Oscar: Project Manager, Design, and Mechanical


Nate (Left): Mechanical Captain, Drive Coach (@ThatCadGuy)
Brady (Right): Programming Captain, Driver (@indoorfish)


James (Left): Operator and Programming
Hamid (Right): Technician, Programming, and Certified Media Man


Maya (Left): Impact Captain (@hellooooo)
Avi (Right): Impact Captain

All of our student leaders get class credit and a grade for their work, and I’m sure you’ll be hearing more from them as the season goes on.

Coming Up On The 4930 Build Thread
We ended our offseason with the Ra Cha Cha Ruckus offseason event, before jumping right into our preseason in november. We filled it with projects and outreach events, but that deserves a post of its own.

Expect to see posts from us every weekend during the build season. Bringing updates of our progress and designs. We will go into more detail on our build season strategy in another post, but in summary to avoid some issues we had last year, we intend to CAD the entire robot before building anything. So expect a lot of CAD in January.

Where Can You Find Us
CAD: Onshape
Youtube: @electricmayhemrobotics
Instagram: electric.mayhem.robotics
Facebook: electric.mayhem.robotics
Github: 2025-Janice

More to Come!

13 Likes
2

We had a lot of issues with our robot last year, mostly in our strategy choices and CAN Bus issues. We decided to structure our Offseason around addressing some of these issues.

Offseason
Our main offseason project was taking another robot to the Ra Cha Cha Ruckus offseason scrimmage. We did this as a way to allow some rookies from last season to design and build their own robot. They went with a shooter design inspired by Orbits robot from last year, which was compatible with our amp focused from last year. They were given the offseason number 9990. Unfortunately, both robots faced mechanical issues at the competition which hindered our performance. For 4930 it was CAN problems that persisted from the competition season, for 9990 it was power issues. Despite this, 4930 got moved up to 8th captain where we were able to pick 9990 which made for a pretty fun tournament.

After this we decided we needed to fix our CAN bus problems. So we made some investments. First was Posi-Taps, the idea being that we could have one long continuous CAN wire with branches that come off of it to link up to devices. That way if one of the links breaks the whole bus can still continue on. This combined with our second investment into a CANivore will hopefully make our CAN network significantly more reliable. If there’s anyone with other suggestions on CAN fixes and/or solutions you have found helpful, we would greatly appreciate them!

Our team was heavily invested in Rev Neo Brushless Motors and Vex Versa Planetary gearboxes. Though we observed what the more successful teams were using and found that Krakens and Max Planetary gearboxes seem to be the cutting edge in motors and gearboxes. So we made the change.

The Kraken Self

We had first bought Kraken when we decided to use SDS Mk4is on our offseason robot. We loved them so we bought enough to use them on our comp bot this year. We also bought a bunch of Max Planetary gear boxes and used them on a preseason robot. We also loved them so far, so we intend to use them on our Comp Bot as well. Once again, anyone who has more experiences with Krakens or Max Planetary please feel free to give us any tips and suggestions you have about them.

Mechanical Preseason
Our preseason started in November, and with a smaller mechanical team, we decided to pursue two mechanical projects. A rope climber and an elevator. We split the mechanical team into two groups and set goals for each of these projects.

We wanted to do a more unique and interesting climber preseason project, so we chose a rope climb 2017 style.

CAD of the Rope Climber

The rope climber came together fast. We didn’t connect it to a full robot instead opting to just tie weights to the bottom of it. We wired it to The Football. What is The Football? You may find yourself asking. The Football is a box we have built a couple of years ago, it has a full robot control and power system in it, limelights, motors, PIs, Rios and the like. It’s perfect for situations like this when you want to give power and code to a single subsystem. We wired it using our new CAN solutions and it worked great! It climbed up the rope great right until we added some weight to it. Regardless, it was a good learning experience and CAD practice for the mechanical team.

We have a sneaking suspicion that next year’s game will be an elevator game. Even if it’s not, we aren’t good at elevators so we wanted to try to get better. We designed a chain driven elevator. Nothing complicated, just chains driven by motors at the bottom connected to a carriage. The carriage uses some WCP Bearing Blocks that we bought a while back.

It worked great, we went simple as we had limited time to complete it as many meetings got canceled because of snow days. All and all the preseason went well on the mechanical side of things, expanding our skills in many departments.

Programming (Pre) Preseason
We now enter the first thrilling installment of the Brady Show!

The programming preseason started a bit earlier than the mechanical preseason, with James and other programmers experimenting with AT and object detection with the Ruckus bot: Boomerang.

We’re using all LL3’s for the object and AT detection with the Google Coral coprocessor. We’re also using Mechanical Advantage’s (6328) codebase for most of our swerve and logging. As always, the github for these preseason projects and Boomerang, our offseason robot for Crechendo can be found here: GitHub - NicholsSchool/2024-Boomerang: Code for the 2024 Rochester Ruckus bot.

Below is a video of Boomerang aligning to the note off of LL’s object detection

Besides Boomerang, with only around 3 experienced programmers, and countless rookies joining the programming subteam, we decided to dedicate most of our time in the preseason to teaching rookie programmers the basics of Java and WPILib’s Subsystem/Command based paradigm. If you’d like any of the notes from these sessions, please let us know!

That concludes the Brady Show and this post.
See you at Kickoff!

4 Likes
3

Happy Kickoff everyone! Our project manager Oscar wanted to write up a little post on what we use as a team for project management. But his trust level isn’t yet high enough to post links and images and such. So he asked me to post this for him, so without further ado welcome to the first thrilling instalment of the OSCAR SHOW!

Last year our team had the goal of starting to develop our project management skills, hoping to refine our work timeline during build season. We started with nominating a project manager and some other associated helpers and had good results. This year, we wanted to continue building on these skills. I spent some of the offseason surveying some project management softwares and after some deliberation, we decided on GitHub projects. Our progress so far is summarized in this post.

Github for Project Management
Initially, we were considering monday.com, but although the version accessible to FIRST teams had many features we loved, such as an intuitive, user-friendly design and subtasks, we ultimately decided that the additional login created too large a problem for new students. We also explored the native system in google chat, our communication app, but it lacked many features we wanted.

However, all the Electric Mayhem teams share a GitHub organization, allowing us to utilize its projects feature, which is how we decided on using it. We started by creating our own templates custom to how we want to use the feature (see layouts). Once this was complete, we could create individual projects from them, saving hours of setup work. One of the main draws to GitHub is the integration aspect. Every programmer already had an account, and many other students, likely going into STEM, would probably need their own at some point (this is why we suggested using our personal emails for login rather than our school ones). This was the deciding factor in comparison with monday.com for us. The largest problem, however, is the organization of projects. The default view, for example, is Recently viewed, but that’s not helpful when signing in for the first time or trying to find specific projects. The impeccably-named Projects tab (not to be confused with the other tab by the same name it is nestled within) offers some useful sort options, but we wish we could separate the projects into folders, as we utilize GitHub for our FTC teams and side projects alike. This results in a daunting list of projects that stifles ease of use.

An item is the basic unit of the projects. You can create them wherever and give them sortable and groupable properties such as status, priority, and dates. Every item is created as a draft. You can assign them to issues (linked to repos in your organization), but we have not found much use for this feature as non-programmers. Thus, all of our items are drafts demarcated with dotted gray circles. The titles of items can be clicked on to open a side panel showing its description, where text can be added to link to websites or provide important information. Projects also supports descriptions, readme’s, and status updates, as well as insights where you can create charts to view data intuitively.

Layouts
We use GitHub projects with three main setups: task lists, BOM’s (bill of materials), and schedule overviews. A note about roadmap views: we found that to lay items out intuitively it is best to sort by start date ascending, secondary by due date ascending.
Task lists list tasks. Our items are given a title, assignees, status, priority, a skill tag, and four dates: a start date and a due date for planning ahead and mapping smaller tasks, and a real start and real end for easely documenting what actually happened. It also has four views, which are the board view, grouping tasks by status into four bins. Next is the master table, containing all items and their associated values. This is the easiest place to add tasks. The for you view is also a table, but it shows only items assigned to the user. Last is the schedule, which lays all the tasks out on a roadmap.

The BOM lists every part that we want to order. Items are given a title, status, manufacturer, subsystem, order date, and delivery date. Additionally, the description of every item includes a link to its store page and critical purchasing info like how many to buy. The status view groups items by status, and is useful when looking to see what has come in yet. The first table view groups items by manufacturer, used by our mentor when placing orders, so he can go site by site. The next groups by subsystem, allowing students working on the arm, for example, see all parts pertaining to the arm and add items there. We also have a schedule view, but it’s not very useful.

The schedule overview is just a simple list of phases and their associated dates. We are going to use it as a helpful visual tracking season progress, likely showing it on the TV at the start of each meeting. I converted all of these items to issues and closed set dates of events to have colors, as this was something I wanted to look nice for each meeting. This is just a roadmap view with normal date sorting.

Summary / Conclusion

  • Pros
    • Team integration
    • Necessary features
    • Very useful for programmers
    • Opportunity for documentation
  • Cons
    • Bad organization
    • No subtasks
    • New account and login for some of the team

I believe that project management software can be very beneficial to all FIRST teams as it has been to ours. If you are looking to implement one, try some out–even though we didn’t end up going with monday.com, they have a partnership with FIRST and the software is really nice. We also have a lot more smoothing out to do with GitHub but hopefully it’s here to stay. Feel free to ask any questions as I am sure I left a lot unclarified in this post.

Happy kickoff, and see you soon with more exciting updates!

2 Likes
4

Well, well, well, a pick and place game after all.

Normally these posts will come out over the weekend, but I thought a post kickoff post was important.

How We Run Our Kickoff
First and foremost, some context.

We don’t run an official FIRST sanctioned kickoff, instead we have teams from our area join us at our school to watch the game and strategize together. This year we were joined by 5590 Alumiboti. We get our box delivered from another kickoff in a neighboring town, which is then split amongst the teams.

After we watched the reveal and the field tour (Side Note: Love the field tours, I think its great those are sticking around), we split up into groups. Each group is responsible for analyzing one section of the manual, and one group is responsible for building a rough model field. After analyzes and rough field building we reconvene to discuss our findings and notable rule changes before The Fun Part begins.

The Fun Part: We use blindfolded people to act as robots, and non blindfolded people to steer them as drivers. We play full matches with this set up. We’ve been doing this activity to end kickoff for years, is it real useful? Eh, it can be, it can give you an ok sense of what strategies score more than others, though this falls apart when the humans can usually get more cycles then our robots. It can be really good at seeing what parts of the field get congested, if you’re looking for it. But most importantly it’s great at being fun, which is the important part.

The Reveal
In order to break the ice before the video started, we split the teams into groups, and raised the challenge to design and then present your own FRC game. Shout to FIRST Cavern Collapse, and FIRST Touch Grass (Sponsored by John Deer and the State of Idaho), for taking home 1st and 2nd place respectively.

Then the reveal video started, and a hush fell over the room. It’s quite the game, I find that after the first watch of the video there is a general sense of dread as the game looks way harder than it is. Especially those climbs! FIRST is making them sketchier and sketchier. Then we split into our groups for game manual analysis.

Whiteboards from the game analysis. (Top Right: Driver Station POV, Top Left: Field Dimensions, Bottom: Score Breakdown)

By this point I’m not sure I can add much to the conversation as the big stuff has already been found and propagated. I will, however, add what we as a team made of this year’s game later in the post.

The Fun Part (Game Simulation)
As explained above we played a game simulation to examine how the game may be played.

Our Quickly and Self Built Reef for the Simulation

During our simulated matches we found that teams that focused the reef generally put up more points and cycles. Though the Co-op was a good way to get max RP. An interesting strategy that emerged from one of the simulations was throwing out every piece of Coral from the human player station. This resulted in faster cycle times for placing on the reef, but increased the difficulty of navigating on the field, and is not viable in a real match as it is unlikely that you could get coral all the way to the reef. Though we said that you couldn’t get the cube/cones very far in Charged Up and that turned out to be false, so more testing is required.

Strategy Meeting
After our friends from 5590 left, we sat down for a strategy meeting. The main question we were trying to answer was whether Coral or Algae should be our main focus. Using what we found from our score analysis and our simulation, we wanted to prioritize scoring Coral on all levels.

Our Analysis Board

We wrote out all the functions a robot might want to have, once we had our focus we started removing functionality from our list until we had a collection of achievable functions for our robot.

Our Initial Robot Function List

By the end of Saturday we knew that we wanted to be really good at picking up and scoring Coral. We also wanted to be able to take Algae off the Reef. We spent some time at the end thinking about initial designs for our bot. Then slept on it.

1/5/25
We reconvened the next day, and started prototyping manipulators for the game pieces. We also built our first field elements, a reef segment and human player station.

Reef Segment and HP Station

We also want to build a cage that we can hang off some old field elements, and may try to reuse our amp from last year as a processor.

We spent most of the day prototyping. We were originally trying some grabber mechanism that could pick up the coral. But the bumper rules kept coming up as a roadblock so we pivoted to over the bumper intake. Those and an end-effector for placing on the reef are still in the works and will be debuted in a future post. We also worked on some algae removers. One drive by rotation and the other by pneumatics.

Arm Based Algae Remover (Left) & Piston Based Remover (Right)

They both didn’t work great. But we did learn from them, and in our research for improvements, we saw Cranberry Alarms work during RI3D and how a spinning compliant wheel can really effectively remove Algae.
Testing Wheel Algae Remover

We tested it out with a drill and found similar success. We think our end-effector for placing coral may have the ability to double as an Algae remover.

We also purchased a WCP elevator this weekend. All of our designs involved elevators, something we are historically bad at. So we went with the WCP kit as it is highly configurable and reaches a very high height.

That’s all for our kickoff, we have a lot of prototypes in the works. Intakes and End-effectors, all for the end of week post when we have them in working/failing states.

Have a holly jolly Week 1!

1 Like
5

This post on 4930 Reefscape Build Thread is proudly sponsored by THE WEEKLY DOSE OF MAYHEM PODCAST!

Weekly dose of mayhem is the only show which gives you top quality “comedy” and first hand accounts of what happens in the Electric Mayhem Lab. After a little hiatus Season 2 Episode 8 is on air now with a LIVE STUDIO AUDIENCE! The podcast goes up nearly every Friday at about 1:00 Pm EST.

/Ad Over/

Intakes Galore
The bumper rules this year are really hard. Which makes coral intakes really hard. I’m traditionally “the intake guy”, but it stumped me. The design I came up with would eventually prove a useful end-effector (we’ll get to it). One of our interesting failed prototypes was a combine like intake where fingers could lift the coral over the bumper.

It didn’t work great, but some of our roller and compliant wheel designs looked promising. But some of them suffered from having to make you come down over the coral instead of just driving into it.

Initial Over the Bumper Intake Sketch

Others looked promising but were potentially prohibitively large and heavy

Other Intake Sketches and Crayola CADs

Prototypes looked good until the coral would start spinning out on the bumper and not make its way up the bumper. It was at this point where we started debating forgoing the ground intake and focusing exclusively on picking up from the HP station, until…

With a little grip tape and letting the front compliant wheel move up and down we were able to get the coral up over the bumper. This worked even better when we added another stationary shaft of complaint wheels above it to move it further up the bumper.


2d Sketch of Intake with Front Moveable Wheel

There is still a lot of work to be done on the intake. Making that front compliant wheel move up and down linear so it can move around the coral (most likely driven with gas shocks) and figuring out where and how to drive the pivoting of the intake. But more on that as it comes out.

Indexers
We weren’t sure if we needed an indexer but we wanted to prototype one anyway. We first started playing to see if we could rotate a coral.

Our initial prototypes worked pretty well, we think if we had another mechanism behind it to grab it once it’s oriented right it would stay in said orientation. We did CAD a design to do so, but it was too large to build for real.

Indexer CAD

End-Effector
Remember my failed intake prototype, well we pursued it as an end-effector and it worked pretty well.

The way it works is it has compliant wheels driven by a motor for intaking, and a piston for grabbing and dropping. Just like a grabber from 2023, the idea is that this would sit at the bottom of the elevator and grab corals intook from the intake. Then ride up the elevator to outtake on the reef. But now here’s the cool part, it can double as an algae remover.

Overall this prototype worked great, we want to iterate on it more to make the grabbing a bit more consistent, and we still need to work on a mounting solution, but it’s well on its way.


Intake 2d CAD (Including: Future Geared Finger Iteration)

We also prototyped possible scoring angles, as we were intrigued by the idea that one angle could score on all levels.

We found that angles about equally between the L2 and 3 angles and vertical work great. In the video we measured our angles from vertical making L2 and 3 at 55 deg and our prototype at 26 deg. Which seemed to work great.

So with all these prototypes, a lot of them working, we now had to figure out how to best put them together.

Crayola CAD
We spent a good amount of time working on this…


Current Crayola CAD of the Robot

Because I’m so nice, I’ll even give you a link to view it yourself.

In Green we have our intake, behind that in red the end-effector in its stow position. In blue is our WCP elevator which we ordered. On top of that at its full extension, the arm is shown in Orange. I haven’t discussed the arm yet, as it’s still a work in progress, but we intend to rotate it one way to reach out over the bumper for scoring and rotate it the other way to pick up from the HP station.

As stated early the intake still needs some work, as we need to work out the pivot, the end-effector still needs a mounting solution to the arm, which needs to be driven. The end-effector probably also needs to be changed to pick up from the human player station. We have ideas on how to accomplish all of these, and our next steps is to work on these in the coming days.

And with that, I’ll see you next week.