Opinion Poll: Proliferation of Prefbricated Parts

[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.

[AndyB871]

Originally Posted by bEdhEd

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

Haha, no worries, I don't. I was just a little worried that the discussion would turn into a flame war before the _real_ discussion started, so I was a bit defensive (plus I'd just finished shoveling after the snowpacolypse so...) . Reading the discussion now (and holy cow it's exploded over the last day) I'm really stoked with where this discussion is going.

I'm seeing lots and lots of great opinions, and even a sort of consensus about COTS parts.

As I Read further, I'm starting to see my viewpoint change a bit too with the way people frame the issue.

This is one of my favorite replies so far

Originally Posted by JesseK

In developing new products, I simply hope that suppliers do not encourage sacrificing resiliency in problem solving for convenience in executing a solution. Students who are taught that mindset are terrible Engineers, expecting where to be told a solution and the complaining when it doesn't "just work by pressing the button". "Business is Business" is a cop-out when it goes that far.

And I think that's the center of my worry too. Problem solving is important and you can't start problem solving by trying to design an airliner, you've got to start small. Where better to start that process than at the lowest (reasonble ) level possible?

For example, to jump into software-land. We're using Java now, and Java has a hozillion great libraries for everything under the sun, INCLUDING lots of fantastic FRC open-source projects that we could leverage. This is a LOT like COTS mech/electrical parts.

I let my students use these libraries, even if (and when) they do find them on their own, but under one condition. I get them to understand the concepts and reasons WHY that library existed.

NAVx MXP is a great example; No one is going to expect every student to understand sensor fusion, and kalman filtering, on top of a robust I/O protocol. That's Crazytown. I'm sure some particularly bright students might be able to get it. I don't expect them to reverse-engineer anything, but I do help them understand what a Filter is, and why it's important.

A yearly project for new students is to build a simple complementary filter that eats gyro data & a single magnetometer and produce a smoothed heading. This is a simple (mathematically too) project that helps them understand just what's happening under the hood. Once that project is done, the concepts are understood, I give the go-ahead and they pull in the NAVX libraries and navigate away! No re-designing the wheel, the guys at kauailabs did a fantastic job, better than we can expect to in 6 weeks, so by all means lets leverage that.

That is how I feel about larger COTS Parts. If you use them, that's great, just make sure the backup knowledge is there, the why, the question to the answer.

Thanks again guys for the fun discussion

[Rangel(kf7fdb)]

Software is getting to the point where not much needs to be done to get it to work. GRIP is a fantastic example of that this year. It takes most of the effort in getting vision code down to a bare minimum. That being said, I don't think it's necessarily a bad thing. For many other non FRC projects, vision has always been a hassle. Whether it's getting libraries to be recognized correctly, installing OpenCV, or cluttering code, it's never been quite as straightforward as I would have liked. With GRIP though, I don't think I will ever have to worry about that again. Although it only supports exports to FRC network tables, it seems like it shouldn't be too difficult to modify the export so that it can be used in non FRC projects. Does it take a lot of the work out of getting vision code? Absolutely! Would I ever go back or tell students to go back to hard coding it for the sake of doing it manually? Probably not. Especially since it makes it easier to transition into more advanced concepts. As new platforms make things easier to code, new things will likely emerge to take it's place.

[ThaddeusMaximus]

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 what it boils down to.

The VersaPlanetary is probably the best example of this. It has enabled amazing mechanisms (which is good- inspiration and stuff), but isn't an amazing mechanism (which is good- students still have to design).

Individual COTS items that don't achieve end goals enable students to create those sweet mechanisms that do, and that's typically where the cool engineering that students learn the most from. There's very little interesting or challenging about figuring out how to get an 8mm, 2mm key shaft to 1/2" hex; it's just resource and time consuming. There's a lot that's challenging and interesting about selecting pinch distance on flywheels, moment of inertia, gear ratio, etc.

[Brian C]

Proliferation of Purchasable, Prefabricated Parts - P4 for all you DoD acronym lovers

I like this quote, it reminded me of the Tinman in the Wizard of Oz when he's called A clinking, clanking, clattering collection of caligenous junk! - C4

But I digress.

The OP for this thread has evidently touched a nerve with a few folks. I can vouch for his sincerity and I understand the reasoning behind his questions.

While I think very few, if any of us want to go back to the days of Small Parts and limited resources. There has been a natural evolution in FIRST for prefabricated purchased items. I think it comes down to some basic things that we have all seen both in FIRST and life in general.

There will always be the "haves" and the "have nots" Them's the facts, like it or not.

I always recall the days of drill motors and Small Parts and all the things that were FIRST back in the 90's and the turn of the century. There were occasions where our team at the time, 311 did exceptionally well. There were also occasions where we were, shall we say less than stellar :rolleyes

The important thing is to realize that it IS an evolutionary process. Recalling those days of dealing with limited supplies and equipment make me appreciate what we have now even more!! I believe that an influx of COTS items that are manufactured specifically for FIRST is a benefit to students in the long term.

Sure we can go through the whole process of designing something from scratch. But there are honestly only maybe 20% of teams out there with the ability and support to actually DO that and do it well. This leaves the majority of teams somewhat lacking in many ways.

If a team purchases a (insert item name here) piece for the robot then there now lies a great opportunity for students to learn from what they see and give them ideas for other things in the future. A little reverse engineering if you will. Over my years involved with FIRST I've seen far too many teams that struggle with fabrication of various components. Only to become disillusioned and frustrated in the long run.

The complete overhaul or deletion of "shop" classes in a many school districts has become a big factor in this as well. But that's a subject for a different discussion.

In recent years I see many of those same teams that used to struggle are now able to be competitive and fully partake in the competition. Much of it is a direct result of what this thread is about. When the team has success the students become more interested and inspired. Once that happens there's no telling what they can achieve!

Someone touched on this in an earlier post. It has leveled the playing field and I think that's a good thing.

The answer, IMHO is there's room for everyone. As long as the students are learning.

As long as they understand the engineering concepts behind the design.

As long as they are exposed to the principles that FIRST displays and embraces.

Then that's what's really important.

Oh one more thing. I can certainly assure that Andy is NOT a crusty, grumpy old man!

[techhelpbb]

Originally Posted by Brian C

Proliferation of Purchasable, Prefabricated Parts - P4 for all you DoD acronym lovers

I like this quote, it reminded me of the Tinman in the Wizard of Oz when he's called A clinking, clanking, clattering collection of caligenous junk! - C4

...

I can certainly assure that Andy is NOT a crusty, grumpy old man!

I fully noted I was a grumpy old man on my first post to this topic
Anyone on my lawn right now needs to work their way through 24" of snow melting to get off.
So I will give you time before I give chase with my cane on a sled.