Opinion Poll: Proliferation of Prefbricated Parts

[AndyB871]

I pretty much read OP's post as:

Quote:
When I was your age, I built robots with drill motors uphill in the snow both ways and had to remove the anti-backdrive pins too! AND WE WERE HAPPY ABOUT IT YOU WHIPPERSNAPPERS!
Seriously, COTS parts are awesome! Use them to your advantage. I don't miss the old days.

There's always someone. I did make an attempt to say that what you "interpreted" was actually NOT what I was saying.

Again, COTS Parts are great. I was more opinionated to the more frc-specific stuff, like prebuilt ball grabbers and such.

I don't particulary appreciate the way you attempt to make me seem like a crusty old grumpy man... I'm actually not much older than my students. I also don't want or expect them to design individual gears and sprockets and gearboxes and chains, etc etc. Cut me some slack here. Try to read what I'm actually saying. I don't hate everything, I don't hate COTS, I just see a pattern towards more complete purchaseable solutions.

I wholeheartedly apologize for using words that , I guess, made me sound like I expect students to "figure it out" and "deal with it". That's NOT where I'm going here.

[Lil' Lavery]

I do think there is a difference between a generic-use COTS robot part (a gearbox) and a game-specific COTS robot part (an intake). That may be the distinction that upsets some people.

[cadandcookies]

Originally Posted by Lil' Lavery

I do think there is a difference between a generic-use COTS robot part (a gearbox) and a game-specific COTS robot part (an intake). That may be the distinction that upsets some people.

The interesting thing about the intake mechanism AndyMark is selling is that while it seems like a game specific thing, if you look at the last ten or so games for FRC, you could use it as is in probably 7 of them as is, and the other 3 (2007, 2011, 2015) you could modify it a bit for use in, say, a roller claw. So while it may look like something game specific, really a roller intake is just another common component of a robot. That's a big difference in selling that versus, say, a variety of 7, 8, and 10" flywheel ball shooters.

[XaulZan11]

Originally Posted by Lil' Lavery

I do think there is a difference between a generic-use COTS robot part (a gearbox) and a game-specific COTS robot part (an intake). That may be the distinction that upsets some people.

I think this is a common feeling on the matter.

I think this is a fantastic discussion to bring up. I do think it is only a matter of time before companies start selling kits to make game specific systems (intake, climber, shooter...) that could be combined to build a complete robot. The past few years have brought companies building complete robots, providing CAD drawings and selling kits of the more challenging to produce parts for these robot systems. The next step is for companies to explicitly sell robot systems along with step by step instructions.

Originally Posted by Ian Curtis

I don't think anyone wants to sell teams prefabbed game solutions (that wouldn't be any fun!).

I think it would be fun for the company if they could sell them for a significant profit.

[Akash Rastogi]

Originally Posted by XaulZan11

I think this is a common feeling on the matter.

I think this is a fantastic discussion to bring up. I do think it is only a matter of time before companies start selling kits to make game specific systems (intake, climber, shooter...) that could be combined to build a complete robot. The past few years have brought companies building complete robots, providing CAD drawings and selling kits of the more challenging to produce parts for these robot systems. The next step is for companies to explicitly sell robot systems along with step by step instructions.

If there is a market for it, if it is cost effective for the company, and if the prices fall within the rules, let the free market do its thing.

Nobody forces anyone to buy anything.

Do people take issue with companies making a profit?

Heck, if I had the start up money and the man power, I'd be selling my own game specific kits. Business is business.

[XaulZan11]

Originally Posted by Akash Rastogi

If there is a market for it, if it is cost effective for the company, and if the prices fall within the rules, let the free market do its thing.

I agree with everything in your post (I have no problems at all with the current suppliers), except this. If FIRST (either HQ or the teams/community) decided they don't want 'purchasable robots' something could be done.

[Akash Rastogi]

Originally Posted by XaulZan11

