Subsystem Resource Survey

TBH, I’d take the Frisbee shooters from 2013 over the ball shooters we’ve had to come up with the past few years (especially 2017). At least with Frisbee’s you have a game piece that behaves consistently, that alone eliminates a number of potential variables (though, granted, floor pickup intakes for Frisbees was hell).

Does “resource intensive” mean how difficult it is, or literally requiring a lot of resources to be able to do?

There’s no meaningful way to answer the “other” and “miscellaneous” categories

1 Like

I suppose both? I imagined one of the resources required to execute a subsystem well to be how difficult it is. Harder subsystems take more time / people power / money to execute well, which to me translates to more resources.

It’s a difficult concept to capture, and I’m sure I’m not doing it the best way, it’s just the best way I can convey the concept right now.

As for the “other” / “misc”, I think the primary factor is the R&D that goes into the subsystem. The listed subsystems are ones I found to be commonplace enough that teams aren’t reinventing the wheel to make one.

The survey method is definitely flawed - I don’t really know much about this area of surveyance. Any input on how to get better results or make a more clear survey would be appreciated.

Considering the granularity inserted into many other systems, it may make sense to break elevators into multiple categories. At the very least, breaking up single stage elevators from multi-stage elevators from pass-through elevators. As with basically any of the systems, the devil is in the details.


I was on the fence about that, but you’re definitely right that the extra features of a subsystem can change it’s categorization. My original idea with this was that most extra features could be considered separate subsystems, but design optimizations such as single stage vs multi stage and pass through are things I couldn’t account for without making the survey too long. I elaborated for drivetrains because most of thme are different enough that I could easily justify it, but I couldn’t figure out how to handle the other subsystem optimizations.

Personally, I think a pass through elevator and non-pass through is just a function of the width of the elevator and that that doesn’t majorly contribute to the resource intensity of the elevator, and while more resources are required for multi-stage vs. single stage, I wouldn’t think it’s enough to merit that much difference in terms of listing, but I could be wrong.

I think in the later stages of this project I will consider more of the “extra details” like the ones you’ve mentioned and find a way to accumulate them on top of the base structures (ie. For each stage of an elevator, there is n more resources taken up). I think in most examples such additions would be relatively linear, but I’m open to suggestions.

It significantly impacts cable routing, carriage design, and elevator bearings as well. While the latest generation of elevator designs and carriage bearings are generally fine with loads on both sides of the elevator, things like 80/20 sliders will be much more significantly impacted by changing the direction of the load. So, by limiting the pool of potential options, you do cause the design to become more resource intensive.

1 Like

One type of mechanism missing from this survey is an intake. IMO for most games your intake design should take up a significant portion of your resources for all types of teams. For low-resource teams, designing and assembling any type of intake is a challenge, so it takes up a lot of resources. It’s necessary though, because you can’t score a game piece that you can’t pick up (in most games). For higher-resource teams, the a large part of the difference between an average cycler and an elite cycler is the time it takes to intake the game piece. If you have a wide error margin for intaking you can cycle faster, meaning score more points. Teams spend a good amount of time iterating intakes to make them as tolerant of misalignment as possible, which takes up resources. These teams might be able to throw something together that will work pretty quickly, but I expect that most spend more resources than that by choice.

1 Like

I see the issue being that all responses are required. You’re getting a mix of expert reflection and novice assumption. A rookie team who’s never made a turret may score it a 10 because it seems hard. Veterans who’ve given it a try may all rate it between 5 and 8.

Be prepared to see data that confirms commonly held opinions more than an objective assessment of resource intensity.


All intakes I’ve seen are just combinations of core mechanisms, typically rollers + pneumatic pivots / single jointed arms

That is what the data shows, but that’s also something I’m more interested in seeing. The final scores will be decided by myself and a smaller, private group. The survey is to see how our internal ideas compare to a public sample’s.

