FRC 4481 Team Rembrandts | 2025 Build Thread | Open Alliance

Great to hear! I’ll check if it’s possible to make more content/quizzes public.

@Justin_Foss is currently working on the more advanced FRC history levels. I believe he has been in FIRST for more than two decades now, so completing those levels will be super fun and challenging :smile:

15 Likes

Renewed Hardware Skills Class Program

Over the past years, our team has tried various structures for the roles within the Hardware Department :gear:. Especially the division of roles and students between the two sub-departments: Mechanical Design and Manufacturing & Tooling.

Last year, new students could sign up for either of the two sub-departments and would start in a role that was affiliated with that specific sub-department. This resulted in students not being able to reach their full potential, often due to a lack of training.

On top of that, we often struggled with our student-to-mentor ratio. We want to keep performing on a high level, like we always do, but also give younger students the chance to develop themselves :star2:. And we want them to be part of our build season process, allowing them to become role models for others in the future. Therefore, we decided that a new structure would be necessary.

New Training Path for Students :hammer_and_wrench:

For the upcoming Reefscape pre-season, we made the decision that new students will always start within the Manufacturing & Tooling sub-department to learn the skills required for working in our machine shop :wrench:. In addition, they will learn valuable skills such as technical drawing reading to enable them to quickly analyze designs and build up these systems.

After the first year, and acquiring the necessary knowledge for production and assembly of robot parts/systems, it is possible to enroll within the Mechanical Design sub-department as a part designer. We strongly feel that new students will benefit from the technical knowledge learned during their first year, to be able to add value to our mechanical design process. They will become better designers when they know how to build what they are actually designing.

It has to be said that the implementation of this structure is a plan to be executed over the upcoming few years, and as a team, we are working on defining the skills required for each role. To make sure that we do not bite off more than we can chew, we decided to start this year with the implementation of a smaller portion of the overall structure overhaul.

For the upcoming season, we focused solely on the roles and specifically the learning path for first-year students. The other roles are more naturally taken already by senior students, active support members, and mentors. It will take time to get those roles worked out in detail as well. However, this is not a priority for the Reefscape pre-season.

After deciding on the smaller version of the large role structure, it was time to set up a new Skills Class program for the Hardware Department. The idea is to let students slowly get to know all the tools in our workshop and, besides that, learn valuable skills needed for assembling a robot during the build season.

Starting off with the first two roles students can enroll in: Help Mechanic and Workshop Junior Machine Operator. The first three weeks of Skills Class students will get to know the following machines: Drill press, brake press, miter saw, and large bandsaw. Starting with these machines means getting yourself familiar with some of the simpler machines in the workshop as opposed to, for example, our lathe, 3D printers, or the CNC router.

The two weeks after the ‘first’ learning trajectory of the ‘simple’ machines will be spent on assembling robotic systems :robot:. For example, an old intake from last year’s robot, Coda, or a new drivetrain that we’ve designed for prototyping. Students now get the opportunity to familiarize themselves with certain aspects of subsystems, such as assembling, but also learning about standard parts such as axles and bearings.

Only after these first few weeks will students learn about other things such as the lathe or CNC router. These machines, we believe, are more complex, need more work, and therefore larger classes are being set up for them. This will give students the opportunity to slowly but gradually learn more about these machines as time passes over pre-season.

Introducing Online Learning :books:

To ensure our team evenings are both productive and fun :tada:, we’ve integrated an online learning environment into the Skills Class program. By using the TR Academy, students can now complete their theoretical training at home :house_with_garden:, allowing them to focus on hands-on learning when they’re in the workshop. This approach should maximize the time spent on actually operating machines and building things, while minimizing the need to cover theory during team nights.

We believe this will make the learning process more efficient and enjoyable for students.

homework GIF

Future Steps :rocket:

This is just the beginning of our multi-year plan to revamp the roles within the Hardware Department. For now, we’re focusing on first-year students, but as the program evolves, we’ll be working to define the roles of senior students, support members, and mentors as well. Stay tuned for more updates! :date:


Written by:
@Luukyluuk4481 - Hardware Manager
@EmmaVTW - Lead Manufacturing & Tooling

20 Likes

