The intent is for users to base their response on the average team, so some people’s “average team” will have unique resource situations compared to other’s “average team”. This isn’t super scientific, I’m guessing most of the averages just blur out the inconsistencies of the data to get a “close enough” result. I’m using the data to check my own estimates, not to use as its self, so there’s a large enough tolerance of error.
I’m ready for some delicious recency bias.
It’s already showing. It’s interesting to see what survey takers see as difficult compared to how long it’s been since a subsystem was commonplace in a game.
People must be experts on elevators by now. A frisbee shooter must seem impossible to accomplish to most students right now.
Yes, though being an expert on an elevator doesn’t inherently make it less resource intensive in all regards. The knowledge and experience barrier is lower, but that is only one of many criteria.
I put 3 on bells and whistles, but it seemed pretty broad to me. Powder coating requires either a sponsor or a specialized facility. LEDs require a $20 LED strip from China and a $40 Blinkin from Rev. (Or a $2 bootleg Arduino if you want to code it all yourself and work out power distribution and stuff)
I spent some time figuring out whether to separate the “extras” such as powder coating and LEDs. I decided to group them together because I believed that on average their resource intensities were more or less comparable. Some require more money, some more time, some more sponsorships, some more experience, etc. I think with all of the resource variability between the “bells and whistles”, their resource intensity would likely be the same.
But that’s just me - maybe I’m missing something.
If you would like to follow the results of the survey as it updates, check out the following link: https://docs.google.com/spreadsheets/d/1RWAyLVABD_y-gRlqFsFhj79DqWqXH0yv0hN12oFS6JQ/edit?usp=sharing
I ask that survey participants not look at the results before taking the survey to reduce result bias.
It is interesting to look at some of the trends among the responses. I do not believe the data is a complete accurate reflection of the actual resource intensity of the listed subsystems, as there is too much variability between subsystems and individual team circumstances to get a right answer, but looking at the trends as data updates does provide some valuable insight into the perspectives of the population sample who took the survey.
To be fair though, in general shooters are harder to design and build than elevators. For elevators, you really only change the number and height of the stages, width, rigging, and motors. All of the intricate stuff stays pretty much constant between implementations and can be bought as a kit from a number of suppliers. Most teams could design an elevator in 2018 without prototyping even if only the seniors had any experience with elevator robots.
On the other hand, shooters have a thousand and one variables you need to account for to get everything dialed in properly, and they will vary widely from year to year. It generally takes multiple prototypes to find geometries that will work, even if all the students have experience designing a shooter. Shooters in 2012 vs 2013 vs 2014 vs 2016 vs 2017 were all very different; elevators in 2011 vs 2015 vs 2018 vs 2019 were pretty similar.
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
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.
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.
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.