FRC 4481 Team Rembrandts 2022 Build Thread

Hey Zent,

Here are the answers to your questions!

  1. What do you mean with the bouncing? Bouncing in the air or bouncing on the floor?
    I think it’s still going to be interesting to see how CARGO will fly into the hub with 6 robots on the field and that it well happen sometimes that CARGO hit each other in the air and bounce out/away from the UPPER hub.

  2. The flaps spin in the same rotation as the mecanum wheels. The flaps push the ball down and since it’s non-slip drawer liner it flexes around the CARGO to form to the position of the ball. Velcro might be too stiff and push/hit the ball if it enters at a wrong angle where the non-slip drawer liner deforms to the incoming CARGO.

  3. Yeah better than we expected! We got 6 CARGO on the way from Andymark so then we can test the durability :wink:

  4. You mean creating a big enough of a gap in the bumper that you don’t need an indexing mechanism? I wouldn’t advise to go down that path since you’ll be a defense magnet. With big gaps it will get easier to be pushed around.
    But basically a gap is a gap so this reason also counts for us. We’re hoping to be tiny, quick and offensive enough to avoid the defense.

  5. Yes very much so! Going for 4" wheels with a wider drum so stacked wheels side to side and then 2x NEO on 1:1 will get you shots that can shoot in either goal. It’s all in the details on how you tune from there, hood material for backspin, software control etc. We’re aiming for scoring LOW and UPPER in AUTO depending on what the other 5 robots will be planning on doing.

Hopefully that answered all your questions, if not let me know :wink:


Week 2 - Monday

Our media & branding team has worked hard on a cool recap video of week 1. Please go check it out, give it a thumbs up and hit that subscribe button :wink: We’re currently uploading videos to YouTube straight away, it might happen that there are videos on YouTube than a post on Chief Delphi.

So if you want to be the first then hit that subscribe button and put on your notifications.

That being said… ENJOY!

Shooter Testing

We’ve been testing our shooter prototype over the weekend on various variables.
Every video down below has a whiteboard in the right corner with the right settings of the test in there.

If there is a black area with white text then that’s there to correct a mistake on the whiteboard. In the upper right corner we displayed a picture of the materials we used on the backing of the hood. If there is no picture then we just used the polycarbonate of the hood.

1 Neo Shooter vs Different Hoodmaterials

Apparently all our previous shooter videos were with only 1 neo powered… Shame on us! So we’ve spent testing for an hour with only running 1 neo and no PID or just P controller.

We still wanted to edit the video and share it with you all since some teams might not be able to run 2x Neo. So here’s the results of our 1 Neo Shooter.


  • If you’re LOWER hub scoring only then 1 neo will be enough for you.
  • 1 neo is capable of reaching the UPPER hub in these videos but image there is no software control on there AND we’re running nothing else. No climber, no drivetrain, no intake. So with only 1 neo and needing it to run at 80% to score high across 2,5 minutes of robot action on the field is not a guarantee I’d like to give you. If you want to go UPPER goal then definitely go for dual neo setup.

The first couple shots are to dial it in and were done on black nitrile roughtop tread. Halfway the video we’ll be shooting with different materials.

2 Neo Shooter vs. Different Hoodmaterials

These are the shots with dual neos powered. Still no controls so just raw percentage.

Our controls department is trying to get the PID to work properly this week. During last weekend tests we ran into some CAN wire issues.

Shooter Conclusions

We’ll be proceeding on the setup outlined below. Currently the ribbed rubber looks pretty interesting but balls hit each other quite some times. So dialing in your shot to properly shoot 2 CARGO will take some time this week.

Today’s Week 1 Recap Meeting

Today we’ve had a completely remote Week 1 Recap meeting and Design Review. We’ll post a bigger update on that on Tuesday/Wednesday on the current CAD status, goals for week 2, what we’re aiming for to have done on upcoming sunday etc.

For now it’s… ZzzzZzzzZZZzzz




During week 1, we’ve been working on creating as many prototypes as possible to get a good feeling of the game elements, performance indicators and design geometry. Make sure to check out the recap video Week 1 | Team Rembrandts Building Season 2022