Great quiz, but I’m gonna have to respectfully disagree with some of the answers. Having rope be an incorrect answer for the 2017 climb question seems odd, and in the 2023 defence question, answers 2, 3, and 4 are all correct together, but 2 is the most correct in my opinion. Good defence can avoid safezones, but the lack of any applicable chockepoints or structure to pin a robot to really killed defence that year (aside from the goats 1678)

2 Likes

Hey @art3misfowel,

I get what you’re saying and some questions might indeed have some alternative answers that can also be considered correct.
The purpose of the quiz is mostly to make our students really think about certain game aspects and to have discussions about how they would approach each game on a strategic level.

3 Likes

From Data to Dominance: The Power of 3DM in FRC

Every season, our strategy department kicks things off with 3DM (Data Driven Decision Making), a method that guides us from day one to ensure our robot is designed for success. Want to know how we do it? Here’s a peek into our data-driven process!

Our Kick-Off Strategy Breakdown

The first weekend of the FRC season is intense and exhilarating. Here’s how we lay the groundwork for our winning strategy:

Saturday: Game Analysis Day

We dive into the game manual, taking detailed notes on the rules and requirements. Our goal is to understand every scoring opportunity, from game actions to ranking points, and summarize it all for easy reference. By the end of Saturday, we have a solid understanding of the game’s scoring opportunities.

Sunday: Strategic Skill Planning

Sunday is where our strategy truly takes shape. We start by creating a comprehensive robot skills list, documenting every skill a robot might need to excel in the game. Each skill is paired with specific Key Performance Indicators (KPIs) to measure effectiveness. As the season progresses, we continually update the priorities of these skills based on our 3DM findings.

Using PathPlanner, we sketch out feasible auto routines to estimate how many game pieces a robot can score during the autonomous period.

Next, we shift our attention to teleop cycles. By analyzing the average time it takes to complete a scoring cycle, we can estimate how many game pieces a robot should be able to score during teleop. We make these estimations by physically driving a drivetrain and timing it, or by driving a robot in the xRC simulator.

We evaluate all potential endgame tasks, considering their point value, the time they take to complete, and the complexity of building a mechanism to perform them. This helps us decide which endgame strategies are worth investing in and how to balance them with the rest of our robot’s design.

Lastly, we conduct a thorough ranking points analysis. We look at the requirements for earning ranking points and assess how achievable these are with a full alliance of three robots.

Monday: Learning from the Past & Finalizing Strategy

On Monday, we dig into FRC history. We identify old games with similar elements to the new game, learning from past strategies and outcomes.

After that, we brainstorm different alliance strategies, predicting which combinations of robot roles and capabilities will be most effective on the field. This helps us understand how to optimize our team’s performance alongside our alliance partners.

We also focus on human player skills. We develop a detailed skills list for the human player, identifying critical abilities that can impact robot performance. By setting training priorities, we ensure the human player is well-prepared to execute their role efficiently and avoid any potential performance bottlenecks.

Field analysis is another important step. We carefully annotate the field map, adding callouts and reference points to assist our strategy team, drivers, and programmers.

From Predictions to Performance: Our X% Rule Explained

After completing our analyses, we estimate how many points the best robot in the world will score, using our X% rule. We consider factors like auto game pieces scored, teleop efficiency, and endgame potential. Our goal to win the California regionals drives us to build a 70% robot, one capable of scoring 70% of the points we predict the best robot in the world will achieve. Through our calculations, we’ve determined that achieving 70% gives us a high probability of winning a week one California regional.

We experiment with different robot skill compositions to reach this 70% goal, balancing simplicity and reliability. At the end of build season week one, we compare these concepts with our hardware archetypes, selecting the one that offers the best performance with minimal risk. This strategic choice provides the flexibility to perfect our design and practice extensively without sacrificing competition success.

Continuous Improvement During Build Season

Our work doesn’t stop after kick-off. Throughout the build season, we monitor robot and subsystem performance, measuring KPIs to identify where we can achieve the greatest improvements with the least effort. This pursuit of excellence ensures our robot is more than ready to take on the intense competition at the California regionals.


TL;DR

Watch this YouTube shorts video about 3DM:

If you have some more spare time, I recommend watching our 2024 pre-season presentation about how we approached the 2024 season:

3DM LIVE OPEN SOURCE ACCESS

Since some of you might be very curious what happens in the black box called 3DM, I decided to make the spreadsheet that we’ll be working in during the 2025 season open-source. Note that some tabs are still under development at the moment, but will definitely be ready for kick-off. Please let me know if you have any questions about the sheet or our 3DM approach!



Written by:
@Bjorn - Chief Editor & Lead 3DM

37 Likes

Since the pandemic it really has been win or don’t move on from the perspective of moving on via robot performance. However do you foresee this methodology changing with the way qualifications will change heading into 2026 (and kind of 2025)?

Since winning is not the be all end all would a methodology focused on getting more advancement points (such as from ranking higher thus a greater focus on RP) replace the 70% performance metric? Or do you all think that a robot who is performing at 70% of the best at week 1 (and 2) secure enough points anyway that you would be able to qualify?

13 Likes

That is the question isn’t it: ‘does this mean you can lean back a little?’. We haven’t been able to fully go over the data, and of course the answer is super region depend.

For California I think our goal will remain the same. Looking at the attendance of our two events, the competition not just for winning the event, but even for being on the finalist or third alliance is insane. But we will certainly be looking into (and posting if we think the results are interesting) how the new qualifying rules impact our strategic design decisions.

11 Likes

Hey @MARS_James,

I’m working on the data analysis at the moment to confirm the effectiveness of the 70% rule we have been using the last couple of years.

I’ve created a python script that loads event data such as the OPRs of teams, whether they won the event or not and what their qual ranking was.
Then I do some data magic like normalizing the OPR for each year so that 1.0 equals the highest OPR of that year.

Using the historical data, I can make a OPR distribution for teams that won the event and for the other teams. Overlapping these distributions, while taking into account the sample size, results in the following graph below.

The figure shows the OPR distributions for week 1 & 2 California regionals over the last few years and the winning probablilties. Keep in mind that the distribution is not perfect, since the sample size of winning teams is quite small.

As you can see, from around 70% of the max OPR the chances of winning a week 1/2 california regional is about 30-60%. The probability calculation is purely made based on event OPR which might not be very accurate since there are a lot of other factors that can also impact a team’s robot performance.

Based on this graph I just made, 70% robots have a good chance of winning, and therefore this will probably remain our robot performance target for this year. Over the next days, I’ll try to find some time to maybe also make some graphs/models that include for example the qual ranking of a team so that the regional advancements changes of 2026 can be taken into account.

Feel free to check out the public GitHub repo and let me know if you have any questions!

9 Likes

Have you tried using the normalized EPA that Statbotics provides? It’s designed to be comparable year to year while still varying enough that you can see how dominant a team was or how well balanced the game was that year.

1 Like

Okay so EPA is interesting.
Since it’s kind of a moving average, it’s hard to estimate the performance of a team at a given event (our team is particularly interested in week 1/2 data).
I guess it would be possible to do the some thing as I did with OPR for EPA. At first, I didn’t think that it would work, but now that I give it a second thought it might not be a bad idea. Will let you know sometime soon how the graphs looks based on EPA.

2 Likes

I figured they still have a good chance of winning however winning does not equal qualifying in 2026 (for now it is fine).

Under 2026 rules you would have qualified at Hueneme Port as the 3rd highest point earner (1678 and 4414 were 1 & 2) in a 3 way tie that took to the 4th round tie breaker to decide. 4481, 6036 and 4 all had 59 points. 4 loses the tie breaker due to having a poorer finish in Elims. 4481 and 6036 then tie on Alliance Selection and Qualification Round points. Meaning it goes to Highest Scoring Match which 4481 wins via having a 159 point match in Qual 70 and 6036 had the 148 point match in Finals 1.

Losing the tie breaker ultimately would not have mattered since you still were the number 1 point earner (second on robot points to 4414) the following week at Ventura County.

In 2024 at Hueneme you would have been second in points to 498 (4481 was first in robot points) so would have qualified. At Ventura you also would have been second on points to 4414.