I agree with everything in your post (I have no problems at all with the current suppliers), except this. If FIRST (either HQ or the teams/community) decided they don't want 'purchasable robots' something could be done.

Sure, something could be done. But I have a hard time agreeing with any statements that something should be done if such a scenario exists in the future.

FIRST already has price per component rules in place, how much further would you want them to go with such restrictions? How would they be defined/enforced?

If the community doesn't want something, then those people don't need to purchase the hypothetical components. Telling others to not buy something just sounds a bit ludicrous to me.

[XaulZan11]

Originally Posted by Akash Rastogi

Sure, something could be done. But I have a hard time agreeing with any statements that something should be done if such a scenario exists in the future.

FIRST already has price per component rules in place, how much further would you want them to go with such restrictions? How would they be defined/enforced?

If the community doesn't want something, then those people don't need to purchase the hypothetical components. Telling others to not buy something just sounds a bit ludicrous to me.

I have yet to take any stance on if pre-fab systems should be allowed or not. I was just responding to those who have expressed concerns over pre-fab game specific systems and doubt that they will ever be sold, by predicting they will likely become a reality in the near future.

Originally Posted by Sperkowsky

I do not think companies will ever sell a robot in a box. Not for moral reasons but because cots parts can't be more then $400. A robot in a box is worth more then $400.

If I was a brilliant designer and had the manufacturing capabilities, I would look at designing a game specific subsystems using mainly the current COTS parts. Then sell a kit containing the 'custom' parts and instructions on how to assemble the 'custom' parts in the kit with standard COTS parts (sold separately). I believe these would be legal if each kit was priced under $400.

[Christopher149]

Originally Posted by XaulZan11

I agree with everything in your post (I have no problems at all with the current suppliers), except this. If FIRST (either HQ or the teams/community) decided they don't want 'purchasable robots' something could be done.

(As someone involved with FTC this year) The FTC rules for 2015-16 state:

Originally Posted by FTC - RM01 (c.)

COTS parts and assemblies may only have a maximum of a single degree of freedom. It is the intent of FIRST that Teams design and build their devices to achieve the game challenge. Assemblies of COTS components, such as linear slides, and gearboxes are allowed while a pre-fabricated gripper assembly designed to grab the game elements is not. Holonomic wheels (omni or mechanum) are exempt from the one degree of freedom limitation.

So, it is not impossible that FRC may at some point have a similar sort of rule to push back on complete COTS solutions. (Though the specific rule would sure put a damper on shifting gearboxes, etc.)

[evanperryg]

Originally Posted by Lil' Lavery

I do think there is a difference between a generic-use COTS robot part (a gearbox) and a game-specific COTS robot part (an intake). That may be the distinction that upsets some people.

Agreed. COTS parts level the playing field by providing lower-resource teams with affordable, premade options that will fit their needs well enough. However, a team who relies solely on COTS systems will find that their performance is much the same- off-the-shelf, just like everyone else. Although COTS assemblies raise the baseline for competitive robots, they don't hurt teams who put time and effort into mechanisms of their own design.

[Caleb Sykes]

I don't really buy the arguments that having more COTS components brings the bottom up relative to the top, although they do certainly bring everyone up. Even though there has been a steady increase in FRC-specific COTS components over the past few years, OPR distributions have remained similar. It would be interesting to see these same plots from even earlier years though. COTS components do indeed bring the bottom up, but that statement alone is misleading, because if so, they also bring the top up by a pretty comparable amount.

I am convinced though that having easily accessible drive components makes it very difficult for teams not to field driving robots. I would love it if we could get to the same point with mechanisms.

The times from before the kit chassis were the Dark Ages. We are in the Renaissance now, and after the ravaging Stronghold wars are finished, AndyMark, VEXPro, WCP, and many others will bring us so many good COTS parts that every robot will not only be able to drive, but will also have functional mechanisms. Then, we will enter the Enlightenment, and the whole world will be inspired by our amazing robots that can all actually do something.

