Opinion Poll: Proliferation of Prefbricated Parts

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

[techhelpbb]

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.

Yes they can certainly get a job - even if they can't optimize their work. They might even be the next FaceBook and still not be able to optimize their work. My actual job besides my personal businesses is leading DevOps for a huge financial institution with about 10,000 developers. My software has been at the core of the financial markets since I was 16 (reviewed, of course, by other programmers with much greater experience at the time). The first time I wrote software that was used by my family business at IT&T and NYMEX in passing as a tool I was 11 years old.

I agree that we would be foolish to discourage the students from taking the more interesting path by using these cool tools (like COTS) we as their seniors (I am 40...when did that happen!) give them for free. However I also want to emphasize that it's easy to encourage them to take the interesting path and totally ignore the foundation. Which works great till it is a major problem (see computer security, Windows Millenium, Windows Vista's task scheduler). Then the difference between those that have the hard foundation and really any interest in that foundation will show.

This is why we can churn out and through programming consultants like water but certain highly regarded entities are looking for the needles in the haystack. So what it boils down to is: does FIRST actually make it easier for those that will be the 'needle in the haystack' who become the most valuable employees to the economy to gain interest and grow. Does COTS help those 'needles in the haystack' or does it make it easier for other people to make them take the easy path when they have the luxury of time to explore the hard path?

I've seen the outcome of this go 5 ways:
1. We've got brilliant students at cool places now that definitely did things the hard way in FRC and gained for it.
2. We've got students now who have realized that the easy way got the job done in FRC but now they need to learn the hard way with all the added pressures of school and adult life.
3. We've got some students that I think might have been better off with the challenge being greater as a participant in FRC because they had more talent and opportunity than they realized.
4. We've got students that took the hard way and it was too much for them.
5. We've got students that rode their talent and when the hard way showed up it was too much commitment for them.

It think it is unavoidable that COTS must stay in FIRST. Just as FIRST must continue to offer high level programming languages. The question then becomes - how does FIRST honor the value of the base engineering and fabrication skills and contribute to the students developing those base skills. Right now I don't think FIRST really has any protection for that flow. If it continues like this it's entirely possible schools will have shops full of tools and they will be a like pretty cars that no one drives.

[MrForbes]

I love having a wide variety of COTS parts...they let all of us bring to life so many more wild ideas....

[mathking]

I think the doing things the hard way vs. doing things the easy way is a false dichotomy. Again, it is about how you use the resources available to you. I have a ton of former students working at cool places and they pretty much all started by learning Pascal, C++ or Java. The key is they learned how to analyze problems then develop and test good algorithms. Their are FRC teams that use all or almost all custom parts where very few students know how or why those parts are created. And teams that use all custom parts where many kids are involved in the design, fabrication and testing of those parts. I don't think there is an intrinsic "right way" and "wrong way" to do this. As I said, if you are part of this discussion you are probably aware enough of the issues to make sure your students learn.

[techhelpbb]

Originally Posted by mathking

I think the doing things the hard way vs. doing things the easy way is a false dichotomy. Again, it is about how you use the resources available to you.

This I entirely agree with. COTS can be used or it can be abused. I can see a team fielding an entire COTS robot bolted together still be successful at teaching the base skills for their team of that year. Maybe they are an engineering school and the FIRST robot was just a passing milestone.

The thing is: there's not much in FIRST that interlocks the concepts of 'how you use the resources available to you' for education versus to simply produce the robot. Obviously if you don't 'use the resources available to you' to build a robot you won't be able to compete. However there is no assurance that anyone used those resources to more widely educate. I am not even sure there's a prize for it and I think maybe there should be something more there.

I can see, MathKing because you have tangible results, that you are delivering on the educational side of this and I'd like to see that rewarded. It should not just be about delivering the robot and that is even a FIRST slogan.

[Robomarfa]

This is my second year in FRC. We bought Rhino two hours after kickoff. Does it feel "too easy?" Sure. I did not want to pass up on a competitive advantage. We did the KoP chassis in our rookie year and did not get it until the end of Week 1. We have limited resources and would have gone the KoP with pneumatics like most others. I predict the end results in six weeks would be very similar with either choice. Except the students will learn about the advantages and disadvantages of a track drive instead of a second year of six-wheel. We all start with some level of COTS after all.

I have a 9th grader who has never programmed and speaks little English. She has learned LabView and has figured out joystick, pneumatics, relays, NavX, Drive, sonar, autonomous, limit switches, Talon soft limits, PID and encoders. Starting at a higher level of software abstraction made this possible. If she wants, she can pursue a proper education in software engineering based upon this introduction. FIRST. Same can be said for mechanical systems. We inspire them to further pursue an interest in engineering or science. FRC is not the College of Engineering. It is one path to the door to the college.

In the end, I think FIRST might consider the pros and cons of sharing the game beforehand with suppliers that make game-specific COTS. That is the real issue under discussion here, not gearboxes. As for me, I'll buy the equivalent of Rhino drive next year if I can. We do not have a machine shop (or hospital or Home Depot) in our county. I want my kids to have a positive experience compared to kids that have their workspace at NASA. Looking at you my fellow Texan friends on 118! Y'all inspire us because of your history and resources. If COTS gives my kids a better overall experience on a very un-level playing field, I'm all in.