So while the robots made would have qualified just fine the only event you achieved the most points for robot performance was 2024 Hueneme at every other event had the Impact or EI gone to a team with better robot performance than they did (or not to you at 2023 Ventura) there was a likely chance of you not qualifying.

Now a robot with a Win and a finalist or 2 wins not making it off of the wait-list pulls in weeks 2, 4, and 6 is highly unlikely but I imagine your goal is to know before you leave the venue in week 2 that you are guaranteed your spot at Champs.

7 Likes

Are you guys going to be doing any pre kickoff bumper prototyping?

For now we do not have anything planned with the new regulations for bumper materials. We did some research into possible materials in the past but these were never allowed by the regulation. Of course we will be closely following the discussion threads on CD regarding the materials.

As the season develops I can imagine we will do some testing, because having the ability to dissipate the impact forces better is always beneficial for the robot.

5 Likes

New Software Architecture :building_construction:

Ever since switching from LabVIEW to Java back in 2020, we have been running a custom implementation of a timed robot. While this has served us well for a couple of seasons but we have started to bump into increasingly more issues, leading us to finally biting the bullet and taking the time to do a complete rewrite of our code base.

Growing Pains 👴

When we started using our old code base, the sub-department barely had 5 members. Starting this preseason, we have around 15, all with different talents, ambitions and experience. To properly facilitate this, you need a completely different structure. Since our way of working is deeply tied to our software architecture, that means we would need to scale up in that area as well. While we cannot possibly solve every issue we have, we can definitely define the most pressing ones.

We can split up the most pressing issues in the following categories:

  • Inability to do concurrent development
    • Lack of robot availability
      • Available from week 3.5 onwards, in the middle of our test/exam weeks
    • Git merge conflicts due to people working in the same files
  • Amount of context required to meaningfully contribute to the code base
    • Lack of available documentation for custom resources
    • Lots of training needed to add basic features due to a perceived lack of structure
    • Existing solutions to problems are not directly applicable due to a difference in architecture

The Solution 🛠️

Over the summer, a couple of super dedicated software members have been meeting multiple times a week in order research and rewrite the complete code base. Instead of going for a custom solution, we opted for a command based architecture with AdvantageKit topped off with some of our most liked ‘legacy’ features.

Robot vs Library :books:

Just like previous years, our code base is split up into two distinct parts: robot code and library code. The robot code contains everything that you would expect from a command based project, while the library contains code that should be reusable for multiple seasons.

Robot Library
Target Season/robot specific code Generic, robot-agnostic code
Scope Entire repository lib package, WPILib, vendordeps
Quality It should work, all public methods should be documented Style should be consistent, all methods should be documented

Availability and Concurrent Development :robot:

Not having (concurrent) access to a robot is our biggest bottleneck at the moment. As mentioned above, most of our students and mentors (almost all of them still in University) have exams around week 4 of build season, right when we are usually expected to have access to a (single) physical robot. Not only is this super inefficient, we most of all don’t want to put extra pressure on people in a way that would inhibit their academic performance.

Leaning heavily into AdvantageKit log replays and physics simulations for every subsystem, we can test and debug systems during driver practice, and even while production and assembly is still ongoing. Allowing us to go through ‘integration hell’ on our own terms. In the best case, we only need a physical robot to tune setpoints.

Example of robot simulation

Ease of Use :baby:

Our other major issue is that it is really hard to find the things you are looking for, as our old code base lacks quite a bit of documentation and a lot of solutions to problems that can be found on the internet are not 1-to-1 applicable.

By switching to a system based on more commonly used features, we can ensure an easier time for students to look up documentation and get answers to questions.

Op top of that: by making more use of inheritance and interfaces, and splitting subsystems up into logic and IO parts (as suggested by AdvantageKit) we can allow people to work on more separated tasks.


Separation between control logic and hardware interfaces in a subsystem as seen in the AdvantageKit documentation.

Code Release 💻

A strong foundation only makes sense when strong implementation rules are applied. To test these rules, we have converted our 2024 robot code into our new architecture. This converted project is openly available through our GitHub linked below!

It does not yet contain the full set of features that was present in our original code base, but it should serve as a good example of the changes we made, and our design decisions for upcoming years.