After finishing up the updated requirements list based on prototype performance, we’ve decided on an approach for week 2.

The new requirements for the robot were acquired by experimentation during the prototyping phase. These requirements will function as a blueprint for the first round of iteration of the robot design.


The start of designing a robot is quite abstract. By creating boxes and talking about the things you already know, we’ll create a better understanding for the entire robot.

Where will certain parts be sourced/bought? How are we doing on total motor count? How do we think the mass will be distributed? Where will we place the hanger-subsystem most likely? Are there certain demands/requirements from departments like manufacturing or controls to take into account?

Down below you will find the layout sketches of the current robot concept we’ve decided upon. The goal of these sketches and the decompositions are to create a point of reference to discuss subsystems.

Throughout time, week by week, we’ll update these decompositions and start thinking about cable management, where the connectors will be. How will we mechanically disconnect the cargo-in subsystem from the cargo-out or cargo storage? What’s the lead time on certain parts? Do we see any risks ahead? Can all the parts be easily manufactured? Aren’t there tooo much 3D printed parts? Do we have all the parts in stock that are currently outlined?

For these types of design questions from a specific point of view we use the term: DfX. DfX stands for Design for X. Where the X in DfX is a variable which can have many possible values. Manufacturability, cost, logistics, test, minimum risk. Etc!

Build Season Timeline - Entering Phase 2

As we enter Phase 2 of buildseason, we shift our focus towards iterating the chosen prototypes of week 1.

To learn more about our subsystems we’re currently designing high fidelity prototypes so we can test more and start fine tuning our design.

CAD designs will be produced to create purely functional subsystems for our “box robot” with the requirements of the subsystems (listed above) in mind.
The box robot will be the first proof of concept for the created prototypes, and will function as the first driver practice bot to start practicing as soon as possible.

Weekly Subsystem Design Reviews - Remote Monday

Throughout the entire build season, weekly design reviews will be held on Remote Monday to update the entire team on design changes and updated requirements; departments will be given the opportunity to comment, with their unique views, on the design; and to allow all members to ask questions.

The Controls Department has been working hard this year to create a process for quick prototyping by using software libraries and control boards. With the introduction of a large group of new students, the control department has set a large number of goals including path following and quick PID loop creation. During week 2, these students will be preprogramming the box robot to quickly get it up and running at the end of this week.

Plug & Play Design Philosophy

What we’ve written today leans into our flexible, plug & play design philosophy. It’s new for us to do it like this. It’s a process that will need lots of fine tuning over the next couple of seasons most likely.

Once the designs get more detailed we’ll dig a little deeper into this. For now we’d like to share some slides from our off-season that we created to train the team and start having them think in a plug & play way.



Week 2 - Wednesday

This post is going to be all about how we analyzed how many points we will need to win an event in week 1.

Prediction Methodology

During the offseason we spent time trying to figure out how you can predict scores for new games. The problem is complicated, there are a lot of variables that you can’t be sure of before you see the first matches. So the first step is: make assumptions! We decided to take a look at the historical data and see if that could help us.

Historical data is available, we have about 30 years worth, so at least there is plenty to cherry pick from. But the reality is that games aren’t what they used to be, and that isn’t just me being nostalgic for games I never even played, it’s also a fact that games have evolved over time. Some notable revolutions in this evolution are double trouble and triple play, all of a sudden you don’t even have the same amount of robots working towards objectives, and every year you see an evolution in the game so it is important to decide which games are still relevant to the modern game.

After a lot of debate and research we decided to start in what is often called the sports game era (2010 - 2014). A decision was made and we started scouring the blue alliance for game data, and almost immediately we ran into trouble: 2010, 2011 and 2012 often only have the match results but not the detailed results, so unfortunately they aren’t useful to us. Easy call: we’re no longer considering these games as modern FRC (in my head there are now two ages of FRC: the Data Glory Days… and the Dark Ages). Another cut had to be made for 2020, great game, great data sets, only played consistently in week 1, and had its last events played in week 3.