[GeeTwo]

Originally Posted by Lil' Lavery

There are a great many real-world engineering jobs that involve the spec'ing, selection, and integration of COTS components. Not all engineers work on the component design level.

This. One of our mentors engineers ocean data collection and transmission systems. Most of his designs are 80-90% COTS parts integrated with the critical 10%-20% that make the system meet the requirements. There are some major companies out there who sell and service operating systems that are 90% open source and 10% custom. When a COTS product meets a one-off requirement at a decent price, designing and building a custom solution is bad engineering.

Likewise, our team starts with pre-engineered COTS drive trains, gearboxes, motors, and mounting brackets when available, and designs and assembles them to meet the requirements of our strategy, which was decided in order to meet the requirements of the game. I can't think of a time that we used anything mechanical that was more complex than a gearbox without making some modifications to it to suit our game strategy. Last year we turned the 2015 KoP chassis into an H-drive, this year we're making a 10 wheel drive starting from the same kit. We were working on a leading wedge for our robot that matches the one AndyMark will be selling soon; once we expected this to happen, we did the prototype but canceled the design and construction of the competition wedge, and moved on to even more manipulator design. This is a miniature version of the real-world situation in many, many fields.

The $400 limit does a pretty good job of preventing "prefab" robots. If a team showed up with a robot built and programmed 100% according to plans available from a vendor or on-line, there would be little STEM inspiration. When a team shows up with a well-running original design that is composed of 90+% COTS parts, learning and inspiration are all but certain to have been part of the process.

[bEdhEd]

Andy, I don't take your post as a bash, so please don't take mine as a bash either.

Personally, I think if someone thinks that heavy use of COTS components in a robot stifles learning, creativity, and problem solving, then that person is lacking in a little thing called imagination.

We LOVE LOVE LOVE COTS parts. VEXPro is our go-to COTS system, and the bonus is that they share our color scheme

The reason I bring up imagination is because the ways that COTS parts are creatively implemented is what is important. I think one issue is the very wrong implication that building with COTS yields a lack in creativity or learning value. I think it's quite the opposite. With COTS parts, we can prototype and iterate many times faster than if we had to fabricate more things from scratch. The most important part of our design process is iterating. This is what I feel can be most valuable to learn during the build season. Taking time to custom design something with the intent of learning skills should be left for the pre- and post-season.

It seems like some people think using COTS parts is a plug and play game, but it really isn't, at least on my team. It's more of a game of plug and fail, plug again, and it's kind of OK now, do some math, plug again, and well, it looks great but need to do better, plug again, and finally it works the way we want!

Some may disagree with me on this, but with the six weeks you're given, there's no time to learn through making everything custom! That takes up precious time that could be spent making prototypes and constantly improving them until they can no longer be improved. That's how progress is made in technology in the real world. The biggest technological advances don't come from one isolated design, or from some person making an original breakthrough seemingly out of nowhere. These advances come from years and even generations of gradual iteration and building upon the knowledge acquired from others.

Real engineers don't have to build everything they design, and that idea can apply to FRC teams too. If my team can put together a VEXPro ball shifter, and not bother with building a custom gearbox, then we will do it! But can we build our own gearboxes, and do we have students with the skills to design them? Yes! Because they did that learning in the other part of the year known as the off-season, where we have time to step back and go through the details with both FRC and non-FRC related projects.

If we don't spend time fabricating systems that can be bought already, then that gives us the time to fabricate the systems that really have to be custom. We may LOVE LOVE LOVE COTS, but COTS doesn't give us everything. We CNC and 3D print our own parts, weld our frame, and make our own composites. It's COTS parts that allow us to focus on the custom systems of our robots, so those systems are better tuned and ready for competition. If we had spent time machining drive transmissions, the most basic of systems that can be taught in the pre-season, then we would have less time, energy, and resources into making custom systems work, and work well.