:point_right: 2025 architecture example code :point_left:

Future Steps 🚀

While we have already seen a big increase in ease of use compared to the old system, we will inevitably discover new issues along the way. For instance, if coming season will be a pick and place game, we might need more complex state logic compared to what we have tested up till now, so we will have to see if we can blindly implement that with the design decisions we have made for now.

We will be sure to update you about any important changes we make along the way so stay tuned :date:, and as always, questions are more than welcome :thought_balloon:!



State of the 4481 code base pre-rewrite, beautifully visualized by this xkcd comic.


Written by:
@nigelientje - Mentor / Project Lead

30 Likes

New! “How We” Posts :thinking:

We noticed that there are a lot of teams that recently started an OA Build Thread or are thinking about starting one. Therefore, we want to provide those teams with information about “How We” run our OA efforts, so they can learn from it and apply the knowledge in their own way.

What can you expect?

For the next several weeks, we’ll launch a new “How We” post every Monday at 11am (ET). These posts provide beginning OA teams with useful knowledge to enable them to grow their OA efforts for the upcoming years. Some already scheduled topics are:

  • “How We” Write and format our OA Posts
  • “How We” Post our prototyping to YouTube
  • “How We” Stay motivated and continue to post throughout build season

If there are topics that you would like us to discuss, feel free to mention them below. We hope to support other OA teams with this content and we’re excited to share our way of working with all of you.


Written by:
@Bjorn - Chief Editor & Lead 3DM

20 Likes

“How We” Post our prototyping to YouTube

Ever since joining the Open Alliance, we have put specific emphasis on the sharing of our prototyping process by uploading videos of our prototypes (successes and failures) to YouTube in real time, or at least within 24hrs of recording. In order to do this, we have created a workflow that allows multiple contributors to support the process while maintaining a consistent brand.

YouTube Playlist :movie_camera:

This starts with organizing our YouTube channel. Each season we create a new playlist called “Build Season 20XX - Robot Development,” where all videos related to prototyping and then robot development will be stored.
When uploading videos, we use a standard naming convention as well, which typically looks something like: “FRC4481 - 20XX Prototypes - Name of Prototype/System, Specific Test Information.” This allows viewers, as well as team members, to reference specific testing in the future.

Slack Integration :calling:

Now how do we record and track the uploads? Team Rembrandts uses Slack as our primary method for internal communication. A Slack channel is created each season, for the upcoming season it is called “2024-2025-prototypes” since the team will start using it during the preseason as we work on projects mechanically as well as software.
We then set guidelines about video recording, most notably that all videos should be recorded in landscape view, and with those on camera wearing proper personal protective equipment (PPE) :man_mechanic::eyeglasses:. Everyone is free to record and upload to the Slack channel.
The videos on the Slack channel are then reviewed by a few members of the team who have access to our YouTube channel. They select the videos that will be uploaded, upload them with the proper naming convention, linking them to the proper YouTube playlist, and then adding the proper “:clapper:” emoji to the post in Slack. This signifies that the video was selected and uploaded.

Future Steps :rocket:

This year we expect the general process to remain the same as we have documented here, and the goal, of course, is to share the same amount or more as we have in the past.


Written by:
@Justin_Foss - FRC Historian & Mechanical Mentor
@Bjorn - Chief Editor & Lead 3DM

10 Likes

My team along with many others have migrated over to slack as a primary method for communication, I am curious to know more about the ways you utilize slack.

What are some neat tricks you may use to help increase communication and workflow? What apps have you used to help manage/track projects? What do you use to keep the team synced on meetings and when important events are happening?

Any other helpful tips are appreciated! :slightly_smiling_face:

2 Likes

I’m interested in what value do you get from open alliance. Many teams look at open alliance and think why would I join open alliance and tell others what I’m doing if I’m not getting anything from it. I do think there is value you get from open alliance but I’m curious what you have gotten out of it.

2 Likes

Hey @RSimpson & @Smtopps,

Both are very good questions! I’ll make sure to write a detailed response soon, but don’t have the time at the moment😅

4 Likes

Hey, thanks for your reply! Here’s…

“How We” Manage our Slack Communication

