Philosophies on design reuse

[ToddF]

For the first time, our team has managed to do some serious development work during the off-season. We have debated internally about how best to utilize what we have learned while staying both within the letter and the spirit of the design reuse rules. I'm a "newish" mentor, (starting my third year). My reading of the rules from the past two years is that there is a rule prohibiting design reuse, immediately followed by a bunch of examples of how to get around that rule. My reading of cheif delphi postings, and supported by the posting below, is that design reuse is a common practice among top tier teams, including numerous chairman's award winning teams. As these are the teams FIRST holds up as examples to emulated, would any of the others be willing to describe their design reuse practices, and how you do this legally? I'd be much happier if the rule were just changed to: "Using previous designs is acceptable. All fabrication must be done after the start of build season." This seems to be a truer reflection of what actually happens.

Originally Posted by apalrd

I think you're completely missing the point about developing drivetrains, and using designs from the design shelf.

When we build prototype drivetrains pre-season, we have several goals:
-Design exercise for everyone involved
-Better performance in any number of categories (turning performance and weight are most commonly optimized) than what we have now
-Find a way to manufacture it easily using our resources
-Create a list of lessons learned that we would change the next time we built a similar drivetrain.

We built a nice development platform in the 2010 off-season. We ended up with an 8wd Dual Drive articulating rear wheel cantilever live axle chassis, with fully automated articulation (all written in C on the IFI processor) and Toughboxes that went around 11fps. We used kit wheels (2008 gray style) because we had a lot of them. We had a lot of things we wanted to learn, so we designed it to test all of them:
-Could we get away with thinwall (1/16th") box tube?
-Would our 2-plate bearing carrier work?
-Would the dynamic performance of the articulating drivetrain be better than a flat 8wd? We also wanted to develop algorithms for this since it worked well in initial tests.
-Would our method of chain tensioning work? We were slightly concerned about the lack of dynamic tensioning on the articulating wheels, and wanted to prove it.

We learned a lot. If, in 2011, we wanted to build a wide robot, it would not have been very hard to use the lessons learned from previous designs to build something good. We put the test chassis on our design shelf (figuratively, it was physically left in the basement), and decided it might be useful in the 2011 season (which it was). When we took the design off the shelf for season use, we also had a list of things we didn't like that we would change, changed them all, and modified it to fit our design goals for that season.

Most of the design in a design from the design shelf is not the exact length and width of the chassis. Had we been required to build a smaller or larger robot, we could have taken the wheel module assembly and located it anywhere along the frame rail, and adjusted the frame rail as necessary, or even added or subtracted wheels easily. To change the length and width, a total of four pieces would be made differently. All of the 'tough' design work was already done, in designing the wheel module assemblies. Those would not change, even as the robot dimensions change.

What's cool about that is we already have the 'stock' engineering done. For a specific game, once we decide we are building a skid-steer robot, and we make a general mechanism package model (large rectangles of space reserved for mechanisms, and optimal hard mounting points), we can CAD the frame rails or panels, and drop in the wheel module model we already have, and make it.


Basically, what I'm saying is that it's not hard to change the dimensions of a shelf design to fit another set of requirements.