So we’ve narrowed it down to 2013-2019, still 7 games, so not bad, plenty of data to go from. I still had some scripting which downloads data from the blue alliance, calculates OPR (explained better than I could, by people that are smarter than me in a lot of places like: The Math Behind OPR — An Introduction – The Blue Alliance Blog) and put it in an excel spreadsheet, we ran that for those years, not only for the match results but also for individual scoring objectives. After taking a look at the data we had another epiphany: not all scoring is the same, some games score linearly (the same action repeats for the same score: think scoring cargo in 2019) and some games score stepped (the same action doesn’t always score the same points, think gears in 2017). As great as some of the stepped games are, they aren’t very useful for predicting future score development, so unfortunately they bite the dust as well: so long 2014 and 2017. We had two other dropouts for other reasons: 2015 had to go for only playing on a half field without any chance of defense and 2018 because its scoring mechanic is not at all dependent on the quality of robots (in theory an alliance robot could score way fewer cubes in one match than another alliance in another match and still score insane amounts more).

And then there were three: only 2013’s Ultimate Ascent, 2016’s Stronghold and 2019’s Destination: Deep Space. We went to work with that data, in the following three charts you can see the OPR progression from week 1 through the championships for each of these games broken down into percentiles, from the lowest scoring robots in the 0-10% percentage group to the highest scoring teams in the 90-100% percentage groups.

These graphs tell us a lot about the scoring progression. Basically, every week teams get better in every quality group, except for week 7 when the bottom 60% outperforms the bottom 60% percent of week 8. This is not too hard to explain: the district championships happen in week 7.

Scores increase every week, by relatively the same amount. So if we can predict any point that is on this scale or might correlate to this scale we can predict the scores during every week! So we set to work on coming up with what a single top 1% robot could score in a single match by the end of the season, and then use those predicted scores to normalize the three years in the analysis. The predicted scores in general are based on autonomous, maximum expected cycles completed, their points values, and the value of the end game. Since we’re trying to predict how to win events we only used the top 10% for the graph below:

Not bad of a curve fit right? All three games progress relatively similarly, so we decided our assumptions were at the very least reasonable. So based on this we decided to say the following: you have to score 60% of the ultimate match to win events in Week 1, the average of the three games is about 55% but we chose 60% to be on the safe side.

Rapid React Prediction

So if we need 60% of the perfect match, what do we think the perfect game is going to be? We discussed this a lot, checked out other opinions, and concluded about the following.

Auto TAXI 2
Auto CARGO Points 20
Teleop CARGO Points 40
HANGAR Points 12,5
Perfect Match Top Tier 74,5
Week 1 Top Tier 44.7

You might notice that 12.5 points is not something you can score in reality, after all you get 10 points for the high rung and 15 for the traversal. This is because we don’t really know if the traversal is worth it, yes 15 points is a lot, but you shouldn’t compare it to not climbing at all, but to climbing from the high rung to the traversal rung. It would take a while, time that you could also be scoring cargo in the upper hub. If you can’t do the climb in less time than you can do 1.5 cycles it’s not worth it (at least not in the playoffs). Still, some games at a high level might be worth it, and again better to score higher than we need than to go below so we settled on half of the time you make the climb, half of the time you don’t.

Scoring Plan

And then we’ve got to the ultimate question, how do we get the 44.7 points we project to need? Without trying to emulate a terrible soap opera, we’re going to have to leave you on a cliffhanger for that one. As of now we’re finishing up the story on the cycle analysis which is valuable input for what you have to be able to do to score x amount of points, when that is fully written down it will be released in this blog as well.


What a crazy analyze :smiley: Congrats for this.

1 Like

So six cycles of 2x CARGO in the high HUB, plus three high auto CARGO, and climb every time. Sounds like a hard challenge. Thanks for sharing this


Thanks so much!!!

We will be assembling out test bed tonight!!


Gotta show off our shop sabre also.


Let us know how it works for you! And of course if you have any questions. Good luck!

1 Like


As promised in the last post, this one is going to be all about cycle time analysis. First we will explain the calculations of the autonomous cycles and then the tele-op cycles.

In order to analyse the cycle times, first the cycle paths are determined and some basic parameters are determined. The following parameters are estimated before analysis:

  1. Robot speed: 3,5 m/s which is 11,5 ft/s
  2. Cargo collect time: 1 s / per cargo
  3. Cargo score time 1 s/ per cargo