By the time this build season is over, we will have built/worked with four robots: Concept (mostly built pre-season as an adaptable chassis), Prototype, Practice, and Competition. Without COTS parts at the ready, we wouldn't be able to do this. It is this iterative process that shows students what true learning is. True learning isn't limited to being able to recall past instructions enough to design a custom gearbox or having the skills to mill everything manually. True learning is being able to develop meta-cognition, or in other words, self reflection in what has, can, and will be done. This is what the iterative process gives to our students. It shows them that rarely is anything done on the first try. Neither is building anything easy, even with the amount of perceived convenience that COTS parts can deceptively give to teams who won't see COTS parts as something that they can make their own in some creative manner.

If we can buy an entire intake system, arm system, or shooting system, we will. But you sure can bet that our students will break it down, rebuild, tinker, and tweak it to make it suited to our own strategic needs better than what the assembly instructions recommend.

A team that heavily relies on COTS parts only misses out on the learning of building a robot if their mentors and students lack the creativity to "own" those parts and make something original from them. For that kind of team, the problem isn't in the prefabricated parts, but in the limits of their imagination. Why not buy a COTS part and ask, "can I use this for something it isn't intended for?" (but safely)

Teaching meta-cognition through the iterative process is one way to keep in mind that FRC isn't all about the robot, but about learning the skills that can make a student a productive and articulate member of society. This self reflection is one of those skills. Focusing on making students learn particular niche skills like fabricating custom parts is to lean more on the "it's all about the robot" side of the spectrum.

By no means am I saying that custom fabricating parts that are available COTS is a bad thing. If your team is capable of it, by all means go ahead. My main point is that with the short time we are given to make a competitive machine, it is OK to opt for the quicker option, and save the more technical learning for the off-season. Also, I'm not saying that build season is not the time to learn technical skills. There's plenty of time in the season to learn technical skills, but that should be through the systems that are unique to the team design and the year's game, not something that can always be designed during off-season, such as drive transmissions (which rarely change season to season) and experimental systems (e.g. if a team wants to do swerve the first time, they first do it pre-season instead of after kickoff)

COTS parts are as valuable a learning too as you make them.

[techhelpbb]

COTS is not a panacea.

Ask the US Military about parts obsolescence or security and quickly the issues COTS creates will appear.

http://www.militaryaerospace.com/blo...t-go-away.html

https://www.cigital.com/papers/download/ses.pdf

Now the FIRST challenge of a project too big in a time too small really does have benefit from COTS. It allows under-resourced teams to deliver on something they couldn't otherwise deliver without some serious pain.