We’ve been working with Slack ever since our 2017 season. After many years, we’re still figuring out what the perfect way is to use every feature, but we’ve got some tips and tricks we’d like to share. To start off, we’ve divided almost everything into different channels. This offers the team a well-organized and overviewable workspace, needed for an optimal workflow.

We use the following channels:

  • Announcements - in here you can post your MOST important messages. For us, it’s mostly communicating deadlines and important dates. Therefore, not many messages are being sent in this channel during the year, since only the ones with the highest priority are being sent here. Regionals sign-up deadline? Share it in announcements. Team weekend sign up form? Share it in announcements.
  • General - in here you can post all of your General announcements, think about events coming up or semi-important dates everyone should know. Is awards holding a review session? Share it in general. Do we have an event coming up and we’re looking for attendees? Share it in general.
  • Random - in here you can post all of your random messages. Is an event going great? Share it in random! Do you want to order food for your team evening? Share it in random.
  • Memes - To make sure you have a very fun channel, and more important— a very organized Slack, create a memes channel! In here, everyone can share the memes they created. Have you captured a fun picture at an event? Share it in memes. You’ve created the most legendary meme after winning week one regionals? Share it in memes.
  • Departments - For every department, and sometimes sub-department, we’ve created a separate channel. In here, everything surrounding that department is sent in this channel.
  • Events - Recently, we’ve started using Slack channels for different events. First, a message in general is sent out where team members can sign up using our feedback & response system (more about this below). After this, they’re added to the event-specific channel.

image

Build season channels
Build season is chaotic, that’s why it is important to keep your workspace as organized as possible. So we’re creating different channels to keep everything as clear as possible.

  • Build season 2025
    We create a main build season channel. Here we discuss things such as first game impressions and archetype selections.
  • Prototype 2025
    Have you created, tested or build anything during build season? Make sure to capture it and send it in this channel. It’s one big bunch of brainstorms and trial and error! This way, everyone is updated and aware of the latest findings within the team.
  • Subsystem channels
    For every subsystem, a channel is created. All the progress and development on this subsystem is shared within this channel. With this, we keep our process during build season clear and organized.

Threads
Threads are your best friend when it comes to an organized channel. Within our channels, especially build season-related, we talk mostly within threads. These prevent your channel from getting spammed so much it becomes unorganized and messy.

Feedback and response system
When asking for feedback or response from other team members, we’ve created the feedback and response system. It works as followed. Let’s say I wrote a social media post; but I’m not sure if my English grammar is right. I’ll send the following at the end of the text:

image

The same method is used when we’re asking who is present at for example our weekly team evening:

image

Workflows & Slack Bots

We also make use if workflows that act as our own Slack bots. For example, we have created the “Door Bot”, which allows team members to virtually ring the bell of our workshop’s building and it asks in Slack if the last person can respond and open the door. We made that one specifically, since the building we’re in, uses a RFID key system to open doors and since only a few of us have those keys, team members have to ask others to open the door.
Since this communication is very repeatable, it is worth it to make such a Slack workflow/bot. We also so do this for other common communications like asking the whole team who will be present at the team evening.

image
image

There are also more fun/advanced bots that we use to inform the team about external updates. I’ll cover this in a future “How We” post, but just to give a small teaser; it involves tracking our Chief Delphi thread and other threads to inform the team via Slack using a Slack Bot and a Raspberry Pi…

Names & pictures
Everyone within our Slack has to have their name and their role within the team for their Slack username. We also encourage everyone to upload a profile picture, so others know who they are talking to or need to talk to.

Communicating within a department
Everyone is free to communicate as much as they want within their department. We do however encourage to either give everyone an update during our weekly standup, before team evenings. Or send updates within the department specific channel.

In short
To answer your questions: We use a well-organized multichannel workspace to increase our communication and workflow. We’ve noticed that separating channels, projects and events helped us manage and track our projects.
And most important: We have different channels for different priorities on messages. I hope that this answers your question. Please let us know if you want to know more details or if you have questions other than our Slack communication.


Written by:
@Sandwich21 - Lead Media and Branding
@Bjorn - Chief Editor & Lead 3DM

18 Likes