To illustrate a robot position on the field we’ve used red numbered boxes.

Autonomous Cycles

The layout of the field indicates that there are 5 cycles that can be chosen. Each of these will be shown below.

1 Cargo - Auto Cycle

The first possibility is the 1 Cargo autonomous cycle. This option only scores 6 points (if Cargo is scored in the upper hub).

Action Time
Score 1 Cargo in upper hub 1.00 s
TAXI out of TARMAC 0.85 s
Total time 1.85 s
Points 6.00 p
Points per time 0.40 p/s

2 Cargo - Auto Cycle

The 2 Cargo auto can score 6, 8 or 10 points depending on how many cargo is scored in the lower or upper hub.

This auto is a valid option if the robot is not positioned on the right side of the alliance station. The reason is the amount of Cargo that is located on that side of the field which creates potential for more.

Action Time
Score 1 Cargo in upper hub 1.00 s
TAXI out of TARMAC 0.85 s
Collect CARGO 1.00 s
Move to scoring position 0.85 s
Score 1 CARGO in upper hub 1.00 s
Total time 3.69 s
Points 10.00 p
Points per time 0.67 p/s

This version of the 2 Cargo auto takes a bit less time due to the reduced driving location. This is the result of a different starting position.

Action Time
TAXI out of TARMAC 0.26 s
Collect CARGO 1.00 s
Move to scoring position 0.85 s
Score 2 CARGO in upper hub 2.00 s
Total time 4.11 s
Points 10.00 p
Points per time 0.67 p/s

3 Cargo - Auto Cycle

The 3 Cargo cycle could be executed in multiple ways and combinations. The result will be expected to look as shown below.

This auto scores between 14, 12, 10 or 8 points depending on whether Cargo is scored in the lower or upper hub.

Action Time
TAXI out of TARMAC 0.26 s
Collect CARGO 1.00 s
Move to scoring position 0.85 s
Score 2 CARGO in upper hub 2.00 s
Drive to CARGO 0.85 s
Collect CARGO 1.00 s
Drive to scoring position 0.85 s
Score 1 CARGO in upper hub 1.00 s
Total time 7.80 s
Points 14.00 p
Points per time 0.93 p/s

4 Cargo - Auto Cycle

The 4 Cargo auto is the ultimate autonomous cycle. It scores the most points and it has potential to complete the QUINTET.

The Quintet allows an alliance to gain a ranking point after only 18 scored cargo instead of having to score 20 cargo. This means either a 1 or 2 cycles advantage. The 4 cargo auto is strong because it allows 1 team to complete this Quintet. This is done when the human player scores their cargo shot.

Action Time
TAXI out of TARMAC 0.26 s
Collect CARGO 1.00 s
Move to scoring position 0.85 s
Score 2 CARGO in upper hub 2.00 s
Drive to CARGO 0.85 s
Collect CARGO 1.00 s
Drive to CARGO 1.37 s
Collect CARGO 1.00 s
Drive to scoring position 2.22 s
Score 2 CARGO in upper hub 2.00 s
Total time 12.54 s
Points 18.00 p
Points per time 1.20 p/s

5 Cargo - Auto Cycle

Having all the faith in the world in human players our variation of the 5 cargo cycle will be performing a 4 cargo cycle and having the human player yeet a cargo into the high goal.

Another variation of the 5 cargo auto is possible which is outlined below.

Being 1678.


In this game the tele-op cycles aren’t easily predicted. Ths has the following reasons:

  1. The Cargo is located all over the field. It’s not stacked in 1 place. There are no discrete (human player) spots in the field where cargo can be entered into the game.

  2. The cargo is a bounce / rolly game piece and is easily moved by touching.

  3. After being scored, cargo is ejected back onto the field by the scoring hub. The cargo can be released on four different sides and on each side there are two exit sides. Cargo will therefore be placed all over the field after the first several cycles.

  4. Due to the nature of the game, the cargo will probably be all over the field after autonomous due to there not being a specific stack to collect.

Basic Tele-op Cycles