On the other hand - personally I think it comes a bad time in their careers.
When one can continuously get financial resources from other people and direct them towards COTS vendors instead of learning the more base principals from the moment they were first old enough, and responsible enough, to understand those principals I think we might be robbing some of the students, in the long term, the value of tactile experience (even if it's hard work) early on.

To this concept let's theorize in direct relation to Dean Kamen himself. Would Dean have had the opportunity to found FIRST if his work did not show unique determination early on to acquire the resources to materialize on his ideas?

I won't deny that when I was younger I certainly used TTL chips which are COTS digital circuits and still maintain a large surplus of them. However they were inexpensive and you had to work to build something from them. The knowledge I acquired from learning how to integrate their functions together was invaluable when moving into programmable logic. While I certainly do not miss hours bread boarding and wire-wrapping circuits - I do often see the price people pay for not having that experience. Simple things to me like: delay lines, are confounding to a new generation of people who never saw a race state up close and personal. So they connect macro cells together so many years later (college and later) than when I started working with TTL at age 8 and can't understand why the resulting responses are unstable.

I think sometimes that in order to make FIRST appear ever more impressive we are trading the illusion of hard experience for the quick delivery of something that looks cool using COTS. Something that justifies more investment into it because it looks cool. Something that might not be delivering at the educational level what the casual onlooker might be thinking it is delivering.

I consider it something very much like 'my kid is a computer genius' syndrome. Where every generation looks at their own personal reference for 'genius' and assumes that their child reached the equivalent proficiency without out realizing that they are bootstrapped on the COTS of the last people who did it. Yes your child was able to write a web based accounting system. On what amounts to a supercomputer from when I was a child with a language that would be appalling inefficient on what was the practical computer when I was a child. The math is not that much more complicated and the protocols and languages were given to them basically for free. I'll issue a challenge here: anyone can write their own protocol for an IP network using UDP. In the financial industry at any place where latency is the determining factor between success and failure writing non-TCP protocols is often the tool of choice. Yet in FIRST we often seem to run away from UDP screaming because TCP 'just works' and you 'don't have to do that work'. This makes TCP basically COTS. Yes using TCP saves the user from the effort to make their work reliable on an average IP network. At the price of the user very likely not actually understanding how it even works - however FIRST is not exactly the average IP network - so what you have here is a perfect example of not understanding why the easy way may not actually be the best way.

It is very cool to watch - but lots of people own cars today - and lots of people can't change a tire properly. So the proposition becomes we expose everyone to the robotics technology like cars and hope that this makes more shining stars because it is accessible. However it is accessible within basically 4, 6 week build seasons and after that - as an adult - you now have to pay for continuing access often at a dear price (see rising college debt). Now I do see this is where the Maker community helps. Where we network our skills and resources together at a reasonable price to break this high cost consequence to not getting the basics in sooner (I spent many hours at NextFAB taking a vast number of their classes and I can clearly see the very wide gap in knowledge when people approach a subject in those required classes). However there is still a large social gap between the two. I see where coming back from being a student to a mentor can help as well. However there are many topics on ChiefDelphi as to the risk of coming back as a mentor and people often can't because the demands of college on their resources are very high.

This is a devil's due. We are advancing our primary cause of FIRST with COTS but we may not be advancing the educational goal one might casually think we are advancing.

[mathking]

I have read a lot of posts, and like that this thread has not turned too heated. So here is my two cents. As a teacher, I don't think using COTS parts necessarily mean students learn any less than they would without them. It is all in how you conduct your design and construction process. We do make use of COTS parts. We also have used chassis we designed and built for 10/14 FRC seasons. We go through a brainstorming - prototyping - testing phase in which we use whatever resources we have at hand to build and test various mechanisms. Once we settle on a basic design, we look for how best to implement it.

For example, last year one of our mentors found a place that was selling some old garage door opener lead screw assemblies. We used these because they were affordable. The students then had to use a combination of calculation and testing to figure out what gear box assembly would be the best to operate it. The calculations showed that we were right on the edge between two and three motors, so we selected a Vexpro gear box that could be used with two or three motors. After a couple of failures we settled on a AndyMark hex hub bored out on one end to accept the lead screw. In the end the kids had a good device and understood its operation well.

I think there is a software analogy to be made here. As techhelpbb pointed out, where kids start today with languages and processing power is amazing compared to where I started (fortran punch cards on an old VAX-11/780). As someone who teaches programming, I also know that my students in general use much better practices in designing programs than I did. Precisely because they are not worried about things like using short variable names to take up less space in memory. I know a number of people who lament that kids learn Java or C++ or Php before learning Assembly. "They need to know how computers really work." But that isn't Assembly, which is really just abstraction at a lower level. "They don't learn how to optimize a program's performance." Wrong. Plain and simple. They still learn about optimizing, but they optimize algorithms and not code. Using prebuilt libraries. Because that is the way they will need to operate when they get jobs. I find that students who learn assembly first tend to write code that is very difficult to read and maintain. It is much easier to teach (and learn) assembly after students have a solid understanding of higher level language.

OK, I am getting a little far afield now. So back to my main point. If you are a mentor and thinking about this question, your students are probably doing fine and learning well. Because the real question isn't whether they build their own gearbox or use one from AndyMark. It's whether they understand what the gearbox does and why you chose it.