I’m surprised that omni tank is rated more than two points more resource intensive than kitbot. Just change out the wheels and some spacers on a kitbot and you have omni tank. OBTW, the AM kit is way too complicated - skip the long axles, pulley spacers, long churros! Just get the wheels and swap out the am-1307 spacers with 4 more am-1306’s*. If you want only omni, also get 2 4" hi-grip or similar wheels to replace the 6" center wheels.

* You’ll be 0.07" too short, but omnis don’t transmit axial forces anyway. If it bugs you, cut the 1307’s down to 0.35" instead.

1 Like

Thank you to everyone who participated in the survey. We have received 85 submissions so far as of this posting, and the results are not only extremely useful for my project, but also very interesting to consider. I have posted them below. Note that given the nature of the survey, this is not an official metric of subsystem ranking, but a reflection of the opinions of those who participated in the survey.

Rank Resource Intensity Score Subsystem Outliers believe subsystem is ___ resource intensive than average Standard Deviation
1 1.65 Kitbot More 1.00
2 3.60 Roller / Conveyor More 1.66
3 3.91 Pneumatic Pivot / Linkage More 1.95
4 3.99 Omni Tank More 1.72
5 4.09 Limelight Vision More 2.10
6 4.32 Single Jointed Motorized Arm More 1.58
7 4.48 WCD More 1.54
8 4.80 Mecanum Less 1.77
9 5.02 Four-Bar Linkage More 1.71
10 5.08 Bells / Whistles More 2.24
11 5.20 Linear Punch Less 1.91
12 5.32 Elevator Less 1.70
13 5.45 Flywheel Shooter More 1.89
14 5.46 Catapult Shooter More 1.72
15 5.70 H-Drive More 1.61
16 6.36 Custom Drivetrain More 1.75
17 6.59 Purchased Swerve Less 1.74
18 6.64 Ramps / Forks Less 2.14
19 6.97 Double Jointed Motorized Arm More 1.53
20 7.06 Custom Vision Less 1.63
21 7.18 Custom Mech More 1.66
22 7.28 Octocanum Less 1.85
23 7.59 Butterfly Less 1.62
24 8.03 Turret Less 1.70
25 9.07 3+ Jointed Motorized Arm Less 1.57
26 9.33 Custom Swerve Less 1.26
1 Like

Just to note, powder coating does not necessarily require a sponsor/special facility. 'Snow Problem has powder coated many robots in their own shop with nothing special in terms of facilities. Here is their white paper on the set up.


Looks to me like people perceive elevators to be harder than they actually are in the current age of FRC. I’m convinced at this point that an elevator is far superior for the average team to choose than a single-jointed arm. Wouldn’t have said that before COTs made them easy in 2015, though.


The survey was regarding resource intensity, which covers ease of implementation, but is not solely defined by it. I can see other factors of elevator implementation contributing to survey takers’s perceptions regarding it’s resource intensity. COTS elevators have removed many barriers to entry (and even added some), but not all.

Fair. I still believe the survey responders to be incorrect :slight_smile:

1 Like

Absolutely concur. In resources, I included money for parts, time and opportunity cost for students and mentors, and facilities/tools available, scaled to the scarcity of those resources in my years of experience.


There is a lot I find questionable, but there is a lot that I find insightful. I went into this knowing that I tend to underestimate the resource requirements for subsystems (it’s easy to say that it’s just a turreted shooter on just a four-bar) and while the results aren’t the most accurate, they provide a perspective that both confirms and challenges some of my prior conceptions. If anything it has me rethinking some of my prior points of view to find things I may have missed before, which to me means this part of the project has been a success. Of course this is just the beginning of the project, but it has been an incredibly helpful one.

Hey all -

Thank you to everyone who helped provide input for the first iteration of this project. After working on the second iteration, I have what I believe is a somewhat presentable version that I’m not too embarrassed for the public to see, so I would like to submit it for further evaluation. It is always helpful to get a sense of what other’s think to balance against my own assumptions.

I would appreciate it greatly if anyone would be willing to look over the data in the “Breakdown” tab of the spreadsheet and provide feedback on what values they believe may not be reliably reflective. The data is more clearly reflected in the associated “scores” tabs for each primary resource method.

Thank you!

1 Like

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.