The first basic tele-op cycle is the fastest one as well. This cycle assumes there is still cargo located in the cargo ring on your team’s alliance side of the field. As is shown, this cycle is fast. The only downside is the limited availability.

Even after auto it is questionable whether this cycle is still available. Therefore it is expected that this cycle will only be possible if the autonomous period is not executed as planned.

Action Time
Drive to CARGO position (1) 0.85
Collect CARGO 1.00
Drive to scoring position 0.85
Score CARGO in upper hub 1.00
Totaal 3.69
Points 2.00
Points per second 0.54

The terminal cycle is shown here. This cycle is necessary if the robot does not have a solid way to collect Cargo from the ground. The obvious disadvantage is the distance a robot has to drive for this cycle. This results in a longer duration of the cycle.

Another fact that works against this cycle is that the cargo will bounce towards the center of the field where the hub is located. Driving all the way to the terminal is therefore a waste of time when a robot could be doing other things while a cargo ball being dropped in the terminal is bouncing towards the hub for an easy score later on.

Action Time
Drive to TERMINAL 2.22
Collect CARGO 1.00
Drive to scoring position 2.22
Score CArGO in higher Hub 1.00
Total 6.43
Points 2.00
Points per second 0.31

Match simulation

xRC ball location analysis

The heat map is shown in the picture below. This heat map is created by educated assumptions and gameplay experience in the XRC game. This game is a simulation of the FIRST Rapid React game. The results have shown that Cargo after being scored will roll or bounce towards the edges of the field. This indicates that the areas shown in yellow will and orange will be the destinations of Cargo that are ejected by the hub. The orange zones are believed to be key zones to collect cargo.

These are the estimated times it takes to travel back and forth between scoring position and each of the 8 marked zones in the figure above. These are estimations:

  1. 3 seconds
  2. 5 seconds
  3. 6 seconds
  4. 10 seconds
  5. 5 seconds
  6. 4 seconds
  7. 4 seconds
  8. 8 seconds

One of the aspects that is introduced to this game is the random eject pattern by the hub. This means that it isn’t possible to make educated guesses about where the cargo will end up exactly.

It can be said however that all 4 exits have a chance to eject cargo in a nearby orange zone (1, 5 and 7). The only orange zone that is a bit out of reach would be zone 3. This zone can be reached by 2 out of 8 exit ways. This however is far-fetched because the interaction between the cargo and the hub exit is not consistent.

Cargo availability

This year there are only 11 game pieces per alliance. With 3 robots attempting to score those and the field only returning the cargo after 4 to 7 seconds one of the things we worried about was if there would end up being too few cargo on the field to get efficient cycle times.

So we set out to find if that was true by writing a python script that simulates matches. First thing we needed to do was to decide which variables would impact cargo availability. Of course the return time to the field is set to 4-7 seconds, but the main two variables that impact how many pieces of cargo on the field are the average time that it takes for a robot to collect cargo and the average time that it takes a robot to drive to their shooting position and shoot.

Simulating 10000s of match time per combination of time that it takes to shoot and collect gave us the heat map that can be seen below. We’re pretty happy to be able to do this with software, looking at that much match time (with the 30s cut of already heavily reducing the total amount) would take us 9.000.000 seconds or which is roughly 104 days, meaning that we would have been just on time for the einstein finals… provided that we came up with it on kickoff and not a week into build season.

What we conclude from this graph is the following: unless it takes your entire alliance insanely low time to collect balls you’re unlikely to get into real trouble with cargo availability, we project during general matches there will be about 7-8 pieces of cargo available to pick up and score.

Strategy analysis

It’s a bit early to start thinking about exactly how we would like our alliances to play matches, but the mind goes where it wants and we have been considering a couple of basic strategies. One being the best robot on the alliance is responsible for the half of the field furthest away from the alliance stations, and the other two both having a quarter on the side closest to the alliance stations.

We thought about this strategy for a bit and came to the conclusion that it might be too rigid. What if one half of the field outperforms the other side, won’t they have too few pieces of cargo soon? So once again we turned our eyes to simulation and we decided that the two variables that impacted this were cycle time of one half of the field and the ratio of both halfs combined cycle time.