[techhelpbb]

I don't want to discourage students from going to college. However my intent in what I am about to link and write is to encourage students to understand that time is time - it moves forward - and one should always make the most of the time you have.

The hard analysis is that we can't rely on college to make up for the opportunities we miss teaching today.

The longer the time you put into something the more practiced you can be at it. So while I value the late bloomer and otherwise disadvantaged as deeply as anyone else - I worry we can easily create a system where we waste great opportunity in the name 'we can fix that later'.

Ask any system administrator: 'I'll do it later' often means it won't get done and very few can afford to remain in college for very long periods of time.

FRC is huge. It gives awards for so many diverse things. We should be able to find a way to balance an award or reward for those that manage to teach the fundamental skills in: engineering and fabrication (we already do for programming we somewhat do for engineering) and can show that and the value it returns on an FRC field. If we can manage this then it doesn't matter what COTS stuff is in the community. In parallel we are helping those that are at a disadvantage by letting them challenge those who are not disadvantaged with what the community can cook up in the form of COTS.

[bEdhEd]

Originally Posted by MrForbes

I love having a wide variety of COTS parts...they let all of us bring to life so many more wild ideas....

EXACTLY! This is precisely my point about imagination in my last post on this thread. There's a whole world of possibilities with COTS parts only if you choose to be creative with them.

[Foster]

I think that the COTs products are great. I'm willing to match wire wrap skills with "techhelpbb", and I am also coming from his background. But COTS parts make it easier for teams to build a robot and compete and I'm willing to put out a thesis that says COTS parts makes it easier for teams to sustain themselves.

The RI3D teams show how COTS stuff can come together to make something and I think that is a positive sign. I think that having COTS parts allows teams to try to pull some feature (swerve drive, shooter, climber) and focus on that while knowing that they can manage the rest of the robot.

Big fan of VEX, AndyMark and West Coast. But there are other places to look for parts. That was the good thing about the early days. "Why no that's not a drill that is a drive train!" Can you find all the parts to build a robot at Bed Bath and Beyond? (Hint, those stand mixers have pretty heavy duty planetary transmissions).

I like the "stand on the shoulders of giants" theory. I like that teams can build on what others have done. But I agree with techhelpbb, at some point roboteers need to be able to dig down and look at what the things are built on. In the programming world TCP is the bucket we can carry data in. And while I can design and code a UDP based system that would send 35 frames a second to the driver station the question becomes "what can I do instead of that". COTS will never replace just sitting down and thinking about the problem and put forth multiple solutions.

[techhelpbb]

Originally Posted by Foster

And while I can design and code a UDP based system that would send 35 frames a second to the driver station the question becomes "what can I do instead of that". COTS will never replace just sitting down and thinking about the problem and put forth multiple solutions.

The question for me is: why hasn't someone just done that?
Once they do and open source it the solution can easily be the equivalence of COTS.

I get that FIRST/FRC may not want to be in that business either but it's clearly well within the scope of the skills the community can bring together. So are we dropping TCP in there just to avoid looking at the gorilla in the room?

If I didn't think the military would immediately grab any work I did on this and put it into drones I might do this myself.

Originally Posted by GreyingJay

Knowing when to invent your own and knowing when to go with an established solution is itself an important design skill.

I agree there is definitely value in not pushing unnecessarily uphill.

I recently have been helping a mechanical engineering firm to upgrade some data capture equipment that is somewhat high speed but also has many features you could do with a laptop from Walmart.

Their previous solution was very hardware intensive for things that would have been better served from software. It was very custom through the whole process and once it acquired data that was hugely unnecessary.

Surely the folks that designed it showed they were very interested in locking them in and getting to play with all those elements, but it drove the cost per unit over $10,000 and that was likely not necessary.

Surely it is a difficult to capture 1Msps at 24bits for 9 channels differential at these levels cleanly and that's an engineering issue. Pushing that data over a wireless to a Cloud that's actually been done and can be replicated.

So yes it matters not to over engineer - but you can under-engineer if you don't know any better.
In the case of this unit I was working in clearly there was a little of both.
Hopefully when we finish they'll have a COTS data acquisition module which solves the core acquisition issue.
The rest they can filter and modify in software with whatever expendable PC hardware they can find.

I have no doubt that the person that built this originally is a competent developer of FPGA based hardware.
They thought the rest would best be served by things like sticking a Raspberry Pi in there - COTS that makes no sense in this system.

System integration, which is what this is, requires a a wide enough experience to know where the edge of the box is.

[philso]

Originally Posted by bEdhEd

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

Yes! There are other forms of competition where all one can use are COTS hardware, say in some classes of motorsports such as the Porsche Supercup. The competition is no less fierce. There is no lack of learning opportunities for the participants.


Is FIRST Lego League not inspiring for its intended audience? In FLL, the competitors can only use un-modified Lego manufactured parts which seem to qualify them to be described as COTS parts.