I.e. if the best robot has a cycle time of 10 seconds for scoring 2 pieces of cargo, and the ratio is 2 the two robots on the close by half need to score 4 pieces of cargo in that time frame. Inputting this in python we ran scenarios for cycle times ranging up to 60 seconds and ratios from exactly the same cycle time to 3 times faster.

This gave us the graph below, if a field is dark blue it means you could last the entire teleop before it becomes a problem, everything not dark blue may mean you’re getting trouble at some point during the match and you would need to adjust your strategy on the fly. To us this means the strategy is unlikely to be rigid, it might work during the qualifiers, but during the playoffs you will have to be able to adjust to the flow of a match and it might not hurt to have one robot play some defense.

For those of you who are interested in taking a closer look at both graphs you can find them as html files in this drive map: .


After two blog posts we know a bit more about what to expect of the game, we know that we don’t know everything but still a little bit of data is better than no data.

Of course eventually we will see things happen on the field that we could never have imagined and those things will inevitably bite us in the end, but for now we’re happy.

The next post will be the conclusion to our data project, which cycles are we going to use to get to the holy number of 44.7?!


You used 2 inch wheels on the bottom shaft and then the 4 inch AndyMark compliance wheels on the top, correct? We have the upper wheels all prepared, but what should we order for the lower ones?

We’ve been using 2" stealth wheels as the feeder, and the shooter drum is 4x 4" stealth wheel. Both bought from Anydmark.

Here’s the current concept


Sorry if this has already been asked or covered, but how much compression are you putting on the ball on the shooter wheel?


Very cool, thanks. I thought they were the stealth wheels.

1 Like

We’re shooting with approximately 40mm depending on if we’re going to shoot with a grippy material on the hood. Then it might be around 42mm


What gear ratios do you use for your shooter and intake gearboxes? Are you using MAXPlanetary systems?

1 Like

I generally avoid using Planetaries of any kind on high speed applications because it adds inefficiency and generally you need so little reduction that it can easily be achieved with a single belt, chain, or gear stage.


Shooter is 1:1 with 2 NEOs. (Tuned and powered down with software)
Feeder is currently 5:1 but will most likely go to 9:1 with a NEO.

Usually we use the MAX Planetary gearboxes for prototyping and then try to design it for belts and pulleys in the final design without using additional gearboxes. This is usually more lightweight and works for us since we some nice productions partners to lasercut custom parts and 3D print every pulley we like.

I think this year for the feed through we’ll be ending up with a MAXPlanetary gearbox since we don’t have the space to package a pulley and belt with a reduction.


Friday & Saturday Week 2

Here’s a quick update on our progression so far. The original goal we made on Monday of week 2 was to have a complete robot done by the upcoming Sunday.

Sadly we ran into two issues. Our shipment from VEX Robotics in the UK didn’t get delivered on time. It’s been held in Eindhoven since Wednesday due to insufficient paper work from VEX, is what UPS has been telling us…

They had no contact info and there was no total invoice value with the shipment so it was a clueless box for Customs which alarmed some red flags… We paid for priority shipping since they were important parts for us but sadly we still didn’t receive the package yet.

The other issue we ran into is that we forgot to upload ALL the sheetmetal parts that were needed to assemble the drivetrain. We do all our sheetmetal lasercutting at the Cromvoirtse, one of our partners. So too bad we couldn’t CNC router our own sheets and have to wait until Monday to pick up the last parts.

Proto Subassembly

Luckily we were able to get some work done! We’ve assembled the entire intake and shooter so far. We’ll be running tests with those tomorrow.

Today they adjusted some hood angles and tested different PID settings to see what shot worked best.

Here’s a quick compilation of some shots:

Complete Hanger Prototype

We’ve assembled a mock-up prototype to test our hanger principles of a pneumatic climber.

Various tests can be seen in the video below:

Sunday’s Plan of Approach

See if we can get the intake tested on a different drivetrain we have if we can match the needed height requirements.

We dialed in the PID values for this shooter. Tomorrow we’ll be testing the shooter with the adjusted hood angles and different PSI Cargo.

Stay tuned!


I really like the hanger design. Passive deployment, and a simple extend, drive, and retract. What size is the cylinder, and where did you source it from?